Histórico da Página

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

Iremos tratar sobre a página de Manutenção de usuários, ou seja, a página para modificação de beneficiários já existentes e cadastrados no sistema. Essa página também irá utilizar o layout genérico, devido a flexibilidade oferecida para o desenvolvedor e cliente. 

2.2) Manutenção de Beneficiários

1. Para acessar o layout genérico, acesse: Miscelanea -> Genérico -> Layout Genérico (fonte PLSCADLAY).
2. Na tela de layout genérico, clique no botão Incluir e no campo Chave de Busca, preencher com o nome PPLMANBEN. Isso significa o nome do nosso formulário de manutenção.Em Grupos de Campos, adicionar a tabela BA1 – Beneficiários, pois a vida já é um beneficiário e os dados necessários para alteração são os mesmos que usamos na tela de inclusão. Assim, devem ser exibidos apenas os campos demonstrados no item de inclusão de beneficiários, nenhum campo a mais
   1. Lembrando que a tela de manutenção será aberta a partir do grid de exibição de beneficiários (veja em ER_PCREQ-6467_Manutencao_Beneficiarios_Portal_Remote_PARTE III (ManutencaoVisualizacao)). Logo, será necessário passar o RECNO do registro, para abrir a tela com todos os dados preenchidos do usuário selecionado, para manutenção.
3. No Layout genérico, com relação a tela de manutenção, devemos definir alguns campos como chave para análise da Operadora, quando são alterados e que devem ser analisados, antes de serem gravados.
   • Como exemplo, toda vez que o campo BA1_CPFUSR for alterado, quero validar esta alteração.
   • Então, devemos clicar no grid Campos da tela de layout, selecionar o BA1_CPFUSR e depois, no item Configurações Complementar, digitar VALIDA no campo Variável (B2C_VAR) e o no campo Valor (B2C_VALOR), inserir o valor .T..  Isso significa que caso o usuário altere o campo CPF, ele não será gravado na tabela BA1, mas sim, será gravado em outra tabela para análise (iremos utilizar a tabela B7L para esta função).
   • É possível também informar que determinado campo se alterado, deverá ser gravado log da alteração, mas sem necessidade de análise. Para isto, no campo Variável (B2C_VAR), digitar LOG e no campo Valor (B2C_VALOR), entrar com o valor .T..
   • Dependendo do campo, a Operadora pode dizer que é obrigatório o anexo de algum documento, para análise. Por isso, no campo Variável(B2C_VAR) devemos inserir uma variável de nome MOTIVO. Como exemplo, o campo BA1_ESTCIV, que o usuário mudou de Solteiro para casado. A operadora pode pedir a certidão de casamento ou contrato de matrimônio, para validar esta alteração.  Essa variável terá como valor (campo B2C_VALOR) o sequencial da tabela B9G – Motivo Solicitação Contratual. No fonte PLSA727, temos o cadastro destes motivos, onde podemos inserir um motivo com descrição qualquer e na sequência, informar que é necessário um documento – que será buscado da tabela BD2. Desta forma, quando o usuário salvar as alterações, será apresentado a tela de anexos, para que possa inserir o anexo solicitado.
     No nosso caso, também precisamos criar uma variável do tipo MOTIVO – no campo Variável. Contudo, para usar este recurso, será necessário informar no campo VALOR o sequencial da tabela Motivos xxxx, que é a tabela responsável onde inserimos um motivo e o documento que deve ser anexado.
     Para maiores informações sobre estes campos, consultar o documento  ER_PCREQ-2981_Alteracao_cadastral_da_RDA_no_portal.
4. Para que seja possível a validação dessas variáveis informadas (VALIDA, LOG e MOTIVO), será necessário no campo FUNC PRE VAL da tela de layout, inserir o nome da PLSMNPREB(), que deverá ser criada no fonte PLFUNCADGE.
   • A função PLSMNPREB irá manipular o array dos dados da página e deverá validar se existem campos com as variáveis, para gravar na tabela de LOG, caso a opção LOG esteja ativa, bem como para validação posterior do campo na tela de análise, caso a variável VALIDA esteja presente. Além disso, é necessário o tratamento quando queremos analisar determinado campo (VALIDA igual a .T.), pois este campo deve ser removido do array de dados da gravação e inserido em outro, para gravação na tabela B7L.
   • Para exemplo de caso prático de funcionamento, no fonte PLFUNCADGE existe a função PLSALTCPRE(). O funcionamento é idêntico ao descrito aqui, devendo a função ser adaptada para a necessidade deste requisito, bem como para o alias da tabela correta e demais ajustes.
5. Quando o formulário for salvo, teremos que criar um registro na tabela BBA, indicando que houve alteração nesta data. Porém , poderá ocorrer duas situações:
   • Se não houver qualquer tipo de validação em nenhum campo, todas as alterações serão salvas diretamente na BA1.
   • Se houver a necessidade de validação de qualquer tipo, todas as alterações serão salvas na tabela B7L - Cadastro de LOG de alteração do layout genérico. Ou seja, caso algum campo com opção de validação esteja sendo alterado, a mudança não será gravada diretamente na tabela BA1, mas sim, na tabela B7L, que será exibida para o usuário da análise, os registros serão vinculados pelo campo B7L_CHAVE. Novamente, para informações e exemplo de uso dessa funcionalidade, veja o documento ER_PCREQ-2981_Alteracao_cadastral_da_RDA_no_portal. Ou seja, toda alteração que for realizada num campo que deve ser validado, será salvo na tabela B7L, onde o usuário no remote irá visualizar as alterações e em caso de Aprovação, irá aceitar e elas serão replicadas para a tabela BA1.  Ou seja, no caso de haver campos com validação  outros sem, os que não possuem serão salvos diretamente na tabela BA1 e os outros que necessitam, serão salvos na tabela B7L.
6. Lembramos que se houver a necessidade de anexos (conforme definição de algum campo, como explicado no item 5), a tela de anexos deverá ser aberta (manter o padrão adotado na Inclusão – uma nova janela ou então, uma div). Os documentos deverão ficar atrelados a tabela BA1, conforme existe hoje no Protheus.
   1. Caso o usuário não adicione nenhum anexo, no protocolo (tabela BBA), o campo status (BBA_STATUS) ficará como Pendente Documentação.
   2. Caso não haja nenhuma obrigatoriedade de documentos ou foi adicionado algum, o campo BBA_STATUS ficará como Análise.
7. O campo BBA_TIPMAN deve receber o valor 2, pois se trata de uma manutenção (alteraçã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.

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

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.