Histórico da Página

Informações Gerais

Objetivo

   Esta especificação tem como objetivo detalhar a melhoria à ser implementada na integração entre RM Saúde e os a API da aplicação de Formulários Dinâmicos, utilizados utilizada pelo PEP 2.

Definição da Regra de Negócio

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

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

 Image Removed

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

    RN001 - Deve ser criado um novo parâmetro, em parâmetros gerais, permitindo ao usuário informar a URL da aplicação de formulários dinâmicos,

  RN002 - Para a integração entre RM Saúde e Formulários Dinâmicos, deve ser criado um novo cadastro, onde serão necessárias as seguintes informações:

• Tabela do RM e Campo do RM, correspondentes à informação que será buscada do Formulário;
• ID do formulário dinâmico, onde deverá ser informado o ID do formulário cadastrado na aplicação de Formulários Dinâmicos;
• Campo do Formulário Dinâmico, que será o campo buscado na pesquisa à API;
• Utiliza Attention ID, que deverá ser setado como "T", caso o formulário tenha em seu filtro a tag "attentionId".;
  

   **Importante: Neste cadastro não será permitido incluir ou excluir, apenas editar. Os dados serão alimentados pelo responsável pela implementação, via insert em banco. Cada cliente poderá ter formulários e metadados cadastrados de forma diferente.

   RN003 - Será criada uma Classe Server, bem como sua Interface, que será a responsável por realizar a consulta à API de formulários dinâmicos e retornar a informação desejada. Os seguintes pontos devem ser observados:

• A API espera uma URL como requisição, onde já deverão estar todos os filtros montados, seguindo o padrão descrito no documento que está publicado em: FORM0003_API_de_pesquisa_de_metadados;
• O Método utilizado para a pesquisa deverá ser genérico, retornando qualquer campo que seja informado na chamada da aplicação;

   RN004 - Deve ser implementada a consulta à API, no momento da pesquisa por paciente, no registro de Alta do Paciente, seguindo as seguintes regras:

• Quando a pesquisa por paciente for realizada e o parâmetro geral (RN001) estiver com a URL configurada, o sistema deverá chamar a integração e retornar o CID de alta do paciente (campo CIDPRINCIPAL da tabela SZATENDIMENTO);
• Quando estiver vazia a URL, sistema mantém a rotina normal de execução.   

Exemplo de Aplicação:

• Realize o insert no banco de dados, na tabela "SZCAMPOSFORMDINAMICO", com as informações referentes à coluna "CIDPRINCIPAL" da tabela "SZATENDIMENTO", e de onde será trazida a informação(IDFORMDINAMICO e CAMPOFORMDINAMICO),
  a coluna "UTILIZAATTENTIONID", deverá ser "T", caso o formulário utilize essa tag e "F", caso contrário;
• Acesse o menu "Opções > Parâmetros > Parâmetros Gerais" e, na aba "Integração", informe a URL da aplicação do formulário dinâmico;
• Acesse o menu "Cadastros > Registro e Controle > Correlação com Form. Dinâmico" e valide se o registro correspondente à coluna "CIDPRINCIPAL" da tabela "SZATENDIMENTO", está corretamente correlacionado com o formulário dinâmico;
• Acesse o menu "Atendimento > Internação > Alta" e selecione o paciente desejado (que já possua alta preenchida no formulário dinâmico configurado). Sistema deverá preencher o campo CID(Alta) com o valor correspondente.
  
  

Tabelas Utilizadas

   SZCAMPOSFORMDINAMICO
   

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