Histórico da Página

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 (5, 9, 10 e 18).

• 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 (lembrando que o documento 5 e 18 possuem controle de prioridade de aprovação);
  
  

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.

Image Added

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.

Solicitação de Cotação:

Cabeçalho:

• Número da solicitação
• Estabelecimento (código e descrição)
• Requisitante (código e nome)
• Valor
• Opção "Ver narrativa": deve mostrar a narrativa 

Itens: 

• Sequência e Código do item:
  • Será apresentado como agrupador.
  • Ao abrir o agrupador deve ser mostrado:
    • Descrição do item
    • UM
    • Quantidade requisitada
    • Quantidade atender
    • Valor Unitário
    • Valor Total
    • Data entrega
    • Conta e Centro de Custo
  • Opção "Ver narrativa": deve mostrar a narrativa o item da solicitação.
    
    
    
  • Opção "Ver Cotação aprovada": deve mostrar as informações abaixo (para a cotação aprovada da ordem): 
    • Aprovada;
    • Fornecedor (código e nome abreviado);
    • Moeda (código e descrição);
    • UM fornecedor;
      
    • Condição de pagamento (código e descrição);
    • Prazo;
    • Preço Unit Fornec;
    • Preço Total (Sem IPI);
    • Preço Total (Com IPI);
    • Opção "Mais detalhes": deve mostrar:
      • Mesmas informações do "Exibir detalhes" do formulário desktop;
  • Opção "Ver Outras cotações": deve mostrar as mesmas informações (para as demais cotações da ordem)
    
    
  • Opção "Ver Última compra": deve mostrar as informações abaixo: 
    • Pedido 
    • Ordem 
    • Quantidade
    • Fornecedor (código e nome abreviado);
    • Moeda (código e descrição);
    • UM fornecedor;
      
    • Condição de pagamento (código e descrição);
    • Prazo;
    • Preço Unit Fornec;
    • Preço Total (Sem IPI);
    • Preço Total (Com IPI);
    • Opção "Mais detalhes": deve mostrar:
      • Mesmas informações do "Exibir detalhes" do formulário desktop;
    
    

Cotação:

Cabeçalho:

• Ordem
• Estabelecimento (código e nome abreviado)
• Item (código e descrição)
• Valor
• Opção "Mais detalhes": 
  • Requisitante (código e nome);
  • Comprador (código e nome);
    
  • Quantidade
  • UM
  • Moeda (código e descrição)
  • Narrativa Item Solicitação
    

Cotação aprovada:

• Fornecedor (código e nome abrev)
• Moeda (código e descrição)
• UM Fornec
• Condição de pagamento (código e descrição);
• Prazo;
• Preço Unit Fornec;
• Preço Total (Sem IPI);
• Preço Total (Com IPI);
• Opção "Mais detalhes": deve mostrar:
  • Mesmas informações do "Exibir detalhes" do formulário desktop;
    
    

Opção "Outras cotações":

• Mesmo formato da apresentação das informações da cotação aprovada;

Opção "Última compra":

• Pedido 
• Ordem 
• Quantidade
• Mesmo formato da apresentação das informações da cotação aprovada;
  

Processo de compra (Item):

• Mesmas informações da cotação (somente apresentando a mais o campo de número do processo).

Processo de compra (Total):

Cabeçalho:

• Processo (código e descrição);
• Estabelecimento (código e descrição);
• Comprador (código e nome);
• Total a aprovar;
• Total aprovado;
• Valor total do pacote;

Ordens:

• Ordem e código do item
  
  • Será apresentado como agrupador.
  • Ao abrir o agrupador deve ser mostrado:
    • Descrição do item;
    • UM;
    • Quantidade;
    • Aprovada;
    • Opção "Mais detalhes":
      • Cotação aprovada: Mesmas informações da cotação
      • Opção "Outras cotações": Mesmas informações da cotação
      • Opção "Última compra": Mesmas informações da cotação

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;

[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.

[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante

[3] Categorias são obrigatórias para os programas FLEX.

[4] Obrigatório quando o projeto for FLEX

[5] Obrigatório quando o projeto for FLEX