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

Nesta parte, iremos tratar sobre a exclusão do beneficiário. Na verdade, o processo será exclusão para o usuário que está solicitando, mas para o sistema, o usuário será bloqueado, pois caso o registro deste beneficiário seja excluído realmente da base dados, iremos perder as referências e integridade. Logo, sempre que o usuário solicitar uma exclusão, no sistema iremos tratar como um bloqueio.

Exclusão de beneficiários

Quando na tela de manutenção de usuários a opção escolhida for Exclusão, devemos proceder da seguinte maneira:

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 PPLEXCBEN. Isso significa o nome do nosso formulário de exclusão.
3. 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
4. Como se trata de uma exclusão – que na verdade, no sistema, será tratado como bloqueio – todos os campos deverão ter a propriedade VALIDA como .T., para que não seja alterado nada no sistema e passe por análise do operador.
5. Para que seja possível a validação dessas variáveis informadas (VALIDA, LOG e MOTIVO), será necessário no campo FUNC PRE VAL informar uma função de pré-validação, como a função PLSMNPREB() (verificar se pode usar a mesma, conforme desenvolvimento ou criar uma nova), no fonte PLFUNCADGE (função criada na Parte V ddesta especificação, para a parte de manutenção ER_PCREQ-6467_Manutencao_Beneficiarios_Portal_Remote_PARTE V (Manutencao)).
   1. A função PLSMNPREB ou outra 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.
   2. 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.
6. No final do processo, será necessário gerar e exibir o relatório Formulário de Movimentação de Beneficiários.
   1. Para emitir o relatório, no layout genérico, será necessário criar uma função para esse fim, a PLSRLBENF(), no fonte PLFUNCADGE.
   2. 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:
   1. Forma tradicional, com FWMSPrinter ou outra similar, que pode ser reaproveitada depois no remote;
   2. 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: Essa proposta de relatório já foi discutida na parte IV desta especificação. Logo, basta criar apenas uma função, diferenciando quando se trata de Inclusão, Alteração ou Exclusão, para que o relatório seja gerado (ER_PCREQ-6467_Manutencao_Beneficiarios_Portal_Remote_PARTE IV).
8. Nesta tela, 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).
   1. Se o usuário clicar em Continuar com Anexo, os anexos ficarão vinculados a tabela BA1 e a chave será conforme padrão adotado no Protheus , 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
   2. Se não for anexado nenhum documento, será necessário atualizar o status do protocolo (BBA_STATUS) como Pendente Documentação. Se for anexado um ou mais documentos, o campo de status do protocolo ficará como Em Análise.
   3. Se o usuário clicar em Continuar Depois, o status do protocolo (BBA_STATUS) deverá ficar com o status Pendente Documentação.
   4. O campo BBA_TIPMAN deve ser atualizado com o valor 3, pois a operação se trata de uma exclusão.
      
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 co 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

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