# 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:
  1. Anote o CFOP_ENTRADA atual de um produto de teste (ou deixe em branco).
  2. Abra o cadastro do produto 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).

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

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