Histórico da Página

01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

Foi identificada a necessidade de melhorar o controle dos pedidos, evitando problemas com numeração desatualizada e registros antigos que permanecem no sistema.

O RPM apresentava quedas de performance causadas por chamadas excessivas de conversão de moeda, inclusive para valores zerados. O envio de e-mails de erro ocorria sem qualquer controle de frequência, gerando volume desnecessário de notificações. Os arquivos de log também cresciam sem limite, sem nenhuma política de rotação.

Na atualização de pedidos, o processo falhava sempre que não havia token disponível para o usuário, além de os logs não oferecerem informações suficientes para análise de problemas. A rotina OFIA511 (PMM) também apresentava inconsistências nos cálculos de custo, venda e inventárioTambém foi observado que, ao trabalhar com pedidos já existentes, podem permanecer resíduos de dados anteriores.

03. SOLUÇÃO

Foi implementada a atualização automática dos números de pedidos, mantendo a sequência correta conforme os registros.

No RPM, foram eliminadas as chamadas desnecessárias de conversão de moeda e o envio de e-mails de erro foi limitado a um por dia. Os logs passaram a usar rotação automática, evitando o acúmulo descontrolado de arquivos.

Na atualização de pedidos, o processo agora tenta utilizar tokens de outros usuários quando o token principal não está disponível, reduzindo significativamente as falhas. Foi criada a rotina de Atualização dos pedidos JD automáticos (OFIA610) para atualização de pedidos de fábrica e incluídos novos logs para facilitar o acompanhamento e a análise do processo.

Na rotina OFIA511 (PMM), os cálculos de custo, venda e inventário foram revisados e corrigidosAo identificar pedidos já existentes, o sistema realiza a limpeza dos resíduos relacionados, evitando inconsistências.

04. DEMAIS INFORMAÇÕES

05. ASSUNTOS RELACIONADOS

        Não há.

...