Como funciona integração fiscal no SAP?

Faço conferência semanal. Como sempre, né, o fechamento sozinho chega tarde demais. Eu separo os documentos por bloco de data e confiro um lote por vez, o que demora mais, mas pega o estorno antes que ele vire problema. Essa forma serve quando a equipe é pequena e o volume cabe numa semana. Quando o volume estoura, prefiro automatizar a conferência por regra e deixar a conciliação mensal só para as exceções. Cada caminho depende do tamanho da carga e de quem vai olhar.

Concordo em parte com o Leandro Xavier, o relatório é útil. Discordo que zerar seja sinal de que o fechamento está certo. No go-live, tá, a gente viu relatório limpo com a apuração errada, porque o relatório só olha o que foi lançado e não o que deixou de ser lançado. Seria bom comparar com o total de documentos do período, e não só com as exceções. Aí sim o zero vale alguma coisa.

Fábio, discordo com educação da parte em que você diz que a tabela de correspondência deve ser carregada antes com documentos de teste de cada combinação. Puxando o fio, ó, em alimentos a combinação de imposto muda quase toda semana por causa das promoções, e um teste feito antes do go-live já nasce desatualizado. O que nos funcionou foi uma rotina de revisão da tabela a cada ciclo de fechamento, com dono definido. Assim o teste inicial vira só uma linha de base, e não uma garantia.

Será que o relatório de exceções do Leandro Xavier cobre os casos de estorno? Em todo caso, eu acrescentaria que, na siderurgia, o estorno é o que mais escapa, porque ele cai no período seguinte e ninguém relaciona com o original. Vale incluir no relatório os documentos cancelados com data de referência anterior ao corte. Assim a regra por alçada não deixa passar esse tipo de erro. Eu fiz isso por fora, numa planilha, e não é o ideal, mas ajudou bastante.

No nosso caso de farmacêutica, a rotina de todo mês começava com a conferência manual de notas que não batiam, e eu passava a tarde nisso. A saída é, viu, montar um relatório de exceções logo depois do faturamento, e só fechar o período quando ele zerar. Isso vale quando o volume é médio e a equipe consegue olhar tudo. Quando o volume é grande, a alternativa é tratar a exceção por regra, com alçada, e deixar só o que foge da regra para revisão humana. Cada caminho depende de quanto o time aguenta olhar à mão.

O resultado que importa é que a diferença que o Paulo descreveu não se resolve só com a tabela. Discordo da leitura de que o mapeamento explica tudo. Por assim dizer, né, a tabela pode estar perfeita e o problema estar na data do documento que alimenta a apuração. Um print do log de dois documentos, um dentro e outro fora do período, mostra isso em minutos. Eu separaria o teste em duas partes: primeiro a correspondência, depois a data de corte. Sem essa separação, a gente corrige a coisa errada e o fechamento seguinte volta a falhar.

Nádia, sua ressalva lembra o que vemos nos projetos de migração de outro ERP. Olha, como falei na reunião da semana, nós não tratamos a tabela de correspondência como ajuste pós-go-live. Carregamos ela antes, com uma rodada de documentos de teste cobrindo cada combinação de imposto, e só depois liberamos. Isso vale quando o volume de códigos é alto e o cliente tem equipe para revisar. Quando o caso é pequeno e os códigos são poucos, dá para fazer no próprio sistema de origem e migrar pronto. Cada caminho depende do tamanho da carga.

O risco que eu já vi é a regra ser criada pela área de negócio sem passar pelo fiscal, e aí ela existe no papel e não no sistema. A Aline Rodrigues tem razão de que o mapeamento costuma ser o problema, então, em todo caso, eu acrescentaria uma revisão mensal dessa tabela cruzada com o que o faturamento grava. Na mineração a gente só descobriu isso depois de uma apuração que não batia, e a dor foi bem maior do que o ajuste em si. Vale colocar essa checagem no calendário antes do fechamento, não depois.

Concordo em parte, Paulo. A integração depende mesmo da ordem em que os documentos são gerados, mas a diferença que você descreve costuma vir do mapeamento do código de imposto. Veja, meu ponto: se o faturamento grava um código que a apuração não reconhece, o sistema não dá erro, ele simplesmente ignora. No nosso caso, um print do log mostrou esse código sem correspondência, e corrigimos só o mapeamento. Antes de mexer na sequência das baixas, eu checaria a tabela de correspondência junto com os dados que chegam.