Rejeição 1069: valor da CBS difere do calculado: Auditoria de XML e regressão

Introdução

Rejeição 1069: valor da CBS difere do calculado integra o novo lote de tratamentos da Reforma Tributária publicado pela TOTVS em setembro de 2026. O foco aqui é criar evidências e prevenir reincidência.

O que a TOTVS documenta

• A fórmula é vCBS=(vBC×pCBS/100)-vDif-vDevTrib.
• Com redução, deve-se usar pAliqEfet.
• A tolerância é R$ 0,01 e a TOTVS cita base, alíquota, arredondamento, diferimento, devolução, CST e cClassTrib.

Solução principal

Recalcular a CBS e revisar Regra de Alíquota/redução.

Fórmula oficial

vCBS = (vBC × pCBS/100) - vDif - vDevTrib.

Com redução, use pAliqEfet. Exemplo: 10.000 × 0,9% - 10 - 5 = R$ 75,00.

Auditoria

Guarde XML rejeitado, retorno, print da regra, classificação, release/TSS, XML corrigido e autorização. Execute cenário positivo e negativo. Para valores, concilie item antes do total; para referências, compare chave, item e participantes.

Fluxo de investigação

Cadastro/classificação → Perfis/contexto → FISA170 → cálculo/escrituração → TSS/XML → SEFAZ.

Checklist

• preservar XML original;
• identificar item;
• conferir artigo TOTVS;
• revisar release e TSS;
• confirmar CST/cClassTrib;
• revisar FISA170;
• fazer cálculo manual quando houver fórmula;
• conferir origem quando houver DFeReferenciado;
• regerar XML;
• homologar e arquivar evidência.

Evite atalhos

Não faça UPDATE em F2D, CJ3, DKN ou tabelas fiscais. Não remova tags manualmente. Não troque cClassTrib ou benefício apenas para autorizar.

Revisão independente

Refaça o cálculo em planilha quando houver fórmula, ou monte tabela com chave/item/participantes quando o problema for referenciamento. Compare antes e depois da correção.

Monitoramento pós-produção

Acompanhe reincidência, novas rejeições relacionadas, diferenças por filial e comportamento do TSS. Uma correção só está estabilizada quando não cria efeitos colaterais.

Conclusão

A correção segura acontece na origem: classificação, regra, cálculo, referência ou atualização. Depois, gere novo XML, valide em homologação e documente o resultado.

Conteúdo técnico baseado em documentação oficial TOTVS publicada entre 9 e 11/09/2026. Tratamentos fiscais e classificações devem ser confirmados pela área Fiscal/Contábil.

Validação funcional antes da produção

Antes de liberar a correção, compare o comportamento do Protheus com uma memória independente. Quando a rejeição envolver cálculo, reproduza a conta em planilha com base, alíquota, redução, diferimento, devolução e arredondamento explícitos. Quando envolver referenciamento, monte uma tabela com chave de origem, item, CNPJ/CPF do emitente e destinatário. Quando envolver classificação, registre CST, cClassTrib e a versão da tabela usada.

A validação deve responder três perguntas: a regra correta foi escolhida? o valor/grupo gerado está correto? o XML representa fielmente o resultado interno?. Se qualquer uma delas ficar sem resposta, a autorização da nota não deve ser usada como única evidência de que o problema foi resolvido.

Evidências para suporte e auditoria

Um pacote de evidências útil pode conter:

01_xml_rejeitado.xml

02_retorno_sefaz.txt

03_print_regra_cfgtrib.png

04_memoria_calculo.xlsx

05_release_build_tss.txt

06_xml_corrigido.xml

07_retorno_autorizado.txt

Se a ocorrência envolver DFeReferenciado, acrescente a chave da nota de origem, item de origem e participantes envolvidos. Se envolver F2D/CJ3, use consultas apenas de leitura e anexe a evidência correspondente. Se o artigo oficial indicar possível problema no autorizador, guarde também o resultado do validador nacional ou de outro ambiente comparável.

Teste negativo obrigatório

Além do cenário corrigido, execute um caso semelhante que não deve usar a mesma regra. Essa etapa é essencial para evitar parametrizações amplas demais. Uma correção que faz a nota rejeitada autorizar, mas passa a aplicar diferimento, crédito presumido ou classificação a operações indevidas, não está concluída.

Exemplos de teste negativo:

• outro CST sem direito ao mesmo grupo;
• cClassTrib diferente;
• participante ou UF diferente;
• nota sem vínculo de origem;
• benefício fiscal fora da área incentivada;
• documento de finalidade diferente.

Política de atualização

Rejeições da Reforma Tributária mudam rapidamente com novas versões de Nota Técnica, patches, fontes e TSS. Portanto, associe cada solução à data do artigo TOTVS, release testada e versão do ambiente. Evite registrar a solução apenas como “ajustar campo X”.

Após atualização de Protheus, TSS ou pacote fiscal, repita pelo menos os cenários mais críticos. Essa rotina de regressão transforma a coleção de artigos em uma base operacional para sustentação e não apenas em material de consulta.

Critério de encerramento do incidente

Considere a rejeição encerrada somente quando houver:

• causa identificada;
• correção aplicada na origem;
• XML novo gerado;
• homologação concluída;
• cenário negativo executado;
• evidência arquivada;
• responsável Fiscal/Contábil de acordo, quando aplicável.

Esse critério reduz reincidência e evita soluções improvisadas.