Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.                                                             

  

Informações Gerais

 

 

Especificação

Produto

Microsiga Protheus

Módulo

Plano de Saúde - SIGAPLS

Segmento Executor

Saúde

Projeto

M_SAU_PLS003

IRM

PCREQ-6465

Requisito

PCREQ-6467

Subtarefa

PCSFV-11

Release de Entrega Planejada

12.1.9

Réplica

Não

País

X ) Brasil  (  ) Argentina  (  ) Mexico  (  ) Chile  (  ) Paraguai  (  ) Equador

(  ) USA  (  ) Colombia   (  ) Outro _____________.

Outros

Devido a complexidade das mudanças necessárias, a especificação foi dividida em 4 7 partes. Está é a parte II (II de IVVII)

   

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_AlteracaoAlteração_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, matrícula ou e-mail 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 deacordo 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_AlteracaoAlteração_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 (Cadastros_Iniciais).).
           OBS 6: No final do processo, estando o layout pronto, configurado e testado, será necessário preencher o RUP_PLS com as informações deste layout e demais dados necessários, bem como verificar a necessidade de usar algum arquivo csv, para rodar junto com o Wizard do PLS (no momento da presente especificação, o Wizard ainda não está operacional, necessitando que o desenvolvedor veja qual arquivo é o correto para essa imputação de dados)

 

 

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

 Image Added

Figura 1 - Portal com o menu Primeiro Acesso


Image Added

Figura 2 - Janela de Primeiro acesso, solicitando o CPF do usuário.


 

 Image Added

Figura 3 - Exemplo de mensagem, ao informar um CPF inválido ou não cadastrado. Essas mensagens devem seguir o funcionamento conforme a Parte I desta especificação, no tocante as mensagens.

 


Image Added

Figura 4 - Tela de troca de senha (imagem obtida do documento DT_Alteração_Senha_Primeiro_Acesso)

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

 

 

 

 

 

 

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.