Objetivo da mudança: O objetivo foi implementar um controle de concorrência para evitar a duplicação de lançamentos na “Conciliação Bancária”. Foi identificado que era possível abrir duas instâncias da mesma tela, selecionar o mesmo lançamento do extrato em ambas e gerar duas movimentações bancárias para um único evento. Foi adicionada uma trava que, ao iniciar a…
Continue lendoVersão 30.74.150
Objetivo da mudança: O objetivo desta alteração técnica foi solucionar um grave problema de performance causado pelo robô de previsão de estoque. A rotina mantinha uma transação de banco de dados única e extremamente longa, gerando travamentos (locks) que se estendiam por vários minutos e impactavam toda a operação do sistema. A lógica foi refatorada…
Continue lendoObjetivo da mudança: O objetivo desta alteração foi aprimorar o processo de retorno bancário do “Itaú (341)”. Foi implementada uma regra para que, ao processar um arquivo de retorno que contenha a ocorrência de código ’32’ (Título Protestado), o sistema grave automaticamente no histórico da duplicata a palavra “Prostetado”. Esta automação garante que o status de…
Continue lendoObjetivo da mudança: O objetivo foi adequar o sistema para enviar as informações de rastreabilidade de produtos no XML da NFe, conforme a Nota Técnica 2016.002. Foi criada uma nova configuração que, quando ativa, habilita a geração das tags <nLote> (número do lote), <dFab> (data de fabricação) e <dVal> (data de validade) para cada item que possuir lote informado na venda….
Continue lendoObjetivo da mudança: O objetivo foi desenvolver uma nova integração para automatizar o lançamento de despesas no contas a pagar, especificamente para os gastos com combustível realizados via “Ticket Log”. Foi criada uma nova rotina que importa um arquivo de extrato fornecido pela Ticket Log e, com base nele, gera automaticamente os títulos individuais no contas…
Continue lendoObjetivo da mudança: O objetivo desta alteração foi refatorar e modernizar a rotina de “Conciliação de Cartões”. A lógica de processamento foi extraída do executável principal e encapsulada em DLLs (Dynamic Link Libraries) separadas para cada operadora de cartão. Esta arquitetura modular, similar à já utilizada para importação de arquivos, facilita a manutenção, agiliza a implementação…
Continue lendoObjetivo da mudança: O objetivo foi aumentar a transparência e a rastreabilidade do cálculo da GNRE-ST. As rotinas de entrada de mercadoria que calculam a GNRE agora salvam a memória de cálculo (base de cálculo, alíquotas, MVA, etc.) em um novo campo. Posteriormente, na “Manutenção do Livro Fiscal”, essa memória de cálculo pode ser consultada através…
Continue lendoObjetivo da mudança: Como complemento ao requisito 392695, o objetivo desta alteração foi aprimorar a lógica de busca de pedidos no “Robô Fulfillment” para operações de “Cross Docking”. Foi estabelecida uma nova hierarquia de busca para localizar o pedido de venda original a ser baixado. O robô agora tentará primeiro localizar o pedido utilizando o PACK_ID da nota fiscal. Caso…
Continue lendoObjetivo da mudança: O objetivo desta alteração foi implementar uma trava de segurança para impedir um cenário operacional indevido. Foi identificado que era possível, na rotina de “Outras Saídas” para fornecedor, marcar a operação como “venda presencial”, o que é conceitualmente incorreto e gerava inconsistências, como o cálculo indevido de frete. Para prevenir o problema,…
Continue lendoObjetivo da mudança: O objetivo desta alteração técnica foi solucionar a lentidão na rotina de “Inclusão de Romaneio”, visando reduzir o tempo total de gravação para menos de 20 segundos. A análise identificou que transações longas e consultas individuais dentro do loop de gravação eram a causa do problema. A rotina foi refatorada para utilizar gravação…
Continue lendo