GTI_GERENCIADOR_FISCAL/docs/dossie_contador.md

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).

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.