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. 

Definição da Regra de Negócio

Aqui, iremos tratar sobre a página de Inclusão de novos beneficiários - que será gerada usando o layout genérico. Iremos tratar sobre quais são as necessidades especificas para a Inclusão, que terá um processo diferenciado das demais páginas, devido a necessidade do uso da tabela temporário B2N, que será usada para análise dos usuários da Operadora, para aceite ou não da vida em questão. A tabela B2N está detalhada na Parte I desta especificação.

Inclusão de Beneficiários

1. Após a criação da tabela, será necessário criar a página no Layout genérico disponível no Protheus (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_PCREQ-2981_Alteracao_cadastral_da_RDA_no_portal).
2. Para acessar o layout genérico, acesse: Miscelanea -> Genérico -> Layout Genérico (fonte PLSCADLAY).
3. Na tela de layout genérico, clique no botão Incluir e no campo Chave de Busca, preencher com o nome PPLINCNBEN. Isso significa o nome do nosso formulário que será aberto para inclusão.
4. Em Grupos de Campos, adicionar a tabela B2N e na coluna tipo, colocar como Grupo de Dados. Automaticamente, todos os campos da tabela serão exibidos abaixo.
5. No cadastro do layout genérico, será necessário no campo FUNC PRE VAL, inserir uma função de validação, pois após a gravação de um registro, será necessário exibir um alerta (modalBs), indagando ao usuário se deseja incluir mais dependentes no plano.
   • Se a resposta for Sim, será necessário exibir o formulário novamente, para a inclusão de um novo beneficiário.
   • Se a resposta for Não, será necessário gerar o registro dessa solicitação (o protocolo) na tabela de Cabeçalho de Solicitação beneficiário - BBA. Ao gerar o protocolo na BBA, o número do protocolo gerado pela tabela BBA deverá  (BBA_CODSEQ)deverá ser replicado para todos os itens da solicitação, no campo B2N_PROTOC, para que fiquem atrelados. 
   • O campo BBA_TIPMAN deverá ficar com o valor 1, pois se trata de uma inclusão.
   • O campo BBA_TIPSOL deverá ficar com o valor 2, pois se trata Inclusão/Manutenção.
6. Quando o usuário não desejar mais incluir beneficiários – ou seja, selecionou a opção Não na janela de alerta, será necessário gerar e exibir o relatório Formulário de Movimentação de Beneficiários.
   • Para emitir o relatório, no layout genérico, será necessário criar uma função para esse fim, a PLSRLBENF(), no fonte PLFUNCADGE.
   • A função PLSRLBENF() deve ser colocada no campo FUNC POS VAL, do layout genérico, pois ela será disparada após a gravação dos dados.
7. Contudo, temos duas formas de gerar esse relatório, descritos abaixo:
   • Forma tradicional, com FWMSPrinter ou outra similar, que pode ser reaproveitada depois no remote;
   • Arquivo .APH, da WEB.
     Caso seja via APH, será necessário criar um APH com o nome do relatório (exemplo PLFRMMBEN.APH) e criar uma web function no PPLCMBEM, que irá chamar o relatório, podendo personaliza-lo via css e outras formatações WEB.
     OBS: Pode-se encontrar um exemplo da função na Web Function PLSIMPOPC, no PPLMFUN.
     OBS 2: De acordo com a escolha de geração do relatório, deverá ser genérico, pois será usado em outras movimentações, pois também deverá ser gerado quando se trata de Exclusão. Logo, será necessário diferenciar pelo tipo de movimentação como esse relatório será gerado.
8. Nesta tela de relatório, devemos ter dois botões, Continuar com Anexos (indica que o usuário imprimiu e deseja continuar) e Continuar Depois (caso o usuário deseje continuar depois).
   • Se o usuário clicar em Continuar com Anexo, os anexos ficarão vinculados a tabela B2N e a chave será o número de Protocolo gerado mais o CPF do titular, de modo que seja possível a visualização no remote e o armazenamento correto no Banco de Conhecimento. O usuário poderá anexar um ou mais documentos.
     OBS: Utilizar a rotina genérica de inclusão de anexos, onde o desenvolvedor poderá escolher se será aberta uma janela normal no portal ou então, uma div, com a mesma funcionalidade.  Para verificar o funcionamento da rotina genérica, veja xxxx
9. Se não for anexado nenhum documento, será necessário atualizar o status do protocolo (BBA_STATUS - verificar OBS 1), como Pendente Documentação. Se for anexado um ou mais documentos, o campo de status do protocolo ficará como Em Análise.
10. Se o usuário clicar em Continuar Depois, o status do protocolo (BBA_STATUS) deverá ficar com o status Pendente Documentação.

    1. OBS 1: Para realizar o controle das solicitações realizadas via portal, iremos utilizar a tabela BBA – Cabeçalho das solicitações. Toda vez que o usuário terminar de incluir os dependentes – pois irá clicar no alert que não deseja mais – será necessário inserir um registro dessa solicitação na tabela BBA, para gerar um número de protocolo e em seguida, replicar este número de protocolo para o campo B2N_PROTOC para todos os registros inseridos nesta solicitação, para controle e relacionamento entre BBA x B2N (Cabeçalho x Itens).

    2. No entanto, o desenvolvedor quando for atuar neste item, deverá observar outras características, pois no momento dessa especificação, tratava-se de uma tabela criada para o requisito ER_Solicitacao_de_adesao_a_Opcionais_via_Portal, que ainda encontrava-se em desenvolvimento. Assim, talvez seja necessário mais ajustes para o correto funcionamento.

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