Histórico da Página

(Obrigatório)

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. 

(Obrigatório)

Definição da Regra de Negócio

• Prestador acessa a rotina via portal e solicita uma visita 

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

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

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

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

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

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

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMBB7KB9L

DescriçãoConfigurações de Planejamento	Motivo Visita Institucional
Tipo	Consulta Padrão
Tabela	“AMB”“B7K”
Índice	“Código”
Campo	“Código”; ”Descrição”
Retorno	AMBB9L->AMB>B9L_CODIGO   CODVIS B9L->B9L_DESVIS
Filtro	B9L->B9L_TIPVIS == "3" .AND. B9L->B9LCODINT == PLSINTPAD()

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