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

Edição das 17h31min de 19 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 perfil 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 pedido 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 perfil (inclusive cancelamento) após efetivação.

Solução

Quando o perfil, 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 o perfil retorne À tela de prospect, com status de não efetivado, permitindo a edição do perfil pelo usuário, que deverá ser informado do retorno do prospect à base.

Implementação

Todos os processos de tentativa de integração são registrados na tabela ACK_LOG_TABLE.
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);
O perfil 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:

Nova efetivação do perfil para nova tentativa;
Exclusão do perfil, caso o usuário escolha pelo cancelamento;

Cenários

Criação de Pendência na Tabela TIPO_BLOC_PEDIDO_SIT

Regras de Negócio

[RN1] - A pendência que ira disparar o trigger para retorno deverá ser criado na tabela TIPO_BLOC_PEDIDO_SIT.

[RN2] - O retorno do pedido será feito imediatamente após a falha na integração, e retorno da pendência 'falha na integração'.

[RN3] - 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 pedido retornou).

[RN4] - Pode ocorrer, ainda de muito remotamente, o risco de o pedido ser integrado no momento entre o processo de retorno. No caso de ocorrência deste processo, o processo de retorno deverá ser cancelado.

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	Pessoa que aprovou	00/00/0000
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	___________________	___/___/_____	________________________

@@ Linha 32: / Linha 32: @@
 === Criação de Pendência na Tabela TIPO_BLOC_PEDIDO_SIT ===
-{|class="wikitable"
-! <code>CD_TIPO_BLOC</code>
-! <code>DS_TIPO_BLOC</code>
-! <code>CD_TIPO_PEDENCIA</code>
-|-
-| XX || Falha de integração || NULL
-|-
-|}
 <!--=== Cenário 1 (Pedido não efetivado e Aprovado - Sem Pendências) ===
-Neste cenário, o pedido não possui nenhuma pendência de configuração ou de políticas comerciais (e, portanto, na situação de 'aprovado').
+Dado que eu acesso a plataforma GeoSales EVO
+E realizo um cadastro de prospect
-* O portal, nesta fase, ainda permite alterações por parte do usuário;
+E salvo as alterações
-* O pedido '''não será enviado''' para ERP caso esteja nesta situação.
+E efetivo o perfil
+Então o Perfil será enviado para integração na ERP do cliente.
-=== Cenário 2 (Pedido não efetivado e Pendente) ===
+O perfil não foi integrado na ERP.
+Será gerado log na Tabela ACK
-Neste cenário, o pedido possui alguma pendência.
+Será acionado o trigger de retorno do perfil à base
+Será disparado informação de retorno ao usuário, para novas alterações.
-* O portal, nesta fase, ainda permite alterações por parte do usuário;
-* O pedido '''não será enviado''' para ERP caso esteja nesta situação.
-=== Cenário 3 (Pedido efetivado e Pendente) ===
-Aqui, o pedido já foi efetivado. No entanto, foram encontradas situações no registro que gerara pendências. Portanto, o pedido estará no status de pendente.
-* O portal, nesta fase, ainda permitirá alterações por parte do usuário (caso o gestor não aprove o pedido e devolva ao vendedor para edição). Também será possível cancelar o pedido nesta situação;
-* O pedido '''não será enviado''' para ERP caso esteja nesta situação.
-=== Cenário 4  (Pedido Efetivado e Aprovado) - com Integração ERP ===
-Neste cenário, o pedido foi efetivado e já aprovado pelo supervisor.
-* O portal, nesta fase, não permitirá mais qualquer edição ou correção por parte do usuário;
-* O pedido '''será enviado''' para ERP caso esteja nesta situação.
--->
 === Cenário 1 (Pedido Efetivado e Aprovado pelo vendedor, sem necessidade de aprovação pelo Gestor) - sem Integração ERP ===