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:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

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.

Image Added

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:

Image Added

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>.