Mudanças entre as edições de "Cancelamento de Pedidos"
| Linha 54: | Linha 54: | ||
| − | 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 | + | 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 documento. | * O pedido não será integrado, pois a falha apresentada é perene, ou seja, as schedules não farão subir o documento. | ||
Edição das 11h43min de 15 de abril de 2021
Histórico de Alterações
| Data | Quem | Comentários |
|---|---|---|
| 13/04/2021 | João Ramon | Criação do documento |
Necessidade
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
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.
Implementação
Cenários
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 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 documento.
- O pedido, por já estar aprovado na plataforma, não pode retornar para o usuário para edição, para ser corrigido/cancelado/deixado pendente.