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.

Nesta primeira parte, iremos descrever as mudanças prioritárias que serão a base para os demais desenvolvimentos, bem como os dicionários de dados envolvidos, para realização dos cadastros.

Definição da Regra de Negócio

Por se tratar de um processo complexo – pois abrange desde o cadastro inicial do usuário no portal até a efetivação de seu vínculo ao plano escolhido – iremos dividir a nossa especificação em 4 partes distintas, visando uma maior compreensão dos itens que compõem a especificação, pois irá envolver uma série de modificações, seja em criação de telas e funções novas, bem como a modificação de processos existentes hoje no sistema.

A parte de divisão também irá abranger o nível de escopo, para facilitar a codificação e demais atividades inerentes que irão fazer parte e que necessitam de maior atenção para o sucesso do requisito no final das atividades.

Mensagens e textos pré-formatados no Portal

Com a grande quantidade de informação que será exibida aos usuários durante o acesso no portal – bem como os alertas – e visando uma maior simplificação no processo, permitindo a personalização por parte do cliente, as mensagens e textos de maior importância deverão usar a função PLSRETMSG(), que está localizada no fonte PLSXFUN.

Essa função permite cadastrar mensagens diversas na Tabela BMV – Mensagens do Portal e depois retornar para a página, permitindo uma flexibilização e maior personalização por cliente, pois o princípio é como o arquivo de tradução do Protheus (arquivos .ch), onde temos um código para uma string e podemos buscá-la a partir deste código e do código do portal acessado.
Porém, será necessário alterar a função, para evitar requisições desnecessárias a WebServices, buscando as strings no Banco de dados , na tabela BMV. Para isso:

• Alterar a função PLSRETMSG(), para que o usuário ao se logar, seja identificado o portal que está acessando e possamos armazenar numa session as strings referentes ao portal logado, fazendo com que elas permaneçam na sessão e possam ser utilizadas a qualquer momento, sem a necessidade de novas buscas no Banco de Dados.
  Isso economiza requisições desnecessárias no banco de dados e torna o processo mais rápido. 

Lembramos que apenas mensagens críticas e importantes devem ser utilizadas nesta tabela, para evitar sobrecarga numa session.
OBS 1: Essa parte será muito utilizada no item Primeiro acesso, pois será necessário emitir vários alertas que poderão ser alterados a qualquer momento pela Operadora. 

Documentos

Como dito, é vital a inclusão de anexos no processo de manutenção dos beneficiários no portal. Porém, devido a algumas necessidades especificas, será necessário alterar algumas rotinas existentes hoje, bem como realizar a inclusão de novas tabelas.

1. Criação da tabela B2O – Tipos de Documentos (o alias já encontra-se reservado no Trello para este fim).
2. Esta tabela terá os campos:
   1. B2O_FILIAL
   2. B2O_SEQUEN
   3. B2O_DESCRI
      (No final do documento – seção Dicionário de Dados – será informado tamanho e características dos campos)
3. Essa tabela tem como objetivo armazenar os tipos de documentos – como por exemplo – Documento de Representação, Documento de Inclusão, Autos e outras classificações.
4. Alterar a tabela BD2 - Documentos, devido a necessidades especificas na análise documental:
   1. BD2_TIPDOC - Campo consulta F3 (B2OTPDOC) com referencia a tabela B2O.
   2. BD2_INDAUT - Indicativo de para forçar o atendimento. 
      No caso, para cada documento na tabela BD2, teremos que associar o tipo do documento, conforme cadastro na nova tabela B2O. Já o campo BD2_INDAUT serve para informar se o documento forçar um atendimento, como um Mandado de Segurança, Ordem Judicial e outros.
5. Alterar a tabela BCP - Documentos dos usuários, incluindo os seguintes campos:
   1. BCP_DATINC - Data de Inclusão do documento
   2. BCP_DATVAL - Data de Validade do Documento

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. 

Dicionário de Dados

Tabela B2O - Tipos de Documentos (Criação):

Tabela BCP - Documentos x Usuários (Alteração):

Tabela BD2 - Documentos (Alteração):

Tabela BTS - Vidas (Alteração):

Tabela B2N - Inclusão de Vidas Portal (Criação - Já reservado no Trello):

Conforme especificação (ER_PCREQ-6467_Manutencao_Beneficiarios_Portal_Remote_PARTE IV (Inclusão)), essa tabela deverá possuir os campos citados abaixo e possuir as mesmas características de seus campos correspondentes nas tabelas BTS - Vidas e BA1 - Beneficiários. Os campos não serão citados aqui, pois no momento da criação, o desenvolvedor deverá olhas as características existentes no ATUSX (repositório oficial das informações sobre campos). Por isso, será necessário apenas alterar o alias da tabela e manter o sufixo, como por exemplo: BTS_NOMUSR e na tabela B2N deverá ser criado como B2N_NOMUSR.
Iremos descrever apenas os campos exclusivos da tabela, pois os demais deverão ser cópia fidedigna do ATUSX:

• Nome (BTS_NOMUSR)
• Tipo de beneficiários* (BA1_TIPUSU): T – Titular / D – Dependente (cadastro de usuário do Protheus)
• Grau de Parentesco* (BA1_GRAUPA): Cadastro de grau de parentesco do Protheus
• Descrição do grau de parentesco*
• CPF (BTS_CPFUSR)
• Data de Nascimento (BTS_DATNAS)
• Sexo (BTS_SEXO)
• RG (BTS_DRGUSR)
• Órgão Emissor (BTS_ORGEM)
• Estado Emissor (BTS_RGEST) – Deve ser em formato de lista ou pesquisa
• Estado Civil (BTS_ESTCIV)
• CEP (BTS_CEPUSR) : Deve pesquisar a tabela de CEP do Protheus.
• Endereço (BTS_ENDERE)
• Número (BTS_NR_END)
• Complemento (BTS_COMEND)
• Bairro (BTS_BAIRRO)
• Código do Município (BTS_CODMUN)
• Descrição do município (BTS_MUNICI)
• Estado (BTS_ESTADO) - Com opção de busca
• Telefone (BTS_TELEFO)
• Banco (BTS_BANCO)
• Agência (BTS_AGENC)
• Conta (BTS_CONTA)
• E-mail (BTS_EMAIL)
• Nome da Mãe (BTS_MAE)
• Nome do Pai (BTS_PAI)
• Data de Casamento (BA1_DATCAS)
• Data de Adoção (BTS_DATADT)
• Data de Óbito (BTS_DATOBI) – Deve ficar editável apenas na alteração, jamais na inclusão)
• Universitário (BTS_UNIVER)
• Invalido (BTS_INVALI)
• Tipo de Comunicação (BTS_COMUNI)
• Número do cartão Nacional de Saúde (BTS_NRCRNA)

Tabela BBA - Cabeçalho Solicitações Beneficiários (Alteração):

Tabela B4G - Passos da Análise (Alteração):

Tabela B5G - Passos x Analise (Alteração):

Parâmetros

Consulta Padrão

Consulta B2OTPD - para o campo BD2_TIPDOC

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.

Telas

Se faz necessário realizar o entendimento e a criação deste campo de relacionamento, para que possamos saber no momento de aceite da vida no sistema, na tela de análise, qual empresa, contrato e subcontrato está atrelado a vida e seus dependentes, pois atualmente, na tabela BTS, não encontramos estes campos.