O esquema contábil da sincronização

Problemas

· A venda inteira em "otros ingresos". Se o primeiro item cair nessa conta — o que acontece com produto.idgrupo_produto vazio —, todas as demais linhas vão para ela: a troca pela conta do grupo só acontece enquanto a conta corrente não for essa. Costuma ser um produto sem grupo, não todos. É do sistema antigo.

· Um crédito de 999.999.999 é uma sentinela: no Brasil, crédito negativo é substituído por esse número para estourar aos olhos de quem confere. Não é o valor do documento.

· Asiento que não fecha fora do BR e do PY: lá o desconto é debitado e não sai do valor da nota. É o que o sistema antigo faz; na prática aqueles países não usam a coluna.

· Pulados: doação — não contabiliza · venda a funcionário não contabiliza na Bolívia · tipo de faturamento 11116 não contabiliza no Brasil · grupo de produto … sem conta de crédito.

Problemas

· Provisão e reversão só com a chave SINCRONIZA_VENDA_EXPORTACAO_PROVISAO de system_config valendo "1" (sem a chave, não rodam) — só o fvx roda sempre. Até 12/09/2026 o gate era "fora de 003, 004 e BFC-USA"; o sistema antigo trocou pela chave e o porte acompanhou. O câmbio e a coluna de data continuam pelo teste antigo.

· Provisão sem reversão. Emissão e cumprido caem em meses diferentes, e uma venda emitida e nunca cumprida deixa a provisão de pé. Procurar a reversão no mês da emissão não a acha.

· Pulados: cumprido em mês fechado · documento sem numeração fiscal.

Problemas

· Este módulo faltava inteiro no porte até 03/09/2026 — e a comparação com o sistema antigo não podia tê-lo achado: ela percorre os módulos do porte; um módulo que não existe aparece como nada, não como diferença. Em janeiro/2026 são 1.759 linhas em 214 asientos.

· A nota de crédito inverte o lado, e os dois acumuladores não são simétricos: o total soma com IVA e a nota de crédito soma sem.

· Linha inválida é descartada, o grupo não — despesa sem conta é pulada e as demais formam o asiento.

· Pulados: sem numero de despacho · despesa de despacho … sem conta.

Problemas

· As contas são chumbadas por filial — oito lojas com o seu par. Filial nova cai no genérico e ninguém avisa.

· Um ramo que existiu e foi removido. Uma filial ganhou ramo próprio com base em 5.320 linhas da cópia de produção, e no mês seguinte, sincronizado pelo sistema antigo, as 395 linhas dela saíram no genérico — o executável do cliente não tem o ramo. Ressincronizar janeiro a junho hoje moveria 5.320 linhas.

· Gift card não gera asiento: ali não houve receita, e sim o resgate de um valor já recebido.

· Pulados: cupom sem data de fatura · … sem par de contas do ticket.

Problemas

· Compra com XML do fornecedor tem outra origem de imposto. Havendo faturamento_compra_carne.xml_fornecedor, o ICMS vem do vICMS do XML — que é o total da nota — e é deduzido só da primeira linha. Conferir item a item não bate.

· Três passadas, três desenhos. Compra, devolução no mercado interno e devolução de exportação têm tipos, conta de débito e histórico próprios.

· Pulados: compra sem data de emissão · título do próprio CNPJ (compra mismo RUC) · grupo de produto … sem conta · nenhum item com conta contábil.

Problemas

· Duas cotações no mesmo asiento. Frete, COLCAT, pedágio e frete lavado vivem em guarani e a compra pode estar em dólar: eles são convertidos pelo valor_cambio_desc, e a sobra vai para a linha de arredondamento do fim. É a origem das dúvidas de "por que sobrou essa linha".

· O rateio do desconto fecha na ÚLTIMA fatura — conferir fatura a fatura mostra a última "diferente".

· A cotação aqui é a do dia anterior por LITERAL, não pelo parâmetro de país.

· Pulados: compra sem data · comissão sem data de fatura · emitente … sem conta · centro de custo COLCAT sem conta de crédito.

Problemas

· A conta de débito não está na compra, está no centro de custo — e qual coluna dele vale depende do tipo de faturamento. Procurar a conta no documento não a acha.

· O sistema antigo tem OITO passadas e só DUAS estão vivas. As de 3 a 8 têm um desvio incondicional antes da consulta, e as tabelas que gravariam estão marcadas ali como "não está usando". Com elas fica de fora o módulo almoxarifado em curso inteiro.

· Um asiento que não fecha, e é erro de lançamento. Caso medido com falta de 32.941: um serviço de 80.000 com % IVA e % retenção trocados (70 e 10 em vez de 10 e 70). Com 70% a base cai fora de qualquer faixa e o módulo só tem conta para 10% e 5%. A correção é no documento, na tela 242.

· Pulados: a compra não tem produto nem serviço com valor · centro de custo … sem conta · crédito fiscal de IVA — centro de custo ….

Problemas

· Duas moedas no mesmo asiento — cada linha carrega o próprio par moeda/câmbio. Conferir por uma cotação só não fecha.

· A faixa de 5% é lançada na conta de IVA 10. Parece troca de coluna e não é: o sistema antigo manda as duas para a mesma conta e só muda o histórico.

· No FOB, o frete e o seguro debitam e creditam a MESMA conta — quem paga é o comprador, então o valor volta para a conta de custo em vez de virar dívida.

· O IVA da despesa sem fatura: vale o EXECUTÁVEL (decisão do usuário, 12/09/2026). O fonte manda debitar despSF + rep e creditar despSF + ivaSF + despCF; o executável que gravou a produção fez despSF − ivaSF + rep e despSF + despCF. As duas convenções fecham o asiento — pelo fonte, o IVA entra no custo e de novo na linha própria, inflando na mesma medida o custo e a dívida. Medido em dois despachos reais, nos dois módulos: 18.012.469 contra 2.688.859 no débito. O porte passou a gravar como o executável: o IVA sai do custo e o despachante é credor do líquido.

· Na Bolívia o acd separa a ADUANA do despachante pelo fornecedor de cada despesa (o emitente literal 1001269); as duas metades são debitadas em separado e o crédito vai inteiro ao despachante.

· Pulados: despacho sem data · sem numero de despacho · despacho com IVA maior que a despesa.

Problemas

· A segunda passada existe para um caso que ninguém lembra: o título cuja fatura é de um mês já fechado mas que só foi emitido agora. Ele não apareceu na primeira passada de mês nenhum e ficaria sem contabilizar para sempre.

· A data e o câmbio NÃO seguem a passada que achou o título. Cada um recalcula: usa a fatura quando ela é posterior à emissão ou posterior ao mês fechado — o que quase sempre escolhe a fatura. Tratar "achado pela segunda passada" como "usa emissão" produz asiento com a cotação de uma a duas semanas depois. Foi defeito real, corrigido em 03/09/2026.

· Pulados: documento sem data · sem conta do tipo de título · IVA retido — tem sincronização própria · empréstimo bancário — já lançado pelo módulo de empréstimos.

Problemas

· A conta de cheque é ANALÍTICA por conta bancária, não a sintética da filial — e é criada quando falta. Debitar a sintética direto era defeito, corrigido em 29/08/2026.

· A consulta AGRUPA por data_baixa, idconta_bancaria, idemitente, numero_cheque, idcentro_custo, idfinanceiro_emissao — mas o fb.id entra só no a pagar. No a receber, várias baixas do mesmo título no mesmo dia viram um asiento. Foi a causa de 4 "diferenças de valor" que não eram.

· A cotação é a do FIM DO MÊS ANTERIOR, não a do dia anterior.

· Baixa de empréstimo debita a conta do tipo de FATURAMENTO, não a do tipo de título — são dois ramos, e o porte só tinha um.

· A linha de resíduo de conversão esconde erro de valor: ela absorve qualquer divergência, e foi ela que fez asientos com a cotação errada "fecharem" sem sintoma.

· Pulados: baixa sem data de conciliação · a receber sem número de documento · devolução do exterior — o desconto já saiu no título principal.

Problemas

· O câmbio é DERIVADO, não lido. A retenção é calculada em moeda estrangeira (base ÷ 1,10 × 10% × % de retenção) mas o que se recolhe é um valor em guarani, já no comprovante. O sistema divide um pelo outro para o lançamento fechar exatamente no valor recolhido — e o resto vira as duas linhas de diferença cambial. Um câmbio "estranho" aqui é isso, não erro.

· A moeda e a data saem da ORIGEM quando a retenção não as tem: a coluna retencao_iva.tabela diz de onde veio — emissão, compra de gado, compra de carne, almoxarifado, fatura avulsa, despacho — e cada origem tem a sua coluna de data. Origem excluída, ou que não existe mais, pula o comprovante inteiro.

· Pulados: retenção sem data · a fatura de origem (…) não existe · câmbio derivado inválido · retenção sem base calculada e em moeda estrangeira.

Problemas

· A conta nem sempre é a do banco — só com conta_bancaria.tipo_conta = '1'. Nas demais valem as contas de trânsito: o dinheiro que saiu de um banco e ainda não entrou no outro. Medido num caso real: as duas pernas eram de trânsito.

· Uma armadilha do sistema antigo que o porte não tem. Lá o cursor lê a linha corrente como crédito e avança uma; se a primeira do par não for 113, ele não avança e lê os dois lados da mesma linha — asiento que debita e credita a mesma conta. Aqui as duas são agrupadas por idtransferencia e escolhidas pelo tipo.

· Pulados: a transferência não tem as duas pernas (…) · lançamento sem data.

Problemas

· Um asiento nem sempre é uma baixa. Confirmado nos dados: um coletivo com 103 baixas e um único asiento de 173.304.050.

· Quem representa o grupo é a PRIMEIRA linha na ordem da consulta, e dela saem o idfaturamento e o documento — não é a de menor id. Procurar o asiento pela primeira baixa que se vê na tela costuma não achar.

· O reencontro do cheque tem dez dias de folga (a compensação chega depois da baixa); o do coletivo é no mesmo dia, exatamente.

· A pagar sem número de cheque não concilia. Num tenant que não usa cheque isso deixa de fora todas as baixas a pagar — e é o esperado.

· A conta bancária tem fechamento PRÓPRIO (conta_bancaria.udf_contab), além da U.D.F. contábil.

· Cuidado ao comparar este módulo: uma rodada real do porte contamina a base — o sistema antigo pode não reconhecer o asiento que ela gravou e criar outro, deixando os dois vivos. Foi o que produziu 157 "diferenças" que eram resíduo nosso.

Problemas

· As duas pernas usam o MESMO idfaturamento (o número da transferência) — quem as separa é a tabela. O reencontro de um lado nunca acha o do outro, e procurar por idfaturamento sem filtrar a sigla traz os dois.

· Conta de CAIXA não concilia: com tipo_conta = '1' o dinheiro nunca esteve em trânsito, e a transferência já foi lançada inteira no ftb.

Problemas

· Cinco desenhos com a mesma consulta. 1118/11173/11174 é o comum; 1143 de terceiros (comissão inteira, com IVA, e juros em juros pagos); 1144 bônus (bruto contra bruto); 1163 e 1162 do exterior.

· BUG DO SISTEMA ANTIGO, reproduzido: um asiento que não fecha. No ramo comum ele calcula líquido − IVA − comissão, subtraindo um IVA que o valor_liquido da parcela já não contém. O ramo de terceiros, uma linha acima, tem a forma certa. Medido: faltam 1.036.430 num empréstimo real. O porte segue o fonte, e por isso esse asiento aparece com "Fechou? NÃO".

· Empréstimo SEM parcela lançada é pulado. O LEFT JOIN traz a linha com os campos de parcela nulos, e como os valores estão no cabeçalho mas o líquido sai das parcelas, o asiento sairia zerado. Foi o único delta real de uma rodada inteira de agosto.

Problemas

· O acréscimo entra na ÚLTIMA fatura, não em linha própria.

· Faturas menores que o bruto creditam a sobra na conta de exportação. Conferido num asiento real: 18 créditos ao cliente e um de 17.702,17 nessa conta — porque a 19ª distribuição foi acrescentada depois da contabilização.

· O documento da linha de crédito é o do TÍTULO, não o swift. E a diferença cambial sai zero quando a distribuição não tem faturamento.

· Pulados: cobrança sem data · sem comprovante (…).

Problemas

· A nota de crédito (tipo_doc = 'NC') INVERTE os lados — todo o asiento.

· O revés não sai sempre. Só quando a fatura não é importada e o tipo de título admite reversão. No Brasil nunca há reversão, e numa transportadora paraguaia também não; nos demais quem decide é o tipo de título (frete não reverte). Procurar o far de uma fatura brasileira é procurar o que não existe.

· Dois ramos do sistema antigo são código morto: os que tratariam a fatura excluída, já que a consulta filtra excluido <> 'T'.

· Pulados: fatura sem data · fatura sem financeiro · fatura com asiento manual e sem contas de centro de custo · fatura com conta de valor bruto e sem conta de valor líquido.

Problemas

· O custo NÃO sai da saída. Ele vem da função custo_almox_si; o valor_total gravado inclui IVA e a própria consulta o traz apelidado como custo_total_com_iva — separado, e sem uso. Comparar o asiento com o valor da saída não bate, e está certo.

· Débito por linha, crédito acumulado — e é no acúmulo que mora a única diferença cambial do módulo: o débito converte linha a linha e o crédito converte a soma.

· A exclusão de uma saída, no sistema antigo, apaga o asiento do DIA INTEIRO — sem filial e sem id. Uma saída excluída derruba a contabilização do dia da empresa toda. O porte não reproduz isso; está marcado como decisão pendente.

· Este módulo levava um minuto POR DIA até 01/09/2026 — a coluna excluido faz parte de um índice, então o MySQL materializava os candidatos antes de atualizar. Hoje o apagar é em duas etapas.

· Pulados: Subgrupo sem conta de Débito … · Subgrupo sem conta de Crédito ….

Problemas

· A ordem dos dois arredondamentos muda centavos — é ROUND da divisão e depois a alíquota.

· Uma janela de 2022 parte a faixa de 10 ao meio no tcv: entre 01/08 e 31/12/2022 o imposto da carga era calculado a 5% e o resto dividido em duas metades, uma tributada e outra isenta. Não é regra viva — é uma medida do governo paraguaio, portada porque refazer aqueles meses tem de reproduzir o que foi feito.

· O corte de 01/07/2017 no tcv saiu do legado em 13/09/2026, e com ele os de 01/04/2015 (emissão e baixa), 31/03/2015 (período) e 30/11/2018 (consumo em FRIGO).

· Um deslize do sistema antigo, corrigido aqui: no fal, quando a conta já é analítica, a conta de débito fica com o valor da iteração anterior — o ramo equivalente só tem um comentário. O gêmeo sal faz a atribuição que falta.

· fal não pôde ser exercitado: faturamento_transp_almox não existe em nenhum dos bancos que temos. O módulo se declara indisponível em vez de estourar.

· Pulados: saída sem data de emissão · sem conta de crédito — centro de custo … · transferência entre sucursais.

Problemas

· A mesma despesa aparece duas vezes, e não é duplicidade — na fatura ela é repasse ao cliente, no ftd ela é custo. São dois fatos.

· O ftd vai na data da NOTA DA DESPESA, que pode cair em outro mês que o da fatura.

· A "diferença cambial" não é a diferença do asiento. O sistema antigo acumula dois totais à mão que não são os do asiento — o IVA entra no débito embora seja crédito, e da conta 1162 só uma parte entra no crédito. É essa conta, e não o desequilíbrio real, que decide se sai linha de diferença. Reproduzido como está.

· NÃO PÔDE SER EXERCITADO: faturamento_transportadora tem 2 linhas no banco de homologação, as duas excluídas e sem data. É módulo de outro tenant.

· A janela de 2022 aqui começa em 14/07, e no transporte de carne em 01/08. Não é engano de leitura: os dois métodos têm a mesma regra com datas diferentes.