Histórico da Página
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Informações Gerais
Especificação | |||
Produto | Microsiga Protheus | Módulo | Plano de Saúde - SIGAPLS |
Segmento Executor | Saúde | ||
Projeto | M_SAU_PLS003 | IRM | PCREQ-6465 |
Requisito | PCREQ-6467 | Subtarefa | PCSFV-11 |
Release de Entrega Planejada | 12.1.9 | Réplica | Não |
País | ( X ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros | Devido a complexidade das mudanças necessárias, a especificação foi dividida em 4 partes. Está é a parte IV (III de VII) |
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
- 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).
- Para acessar o layout genérico, acesse: Miscelanea -> Genérico -> Layout Genérico (fonte PLSCADLAY).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 em ER_PCREQ-5677_rotina_generica_upload_de_arquivos
- 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.
- 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.
- Se o usuário clicar em Continuar Depois, o status do protocolo (BBA_STATUS) deverá ficar com o status Pendente Documentação.
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).
- 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.
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.
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
Figura 1 - Tela de montagem de Layout genérico (exemplo)
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|