Informações Gerais

Objetivo

Simplificar o processo de parametrização de preço para o faturamento de pré-pagamento, visando melhorar a usabilidade do processo.

Eliminar os GAPs existentes em relação ao unicoo permitindo as seguintes funcionalidades:

- Faixa etária diferenciada para módulos opcionais.

- Valores diferenciados por usuário dentro de um mesmo grau de parentesco, para planos não regulamentados e/ou liminares judiciais.

- Consultar o valor por grau/faixa de forma simples. 

Definição da Regra de Negócio

Desenvolvimento de interface de parametrização das Regras de Mensalidade de Pré-pagamento.

Será desenvolvida a “Manutenção de Regras de Mensalidade de Pré-Pagamento”.

Esta  manutenção deverá ser desenvolvida em “progress”, porém o código da mesma deverá ser estruturado de forma que a interface e a regra de negócio fiquem separadas para possibilitar o reaproveitamento do código para uma futura conversão em HTML5 (programa progress de interface, fachada, e bo).

Esta nova manutenção será composta por uma tela principal de busca de registros (mesmo padrão das telas metadados), contendo os campos: “Código da Regra”, “Descrição da Regra”, “Tipo de Índice”, “Data de Inicio” e “Data Fim”. Verificar  “protótipo de interface”.

Ao acessar as opções de “Detalhar”, “Adicionar” e “Modificar”, será exibida interface separada por “abas”: “Detalhes da Regra”, “Critérios da Regra”, “Estruturas da Regra” e “Reajuste” onde será possível realizar toda a parametrização de  valores do faturamento.

Abaixo detalhamento do comportamento e interface de cada uma das abas:

Detalhes da Regra (protótipo de interface)

Tabela: regra-menslid

              Nesta aba serão detalhadas informações cadastrais da regra:

                - Descrição: Descrição Informativa da regra.

                - Vigência: Inicial e Final.

                - Tipo de Indice: conforme o cadastro de “tipo de índice”, deverá existir zoom para esta opção.

                - Tipo Regra: Este campo servirá para filtros apenas.

                - Observações: informativo.

Critérios da Regra (protótipo de interface)

Tabela: regra-menslid-criter

Tabela Histórico: menslid-criter-histor

Nesta aba são definidos os critérios da rega, que influenciarão diretamente no valor de mensalidade do beneficiário.

Os campos são:

- P.C. (Padrão de Cobertura) : Caso exista fator diferenciado por padrão de cobertura, este deverá ser informado, senão não há necessidade. (Deverá existir zoom para esta funcionalidade)

- Mod (Módulo) : Informação obrigatória, deverá ser informado o módulo de consulta para mensalidade e os módulos opcionais. (Deverá existir zoom para esta funcionalidade)

- Grau de Parentesco: Deverá ser informado “0” para todos os graus de parentesco ou especificado o grau de parentesco.  (Deverá existir zoom para esta funcionalidade)

- Faixa Etária: Informação obrigatória, devem ser informadas as faixas etárias (faixa, idade inicial e idade final) dos módulos de cobertura (mensalidade e opcionais) para composição do preço.

- Vlr. Mens (Valor de Mensalidade) : Valor da mensalidade para o Padrão de Cobertura (quando aplicado) X Modulo X Faixa Etária.

- Vl. TX. Insc (Valor da Taxa de Inscrição): Valor da taxa de inscrição mensalidade para o Padrão de Cobertura (quando aplicado) X Modulo X Faixa Etária.

- Fator de Repasse: Fator ao qual o valor de mensalidade será multiplicado quando o beneficiário estiver repassado. Por padrão é informado “1.0000”.

- Data Inic/Data Fim – Vigência do critério.

OBS: mesmo existindo vigência nos critérios, todos os campos poderão ser editados, porém o sistema realizará o histórico de todas as alterações realizadas.

Regras de preenchimento e validação dos campos:

- P.C – Preenchimento opcional, se informado o valor informado deve existir na tabela “pad-cob”

- Módulo – Preenchimento obrigatório, o valor informado deve existir na tabela “mod-cob”.

- Grau Parentesco - Preenchimento obrigatório, pode ser informado “0” que representa todos os graus de parentesco ou informado um grau em especifico (Que deverá existir na tabela gra-par).

- Faixa etária: Código sequencial por “P.C”/”Módulo”/”Grau de Parentesco” / “Data Validade’.

- Numero de beneficiário Inicial e final: A quantidade de beneficiários inicial e final que o critério se aplica. 

Exemplo :

Se informado de forma incorreta o sistema não deverá permitr, gerando erro.

- Idade Inicial e Idade Final: A idade inicial não poderá ser maior que a final. Não poderá existir sobreposição de idades entre faixas etárias diferentes dentro de um mesmo “PC/Mód/GrauPar/validade”.

Abaixo exemplo, em vermelho situação em que o sistema não deve permitir:

- Valor Mensalidade, Valor Taxa Inscrição – Informação livre de valor, formatar em reais.

- Fator de Repasse – Informação livre de valor.

- Data Inicio e Fim de Vigência – a data de fim não poderá ser menor que a data de inicio.

OBS: Ao salvar todo o registro de regra de mensalidade, o sistema deverá validar se existem lacunas de idade  no cadastro de critérios de mensalidade, informar para o usuário as lacunas (em um grid com todas as existentes) e permitir salvar o registro caso usuário deseje prosseguir mesmo com as lacunas.

Exemplo lacunas:

- Não existe registro para idade “19” anos com padrão de cobertura.

- Deverá existir opção “Copiar de” ao lado do histórico, quando selecionado esta opção o sistema permitirá realizar a copia dos critérios ativos de outra regra de mensalidade, a fim de facilitar a parametrização.

- O sistema permitirá alterar e excluir informações livremente dos critérios, porém cada informação alterada ou excluída gerará um registro de histórico. A tabela de histórico, possui os mesmo campos da tabela de critérios apenas adicionando os seguintes campos:

                               - Tipo Alteração: A – Alteração, E – exclusão:

                               - Data Alteração: Data em que registro foi alterado.

                               - Hora Alteração: Hora que o registro foi alterado.

                               - Usuário Alteração: Usuário que realizou a alteração.

                               - idi-seq: sequencial por cdd-id.

Ao clicar no botão histórico, sistema deverá exibir grid com o histórico de alterações e exclusões.

Estruturas da Regra (protótipo de interface)

Tabela: regra-menslid-estrut

Tabela histórico: menslid-estrut-histor

 Nesta aba serão definidas as estruturas/contratos e usuários ao qual a regra poderá ser aplicada.

Poderão ser informados: Modalidade, Plano, Tipo Plano, Contrato e usuário.

A informação poderá ser da seguinte maneira:

O sistema permitirá o cadastramento de dois níveis iguais para regras de mensalidade diferente:

Para definição de qual regra será utilizada, o sistema realizará a atribuição da mesma na manutenção do contrato.

Será permitido a edição deste cadastro, porém o sistema realizará controle histórico de todas as alterações.

Para todos os campos deverá existir zoom.

Validação de dados:

- Se informado valor diferente de zero, deverá ser:

   - Modalidade: validado com a “modalid”.

   - Plano: validado com a “pla-sal”. (somente poderá ser informado se a modalidade for informada)

   - Tipo de Plano: validado com a “ti-pl-sa”. (somente poderá ser informado se o plano for informado

   - Proposta: validado com a “propost”. (somente informado se a modalidade estiver informada e o plano não)

   - Usuário: validado com a “usuário”. (somente poderá ser informado se a proposta for informada)

   - Data Inicio e Fim de Vigencia – a data de fim não poderá ser menor que a data de inicio.

- O sistema permitirá alterar e excluir informações livremente das estruturas, porém cada informação alterada ou excluída gerará um registro de histórico. A tabela de histórico, possui os mesmso campos da tabela de critérios apenas adicionando os seguintes campos:

                               - Tipo Alteração: A – Alteração, E – exclusão:

                               - Data Alteração: Data em que registro foi alterado.

                               - Hora Alteração: Hora que o registro foi alterado.

                               - Usuário Alteração: Usuário que realizou a alteração.

                               - idi-seq: sequencial por cdd-id.

Ao clicar no botão histórico, sistema deverá exibir grid com o histórico de alterações e exclusões.

Reajuste (Potótipo de Interface)

Tabela: regra-menslid-reaj

Tabela Histórico: mesalid-reaj-histor

Nesta aba será possível informar os seguintes campos:

-  Ano/Mês: ano mês base do reajuste.

- Módulo: Módoulo de cobertura com zoom, podendo informar zero todos.

- Percentual de Reajuste

- Reajsutar contratos ativos por: nesse campo existirão três possibilidades, onde a possibilide por “Aniversario do modulo” somente poderá ser aplicada quando for informado módulo.

- Oficio ANS: informação livre, opcional.

-  Observações:  informação livre, opcional.

- O sistema permitirá alterar e excluir informações livremente dos reajustes, porém cada informação alterada ou excluída gerará um registro de histórico. A tabela de histórico, possui os mesmso campos da tabela de critérios apenas adicionando os seguintes campos:

                               - Tipo Alteração: A – Alteração, E – exclusão:

                               - Data Alteração: Data em que registro foi alterado.

                               - Hora Alteração: Hora que o registro foi alterado.

                               - Usuário Alteração: Usuário que realizou a alteração.

                               - idi-seq: sequencial por cdd-id. 

Alterações Programas para utilização do novo faturamento

• Parâmetros do Faturamento

Será adicionado o frame “Regras Mensalidade Pre-Pagamento”, neste frame existirão os seguintes campos:

- “Utilizar Regras Mensalidade Pre-Pagamento” (parafatu.char-25), este campo deverá ser um “option-box” contendo as seguintes Opções:

“S – Sempre” (“S”)

“C – Denifido no Contrato” (“C”)

“N – Não Utilizar” (“N”)

- “Data Inicio Utilização” (parafatu.date-1), este campo somente poderá ser informado se o parâmetro anterior possuir valor igual “S”. Neste campo somente poderá ser informada data superior a data corrente.

- “Tipo de Faturamento default inclusão contratos” (parafatu.log-19), sendo “Tabela de Preço dos Módulos” (“no”) e “Regras Mensalidade Pre-Pagamento” (“yes”). Esta opção somente poderá ser habilitada se o “parafatu.char-25” for igual a “C”.

Ao alterar um registro nesta parametrização, se o registro possuir o campo “parafatu.char-25” com valor igual a “S” e o parâmetro “parafatur.date-1” possuir uma data menor igual a data corrente o sistema não permitirá a alteração de nenhum dos campos desse frame, senão a alteração será livre.

Ao alterar um registro nesta parametrização, se o registro possuir o campo “parafatu.char-25” com valor igual a “C” somente será permitido alterar a informação do “log-19”. 

• Manutenção de Contratos:

Ao adicionar um contrato quando o parâmetro “parafatu.char-25” possuir valor:

“N” – Mantem processo igual ao atual.

“C”:

               - Na aba “Faturamento” sub-aba “Tabela de Faturamento” deverão existir os seguintes campos:

• “Utiliza Regras Mensalidade Pré-Pagamento” (propost.log-12), este campo deverá vir com o valor do campo “parafatu.log-19”, permitindo alteração
• Deverá existir o campo "Regra Mensalidade” este campo somente será exibido se “propost.log-12” for igual a “Sim”. Este campo possuirá opção de zoom e permitirá selecionar entre 

todas as regras de mensalidade que se aplicam ao contrato. Para definir quais regras podem ser utilizadas na proposta utilizar a seguinte regra:

• Verificar se existem regras associadas a proposta e retornar elas, caso encontre:
  
  
  
• Se não existir regra para proposta, verificar por estrutura:
  

Após exibir todas pedindo a seleção pelo usuário. 

Na manutenção de contratos deverá existir ainda opções para verificação do preço das faixas etárias e também para verificar histórico de alterações:

Para exibição do preço das faixas etárias deverá ser verificado o valor do critério da regra atualizando com os reajustes (no FP0910v  será explicado esta lógica):

Enquanto para exibição do histórico de regras, deverão ser exibidos os registros da tabela "regra-menslid-propost" vinculada a proposta

- “Reajuste de Mensalidade” (propost.log-13) contendo as opções “Regra de Mensalidade” e “Contrato”. O default será sempre “Contrato”. Este campo poderá ser editado via manutenção de contratos somente enquanto a proposta não possui contrato.

- Quando o campo “propost.log-12” possuir valor igual a “Sim” o campo “Tabela de Preços” deverá ficar desabilitada.

- Somente poderá ser alterado o valor do campo “propost.log-12” enquanto a proposta ainda não possui contrato (propost.nr-ter-adesao = 0).

- Quando o campo “propost.log-12” possuir valor igual a “Sim” a aba faixa etária especial não poderá ser exibida.

- Quando o campo “propost.log-12” possuir valor igual a “Sim” não deverá ser exibida na aba “Cobertura” sub-aba “Módulos de Cobertura” o campo “Valor” nos grids “Modulos Obrigatórios” e “Módulos Opicionais”.

“S”: mesmo comportamento de quando o valor for igual a “C” porém o campo “propost.log-12” não estará disponível.

Ao salvar o registro no banco de dados, o sistema deverá alimentar a tabela "regra-menslid-propost" vinculando a proposta e a regra escolhida.

Deverão ser alteradas as “APIs/BOs”, referente a inclusão de propostas para quando a proposta utilizar “Regra de mensalidade” o sistema não realize validações referentes a “tabela de preço”

• Parâmetros criação automática proposta (vp0220b)

Quando o parâmetro “parafatu.char-25” possuir os valores:

“N” – Mantem processo igual ao atual.

“C” / “S”

   - No frame “Tabelas da Proposta” adicionar:

- “Utiliza Regras Mensalidade Pré-Pagamento” (model-param-propost.log-livre-2), este campo deverá vir com o valor do campo “parafatu.log-19”, permitindo alteração.

Quando o “parafatu.char-25” for igual a “S” o campo “model-param-propost.log-livre-2” deverá ficar igual a “sim” sem  permitir alterar.

Se informado “Sim” neste campo, o campo “Tabela de preço” deverá ficar desabilitado.

- Deverá existir o campo “Regra Mensalidade” este campo somente será exibido se “model-param-propost.log-livre-2” for igual a “Sim”. Este campo será composto por código e descrição e não poderá ser editado.

O código da regra e descrição deverá ser buscado. (busca-regra-contrato)

- “Reajuste de Mensalidade Definido” (model-param-propost.log-livre-3) contendo as opções “Regra de Mensalidade” e “Contrato”. O default será sempre “Regra de Mensalidade”.

• Transferencia de Beneficiários:

Ao transferir um beneficiário o sistema deverá considerar para criação da proposta os campos “model-param-propost.log-livre-2” e “model-param-propost.log-livre-3” transferindo a informação respectivamente para “propost.log-12” e “propost.log-13”.

Quando o parâmetro “model-param-propost.log-livre-2” for igual a “yes” o sistema não deverá consistir a tabela de preços e tão pouco criar a faixa etária especial (teadgrpa).

• Manutenção de Beneficiário:

Quando a proposta do beneficiário utilizar o novo faturamento (propost.log-12), na aba “outras informações” da manutenção de beneficiário, deverá existir o campo “Regra Mensalidade” Este campo será composto por código e descrição, possuindo zoom e opções de verificação de histórico e valores da regra. 

Por default este campo será preenchido com o mesmo valor da proposta, sendo necessário alterar caso deseje assumir uma regra diferente da proposta para o beneficiário.

Ao clicar na opção de exibição de valores da regra será exibido colorido os critérios que o beneficiário se enquadra:

Ao salvar o registro do beneficiário, se a regra de mensalidade do beneficiário for diferente da regra de mensalidade do contrato, então deverá ser criado registro na "regra-menslid-propost" associado ao benef, senão não. 

Criação de API para cálculo do novo faturamento

Será desenvolvida nova API para realizar o cálculo do novo faturamento. Esta API deverá ser chamada por todos os processos de faturamento do sistema (simulação, geração, padrão de cobertura, faturamento complementar, desmembramento de faturas e alteração de vencimento). 

Esta rotina será chamada de "api-mens-pre-pagamento" e será rodada de forma persistente. A API possuirá três métodos principais: "api-mens-complementar", "api-desmembra-fatura" e "api-mens-pre-pagamento".

O fluxo de execução delas será semelhante, apenas variando conforme as diferenças funcionais entre cada tipo de faturamento possível. 

O fluxo de execução principal do faturamento de pré-pagamento deverá ser da seguinte forma:

• Validações iniciais: identificação do termo de adesão, próximo faturamento, verificação da data de término do termo, caso informado via parâmetro barrar a execução do faturamento caso possua beneficiário com data inferior ao último faturamento sem possuir faturamento complementar. 
• Identificação da regra de mensalidade que a proposta se enquadra.
• Criação de temporária com os reajustes a nível de proposta existentes.
• Leitura dos eventos parametrizados para estrutura, bem como verificação das contas contábeis e criação dos registros em uma tabela temporária que será utilizada no decorrer do fluxo.  Nesta leitura deverá ser criado registros na temp para eventos de todos os tipos: "impostos", "automáticos", "manuais", "taxa de inscrição", "nova via de carteira", "com módulo de cobertura vinculado",  "sem módulo". 
• Execução das rotinas especificas conforme criadas na temporária.
• Verificação dos percentuais de desconto e acréscimo da proposta para posterior utilização.
• Verificação da quantidade de meses faturados da proposta.
• Leitura de todos os usuários ativos da proposta no mês de referencia e para cada usuário verificar:
  • Verificar se existe regra de mensalidade a nível de usuário.
  • Verificar se o beneficiário é recém nascido e está dentro da regra de isenção de cobrança do recém nascido e desconsiderar a cobrança do mesmo. 
  • Verificar se o beneficiário está suspenso e não realizar cobrança do mesmo
  • Para eventos da temp que possuem valor por usuário e módulo de cobertura associado:
    • Se o módulo for opcional, somente continuar o cálculo do mesmo se o beneficiário possuir este. 
    • buscar nos critérios de mensalidade, o critério que o beneficiário se enquadra para o módulo (faixa etária). Para tanto será necessário identificar a idade do beneficiário no mês de faturamento e quando beneficiário possuir mais de 60 anos e mais de 10 anos de plano deverá ser utilizada a idade de suspensão de reajuste.
    • Com as informações de faixa etária do beneficiário, situação, data de inclusão, data de exclusão, e outras deverá ser criado registro em temp de módulos a serem calculados por beneficiário. 
  • Para evento da temp que possuem valor por beneficiário e não possuem módulo de cobertura associado:
    • Se a classe do evento for diferente de "G", "Y", " D" e "M" deverá ser desconsiderado. 
    • Deverá ser criado registro na temp de valores por beneficiário para este, associando informações do beneficiário e os valores dos eventos conforme criados na temp de evento do faturamento.
  • Deverá ser acumulada a quantidade de beneficiários. 
• Após a leitura dos usuários e criação da temp de valores por beneficiários, a mesma deverá ser lida e verificado o valor efetivo conforme as rotinas de cálculo do faturamento:
  • Quando possuir módulo associado deverá:
    • Identificar o critério de mensalidade que se enquadra, a partir da faixa etária e quantia de beneficiários
    • Identificar os reajustes por módulo, grau de parentesco, beneficiário, beneficiário x módulo.
    • Aplicar os reajuste que se enquadram partindo da regra do mais especifico para o mais genérico. 
  • Executar as rotinas de cálculo que podem ser especificas ou padrão do produto. As padrões são:
    • mensalidade-basica
    • mensalidade-proporcional
    • primeira-mensalidade
    • mensalidade-anterior
    • inscricao
    • nova-via-carteira
    • imposto
    • taxa-transferencia
    • beneficiarios-mes-atual
    • beneficiarios-incluidos-mes-atual
    • beneficiarios-mes-anterior
    • beneficiarios-incluidos-mes-anterior
    • beneficiários-exluidos-mes-anterior
    • calculo-programado-valor
    • calculo-programado-percentual
    • calculo-programado-sobre-evento
    • faturamento-periodico-normal
    • fatuamento-periodico-proporcional-normal
    • diluicao-reajuste
    • mensalidade-proporc-saida
    • mensalidade-reajuste-retroativo.
• Realizar o cálculo dos eventos de acréscimo - classe H
• Realizar o cálculo dos eventos de descontos - classe I
• Realizar o cálculo dos eventos de outros - classe J
• Realizar o cálculo dos eventos de programado percentual - classe R
• Realizar o cálculo dos eventos de programado valor - classe M
• Realizar o cálculo dos eventos de programado percentual sobre evento - classe S
• Realizar o cálculo das regras de desconto de mensalidade.
• Calcular os impostos
• Criar as tabelas do faturamento ou temporárias para o processo de simulação -realizando a criação de reajuste, atualização da situação do termo e do usuário. 

Para o método de cálculo complementar a regra segue praticamente a mesma, possuindo como diferença a identificação dos usuários, pois somente será calculado faturamento para os beneficiário de que possuem mês/ano do último faturamento inferior ao último faturamento do termo, gerando uma nota de serviço para cada mês de faturamento pendente.

Para o método de desmembramento de fatura a regra  semelhante, porém será gerado uma fatura para os dependentes indiretos e duas para os diretos conforme os percentuais informados na proposta. O cálculo de impostos também é alterado podendo incidir sobre todo o valor ou somente sobre uma parte do faturamento direto. 

Alteração dos programas do faturamento para utilizar a nova API

Os programas de faturamento deverão ser alterados de maneira a quando o contrato utilizar regras de mensalidade, o mesmo realize a chamada da API e quando não utilizar realizem o processo normal. 

A implementação fará com que os programas funcionem a partir dos dois conceitos: com regras de mensalidade e sem regras de mensalidade. 

Chamada da api de regras de mensalidade a partir da procedure "api-mens-pre-pagamento":

• Api-simula-faturamento
• dtvw0711a.p
• dtvw0711a1.p
• Fp0511j.p 
• Fp0511l.p 
• Fp0711a.p  
• Fp0711a1.p  
• Fp0711f.p
• Fp0711h.p

Fp0711n.p

Exemplo de chamada da api para geração:


Exemplo de chamada da API para simulação

Chamada da api de regras de mensalidade a partir da procedure "api-mens-complementar":

• api-fp0001.p
  

Chamada da api de regras de mensalidade a partir da procedure "api-desmembra-fatura":

dtvw3127.p


Criação de Programa para consulta de valores da regra de mensalidade (fp0910v)

Deverá ser criado o programa fp0910v, este programa será responsável pela realização de consulta de valores da regra de mensalidade:

As consultas serão realizadas por: "contrato" , "beneficiário" ou "regra de mensalidade" conforme período de referência, conforme:

"Regra de Mensalidade" : Deverá existir opções de zoom (iguais da manutenção de regras) para identificar a regra que se deseja buscar, para trazer os valores da regra utilizar a tabela de critérios da regra (regra-menslid-criter) conforme a vigência informada e aplicar os reajustes da regra até a vigência . 

"Contrato" : Poderá informar um grau de parentesco especifico ou todos, e deverão ser exibidos os critérios da regra associados ao contrato no periodo informado (regra-menslid-propost / regra-menslid-criter) conforme a vigência informada e aplicar os reajustes da regra até o inicio da associação ao contrato e os do contrato.

Beneficiário: Mesma lógica do contrato, porém, deverá solicitar o beneficiário, e o resultado deverá colorir as linhas que a idade do beneficiário se enquadra nos critérios. Além disso considera além do reajuste por contrato e módulo, o reajuste por grau de parentesco e beneficiário.

Regra reajuste da regra (considerado em todos os casos): 

Regra Reajuste contrato (alimentado temporária para posterior definição da aplicação):

Reajuste por Usuário  (alimentado temporária para posterior definição da aplicação):

Aplicação do Reajuste por contrato e beneficiário

 Criação de Programa para consulta de valores da regra de mensalidade (fp0910v)

A consulta de termo de adesão (faturamento) e consulta de faturas do contratante, deverão nas opções:

"F6" - Consulta de valores por grau faixa: Quando regra de mensalidade exibir o código da regra e realizar o agrupamento por grau x faixa x regra.

'F5' - Valores por beneficiário: Exibir o código da regra de mensalidade do beneficiário e possuir opção de ordenação por familia. 

Protótipo de Tela 

Protótipo 01 (CRUD - Regras de Mensalidade)

 Protótipo 02 (Aba - Detalhes da Regra)

  Protótipo 03 (Aba - Critérios da Regra)

  Protótipo 04 (Aba - Estruturas da Regra) 

  Protótipo 05 (Aba - Reajuste) 

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

·         Tabela: Regra-menslid

·         Tabela: Regra-menslid-criter

·         Tabela: Menslid-criter-histor

·         Tabela: Menslid-estrut-histor

·         Tabela: Regra-menslid-propost

·         Tabela: Regra-menslid-estrut

·         Tabela: Regra-menslid-reaj

·         Tabela: menslid-reaj-histor

Estrutura de Menu

Procedimentos

Programas

Informações Gerais

Objetivo

Simplificar o processo de parametrização de preço para o faturamento de pré-pagamento, visando melhorar a usabilidade do processo.

Eliminar os GAPs existentes em relação ao unicoo permitindo as seguintes funcionalidades:

- Faixa etária diferenciada para módulos opcionais.

- Valores diferenciados por usuário dentro de um mesmo grau de parentesco, para planos não regulamentados e/ou liminares judiciais.

- Consultar o valor por grau/faixa de forma simples. 

Definição da Regra de Negócio

Desenvolvimento de interface de parametrização das Regras de Mensalidade de Pré-pagamento.

Será desenvolvida a “Manutenção de Regras de Mensalidade de Pré-Pagamento”.

Esta  manutenção deverá ser desenvolvida em “progress”, porém o código da mesma deverá ser estruturado de forma que a interface e a regra de negócio fiquem separadas para possibilitar o reaproveitamento do código para uma futura conversão em HTML5 (programa progress de interface, fachada, e bo).

Esta nova manutenção será composta por uma tela principal de busca de registros (mesmo padrão das telas metadados), contendo os campos: “Código da Regra”, “Descrição da Regra”, “Tipo de Índice”, “Data de Inicio” e “Data Fim”. Verificar  “protótipo de interface”.

Ao acessar as opções de “Detalhar”, “Adicionar” e “Modificar”, será exibida interface separada por “abas”: “Detalhes da Regra”, “Critérios da Regra”, “Estruturas da Regra” e “Reajuste” onde será possível realizar toda a parametrização de  valores do faturamento.

Abaixo detalhamento do comportamento e interface de cada uma das abas:

Detalhes da Regra (protótipo de interface)

Tabela: regra-menslid

              Nesta aba serão detalhadas informações cadastrais da regra:

                - Descrição: Descrição Informativa da regra.

                - Vigência: Inicial e Final.

                - Tipo de Indice: conforme o cadastro de “tipo de índice”, deverá existir zoom para esta opção.

                - Tipo Regra: Este campo servirá para filtros apenas.

                - Observações: informativo.

Critérios da Regra (protótipo de interface)

Tabela: regra-menslid-criter

Tabela Histórico: menslid-criter-histor

Nesta aba são definidos os critérios da rega, que influenciarão diretamente no valor de mensalidade do beneficiário.

Os campos são:

- P.C. (Padrão de Cobertura) : Caso exista fator diferenciado por padrão de cobertura, este deverá ser informado, senão não há necessidade. (Deverá existir zoom para esta funcionalidade)

- Mod (Módulo) : Informação obrigatória, deverá ser informado o módulo de consulta para mensalidade e os módulos opcionais. (Deverá existir zoom para esta funcionalidade)

- Grau de Parentesco: Deverá ser informado “0” para todos os graus de parentesco ou especificado o grau de parentesco.  (Deverá existir zoom para esta funcionalidade)

- Faixa Etária: Informação obrigatória, devem ser informadas as faixas etárias (faixa, idade inicial e idade final) dos módulos de cobertura (mensalidade e opcionais) para composição do preço.

- Vlr. Mens (Valor de Mensalidade) : Valor da mensalidade para o Padrão de Cobertura (quando aplicado) X Modulo X Faixa Etária.

- Vl. TX. Insc (Valor da Taxa de Inscrição): Valor da taxa de inscrição mensalidade para o Padrão de Cobertura (quando aplicado) X Modulo X Faixa Etária.

- Fator de Repasse: Fator ao qual o valor de mensalidade será multiplicado quando o beneficiário estiver repassado. Por padrão é informado “1.0000”.

- Data Inic/Data Fim – Vigência do critério.

OBS: mesmo existindo vigência nos critérios, todos os campos poderão ser editados, porém o sistema realizará o histórico de todas as alterações realizadas.

Regras de preenchimento e validação dos campos:

- P.C – Preenchimento opcional, se informado o valor informado deve existir na tabela “pad-cob”

- Módulo – Preenchimento obrigatório, o valor informado deve existir na tabela “mod-cob”.

- Grau Parentesco - Preenchimento obrigatório, pode ser informado “0” que representa todos os graus de parentesco ou informado um grau em especifico (Que deverá existir na tabela gra-par).

- Faixa etária: Código sequencial por “P.C”/”Módulo”/”Grau de Parentesco” / “Data Validade’.

- Numero de beneficiário Inicial e final: A quantidade de beneficiários inicial e final que o critério se aplica. 

Exemplo :

Se informado de forma incorreta o sistema não deverá permitr, gerando erro.

- Idade Inicial e Idade Final: A idade inicial não poderá ser maior que a final. Não poderá existir sobreposição de idades entre faixas etárias diferentes dentro de um mesmo “PC/Mód/GrauPar/validade”.

Abaixo exemplo, em vermelho situação em que o sistema não deve permitir:

- Valor Mensalidade, Valor Taxa Inscrição – Informação livre de valor, formatar em reais.

- Fator de Repasse – Informação livre de valor.

- Data Inicio e Fim de Vigência – a data de fim não poderá ser menor que a data de inicio.

OBS: Ao salvar todo o registro de regra de mensalidade, o sistema deverá validar se existem lacunas de idade  no cadastro de critérios de mensalidade, informar para o usuário as lacunas (em um grid com todas as existentes) e permitir salvar o registro caso usuário deseje prosseguir mesmo com as lacunas.

Exemplo lacunas:

- Não existe registro para idade “19” anos com padrão de cobertura.

- Deverá existir opção “Copiar de” ao lado do histórico, quando selecionado esta opção o sistema permitirá realizar a copia dos critérios ativos de outra regra de mensalidade, a fim de facilitar a parametrização.

- O sistema permitirá alterar e excluir informações livremente dos critérios, porém cada informação alterada ou excluída gerará um registro de histórico. A tabela de histórico, possui os mesmo campos da tabela de critérios apenas adicionando os seguintes campos:

                               - Tipo Alteração: A – Alteração, E – exclusão:

                               - Data Alteração: Data em que registro foi alterado.

                               - Hora Alteração: Hora que o registro foi alterado.

                               - Usuário Alteração: Usuário que realizou a alteração.

                               - idi-seq: sequencial por cdd-id.

Ao clicar no botão histórico, sistema deverá exibir grid com o histórico de alterações e exclusões.

Estruturas da Regra (protótipo de interface)

Tabela: regra-menslid-estrut

Tabela histórico: menslid-estrut-histor

 Nesta aba serão definidas as estruturas/contratos e usuários ao qual a regra poderá ser aplicada.

Poderão ser informados: Modalidade, Plano, Tipo Plano, Contrato e usuário.

A informação poderá ser da seguinte maneira: