Reforma tributaria totvs winthor

O risco que já vi foi confiar em uma só leitura de versões. Discordo do Leandro num ponto: o teste em base própria não cobre o time do winthor, que mantém as adequações dele e anda em ritmo próprio. O prazo é, tá, o que o contribuinte definir, e não o do sistema. Por isso eu combino datas com os dois lados antes de testar, tanto no SAP quanto no totvs, e registro o combinado no chamado.

Concordo com o Sérgio sobre a leitura, mas discordo de parar nela. Um alerta, tá: no e-commerce, a validação no sistema vale mais que ler a nota técnica. Primeiro, subo a NT numa base de teste; segundo, a utilização dos campos novos é medida pelos eventos de rejeição. Isso vale quando já existe base de teste; sem ela, resta a leitura. A decisão tributária fica com o contribuinte, mesmo quando o teste envolve a totvs.

Meu caso concreto: no varejo, em setembro conferi a NT 2025.002-RTC, a 1.52, e comecei pelo sumário, que mostra todos os grupos. De modo geral, tá, a leitura guiada pelo sumário substitui a tabela e o teste automático quando o time é pequeno; com time grande e muita mudança, os outros caminhos compensam. A reforma tributária pede disciplina de leitura, e no log do projeto eu anoto a data de cada uma, inclusive para a filial da totvs.

Resultado prático: cada campo novo ganha um dono. Evandro, completando o seu teste, a inserção dos campos novos e a introdução do grupo de pagamento antecipado mexem em telas diferentes no SAP, então quem testa precisa saber qual. E aí, o teste é rodar o mesmo cenário duas vezes, com e sem esse grupo preenchido. Em RISE with SAP isso sai rápido. A parte tributária fica com o contribuinte, e o resultado do teste vai para ele, inclusive o da filial na totvs.

Se a NT é só publicação de campos, discordo da Úrsula num ponto: rodar o cenário duas vezes não basta para a nota referenciada. De perto, né, o grupo de NF-e referenciada tem banco de dados próprio e o teste precisa de uma nota anterior válida. Eu olharia também o presumido, que pode mudar o resultado. Se a filial da totvs emitiu a nota anterior, confira o formato dela, porque a tributária da nova nota depende disso.

Moisés, ponto justo, e aqui vai outro caminho que o time usa: em vez de tabela, uma criação de teste automático por código, com a descrição do cenário no próprio caso de teste. O risco é, né, o teste ficar velho também, então só vale se alguém for dono da revisão. Esse caminho compensa quando há muitos códigos, como no grupo de crédito; com poucos, a tabela do Luiz basta. Na filial da totvs, a regra tributária entra no mesmo teste.

O risco que já vi: tabela fixa de códigos. Discordo do Luiz num ponto, porque a NT recebe correções a cada revisão, e o controle de mudanças fica por conta de quem mantém a tabela. No S/4HANA 2023, uma tabela velha segurou nota boa. Agora, a regra é revisar o cadastro quando sair texto novo sobre o consumo e só depois liberar a emissão, inclusive na filial que usa totvs. A leitura tributária continua com o contribuinte.

Concordo em parte com o Alexandre, mas discordo de começar só pelos tipos de campo. Olha, na última auditoria do ECC 6.0 pedimos a lista de códigos por classificação e o ccredpres apareceu como ponto de dúvida, então hoje mantemos uma tabela complementar com cada código aceito. O pedaço do log mostrado ao auditor trazia só o nItem e o código. Esse caminho vale quando há auditoria; para teste rápido, a leitura direta da NT basta, mesmo com a emissão pela totvs.

Separar ajuda? Ajuda, sim, porque a NT trata dos campos de emissão e a apuração entra por eventos. Olha, só pra alinhar, eu começaria pelos tipos básicos e pelo cclasstrib, porque o resto depende deles. Com a totvs na filial, valeria combinar com o time de lá qual sistema preenche cada campo, para não duplicar. A decisão tributária é do contribuinte; nós só garantimos o comportamento.