Informações Gerais

Objetivo

 Possibilitar que no processo de AuditoriaPos seja possível determinar o fluxo das auditorias conforme as regras cadastradas para cada perfil.

Definição da Regra de Negócio

1)

No modelo atual, quando uma conta entra no sistema o mesmo processa a conta contra todas as regras de auditoria cadastradas conforme a ordenação. Caso a conta se enquadre em uma das regras o sistema assume essa regra como principal e realiza a ação determinada pela regra.   

Nesse novo modelo, quando a conta entrar no sistema ocorrerá a execução das regras de auditoria na seguinte ordem:

• Se a conta for de intercambio, o sistema processa primeiramente as regras de Auditoria Administrativa em seguida as regras de Auditoria de Enfermagem e por fim as regras de Auditoria Médica.
• Se a conta for da base o sistema processa primeiramente as regras de Auditoria Medica, em seguida as regras de Auditoria de Enfermagem e por fim as regras de Auditoria Administrativa.

Além disso, durante a auditoria deve ser possível visualizar todas regras de auditoria ao qual a Conta se enquadra.

Para isso, será necessário alterar a api-regras-auditoria-movimentos.p para que a mesma não aborte o processamento quando a conta  encontrar a primeira regra a qual o documento se enquadre.

A api deverá armazenar as regras processadas na seguinte forma: 

• As regras de perfil Auditoria Medica devem ser armazenados nos campos movimen-proced-compl.cod-livre-7 e movimen-insumo-comp.cod-livre-7.
• As regras de perfil Auditoria Enfermagem devem ser armazenados nos campos movimen-proced-compl.cod-livre-5 e movimen-insumo-comp.cod-livre-5.
• As regras de perfil Auditoria Administrativa devem ser armazenados nos campos movimen-proced-compl.cod-livre-6 e movimen-insumo-comp.cod-livre-6.
• O campo cdd-regra-audit deve manter o comportamento o qual continua armazenando o valor da primeira regra ao qual a conta se enquadra.

2)

Alterar o fluxo de atividades do Processo de Auditoria de forma a adicionar as tarefas PROXIMA AUDITORIA e FINALIZAR AUDITORIA

Conforme o papel da regra, que pode ser Medica, Enfermagem ou Administrativa o sistema encaminha a solicitação para a etapa do processo correspondente a regra. O andar do fluxo é determinado pelas regras de auditoria dos próximos papeis, ou seja, quando a Solicitação é enviada para a PROXIMA AUDITORIA o sistema processa as regras de auditoria daquele papel caso existam regras as quais a conta se enquadre o sistema envia para essa atividade do fluxo, caso contrário o sistema processa o próximo papel fazendo a mesma verificação.

Caso o último papel do fluxo possuir uma regra de liberação automática o sistema irá efetuar a liberação automática dos movimentos contas deixando-os aptos para os processos de Pagamento de Prestadores e Faturamento.

Caso a solicitação não atinja o último papel do fluxo, ou seja, a conta não se enquadre em nenhuma regra de auditoria dos papeis seguintes o sistema encerra a solicitação e deixa os movimentos pendentes de liberação manual no revisão de contas.

3)

Como o processamento das regras de auditoria assim como a finalização da solicitação consomem um tempo considerável esse processo possui duas etapas automáticas que ficam responsáveis  por controlar essa execução em segundo plano deixando o usuário livre para atender outra solicitação.

A etapa PROXIMA AUDITORIA é a etapa que verifica se existe regras para o próximo perfil e de acordo com o resultado decide para qual etapa deve transferir automaticamente. Quando a solicitação é encaminhada para essa etapa ela é movida para o grupo ANALISE_REGRA, determinado na tarefa de processo. Esse grupo é responsável por enfileirar as tarefas que precisam executar as regras de auditoria.

A etapa FINALIZAR AUDITORIA é a etapa que envia para o fim a solicitação. Nessa etapa o sistema consolida as ações realizadas pela auditoria na base de dados e libera os movimentos do revisão de contas. Quando a solicitação é encaminhada para essa etapa ela é movida para o grupo ANALISE_FINALIZACAO, determinado na tarefa de processo. Esse grupo é responsável por enfileirar as tarefas que precisam ser executadas.

A ferramenta de Auditoria permite que apenas uma tarefa de cada uma das caixas seja movimentada automaticamente por vez. Devido ao volume de informação isso se torna inviável, de forma que o sistema não conseguirá atender a demanda no tempo necessário. Por essa razão, existe o programa ouvidor ouvidorProcessoECM.w,  esse programa possibilita movimentar múltiplas solicitações simultaneamente. Assim sendo, para que o processo possa ser executado, deve-se ter duas sessões desse programa iniciadas onde uma aponta para etapa ANALISE_REGRA e outra para ANALISE_FINALIZACAO.

Na tela de configuração deverá ser parametrizado quantas sessões múltiplas serão administradas para cada etapa.

4) 

Alterar o formulário de auditoriapos para apresentar as regras gravadas conforme o perfil correspondente.

Se a solicitação estiver na Auditoria Medica apresentar as regras existentes no campo cod-livre-7

Se a solicitação estiver na Auditoria Enfermagem apresentar as regras existentes no campo cod-livre-5

Se a solicitação estiver na Auditoria Administrativa apresentar as regras existentes no campo cod-livre-6

5)

Alterar a tela para possibilitar a inclusão de codigos HTML específicos do cliente. De forma a possibilitar que os clientes adicionem logicas especificas na tela de auditoria.

Será desenvolvido um formulário HTML que possibilitará ao cliente cadastrar os seus programas específicos.

Esse formulário possibilita ativar os pontos específicos que se deseja utilizar.  Os pontos específicos pode ser de dois tipos: VIEW, quando trata-se de alteração na tela necessitando apresentar dados em HTML; e INLINE, quando trata-se de uma alteração numa logica já existente sem a necessidade de apresentar dados em tela.

• • No caso dos pontos de VIEW, deve-se cadastrar o formulário HTML que deverá ser apresentado quando o ponto for executado.
  • No caso dos pontos INLINE, deve-se cadastrar a chamada da função javascript que deverá ser chamada quando o ponto for executado.

Para ambos os casos as funções javascript especificas devem ser incluídas dentro do arquivo config_espec.js existente no formulários auditoriapos. Esse javascript é local determinado para as logicas especificas.

Até o momento teremos 2 pontos de chamada especificas disponíveis no formulário.

Ponto: “Antes da Area de Mensagem", 

Código: "especificPoint1"

Tipo: "VIEW"

Descrição: Esse ponto está localizado sobre a área de mensagens e possibilita a injeção de programas HTML.

Exemplo: <p> Teste </p>

Ponto: “Altera Permissao Para Validacao", 

Código: "especificPoint2"

Tipo: " INLINE"

Descrição: Esse ponto está localizado dentro da função que inicializa as propriedades de cada movimento possibilitando assim sobrepor as lógicas de negócio padrões.

Exemplo: Chamada da função definida dentro do config_espec.js : EPCVerifyPermissionOfRestricion(moviment);

6) 

Alterar a tela para Procedimentos em Auditoria e Insumos em Auditoria:

A estrutura os movimentos devem ser alterada para a seguinte forma Procedimentos em Auditoria e Insumos em Auditoria e não mais em Movimentos em Auditoria e Movimentos Vinculados.Essa estruturação se deve pois nesse processo o sistema apresenta todas as regras que os movimentos podem vir a sofrer o que resultaria em uma lista de movimentos em auditoria muito grande perdendo o real sentido.

7)

Adicionar botão que possibilite desfazer a Troca de um movimento

8)

Adicionar na tooltip sobre o valor e a quantidade do movimento a informação referente a todas as glosas do movimento .

9)

Desenvolver uma tela para efetuar a troca da glosa principal. Nessa tela é possível definir dentre as glosas existentes no sistema a que será a principal.

10)

Destacar os movimentos que possuem glosas validadas com outra cor.

Fluxo do Processo

Com a alteração na sequencia de execução o fluxo do processo segue a seguinte estrutura.