O módulo de processos controla as máquinas de status do sistema.

Histórico

Originalmente o sistema não possuía o conceito de máquinas de status. Os campos de status das diversas tabelas do sistema são simples campos do tipo DN_STATUS (smallint) que permitem a utilização de qualquer valor.

Por convenção, na tabela CFG_STATUS armazenamos os valores possíveis para cada campo de status de cada tabela. E não existe nenhum controle automático ou genérico para a troca de status. Nem mesmo uma verificação se o valor preenchido na tabela existe na lista de valores da CFG_STATUS. Em suma, não tem FK.

O fato de não ter FK implica que os valores listados na CFG_STATUS dependem totalmente que o programador de uma determinada tela, campo ou filtro siga a convenção. Ao criar um lkp ele tem que configurar a CFG_STATUS correta para aquela situação manualmente.

Contudo, alguns campos de status do sistema acabaram por ser utilizados como máquinas de status. Isso foi implementado de diversas formas. Com triggers implementando travas, verificações manuais e atualizações ou ações automáticas em outras tabelas. Ou ainda com procedures que implementam ações que representam alguns status chave no sistema como aprovar, cancelar, reabrir etc.

Esta implementação funciona e em muitos casos é bem simples. Mas o acúmulo de travas, comportamentos, verificações, diferentes configurações entre clientes/usuários acaba por deixar o código dos triggers e procedures difícil de ler, dar manutenção e de acompanhar o fluxo de ações automáticas ou verificações encadeados entre estes status que se tornaram complexos.

O módulo de processos é uma tentativa de organizar os status complexos em máquinas de status configuráveis por um usuário avançado. Foi baseado na modelagem do redmine onde o workflow (lista das próximas etapas permitidas) é armazenado numa tabela com origem e destino.

Descrição

O primeiro objetivo do módulo de processos é listar as etapas de um processo e manter uma lista da próxima etapa permitida. As etapas de processo serão análogas aos valores de cada campo de status da CFG_STATUS.

Nos status do sistema que se tornaram complexos houveram diversas alterações na lista de status possíveis dentro de um mesmo processo. Isso cria uma dificuldade de manter os objetos que utilizam este status coerentes em relação as regras de negócio vinculadas a cada valor de status. Para resolver esta situação decidimos agrupar as etapas de processo dentro de versões de processos. Assim, cada objeto que utilizar uma máquina de status pode seguir uma versão diferente do processo, de acordo com a versão que está utilizando.

Mas atenção. As etapas pertencem ao processo e não a versão. A versão apenas indica o conjunto de etapas válidas naquela versão, bem como o workflow. Isso foi feito assim para que um filtro de objeto numa determinada etapa englobe todas as versões que usam aquela etapa.

Modelo de Dados

  • Tabela PROCESSO_MODELO - Representa o próprio cadastro de processo;
  • Tabela PROCESSO_ETAPA - Lista as etapas do processo;
  • Tabela PROCESSO_VERSAO - Lista as versões do processo;
  • O TIPO determina se o comportamento do processo, se livre para trocar de qualquer status para qualquer status ou se configurado como workflow;
  • Tabela PROCESSO_ETAPA_VERSAO - Lista as etapas de cada versão de processo;
  • Tabela PROCESSO_ETAPA_NEXT - Lista as próximas etapas permitidas a partir de uma etapa, dentro daquela versão;

Regras de Negócio

  • Não é permitido desativar uma etapa que está numa versão ativa;
  • Ao ativar uma versão, todas as outras do mesmo processo são desativadas automaticamente;

Ideias para o Futuro

  • Cadastro de checklist de etapas com a tabela PROCESSO_ETAPA_CHECKLIST
  • Cadastro de tipo de processo com a tabela PROCESSO_MODELO_TIPO
  • Será necessário definir tipos de processos conhecidos pelo sistema para se codificar pontos de processo chave para as ações do sistema (pedidos, cobranças etc.);
  • Gerar um diagrama das versões do processo usando o mermaid;