Professional Documents
Culture Documents
OMNIA PLATFORM
Versão 1.0
Junho de 2016
Índice
Índice................................................................................................................................. 2
Introdução ......................................................................................................................... 6
Plataforma ......................................................................................................................... 6
REA .................................................................................................................................6
Processo de Desenvolvimento............................................................................................. 8
Templates ........................................................................................................................8
Como configurar uma entidade transacional para ser vista como um calendário? ..................... 12
Interface .......................................................................................................................13
Atributos .......................................................................................................................... 15
Fórmulas .......................................................................................................................18
Ações.............................................................................................................................19
Momentos ..................................................................................................................... 19
Comportamento .............................................................................................................21
Pg 2
Como definir obrigatoriedade? ......................................................................................... 21
Interface .......................................................................................................................23
Visualização de dados....................................................................................................... 29
Listas.............................................................................................................................29
Relatórios de impressão.................................................................................................33
Pg 3
Como testar um relatório durante o desenvolvimento? ........................................................ 34
Notificações...................................................................................................................... 40
Menu ................................................................................................................................ 42
Segurança ........................................................................................................................ 43
Erros ................................................................................................................................ 45
Anexos ............................................................................................................................. 46
Operações de comparação............................................................................................... 48
Pg 4
Funções matemáticas ..................................................................................................... 48
Pg 5
Introdução
Este documento pretende servir como um manual do utilizador para toda a componente de modelação da
plataforma. Para esse fim, percorre todas as secções desta componente, explicando-as ao pormenor e
fornecendo exemplos descritivos para cada uma.
Plataforma
A plataforma consiste numa aplicação alojada na cloud cujo objetivo é permitir a qualquer pessoa, sem
necessidade de escrita de código, modelar aplicações informáticas orientadas ao negócio.
Permite uma prototipagem rápida de soluções para vários problemas, bem como uma entrega ágil de
diferentes versões de uma solução, respondendo a alterações nos requisitos que surjam durante o
desenvolvimento de um projeto.
O desenvolvimento na plataforma é efetuado numa linguagem de domínio específico, baseada nos princípios
do modelo REA (descritos na secção seguinte).
Ao usar uma linguagem deste tipo (baseada na teoria económica e na teoria da contabilidade), a plataforma
permite aos modeladores descrever soluções de uma forma mais aproximada ao domínio do problema e
mais afastada de questões de implementação, garantindo assim a facilidade em desenvolver uma aplicação
ainda que o utilizador tenha conhecimentos limitados de informática, mas elevados dentro do domínio do
problema em questão.
REA
A framework REA (Resources, Events, Agents) é orientada ao desenvolvimento de sistemas de
contabilidade, com foco no registo dos diversos eventos económicos de uma organização. Assume que
existe um número limitado de conceitos presentes em todo o software de contabilidade e que é possível
desenhar uma aplicação facilmente adaptável, sem pôr em causa o cumprimento das regras de negócio.
Recursos económicos: entidades do sistema que representam bens com valor comercial e
quantidades possíveis de definir. Estes bens estão na posse de Agentes Económicos, sendo
trocados em transações financeiras entre agentes. Exemplos: Produtos, Dinheiro e Serviços;
Pg 6
Compromissos: representam o compromisso assumido entre dois agentes em efetuar uma
transação de recursos. O Compromisso é assumido uma vez que, muitas vezes, a transação não se
realiza no momento em que é definida, mas sim posteriormente. Podem ser de dois tipos:
incremento ou decremento, conforme representem uma diminuição ou um aumento nos recursos da
empresa. Exemplos: Pagamento de bens adquiridos, muitas vezes pago a prazo;
Eventos económicos: representam a transação de recursos entre dois agentes, atuando um como
fornecedor e o outro como recetor. Desta forma, a transação representa um incremento para o
agente recetor e um decremento para o agente fornecedor. Excetuando alguns casos, como a
prestação de serviços, um Evento ocorre no momento em que foi criado.
Todos os compromissos são satisfeitos por um ou mais eventos económicos, numa ação
denominada por fulfillment, despoletada no momento em que a troca de recursos se efetua. Este
cumprimento pode ser total ou parcial.
A estes conceitos do modelo REA, a implementação da plataforma adiciona alguns conceitos adicionais:
Processo: permite agrupar várias interações em processos de negócio. Desta forma, é possível
obter uma organização lógica de interações de natureza semelhante.
Na secção Descrição do Problema deste documento, é apresentado um exemplo de um problema que pode
ser modelado na plataforma e que exemplifica os conceitos descritos nesta secção.
Pg 7
Processo de Desenvolvimento
A plataforma destaca-se, comparativamente a outras soluções de desenvolvimento, pela estrutura de
geração da aplicação. A aplicação produzida é interpretada diretamente a partir do modelo e todas as
modificações passam por alterações no modelo – usando uma estrutura no code (não necessita da escrita de
código).
O utilizador modelador pode desenvolver toda a sua aplicação testando os efeitos das suas alterações à
medida que modela, sem necessidade de fazer builds demoradas para obter resultados.
Toda a modelação é feita no contexto de um tenant. Um tenant corresponde a uma conta na plataforma, que
contém um modelo específico para a resolução de um problema em particular.
Templates
Um template é um tipo de tenant que corresponde a um modelo desenvolvido para dar resposta a um
problema específico. O objetivo é que corresponda à versão ‘base’ de uma solução, sem quaisquer dados a
nível da aplicação, e que essa versão base seja posteriormente utilizada para criar novos tenants, que
podem ser vistos como instanciações de um modelo para o cliente final.
Tal como descrito anteriormente, existem vários tipos de entidades na plataforma que partilham
características de modelação:
Relativamente aos eventos económicos, estes são também representados como entidades, neste caso
entidades transacionais:
Pg 8
Como criar uma entidade?
Aceder a Menu | Entities | Agents / Resources
Todas as entidades são criadas na zona correspondente do menu lateral da modelação. Contudo, as
entidades transacionais não são passíveis de criar aqui, uma vez que só fazem sentido no contexto de uma
interação. Os Agentes e Recursos partilham uma estrutura, sendo portanto criadas de forma análoga.
Ao aceder ao menu, surge a listagem de todas as entidades existentes desse tipo, disponíveis para
edição, bem como um botão de criação. Escolhendo a criação de uma nova entidade, surge um formulário
com os seguintes separadores:
Pg 9
Como permitir relacionar utilizadores?
Aceder a Menu | Entities | Agents
Nas entidades do tipo Agente é possível permitir a sua associação a um utilizador da plataforma. Para tal,
aceder à edição/criação de uma entidade deste tipo e no separador Others marcar a caixa Allow Users.
Um processo corresponde a uma unidade de organização na plataforma que permite agrupar várias
interações de natureza semelhante num só elemento agregador. São necessários apenas dois parâmetros
para configurar um Processo:
Exemplo: Numa aplicação de encomendas (ver Descrição do problema), criar o processo “Gestão de
Encomendas”. Posteriormente, este irá conter interações tanto representando o registo de encomendas
como o seu registo de receção.
Na plataforma, as interações são a forma de definição das operações que serão executadas na aplicação,
representando uma interação entre vários agentes e trocas de vários recursos.
Uma interação tem três áreas: o cabeçalho (Document), as linhas de grelha (Details, opcionais), e um
resumo (Summary, opcional). O cabeçalho contém os atributos definidos no contexto da interação,
enquanto nos detalhes é possível ter uma ou mais entidades transacionais e no resumo uma entidade
transacional.
Para adicionar uma nova interação, selecionar o botão Add Interaction no contexto de um processo. Este
formulário, tal como o das Entidades, tem um conjunto de separadores onde é possível configurar vários
parâmetros:
Pg 10
o Entity Items: itens que existem no contexto de uma interação e surgem como uma
tabela na aplicação. Ao criar um item destes, surge um novo separador para o
configurar (ver Entidades de configuração);
o Details: corpo do documento (opcional). Pode conter uma ou mais entidades
transacionais, correspondentes a linhas de grelha (ver Como configurar um
compromisso/evento?);
o Summary: resumo do documento (opcional). Pode conter uma entidade transacional
(ver Como configurar um compromisso/evento?);
View: definição de diferentes vistas sobre a interação que está a ser criada (ver Como
configurar uma View?);
Interaction Attributes: definição de todos os atributos do cabeçalho do documento e seus
comportamentos, bem como a organização do ecrã sob a forma de grupos. Os atributos são
descritos em mais detalhe na secção Atributos e os grupos na secção Como gerir grupos?. Os
atributos base estão detalhados no anexo Atributos base;
Atributos de entidades transacionais: por cada entidade transacional adicionada, surge um
novo separador que permite configurar os atributos correspondentes, da mesma forma que no
cabeçalho;
Documentation: definição de uma hiperligação para um documento de apoio, externo à
plataforma, associado a cada ecrã da interação;
Others: outros comportamentos associados às interações:
o Hidden: ver Como esconder uma entidade/interação?;
o After Submit: ver Como configurar os comportamentos de gravação?;
o Form Operations: ver Como configurar os comportamentos de gravação?;
o Tabbed Groups: ver Como gerir grupos?;
o Allow to Revert: ver Como permitir a reversão de entidades/interações?.
Na criação de uma interação, é frequentemente necessário criar um compromisso ou evento, quer para os
detalhes, quer para o resumo. Para tal, primeiramente é importante identificar se é necessário um
compromisso (a linha corresponde a uma promessa de algo) ou um evento (corresponde a uma satisfação
de uma promessa anterior). Sabendo isso, podemos reutilizar uma entidade transacional ou selecionar uma
nova, recorrendo à opção Create New.
Ao selecionar a opção Create New surge uma janela onde é possível definir os detalhes do
compromisso/evento a adicionar:
Exemplo: Numa aplicação de encomendas (ver Descrição do problema), criar uma interação representando
um pedido de encomenda. Aí pretende-se definir uma entidade na secção de detalhes que corresponda à
requisição ao fornecedor (Provider Agent) a entrega de artigos (Resource) à empresa (Receiver Agent).
Como esta entrega será efetuada numa data a definir, o tipo de entidade transacional em causa será um
compromisso.
Após a criação de um compromisso ou evento, ou ao editar uma interação que já os tenha, é possível aceder
a uma série de parâmetros de configuração:
Como configurar uma entidade transacional para ser vista como um calendário?
Aceder a Menu | Processes | Criar ou editar uma interação
Numa interação, ao editar um evento ou compromisso, é possivel definir que este esteja visível sob a forma
de um calendário. Para tal, definir a checkbox Calendar como ativa, que fará aparecer um conjunto de
parâmetros a configurar:
Pg 12
Invalid Week Days: contém os dias não válidos para marcação no calendário;
Calendar Period Begin/End: data de início e de fim do calendário;
Title field: contém a informação a usar como título do evento demonstrado;
Category field: categoria do calendário;
Default date field: informação da data onde se pretende posicionar o calendário;
Allow to select ranges: definir se um utilizador pode marcar eventos ou compromissos num
conjunto de dias de uma só vez usando o calendário;
Begin date field: colocar a data de início de uma seleção de dias no calendário;
End date field: colocar a data de fim de uma seleção de dias no calendário;
Blocked days field: informação dos dias do calendário bloqueados (feriados);
External events field: outros eventos (não eventos ou compromissos) que podem ser pertinentes
no calendário;
Group by: atributo pelo qual são agrupados os elementos na vista de cronograma;
Custom Icons: determina se podem ser usados ícones customizados no calendário;
o Property: atributo do tipo Value Pair cujos valores serão usados para calcular o ícone;
o Icons: mapeamento entre valores do atributo alvo e o ícone a usar.
Para criar novas vistas e alternar entre as existentes, é necessário clicar no botão disponível no canto
superior direito, escolhendo a vista que se pretende manipular ou selecionando a opção “Create”.
Interface
Após a criação de grupos, é também possível reorganizar a ordem pela qual são exibidos no sistema,
também no separador Atributos.
Pg 13
Por omissão, os grupos surgem na aplicação sob a forma de separadores. Contudo, existe a opção Tabbed
Groups, na secção Others, que permite trocar este comportamento e mostrar os grupos agrupados de forma
vertical, consecutivamente, no cabeçalho.
Outros comportamentos
Também é possível alterar as opções que surgem no momento da gravação. O parâmetro Form Operations
permite definir as operações base da plataforma que estarão disponíveis. Existem dois modos possíveis:
Standard: são mostradas todas as opções: Limpar, Gravar e, se aplicável, Submeter para
Aprovação;
Custom: permite a seleção individual de cada operação.
Ao aceder ao separador Others fica acessível a propriedade Allow Contacts. Esta permite definir se o tipo
de entidade pode ser exportado sobre a forma de um ficheiro de contacto (formato vCard – extensão .vcf).
Em caso positivo, é necessário indicar quais os atributos da entidade que irão ser utilizados para compor a
informação do ficheiro de contacto.
Pg 14
Atributos
A figura dos atributos na plataforma é transversal, sendo estes comuns na definição dos diversos tipos de
entidades e interações. A sua gestão é igual nos diferentes locais, mantendo a mesma estrutura de
separadores:
Tipos de dados
A plataforma suporta um conjunto de tipos de dados que condicionam o aspeto, conteúdo ou
funcionalidade dos atributos que os usam:
Pg 16
Value pair Referência a uma entidade chave/valor da plataforma.
Após a definição do tipo de campo, existem alguns campos adicionais que permitem configurar/definir limites
aos valores introduzidos, mediante o tipo de atributo:
Pg 17
Tipo de entidade representada neste
Entity Type Other Entity
campo.
Por último, no caso em que o atributo é do tipo Other Entity, existe ainda uma funcionalidade de filtro das
entidades a mostrar, segundo a lógica na secção Como filtrar entidades?.
Fórmulas
As fórmulas no contexto de atributos permitem aos utilizadores efetuar um conjunto de operações. Esta
secção descreve de forma breve os diferentes tipos de operações possíveis, sendo que o anexo Referência
de Fórmulas as descreve mais extensivamente.
Pg 18
A sintaxe para utilização de um atributo em fórmulas depende da sua localização:
Na entidade/interação atual:
o [CodigoDoAtributo]
No cabeçalho de uma interação:
o [Document.CodigoDoAtributo]
Nos valores de uma grelha:
o [Details.CodigoDaEntidadeTransacional.CodigoDoAtributo]
o [Summary.CodigoDaEntidadeTransacional.CodigoDoAtributo]
Ações
As ações podem ser definidas no contexto de um atributo, e são constituídas por um momento de execução,
juntamente com um conjunto de ações a executar nessa condição.
Momentos
Evento Descrição
Pg 19
Tipos de Ação
Pg 20
Como definir uma ação?
Primeiro, é necessário definir o momento de execução, para depois definir uma condição para limitar a
execução (ver Como definir as fórmulas?).
De seguida, definir o tipo de ação a executar. Após a escolha do tipo de ação, é possível configurar as
condições em que a ação vai ser executada.
Em ambos os casos é possível inativar a ação temporariamente, quando não se pretende que seja
executada, mas não se pretende apagar. É ainda possível definir se se pretende que, ao executar, ocorra um
erro caso não sejam obtidos resultados da ação.
Comportamento
Pg 21
Como definir um valor por defeito?
O campo Default Value permite definir o valor por omissão que um atributo recebe. Corresponde sempre a
um valor concreto e não uma referência a outro atributo ou fórmula. Por exemplo, é possível definir que um
campo true/false começa ativo, com Default Value como true, ou definir que a quantidade base de uma
encomenda é sempre 10, definindo-o como 10.
Para este fim, é necessário configurar uma operação lógica que faça uma comparação entre o valor pelo
qual se deseja filtrar e o valor da entidade com a qual está a ser feita a comparação.
Propriedade Descrição
Pg 22
Interface
Para além desses campos, existe um terceiro, Visible from Screen Sizes, que determina os tamanhos de
ecrã onde o atributo ficará visível.
Row e Column: definem a linha e coluna do formulário onde se pretende que o atributo surja. No
máximo, é possível ter quatro colunas por cada linha, ou seja, suportar até quatro atributos
consecutivos;
Order: no contexto de uma grelha, determina a ordem pela qual irá aparecer o atributo na grelha;
Size: representa o tamanho desse atributo, de 0 a 10, sendo que o somatório do tamanho de todos
os atributos na mesma Row deve corresponder a 12, sabendo que para cada valor Size é
necessário adicionar 2 para a label;
Grid Size: representa o tamanho de um atributo numa grelha, em percentagem. O somatório dos
atributos na mesma linha da grelha deve corresponder a 100%.
As opções deste separador sobrepõem-se à possibilidade de editar o atributo, ou seja, mesmo que o atributo
esteja definido como Editable, se a condição de ReadOnly Condition falhar, não é possível alterá-lo no
momento de edição.
Pg 23
Acesso a dados
A escrita das fórmulas não executadas na interface (executadas, por exemplo, nas ações, listagens ou em
filtros de segurança), tem uma nomenclatura ligeiramente diferente, para lhes permitir aceder, a partir de
qualquer contexto, a todos os atributos necessários:
Distinção entre atributos base e não base: sempre que um atributo tenha sido criado pelo
utilizador deverá ser precedido do carácter “#”;
Distinção de atributos do tipo entidade: sempre que um atributo representa uma outra entidade
do sistema deverá ser precedido do seu tipo: Agent:Atributo, Resource:Atributo,
UserDefinedEntity:Atributo, etc. Caso se pretenda aceder a uma propriedade do mesmo, esta
deverá ser colocada a seguir à definição do atributo – por exemplo Agent:Atributo.Propriedade;
Distinção de atributos do sistema: alguns atributos não são representados no modelo de uma
forma física, mas são disponibilizados para permitir validações, nomeadamente ao nível do
mecanismo de segurança. Estes atributos não físicos são representados entre “@”.
As diversas condições que compõem uma fórmula podem ser concatenadas com separadores lógicos “&” (e)
e “|” (ou). A secção Fórmulas de acesso a dados descreve alguns exemplos deste tipo de fórmulas.
Entidades de configuração
Nem todas as entidades utilizadas pela plataforma se encaixam nos princípios base do modelo REA. Existem
alguns pontos onde foram definidas estruturas auxiliares, que complementam a funcionalidade base deste
modelo, e são descritas neste capítulo.
As User-Defined Entities, ou entidades definidas pelo utilizador, são entidades auxiliares da plataforma que
não se enquadram no modelo REA, e descrevem outras entidades que não sejam nem agentes nem
recursos, mas que têm importância para os modelos criados, através da adição de informação adicional às
transações existentes.
A sua configuração é idêntica à dos agentes e recursos, portanto deve ser seguida a lógica descrita em
Como criar uma entidade?.
Pg 24
Como criar tabelas de configuração?
Os Entity Items, ou tabelas de configuração, existem no contexto de um determinado tipo de entidade,
permitindo definir uma nova estrutura representada numa tabela, garantindo uma relação 1 para N. Após
definir o Código e Nome desta nova estrutura, é adicionado um novo separador que permite manipular os
seus atributos.
A configuração de uma destas tabelas é idêntica à das restantes Entidades, com pequenas diferenças: os
Entity Items apenas têm um grupo e os seus atributos são sempre definidos dentro da lógica de uma grelha.
As entidades do tipo Value Pair – pares chave/valor -, são um elemento auxiliar que deve ser utilizado para
limitar o input dos utilizadores a um pequeno conjunto de opções que raramente sofre alterações. Para definir
uma entidade deste tipo, há dois pontos a configurar:
Exemplo: Numa aplicação de encomendas (ver Descrição do problema), pretende-se definir o estado da
encomenda. Criar um Value Pair, com os pares 0/Proposta, 1/Aceite e 2/Fechada. Adicionar um atributo à
interação com o tipo Value Pair e identificar o par criado.
Satisfação de compromissos
As satisfações de compromissos, ou fulfillments, funcionam como uma mecânica complementar dos
Compromissos, permitindo completar a troca de recursos.
A operação de satisfação do compromisso pode ser efetuada tanto por eventos como por outros
compromissos. É possível que mais de um tipo de evento ou compromisso satisfaça o mesmo compromisso.
Os fulfillments são sempre definidos no contexto de uma interação, aquela que contém a entidade
transacional (compromisso ou evento) que irá fazer a satisfação do compromisso.
Pg 25
Como configurar uma satisfação de um compromisso?
Aceder a Editar ou Criar uma interação | Configure Fulfillments
Process: processo que contém a interação na qual se inclui o compromisso a ser satisfeito;
Interaction: interação na qual se inclui o compromisso a ser satisfeito;
Commitment: compromisso a ser satisfeito;
Kind: tipo de fulfillment:
o Any: satisfação permitida por qualquer valor;
o Equal: satisfação permitida pela quantidade original;
o Less than: satisfação permitida por uma quantidade inferior à original;
o Greater than: satisfação permitida por uma quantidade superior à original;
o Equal only: satisfação permitida pela quantidade total apenas, não sendo permitidos
fulfillments parciais.
A configuração de mapeamentos entre entidades necessita de recorrer a dois locais diferentes. Primeiro, é
necessário definir as Type conditions, que permitem filtrar os compromissos a satisfazer. A sintaxe utilizada
é idêntica à descrita em Como filtrar entidades?.
From: atributos do compromisso a satisfazer; utiliza a lógica de Acesso a dados, com as seguintes
particularidades:
o Não necessita de referenciar o tipo de entidade para aceder a um atributo de uma entidade
(Por exemplo, ProviderAgent.Code);
o Ao aceder a campos não base não é necessário o ‘#’;
Pg 26
To: atributos correspondentes da entidade transacional, selecionáveis via dropdown.
Por omissão, a plataforma cria um conjunto de mapeamentos entre os campos base das duas entidades, que
podem ser alterados ou removidos pelo utilizador modelador.
Fluxos de aprovação
A plataforma disponibiliza um mecanismo de aprovações que pode ser aplicado a entidades e interações,
permitindo que estas sejam validadas por um ou mais indivíduos antes de chegarem a um estado final.
É possível definir várias etapas seguindo essa lógica, sendo necessário configurar cada uma:
Start Stage: indica se a etapa representa o início do fluxo de aprovação. Apenas pode haver uma
etapa inicial;
End Stage: indica se a etapa representa o fim do fluxo de aprovação. Podem existir N etapas finais,
sendo necessária pelo menos uma;
To Approve: indicação de qual a entidade transacional (compromisso ou evento) aprovada nesta
etapa. A indicar apenas em etapas intermédias;
Next Stage when Approved: etapa para a qual a interação passa após aprovação (ver Como
configurar o fluxo de etapas?);
Next Stage when Rejected: etapa para a qual a interação passa após rejeição (ver Como
configurar o fluxo de etapas?);
Evaluate Execution: fórmula que determina se a etapa atual será executada, com base em
informação da interação (ver Como configurar o fluxo de etapas?);
Approver Rules: determinação da escolha do aprovador (ver Como configurar o próximo
aprovador?);
Editable Attributes: atributos da interação e das suas entidades transacionais disponíveis para
edição na etapa de aprovação (ver Como tornar um atributo editável numa etapa de aprovação?).
Pg 27
Como configurar o próximo aprovador?
Aceder a Criar ou Editar uma entidade/interação | Configure Approval Stages
Ao configurar uma etapa de aprovação, é necessário definir quais os utilizadores que terão acesso à
aprovação. Em qualquer momento, a escolha é feita com base em dois atributos:
Evaluate Execution: fórmula que avalia se a interação corresponde às condições definidas. Caso
seja verdadeira, o aprovador definido em Assign To nesta linha pode aprovar o documento;
Assign To: atributo que contém a informação do Agente associado ao utilizador que irá ter acesso
a esta aprovação.
Não necessita de referenciar o tipo de entidade quando queremos aceder a um atributo de uma
entidade (Por exemplo, ProviderAgent.Code);
Ao aceder a campos não base, não é necessário o ‘#’;
As comparações são feitas com ‘=’ e ‘<>’, e para comparar com algo vazio basta deixar em branco o
outro lado da comparação, por exemplo, “Employee.Manager.User<>”, o que corresponde a dizer
que o utilizador do Manager existe;
As variáveis booleanas são escritas como TRUE e FALSE.
A lógica do fluxo de etapas de aprovação consiste numa espécie de grafo dirigido, com um estado inicial e N
estados finais. O estado inicial, aqui, não corresponde a uma etapa de aprovação propriamente dita, mas ao
valor que as entidades ou interações têm antes de entrar no fluxo, por exemplo, ao gravar como rascunho,
antes de submeter para aprovação.
Para definir o fluxo, cada uma das etapas não finais possui dois atributos que definem para que estado
irá passar: Next Stage when Approved e Next Stage when Rejected.
Para além dessa definição, existe um parâmetro associado, Evaluate Execution, que determina se a etapa
será ou não percorrida. Nesse parâmetro, é definida uma fórmula. Caso a fórmula retorne FALSE, a
interação passa para a Next Stage when Approved, como se tivesse sido aprovada. A fórmula utiliza a
lógica de Acesso a dados, com as seguintes particularidades:
Não é necessário referenciar o tipo de entidade quando se pretende aceder a um atributo de uma
entidade (Por exemplo, ProviderAgent.Code);
Ao aceder a campos não base, não é necessário o ‘#’;
As comparações são feitas com ‘=’ e ‘<>’, e para comparar com algo vazio basta deixar em branco o
outro lado da comparação, por exemplo, “Employee.Manager.User<>” corresponde a dizer que o
utilizador do Manager existe;
As variáveis booleanas são escritas como TRUE e FALSE.
Pg 28
Como tornar um atributo editável numa etapa de aprovação?
Aceder a Criar ou Editar uma entidade/interação | Configure Approval Stages
A plataforma permite definir casos em que o aprovador pode efetuar pequenas correções ao documento sem
a necessidade de o rejeitar. Para estes casos, existe uma secção Editable Attributes, onde é possível
selecionar os atributos editáveis, individualmente, com um dropdown.
Visualização de dados
No âmbito da visualização de informação, a plataforma permite construir dois tipos diferentes de
visualizações de dados: Listas e Gráficos. Estes podem ser organizados sobre a forma de painéis de
controlo (Dashboards) ou ser demonstrados de forma distinta (no caso das listas).
Listas
Uma lista é uma forma de visualização dos dados de uma entidade ou interação específica. É possível
apresentar listas em várias formas: no contexto de um painel de controlo, nas listagens por defeito da
plataforma ou noutros contextos de listagem de entidades/interações (por exemplo, opções separadas no
menu).
Ao criar ou editar uma lista, surge um ecrã de configurações, com as seguintes opções:
Se se pretender configurar uma lista para servir de base a um calendário, existe um conjunto de opções
adicionais a configurar:
Default view: vista do calendário a mostrar por defeito: anual, mensal, mensal (cronograma),
semanal ou diário;
Calendar name: nome do ficheiro de calendário exportado;
Title field: contém a informação a usar como título do evento demonstrado;
Category field: categoria do calendário;
Begin date field: colocar a data de início de uma seleção de dias no calendário;
End date field: colocar a data de fim de uma seleção de dias no calendário;
Blocked days field: informação dos dias do calendário bloqueados (feriados);
Group by: agrupar os elementos na vista de cronograma.
Ao configurar uma lista, é necessário escolher a fonte de dados. Existem duas opções de definição da fonte:
Use existing: de forma a simplificar a criação de novas listas, é possível usar uma fonte de dados já
existente, obtendo assim toda a informação dos atributos presentes nessa fonte para a lista atual;
Create new: criação de uma nova fonte de dados. Para criar uma nova fonte de dados é necessária
a indicação dos atributos da entidade/interação a mostrar na lista, inserindo a informação visível na
tabela seguinte:
Propriedade Descrição
Pg 30
Ordem da ordenação do atributo. Como é possível ordenar por vários
Sort Order
atributos, tem de ser definida a lógica de aplicação da ordenação.
Neste separador, é possível decidir se queremos disponibilizar individualmente cada uma das opções que a
plataforma oferece por defeito (Edit, Approve, Revert, Print, Copy), bem como adicionar novas operações
associadas à execução de scripts de extensibilidade.
Painéis de controlo
Um painel de controlo, ou dashboard, é uma estrutura da plataforma que pode conter um conjunto de listas
e/ou gráficos. Podem ser mostrados ao utilizador nos menus ou na página inicial, após o momento de login.
Um gráfico é uma forma de visualização dos dados de uma entidade ou interação específica. A lógica de
configuração de um gráfico passa pelas seguintes configurações:
Pg 31
o A lógica de escolha de campos é idêntica à das listas, descrita em Como configurar os
dados de uma lista?;
o Where: filtro a aplicar sobre a informação obtida, composto sob a forma de uma fórmula
(opcional);
o Top: número de elementos a obter (opcional);
o Date Field: campo que representa uma data pela qual se pretende filtrar os elementos do
gráfico (opcional);
o Company Code Field: campo que representa o código da empresa, permitindo filtrar os
dados por empresa (opcional);
Data display configuration: define o aspeto do gráfico:
o Chart Type: a plataforma suporta quatro tipos de gráficos: linha, donut, barras verticais e
área;
o X axis: atributo que corresponderá às categorias;
o Value: atributo que corresponderá ao valor.
A fórmula a usar no Where utiliza a lógica de Acesso a dados, com as seguintes particularidades:
As comparações são feitas com ‘=’, ‘>’, ‘<’, ‘<=’, ‘>=’ e ‘<>’, e para comparar com algo vazio basta
deixar em branco o outro lado da comparação;
As variáveis booleanas são escritas como TRUE e FALSE.
A configuração dos painéis de controlo divide-se em dois pontos: a configuração do cabeçalho, e o conjunto
de elementos a adicionar ao painel. Relativamente ao cabeçalho, existem os seguintes parâmetros:
De seguida, é possível configurar os elementos a aparecer no dashboard (ver Como adicionar elementos?).
É possível adicionar tanto listas como gráficos a um dashboard. Para esse fim, é necessário configurar um
conjunto de parâmetros:
Pg 32
Visible from: tamanho do ecrã a partir do qual o elemento é visível;
Description: descrição do elemento, localizável em vários idiomas;
Row: linha do painel de controlo na qual o elemento será colocado;
Column: coluna do painel de controlo na qual o elemento será colocado;
Size: tamanho do elemento, de 1 a 12. O somatório do Size de todos os elementos colocados na
mesma Row do painel de controlo deve corresponder a 12;
Chart / List: gráfico ou lista a mostrar;
Dimensions: atributos da lista/gráfico que podem ser usados como dimensões, permitindo
visualizar a informação com base nestes;
Default dimensions: das dimensões definidas em Dimensions, quais devem estar selecionadas
por omissão, através de um parâmetro true/false para cada uma;
Max number of elements: número máximo de elementos da lista/gráfico;
Compare with corresponding period: no contexto de um gráfico, indica se é pretendida a
comparação com o período anterior correspondente;
Hide until have data: indica se o elemento deve aparecer no painel mesmo que não tenha dados.
Apenas é possível ter um painel de controlo visível na página de entrada. Se se pretender controlar a
informação mostrada, como por exemplo, mostrar gráficos diferentes a utilizadores diferentes, é necessário
colocar todos os gráficos como elementos no painel de controlo e controlar o acesso através de perfis de
utilizador e da opção Hide until have data.
Relatórios de impressão
A plataforma permite a obtenção de interações sobre a forma de relatórios. Estes são gerados sobre a forma
de ficheiros .pdf, sendo possível aos utilizadores de aplicações da plataforma descarregá-los para o seu
dispositivo.
Para iniciar o desenvolvimento, é necessário aceder à área de modelação, e, no contexto de qualquer tipo de
interação, selecionar a opção “Configure Printing Reports” e descarregar a solução Visual Studio que irá
auxiliar o teste e desenvolvimento.
Pg 33
No Visual Studio, é possível aceder a um conjunto de ficheiros:
Report.xml: amostra da interação em XML, que contém os dados necessários para testar o script;
Report.xsd: estrutura da interação em XSD, que irá ser utilizada para compor a estrutura do
relatório;
ReportDevelopment.cs: definição de parâmetros a utilizar nos testes, nomeadamente identificação
do ficheiro de Report a testar, do ficheiro que contém os dados e da estrutura de dados;
Report.rdlc: ficheiro no qual será desenvolvido o relatório.
De forma a obter uma amostra de uma interação, aceder de novo à área de modelação e, selecionando a
listagem do tipo de interação a desenvolver, escolher a opção Download XML example.
Para obter a definição da estrutura a usar no relatório, deverá ser selecionada a opção Download XML
Schema. Ter em conta que só é possível descarregar estes dois elementos após ter criado uma interação do
tipo em causa.
Após a obtenção de toda a informação, será necessário aceder ao ficheiro de reporting e, acedendo à opção
View | Report Data e definir os diferentes Datasets, escolhendo a opção “Add Dataset”. Em seguida, após
a definição de todos os Datasets, é possível manipular o relatório, definindo as diversas áreas e elementos
do mesmo, utilizando o designer do Visual Studio.
De seguida, o funcionamento é similar a qualquer outra aplicação, sendo possível recorrer a breakpoints,
prints de informação para depuração, entre outros. De forma a aceder às ferramentas de depuração do
Visual Studio é recomendado que o desenvolvimento seja feito na mesma máquina onde está instalado o
sistema externo onde serão executados os scripts.
Para adicionar um relatório à plataforma, é necessário indicar o valor dos seguintes parâmetros:
Pg 34
Number of Copies: número de cópias a gerar em cada impressão;
Configuration: configuração opcional do relatório. Caso não seja indicada, é gerada
automaticamente;
Default: indicação da configuração a ser usada por omissão no tipo de interação;
File: carregamento do ficheiro “rdlc” do relatório.
<GridCommentsProperty>Resource</GridCommentsProperty>
<Datasets>
<DataSet>
<Name>DataSetInteractionCompany</Name>
<TableName>myCompany</TableName>
</DataSet>
<DataSet>
<Name>DataSetInteractionHeader</Name>
<TableName>ExpenseReport</TableName>
</DataSet>
</DataSets>
Campos adicionais: definição de campos não presentes na interação, mas que fazem parte das
entidades associadas à mesma:
<ReportExtraFieldsConfiguration>
</Entity Code="@Employee.Code" Type="Employee"
Kind"Agent">
<Field Name="Name" />
</Entity>
</ReportExtraFieldsConfiguration>
Pg 35
Casas decimais: definição opcional do número de casas decimais de um determinado atributo da
interação:
<DecimalScaleConfig>
<ExpenseReport>
<ExpenseReport_Rate>5</ExpenseReport_Rate>
</ExpenseReport>
</DecimalScaleConfig>
O XML resultante deverá ser adicionado como uma nova configuração XML e poderá posteriormente ser
referenciado na configuração do relatório (ver Como adicionar um relatório à plataforma?).
A definição da forma de comunicação com outros sistemas é feita sobre a figura de sistemas externos, sendo
a leitura de informação modelável sob a forma de entidades externas, descritas neste capítulo.
A escrita de informação noutros sistemas é garantida sobre a figura de scripts de extensibilidade, descritas
no capítulo Scripts de integração em sistemas externos.
Os tipos de sistemas externos permitem à plataforma comunicar com os mais variados sistemas. Uma vez
que cada sistema tem as suas necessidades de comunicação específicas, deve ser representado sob a
forma de um tipo de sistema externo diferente, de forma a permitir definir os seus atributos específicos.
A configuração de uma destas entidades é idêntica à das restantes Entidades, com a diferença de que os
External Systems apenas suportam a vista por omissão.
Após a sua definição, as entidades externas podem ser utilizadas em diversos contextos da plataforma:
Pg 36
Em outras entidades ou interações: para evitar a replicação de informação, é possível consultar
informação a partir de um sistema externo;
Em listagens e gráficos: visualizar dados diretamente a partir de um sistema externo.
Code: identificador do novo tipo de entidade externa. Este identificador é único e não pode ser
alterado após a sua definição;
Name: nome do tipo de entidade externa, localizável em vários idiomas;
Query: definição da consulta SQL que irá permitir o acesso à informação de uma entidade;
Query Key Parameter: definição do parâmetro da consulta a usar como parâmetro chave;
External System: tipo de sistema externo sobre o qual a consulta será executada.
Pg 37
Para obter o ficheiro a usar no Entity.cs, aceder novamente à área de modelação e, selecionando a listagem
do tipo de entidade ou interação a desenvolver, recorrer ao método Download C# Sample.
Para obter o ficheiro Default.json, no mesmo local, recorrer a Download JSON example. Os dados obtidos
por este método são dados retirados da aplicação.
Caminho completo
//#R C:\PathToDll\DllName.dll
Caminho completo, utilizando variáveis de ambiente
//#R %PROGRAMFILES%\DllName.dll
Caminho relativo (usando os caminhos configurados no ficheiro de configuração)
//#R DllName.dll
Para além disso, é necessário adicionar (como em qualquer projeto C#) as diretivas using:
using MyDll;
O excerto de código abaixo mostra uma inicialização do cliente de API, seguida de autenticação na
plataforma, recorrendo às credenciais do utilizador configurado no sistema externo. Após essa autenticação,
é possível aceder a dados usando a API.
document.MarkToApplyChanges();
Pg 38
A execução desta linha de código implica que quaisquer alterações feitas anteriormente serão refletidas na
plataforma.
De seguida, o desenvolvimento realiza-se como em qualquer outra aplicação, sendo possível recorrer a
breakpoints, prints de informação para depuração, etc.. De forma a ter acesso às ferramentas de depuração
do Visual Studio, é recomendado que o desenvolvimento seja feito na mesma máquina onde está instalado o
sistema externo onde serão executados os scripts.
Existe um conjunto de parâmetros a configurar sempre que se pretende adicionar um script à plataforma:
Pg 39
State transition: na transição entre etapas de aprovação;
Revert: ao reverter uma entidade ou interação;
Revert state: ao reverter uma etapa de aprovação;
List: numa listagem;
UI Trigger: despoletado por algo na UI (por exemplo, um atributo Button);
Account setup: ao criar uma conta nova com base nesta – usado, por exemplo, para carregar
dados de demonstração;
Remote Query: script a executar para fazer consultas remotas a um sistema externo, no âmbito de
uma entidade.
Essas ações são combinadas com um momento de execução para determinar quando os scripts são
chamados:
Notificações
A plataforma OMNIA permite o envio de notificações por correio eletrónico numa diversidade de
operações relacionadas com as entidades e interações. Para gerir as notificações de um determinado tipo de
entidade ou interação é necessário aceder a esse tipo e selecionar a opção “Configure Notifications”.
As notificações de email podem ser enviadas nas seguintes operações de entidades ou interações:
É possível configurar várias notificações diferentes a enviar em cada uma das operações identificadas. Para
configurar, ver Como configurar o envio de uma notificação por email?.
A plataforma, por defeito, cria um conjunto de notificações que cobre os casos mais comuns (ver o anexo
Notificações por omissão).
Pg 40
Como configurar o envio de uma notificação por email?
Aceder a Criar ou Editar uma entidade/interação | Configure Notifications
Condition: fórmula que representa uma condição a avaliar para decidir se a notificação é enviada
(opcional);
Approval Stage: a notificação é enviada sempre que a entidade/interação entre na etapa definida.
Aplica-se apenas na operação Go to Approve;
To: contém o email para o qual será enviada a notificação;
CC: contém o email para o qual será enviada a notificação em CC;
BCC: contém o email para o qual será enviada a notificação em BCC;
Subject: assunto do email, localizável em vários idiomas. Pode ser composto com base em
parâmetros (ver Como configurar os parâmetros de uma notificação?);
Parameters: lista dos atributos da interação (separados por vírgulas) que serão usados para
compor o assunto do email (ver Como configurar os parâmetros de uma notificação?);
Body: corpo do email, traduzido nos diversos idiomas da aplicação. Permite utilização de sintaxe
HTML e pode ser composto com base em parâmetros (ver Como configurar os parâmetros de uma
notificação?);
Parameters: lista dos atributos, separados por vírgulas, que serão usados para compor o corpo do
email (ver Como configurar os parâmetros de uma notificação?).
Tanto no assunto como no corpo dos emails enviados a partir da lógica de notificações, é possível introduzir
excertos de texto baseados em atributos, através de parâmetros. A lógica dos parâmetros das notificações
consiste em passar um conjunto de atributos, separados por vírgulas e entre parêntesis retos, nos campos
Parameters do ecrã de notificações.
A fórmula de acesso aos atributos utiliza a lógica de Acesso a dados, com a particularidade de não
necessitar de referenciar o tipo de entidade quando se pretende aceder a um atributo de uma entidade
(Por exemplo, ProviderAgent.Code).
De seguida, é possível referencia-los nos campos Subject e Body, recorrendo a uma sintaxe semelhante a
métodos de formatação de strings: por exemplo, {0} será substituído pelo primeiro elemento dos parâmetros.
Pg 41
@URL-ENTITY-APPROVE@: gera no e-mail um link para aprovar uma determinada entidade;
@URL-ENTITY-EDIT@: gera no e-mail um link para editar uma determinada entidade.
Menu
A plataforma gera de forma automática o menu disponibilizado aos utilizadores, à medida que a modelação
da aplicação é efetuada. No entanto, uma vez que a organização dos diversos elementos pode não ser a
mais adequada para casos específicos de aplicações, é possível o desenvolvimento de um menu
customizado à medida das necessidades identificadas.
Para construir um menu, devem ser definidos os diversos elementos que o compõem, relacionados entre si
sobre a forma de ligações em árvore, com a profundidade máxima de cinco níveis. Existem três tipos de
elementos que podem ser utilizados:
Nos menus, a plataforma disponibiliza um elemento que permite disponibilizar uma hiperligação para
qualquer página web. Para definir um elemento do tipo External Link, é necessário:
Text: texto que será visível no menu (localizável nos vários idiomas);
Icon: ícone a mostrar;
URL: hiperligação a aceder.
O elemento Application link é o elemento que permite o acesso a uma funcionalidade da plataforma. Para
definir o acesso à funcionalidade é necessário:
Text: texto que será visível no menu (localizável nos vários idiomas);
Icon: ícone a mostrar;
Link To: tipo de função da plataforma para a qual se pretende apontar (Agente, Interação, etc.), e
indicar o elemento em específico;
Pg 42
Operation: quando aplicável, é possível definir a operação a que a entrada no menu dará acesso
(Listar, criar ou aprovar);
View: quando aplicável, é possível definir qual a vista que será mostrada;
Approval Stage: quando aplicável, é possível definir a etapa de aprovação a que a entrada no
menu dará acesso.
Um Container, ou agrupador de links, é um elemento do menu que funciona como elemento agregador. A
partir deste não é efetuada nenhuma ação, apenas são disponibilizados outros elementos do menu.
Para definir um elemento do tipo “Container”, é necessário indicar o texto que será visível posteriormente no
menu (localizado em diversos idiomas), bem como o ícone a mostrar.
Segurança
Todas as aplicações modeladas sobre a plataforma têm acesso a uma área de administração. Nesta área é
possível gerir as configurações de segurança e, apesar de não ser diretamente do domínio da modelação, é
importante detalhar as diferentes configurações possíveis nesta secção.
A configuração de perfis na aplicação permite atribuir diferentes privilégios aos utilizadores, garantindo o
controlo no acesso às diferentes operações. A configuração é bastante granular:
Interações: os privilégios de acesso a interações são geridos no contexto das empresas, permitindo
que os utilizadores tenham privilégios distintos no acesso às interações mediante a empresa e/ou
série de documento da plataforma;
Entidades: privilégios definidos para cada tipo de entidade;
Operações: ao aplicar os privilégios em entidades/interações, são aplicados individualmente por
operação (Acesso aos dados, criar novo, editar, remover, entre outros). É possível aplicar filtros de
segurança em algumas das operações (ver Como configurar um filtro de segurança?);
Vistas: os privilégios de acesso têm em conta as diferentes vistas sobre as entidades/interações. É
possível fornecer aos utilizadores privilégios de acesso a apenas um conjunto limitado de vistas;
Etapas de aprovação: os privilégios têm em conta as etapas de aprovação, quando estas existem.
É possível garantir que os utilizadores só têm acesso às etapas necessárias (ver Como configurar
um filtro de segurança?);
Painéis de controlo: cada perfil pode ter ou não acesso a cada um dos painéis;
Pg 43
Outros: os restantes privilégios são atribuídos de forma individual e não são relevantes do ponto de
vista da modelação.
Os filtros de segurança, na criação de perfis, são aplicáveis em dois locais distintos: no acesso a operações
e no acesso a etapas de aprovação. A sintaxe a utilizar em qualquer um destes casos está descrita na
secção Acesso a dados.
Ao aceder ao menu de criação de utilizadores a partir de uma aplicação, existe um conjunto de campos
obrigatórios a configurar:
Para inativar um utilizador, é necessário aceder à sua edição. No cabeçalho do documento é visível a
checkbox Inactive, que deve ser marcada. Ao gravar, o utilizador fica inativo.
Pg 44
Erros
Existe um conjunto de situações em que a plataforma devolve erros enquanto o utilizador modelador está a
desenvolver a aplicação, que podem levar a uma resolução no ambiente de modelação. Esta secção
descreve algumas situações comuns e como as ultrapassar:
Erro Solução
Your user has no AGENT related. Please Garantir que há um agente do tipo desejado criado e
check user configuration. atribuído na edição de utilizadores ao utilizador ativo.
An error has ocurred: Model error (…) Ocorreu um erro numa das fórmulas que foi definida.
Unable to process binding (…) Validar se as fórmulas dos atributos estão corretas.
External Entity created. An error has Ao criar a entidade externa, a plataforma tenta gerar
occurred while creating the default list. uma listagem por defeito, mas ao haver um erro de
conexão ao sistema externo, a listagem não é criada.
Pg 45
Anexos
Anexo 1: Descrição do problema
Múltiplos dos exemplos descritos ao longo deste manual baseiam-se num caso concreto – a modelação de
uma aplicação de gestão de encomendas a fornecedores para uma empresa.
Pedido de Encomenda:
o Registo por parte dos colaboradores;
o Identificação de vários artigos distintos por documento;
o Aprovação dos pedidos por parte de um gestor;
Entrega de Artigos:
o Registo por parte dos colaboradores;
o O registo deve permitir identificar os artigos presentes nos pedidos de encomenda;
o Deve também permitir indicar artigos que não estavam previstos no pedido inicial;
o Deve ser possível fechar as entradas de artigos no momento da receção, não permitindo
mais entradas para um determinado pedido de encomenda.
Pg 46
Entrada de artigo: entidade transacional do tipo evento, que representa a entrada
efetiva do artigo na empresa. Modelada como um incremento de um artigo entre o
fornecedor e a empresa. Completa o compromisso de encomenda.
Integrações:
o O pedido de encomenda irá gerar um documento do tipo Encomenda a Fornecedor (ECF)
no ERP Primavera.
Operações matemáticas
Função Descrição
Operações booleanas
Função Descrição
NOT(cond) Dada uma condição cond, a função NOT retorna o valor lógico
contrário ao que a condição apresenta – true se esta for false, false
se esta for true.
Pg 47
XOR(conj) Dada uma condição cond, a função NOT retorna o valor lógico
contrário ao que a condição apresenta – true se esta for false, false
se esta for true.
Operações de comparação
Função Descrição
Funções matemáticas
Função Descrição
Pg 48
SUMIF(conj,cond) Dado um conjunto conj de atributos, a função SUMIF retorna o
somatório dos valores desses atributos que passam a condição
cond.
SUMIFS(conj1, cond1, conj2, Dados vários pares conjunto conjN de atributos/ condições condN,
cond2…) a função SUMIFS retorna o somatório dos valores desses atributos
que passam a condição associada.
ISEVEN(n), ISODD(n) Dado um número n, ISEVEN(n) retorna true se for par, false se for
ímpar; ISODD(n) retorna false se for par, true se for ímpar.
Pg 49
COUNTUNIQUE(conj) Dado um conjunto conj de atributos, a função COUNTUNIQUE
conta o número de incidências desses atributos que são distintos
entre si.
MAX(conj), MIN(conj) Dado um conjunto conj de atributos, a função MAX retorna o maior
desses atributos; a função MIN retorna o menor.
Função Descrição
HOUR(h), MINUTE(h), Dada uma hora (ou data e hora) h, retornam o valor correspondente
SECOND(h) às horas, minutos e segundos respetivamente.
Função Descrição
UPPER(txt), LOWER(txt) Dado um texto txt, a função UPPER converte-o inteiramente para
maiúsculas; a função LOWER converte-o inteiramente para
minúsculas.
Pg 50
Anexo 3: Exemplos de fórmulas
Operações matemáticas
=[UnitPrice]*[Quantity]
Esta fórmula permite atribuir a um atributo o valor da multiplicação do “UnitPrice” pela “Quantity”.
=([UnitPrice]*[Quantity])/12
Operações booleanas
=IF([Selected]==true&[RowNumber]==[@1],true,false)
Esta fórmula retorna verdadeiro apenas nos casos em que é marcada a checkbox Selected na primeira linha
da entidade selecionada.
Funções matemáticas
=SUM([Details.GoodsPurchaseRequest.Amount])
Esta fórmula permite atribuir a um atributo o somatório dos atributos “Amount” de todas as entidades
transacionais (linhas) do tipo “GoodsPurchaseRequest”.
=PRODUCT([Details.GoodsPurchaseRequest.Amount])
Esta fórmula permite atribuir a um atributo o produto dos atributos “Amount” de todas as entidades
transacionais (linhas) do tipo “GoodsPurchaseRequest”.
=PRODUCT(1,2,15)
Valor obtido: 30
=SUMIF([Details.GoodsPurchaseRequest.Quantity], '>10')
Esta fórmula permite atribuir a um atributo o somatório dos atributos “Quantity” de todas as entidades
transacionais (linhas) do tipo “GoodsPurchaseRequest” onde a encomenda foi feita com uma quantidade
superior a 10.
=SUMIF([2,4,8,16], '>5')
Valor obtido: 24
Valor obtido: 12
Pg 51
=ABS(-5)
Valor obtido: 5
=SIGN(-35)
Valor obtido: -1
=ISEVEN(2)
=AVERAGE([Details.GoodsPurchaseRequest.Amount])
Esta fórmula permite atribuir a um atributo a média dos valores dos atributos “Amount” de todas as entidades
transacionais (linhas) do tipo “GoodsPurchaseRequest”.
=AVERAGE([1,2,3])
Valor obtido: 2
=AVERAGEIF([Details.GoodsPurchaseRequest.Amount], '>10')
Esta fórmula permite atribuir a um atributo a média dos valores dos atributos “Amount” de todas as entidades
transacionais (linhas) do tipo “GoodsPurchaseRequest” cujo valor é superior a 10.
=MEDIAN([Details.GoodsPurchaseRequest.Amount])
Esta fórmula permite atribuir a um atributo a mediana dos valores dos atributos “Amount” de todas as
entidades transacionais (linhas) do tipo “GoodsPurchaseRequest”.
=COUNT([Details.GoodsPurchaseRequest.ProviderAgent])
Esta fórmula permite atribuir a um atributo o número de fornecedores diferentes definidos nas entidades
transacionais (linhas) do tipo “GoodsPurchaseRequest”.
=COUNT([1,2],[3,4])
Valor obtido: 4
=COUNTIF([Details.GoodsPurchaseRequest.Amount] , '>10')
Esta fórmula permite atribuir a um atributo o número de todas as entidades transacionais (linhas) do tipo
“GoodsPurchaseRequest” cujo valor “Amount” é superior a 10.
=COUNTBLANK([Details.GoodsPurchaseRequest.Amount])
Esta fórmula permite atribuir a um atributo o número de todas as entidades transacionais (linhas) do tipo
“GoodsPurchaseRequest” cujo valor “Amount” é vazio ou nulo.
Pg 52
=COUNTBLANK([1,'',0,2,null])
Valor obtido: 3
=COUNTUNIQUE([1,1,2,2,3,3])
Valor obtido: 3
=MAX([Details.GoodsPurchaseRequest.Amount])
Esta fórmula permite atribuir a um atributo o maior valor “Amount” de todas as entidades transacionais
(linhas) do tipo “GoodsPurchaseRequest”.
=MIN([1,2,3,4])
Valor obtido: 1
Partimos do campo DateOccurred (predefinido), contendo a data em que ocorreu um determinado evento
(por exemplo, registo de uma encomenda) e se deseja obter o mês. De forma análoga, é também possível
obter o dia ou o ano.
=NOW()
Modelar um campo com o nome Hoje, partindo do exemplo anterior, e utiliza-lo para preencher um outro
campo com esta sequência, que ficará com o aspeto “15/4”.
=HOUR(NOW())
Recorrer à função NOW() para obter a data/hora atual e obter o valor correspondente à hora atual (UTC)
dessa data.
=MINUTE("1/1/2016 15:05:01")
Valor obtido: 5
Pg 53
=LOWER(“Outono”)
=CONCATENATE(“Joana”, “ ”, “Guedes”)
Formula Descrição
Pg 54
Anexo 5: Atributos base
Pg 55
No caso dos External Systems é removido o ExternalSystemCode e ExternalCode, sendo adicionado o
seguinte conjunto de atributos:
Pg 56
Atributos base das entidades transacionais
Pg 57
CommitmentToFulfill, Configurações associadas ao mecanismo de Não
AmountToFulfill, fulfillments.
CloseCommitment
Pg 58
CompanyCode Código da empresa à qual a interação está Sim
associada.
Notificações na aprovação
Etapa Inicial:
Campo Valor
To: [CreatedBy.ContactEmail]
Parameters: [MisEntityType.Code]
Parameters: [MisEntityType.Code],[NumberSerieCode],[Number]
,[Approver.Email]
Pg 59
Etapa(s) Intermédia(s):
Campo Valor
To: [ApproverContactEmail]
Parameters: [MisEntityType.Code],[NumberSerieCode],[Number]
Stage: EtapaIntermedia
Parameters: [MisEntityType.Code],[NumberSerieCode],[Number]
,[CreatedBy.ContactEmail]
Etapa(s) Final(Finais):
Campo Valor
To: [CreatedBy.ContactEmail]
Parameters: [MisEntityType.Code]
Parameters: [MisEntityType.Code],[NumberSerieCode],[Number]
,[Approver.Email]
Pg 60
Notificações na reversão
Todas as etapas:
Campo Valor
To: [PreviousApproverEmail]
Parameters: [MisEntityType.Code],[NumberSerieCode],[Number]
Parameters: [MisEntityType.Code],[NumberSerieCode],[Number]
,[Approver.Email],[ModifiedDate]
Pg 61
PRIMAVERA Business Software Solutions, S.A. © 1993 - 2016, All rights reserved
Pg 62