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

Aqui, iremos detalhar a janela de Inclusão/manutenção de beneficiários, que será exibida sempre para a empresa ou beneficiário. De acordo com as ações nesta tela, iremos abrir a página correspondente a ação desejada do usuário, como inclusão, edição ou exclusão. Esta janela deverá ser sempre exibida ao usuário.

Também iremos detalhar a janela de Protocolos, que será a tela onde o usuário poderá consultar o andamento de suas solicitações e anexar documentos, caso seja necessário.

1)     Inclusão de Beneficiários

Nesta parte da especificação, iremos tratar sobre a tela de manutenção de usuários, que deverá ser exibida tanto para os beneficiários quanto para a empresa, para inclusão e manutenção das vidas existentes.

Essa tela deve ser exibida assim que o beneficiário conseguir seu primeiro acesso (primeira parte dessa especificação), bem como poderá acessar depois para dar a devida manutenção dos dados quando for necessário. O mesmo ocorrerá para a empresa, que irá acessar para realizar as manutenções de acordo com sua rotatividade e processos.

Abaixo, algumas premissas que devem ser seguidas para ambos os portais (beneficiário e empresa):

• O menu Solicitação de Inclusão deverá ser idêntico para ambos os portais, mas deverá ser passado um parâmetro para diferenciar qual é o tipo de acesso.
• De acordo com o tipo de acesso, a tela inicial terá diferenças, de acordo com o acesso.

Escopo da tela de Solicitação e manutenção:

1. Criar o fonte PPLSOLMBEN.APH, que será responsável pela exibição da tela inicial de solicitação e manutenção de beneficiários.
2. Criar a Web Function PPLSOLMBEN no fonte PPLCMBEM, que será responsável pela abertura da página de mesmo nome – página de manutenção e inclusão de novos beneficiários. Essa web function deverá ser passada com parâmetro, para diferenciar se o acesso é de beneficiário ou empresa, pois as exibições serão diferentes.
   
   • Para o parâmetro – chamado cTipo – o valor 1 significa acesso de beneficiário e o valor 2 significa acesso empresa.
   • OBS: Exemplo da web function com parâmetro: W_PPLSOLMBEN.APW?cTipo=1 e para pegar o valor desse parâmetro na web function, utilize o método HttpGet, que no caso ficaria HttpGet->cTipo.
3. O fonte PPLSOLMBEN deverá conter a seguinte estrutura abaixo e será diferenciado apenas pelas informações que serão retornadas, de acordo com o parâmetro cTipo da web function de mesmo nome. Caso o acesso seja realizado por um beneficiário, o grid trará as informações de todos os dependentes numa grid, para facilitar a sua visualização. Caso seja empresa, o grid virá em branco, para que seja possível a procura exata do colaborador desejado. 
   Esse fonte deverá ser construído com a classe WCHTML.
   • Adicionar um fieldset relativo a pesquisa, que irá abrigar os componentes listados abaixo:
   1. 1. Se o parâmetro cTipo da web function vier com o valor referente a beneficiário, adicionar um componente do tipo combo, listando os beneficiários atrelados ao login. A propriedade “value” do combo deve ser a matrícula e o “option” o nome dos beneficiários.
      2. Se o parâmetro cTipo da web function vier com o valor referente a empresa, deverá ser exibido um componente do tipo Pesquisa F3, para que seja possível a busca dos beneficiários relativos ao contrato da empresa. Essa pesquisa deverá retornar a matricula no próprio campo de pesquisa e o nome do beneficiário em outro campo, do tipo apenas leitura.
      3. OBS: Para a pesquisa do tipo F3, pode-se copiar o modelo encontrado no fonte  PPLCHACPR, que contêm pesquisa idêntica a necessária deste campo.
      4. Adicionar um campo do tipo Texto (Field), para receber o número do CPF. Pode-se optar em formatar o campo, apenas para fins de exibição ao usuário. Deverá também validar se o CPF inserido é válido, evitando requisições desnecessárias de WebService.
      5. Inserir um componente do tipo botão – com o label Pesquisar – que irá executar a chamada da função para pesquisa via WebService dos dados informados.
   • Abaixo do fieldset, adicionar um componente do tipo grid (GridData), que deverá possuir as seguintes colunas (sugerimos que o grid retorne no máximo 30 linhas de pesquisa por página):
   1. 1. Nome do beneficiário;
      2. Matrícula do beneficiário;
      3. CPF do beneficiário;
      4. Data de Nascimento do beneficiário;
      5. Tipo do beneficiário: Titular ou dependente;
      6. Botão Editar com imagem;
      7. Botão Excluir com imagem.
      8. Se o parâmetro cTipo da web function vier com o valor referente a beneficiário, sempre que a página for aberta, deverá trazer o grid com todos os beneficiários atrelados ao beneficiário que está logado. Mesmo com essa facilidade, as opções de busca deverão estar disponíveis, conforme item acima.
      9. Se o parâmetro cTipo for referente a empresa, esse grid sempre deverá ser exibido sem dados, visto a grande quantidade de colaboradores que pode possuir, aumentando a performance do portal e trazendo pesquisas exatas, de acordo com as informações inseridas na parte de pesquisa.
   2. Essa grid irá exibir os beneficiários encontrados, de acordo com os dados pesquisados pelo usuário e retornados via Web Service.
   3. Caso o portal seja Empresa, ao localizar um registro, deverá trazer no grid além do beneficiário pesquisado, os demais que estão atrelados ao mesmo contrato. Ou seja, ao localizar o registro, deve trazer o titular e demais dependentes atrelados ao contrato do beneficiário pesquisado. 
      Para exemplo de grid, utilize o fonte PPLCHABOL.APH. Este fonte tem todas as etapas necessárias para a criação do grid, desde a chamada da função PPLGETDGRI (localizado no fonte PPLMFUN), que em seguida chama o método do Web Service getDadGrid (no fonte WSPLSXFUN), que realizar uma série de funções e que por fim, chama uma função localizada no fonte PPLSRDBRW, responsável em executar o Select no Banco de dados, retornando os dados solicitados. Logo, é necessário seguir o mesmo procedimento para o retorno dos dados.

4. Na página, será necessário crias as funções JavaScript encarregadas de obter os dados inseridos no componente field de pesquisa e que irão disparar a pesquisa no WebService.

   De acordo com o retorno, alimentar o grid com as informações localizadas. Se a pesquisar não retornar dados, informar o usuário via mensagem na tela (usar preferencialmente a função modalBs, que está localizada no arquivo jspls.js, que possibilita cores e outros componentes a mais nos diálogos).
   • Criar no fonte WSPLSXFUN uma rotina de pesquisa de beneficiários na tabela BA1 e se necessário, do grupo familiar - tabela BA3 - para trazer os resultados da pesquisa (conforme exemplo acima do fonte PPLCHABOL.APH). 
5. O botão Editar no grid deverá chamar a página PPLMANBEN, que será a página responsável pela manutenção dos dados do usuário selecionado no grid. Ou seja, quando pressionado, irá abrir a página PPLMANBEN com todos os dados constantes no cadastro do beneficiário selecionado, onde o usuário deverá efetuar a manutenção desejada. Lembre-se: quando for chamar o formulário de manutenção, seja necessário passar como parâmetro cRecno, com o número RECNO do registro posicionado, pois será usado o layout genérico.
6. O botão Excluir, ao ser pressionado, irá chamar a página PPLEXCBEN, que será a página de exclusão de beneficiários. Assim que for pressionado, deverá abrir a PPLEXCBEN e trazer todos os dados preenchidos, para conferência do usuário. Ou seja, ao clicar no botão Excluir, o usuário será alertado (usar a função modalBs) que a ação selecionada é a exclusão do usuário. O alerta deverá ter os botões para confirmar ou cancelar (ou equivalentes) a ação de exclusão.
   • Caso seja pressionado o botão cancelar, nada será alterado.
   • Se for pressionado o botão de confirmar, será aberta a página PPLEXCBEN, com todos os dados do usuário já preenchidos e não editáveis. 
7. Abaixo do grid, inserir um componente do tipo botão, que deverá possuir a label Inserir um novo beneficiário.
   • Ao pressionar esse botão, o usuário deve ser alertado se realmente deseja incluir uma nova vida no plano de saúde. Esse alerta deve usar a função modalBs(), com os botões de cancelar e confirmar (ou equivalentes).
   • Se pressionado o botão de Cancelar, nada será alterado na página.
   • Se pressionado o botão Confirmar, deverá ser aberta a página PPLINCNBEN, que será a página responsável pela inclusão de novos dependentes no plano de saúde. Após uma inclusão, deverá ser gerado um relatório e um protocolo. (ver item xxxx).
     OBS: caso a operadora deseje, poderá incluir um atalho direto para esta página, no menu dos portais.

   1. OBS 1: Se o portal for Beneficiário e não houver nenhum registro de beneficiário cadastrado, significa que não existe beneficiários no Plano. Assim, a primeira inclusão deve ser do titular do plano, para em seguida, incluir os dependentes. Assim, de acordo com o login (também é possível criar um controle para verificar se trata de primeiro acessou ou outro método), verificar se a vida existe no cadastro da tabela BTS. Se sim, quando clicar no botão Incluir novo beneficiário, os campos da página de inclusão deverão carregar os dados que estão na vida da tabela BTS, marcando este como titular, para facilitar ao usuário. Somente depois da inclusão do titular permitir a inclusão dos dependentes.

   2. OBS 2: Se o portal for Empresa, esse botão deverá ficar oculto, sendo exibido somente após a pesquisa de alguma vida, conforme parâmetros de pesquisa. Caso a empresa pesquise uma vida e para esta não retorne nenhum beneficiário, significa que não existe beneficiários no plano. Assim, habilitar o botão Incluir Novo beneficiário e quando clicar, os campos da página de inclusão deverão trazer os dados da vida pesquisada nesta tela, pois significa que iremos incluir primeiro um titular, para depois, incluir os dependentes.

2)     Protocolo de Solicitações

Após a inclusão ou manutenção de usuários, o usuário do portal poderá verificar os protocolos gerados, para acompanhar o andamento das solicitações, bem como para adicionar documentos quando necessário.

Essa tela deverá ser construída com a classe WCHTML. A tela será idêntica da tarefa ER_Solicitacao_de_adesao_a_Opcionais_via_Portal, no tocante a tela de Consulta de Solicitações (Protótipo 04 do link).

1. Os registros de protocolo estão na Tabela BBA – Cabeçalho Solicitações Beneficiários.
2. O desenvolvedor poderá utilizar o mesmo layout utilizado nesta tela, com as adaptações necessárias para o bom funcionamento com relação a solicitação de protocolos de manutenção de beneficiários.
3. O grid que apresentará os itens deverá ter a seguinte estrutura:Quando o portal for de beneficiários, todos os protocolos serão exibidos para o usuário logo que abrir a tela, pois trará poucos registros. Porém, as opções de filtros poderão ser utilizadas a qualquer momento.
   1. Coluna Status;
   2. Coluna do tipo botão, que ao ser pressionado, irá exibir abaixo um grid com todos os itens atrelados ao protocolo (ou seja, os beneficiários que sofreram algum processo de inclusão, manutenção ou exclusão);
   3. Coluna Número do Protocolo;
   4. Coluna do tipo de Solicitação (Inclusão, Manutenção ou Exclusão);
   5. Coluna do tipo botão, que ao ser clicado, irá exibir as observações do analista, caso exista;
   6.  Coluna da Data de Solicitação;
   7. Coluna do tipo botão, que ao ser clicada, o usuário poderá anexar um ou mais documentos.
4. Quando o portal for empresa, ao abrir a tela, nenhum registro deverá ser retornado, pois dependendo do volume, ocasionará lentidão e perda de performance. A empresa terá que filtrar por número de protocolo ou status.
5. Nesta tela, o usuário poderá incluir anexos faltantes (como o formulário de manutenção e outros). O desenvolvedor poderá escolher se deseja abrir uma nova janela com os campos de inclusão do anexo ou então, abrir uma div para isso.
6. O status desta tela deverá acompanhar os status que existem na tela de análise do Remote do Protheus, pois nesta tela, a análise se dá por item. Assim, será necessário adicionar também as legendas existentes no remote.
7. Só será possível anexar documentos quando o Status estiver como Pendente de documentação ou Rejeitado.
8. Se a solicitação estiver com o status Pendente de Documentação ou Rejeitado e for adicionado  algum anexo, o status do protocolo deverá ser atualizado "Em análise".
9. Quando da inclusão do Anexo, será necessário exibir para o usuário o combo xxxxx, para que seja possível selecionar o tipo de documento que será anexado.
10. Para verificar as condições gerais de anexos, Consultar o item Anexos e Documentos desta especificação.

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.

Opcional

Protótipo de Tela

Image Added

Figura 1 - Protótipo da tela de manutenção principal, com grid e informação de beneficiários. Quando Portal Beneficiário, os usuários atrelados ao login já vem no grid e o campo beneficiário é um combo<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 01Image Added

Figura 2 - Protótipo da tela de manutenção principal, com grid e informação de beneficiários. Quando Portal Empresa, o grid deve ficar sem nenhum dado, apresentando apenas após a consulta 

 Image Removed

Image Added

Figura 4 - Tela em que deve ser baseado a consulta de Protocolo de solicitações (realizar as alterações necessárias, conforme descrito acima. Imagem obtida em ER_Solicitacao_de_adesao_a_Opcionais_via_Portal)