Histórico da Página

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

O objetivo desta rotina é permitir o estreitamento do relacionamento entre Prestador e Operadora, por meio de possibilitar a solicitação de visitas institucionais pelo prestador, que poderão ocorrer tanto na Operadora, quanto no próprio Prestador e, também, permitir para a Operadora o controle das solicitações e deferimento, ou não das mesmas, conforme disponibilidade e critérios da mesma. 

Definição da Regra de Negócio

• Prestador acessa a rotina via portal e solicita uma visita 
• O combo de Motivos de Visita deve apresentar somente os motivos com tipo = 3
• Solicitação é verificada pelas regras de validação do sistema
  
  

       Regras de validação:

1. Tipo é obrigatório
2. Motivo é obrigatório
3. Data sugerida é obrigatório
4. Data deve ser maior ou igual do que a data atual
5. Demais campos não são obrigatórios
6. Se solicitação é válida, é criada solicitação para análise na rotina PLSA817 e enviado e-mail para o solicitantedestino especificado no parâmetro MV_817EMAIL.
7. Se não, devolve mensagem ao usuário
   

• Além dos campos que o usuário irá interagir deve ser informado na gravação do Protheus
  

1. B7K_FILIAL
2. B7K_CODINT
3. B7K_CODRDA
4. B7K_DATSOL
5. B7K_HORSOL
6. B7K_CNTSOL
7. B7K_TELSOL
8. B7K_MAILSL

• Solicitação é analisada no Protheus (PLSA817)

       Regras:

• Haverá três status de legenda no browse: Visita confirmada (Verde – B7K_DEFERE = Sim), Visita indeferida (Vermelho – B7K_DEFERE = Não), Visita em análise (Amarelo – B7K_DEFERE = não preenchido)
• O campo B7K_DEFERE virá em branco
• Não haverá opção de inclusão para esta rotina
• Não será possível alterar os dados enviados pelo prestador, exceto:
  1. B7K_CNTSOL
  2. B7K_TELSOL
  3. B7K_MAILSL
• Caso seja alterado para SIM o combo de confirma visita (B7K_DEFERE), mostrar mensagem de informação ao usuário (que será enviada confirmação via e-mail ao salvar)
• Caso seja alterado para NÃO o combo de confirma visita (B7K_DEFERE), mostrar mensagem de informação ao usuário (que será enviada informação via e-mail ao salvar)
• Caso seja alterado para SIM, o formulário somente poderá ser salvo ao informar a data e horário agendados da visita (B7K_DATAGE e B7K_HORAGE), além de contato solicitante e contato Operadora (B7K_CNTSOL e B7K_CNTOPE).
• Caso seja alterado para SIM, ou NÃO e não haja problemas ao salvar, deverá ser enviado e-mail ao prestador (Considerando o campo B7K_MAILSL, como endereço para envio)
• Caso o campo B7K_MAILSL não esteja preenchido, exibir informação que não será possível enviar o e-mail, devido a ele não ter sido informado.
• Se aprovada a análise e há e-mail preenchido, é enviado e-mail ao prestador, confirmando a data e horário.
• Se não é aprovada, mas há e-mail preenchido, é enviado e-mail ao prestador informando a não possibilidade da realização.
• Após o deferimento, ou indeferimento, não será possível realizar alterações no registro.

 

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

• Cadastro de Motivos de Visita (PLSA801)

• Alterar as mensagens de aviso que envolvam o tipo “Ambos” (já que haverá o terceiro tipo de motivo, sugestão, “CAPTAÇÃO/RELACIONAMENTO”)

• Incluir o Tipo de visita 3, para visita institucional (sugestão, "INSTITUCIONAL")
• Adaptar validações, se necessário
• Ponto de Atenção: Esse cadastro pode impactar nas rotinas PLSA806, PLSA807 e consultas padrão B9PB9L e B9WB9L, as alterações propostas não devem interferir no funcionamento destas. Por este motivo o tipo 3 deve ser tratado separadamente e não será unido como um motivo genérico para as três situações. Caso se mostrar necessário fazer isso durante o desenvolvimento, deverão ser ajustados os impactos gerados nestes pontos.

 

Rotina	Tipo de Operação	Opção de Menu	Regras de Negócio
[PLSA801– Parâmetros]	[Alteração]	[Atualizações -> Rede de Atendimento-> Motivos de Visita]	-
[PLSA817– Visitas Institucionais]	[Criação]	[Atualizações -> Rede de Atendimento-> Visitas Institucionais]	-

 

Exemplo de Aplicação:

• Criar o a tabela B7K, conforme especificado no Anexo "Tabela B7K".
• Alterar o campo B9L_TIPVIS, adicionando o Item 3 nas opções do combo.
• Criar Arquivo PPLVINST.APH para criar a página a ser exibida no portal do prestador.
• Criar Arquivo PLSA817.PRW para criar a rotina do Protheus.

 

Tabelas Utilizadas

• B7K– Visitas Institucionais
• B7L– Motivos de Visita.
• BAU - Rede de Atendimento

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

Tela Portal de Solicitação de Visita Institucional

 Image Added

Tela Remote de Vistas Institucionais

Image Added

Browse Tela remote de Visitas Institucionais

Image Added

Fluxo do Processo

 Caso de uso

 Image Added

Importante: antes de utilizar a rotina é necessário realizar o cadastro dos Motivos de Visita e dos e-mails padrão, na rotina de Sinalizadores.

Dicionário de Dados

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/  B7K - Visitas Institucionais

Índice	Chave
01	<FI9B7K_FILIAL + FI9B7K_IDDARFCODINT + FI9B7K_STATUS>CODRDA
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

Para detalhes dos campos, consultar o Anexo abaixo:

Configuração dos campos da Tabela B7K

Criação de Parâmetro: MV_817EMAIL

Parâmetro Tipo C

Irá receber o endereço de e-mail de destino para o envio do e-mail ao confirmar a solicitação de visita via portal.

Consulta Padrão

Consulta: B7KB9L

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

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