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

A partir do momento que o Workflow da aprovação de um documento é inicializado no Fluig, todo o processo de análise, aprovação e reprovação de pendências poderá ser executado pelo Fluig.

Sobre o fluxo e suas interações com o ERP:

• A movimentação (Criação ou alteração Solicitação de compra, pedido de compra, etc.) será realizada no ERP, como é feito atualmente (somente a pendência de aprovação que irá para o Fluig);
• Caso o documento deva passar pelo processo de aprovações do MLA no Fluig, ao iniciar o Workflow o ERP vai enviar as informações para geração da pendência de aprovação. 
• Deverão ser enviadas juntamente com as informações da atividade a ser gerada, o número da transação e a chave o documento que está sofrendo aprovação, para que sejam carregadas as informações do documento no formulário vinculado ao workflow.
• Caso ocorram erros na integração com o Fluig, deverá ser gerado um registro na tabela de pendências de integração com o Fluig, nesta tabela ficará armazenada as informações da pendência que não foi enviada, os erros que ocorreram e o processo que estava sendo realizado (envio, aprovação/reprovação, cancelamento). Através do monitor de pendências, detalhado posteriormente, será possível reenviar essas pendências.
• Ao realizar a ação de aprovar ou reprovar um documento, deverão ser feitas todas as validações do ERP referente a permissões de aprovação do usuário em questão, se estiver tudo OK, o ERP é atualizado, e o workflow é finalizado. Para essa rotina, será utilizada a mesma API de aprovação que é utilizada para o Portal do MLA.
• Quando for uma reprovação, o usuário terá que informar o código de rejeição conforme as regras do ERP;
• Toda vez que ocorrer uma aprovação ou reprovação, o status do documento deverá ser atualizado no ERP, e o workflow será encerrado. Obs.: Se houver mais aprovações a serem realizadas serão gerados novos Workflows.

• Para realizar a aprovação de aprovação ou rejeição pelo Portal, utilizar a mesma API já utilizada para o Portal do MLA a lap/mla0007.p (procedure aprovaPendPortal);

• Para a busca dos códigos de rejeição utilizar a lap/mla0007.p (procedute getCodRejeita).

   

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

Cada vez que ocorrer uma alteração de documento no ERP, todas as pendências de aprovação são eliminadas no ERP e re-geradas. Dessa forma, será necessário cancelar a solicitação no Fluig, e iniciar um novo processo. Ao cancelar o Workflow, deverá ser enviado o seguinte conteúdo: “Workflow cancelado devido a eliminação ou alterações no documento que originou a pendência”. O Fluxo desse processo é apresentado na sequência.

Se um documento for eliminado no ERP, e estiver integrado com o Fluig, será necessário cancelar a solicitação de aprovação no Fluig também. Fluxo é apresentado na sequência.

No caso de cancelamento através do ERP, pode ocorrer a situação de que a pendência não foi integrada inicialmente com o Fluig. Se identificada essa situação, o sistema deverá:

• Eliminar a pendência de erro de "envio", pois neste caso que a pendência já foi cancelada, não faz sentido mais integrá-la com o Fluig.

Se um documento for aprovado ou reprovado pelo ERP, o Fluig deverá ser atualizado também, conforme fluxo apresentado na sequência.

No caso de aprovação/rejeição através do ERP, pode ocorrer a situação de que a pendência não foi integrada inicialmente com o Fluig. Se identificada essa situação, o sistema deverá:

• Tentar enviar primeiramente a pendência com "erro de envio":
  • Se for integrada com sucesso --> Integrar a aprovação/rejeição;
  • Se não for integrada com sucesso --> Apenas criar um registro de erro, com o erro "Pendência não está integrada com o Fluig".

Ao executar o programa MLA0170 (Substituir aprovador/Copiar permissões) no ERP, se a pendência a ser alterada está integrada com o Fluig, deve-se enviar uma integração para troca de usuário responsável no Fluig. Se ocorrer erro neste processo, no monitor de pendências esse tipo de integração, aparecerá também como “movimentação”.

Informações técnicas sobre Sincronização de atualização de pendências (alteração/elimininação/aprovação) entre MLA e Fluig:

• Para realizar os cancelamentos de workflow no Fluig, será necessário criar uma procedure (cancelProcessFluig) na API lap/mlaapi014.p criada anteriormente;
• Ela deverá ser chamada de dentro da mlaapi001.p (na procedure pi-elimina-documentos-pendentes);
• A procedure deverá ter os seguintes parâmetros: Número da transação (INPUT) e RowErrors (OUTPUT);
• Ela 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;
• A API para integração com o Fluig a ser utilizada neste caso será a utp/ut-integra-ecm.p (chamar a procedure cancelInstance)
• Caso ocorra algum erro, deve-se gerar um registro de erro de cancelamento na tabela xxxxxxxxxxxx. Mais detalhes nos tópicos a seguir.
• Com relação aos erros retornados da procedure nova, a mlaapi001.p após essa chamada, deve verificar se há algum erro na RowErrors, se houver, criar apenas um registro (de warning) na tt-erro, que será retornada pela API com o seguinte conteúdo: "Não foi possível integrar o cancelamento da pendência de aprovação com o Fluig", help: "Para mais informações sobre os erros ocorridos e re-processamento, consulte o programa xxxxxxxxxxxxxxxx";
  
• Para a sincronização das aprovações/rejeições, será necessário criar uma procedure (changeStateFluig) na API lap/mlaapi014.p criada anteriormente;
• Ela deverá ser chamada de dentro da inbo/boin767c.p (na procedure setAnalysPend);
• A procedure deverá ter os seguintes parâmetros: Número da transação (INPUT) e RowErrors (OUTPUT);
• Ela 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;
• A API para integração com o Fluig a ser utilizada neste caso será a utp/ut-integra-ecm.p (chamar a procedure saveAndSendTaskECM);
• O aprovador para quem será "enviado" o workflow, será o mla-doc-pend-aprov.cod-usuar (neste caso, verificar se para a API do fluig deve ser enviado o código ou e-mail - no caso do Identity);
• Para movimentar o Workflow para a atividade correta se basear na ação realizada. Aprovação: mla-doc-pend-aprov.ind-situacao = 2 / Rejeição: mla-doc-pend-aprov.ind-situacao = 3;
• Para o comentário de aprovação/rejeição, enviar o campo mla-doc-pend-aprov.narrativa-apr ou mla-doc-pend-aprov.narrativa-rej conforme o que ocorreu;
• Caso ocorra algum erro, deve-se gerar um registro de erro de movimentação na tabela xxxxxxxxxxxx. Mais detalhes nos tópicos a seguir.
  
• Com relação aos erros que puderem ser retornados para a boin767c.p, se houver algum registro na RowErrors, criar um registro (de warning) na RowErrors com o seguinte conteúdo: "Não foi possível integrar a aprovação/rejeição da pendência com o Fluig", help: "Para mais informações sobre os erros ocorridos e re-processamento, consulte o programa xxxxxxxxxxxxxxxx" (Como a mensagem é basicamente a mesma de cancelamento, criar uma única, com parâmetros).
• Ainda será necessário, no caso de aprovações/rejeições, gerar pendências para os próximos aprovadores (se houver). Neste caso, deverá ser criado um novo workflow no Fluig, nos mesmos pontos onde hoje há os pontos de epc (são dois locais), com o nome de "aprovacao-pendente".
• Sobre a alteração a ser realizada referente a troca de aprovador:
   
  • Deve ser na boin767.p (procedure piSubstituiAprovador). A integração com o Fluig, deve ser a última coisa a ser realizada dentro do FOR EACH tt-mla-doc-pend-aprov.
  • Para integração com o Fluig, deve-se utilizar o método saveAndSendTaskECM da ut-integra-ecm.p, para isso criar uma nova procedure na API de integração com o Fluig que foi criada.
  • Para saber se deve enviar o troca para o Fluig, verificar se a integração está ativa e se a pendência possui número de processo.
  • Se ocorrerem erros na mudança do aprovador, deve-se gravar na tabela de erro de integração com a situação 4 (que será apresentada juntamente com os erros de movimentação.

6) Re-análise de documentos 

No MLA é possível que os aprovadores realizem a re-análise de documentos “Rejeitados”, fazendo uma "re-aprovação". No Fluig não é possível que o usuário faça uma análise de documentos “Rejeitados”, pois o Workflow já estará finalizado. Por isso, quando a pendência de aprovação estiver integrada com o Fluig, no ERP serão bloqueadas as ações de “Reaprovação”, ou seja, deverá ser apresentada a mensagem "Reaprovação não permitida para pendências integradas com o Fluig".

Informações técnicas sobre Re-análise de documentos:

• A validação citada deverá ser inserida na inbo/boin767c.p (procedure setAssignPend, na parte de re-aprovação - neste caso criar um erro na RowErrors e retorno "NOK");
  
  

7) Usuário mestre

 No Fluig os usuários mestres serão considerados os gestores do processo. Eles deverão ser definidos através de um mecanismo de atribuição customizado, que irá buscar do ERP quais são esses usuários para que possam ser atribuídos como gestores de processo no Fluig. 

Obs.: lembrando que eles serão buscados no momento que o Workflow é criado, se o usuário for tornado mestre e já existirem Workflows em andamento, ele somente será mestre/gestor, dos próximos workflows criados.

Informações técnicas sobre Usuário mestre:

• Criar uma procedure (getGestoresProcesso) na lap/mlaapi014.p para retornar os usuários mestres.
• A tabela é a mla-usuar-aprov, e os usuários mestre são representados pelo campo: mla-usuar-aprov.usuar-mestre.

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

 Será 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

Para que não haja a necessidade de bloquear a inclusão de documentos no ERP, caso ocorra algum erro de integração com o Fluig, ou perda de conexão, a ideia é que o processo não seja interrompido, para não causar transtornos nas atividades do cliente. Dessa forma, o documento será incluso normalmente no ERP, apenas alertando que não houve a integração com o Fluig. Será mantido um registro desses erros de integração para que possam ser re-enviados ao Fluig posteriormente.

Os registros de problemas de integração, poderão ser de tipos diferentes:

• Erro de envio (integração inicial);
• Erro de movimentação (aprovações/reprovações e troca de aprovador);
• Erro de cancelamento (eliminações de pendência).

O monitor deverá ser desenvolvido conforme protótipo apresentado na sequência:

Ele apresentará além dos três tipos de erros citados acima, mais uma situação, que serão pendências não integradas, ou seja, por exemplo, ao implantar os workflows do MLA, se já haviam pendências geradas no módulo, elas poderão ser integradas através dessa opção. Por padrão o programa virá somente as três opções de "erro" marcadas, a opção de "Não integrada" deve vir desmarcada.

As informações que serão apresentadas por esse programa serão as seguintes:

• Tipo de documento e descrição (Será o "título" do registro - Ao clicar nele deverá abrir a tela de aprovação de pendência - Abrirá com as opções de aprovação, porém, se não for o aprovador do documento, o sistema valida);
• Tipo de pendência: é apresentado com as cores na lateral;
• Transação;
• Chave do documento (deverá aparecer formatada para cada tipo de documento;
• Workflow: número do workflow gerado no Fluig. Obs.: Esse campo não deverá aparecer para pendências "Não integradas" e com "Erro de envio";
• Data de Geração;
• Data de Aprovação: Somente apresentar para pendências com "Erro de movimentação";
• Data de Rejeição: Somente apresentar para pendências com "Erro de movimentação";
• Aprovador;
• Data de Cancelamento: Somente apresentar para pendências com "Erro de cancelamento";
• Erro: Situação ocorrido que impossibilitou a integração com o Fluig.
  
  

Quando o usuário usar a opção "Exibir detalhes..." terá acesso as seguintes informações:

• Re-processado por: Se a pendência já sofreu re-processamento, pelo monitor, esse campo conterá o usuário que fez esse re-processamento;
• Data/hora re-processamento: Data e hora de re-processamento, cada o documento já tenha sido re-processado;

Importante: Quando é feita a leitura das pendências, caso o monitor identifique que não faz mais sentido integrar determinadas pendências com o Fluig, neste caso, ele mesmo faz a eliminação desses registros de erros de integração.

Essa situação irá ocorrer quando: 

• Houve a tentativa de integrar com o Fluig a pendência na criação de um documento e gerou um "erro de envio";
• Antes que essa pendência de "erro de envio"  pudesse ser reprocessada no monitor, houve o cancelamento da pendência, ou seja, há também um "erro de cancelamento" no monitor;
• Neste caso, a pendência não existe mais no ERP, e por isso não faz sentido enviá-las ao Fluig.
  
  
  

Existirá uma busca avançada que deverá permitir ao usuário informar:

• Situação das pendências: Com erro de envio, Com erro de movimentação, Com erro de cancelamento e Não integrada. Obs.: Deverá permitir a seleção de todas as situações simultaneamente, por padrão só não deve vir selecionada a opção de "Não integrada";
• Transação: Deverá permitir informar uma faixa de número de transação para visualização das pendências. Obs.: Por padrão a faixa deve vir aberta.
• Código documento: Deverá permitir informar uma faixa de códigos de tipo de documento para visualização das pendências. Obs.: Por padrão a faixa deve vir aberta.
• Geração: Deverá permitir informar uma faixa de datas de geração das pendências para visualização das mesmas. Obs.: Por padrão a faixa deve vir aberta.
• Aprovação: Deverá permitir informar uma faixa de datas de aprovação das pendências para visualização das mesmas. Obs.: Por padrão a faixa deve vir aberta.
• Rejeição: Deverá permitir informar uma faixa de datas de rejeição das pendências para visualização das mesmas. Obs.: Por padrão a faixa deve vir aberta.
• Aprovador: Deverá permitir informar uma faixa de código de usuários aprovadores das pendências para visualização das mesmas. Obs.: Por padrão a faixa deve vir aberta. 
• Chave do documento: Caso o usuário tenha informado na faixa de seleção, somente um documento (ou seja, inicial e final iguais), deverá ser possível que ele informe uma chave para esse documento. Neste caso o sistema deverá disponibilizar em tela os campos da chave para que sejam informados (semelhante ao "vá para" do programa MLA0201 - Consulta de Pendências). Com essa informação será possível que o usuário consulte especificamente as pendências de um integração para um determinado documento.
• Parâmetro "Processa pendências relacionadas": Indica que deve processar pendências relacionadas, mesmo que elas não estejam selecionadas em tela. Ex.: Se o usuário tentar processar uma pendência de "erro de movimentação", e existir uma pendência de "erro de envio", a pendência de "erro de envio" será processada antes. Caso contrário, ocorrerá apresentará uma validação indicando que existem pendências relacionadas não integradas. Obs.: Por padrão o parâmetro deve vir marcado.
  
  

A pesquisa simples deverá permitir a busca por:

• Transação (busca por igualdade);
• Chave do documento (busca por "contém");

O usuário terá a opção de ordenar por:

• Data Geração;
• Documento;
• Tipo de pendência;
• Chave;
  
  

Para integrar as pendências, o usuário terá a opção de realizar a ação individualmente ou em lote, neste caso o comportamento deverá ser o seguinte:

• O processamento sempre irá ocorrer das pendências mais antigas para as mais recentes, neste caso se houverem duas pendências (uma de envio e outra de aprovação), garantimos que a de "envio" será re-processada antes;
• Ao processar cada pendência deverá ser feita a seguinte verificação:
  • Quando se trata de uma pendência de movimentação ou cancelamento que está sendo processada:
    • Se o parâmetro "Processa pendências relacionadas" estiver marcado, e houver uma pendência de "erro de envio" referente a mesma pendência do MLA, a pendência de erro de envio deve ser re-processada antes da pendência selecionada;
    • Se o parâmetro "Processa pendências relacionadas" não estiver marcado, e houver uma pendência de "erro de envio" referente a mesma pendência do MLA, deverá ser apresentada uma mensagem e a pendência não deve ser re-processada: Existem pendências relacionadas (de envio) ainda não integradas. Help: Realize a integração da pendência de envio ou marque o parâmetro "Processa pendências relacionadas".

• • Caso a pendência seja processada com sucesso, ela deve ser eliminada (e não aparece mais no monitor), e o número do workflow é armazenado, caso ainda não exista.
  • Se houver algum erro de re-processamento, deve-se atualizar o registro de pendência de erro com o erro ocorrido, usuário que fez o re-processamento e data/hora de re-processamento.
  • No final do processamento, apresentar a mensagem: "Re-processamento finalizado, pendências não integradas permanecem no monitor".

Informações técnicas sobre monitor de pendências de integração com o Fluig

• • Criar uma BO para a nova tabela criada, com os métodos padrões;
  • Para criação dos erros de envio, movimentação ou cancelamento, deverá ser feito através da BO;
    • Criar uma procedure na BO (pi-cria-erro-processamento), que deverá criar um erro baseado na mla-doc-pend-aprov:
      • Parâmetros:
        • Número da transação;
        • Tipo de erro: 1 – envio, 2 – movimentação, 3 – cancelamento, 4 - Troca de aprovador (Usado apenas internamente, pois em tela é tratado como tipo 2);
        • Erro: erro ocorrido no processamento
        • Reprocessamento: (indica se trata-se de um reprocessamento);
      • Para gravação na tabela xxxxxxxxx:
        • Localizar a mla-doc-pend-aprov pelo número da transação e gravar as informações conforme abaixo;
        • Número da transação: mla-doc-pend-aprov.nr-trans
        • Chave: mla-doc-pend-aprov.chave-doc
        • Workflow: mla-doc-pend-aprov.xxxxxxxxxxx
        • Geração: mla-doc-pend-aprov.dt-geracao
        • Aprovação: mla-doc-pend-aprov.dt-aprova (Somente gravar se for uma movimentação)
        • Rejeição: mla-doc-pend-aprov.dt-rejeita (Somente gravar se for uma movimentação)
        • Cancelamento: data atual (Somente gravar se for um cancelamento)
        • Aprovador: mla-doc-pend-aprov.cod-usuar
        • Erro: erro ocorrido no processo
        • Reprocessado por: usuário logado (Somente passar se for re-processamento)
        • Data/hora re-processamento: data e hora atual (Somente passar se for re-processamento)
  • Criar uma API (ccapi360.p) para busca de dados semelhante a ccapi354.p (procedure REST_POST_getListRequests), que deverá:
    • Ler os registros da tabela xxxxxxxxxxx, conforme os parâmetros selecionados/informados em tela;
    • Se o parâmetro “Não integrada” estiver marcado, será necessário, ler os registros da mla-doc-pend-aprov, que estão pendentes (ind-situacao = 1) e que não possuem código de workflow do Fluig (xxxxxxx = “”). Considerar também os parâmetros de tela para essa leitura. Neste caso as informações virão da mla-doc-pend-aprov. Como as informações a serem apresentadas no monitor podem vir de duas tabelas diferentes, deverá ser retornada uma temp-table com essas informações;
  • Para o re-processamento, criar uma API bem isolada (ccapi361.p) que possa ser utilizada, por exemplo por um programa para re-processamento em batch;
  • Os processamentos de criação, envio de aprovação/rejeição e cancelamento devem ser feitos conforme já citado nos tópicos acima, só será necessário criar o tratamento para a questão de re-processamentos (gravando os campos de usuário e data de reprocessamento).

11) Formulários mobile

xxxxxxxxxxxxxxxxx

12) Réplica de parametrizações entre empresas e estabelecimentos

Como foram inseridos campos novos no cadastro de parâmetros MLA0000 – Parâmetros da Aprovação e MLA0101 – Tipos de Documentos será necessário que esses campos sejam previstos no programa de réplica de parametrizações entre empresas e estabelecimentos (MLA0171).

Para o parâmetro “Parâmetros da aprovação”, deverá ser previsto:

• A exportação/importação e réplica dos campos: Integração Fluig (Label: Integ. Fluig), Prazo Conclusão (Label: Prazo Conc.), Horas de Conclusão (Label: Horas Conc.), Código de rejeição padrão (Label: Cod. Rej. Padrão). Obs.: No arquivos, inserir os novos campos como as últimas colunas.

Para o parâmetro de “Tipos de documentos”, deverá ser previsto:

• A exportação/importação e réplica dos campos: Integração Fluig (Label: Integ. Fluig), Processo, Prazo Conclusão (Label: Prazo Conc.), Horas de Conclusão (Label: Horas Conc.), Prazo da prioridade Baixa (Label: Prazo prior. Baixa), Prazo da prioridade Média (Label: Prazo prior. Média), Prazo da prioridade Alta (Label: Prazo prior. Alta), Prazo da prioridade Muito Alta (Label: Prazo prior. Muito Alta). Obs.: No arquivos, inserir os novos campos como as últimas colunas.
  
  

Informações técnicas sobre Réplica de parametrizações entre empresas e estabelecimentos:

• Parâmetros da aprovação, campos: mla-param-aprov.xxxxxxxxxxxx, mla-param-aprov.xxxxxxxxxxxx, mla-param-aprov.xxxxxxxxxxxx, mla-param-aprov.xxxxxxxxxxxx.
• Tipos de documentos, campos: mla-tipo-doc-aprov.xxxxxxxxxxx, mla-tipo-doc-aprov.xxxxxxxxxxx, mla-tipo-doc-aprov.xxxxxxxxxxx, mla-tipo-doc-aprov.xxxxxxxxxxx, mla-tipo-doc-aprov.xxxxxxxxxxx, mla-tipo-doc-aprov.xxxxxxxxxxx, mla-tipo-doc-aprov.xxxxxxxxxxx, mla-tipo-doc-aprov.xxxxxxxxxxx.
• Lembrar de tratar os log’s de alteração dos registros (inclusão, alteração e eliminação).

13) Programa para limpeza de histórico de pendências de aprovação (mla0173)

Como serão gerados os históricos dos documentos que geraram pendências no MLA para toda pendência integrada com o Fluig, esse programa deve permitir a eliminação desses registros para que não haja um volume muito grande de informações na base de dados.

O programa deverá ser no estilo relatório/execução, com as seguintes características:

Seleção (faixas de):

• Transação;
• Geração;
• Processo Fluig;
• Documento; (código)

Parâmetro:

• Deverá possui um parâmetro para que o usuário informe a partir de um período de existência das pendências na base que devem ser eliminadas.
  Exemplo: Eliminar histórico com mais de XXXXX dias

• Quando esse parâmetro for marcado, deve-se desabilitar a faixa de seleção de “Geração”, pois ele estará sobrepondo essa informação.
• O objetivo desse parâmetro é facilitar a inclusão do programa em rotinas RPW, onde o usuário não precisa de preocupar com a data informada, o programa considerará o período com base na data de execução.

Execução:

• Somente serão considerados os registros de pendência de aprovação já aprovados/rejeitados, ou seja, não será possível eliminar o histórico de um registro ainda pendente de aprovação;
• O relatório deverá apenas apresentar a lista de histórico eliminado com as seguintes informações: Transação, chave documento, data geração e o número do processo no Fluig.
• Se o usuário eliminar o histórico de um documento que ainda possui WF no Fluig, o que vai ocorrer, é que ao consultá-lo não será possível visualizar as informações.
  
  

Informações técnicas sobre programa para limpeza de histórico de pendências de aprovação:

• Para cada registro da tabela de histórico, deve-se verificar se a pendência já  está aprovada/rejeitada: mla-doc-pend-aprov.ind-situacao <> 1;

[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

[6] Obrigatório quando o projeto for FLEX