Histórico da Página

Informações Gerais

Objetivo

 Esta especificação tem a finalidade de detalhar como deverá ser incluída a funcionalidade da tela de Pré atendimento do portal do prestador na tela de Atendimento visando garantir maior flexibilidade e agilidade no processo que é feito atualmente para realizar um atendimento pelo portal.

Definição da Regra de Negócio

A funcionalidade de Pré Atendimento do portal do prestador deverá ser apenas incluída na rotina de Atendimento e a atual rotina de Pre Atendimento irá continuar normalmente no menu do portal, ficará a critério do cliente retirá-la do menu ou não. A rotina deverá continuar possuindo as mesmas funcionalidades sem causar impacto na atual rotina de Atendimento do portal. 

1. Criar o parâmetro (SX6) chamado MV_PREATE

<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

1. PLPREATE (padrão .F.) do tipo lógico que, quando estiver .T. significa que essa funcionalidade estará ativada na rotina de Atendimento, do contrário, se estiver .F. indicará que a rotina estará inativa, isto é, este complemento do Pré Atendimento na tela de Atendimento deverá aparecer se, e somente se esse parâmetro estiver configurado como .T..
2. Todo JavaScript de validação de acesso, leitura de cartão, entre outras que está no arquivo PPLCARTMAT.APH (Pré Atendimento) deverá ser copiado para o arquivo PPLMOSPRE.APH (Atendimento)
3. O JavaScript que executa quando a página de Pré Atendimento está carregando, também deve executar no momento de carregamento da tela de Atendimento, pois é neste momento que é validado o Tipo de Acesso do usuário (0=Cartão,1=Digitação,2=Todos), se possui acesso ao botão internados e se há a funcionalidade de biometria.
4. Os campos do tipo Hidden do Pré Atendimento devem ser replicados para a tela de Atendimento também porque são campos de controle da rotina.
5. A função PPLTPCHM é uma Web Function que é chamada no momento do clique no menu na rotina de Pré Atendimento, ela faz toda validação do usuário logado para carregar a tela com as funções corretas, essas validações devem ser replicadas para a Web function PPLCHAPRE que é a Web Function executada para a tela de Atendimento.
   1. Opcional: criar uma função que possa ser chamadas em ambas Web Functions para não replicar código. 
6. Quando o prestador possui acesso ao botão internação, ao clicar nele, é aberta uma janela onde o prestador pesquisa um beneficiário, e o seleciona para fazer um pré atendimento, portanto, ao selecionar o beneficiário internado, deverá ser feito o mesmo processo, preenchendo o campo matrícula/cartão com o dado do paciente.
7. Após o prestador preencher a Matrícula/Cartão/Biometria do beneficiário, o sistema deverá preencher os dados do mesmo nos campos abaixo do Atendimento, bem como incluí-lo na grade de dados.

Tabelas Utilizadas

• BA1 – Usuários

Protótipo de Tela

 Image Added

Protótipo 01 - Tela de atendimento simulando um prestador com acesso do tipo 0 = Cartão

Image Added

Protótipo 02 - Tela de atendimento simulando um prestador com acesso do tipo 1 = Digitação e acesso ao botão internados

Obs: Se o usuário logado não possuir acesso ao botão internados, ocultar a sua exibição

Image Added

Protótipo 03 - Tela de atendimento simulando um prestador com acesso do tipo 2 = Todos, utilizando o tipo Cartão

Image Added

Protótipo 04 - Tela de atendimento simulando um prestador com acesso do tipo 2 = Todos, utilizando o tipo Matrícula e sem acesso ao botão Internados 

Dicionário de Dados

Parâmetro: MV_PLPREATE

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