Correção de Pedido Duplicado na Consulta F5 Vendas NT 0555/2026
Resumo da Nota Técnica
Foi corrigido um problema na consulta F5 Vendas, em que pedidos vinculados a uma NFC-e e posteriormente a uma NF-e eram exibidos em duplicidade na grade de pedidos. O ajuste altera a forma como a tabela NFISCAL é relacionada à consulta, impedindo que um mesmo pedido seja retornado duas vezes quando possui documentos fiscais diferentes vinculados. Observação: Durante a análise foi identificado um erro de cálculo de IBS/CBS ao tentar reproduzir o cenário na versão mais recente do sistema. Esse erro é um retorno da SEFAZ e não faz parte desta correção.
Detalhes da Nota Tecnica
Problema identificado
Na consulta F5 Vendas (FCons_PedidoB), um mesmo pedido era apresentado duas vezes na grade de consulta.
O cenário ocorria quando o pedido possuía:
• Uma NFC-e emitida.
• Uma NF-e emitida posteriormente.
Como exemplo, foi identificado o pedido 094695, vinculado à NFC-e 003323 e à NF-e 000944.
Durante a validação foi constatado que:
• Na tabela PEDIVE existia apenas um registro do pedido.
• No aplicativo Integrado também existia apenas um pedido no gerenciamento.
• Na tabela NFISCAL havia dois registros, um para cada documento fiscal vinculado ao pedido.
Causa do problema
A consulta utilizava um LEFT JOIN com a tabela NFISCAL utilizando a condição:
SQL
NF_TIPO LIKE 'N%'
Essa condição retornava tanto registros de NF-e quanto de NFC-e, fazendo com que o pedido fosse associado a dois registros diferentes.
O DISTINCT da consulta não eliminava a duplicidade porque os campos NF_NUMERO e NF_STATUSNFE possuíam valores diferentes para cada documento.
Além disso, os CalcFields preenchiam separadamente os campos de número da NFC-e e da NF-e, fazendo com que as duas linhas aparentassem representar o mesmo pedido.
Correção implementada
Foi alterada a consulta localizada em UCons_PedidoB.pas, no método FormActivate.
As alterações foram:
• O LEFT JOIN passou a utilizar:
SQL
NF_TIPO IN ('NC','N1','N2','N3','N4','N5','N6','N7','N8','N9')
substituindo a condição anterior com LIKE 'N%'.
• A cláusula WHERE também foi ajustada para utilizar a mesma lista de tipos de documento, além de considerar:
o CE;
o IS NULL, garantindo que pedidos sem documento fiscal ou somente com NF-e continuem sendo exibidos normalmente.
Resultado da correção
Após a alteração:*
• Pedidos com NFC-e e NF-e deixam de aparecer duplicados na consulta F5 Vendas.
• Pedidos apenas com NF-e continuam sendo exibidos normalmente.
• Pedidos sem documento fiscal permanecem visíveis na consulta.
Configuração
A correção entra em funcionamento automaticamente após a atualização do aplicativo Balcao.
Questões:
1. Em qual situação o pedido era exibido duas vezes na consulta F5 Vendas? • A) Quando o pedido possuía apenas uma NF-e. • B) Quando o pedido possuía uma NFC-e e uma NF-e vinculadas. • C) Quando o pedido ainda não possuía documento fiscal. • D) Quando o pedido era cancelado. 2. Qual era a causa da duplicidade na consulta? • A) Existiam dois registros do pedido na tabela PEDIVE. • B) O aplicativo Integrado criava dois pedidos automaticamente. • C) O LEFT JOIN utilizava NF_TIPO LIKE 'N%', retornando mais de um documento fiscal. • D) O DISTINCT não era utilizado na consulta. 3. Qual foi a principal alteração realizada na consulta? • A) Remoção da tabela NFISCAL da consulta. • B) Alteração do LEFT JOIN para utilizar NF_TIPO IN (...) e ajuste da cláusula WHERE. • C) Inclusão de um novo parâmetro para controlar a exibição dos pedidos. • D) Alteração da tabela PEDIVE para impedir registros duplicados.