Todas as regras definidas na especificação anterior, são válidas para esta também, ou seja, a solução proposta prevê o cenário de que toda a parte de configurações do MLA, será mantida no próprio ERP. Somente serão geradas pendências “individuais” dentro do Fluig. Ou seja, não haverá um “fluxo” desenhado dentro do Fluig para demonstrar os níveis de aprovação de cada documento.

Por exemplo, um documento que passa por três níveis de aprovação, no Fluig, gerará três Workflows distintos com uma única atividade de “Aprovação”.

O objetivo é que o usuário possa gerar as pendências para poder aprová-las pelo Fluig, mas possa continuar utilizando os programas que já existem atualmente para realizar esse processo também. Ou seja, ele escolhe aonde vai fazer as aprovações, seja no Fluig, no ERP (programas progress), por e-mail ou no portal HTML.

A ideia é que cada documento do MLA seja um workflow separado. Dessa forma, será possível identificar mais facilmente as atividades pendentes da Central de tarefas do Fluig por processo de workflow. O cliente poderá também implantar somente os workflows de documentos que são utilizados pela empresa.

1) Habilitar e configurar a integração

A parte de configuração no MLA000 (Parâmetros de aprovação) e MLA0101 (Tipos de Documentos), será mantida igual, somente será necessário permitir que esses programas tratem também os novos documentos liberados (13, 14 e 16).

• MLA0000: Ao efetivar o registro, permitir que a exportação dos dados de integração com o Fluig, seja feita também para os novos documentos;
• MLA0101: Habilitar os campos da integração com o Fluig para os novos documentos;
  
  

2) Sincronização da geração de pendências entre Fluig e MLA

Toda a parte de sincronização de geração de pendências, se mantém da mesma forma que na especificação anterior, pois já foi previsto o tratamento para geração de pendência para todos os tipos de documentos.

3) Workflows e Formulários

Cada workflow de aprovação de documento, possuirá um formulário que permitirá visualizar os detalhes do documento que está sendo aprovado, o formulário de aprovação das pendências será parecido com o formato que é utilizado para o Portal do MLA (HTML).

Por padrão, na parte inferior de cada formulário deve conter:

• Um agrupador com detalhes da pendência (mesmas informações que são apresentadas no detalhe da pendência no HTML) - Por padrão o agrupador deve vir fechado;
• Um agrupador com as informações de histórico de aprovação (como já mostra no detalhe da pendência no HTML) - Por padrão o agrupador deve vir fechado;
• Campos para que o usuário indique se está realizando uma aprovação ou rejeição. Haverá um campo para selecionar se é uma aprovação ou rejeição, com as opções “Aprovar” e “Reprovar” (por padrão a Aprovar deverá vir selecionada). Abaixo deverá conter o campo de narrativa. Caso selecionada a opção de “Reprovar” deverá ser apresentado uma lista com os códigos de rejeição para que o usuário possa selecionar o código.

Informações técnicas sobre Workflows e Formulários:

• Para que os workflows possuam as mesmas características dos outros já liberados, como validações, bloqueios, gestores de processo, atividades, sugere-se copiar de o diagrama do WFMLA001, re-nomeando para o novo workflow e apenas mudar o formulário para o que for necessário;
• Para que os formulários possuam as mesmas características dos outros já liberados, como campos padrões, validações, informações de detalhes e histórico, rotinas de aprovação, etc. sugere-se copiar essas informações de formulários já liberados, como por exemplo o formulário do WFMLA001. O que terá que ser alterada é a busca das informações de negócio, específicas para o documento.

4) Análise, aprovação e reprovação de pendências, diretamente no Fluig

A parte de análise, aprovação e reprovação de pendências, ocorrerá da mesma forma que detalhado na especificação anterior. Basta garantir que o workflow chame as mesmas rotinas de aprovação/reprovação, no mais o ERP já está preparado para tratar todos os documentos do MLA.

5) Sincronização de atualização de pendências (alteração/eliminação/aprovação) entre MLA e Fluig

A parte de sincronização na alteração, eliminação e aprovação de pendências irá funcionar da mesma forma como descrito no outro requisito, sem alterações necessárias na parte do ERP. Apenas é necessário garantir que o número das atividades no workflow sejam as mesmas dos workflows já liberados, para que seja possível realizar as movimentações.

6) Re-análise de documentos 

A validação criada no outro requisito irá funcionar da mesma forma, sem necessidade de alterações.

7) Usuário mestre

Deverá buscar os usuários mestre do MLA para serem gestores do processo no fluig. Garantir que a chamada é realizada da mesma forma que os demais workflows já liberados.

8) Aprovadores alternativos

Os aprovadores alternativos do MLA não serão integrados com o Fluig neste momento. Dessa forma, se for necessário utilizá-los no Fluig, eles devem ser configurados manualmente, como usuários substitutos. No momento de realizar as aprovações o Fluig fará as validações para saber se o usuário é um aprovador alternativo válido.

9) Bloqueio de cancelamento de workflow

É necessário criar um bloqueio de cancelamento do Workflow, pois pendências de aprovação não podem ser “canceladas”, somente se o documento for eliminado, e neste caso o ERP que fará o cancelamento. Neste caso apresentar uma mensagem "Workflow não pode ser cancelado manualmente".

10) Monitor de pendências de integração com o Fluig

O monitor de pendências desenvolvido na especificação anterior, pode ser utilizado para monitor os problemas de integração dos novos documentos que estão sendo liberados, sem a necessidade de nenhum tipo de alteração.

11) Formulários mobile

Os formulários mobile, possuirão menos campos que os formulários padrões a serem executados em desktop, em função das restrições existentes.

Contrato de Compra:

• Número do contrato;
• Descrição
• Estabelecimento (código e descrição)
• Condição de pagamento (código e descrição)
• Validade (início e fim)
• Limite Valor 
• Limite Quantidade
• Fornecedor (código e nome abreviado)
• Valor
• Opção "Mais detalhes" deve mostrar:
  • Data Contrato;
  • Data Revisão;
    
  • Natureza;
  • Moeda (código e descrição)
  • Modalidade (código e descrição)
  • Razão social do fornecedor
  • Situação
  • Controle Recebimento
  • Mensagem (código e descrição)
  • Variação Quantidade e Valor
• Opção "Responsáveis" deve mostrar:
  • Comprador (código e nome);
  • Contato 
  • Gestor técnico (código e nome)
• Opção "Transporte" deve mostrar:
  • Transportador (código e nome)
  • Via Transporte
  • Frete
• Opção "Narrativa" deve mostrar: a narrativa do contrato;
• Opção "Itens":
  • Sequência e código do item: serão mostrados como agrupador;
  • Ao abrir o agrupador  deve ser mostrado:
    • Descrição do item
    • Preço do fornecedor
    • Quantidade total
• Opção "Anexos":
  • Sequência e início da descrição: serão mostrados como agrupador;
  • Ao abrir o agrupador deve ser mostrado:
    • Descrição
    • Narrativa
• Opção "Cláusulas":
  • Sequência e início da descrição: serão mostrados como agrupador;
  • Ao abrir o agrupador deve ser mostrado:
    • Descrição
    • Narrativa

Medição:

• Contrato;
• Descrição;
• Sequência Medição;
• Sequência Item;
  
• Ordem;
• Sequência Evento;
• Estabelecimento (Código e descrição)
• Item (Código e descrição)
• Valor
• Opção "Mais detalhes":
  • UM
  • Data Previsão
  • Quantidade prevista
  • Percentual
  • Observação
    
    

Evento:

•  Ordem
•  Seq Evento
•  Seq Item (sequência e código do item)
• Descrição do item
  
•  Contrato (código e descrição)
•  Estabelecimento (código e descrição)
•  Valor
• Opção "Mais detalhes":
  • Comprador (código e nome)
  • Data evento
  • Data Previsão
  • Data realização
  • Nova realização
  • Condição Pagamento (código e descrição)
  • Perc. Previsto
  • Previsão Entrega
  • Valor Previsto
  • Qtde Prevista
  • Libera Medições parciais
• Opção "Observação e Narrativa": Deve mostrar a observação e narrativa do evento.

Informações técnicas sobre formulários Mobile:

• Para apresentação dessas informações no mobile, a ideia é fazer a leitura do histórico de aprovação, e em um API intermediária filtrar para retornar somente o que for preciso no momento;
• Para a questão dos campos nas opções de "Detalhes", criá-los dinamicamente para não ficar muito pesado o carregamento;