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

De GeoSales
Ir para navegação Ir para pesquisar
(Criou página com '== Histórico de Alterações== {| class = "wikitable" ! Data ! Quem ! Comentários |- | 16/04/2021 ||João Ramon || Criação do documento |- |} == Necessidade == Após a...')
 
 
(22 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 disparado 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: fluxoprospect.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 ___________________ ___/___/_____ ________________________