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.

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.

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-2981PCREQ2981_AlteracaoAlteração_cadastralCadastral_da_RDA_no_portalPortal).
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 (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.
     Tanto no Portal Empresa e Beneficiário, se não houver nenhum registro de beneficiário cadastrado, significa que não existe beneficiários no Plano. Assim, a primeira inclusão deve ser do titular do plano, para em seguida, incluir os dependentes. Assim, de acordo com o login (também é possível criar um controle para verificar se trata de primeiro acessou ou outro método), verificar se a vida existe no cadastro da tabela BTS. Se sim, quando clicar no botão Incluir novo beneficiário, os campos da página de inclusão deverão carregar os dados que estão na vida da tabela BTS, marcando este como titular, para facilitar ao usuário. Somente depois da inclusão do titular, permitir a inclusão dos dependentes. Somente após a inclusão do titular e quando estiver incluindo dependentes, poderá editar o campo grau de parentesco.
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 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 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 xxxxem ER_PCREQ6213_Rotina_Genérica_Upload_de_Arquivos
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_PCREQ6468_SolicitacaoSolicitação_de_adesaoAdesão_a_Opcionais_viaVia_Portal, que ainda encontrava-se em desenvolvimento. Assim, talvez seja necessário mais ajustes para o correto funcionamento.
11. O usuário só pode realizar uma única  inclusão de CPF, ou seja, sempre que for inclusão, será necessário verificar se já não existe  alguma inclusão pendente para ela, na tabela B2N. 
12. 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

<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 montagem de Layout genérico (exemplo)

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