ER_PCREQ6248_JOB_Cancelamento_Solicitações_Protocolos

Informações Gerais

Objetivo

            A presente especificação visa detalhar a regra de negócios e definir algumas diretrizes para o desenvolvimento da rotina de JOB para cancelamento de solicitações ou protocolos de reembolsos após determinado período – definido pela operadora – caso a solicitação não seja concluída pelo beneficiário ou não haja interação dele neste período, nos casos onde o auditor ou outro analista da operadora solicitou maiores informações.

            Além disto, o processo também será aplicado para os casos onde não haja interação nos pedidos de maiores informações acerca de receitas de medicamentos de uso continuado.

            Desta forma, o JOB roda e facilita a gestão e controle destas solicitações, protocolos e receitas, pois irá efetuar o cancelamento automático, simplificando o processo de gestão e controle dos processos inacabados, além de permitir que o beneficiário não consiga mais alterar solicitações onde não houve interação por parte dele.

Definição da Regra de Negócio

            O JOB terá como finalidade cancelar solicitações e protocolos que permaneçam em certos status por um período definido pela Operadora – período este definido via parâmetro – para que estas solicitações sejam canceladas de forma automática, não necessitando de intervenção dos da Operadora, pois seria um processo moroso e nada prático.

            Abaixo, listamos as situações onde este JOB irá atuar, para maximizar o tempo e produtividade da equipe de usuários da Operadora, além de facilitar toda a gestão destes itens no dia-a-dia.

1. Toda vez que o usuário iniciar uma solicitação de Reembolso no portal do beneficiário e por algum motivo não concluir a sua solicitação (como queda de energia, oscilações na rede e outros problemas), essa solicitação ficará com o status Solicitação não concluída. Se após determinado tempo – definido via parâmetro – o usuário não terminar esta solicitação, o status deverá ser alterado para Cancelado.
2. Durante a análise do Protocolo de Reembolso, caso o usuário da Operadora julgue que falta alguma informação ou documento e solicitar uma interação do usuário acerca disto, o status deste protocolo fica como Aguardando Informação Beneficiário. Se após o tempo determinado pelo parâmetro não houver interação por parte do beneficiário, o protocolo deverá ficar com o status Cancelado.

            Logo, sempre que alguma solicitação via portal ficar com o status Solicitação não concluída ou no protocolo o status ficar como Aguardando Informação Beneficiário, após o tempo definido via parâmetro, será necessário cancelar estes processos com o JOB, simplificando a gestão e o trabalho de todos os envolvidos, visto que tudo isso será feito de forma automática e sem intervenção dos usuários, evitando erros e retrabalhos posteriores.

OBS: Durante o desenvolvimento da rotina, deverá ser feita de forma que possa depois, incluir outros itens para cancelamento via JOB. O ideal que a rotina seja genérica ou então, fácil de adaptar para incluir outras atividades de cancelamento, como por exemplo, cancelar receitas que não tiveram anexos do usuário e a Operadora colocou o status como Aguardando Informação Beneficiário. 

ESCOPO

1. Criar o parâmetro MV_PRACAN, pois neste parâmetro será armazenado o valor em dias para o cancelamento das solicitações e protocolos.  
2. As solicitações via portal e os protocolos são salvos na tabela BOW – Protocolo de Reembolso. O status de ambas ficam localizados no campo BOW_STATUS e a data de inserção é o campo BOW_DTDIGI.
3. Criar um novo fonte (PLSACANJB), para a criação de toda a lógica de verificação e cancelamento, pois desta forma, temos fontes desenvolvendo tarefas específicas, facilitando a codificação e manutenção futura.
4. Criar função PLSVSCAN, que deverá ser a responsável pela verificação dos status da guia e datas para o cancelamento. A data base para definir o cancelamento será a data de execução do JOB.
5. A função PLSVSCAN deverá varrer a tabela BOW, verificando se os status encontram-se como Solicitação não concluída ou Aguardando Informação Beneficiário.
6. Caso encontre algum registro com esses status, deverá verificar o campo BOW_DTDIGI e o valor do parâmetro MV_PRACAN, comparando com a data de execução do JOB. Ou seja, basta pegar o valor do campo BOW_DTDIGI e acrescer com o valor do parâmetro e comparar com a data de execução do JOB. De acordo com a  essa comparação, verificar se a solicitação ou protocolo ainda estão na validade: se não, o campo BOW_STATUS deverá ser atualizado para o status Cancelado. Além disso, deverá gravar no campo BOW_MOTIND o texto: Cancelado por falta de retorno do beneficiário.

7. No mesmo fonte, deve-se criar a função PLSVSCJB, que será invocada via JOB no Schedule. Esta função terá que receber como parâmetros a empresa e filial – que são passadas via array no Schedule e depois, chamar a função PLSVSCAN.
   Para exemplo de uma função chamada via JOB, consulte o fonte PLSA770JB.

   Exemplo de Função de JOB

   Function PLSVSCJB(aJob)
   Local cCodEm  := aJob[1]
   Local cCodFil  := aJob[2]
    
   RpcSetEnv( cCodEm, cCodFil , , ,'PLS', , )
   ConOut("Execução da Tarefa de cancelamento de guias conforme status")
    
   PLSVSCAN ()
    
   ConOut("Execução Finalizada!")
    
   Return()

Fontes Utilizados

Funções Utilizadas

Tabelas Utilizadas:

• BOW - Protocolo de Reembolso 
• B1N - Itens do Reembolso

Observação
Em consonância com as melhores práticas de programação e necessidades no desenvolvimento do requisito, poderão ser incluídos mais fontes ou outras funções de apoio e consulta, para executar da melhor maneira possível o proposto neste documento. 

Protótipo de Tela

Por se tratar de uma função que irá rodar em JOB, ela não terá uma interface com o usuário. Abaixo, iremos mostrar como ficaria a função PLSVSCJB sendo programada no Schedule do Protheus.

Fluxograma básico do Processo

Caso de Uso

Dicionário de Dados

Parâmetros