ER_PCREQ-6467_Manutencao_Beneficiarios_Portal_Remote_PARTE VI (Exclusao)

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.

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.

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). 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 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.
      
   5. Antes de permitir a exclusã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 solicitação de uma nova exclusão. Se acontecer, deve 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 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.

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

Figura 1 - Tela de Layout genérico, com a tela para criação da opção da página de Exclusão.