Mudanças entre as edições de "Cancelamento de Pedidos"
Linha 101: | Linha 101: | ||
# O pedido deverá registrar a pendência (Falha na Importação) após a décima tentativa de integrar '''e retornar este mesmo erro'''; | # 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. | # 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 | + | # 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. | # Com este status, o usuário poderá fazer edições no pedido, para verificar eventuais ajustes, ou cancelar o mesmo. | ||
− | + | ||
− | |||
[[arquivo:fluxo.png]] | [[arquivo:fluxo.png]] |
Edição das 13h49min de 16 de abril de 2021
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. 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'.
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
CD_TIPO_BLOC
|
DS_TIPO_BLOC
|
CD_TIPO_PEDENCIA
|
---|---|---|
XX | Falha de integração | NULL |
Cenário (Pedido Efetivado e Aprovado) - sem Integração ERP
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] - A retorno do pedido só será feito após 10 tentativas de integração, e retorno da pendência 'falha na integração', ou qualquer pendência que não permita integração do pedido.
[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 | ___________________ | ___/___/_____ | ________________________ |