Histórico da Página

(Obrigatório)

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

(Obrigatório)

Objetivo

Desenvolver os workflows de aprovação de documentos do MLA no Fluig, para que com isso seja possível realizar toda a parte de acompanhamento e aprovação/rejeição de documentos através do Fluig.

(Obrigatório)

Definição da Regra de Negócio

Requisitos que SERÃO contemplados nesta especificação:

Neste primeiro momento serão tratados os seguintes documentos do MLA (os demais serão tratados em requisitos separadamente):

• Solicitação de compra (Item e Total) – Doc 1 e Doc 2;
• Requisição de estoque (Item e Total) – Doc 3 e Doc 4;
• Pedido de compra (Item e Total) – Doc 6 e Doc 7;
• Pedido de compra Emergencial (Item e Total) – Doc 8 e Doc 19.
• Sincronização da geração de pendências entre Fluig e MLA;
• Implementação do processo de análise, aprovação e reprovação de pendências, diretamente no Fluig;
• Aprovação em dispositivos móveis (formulários mobile para os documentos citados acima);
• Possibilitar a utilização do recurso de prazo de execução de atividades para as aprovações do MLA;
• Sincronização de atualização de pendências (alteração/eliminação) entre Fluig e MLA;
• Sincronização de status de aprovação/reprovação de documentos entre Fluig e MLA.
  
  

Requisitos que NÃO SERÃO contemplados nesta especificação:

• Customização da central de tarefas para contemplar filtros e colunas para facilitar a busca por documentos específicos;
• Sincronização de usuários alternativos (substitutos) com o Fluig - O cadastro deverá ser feito de forma manual no Fluig;
• Não serão desenhados e/ou tratados os fluxos de aprovação de cada documento/tipo de aprovação dentro do Fluig. Cada pendência de aprovação, gerará um Workflow diferente dentro do Fluig;
• Tratamento dos documentos: 
  • Cotação de compra - Doc 5;
  • Processo de compra (Total e Item) - Doc 9 e 10;
  • Contrato de compra - Doc 13;
  • Medição de contrato - Doc 14;
  • Evento de contrato - Doc 16;
  • Solicitação de cotação - Doc 18;
  • Solicitação de Serviço - Doc 20, 
  • Aprovação de crédito – Pedido de venda - Doc 21; 
  • Documento do contas a pagar - Doc 24;
  • Antecipação - Doc 25;
  • Pagamento extra-fornecedores - Doc 26;
  • Título normal - Doc 28.
• Este escopo contempla apenas a parte de aprovação de documentos no Fluig, considerando que a criação dos documentos será realizada pelo próprio ERP e não através do Fluig;
• Re-análise de pendências.

Exemplo de Aplicação:

Os usuários do Datasul não têm a possibilidade de utilizar o Fluig para visualizar e aprovar pendências geradas através do módulo do MLA. Somente com a utilização do módulo do MLA, sem integração com o Fluig, também não é possível estabelecer prazos para a execução das aprovações.

Detalhamento das regras de negócio

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

Como o Fluig é um produto vendido separadamente, deverá haver um local no ERP para dizer que o MLA deverá ser tratado também pelo Fluig (para indicar que existe esta integração). Este ponto será no programa de parâmetros da aprovação (MLA0000 - Aba "Parâmetros II"). Para isso deverá ser inserido o parâmetro “Integração Fluig”, conforme apresentado no protótipo. Como os parâmetros do MLA são por empresa/estabelecimento, significa que o cliente poderá optar por enviar para o Fluig as pendências de apenas alguns estabelecimentos. Por padrão o parâmetro deve vir desmarcado.

Se o parâmetro “Integração Fluig” for marcado, os demais parâmetros contidos neste agrupador deverão ser habilitados em tela, caso contrário permanecerão desabilitados. Sobre os demais parâmetros:

• Prazo de conclusão: Se marcado, indica que as pendências desse estabelecimento utilizarão o controle de prazo de conclusão, que indica o tempo em que cada pendência deve ser aprovada (informada em horas);
• Código rejeição padrão: Esse campo somente será utilizado para o caso de reprovações em lote pelo Fluig, onde não será possível informar um código de rejeição manualmente. Neste caso o sistema utilizará o código informado neste programa;

Ao efetivar os dados dessa tela, deverá ser questionado ao usuário se deseja replicar as informações de integração com o Fluig para os documentos do estabelecimento (MLA0101). Se o usuário confirmar, as informações de “Integração Fluig”, “Prazo de conclusão” e “Horas” deverão ser replicados para os documentos do estabelecimento em questão. Somente não deve ser replicada a informação de “Integração Fluig” para os documentos que não serão liberados neste primeiro momento (mais informações abaixo). 

Como os workflows serão diferentes para cada tipo de documento no Fluig, o cliente poderá optar, por integrar com o Fluig somente os documentos que desejar, neste caso poderá informar no programa Tipos de documentos (MLA0101) quais deverão ou não ser integrados e o nome do workflow no Fluig. Esses parâmetros só poderão ser habilitados se o estabelecimento estiver parametrizado para integrar com o Fluig (MLA0000 – Parâmetro “Integração Fluig”).

Para isso será inserido um parâmetro “Integração Fluig” para indicar que o documento deve ser integrado com o Fluig (por padrão, na inclusão de documentos deve vir marcado conforme o parâmetro do MLA0000 – com exceção dos documentos não liberados agora. Para esses sempre deve vir desmarcado). O nome do workflow será sugerido conforme o número do documento informado, no seguinte padrão:

WFMLA + código do documento com 3 dígitos. Exemplo: WFMLA001 - Para o documento de Solicitação de compra (Doc 1).

O campo ficará disponível para alteração. Isso é necessário para o caso de que o cliente tenha, por exemplo, criado um Workflow novo para o documento com um nome diferenciado.

Os parâmetros do MLA0101B, ficarão dispostos conforme protótipo abaixo:

Para que seja possível utilizar o recurso de prazo na execução das tarefas, será possível definir por tipo de documento qual será o prazo de aprovação para cada pendência gerada.

• No caso dos documentos que possuem prioridade de aprovação (1, 3, 5, 6, 14, 16, 18, 19), o prazo de aprovação poderá ser definido conforme a prioridade, se estiver parametrizado para sua utilização (MLA0000, parâmetro “Prioridade Aprovação Docto”). Neste caso, se tiver valor informado por prioridade ele deverá ser utilizado, ao invés do prazo “genérico”;
• Para os documentos que possuem prazo de conclusão, mas o mesmo está desabilitado no MLA0000, os campos de prioridade devem permanecer desabilitados em tela;
• Para os documentos que não possuem prioridade de aprovação, estes campos de prioridade de aprovação não devem ser apresentados em tela;
  
  

Obs.: Todos esses campos novos deverão ser desabilitados para os seguintes documentos: 5, 9, 10, 13, 14, 16, 18, 20, 21, 24, 25, 26, 28. Na medida que esses documentos forem sendo liberados para integração, os parâmetros serão habilitados.

Informações técnicas sobre habilitar e configurar a integração:

• No MLA0000: 
  • O novo parâmetro “Integração Fluig” deverá referenciar o campo mla-param-aprov.xxxxxxxxxxxx;
  • O novo parâmetro "Prazo de conclusão" deverá referenciar o campo mla-param-aprov.xxxxxxxxx;
  • O novo campo de "Horas de conclusão" deverá referenciar o campo mla-param-aprov.xxxxxxxxx;
    
  • O novo campo "Código de rejeição padrão" deverá referenciar o campo mla-param-aprov.xxxxxxxxx;
  • Para a réplica de dados, criar uma procedure na boin784.p (pi-replica-integracao-fuig), recebendo os seguintes parâmetros: empresa, estabelecimento, se integra com fluig, se utiliza prazo de conclusão, horas de conclusão. A procedure deverá ler todos os documentos (mla-tipo-doc-aprov) da empresa e estabelecimento em questão, e atualizar os dados conforme os parâmetros recebimentos.
    
    
• No MLA0101B:
  • Ajustar os parâmetros existentes em tela para que seja possível inserir os novos;
  • O novo parâmetro "Integração Fluig" deverá referenciar o campo mla-tipo-doc-aprov.xxxxxxx;
  • O novo campo "Processo" deverá referenciar o campo mla-tipo-doc-aprov.xxxxxxxxxx;
  • O novo parâmetro "Prazo de conclusão" deverá referenciar o campo mla-tipo-doc-aprov.xxxxxxxxxx;
  • O novo campo de "Horas de conclusão" deverá referenciar o campo mla-tipo-doc-aprov.xxxxxxxxxx;
  • Os novos campos de horas por prioridade deverão referenciar: Baixa: mla-tipo-doc-aprov.xxxxxxxxxx, Média: mla-tipo-doc-aprov.xxxxxxxxxx, Alta: mla-tipo-doc-aprov.xxxxxxxxxx e Muito Alta: mla-tipo-doc-aprov.xxxxxxxxxx; 
  • Para saber se os campos poderão ser habilitados, lembrar de localizar os parâmetros do MLA pelo estabelecimento e empresa (mla-param-aprov.cod-estabel = mla-tipo-doc-aprov.cod-estabel AND mla-param-aprov.ep-codigo = mla-tipo-doc-aprov.ep-codigo). 
  • O código do documento, que é utilizado em muitas regras de negócio é representado pelo campo mla-tipo-doc-aprov.cod-tip-doc;
  • Para saber se o estabelecimento está configurado para utilizar a prioridade de aprovação: mla-param-aprov.log-priorid-aprova-docto;

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

Nos pontos onde são geradas as pendências de aprovação, na primeira geração de pendência para o documento, caso esteja configurado a empresa/estabelecimento/documento para integrar com o Fluig, será necessário iniciar o workflow do respectivo documento no Fluig (Obs.: Essa inicialização será de forma automática pelo ERP).

Caso haja algum erro de integração, ou problema na comunicação entre ERP e Fluig, o documento e pendências deverão ser criados normalmente no ERP, somente alertando que não houve a integração com o Fluig. Para verificação dos erros ocorridos, e possibilitar o re-envio de documentos para o Fluig, será criado um programa que servirá como um “monitor” desta integração. O objetivo deste monitor será controlar os documentos pendentes de integração (que houve algum problema ao integrar com o Fluig). O monitor será detalhado posteriormente.

Assim que a solicitação for iniciada no Fluig será necessário armazenar o número dela no ERP para sincronização de alterações, cancelamentos e aprovações. O número da solicitação ficará armazenado na tabela de pendências de aprovação do MLA, e poderá ser visualizado através das telas de detalhe de pendência, tanto no progress, quanto no HTML.

Protótipo da MLA0201B com o campo novo “WF Fluig”:

Protótipo da tela HTML com o novo campo “Workflow Fluig”:

Alguns pontos de atenção neste processo:

• Para o caso dos documentos por item (que possuem a geração de uma nova pendência a cada "item"), para a integração com o Fluig, deve-se considerar somente a última geração. Como é feito para o envio de e-mail de notificação. Ou seja, não deve ser gerada uma pendência a cada item incluso;
• Quando houver aprovação automática da pendência, o workflow NÃO será gerado no Fluig, somente se houver a geração uma pendência o próximo aprovador (da hierarquia, por exemplo), neste caso será gerado um novo workflow de aprovação.

Informações técnicas sobre habilitar e configurar a integraçãosincronização da geração de pendências entre Fluig e MLA:

• O campo para armazenar o número do processo no Fluig será o mla-doc-pend-aprov.xxxxxxxxxxxxxxxx;
• Todos os pontos que criam pendências no MLA, acabam chamando uma única API (mlaapi001.p) que faz a geração de pendência e ela que deverá integrar com o Fluig.
• Neste caso, na mlaapi001.p, os pontos de integração serão nos mesmos pontos que existe a chamada da procedure "pi-chama-epc-geracao-pendencia", pode ser colocado antes dela. No local onde a pi-chama-epc-geracao-pendencia passa o Rowid direto da tabela mla-doc-pend-aprov, somente chamar a integração com o Fluig, se a variável "l-proces-compl" estiver com valor YES (que garante que para os documentos por Item, somente chamará na última vez);
  
• Para a integração, a ser chamada pela mlaapi001.p, deve-se criar uma nova api (lap/mlaapi014.p) para tratar as integrações com o Fluig:
  • Criar a procedure "startProcessFluig" com os parâmetros: Número da transação (INPUT), Aprovador (INPUT), Número do Workflow gerado (OUTPUT) e RowErrors (OUTPUT);
  • A procedure deverá localizar o registro da "mla-doc-pend-aprov" com o número da transação recebido por parâmetro - Validar se existe, caso contrário inserir um erro na RowErrors e retornar;
  • Verificar se o estabelecimento/empresa da pendência está configurado para integrar com o Fluig. Se não estiver, retornar sem executar mais nenhuma ação;
  • Verificar se o documento está configurado para integrar com o Fluig. Se não estiver, retornar sem executar mais nenhuma ação;
  • Ao ler a tabela do documento, identificar o código do Workflow (ele será utilizado para envio para API do Fluig);
  • 
    

2) 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á no mesmo formato (com as mesmas informações) que é utilizado para o Portal do MLA (HTML).

Por padrão, na parte inferior de cada formulário, deverão ser colocados alguns 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.

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.