Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

 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.


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á 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 Depoiso 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*/

  

Índice

Chave

01

<FI9_FILIAL+FI9_IDDARF+FI9_STATUS>

02

<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF>

03

<FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO>

Campo

<AAA_PERESP>

Tipo

<N>

Tamanho

<6>

Valor Inicial

<Varia de acordo com o tipo informado. Por exemplo, quando o campo “tipo” for date, neste campo pode ser informado uma data>. 

Mandatório

Sim (  ) Não (  )

Descrição

<Referência Mínima para Cálculo>

Título

<Ref.Calc.>

Picture

<@E999.99>

Help de Campo

<Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação>

 

(Opcional)

Grupo de Perguntas

 

<Informações utilizadas na linha Protheus>.

 

Nome: FINSRF2

X1_ORDEM

01

X1_PERGUNT

Emissão De

X1_TIPO

D

X1_TAMANHO

8

X1_GSC

G

X1_VAR01

MV_PAR01

X1_DEF01

Comum

X1_CNT01

'01/01/08'

X1_HELP

Data inicial do intervalo de emissões das guias de DARF a serem consideradas na seleção dos dados para o relatório 

 

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

 

Consulta: AMB

Descrição

Configurações de Planejamento

Tipo

Consulta Padrão

Tabela

“AMB”

Índice

“Código”

Campo

“Código”; ”Descrição”

Retorno

AMB->AMB_CODIGO

 

(Opcional)

Estrutura de Menu

 

<Informações utilizadas na linha Datasul>.

 

Procedimentos

 

Procedimento

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Módulo

 

 

 

Programa base

 

 

 

Nome Menu

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Registro padrão

Sim

Sim

Sim

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Release de Liberação

 

 

 

 

 

 

Programas

 

Programa

 

 

 

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Nome Externo

 

 

 

Nome Menu/Programa

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Nome Verbalizado[1]

(Max 254 posições)

(Max 254 posições)

(Max 254 posições)

Procedimento

 

 

 

Template

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

Tipo[2]

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Categoria[3]

 

 

 

Executa via RPC

Sim/Não

Sim/Não

Sim/Não

Registro padrão

Sim

Sim

Sim

Outro Produto

Não

Não

Não

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Query on-line

Sim/Não

Sim/Não

Sim/Não

Log Exec.

Sim/Não

Sim/Não

Sim/Não

Rotina (EMS)

 

 

 

Sub-Rotina (EMS)

 

 

 

Localização dentro da Sub Rotina (EMS)

 

 

 

Compact[4]

Sim/Não

Sim/Não

Sim/Não

Home[5]

Sim/Não

Sim/Não

Sim/Não

Posição do Portlet[6]

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

Informar os papeis com os quais o programa deve ser vinculado

 

 

 

 

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

 

Código Papel

(máx 3 posições)

Descrição em Português*

 

Descrição em Inglês*

 


[1] Nome Verbalizado é obrigatório para desenvolvimentos no Datasul 10 em diante.

[2] Tipo é obrigatório para desenvolvimento no Datasul 10 em diante

[3] Categorias são obrigatórias para os programas FLEX.

[4] Obrigatório quando o projeto for FLEX

[5] Obrigatório quando o projeto for FLEX

[6] Obrigatório quando o projeto for FLEX

 Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico.