Com vale refeição, o sistema mostra o crédito de PIS e Cofins sobre as aquisições incidentes, e em qual campo do registro?

Concordo em parte com a Carolina Duarte, porque o cadastro de item importa. Mas discordo de que o problema esteja só no item, veja, em linhas gerais. As críticas que tenho vêm de uma solução desenvolvida em casa, que trata a despesa de vale refeição como custo geral e joga PIS e Cofins no mesmo campo. Sem separar isso na origem, nenhuma regra do sistema resolve. Em gestão fiscal de alimentos, com ECC 6.0, a gente só fechou o problema quando voltou à origem das despesas.

Já pensou em separar o vale refeição num tipo de documento próprio? Na nossa equipe de alimentos, a saída foi criar um controle à parte para esses lançamentos, e a regra de PIS e Cofins fica atrelada a ele. Assim o crédito das contribuições aparece no lugar certo, sem misturar com a compra comum. Quando o controle falha, o detalhe é que, ó, o erro volta para o campo do registro. Vale a pena quando o volume é alto; abaixo disso, a manutenção pesa mais.

Na minha rotina de e-commerce, o caso concreto é o pedido de vale refeição com nota contendo dois tipos de item. Eu vejo, olhando a tela, tá, que o sistema mostra o valor no campo certo quando eu faço as consultas por item, mas o conteúdo do registro sai agregado. Discordo com educação de quem diz que o campo resolve tudo: sem separar os itens, o PIS e a Cofins saem somados e a conferência não fecha. Antes de mexer no cadastro, eu rodaria as consultas item a item e compararia o conteúdo.

Quando o cadastro está certo, o sistema grava o valor. Cláudio Almeida, complementando o seu ponto, o número é, pois é, que a concessionária de dados que alimenta o cadastro muda o cenário. Se a concessionária entrega o código de benefício em outro formato, o campo sai vazio. Já vi concessionárias de benefício mandarem o mesmo vale refeição com códigos diferentes, e a concessionáris não avisava. O detalhe está no fechamento, quando a conta fica torta.

O segredo, segundo o que li, ó, é o cadastro estar certo antes de qualquer lançamento. Discordo de quem põe a culpa no campo do registro, porque os ajustes de comunicação entre o módulo fiscal e a escrituração só auxiliam quando a regra de PIS e Cofins já está parametrizada no sistema. Isso é um ponto complementar, não a causa. Em siderurgia, com ECC 6.0, vimos o sistema gravar o valor certo quando o tipo de operação estava certo desde o início.

Vivemos isso na prática. A saída que deu certo foi montar uma regra de classificação no cadastro do material, e não no documento, e, através dela, o vale refeição cai sempre no mesmo grupo de tributo. Isso permite automatizar a escolha do campo do registro, sem digitação. A regra automática só vale, em campo, pois é, quando o cadastro de benefício está limpo; quando não está, a gente volta para a conferência manual.

O risco que já vi é o valor aparecer certo na tela e sair errado no arquivo, então a resposta está no arquivo gerado e não no cadastro. Em outros ERPs que migramos para SAP, o PIS e a Cofins das aquisições de vale refeição caíam no mesmo campo da compra comum, e o registro ficava correto só na visualização. Por fim, e aí, minha opinião, o caminho é gerar o arquivo com um lançamento de teste e comparar os arquivos linha por linha com a versão anterior. Assim você descobre em qual campo do registro o valor sai.

André Dias, sem rodeio: quando você fala em comparar linha por linha, o que exatamente está sendo comparado? Sou consultor FI, trabalho com GUEPARDO Tax, e o sistema usa assinador e assinatura digital no envio. Não sei se esse passo mexe no dado antes da leitura. Preciso atender o fechamento do mês sem quebrar o PIS e a Cofins. Você já viu esse passo mexer no valor?