Mudanças entre as edições de "Cancelamento de Cadastros em Status Prospect"

De GeoSales
Ir para navegação Ir para pesquisar
 
(20 revisões intermediárias por um outro usuário não estão sendo mostradas)
Linha 12: Linha 12:
 
== Necessidade ==
 
== Necessidade ==
  
Após a criação de um cliente com status "Prospect", este cadastro ainda poderá ser editado, caso ainda não esteja efetivado. Quando o cliente é efetivado, ele é direcionado para integração À ERP do cliente. O problema é que, se houver uma falha de integração, o prospect não poderá mais ser modificado, por já estar efetivado, e ficará eternamente com pendência de Integração. Faz-se necessário criar um dispositivo que permita a edição deste cadastro (inclusive cancelamento) após efetivação.
+
Após a criação de um cliente com status "Prospect", este cadastro ainda poderá ser editado, caso ainda não esteja efetivado. Quando o cliente é efetivado, ele é direcionado para integração À ERP do cliente. O problema é que, se houver uma falha de integração, o prospect não poderá mais ser modificado, por já estar efetivado, e ficará eternamente com pendência de Integração. Faz-se necessário criar um dispositivo que permita a edição deste cadastro após efetivação.
  
 
== Solução ==
 
== Solução ==
  
Quando o cadastro, após a efetivação, tentar subir para integração, caso não obtenha êxito, deverá ser implementado um meio para que este cadastro possa ser novamente editado. Este meio será  a implantação de um trigger de retorno, fazendo com que ele retorne À tela de prospect, com status de não efetivado, permitindo a edição do cadastro pelo usuário, que deverá ser informado do retorno do prospect à base.
+
Quando o cadastro, após a efetivação, tentar subir para integração, caso não obtenha êxito, deverá ser implementado um meio para que este cadastro possa ser novamente editado. Este meio será  a implantação do disparo de um trigger de retorno, fazendo com que ele retorne ao status de não efetivado, permitindo a edição do cadastro pelo usuário, que deverá ser informado da falha de integração e da disponibilidade do cadastro para ajustes.
  
 
== Implementação ==
 
== Implementação ==
  
 +
# A ativação da opção de retorno deve ser configurável pelo usuário.
 +
# Após a efetivação do prospect, ele será enviado à ERP.
 +
# Todos os processos de tentativa de integração são registrados na tabela ACK_LOG_TABLE.
 +
# Quando a integração não for realizada, registra-se a falha de integração do prospect na tabela, cenário onde será disparado o trigger de retorno.
 +
# O usuário deverá ser informado sobre o retorno do prospect (poderá ser por email);
 +
# O cadastro deverá estar disponível para edição, dependendo da demanda do usuário.
 +
# Feita as devidas alterações, as seguintes soluções deverão ser permitidas:
 +
* Nova efetivação do cadastro para nova tentativa de integração;
 +
<!--* Cancelamento do cadastro, caso o usuário escolha pelo cancelamento;-->
  
* Todos os processos de tentativa de integração são registrados na tabela ACK_LOG_TABLE.
+
[[arquivo: fluxoprospect2.png|frame | fluxograma de gatilho de retorno]]
* Quando for detectada a falha na integração do prospect na tabela, será o momento para a ativação do trigger de retorno.
+
 
* O usuário deverá ser informado sobre o retorno (poderá ser por email);
+
== Cenários ==
* O cadastro deverá estar disponível para edição e para cancelamento, caso seja a demanda do usuário.
+
 
* Feita as devidas alterações, as seguintes soluções deverão ser implementadas:
+
<!--=== Cenário 1 - Cancelamento após falha de integração ===
# Nova efetivação do cadastro para nova tentativa;
 
# Cancelamento do cadastro, caso o usuário escolha pelo cancelamento;
 
  
[[arquivo: fluxoprosp.png|frame | fluxograma de gatilho de retorno]]
 
  
== Cenários ==
+
# Criação de cadastro na tela de prospect;
 +
# As alterações são salvas e o cadastro é efetivado;
 +
# O cadastro é enviado para a ERP e não conclui o processo de integração;
 +
# O registro de falha é inserido na tabela ACK_LOG_TABLE;
 +
# A falha de exportação de cadastro irá provocar um disparo de trigger, que fará o retorno do cadastro para edição com status de não efetivado;
 +
# Uma notificação de retorno de cadastro pendente será enviado ao usuário, informando que o cadastro não foi integrado e requer uma ação dele.
 +
# O usuário poderá acessar novamente o cadastro e fará o cancelamento do mesmo.-->
  
=== Cenário - Cadastro não integrado à ERP ===
+
=== Cenário 1 - Re-efetivação após falha de integração ===
  
*Dado que eu acesso a plataforma GeoSales EVO
+
# Criação de cadastro na tela de prospect;
*E realizo um cadastro de prospect
+
# As alterações são salvas e o cadastro é efetivado;
*E salvo as alterações
+
# O cadastro é enviado para a ERP e não conclui o processo de integração;
*E efetivo o cadastro
+
# O registro de falha é inserido na tabela ACK_LOG_TABLE;
*Então o cadastro será enviado para integração na ERP do cliente.
+
# A falha de exportação de cadastro irá provocar um disparo de trigger, que fará o retorno do cadastro para edição com status de não efetivado;
*O cadastro não foi integrado na ERP.
+
# Uma notificação de retorno de cadastro pendente será enviado ao usuário, informando que o cadastro não foi integrado e requer uma ação dele.
*Será gerado log na Tabela ACK
+
# O usuário fará nova edição no cadastro, caso seja necessário, e efetivará novamente o cadastro, para novo envio à ERP.
*Será acionado o trigger de retorno do prospect à base
 
*Será disparado informação de retorno ao usuário, para novas alterações.
 
  
 
== Regras de Negócio ==
 
== Regras de Negócio ==
  
'''[RN1] -''' O retorno do cadastro será feito imediatamente após a falha na integração, e retorno da pendência 'falha na integração'.
+
'''[RN1] -''' O retorno do cadastro será feito imediatamente após a falha na integração, sob o status de 'não efetivado'.
  
 
'''[RN2] -''' Após o trigger ser acionado, deve ser disparado um mecanismo de feedback para o usuário (ex. disparo de e-mail, informando que o cadastro retornou).
 
'''[RN2] -''' Após o trigger ser acionado, deve ser disparado um mecanismo de feedback para o usuário (ex. disparo de e-mail, informando que o cadastro retornou).
  
'''[RN4] -''' Pode ocorrer, ainda de muito remotamente, o risco de o cadastro ser integrado '''no momento entre o processo de retorno'''. No caso de ocorrência deste processo, o processo de retorno deverá ser cancelado.
+
'''[RN3] -''' Pode ocorrer, ainda de muito remotamente, o risco de o cadastro ser integrado '''no momento entre o processo de retorno'''. No caso de ocorrência deste processo, o processo de retorno deverá ser cancelado.
 +
'''[RN4] -''' A ativação deste procedimento deverá ser realizada via configuração.
  
 
== Aprovação ==
 
== Aprovação ==
Linha 66: Linha 77:
  
 
|-  
 
|-  
| Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000
+
| Desenvolvimento - GeoSales || Renato Lima || 26/04/2021
 
|-  
 
|-  
 
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000
 
| Integração - GeoSales || Pessoa que aprovou || 00/00/0000

Edição atual tal como às 19h25min de 26 de abril de 2021

Histórico de Alterações

Data Quem Comentários
16/04/2021 João Ramon Criação do documento

Necessidade

Após a criação de um cliente com status "Prospect", este cadastro ainda poderá ser editado, caso ainda não esteja efetivado. Quando o cliente é efetivado, ele é direcionado para integração À ERP do cliente. O problema é que, se houver uma falha de integração, o prospect não poderá mais ser modificado, por já estar efetivado, e ficará eternamente com pendência de Integração. Faz-se necessário criar um dispositivo que permita a edição deste cadastro após efetivação.

Solução

Quando o cadastro, após a efetivação, tentar subir para integração, caso não obtenha êxito, deverá ser implementado um meio para que este cadastro possa ser novamente editado. Este meio será a implantação do disparo de um trigger de retorno, fazendo com que ele retorne ao status de não efetivado, permitindo a edição do cadastro pelo usuário, que deverá ser informado da falha de integração e da disponibilidade do cadastro para ajustes.

Implementação

  1. A ativação da opção de retorno deve ser configurável pelo usuário.
  2. Após a efetivação do prospect, ele será enviado à ERP.
  3. Todos os processos de tentativa de integração são registrados na tabela ACK_LOG_TABLE.
  4. Quando a integração não for realizada, registra-se a falha de integração do prospect na tabela, cenário onde será disparado o trigger de retorno.
  5. O usuário deverá ser informado sobre o retorno do prospect (poderá ser por email);
  6. O cadastro deverá estar disponível para edição, dependendo da demanda do usuário.
  7. Feita as devidas alterações, as seguintes soluções deverão ser permitidas:
  • Nova efetivação do cadastro para nova tentativa de integração;
fluxograma de gatilho de retorno

Cenários

Cenário 1 - Re-efetivação após falha de integração

  1. Criação de cadastro na tela de prospect;
  2. As alterações são salvas e o cadastro é efetivado;
  3. O cadastro é enviado para a ERP e não conclui o processo de integração;
  4. O registro de falha é inserido na tabela ACK_LOG_TABLE;
  5. A falha de exportação de cadastro irá provocar um disparo de trigger, que fará o retorno do cadastro para edição com status de não efetivado;
  6. Uma notificação de retorno de cadastro pendente será enviado ao usuário, informando que o cadastro não foi integrado e requer uma ação dele.
  7. O usuário fará nova edição no cadastro, caso seja necessário, e efetivará novamente o cadastro, para novo envio à ERP.

Regras de Negócio

[RN1] - O retorno do cadastro será feito imediatamente após a falha na integração, sob o status de 'não efetivado'.

[RN2] - Após o trigger ser acionado, deve ser disparado um mecanismo de feedback para o usuário (ex. disparo de e-mail, informando que o cadastro retornou).

[RN3] - Pode ocorrer, ainda de muito remotamente, o risco de o cadastro ser integrado no momento entre o processo de retorno. No caso de ocorrência deste processo, o processo de retorno deverá ser cancelado. [RN4] - A ativação deste procedimento deverá ser realizada via configuração.

Aprovação

Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado.

GeoSales

Setor Aprovado Por Data
Desenvolvimento - GeoSales Renato Lima 26/04/2021
Integração - GeoSales Pessoa que aprovou 00/00/0000
Configurações - GeoSales Pessoa que aprovou 00/00/0000

Empresa solicitante

Setor Aprovado Por Data Assinatura
Gerente TI - Cliente ___________________ ___/___/_____ ________________________
Gerente de Projeto - Cliente ___________________ ___/___/_____ ________________________
Gerente Comercial - Cliente ___________________ ___/___/_____ ________________________