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

1)     Primeiro acesso no Portal (Portal do Beneficiário)

Após o cadastro da vida no sistema pela Operadora (tabela BTS - Vidas), o usuário deverá acessar o portal do beneficiário e clicar na opção Primeiro acesso, pois é a primeira vez que está acessando o ambiente e deseja solicitar adesão ao plano.

Após clicar nesta opção, será apresentado ao usuário uma janela com os campos CPF, que deverão ser preenchidos com essas informações, a fim de localizar seu cadastro na tabela de vidas. Aqui, poderão ocorrer 3 eventos distintos:

• Caso a pesquisa com as informações imputadas pelo usuário não coincidam com nenhum dado da tabela BTS, será necessário avisar dessa inconsistência e nenhum acesso será permitido.
• Caso a pesquisa encontre o registro na tabela BTS, será necessário verificar se existe registro para este usuário na tabela de portal (BSW - Usuários do Portal). Caso encontre o registro, será necessário alertar o usuário, informando que não se trata de um primeiro acesso e que caso tenha perdido os dados de acesso ao portal, deve solicitar pelo link Esqueci minha senha (já presente na tela de login do Portal). Nenhum acesso deve ser permitido.
• Caso encontre o registro na tabela BTS e não tenha registro na tabela de usuários, o usuário deverá ser alertado que será enviado ao e-mail dele um login e senha provisórios de acesso ao portal, devendo trocar a senha assim que acessar a primeira vez o portal. Porém, antes do alerta de envio do usuário e senha para o email, devemos realizar mais algumas validações:
  • Caso no cadastro do usuário não conste e-mail ou seja um e-mail inválido, o usuário deverá ser alertado sobre essa inconsistência e nenhum acesso permitido.
  • Caso o e-mail esteja correto, será necessário incluir o registro do usuário na tabela de usuários do portal (BSW) e exibir um alerta, indicando que um e-mail foi enviado com a senha e login para o primeiro acesso
• Ao acessar o portal pela primeira vez, será necessário que o usuário troque sua senha (conforme requisito DT_Alteracao_Senha_Primeiro_Acesso) e deverá ter acesso apenas a Inclusão de beneficiários no plano e na tela de Consulta de Protocolos, nenhum outro menu deverá ficar disponível (conforme requisito DT_Criação_Perfil_Acesso_Usuários_Prestador_Beneficiário).

Escopo do primeiro acesso

1. Criar parâmetro MV_PLLPACE, do tipo lógico, com valor padrão .F.. Este parâmetro irá definir se deverá ser exibido no portal do PLS o menu Primeiro Acesso. Se o valor for .T., significa que irá exibir.
2. Realizar alteração fonte PWSX010.prw, pois é o fonte que trata a página principal do portal, adicionado mais uma nova opção, chamada Primeiro Acesso.
3. Incluir no fonte PWSX000.PRW a função ChaPACE, que será a função JavaScript responsável em abrir a nova janela, onde o beneficiário irá digitar seu CPF, para seu primeiro acesso.
   OBS: Por se tratar de um fonte genérico, as alterações devem ser cuidadosas, evitando prejuízos para outros módulos. Por isso, deverá se atentar para as modificações já existentes para o Portal do PLS, prevendo modificações similares para a chamada desta nova janela.
4. Para facilitar futuras manutenções, o arquivo PPLMFUN não deverá ser mais usado, pois está com grande quantidade de funções, podendo ocasionar erros e lentidão na compilação e uso. Por isso, iremos criar um novo fonte especifico para as funções de chamadas de páginas e WebServices.

• • Criar o fonte PPLCMBEM, que irá abrigar as nossas funções de chamadas de páginas e Webservices relativos ao Portal Empresa/Beneficiário.

1. Criar a função PLSABPRAC no fonte PPLCMBEM, que será responsável pela abertura da nova página PPLPRIACP.APH.
2. Criar o fonte PPLPRIACP.APH, usando a classe WCHTML. O fonte será responsável em gerar a página HTML que irá receber as informações do usuário sobre seu CPF, e-mail ou matrícula, além do botão de Enviar.

• • Neste fonte, será necessário criar ou chamar as funções em JavaScript, responsáveis pelas validações necessárias, como:
    • Verificar se o CPF informado é válido – usar a função validarCPF existente no arquivo jspls.js.
    • Ao invés de criarmos campos separados para e-mail ou matrícula, podemos criar um único campo, que irá validar se a informação imputada se trata de e-mail. Se não, sabe-se então que devemos procurar por matrícula. Para validar se o campo se trata de um e-mail, utilizar a função validarEMAIL, no arquivo jspls.js.

1. Criar a função PLSPESQPA no fonte PPLCMBEM, pois será a função que irá receber os parâmetros informados (CPF, e-mail ou matricula) pelo usuário da tela PPLPRIACP.
2. No fonte WSPLSXFUN, será necessário criar o método PLSPSQVIDA, onde de acordo com o CPF informado, irá pesquisar na tabela BTS – Cadastro de Vidas, se o CPF está inserido.

• • Se não encontrar o CPF na tabela, deverá retornar mensagem ou status (de acordo com a lógica utilizada), para informar ao usuário que o CPF não existe na Base de dados e que deverá ser procurado o RH. (OBS 5)
  • Se encontrar a vida na tabela BTS, deverá verificar se existe e-mail cadastrado e se sim, verificar na tabela BA1 – Beneficiários, se já existe algum cadastro como beneficiário. Se houver, deverá retornar mensagem ou status (de acordo com a lógica utilizada), informando ao usuário que já possui cadastro no sistema e que caso tenha perdido a senha, deverá solicitar via portal, no link Esqueceu sua senha. (OBS 5)
  • Caso não encontre registro na tabela BA1, deverá usar a função PIncLogin(), no fonte PLSA260, para realizar a criação de um usuário no portal.  O login dele deverá ser o CPF.

OBS 1: Antes de chamar a função PIncLogin(), será necessário verificar se consta algum endereço de e-mail e se o mesmo é válido no cadastro da tabela BTS (campo BTS_EMAIL). Se constar, para validar e-mail, pode-se utilizar a função IsEmail() ou alguma outra já existente no PLS. Se não constar e-mail ou ele for inválido pela validação, será necessário alertar que para o cadastro não existe e-mail válido e que deve entrar em contato com RH. (OBS 5)

OBS 2: A função PIncLogin deverá ser alterada em alguns pontos, pois ela procura dados na tabela BA1 e referencia campos para preencher alguns dados na BSW. Será necessário alterá-la para incluir um login de uma vida, que ainda não é beneficiário. Assim, alterar a função para pular algumas verificações e incluir dados diferentes de um beneficiário – pois temos apenas dados de uma vida – de forma que depois, possamos localizar o registro e atualizá-lo no final do processo, quando se tornar uma vida (pode-se usar como informação o CPF).

OBS 3 : Será necessário amarrar este login criado como primeiro acesso, devendo o usuário ao se logar pela primeira vez, trocar a senha por uma de sua preferência e possuir acesso apenas a Solicitação de inclusão de beneficiários e Consulta de Protocolos, nenhum outro menu do portal de beneficiário/empresa deverá ficar ativo. O campo BSW_PRIACE deve ser preenchido com o valor de primeiro acesso e a Operadora deve criar um grupo de usuário com perfil de primeiro acesso, limitando apenas ao menu de inclusão e protocolo, que deverá ser associado a este login criado. Será necessário criar o parâmetro MV_TPPERA, que será onde o Operadora irá informar o código desse perfil criado e que será usado na função para preencher o campo BSW_CODACE.

Com relação ao primeiro acesso, consultar o Documento Técnico DT_Alteracao_Senha_Primeiro_Acesso, que trata deste tema e com relação a restrição de acesso, usar as diretivas de direito de acesso do PLS e consultar a nova funcionalidade de bloqueio de menus, que encontra-se disponível no link DT_Criação_Perfil_Acesso_Usuários_Prestador_Beneficiário.

OBS 4: O login gerado deverá ser baseado no CPF do beneficiário. A função responsável em gerar o primeiro acesso verifica como isso deve ser montado (pois pode ser baseado no CPF ou matrícula) e se for necessário, a função deverá ser alterada para considerar o CPF -quando solicitado via portal, já qu temos apenas o CPF da vida.

• • Após a gravação dos dados na tabela BSW – Usuário do Portal, será necessário emitir um alerta para o usuário, orientando que o login e a senha foram enviados para o e-mail do cadastro e que ele será necessário para ter o primeiro acesso no portal. (OBS 5)
  • O beneficiário deverá acessar o portal com este login, devendo ser obrigado a trocar de senha (ver OBS 3 nos itens anteriores).  
  • Após a troca da senha, apenas o menu de solicitação de inclusão de beneficiários e consulta de protoclos deverá ficar ativo, para que possa realizar a sua inclusão e dos demais dependentes. (OBS 5)

       OBS 5: Como serão várias mensagens, usar o recurso de mensagens personalizadas no Portal, conforme Parte I desta especificação (ER_PCREQ-6467_Manutencao_Beneficiarios_Portal_Remote_PARTE I).

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.

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