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>
5.7 KiB
Dossiê para o contador (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. Identificadores de cliente foram substituídos por rótulos genéricos (Cliente A–E); nenhum nome de produto, CNPJ ou razão social aparece aqui.
(a) Em CRT=1, o PIS/COFINS por item segue o cadastro do produto ou a operação/regime?
Evidência: em 5 instalações auditadas (Cliente A, CRT 1; Clientes B/C/E, CRT 1; Cliente D,
CRT 3), o cadastro do produto 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 Cliente A). Nos Clientes B, C, D e E, 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 itens de NFC-e emitidos pelo Cliente A, 9,5% trazem CST de PIS/COFINS = "01" — e são exclusivamente de um único mês (dezembro de um ano específico), não do ano inteiro: 90,9% dos itens daquele mês têm o campo preenchido, todos os outros meses (incluindo o resto do mesmo ano) têm 0%. Testamos se o NCM, o grupo do produto, o CFOP ou o código de ICMS do item explicam quais itens recebem o valor: não há uma fórmula fiscal por trás — é um conjunto pequeno e homogêneo de vendas reais concentrado nesse único mês, que já havia sido sinalizado em outra auditoria interna como um período com problema de integridade de dados. 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 decidimos isso por evidência insuficiente para confirmar a causa exata; a pergunta é se o contador reconhece esse episódio.
(c) CFOP_ENTRADA no cadastro do produto é necessário ou é sempre definido na nota de compra?
Evidência:
- Schema do banco: a coluna é opcional no próprio banco de dados (sem obrigatoriedade, sem valor padrão, sem regra de validação) — o sistema nunca exige um valor aqui a nível de banco.
- Uso real é muito diferente entre clientes: em dois clientes o campo está praticamente sempre em branco; em outros três está preenchido em quase 100% dos produtos, com valores plausíveis — 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 ainda (requer acesso à tela de entrada de nota do sistema, que não fizemos):
se a tela de lançamento de nota de compra lê o CFOP_ENTRADA do cadastro como sugestão inicial, ou
sempre pede a digitação manual. Roteiro de 5 passos para teste manual:
- Anote o CFOP_ENTRADA atual de um produto de teste (ou deixe em branco).
- Abra o cadastro do produto e grave um CFOP_ENTRADA diferente (ex.: 1102).
- Lance uma nota de entrada (compra) desse mesmo produto.
- Veja se o CFOP do item da nota já vem preenchido com o valor do cadastro, ou em branco.
- 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,INTERouMIXED_OR_DYNAMIC(este último não bloqueia mais a completude do produto).
(d) O que mais o levantamento deixou como decisão pendente com evidência insuficiente?
- Origem da mercadoria (nacional/importado): nenhuma fonte automática existe para decidir isso — a grande maioria dos produtos não tem nenhuma evidência. Só pode ser respondido produto a produto ou por grupo, nunca por uma regra geral.
- Tratamento de ICMS para um pequeno grupo de produtos cujo código fiscal está em branco — parte é cadastro de teste/incompleto, mas alguns produtos reais também aparecem.
- Um pequeno número de produtos com o código fiscal (CSOSN) em branco hoje. Nenhuma simulação escreve nada; um valor padrão 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 um padrão cegamente).
Atualização: o que foi realmente transmitido é NÃO_CONCLUSIVO
Procuramos por XML/documento fiscal armazenado nos bancos auditados: não existe — o sistema só guarda o caminho do arquivo no disco da loja, nunca o conteúdo. As colunas de PIS/COFINS por item de venda são a melhor evidência disponível no banco, mas essas colunas estão em branco para quase todos os itens, e sem o XML de verdade não sabemos se "em branco" significa que nada foi transmitido ou que o sistema transmitiu um valor sem gravá-lo de volta no banco — as duas explicações combinam com os mesmos dados. O que continua certo: o cadastro do produto nunca é consultado (também em branco).
Como usar este dossiê
Cada resposta é dada uma única vez, no painel ("Contexto Fiscal", aba do Agent), nunca escrevendo nada no ERP diretamente — a decisão fica registrada e auditada, 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.