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.  

OBS: O método de envio de anexos deve ser padrão em todo requisito. Conforme já mencionado nas outras partes, o método de envio de anexos deverá ser uniforme em todas as telas, ou seja, o funcionamento deverá ser igual. Assim, após a escolha se será aberta uma nova janela para anexos ou uma div na página, isso deverá ser compartilhado para as demais partes que necessitam realizar upload.

2.2) Manutenção de Beneficiários

1. Para acessar o layout genérico, acesse: Miscelanea -> Genérico -> Layout Genérico (fonte PLSCADLAY). Para maiores informações e uso do Layout genérico, consultar o documento: http://tdn.totvs.com/download/attachments/192100986/PCREQ5309_SIGAPLS_BT_DES.doc?version=1&modificationDate=1437071788000&api=v2 e a especificação ER_PCREQ2981_Alteração_Cadastral_da_RDA_no_Portal).
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 (Visualizacao)). 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). 
8. Antes de permitir a edição, o sistema deve validar se já não existe algum protocolo para este beneficiário em andamento. Se existir, não deve permitir novamente a edição dos dados e informar o usuário que já existe uma solicitação de alteração para este beneficiário e que caso sejam outras alterações, terá que esperar que as primeiras sejam validadas.
   
9. 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.

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

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

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 - Tela de Layout genérico da Manutenção de usuários. Note as configurações complementares (LOG, VALIDA e MOTIVO) 

(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>.