Cancelamento de Pedidos

Histórico de Alterações

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. então seguirá o caminho normal, ir pra 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, mesmo depois de várias tentativas sucessivas. 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'.

Solução

Para atender à demanda solicitada, deve ser possível que este pedido, após ter tentado integrar por um determinado número de vezes à ERP, retornar para a edição no portal, sob o status de pendente e não efetivado. Assim, 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 cliente deseje. No processo, deve existir uma rotina no meio do caminho da tramitação do pedido para que, quando o pedido for retornado ao portal, o vendedor/gestor deva ser informado que o seu pedido não foi integrado, e que necessita revisões.

Implementação

Após a conclusão dos seguimentos das tramitações normais do pedido (efetivação e aprovação), o pedido estará disponível para integração.
Após 10 (dez) tentativas de integração, deverá ser acionado um gatilho de retorno (trigger) para que este pedido possa retornar ao portal, com status de não efetivado e pendente.
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:

Exclusão do pedido, caso o usuário escolha pelo cancelamento;
Nova efetivação e aprovação, caso o usuário tenha feito modificações no pedido.

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.

É necessária criar uma pendência dentro da tabela TIPO_BLOC_PEDIDO_SIT, para este tipo de situação.

Cenários

Cenário 5 (Pedido Efetivado e Aprovado) - sem Integração ERP

Neste cenário, o pedido foi efetivado e já aprovado pelo supervisor, similar ao cenário 4, discutido anteriormente. A diferença é que, para este cenário, contemplamos uma falha ao integrar o pedido à ERP:

O pedido não será integrado, pois a falha apresentada é perene, ou seja, as schedules não farão subir o pedido.
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) na décima tentativa do schedule;
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 não efetivado e pendente.
Com este status, o usuário poderá fazer edições no pedido, para verificar eventuais ajustes, ou cancelar o mesmo.
Caso opte por cancelar, o pedido será excluído.
Caso opte por editar, será novamente efetivado e, se estiver sem pendências, será novamente submetido à integração. Caso haja alguma pendência, deverá ter a aprovação de um gestor, e subirá para integração após aprovação.

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] - 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).

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	___________________	___/___/_____	________________________