1180 Pedido Clientes/Case Situacao Pedidos Alteracao Indevida
O Touch Comp ERP atualiza automaticamente e dinamicamente a 108 Situacao Pedidos do 1180 Pedido Clientes em diversas situações. Como exemplo, podemos citar quando um pedido é bloqueado, quando é faturado e produzido. A atualização ocorre quando algum evento é disparado, especialmente nos recursos chaves. Ao enviar uma nota fiscal pelo 247 Lote Faturamento e a nota fiscal for autorizada, a situação do pedido será automaticamente autorizada conforme a situação informada em 107 Opcoes Faturamento.
Esse dinamismo, especialmente quando não configurado corretamente e em empresas que possuem inúmeras situações de controle interno, podem resultar em problemas, especialmente quando o sistema "volta" uma situação de pedido para uma situação considerada indevida. A questão da situação indevida está associada a questão processual do cliente do que propriamente o que está cadastrado.
Afinal, para o sistema as situações são apenas situações com um texto associado e que ele deve alterar automaticamente quando determinado gatilho/situação determinar.
Para resolver este problema, criamos um campo em 108 Situacao Pedidos chamado Ordem Avanço. Esta ordem deve determinar em ordem crescente, o avanço do pedido dentro do processo da empresa:
1 - Pedido Recebido
2- Pedido Liberado
3 - Pedido Produzido
4- Pedido Faturado
5- Pedido Entregue
Acima temos apenas um exemplo hipotético de situações e o respectivo indice de avanço. Você poderá ter inúmeras situações cadastradas. Neste caso o importante é a ordem de avanço.
Problema da Ordem Avanço
Agora, depois desta introdução, vamos ao problema, considerando as situações acima, mas sem ordem avanço:
0 - Pedido Recebido
0- Pedido Liberado
0 - Pedido Produzido
0- Pedido Faturado
0- Pedido Entregue
Agora imagine que depois do Pedido Entregue, o usuário precise de editar o Evento de Produção vinculado ao item do pedido, para corrigir apenas a informação de data/hora de produção. Ao salvar o evento de produção, o ERP irá validar novamente se o item do pedido foi totalmente produzido e se sim irá atualizar a situação do Pedido, conforme ocorre de praxe. Ao verificar que a ordem de avanço é a mesma, ele entende que pode atualizar e logo, atualizado pedido com situação Entregue para Produzido.
Você deve se perguntar que o sistema deve considerar um pedido 'faturado' e não poderia atualizá-lo. Novamente a situação é apenas um texto. Se considerarmos o vinculo com nota fiscal no módulo de produção, traremos para a produção uma 'preocupação' e vinculo que não é do modo de produção. Alem disso, o exemplo é de faturamento, mas existem dezenas de outras combinações e vinculações que um pedido pode ter, além de cada empresa determinar sua politica e processos.
Por isso criamos a ordem de avanço, para respeitar o processo de cada empresa, independente de vinculações.
Depurar o problema
Portanto, quando o sistema 'volta uma situação' anterior que não deveria, deve-se verificar as situações cadastradas e a ordem de avanço, e especialmente os gatilhos que estão sendo ativados e quando, para solucionar o problema.
O primeiro ponto é verificar pelo log do pedido se a situação foi modificada manualmente por algum usuário. É importante investigar também, se algum usuário não está usando a senha pelo outro usuário e vice-versa(senhas compartilhadas ou emprestadas). Se o usuário usa o sistema WEB, e está liberado externo, ele poderá utilizar recursos web que também criam gatilhos para a troca de situações.
Até hoje, todos os problema que identificamos estão associados a ordem de avanço, ou uma dificuldade dos clientes em entender seu funcionamento e usar como deveria. Nos momentos que ela foi utilizada, não tivemos mais relatos desta situação.
