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>
92 lines
6.8 KiB
Markdown
92 lines
6.8 KiB
Markdown
# Dossiê para o contador — Missão 2 (2026-09-28)
|
|
|
|
Este documento não afirma nenhuma regra fiscal. Cada pergunta mostra a evidência real medida
|
|
(somente leitura, sem gravação em nenhum banco) e qual clique na tela "Contexto Fiscal" do painel
|
|
a resposta libera.
|
|
|
|
## (a) Em CRT=1, o PIS/COFINS por item segue o cadastro do produto ou a operação/regime?
|
|
|
|
**Evidência**: nos 5 bancos auditados (Agent 2/GTI, CONSTRUCAO, MMMODAS, RINCAO, UNIAO — CRT 1 e
|
|
CRT 3), o cadastro do produto (`C000025`) **nunca** tem os campos de PIS/COFINS usados pela emissão:
|
|
mesmo quando a nota fiscal emitida traz um CST de PIS/COFINS preenchido, o cadastro está em branco
|
|
para o mesmo produto (23 casos confirmados no Agent 2). Em CONSTRUCAO, MMMODAS, RINCAO e UNIAO, a
|
|
emissão nunca preenche o CST de PIS/COFINS (0% dos itens, em todos os anos de histórico
|
|
disponíveis). Isso indica que a emissão não lê o cadastro — mas não decide se o valor correto é
|
|
"não aplicável", "por operação" ou um perfil fixo por empresa. **Libera**: card "Perfil de
|
|
PIS/COFINS" → escolher `NOT_APPLICABLE`, `OPERATION_TIME` ou um perfil JSON de 6 campos.
|
|
|
|
## (b) O CST 01 emitido em ~9,5% dos itens é intencional?
|
|
|
|
**Evidência**: dos 34.946 itens de NFC-e emitidos pelo Agent 2, 3.336 (9,5%) trazem CST de
|
|
PIS/COFINS = "01" — e são **exclusivamente de dezembro/2022** (não "2022" em geral: nenhum item
|
|
antes de 01/12/2022 ou depois de 31/12/2022 tem o campo preenchido; 90,9% dos itens daquele mês
|
|
específico têm CST preenchido, os outros 9,1% não). Testamos se NCM, grupo do produto, CFOP, CSOSN
|
|
ou o grupo de ICMS do item explicam quais itens recebem o CST: todos os 3.336 itens preenchidos
|
|
compartilham o mesmo grupo de ICMS (vazio), e apenas 10 NCMs e 2 CFOPs aparecem no conjunto todo —
|
|
ou seja, não há uma fórmula fiscal por trás disso, é um conjunto pequeno e homogêneo de vendas reais
|
|
(refrigerante, macarrão, cerveja, biscoito — produtos plausíveis, não lixo de teste) concentrado
|
|
num único mês. Esse mesmo mês (dezembro/2022) já havia sido sinalizado em outra auditoria interna
|
|
como um período com problema de integridade de dados (identidade de produto instável nas notas
|
|
daquele mês). A leitura mais provável é que **não é uma política fiscal deliberada** — é um efeito
|
|
técnico de um evento pontual (ex.: uma migração de dados ou uma versão diferente do software de
|
|
emissão usada só naquele mês), não uma regra de negócio. Não decidimos isso por evidência
|
|
insuficiente para confirmar a causa exata; a pergunta é se o contador reconhece esse episódio de
|
|
dezembro/2022.
|
|
|
|
## (c) CFOP_ENTRADA no cadastro do produto é necessário ou é sempre definido na nota de compra?
|
|
|
|
**Evidência**:
|
|
- **Schema do Firebird** (`RDB$RELATION_FIELDS`/`RDB$CHECK_CONSTRAINTS` em `C000025.CFOP_ENTRADA`):
|
|
coluna **NULLABLE**, **sem DEFAULT**, **sem CHECK/domínio** — o próprio SGV nunca exige um valor
|
|
aqui a nível de banco.
|
|
- **Uso real é muito diferente entre clientes**: no Agent 2 (GTI), CFOP_ENTRADA está em branco em
|
|
527/527 produtos (100%). Em RINCAO, 891/894 (99,7%) em branco. Mas em CONSTRUCAO, MMMODAS e UNIAO
|
|
o campo está **preenchido** em 99,8%/99,9%/99,97% dos produtos, com valores plausíveis (1102, 1403,
|
|
2202 etc.) — ou seja, alguns clientes efetivamente mantêm esse cadastro, outros não.
|
|
- Isso mostra que não existe uma regra universal: depende de como cada loja opera. Por isso o motor
|
|
já trata isso como uma decisão por instalação (`entry_scope`), nunca uma regra fixa do sistema.
|
|
- **Não verificado nesta sessão** (requer acesso ao executável da tela de entrada de nota, que não
|
|
fizemos): se a tela de lançamento de nota de compra do SGV lê o CFOP_ENTRADA do cadastro como
|
|
sugestão inicial, ou sempre pede a digitação manual. Roteiro de 5 passos para teste manual:
|
|
1. Anote o CFOP_ENTRADA atual de um produto de teste (ou deixe em branco).
|
|
2. Abra o cadastro do produto no SGV e grave um CFOP_ENTRADA diferente (ex.: 1102).
|
|
3. Lance uma nota de entrada (compra) desse mesmo produto.
|
|
4. Veja se o CFOP do item da nota já vem preenchido com o valor do cadastro, ou em branco.
|
|
5. Repita com CFOP_ENTRADA em branco no cadastro e confirme se a nota exige digitação manual.
|
|
- **Libera**: card "CFOP de entrada padrão" → `INTRA`, `INTER` ou `MIXED_OR_DYNAMIC` (este último
|
|
não bloqueia mais a completude do produto — Missão 2, Bloco 3.4).
|
|
|
|
## (d) O que mais o dry-run deixou como decisão pendente com evidência insuficiente?
|
|
|
|
- **COD_ORIGEM_MERCADORIA** (origem da mercadoria): nenhuma fonte automática existe no ERP para
|
|
decidir nacional/importado — 526 de 527 produtos do Agent 2 não têm nenhuma evidência. Só pode
|
|
ser respondido produto a produto ou por grupo, nunca por uma regra geral.
|
|
- **icms_treatment** para 12 produtos (Agent 2) cujo CSOSN está em branco — a maioria concentrada em
|
|
produtos de teste/cadastro incompleto (nomes como "TESTE...", "BUG", "SDFSDFSD"), mas 12 produtos
|
|
reais também aparecem (Coca-Cola, queijos, peixes) — ver `docs/runs/GTI_dryrun_universe_summary.json`.
|
|
- **30 produtos com CSOSN em branco no Agent 2** (medição em 2026-09-28; uma medição anterior de
|
|
2026-09-27, registrada em `central/app/fiscal_context_ui.py`, contava 28 — a diferença de 2 é
|
|
compatível com o cadastro de produtos de teste que muda dia a dia neste ambiente, não uma
|
|
divergência de regra). Nenhuma simulação escreve nada; o padrão 102 só se aplica de fato após a
|
|
confirmação do "Tratamento padrão de ICMS" no card correspondente, e mesmo assim o motor consulta
|
|
o tratamento antes de propor o código (nunca aplica 102 cegamente).
|
|
|
|
## Atualização (Missão 5): o que foi realmente transmitido é NÃO_CONCLUSIVO
|
|
|
|
Procuramos por XML/BLOB armazenado nos 5 bancos: **não existe** — o SGV só guarda o *caminho* do
|
|
arquivo XML no disco da máquina, nunca o conteúdo. As colunas de PIS/COFINS de `NFCE_ITENS` (CST,
|
|
base, alíquota, valor por item) são a melhor evidência disponível no banco, mas **corrigimos aqui
|
|
uma afirmação forte demais da Missão 4**: essas colunas estão em branco para quase todos os itens,
|
|
e sem o XML de verdade não sabemos se "em branco" significa "nada foi transmitido" ou "o SGV
|
|
transmitiu um valor no XML mas nunca gravou de volta no banco". As duas explicações são compatíveis
|
|
com os mesmos dados — por isso a fonte do que foi *efetivamente* transmitido continua
|
|
**NÃO_CONCLUSIVO**. O que continua de pé, com certeza: o cadastro do produto nunca é consultado
|
|
(branco também). Ver `docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md`.
|
|
|
|
## Como usar este dossiê
|
|
|
|
Cada resposta é dada uma única vez, no painel ("Contexto Fiscal", aba do Agent), nunca escrevendo
|
|
nada no Firebird diretamente — a decisão fica registrada e auditada (`FiscalContextEntry`), e só
|
|
depois disso o motor passa a considerar o campo resolvido (ou explicitamente não-bloqueante).
|
|
Nenhuma decisão aqui é assumida por padrão.
|