ER_PCREQ-6467_Manutencao_Beneficiarios_Portal_Remote_PARTE VII (Analise_Geracao_Familia)

Informações Gerais

Objetivo

A especificação visa detalhar todas as regras de negócio envolvidas no processo de manutenção de beneficiários através dos portais do Beneficiário (como a inclusão, exclusão e outros ajustes de seu plano e dependentes) e portal Empresa (inclusão, exclusão e outros ajustes de colaboradores e respectivos familiares).

Por se tratar de portais que visam trazer ganhos e facilidades para todos os envolvidos nessas operações, se faz necessário uma ampla concepção de todos os conceitos envolvidos, bem como facilitar essas ações para que o uso seja simples e direto, possibilitando um rápido aprendizado pelos usuários e que as informações sejam confiáveis, pois serão tratadas pela operadora e replicadas para todos os sistemas.

Possibilitando as manutenções de beneficiários e demais ajustes pelos portais, todos os envolvidos ganham em agilidade e fiabilidade das informações, além de diminuir o tempo de interação com a operadora, já que se pode resolver tudo de forma online e sem intermediários, tornando o processo mais seguro e simples, pois elimina-se uma série de etapas que pouco agregam para o resultado final e que muitas vezes, acabavam onerando os demais envolvidos.

Desta forma, iremos detalhar as regras envolvidas nestes processos, que abrangem os portais e o remote do Protheus – visando demonstrar quais são as validações e controles necessários para tanto. 

Definição da Regra de Negócio

Nesta última parte da especificação, iremos tratar sobre a tela de Análise para os usuários da Operadora, que irão analisar as solicitações e aprová-las ou não. Além desta parte de análise, também iremos tratar sobre a geração do grupo familiar, ou seja, quando da inclusão de usuários via portal e após análise esteja tudo correto, o usuário responsável pela análise deverá gerar o grupo familiar, onde todos os dados informados serão inseridos nas tabelas corretas e gerado o grupo familiar, além da correção dos dados do usuário titular na tabela BSW - Usuários do Portal,  pois agora o titular possui matrícula e devemos realizar o processo correto, bem como a migração de anexos que estejam atrelados a tabela B2N, que deverão ser transferidos para a tabela BA1, com a chave padrão do sistema.

Tela de Análise - Remote

Após a inserção dos dados e documentos dos usuários nas telas de Inclusão, Manutenção ou Exclusão, é necessário realizar a análise dessa massa de dados, para verificar a consistência e procurar possíveis irregularidades nas informações, providenciando maiores esclarecimentos junto ao usuário.

Desta forma, todas as movimentações realizadas serão analisadas por uma equipe da Operadora, que terá em tempo real as informações imputadas pelos usuários e no caso de divergências, poderá negar determinada solicitação e deixar um aviso ao usuário.

1. Será necessário criar uma nova tela de Análise de manutenção de beneficiários. Criar o fonte PLSA977AB.
2. A tela terá que possuir a mesma estrutura existente no fonte PLSA814. Usar este fonte como base para desenvolvimento, pois será necessário poucas mudanças para o atual requisito.
3. No nosso caso, a tabela BBA será o cabeçalho da tela de Análise.
4. Será necessário a criação de uma aba denominada Passos da Análise, conforme existe hoje na PLSA814. Esta aba é onde o usuário pode ir definindo os passos que estão sendo tomados na análise. O cadastro destes passos está na tabela B4G – Passos da Análise (Atualizações -> Rede de Atendimento -> Passos da Análise).
   1. Para evitar a criação de outra tabela idêntica a B4G, para criar os passos referentes a Análise do beneficiário, criar um novo campo, do tipo combo – B4G_LEGBEN – que irá armazenar os status referente a tela de análise de Beneficiários.
   2. Para evitar problemas futuros, será necessário alterar o fonte PLSA816 – fonte responsável pelo cadastro de passos, de forma a criar um título que diferencie bem quando se trata de status de Prestador/Credenciado e quando é status de Beneficiário. Por ser em MVC, utilizar a propriedade SetProperty para manipular os títulos dos campos.
5. Para evitar a criação de outra tabela de Análise versus passos, alterar a tabela B5G – Passos x Análise, adicionado um campo B5G_CODBEN, para que o código do protocolo da tabela BBA fique atrelado a este campo, permitindo o relacionamento.
   1. Fazendo esta alteração, será necessário mexer nos filtros em MVC, para retornar os registros a partir deste novo campo quando estamos tratando Análise de beneficiário (alterar os filtros de modo que quando estamos na tela de Análise de beneficiário, o filtro trate este campo, trazendo apenas os dados referentes aos beneficiários).
6. Quando selecionado o registro para análise no browser, de acordo com o campo BBA_TIPMAN, a aba de análise deverá trazer os dados correspondentes ao trabalhado:
   1. Se o campo BBA_TIPMAN estiver com o valor 1, significa que se trata de uma Inclusão. Logo, na hora de visualizar a tela de análise, deve haver o tratamento no fonte, na parte da View, para exibir como alias a tabela B2N, pois é a nossa tabela temporária de dados.
   2. Se BBA_TIPMAN contiver o valor 2, significa uma Manutenção. Assim, a View deve retornar a tabela BA1, pois estamos alterando um usuário já existente no sistema.
   3. Se BBA_TIPMAN retornar o valor 3, significa que estamos no processo de exclusão. Logo, o alias também será referente a tabela BA1.
      
      
7. Na análise de uma Inclusão (campo BBA_TIPMAN com valor 1), devemos observar:
   1. O usuário poderá deferir/indeferir por item, conforme sua análise. Se o pedido for deferido, deverá marcar o checkbox na frente do item do beneficiário. O campo B2N_STATUS deverá mudar para Aprovado, caso o usuário marque o registro como aprovado.
   2. Se todos os itens forem deferidos e não houver documentos faltando, o usuário deverá adicionar o passo correspondente a finalização da tarefa, na aba passos. Como o passo está atrelado ao status da solicitação, o campo BBA_STATUS deverá ser atualizado para Aprovado.
      OBS 1: Caso todos os itens estejam como aprovados, mas o usuário não adicionou o passo da finalização, ao clicar em Salvar da janela de análise, o sistema deve verificar se todos os itens estão aprovados e sem falta de documento. Se sim, deverá alertar o usuário, dando duas opções: Caso deseje adicionar o passo, deverá clicar no botão Cancelar do alerta, para voltar na tela e adicionar o passo da finalização.  Se não quiser adicionar o passo e deseja apenas aprovar, deverá clicar em Continuar e o sistema irá atualizar o campo BBA_STATUS para Aprovado.
   3. Caso na análise nenhum item seja marcado como aprovado e falte documentos (Pendente Documentação), o usuário deverá selecionar o passo correspondente, para alterar o status do protocolo. Caso clique em Salvar da janela de análise com estas incoerências e o campo BBA_STATUS esteja diferente de Rejeitado, deve alertar o usuário, perguntado se deseja adicionar o passo ou atualizar apenas o Status: Caso deseje adicionar o passo, deverá clicar no botão Cancelar do alerta, para voltar na tela e adicionar o passo desejado. Se não quiser adicionar o passo, apenas rejeitar, deverá clicar em Continuar e o sistema irá atualizar o campo BBA_STATUS para Rejeitado.
   4. Caso o usuário aprove algum registro, mas existam outros não aprovados e com falta de documentos, deverá clicar no campo BBA_OBSERV e adicionar o tipo de documento ou informação que falta. Deverá adicionar também o passo desejado, pois neste caso, o status (BBA_STATUS) deve ficar como Aprovado Parcialmente.
      Caso o usuário clique no botão Salvar da janela de análise e esteja no caso acima, com itens aprovados e outros não - além do status (BBA_STATUS) diferente de Aprovado Parcialmente - o usuário deve ser alertado sobre essa diferença no status, podendo retornar a tela e adicionar o passo desejado ou então, deixar o sistema atualizar automaticamente para Aprovado Parcialmente.
      
      
8. Na análise de uma Alteração (campo BBA_TIPMAN com valor 2), devemos observar:
   1. Se o protocolo está como Pendente de Documentação e o item não foi aprovado, o usuário deverá adicionar um comentário no campo BBA_OBSERV e selecionar o passo adequado, pois se trata de uma rejeição. Ao clicar no botão Salvar da tela de análise, o sistema deve verificar está situação e caso o status esteja diferente de Rejeitado, deverá emitir um alertar e informar o usuário, dando duas opções a este: adicionar o passo correspondente a análise (para atualizar o campo BBA_STATUS como Rejeitado) ou então, atualizar automaticamente o campo BBA_STATUS para Rejeitado.
   2. Se o protocolo não consta como Pendente de Documentação e o item não foi aprovado, deverá continuar com o Status Em Análise. Ao clicar no botão Salvar da tela de análise, deverá verificar está situação e caso o status(BBA_STATUS) esteja diferente de Em Análise, deverá emitir um alerta e informar o usuário, dando duas opções a este: adicionar o passo desejado, que permaneça com o status Em Análise ou então, atualizar automaticamente o campo BBA_STATUS para Em Análise.
   3. Se o protocolo não consta como Pendente de Documentação e o item foi aprovado, deverá ficar com o status Aprovado. Ao clicar no botão Salvar da tela de análise, deverá verificar está situação e caso o status esteja diferente de Aprovado, deverá emitir um alerta e informar o usuário, dando duas opções a este: adicionar o passo desejado, que atualize o BBA_STATUS como Aprovado ou então, atualizar automaticamente o campo BBA_STATUS para Aprovado.
   4. Caso o protocolo esteja como Pendente de Documentação, não deverá ser possível aprovar este registro, pois falta documentos.
      
      
9. Na análise de uma Exclusão, (campo BBA_TIPMAN com valor 3), devemos observar:
   1. Se o protocolo está como Pendente de Documentação e o item não foi aprovado, o usuário deverá adicionar um comentário no campo BBA_OBSERV e selecionar o passo adequado, pois se trata de uma Rejeição. Ao clicar no botão Salvar da tela de análise, o sistema deve verificar está situação e caso o status esteja diferente de Rejeitado, deverá emitir um alertar e informar o usuário, dando duas opções a este: adicionar o passo correspondente a análise e que atualize o campo BBA_STATUS como Rejeitado ou então, atualizar automaticamente o campo BBA_STATUS para Rejeitado.
   2. Se o protocolo não consta como Pendente de Documentação e o item não foi aprovado, deverá continuar com o Status Em Análise. Ao clicar no botão Salvar da tela de análise, o sistema deve verificar está situação e caso o status esteja diferente de Em Análise, deverá emitir um alertar e informar o usuário, dando duas opções a este: adicionar o passo desejado, que atualize o status como Em Análise ou então, atualizar automaticamente o campo BBA_STATUS para Em Análise.
   3. Se o protocolo não consta como Pendente de Documentação e o item foi aprovado, deverá ficar com o status Aprovado. Ao clicar no botão Salvar da tela de análise, o sistema deve verificar está situação e caso o status esteja diferente de Aprovado, deverá emitir um alertar e informar o usuário, dando duas opções a este: adicionar o passo desejado, atualizando o BBA_STATUS como Aprovado ou então, atualizar automaticamente o campo BBA_STATUS para Aprovado. Verificar o Item 10, abaixo.
   4. Caso o protocolo esteja como Pendente de Documentação, não deverá ser possível aprovar este registro, caindo nas regras anteriores.
10. Observações importantes na exclusão:
    1. Quando o registro for Aprovado, o beneficiário não será excluído jamais do sistema, por questões de integridade de dados e histórico.
    2. O registro dele ficará como Bloqueado, não permitindo qualquer tipo de atendimento ou operação. Assim, quando aprovar o registro, o desenvolvedor terá que atualizar os campos de bloqueio:
       1. BA1_DATBLO: Data do Bloqueio, informar a data atual do sistema
       2. BA1_MOTBLO: Motivo do bloqueio. Essa informação vem da tabela BG3 – Motivos de Bloqueio.
       3. BA1_CONSID: Considera bloqueio. Se usuário, preencher com U.
    3. Além disso, quando o usuário ou família é bloqueado, é necessário alimentar também a tabela BC3 – Controle Famílias. As informações são iguais aos campos anteriores, da tabela BA1, mas deve-se preencher os outros:
       1. BC3_MATRIC: Número de matrícula do beneficiário.
       2. BC3_TIPO: Informar se o beneficiário está bloqueado, devendo passar o valor B.
       3. Demais campos são informações presentes na BA1, bastando preencher com a informação solicitada.
    4. Deste modo, quando o registro for Aprovado, deverá ser apresentado uma tela (escrita em MVC ou pode-se utilizar a janela do ParamBox), onde o usuário deverá escolher apenas o motivo de bloqueio, pois as demais informações serão passadas pela rotina. Após a escolha, gravar nos campos e tabelas mencionados anteriormente.
    5. Caso a exclusão seja do titular do plano, automaticamente, o sistema deverá efetuar o bloqueio de todos os dependentes atrelados ao titular, preenchendo os campos e tabelas mencionados anteriormente. Pode-se neste caso, bloquear a família toda, em vez do bloqueio individual de cada usuário.
       OBS: Verificar também a necessidade de colocar o registro do titular e demais dependentes que possuam login no portal como deletado, evitando o acesso indevido destes.
    6. A função de bloqueio de usuário é a PL260BLOUS(), enquanto que a rotina de bloqueio de família é a PL260BLOCO(), ambas no fonte PLSA260.
            

Aprovação Grupo Familiar

Após análise das solicitações de inclusão no plano de saúde, o usuário do sistema poderá mandar gerar a família, ou seja, gravar os dados na tabela BTS, BA1, BA3 e demais que são relacionadas a vida e grupo familiar, para o protocolo que possua o status como Aprovado.

Essa opção ficará no botão Outras Ações, no browser da tela de Análise (PLSA977AB)

1. Criar o parâmetro MV_CODPLAP, parâmetro que irá armazenar o código do plano padrão utilizado na inclusão de grupo familiar via essa funcionalidade. Caso a operadora tenha vários planos, bastará apenas deixar em branco.
2. Criar o parâmetro MV_DATVENP, que irá armazenar a data de vencimento padrão da mensalidade dos beneficiários que estão sendo inseridos.
3. Criar o fonte PLSGERGRFM, que será o fonte responsável pelas funções de inclusão de grupo familiar.
4. No fonte acima, criar a função PLSINCGFAM(), responsável pela inclusão dos registros em todas as tabelas de vida, beneficiários e demais atreladas.
5. No browser de Análise (PLSA977AB), adicionar no menudef a opção Gerar Grupo Familiar, que deve ficar no menu Outras Ações.
6. Ao clicar neste item, deve chamara a função PLSINCGFAM ().
7. A função PLSINCGFAM () deverá utilizar o Begin Transaction, pois caso no processo ocorra algum erro, nenhuma alteração realizada será feita no banco de Dados, preservando a integridade e coerência dos dados. Para desarmar uma transação, utilize o comando DisarmTransaction().
8. A função PLSINCGFAM() deverá verificar o status do protocolo: se o campo BBA_STATUS for diferente de Aprovado, deve emitir um alerta, informando que não é possível incluir um grupo onde o protocolo não está aprovado.
9. Caso esteja aprovado, o sistema deverá verificar o parâmetro MV_CODPLAP, pois se estiver preenchido, esse código será usado no campo BA3_CODPLA para todos os beneficiários. Se estiver em branco, deverá abrir uma janela ao usuário, com o combo dos planos que a operadora possui. Poderá ser pensado também em algum filtro onde, de acordo com os planos disponibilizados para a empresa onde a vida está alocada, mostrar apenas os planos comuns a este contrato.Após a verificação do parâmetro ou escolha do usuário do plano, a função deve incluir os registros da tabela B2N nas tabelas de Vida (BTS), Beneficiários (BA1) e grupo familiar (BA3), de acordo com os dados registrados.
   1. Essa janela pode ser feita em MVC ou outro objeto, inclusive com o ParamBox (consultar os fontes PLSA260, PLSA500 e PLSJNTME). 
10. O desenvolvedor deverá verificar a obrigatoriedade de alguns campos nessa inclusão, para preencher com o default deles. Os campos obrigatórios para uma inclusão simples são:
    1. BA3_CODPLA – Código do plano, proveniente do parâmetro MV_CODPLAP ou da escolha em tela do usuário;
    2. BA1_MATVID – Matrícula da vida – que será gerada neste processo
    3. BA1_DATINC – Data de Inclusão (considerar a data atual)
    4. BA1_MAE – Nome da Mãe
    5. BA3_VENCTO – Dia do vencimento da mensalidade, considerando o parâmetro MV_DATVENP
11. Esses campos são o mínimo para gerar os dados nesta tabela e poder criar o grupo familiar, com o titular e seus dependentes.
12. A função deverá realizar a inclusão de todos os dados, de modo que a família fique operacional no sistema, já podendo utilizar o plano, com seu número de matrícula gerado e aprovado.
13. No final do processo de inclusão, a função deverá atualizar o status do protocolo, colocando no campo BBA_STATUS o status de Processado.
14. No final do processo, enviar um e-mail para o titular, avisando que que o grupo familiar foi criado e o número de matricula de todos os dependentes da solicitação. Usar a função PLSINALIZA() - fonte PLSA814.
15. Será necessário também atualizar o cadastro do usuário na tabela BSW e B49, pois agora, o titular possui matrícula. Assim:
    1. Localizar o registro gerado na tabela BSW e inserir os dados corretos, conforme matrícula do usuário gerada.
    2. Reconfigurar seu acesso, permitindo que ele tenha acesso completo ao menu dos portais, pois agora é um beneficiário.
    3. Além disso, no campo BSW_CODACE, deverá ser colocado o valor do parâmetro MV_TPPRAP, pois é o perfil que possui acesso completo aos menus do portal.
16. Uma vez gerado o grupo familiar, não será possível gerar novamente o grupo familiar para o mesmo protocolo e nem permitir a edição de dados. Para isso, utilizar o campo B2N_FLGCTR.

NOTA: A rotina deverá validar os dados dos beneficiários conforme regras da ANS, para validação do SIB (Sistema de Informações de Beneficiários). Consultar o chamado TSJKKA no SSIM, pois existe um chamado referente a isso.

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. Além disso, alterações poderão surgir, devido a negociações ou melhorias posteriores, bem como necessidades de adaptação, devido ao volume e quantidade de alterações necessárias ao sistema ou para funcionamento de todas as partes envolvidas.

Alguns dos requisitos aqui mencionados ainda estavam em fase de codificação. Logo, poderá ser necessário outras alterações não previstas, devido a este fato, bem como alterações surgidas no decorrer do desenvolvimento dos outros requisitos.

Protótipo de Tela

 
Figura 1 - Exemplo da tela PLSA814, na qual deve ser baseada a tela de Análise de beneficiários - PLSA977AB