GTI_GERENCIADOR_FISCAL/fiscal/docs/dossie_contador.md

# Dossiê para o contador — Missão 2 (2026-09-28 — DADO_DE_TESTE=true)

> [!WARNING]
> **DADO_DE_TESTE=true — AVISO DE BASE DE LABORATÓRIO / TESTE**:
> Todas as evidências, contagens e comportamentos relatados neste documento foram levantados exclusivamente a partir de **bancos de dados de teste / laboratório** (Agent 2 / GTI e os bancos de laboratório CONSTRUCAO, MMMODAS, RINCAO, UNIAO). **Nenhum cliente real em produção passou pelo motor fiscal ainda.** Os achados servem para calibrar o mecanismo técnico do sistema e ilustrar perguntas contábeis, mas **não constituem conclusão ou diagnóstico fiscal sobre nenhum cliente real**.

Este documento não afirma nenhuma regra fiscal. Cada pergunta mostra a evidência de laboratório 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.