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

@@ Linha 1: / Linha 1: @@
-== Histórico de Alterações==
-{| class = "wikitable"
-! Data
-! Quem
-! Comentários
-|-
-| 13/04/2021 ||João Ramon || Criação do documento
-|-
-|}
-== Necessidade ==
-Ao finalizar o processo de inserção de pedidos, pelo vendedor, caso não haja nenhuma pendência de negócio (exemplos: tipo de frete não especificado, valor final do pedido ou de um determinado grupo está fora da política comercial de descontos, valor apresentado ao cliente era de uma campanha cuja vigência já encerrou, dentre outros), o pedido 'subirá' para integração na ERP. Caso haja pendências, será necessária aprovação de um gestor responsável. Após a aprovação, então seguirá para integração. O problema é que, após aprovar tal pedido, por algum motivo, ele não consegue 'subir' para o ERP, a fim de integrar a venda. Nesta situação, é impossível fazer qualquer edição ou exclusão do pedido, depois que já foi aprovado. Na situação atual, o pedido fica vagando por um limbo de dados existencial, no qual não pode ser configurado, nem pode subir para integração. Por essa razão, faz-se necessária uma ação que permita que, em situações como essa, haja a possibilidade de cancelar ou editar o '''pedido 'perdido''''.
-<!--Durante o processo de formação de pedidos, é comum que possa ocorrer alguma pendência de processo. Essas pendências podem ocorrer pelos mas diversos motivos, tais como: tipo de frete não especificado, valor final do pedido ou de um determinado grupo está fora da política comercial de descontos, valor apresentado ao cliente era de uma campanha cuja vigência já encerrou, e muitas outras situações, para as quais o portal consegue identificar e listar quais pendências estão ativas após o envio do pedido pelo vendedor. Quando o pedido chega para aprovação do gestor, dependendo de sua alçada, é possível efetivar a aprovação do pedido, mesmo com tais pendências. O problema é que, após aprovar tal pedido, por algum motivo, ele não consegue 'subir' para o ERP, a fim de efetivar a venda, tampouco é possível fazer qualquer edição ou exclusão do pedido, uma vez que já foi aprovado. Na situação atual, o pedido fica vagando por um limbo de dados existencial, no qual não pode ser configurado, nem pode subir para integração.-->
-== Solução ==
-Para atender à demanda solicitada, após o pedido ser finalizado no portal, ele vai para integração. Se o pedido não conseguir ser integrado,  deverá ser possível que este pedido retorne para a edição no portal, sob o status de '''pendente'''. Esse retorno ao portal deverá ser realizado por meio de um gatilho (trigger), sendo acionado logo após o registro da falha. Com este retorno do pedido ao portal, será possível que algumas modificações possam ser realizadas, a fim de tratar alguma pendência ou para tentar integrar novamente, ou para ser cancelado, caso o usuário deseje. No processo, ainda deve existir um recurso que, quando o pedido for retornado ao portal, o gestor deva ser informado que o pedido não foi integrado, e que necessita sua intervenção.
-Ressaltamos ainda, que, no momento do retorno do pedido ao portal, possa existir a possibilidade, ainda que remota, de o pedido ser integrado na tentativa seguinte.
-Em resumo, a solução consiste nos seguintes passos:
-# Criação de uma pendência relacionada à Falha de Integração na tabela relacionada;
-# Criação de um trigger que faça o pedido retornar ao status de pendente;
-# Criação de dispositivo de comunicação ao usuário, informando que o pedido não foi integrado, e aguarda configurações, inserindo este passo na tramitação do pedido;
-# Após as modificações do usuário, o pedido será novamente submetido à integração. Se integrar, o pedido estará encerrado; caso contrário, deverá retornar ao ponto 1 para novo procedimento.
-== Implementação ==
-* Todos os pedidos realizados na plataforma são registrados na tabela ACK_LOG_TABLE. Nesta tabela, todas as especificações de pendências são mostradas em vinculação com as chaves de pedidos. A tabela de registro dos bloqueios existentes é a TIPO_BLOC_PEDIDO_SIT.
-* É necessária criar uma pendência dentro da tabela TIPO_BLOC_PEDIDO_SIT, contemplando a situação deste cenário (Falha de Integração);
-* Após a conclusão das tramitações normais do pedido (efetivação e aprovação), ele estará disponível para integração.
-* Se a integração não ocorrer, deverá ser acionado um gatilho de retorno (trigger) para que este pedido possa retornar ao portal, com status de pendente, utilizando o bloqueio de situação criado na tabela TIPO_BLOC_PEDIDO_SIT.
-* Além disso, deverá haver um retorno (feedback) para o usuário, informando que o seu pedido não foi integrado, e está novamente disponível no portal para revisão.
-* O pedido 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:
-# Re-aprovação do pedido para nova tentativa;
-# Exclusão do pedido, caso o usuário escolha pelo cancelamento;
-# Tramitação do pedido, para reenvio ao vendedor.
-== Cenários ==
-=== 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').
-* 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 2 (Pedido não efetivado e Pendente) ===
-Neste cenário, o pedido possui alguma pendência.
-* 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 ===
-[[arquivo:fluxograma1.png|frame|Fluxo de processos de gatilho de retorno]]
-* O vendedor, ao efetivar o pedido, não retornou pendências. Portanto, ele será aprovado e subirá para integração.
-* Se houver falha na integração, esta falha ficará registrada na tabela ACK.
-* A falha criará a pendencia falha de integração, disparando o trigger que abrirá uma tramitação de pendência, retornando o pedido para o portal.
-* Será disparado uma notificação de pendência para o gestor;
-* O pedido voltará com o status de pendente, retornando ao gestor.
-* O gestor poderá reenviar o pedido numa nova aprovação, ou
-* cancelar o pedido, ou
-* Enviar para tramitação, devolvendo o pedido ao vendedor.
-=== Cenário 2 (Pedido Efetivado e Pendente, enviado para aprovação pelo Gestor) - sem Integração ERP ===
-* O gestor recebeu o pedido do vendedor com pendencias, e envia para aprovação. Nesse momento ele será submetido à integração.
-* Se houver falha na integração, esta falha ficará registrada na tabela ACK.
-* A falha criará a pendencia falha de integração, disparando o trigger que abrirá uma tramitação de pendência, retornando o pedido para o portal.
-* Será disparado uma notificação de pendência para o gestor;
-* O pedido voltará com o status de pendente, retornando ao gestor.
-* O gestor poderá reenviar o pedido numa nova aprovação, ou
-* cancelar o pedido, ou
-* Enviar para tramitação, devolvendo o pedido ao vendedor.
-<!--Neste cenário, o pedido foi efetivado e já aprovado pelo supervisor, mas houve uma '''falha ao integrar o pedido à ERP''':
-* O pedido não será integrado, pois a falha apresentada será considerada perene;
-* O pedido, por já estar aprovado na plataforma, não pode retornar para o usuário para edição, para ser corrigido/cancelado.
-Nesta situação, os passos que deverão ser seguidos para o cenário desejado serão:
-# O pedido deverá registrar a pendência (Falha na Importação) após a décima tentativa de integrar '''e retornar este mesmo erro''';
-# Caso o pedido esteja com a pendência (Falha na Importação), deverá disparar um gatilho (trigger) para que ele cesse de tentar integrar.
-# Esta pendência irá retirar o pedido da fila de integração e alocará de volta ao portal, com o status de pendente.
-# Com este status, o usuário poderá fazer edições no pedido, para verificar eventuais ajustes, ou cancelar o mesmo.-->
-== 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 ===
-{| class="wikitable"
-! 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 ===
-{| class="wikitable"
-! Setor
-! Aprovado Por
-! Data
-! Assinatura
-|-
-| Gerente TI - Cliente || ___________________ || ___/___/_____ || ________________________
-|-
-| Gerente de Projeto - Cliente || ___________________ || ___/___/_____ || ________________________
-|-
-| Gerente Comercial - Cliente || ___________________ || ___/___/_____ || ________________________
-|-
-|}

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

Edição atual tal como às 18h26min de 19 de abril de 2021

Menu de navegação

Pesquisa