gtiandClaude Sonnet 5
8f3dcaada9
Z.1: KB conflict counts were reported as ROW counts (kb_knowledge rows), not DISTINCT GTIN counts - a single conflicted product with 2 competing NCM candidates produces 2 rows, doubling the apparent conflict count. Real number, measured directly in production: 262 distinct GTINs in CONFLICT (all under knowledge_key=ncm), matching the ~264 baseline closely - no real growth, just a row-vs-GTIN counting mismatch in the earlier report. Z.3: corrected the Missão 4 claim that NFCE_ITENS was the "fonte encontrada" for what PIS/COFINS was actually transmitted - that overstated certainty. Relabeled PISCOFINS_FONTE_TRANSMITIDA = NÃO_CONCLUSIVO in docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md and both dossiê copies: a blank NFCE_ITENS column is equally consistent with "nothing was transmitted" and "the SGV transmitted a value in the XML but never wrote it back to that column" - we cannot tell without the actual XML. Z.4: docs/AUTOFILL_SAFE_3_CELULAS_V1.md - table of the 3 real AUTO_FILL_SAFE cells (000801/000802 CFOP, 000697 IPPT) with proposed value, field_contract rule and concrete evidence for each. Z.5: docs/NCM_27_BLOCKED_PRODUCTS_V1.md now marks the 15 test/garbage-named products as "produto de teste" in the kb.attest queue (still counted in coverage, just lower priority); the 3 legacy + 5 out-of-table NCMs are flagged for reclassification once the official NCM catalog (Fase 2 of this mission) is loaded and approved. Z.6: CLAUDE.md records independent Hub/Agent versioning (docs/VERSIONING.md) as the adopted standard going forward. No schema/migration change. No Firebird write anywhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.5 KiB
PIS/COFINS efetivamente transmitido — onde está guardado (Missão 4 / Bloco C)
C.1/C.2 — busca por XML/BLOB e tabelas de imposto por item
Levantamento de todas as colunas BLOB e de todas as tabelas com "XML"/"IMPOSTO"/"TRIBUT" no nome, nos 5 bancos (GTI/Agent 2, CONSTRUCAO, MMMODAS, RINCAO, UNIAO) — mesmo schema nos 5:
- Nenhuma tabela guarda o XML autorizado da NFC-e/NF-e.
XML_MESexiste, mas só guarda o caminho do arquivo no disco local da máquina onde o SGV roda (CAMINHO_XML,C:\GTI SISTEMAS\Schemas\...\xml\<ano>\<mes>\...-nfe.xml) — o conteúdo do XML em si não está no banco, só a referência ao arquivo. Esse arquivo está fora do escopo desta missão (sistema de arquivos de uma máquina de cliente, não um banco, e não temos acesso a ele). CARTA_CORRECAO.XMLeMDFES_XML.*existem, mas são para Carta de Correção e Manifesto de Documentos Fiscais (MDF-e, transporte de carga) — não para o NFC-e/NF-e em si.DEOLHONOIMPOSTOé a tabela oficial da Lei "De Olho no Imposto" (IBPT) — uma tabela de referência nacional por NCM (carga tributária aproximada nacional/importada/estadual/ municipal, para exibir no rodapé do cupom), não o PIS/COFINS realmente aplicado por item.NFCE_ITENStem as colunasCST_PIS_COFINS,ALIQUOTA_PIS,BASE_CALCULO_PIS,VALOR_PIS,ALIQUOTA_COFINS,BASE_CALCULO_COFINS,VALOR_COFINS— colunas simples (não BLOB), presumivelmente preenchidas pelo SGV ao montar a nota. Mas isso é uma suposição sobre como o SGV funciona internamente, não uma prova: essas colunas estão em branco para praticamente todos os itens (exceto o episódio isolado de dezembro/2022 no Agent 2), e sem o XML de verdade para comparar, não sabemos se a coluna em branco significa "nada foi transmitido naquele item" ou "o SGV calculou e transmitiu um valor no XML mas nunca gravou de volta nessa coluna do banco". As duas explicações são compatíveis com os mesmos dados.
PISCOFINS_FONTE_TRANSMITIDA = NÃO_CONCLUSIVO (corrigido nesta missão — a Missão 4 chamou
NFCE_ITENS de "fonte encontrada", o que superestimava a certeza: é a melhor evidência
disponível no banco, não uma confirmação do que foi de fato transmitido). Tabelas inspecionadas
e descartadas como fonte de XML: XML_MES (só caminho de arquivo), CARTA_CORRECAO,
MDFES/MDFES_XML, DEOLHONOIMPOSTO (referência nacional, não por item). Ver Fase 5 (Missão 5)
para o estudo de viabilidade de ler o XML autorizado no disco via Agent, com opt-in por cliente.
C.3 — cobertura, padrão por CRT, relação com o cadastro
Já medido nas Missões 2/3 (docs/runs/BLOCO2_PIS_COFINS_CROSS_DB_V1.json,
docs/runs/BLOCOB_PIS_COFINS_SOURCE_V1.json), reconfirmado nesta missão:
| Banco | CRT | Cobertura (CST preenchido) | Padrão |
|---|---|---|---|
| GTI (Agent 2) | 1 | 9,55% dos itens — só em um único mês do histórico | evento pontual, não regra |
| CONSTRUCAO | 1 | 0% | cadastro nunca lido |
| MMMODAS | 1 | 0% | cadastro nunca lido |
| RINCAO | 3 | 0% | cadastro nunca lido |
| UNIAO | 1 | 0% | cadastro nunca lido |
Relação com o cadastro: em todos os 5 bancos, o cadastro do produto (C000025, campos
COD_ENTRADA_PIS/COD_SAIDA_PIS/ALIQ_PIS/COFINS) está em branco para praticamente 100% dos produtos,
inclusive nos casos em que a emissão preencheu algo — ou seja, não há concordância nem divergência
mensurável na prática: o cadastro simplesmente não é usado pela emissão em nenhum dos 5 clientes,
independentemente do CRT.