Cancelamento de Pedidos

Histórico de Alterações

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

Necessidade

Após a elaboração de um pedido, o vendedor enviará para efetivação. Se não houver pendências, ele será enviado diretamente para integração. Caso contrário, será encaminhado a um gestor para aprovação. A partir daí, será feito o envio à ERP. Nas duas situações, há a possibilidade deste pedido não ser integrado, por conta de alguma falha e, neste caso, não poderá ser mais editado, por já estar efetivado e aprovado. Dessa forma, o pedido não pode ser editado, nem cancelado, apenas existindo. Faz-se necessário, portanto, criar um meio para que este pedido possa ser novamente disponibilizado para edições pelos usuários.

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 seja novamente tornado pendente. O processo deverá ser realizado por meio de um gatilho (trigger), sendo acionado logo após o registro da falha. Após este disparo, o pedido será disponibilizado para o gestor com o status de pendente, possibilitando que ele possa reenviar para aprovação, cancelar o pedido ou reenviar ao vendedor para eventuais ajustes. No processo, ainda deve existir um recurso que, quando o pedido for retornado ao portal, o vendedor deva ser informado que o pedido não foi integrado, e que necessita de 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 ao vendedor;
Após as modificações do usuário, o pedido será novamente submetido à integração para o gestor. 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 fique 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

`CD_TIPO_BLOC`	`DS_TIPO_BLOC`	`CD_TIPO_PEDENCIA`
XX	Falha de integração	NULL

Cenário 1 - Pedido retornado para cancelamento

Fluxo de processos de gatilho de retorno

O pedido, após aprovado, será submetido para integração.
O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
A falha criará a pendencia falha de integração, disparando o trigger que abrirá uma tramitação de pendência, tornando o pedido ao status de pendente.
Será disparado uma notificação de pendência para o vendedor;
O pedido voltará com o status de pendente, retornando ao gestor.
O gestor procede com o cancelamento do pedido, excluindo o pedido de forma permanente.

Cenário 2 - Pedido retornado para reenvio

O pedido, após aprovado, será submetido para integração.
O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
A falha criará a pendencia falha de integração, disparando o trigger que abrirá uma tramitação de pendência, tornando o pedido ao status de pendente.
Será disparado uma notificação de pendência para o vendedor;
O pedido voltará com o status de pendente, retornando ao gestor.
O gestor faz uma nova aprovação no pedido, enviando-o novamente para integração.

Cenário 3 - Pedido retornado e devolvido ao vendedor

O pedido, após aprovado, será submetido para integração.
O processo de integração apresentou uma falha de integração, registrando na tabela ACK_LOG_TABLE.
A falha criará a pendencia falha de integração, disparando o trigger que abrirá uma tramitação de pendência, tornando o pedido ao status de pendente.
Será disparado uma notificação de pendência para o vendedor;
O pedido voltará com o status de pendente, retornando ao gestor.
O gestor faz seleciona a função "tramitação do pedido", devolvendo o assunto ao vendedor para eventuais modificações.

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.

[RN5] - A opção de disparo do trigger de retorno deverá ter opção de habilitação por parte do cliente. Visto que, a princípio, o recurso dificilmente estará habilitado para todos os clientes, este será paulatinamente sendo implantado, conforme as necessidades forem surgindo.

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