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>
52 lines
3.5 KiB
Markdown
52 lines
3.5 KiB
Markdown
# 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_MES` existe, 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.XML` e `MDFES_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_ITENS` tem as colunas `CST_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.
|