5

0

Problema:
Notas fiscais com erros não mapeados permaneciam em loop de tentativa de emissão pelo robô, sem sucesso, causando retrabalho e consumo desnecessário de recursos.

Solução:
Implementada lógica para bloquear o reenvio de notas com erros não mapeados, garantindo que apenas erros conhecidos continuem no fluxo de reautorização.

• Erros mapeados não foram impactados.
• Erros não mapeados são excluídos do fluxo, evitando tentativas repetitivas.

Problema:

Os campos CodigoPedidoParceiro e CodigoRastreioParceiro estavam sendo gravados incorretamente no banco do retaguarda, causando falhas na consolidação dos pedidos vindos do HUB (iFood, Keeta, Rappi). Além disso, o novo campo IdPedidoParceiro não estava sendo preenchido conforme especificado.

Solução:

Foi realizado ajuste no mapeamento dos campos e criada a lógica para gravar corretamente os valores no banco. Após os testes, os dados passaram a aparecer no retaguarda para Consolidation V1.
Para Consolidation V2, será criada uma nova tarefa para corrigir no SVO 2.0 (FOOD-45007).

Problema:

O cálculo e a impressão das quantidades de itens em pedidos de delivery estavam incorretos quando o item principal possuía quantidade superior a 1 e continha subitens. A lógica não replicava corretamente os subitens proporcionalmente, causando divergência entre pedido integrado e impressão.

Solução:

Foi ajustada a lógica de cálculo e impressão para:

• Replicar corretamente os itens conforme a quantidade vendida.

• Garantir que subitens sejam replicados proporcionalmente à quantidade do item pai.

  Após correção, testes em HOM confirmaram o comportamento esperado.

Problema:

O AgentContingencia estava abrindo múltiplas instâncias no gerenciador de tarefas, causando sobrecarga no servidor. Isso ocorria porque não havia limitação de recursos nem controle adequado do processo de inicialização.

Solução:

• Limitação de recursos via configuração no arquivo .ini (tag enable=true por padrão).

• Garantia de que o Agent seja iniciado pelo Launcher.

• Inclusão das alterações no instalador SVC e no setup para distribuição.

Problema:

Na tela de Configurações TEF, o campo CNPJ da Loja não estava sendo carregado automaticamente do banco e permanecia editável, permitindo alterações manuais e aumentando risco de inconsistência. Além disso, não havia lógica clara para fallback entre storeDetails.cnpj e storeCNPJ.

Solução:

• Carregar automaticamente o CNPJ a partir do MongoDB.

• Tornar o campo readonly + disabled, prevenindo edição manual.

• Aplicar lógica de fallback (prioriza storeDetails.cnpj, usa storeCNPJ como alternativa).

• Garantir que a funcionalidade geral do TEF permaneça íntegra após as alterações.