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

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

Objetivo

A presente especificação visa detalhar o processo de preenchimento automático da autorização de um reembolso protocolado e deferido.

Desta maneira, após análise e deferimento de um protocolo, o sistema permitirá que a autorização seja gerada com os dados do protocolo preenchidos automaticamente, aumentando a eficiência do sistema e diminuindo esforço do operador, otimizando o processo e minimizando inconsistências.

Definição da Regra de Negócio

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

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

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

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

 Image Removed

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

Um reembolso de procedimento/medicamento é efetuado quando uma autorização é gerada. Essa autorização de reembolso pode ser gerada a partir de um protocolo incluído anteriormente.

As regras de negócio a seguir descrevem as alterações necessárias nas rotinas de Protocolo de Reembolso e Autorização de Reembolso para possibilitar a abertura e preenchimento das informações da autorização automaticamente após o Deferimento do Protocolo. 

Regras de Negócio

1. Realizar alteração na função PBOWFinal() presenta na rotina PLSA001A - Protocolo de Reembolso para:

   1. Validações do status "Status <BOW_STATUS>":
      1. Permitir os próximos somente se o status for Deferido;
      2. Permitir o status Deferido somente se ao menos 1 dos itens for aprovado;
      3. Quando todos os itens do protocolo forem reprovados (isto é, glosados - B1N_IMGSTA = DISABLE), o status atribuído ao protocolo deve ser Indeferido;
      4. Caso a ação de reprovação seja desfeita (isto é, o item volte a ficar ativo - B1N_IMGSTA = ENABLE), o status atribuído ao protocolo deve ser Deferido; 
   2. Validar permissão para o usuário Aprovar Reembolso no cadastro de Operador verificando o conteúdo do campo existente "Aprova Reembolso? <BX4_APREEM>" (1=Sim; 0=Nao)
      1. Caso o conteúdo do campo BX4_APREEM seja 1, será exibida mensagem de questionamento “Deseja realizar a autorização do reembolso?”
         1. Aplicar regra de negócio 2.
      2. Caso o conteúdo do campo BX4_APREEM seja 2, não será exibida a mensagem pois não existe permissão para este usuário gerar aprovação do reembolso.
   3. Independente do usuário que confirmar a ação, sempre verificar a permissão para aprovação do reembolso através do campo BX4_APREEM. Em casos que outro usuário com permissão confirme alterações posteriormente ao primeiro usuário, a autorização deve ser gerada.
      
      

2. Após selecionar "Sim" na mensagem da Regra 1.B, o sistema abrirá a tela de PLSA001 - Autorização de Reembolso com as informações referentes ao protocolo já preenchidas. Realizar as alterações:

   1. Executar a função existente PLSGERAUT(), cuja função é exibir a tela de Autorização de Reembolso. Essa função já executa a rotina PL001MOV("BOW",Recno(),9). Os dados enviados por parâmetro identificam a chamada da tela pela rotina de Protocolo de Reembolso. Essa rotina preenche o campo “Num. Protocolo <B44_PROTOC>” com o valor obtido na tela anterior - PLSA001A - Protocolo de Reembolso, além de preencher o restante dos campos a partir do gatilho do protocolo.
   2. Preencher a grid "Eventos" com todos os itens existentes - fazer "while" de todos os registros - na B1N (campo B1N_PROTOC) e que sejam relacionados ao protocolo da BOW(campo BOW_PROTOC) proveniente da tela PLSA001A - Protocolo de Reembolso:
      1. Preencher automaticamente o campo “Cod. Proced. <B45_CODPRO>”, e ativar os gatilhos desse campo através da função RUNTRIGGER() (http://tdn.totvs.com.br/pages/viewpage.action?pageId=6815032);
   3. Popular a grid de "Composição" - Tabela B47.
   4. Popular a grid de "Críticas" - Tabela B46.
      1. Realizar ajustes na rotina de crítica (PLSA090PRO()) para exibir todos os itens existentes no protocolo de reembolso (atualmente, esse tratamento é feito para uma única crítica em um único item);

      2. Ajustar a rotina de crítica para (PLSA090PRO()) para possibilitar a autorização da crítica forçada de diversos itens de um mesmo protocolo.

   5. Realizar cálculo dos valores e atribuir valores aos campos M->B44_VLRPAG, M->B44_VLRGLO e M->B44_VLABF. Após calcular o valor dos campos para todos os itens do protocolo, preencher os totalizadores (elementos "say") da tela PLSA001 - Autorização de Reembolso (preenchimento já realizado através da função P001Vld(), verificar necessidade de alteração com múltiplos itens do protocolo).

      
      

3. Os itens das grids "Eventos", "Composição" e "Críticas" podem sofrer alterações através de ponto de entrada. Realizar alterações na grid para manipulação nas grids de acordo com o as alterações realizadas pelos pontos de entrada.

    

Tabelas Utilizadas

• BX4 - Operadores x Instituições
• B44 - Cabeçalho Reembolso
• B45 - Itens do Reembolso
• B46 - Críticas do Reembolso
• B47 - Sub-itens do Reembolso

Protótipo de Tela 

1. Image AddedMensagem de confirmação para gerar a autorização de reembolso preenchida com os dados do protocolo.

   
   Image Added
   

2. Tela "Autorização de Reembolso" com o protocolo preenchido ao iniciar.

Fluxo do Processo

Image Added

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