A coluna “Outras”, relacionada às operações sem crédito/débito, foi excluída da EFD-ICMS/IPI?

Risco que já vi: um lote saiu com a coluna de operações mal mapeada. O combinado é, né, que cada mapeamento tenha uma observação escrita no cadastro, com a data em que foi medido o impacto. A Débora Santos fala de cadastro único, e eu concordo, mas complemento com um ponto: registre a observação do que foi excluída, para que a auditoria saiba quando a regra mudou. Sem isso, o número medido em um mês não é comparável com o do outro.

Concordo em parte com a Cristina Costa, a conferência é indispensável. Mas discordo do caminho de manter a coluna antiga no leiaute, porque a validação passa a rejeitar. Nós preferimos ter a regra inserida no cadastro dos tipos, com a tabela de isentas separada. O bom é, ó, que essa opção se justifica quando a equipe tem tempo para testar cada tipo e quer um histórico limpo. Se a operação é grande e a coluna já foi excluída, o melhor é manter um cadastro único e não criar exceções.

Será que o saldo inicial sobrevive à mudança? Veja, a regra é que a origem da coluna informada no mês de abertura serve de base, então a Adriana Rocha tem razão ao pedir campo de conferência. Eu acrescento um ponto novo: quando a coluna foi excluída, o saldo inicial de cada período precisa carregar a origem do conjunto, não só o valor. Assim a conferência segue a informação no arquivo e não se perde no ajuste seguinte.

Na minha rotina de indústria, a inclusão dos tipos novos já foi feita antes da troca de layout. De cabeça, viu, eu discordo da ideia de que a coluna pode sumir sem registro: os incluídos no industrial precisam de um campo de conferência, senão a auditoria não encontra a origem. Os documentos que eu conferi tinham o mesmo total, mas a divergência estava na distribuição entre os tipos, e isso só apareceu na validação.

O resultado que importa é o arquivo sair limpo, sem registro duplicado. Olha, a título de exemplo, uma forma que usamos aqui foi fazer uma tabela de conversão em que cada descrição antiga aponta para o código novo, e o documento fiscal sai com a coluna certa. Essa rota serve quando o volume de tipos é pequeno e o time confere o resultado linha a linha. Quando há muita variação de crédito ou de documento, o melhor é criar regras por grupo, senão a manutenção fica impossível.

Discordo, com todo respeito. Bem, no meu dia a dia, a combinação de CST, CFOP e o tipo de tributação não substitui as colunas de forma automática, porque o valor correspondente ainda exige uma regra clara. A coluna que antes separava os não tributados não pode cair em outro campo sem conferência. Quando a Patrícia mapeou tudo dessa forma, a validação aceitou, mas o resultado da apuração mudou, e eu não teria feito a mesma leitura sem comparar os meses.

Patrícia, na nossa equipe a gente não mexeu na leitura da coluna antiga. Em vez disso, mantivemos o arquivo do período anterior com a apresentação antiga e criamos um mapeamento separado para o período novo, com a assinatura do responsável no fechamento. Só um detalhe, tá, o mapeamento precisa de um controle de quem alterou cada regra. Esse caminho vale quando há muito histórico e o time quer comparar meses sem retrabalho. Se a operação é nova e o volume é pequeno, reprocessar tudo com a regra nova costuma ser mais simples.

O risco que você já viu tem resposta curta: a coluna Outras não existe mais como campo próprio, porque o valor passa a ser identificado pelo conjunto de CST de ICMS, CFOP e alíquota. Quando alguém tenta preencher a coluna antiga, o arquivo sai com erro. Bem, a gente costuma resolver isso mapeando cada situação antiga para esse conjunto. Quanto às alterações da versão, o ponto central é que o layout mudou e a validação acompanhou a mudança. Se o seu sistema ainda gera a coluna antiga, o correto é ajustar a leitura, não reabrir o campo.