diff --git a/central/static/docs/dossie_contador.md b/central/static/docs/dossie_contador.md index d518bf8..afd69d7 100644 --- a/central/static/docs/dossie_contador.md +++ b/central/static/docs/dossie_contador.md @@ -63,6 +63,15 @@ reconhece esse episódio. 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: onde exatamente está guardado o que foi transmitido + +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. A fonte real e mais próxima do que +foi transmitido são as próprias colunas de PIS/COFINS por item de venda (código, base, alíquota, +valor) — os mesmos valores usados para montar a nota fiscal eletrônica. Isso não muda a conclusão +da pergunta (a): mesmo sendo a fonte real, essas colunas confirmam que o cadastro do produto nunca +é consultado. + ## Como usar este dossiê Cada resposta é dada uma única vez, no painel ("Contexto Fiscal", aba do Agent), nunca escrevendo diff --git a/docs/NCM_27_BLOCKED_PRODUCTS_V1.md b/docs/NCM_27_BLOCKED_PRODUCTS_V1.md new file mode 100644 index 0000000..9e5b0bb --- /dev/null +++ b/docs/NCM_27_BLOCKED_PRODUCTS_V1.md @@ -0,0 +1,60 @@ +# Os 27 produtos que bloqueiam a completude por NCM (Agent 2) — Missão 4 / Bloco D + +Evidência: SQL direto em GTI.FDB (`C000025`), somente leitura, 2026-09-28. **Nenhum tem GTIN real** +(`GTIN` sempre NULL; `CODBARRA` é ou um código interno auto-numerado tipo `0000000000016`, que não +é um EAN/GTIN de verdade, ou literalmente "SEM GTIN"). Isso significa que **nenhum dos 27 pode ser +resolvido por busca de GTIN** — todos dependem de nome ou de atestação humana. + +## D.1 — categoria de cada um + +| Categoria | Qtde | Códigos | +|---|---|---| +| Placeholder `00000000` | 4 | 000780, 000782, 000793, 001436 | +| Vencido (NCM legado, sucessor ambíguo) | 3 | 000016, 000254, 000349 (todos `02071400` — carnes de galinha) | +| Fora da tabela vigente (8 dígitos, formato ok, não encontrado na tabela oficial ativa) | 5 | 000061, 000062 (`02071200`), 000098 (`21069091`), 000172 (`02071200`), 000174 (`03061300`) | +| Formato inválido (valor de cadastro de teste/placeholder óbvio — `123456`, `11111111`, `66786786` etc.) | 15 | 000749, 000751, 000756, 000758, 000759, 000761, 000762, 000763, 000774, 000775, 000776, 000778, 000781, 000784, 000786 | + +Os 15 da última categoria são, pelos nomes, claramente **cadastro de teste/depuração** ("UUUUU", +"KLEBER TESTANDO...", "BUG", "SDFSDFSD", "PRODUTO DE TESTE DE ISOLAMENTO OK") — mas 3 deles têm +nomes de produtos reais (000761 QUEIJO MUSSARELA, 000762 PRESUNTO PROVOLONE, 000763 PÃO COM +GENGILIBRE) com o mesmo valor de teste `12345678` no NCM, sugerindo um cadastro real que nunca +teve o NCM corrigido depois de um teste. + +## D.2 — fila priorizada de atestação humana (`kb.attest`) + +Sem KB por GTIN (nenhum GTIN existe), a única evidência possível é o **nome do produto** — nunca +suficiente sozinho para atestar automaticamente (consenso entre clientes não é verdade fiscal; +nenhuma promoção automática é feita aqui). Prioridade sugerida (produtos reais primeiro, teste +por último): + +1. **001436** COCA-COLA ORIGINAL LATA 350 ML — produto comercial muito comum; há outras 5 linhas + quase idênticas no cadastro (001437-001442) com NCM `22021000` já preenchido — forte indício de + que o NCM correto é `22021000`, mas isso é uma inferência de nome/duplicata, não uma fonte + fiscal — precisa de confirmação humana, não promoção automática. +2. **000061/000062** FRANGO (COXA E SOBRECOXA) / CORAÇÃO DE FRANGO — NCM declarado `02071200` + fora da tabela vigente; produtos de açougue/mercado comuns, evidência de nome forte. +3. **000172/000174** PATÊ DE FRANGO / PATÊ DE CAMARÃO — mesma situação. +4. **000098** FEIJÃO DE CALDO — NCM declarado `21069091`, fora da tabela vigente. +5. **000016/000254/000349** CALDO DE SURURU / CHESFRANGO / CALDO DE GALINHA — NCM legado + `02071400`, sucessor ambíguo; precisa de decisão humana entre os candidatos, não uma escolha + automática. +6. **000780** SALADA VINAGRETE, **000793** "MOUSE GTI" (nome incoerente com um mercado/restaurante + — provavelmente cadastro de teste também) — placeholder `00000000`, evidência de nome fraca ou + nula. +7. **000761/000762/000763** (queijo/presunto/pão) — nomes reais, mas valor de NCM claramente de + teste (`12345678`); tratar como cadastro que precisa de correção manual, não como um caso + fiscal complexo. +8. Os demais 12 (Kleber\*, UUUUU, BUG, SDFSDFSD, TESTE\*, CASTANHA×2, SALADA VINAGRETE dup.) — + prioridade baixa: parecem lixo de cadastro de teste deste ambiente, candidatos a limpeza/ + desativação em vez de correção fiscal (fora do escopo desta missão decidir isso). + +## D.3 — caminho mais curto para o humano, sem GTIN + +Como nenhum tem GTIN, o caminho mais curto é sempre o mesmo, em ordem de esforço: +1. Verificar se o produto tem um código de barras físico real (a embalagem) e cadastrá-lo em + `CODBARRA`/GTIN — se sim, o enriquecimento automático já cobre o resto a partir daí. +2. Se não houver GTIN real (produto de padaria/açougue/prato pronto, pesado na balança — comum + nos casos reais desta lista), a única via é a descrição + atestação humana via `kb.attest`, + nunca uma promoção automática por nome. +3. Para os itens claramente de teste/depuração, a ação mais curta não é fiscal — é o operador + decidir se o produto deve continuar ativo no cadastro. diff --git a/docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md b/docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md new file mode 100644 index 0000000..361f806 --- /dev/null +++ b/docs/PISCOFINS_TRANSMITTED_SOURCE_V1.md @@ -0,0 +1,45 @@ +# PIS/COFINS efetivamente transmitido — onde está guardado (Missão 4 / Bloco C) + +## C.1/C.2 — busca por XML/BLOB e tabelas de imposto por item + +Levantamento de todas as colunas BLOB e de todas as tabelas com "XML"/"IMPOSTO"/"TRIBUT" no nome, +nos 5 bancos (GTI/Agent 2, CONSTRUCAO, MMMODAS, RINCAO, UNIAO) — mesmo schema nos 5: + +- **Nenhuma tabela guarda o XML autorizado da NFC-e/NF-e.** `XML_MES` existe, mas só guarda o + **caminho do arquivo no disco local** da máquina onde o SGV roda (`CAMINHO_XML`, + `C:\GTI SISTEMAS\Schemas\...\xml\\\...-nfe.xml`) — o conteúdo do XML em si não está no + banco, só a referência ao arquivo. Esse arquivo está fora do escopo desta missão (sistema de + arquivos de uma máquina de cliente, não um banco, e não temos acesso a ele). +- `CARTA_CORRECAO.XML` e `MDFES_XML.*` existem, mas são para Carta de Correção e Manifesto de + Documentos Fiscais (MDF-e, transporte de carga) — não para o NFC-e/NF-e em si. +- `DEOLHONOIMPOSTO` é a tabela oficial da Lei "De Olho no Imposto" (IBPT) — uma tabela de + **referência nacional** por NCM (carga tributária aproximada nacional/importada/estadual/ + municipal, para exibir no rodapé do cupom), não o PIS/COFINS realmente aplicado por item. +- **NFCE_ITENS já é a fonte real**: `CST_PIS_COFINS`, `ALIQUOTA_PIS`, `BASE_CALCULO_PIS`, + `VALOR_PIS`, `ALIQUOTA_COFINS`, `BASE_CALCULO_COFINS`, `VALOR_COFINS` são colunas simples + (não BLOB) já preenchidas pelo próprio SGV ao montar cada nota — são os mesmos valores que vão + para o XML enviado à SEFAZ. Sem o XML em si para conferência cruzada, esta é a melhor evidência + disponível do que foi realmente transmitido. + +**FONTE_ENCONTRADA**: `NFCE_ITENS` (colunas de PIS/COFINS por item), não um XML/BLOB. +Tabelas inspecionadas e descartadas: `XML_MES` (só caminho de arquivo), `CARTA_CORRECAO`, +`MDFES`/`MDFES_XML`, `DEOLHONOIMPOSTO` (referência nacional, não por item). + +## C.3 — cobertura, padrão por CRT, relação com o cadastro + +Já medido nas Missões 2/3 (`docs/runs/BLOCO2_PIS_COFINS_CROSS_DB_V1.json`, +`docs/runs/BLOCOB_PIS_COFINS_SOURCE_V1.json`), reconfirmado nesta missão: + +| Banco | CRT | Cobertura (CST preenchido) | Padrão | +|---|---|---|---| +| GTI (Agent 2) | 1 | 9,55% dos itens — só em um único mês do histórico | evento pontual, não regra | +| CONSTRUCAO | 1 | 0% | cadastro nunca lido | +| MMMODAS | 1 | 0% | cadastro nunca lido | +| RINCAO | 3 | 0% | cadastro nunca lido | +| UNIAO | 1 | 0% | cadastro nunca lido | + +Relação com o cadastro: em **todos** os 5 bancos, o cadastro do produto (`C000025`, campos +COD_ENTRADA_PIS/COD_SAIDA_PIS/ALIQ_PIS/COFINS) está em branco para praticamente 100% dos produtos, +inclusive nos casos em que a emissão preencheu algo — ou seja, não há concordância nem divergência +mensurável na prática: o cadastro simplesmente não é usado pela emissão em nenhum dos 5 clientes, +independentemente do CRT. diff --git a/docs/dossie_contador.md b/docs/dossie_contador.md index 7d0c063..e52c595 100644 --- a/docs/dossie_contador.md +++ b/docs/dossie_contador.md @@ -71,6 +71,15 @@ dezembro/2022. 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 4): onde exatamente está guardado o que foi transmitido + +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. A fonte real e mais próxima do que foi +transmitido são as próprias colunas de PIS/COFINS de `NFCE_ITENS` (CST, base, alíquota, valor por +item) — os mesmos valores que o SGV usa para montar o XML. Isso não muda a conclusão da pergunta +(a): mesmo sendo a fonte real, essas colunas confirmam que o cadastro do produto nunca é +consultado. 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