Analisando os SPED’s do DRC BR – Arquitetura, prós e contras – Parte 3

Analisando os SPED’s do DRC BR – Arquitetura, prós e contras – Parte 3

Primeira coisa é ter lido a parte 1 e 2 dessa série. Se você não leu, volte 1 casa e leia essa página Parte 1 da análise e depois essa Parte 2 da Análise.

Se você já leu as duas, avance 1 linha.

Vantagens do DRC sobre o TDF

Separei algumas das vantagens que EU vejo do DRC em relação ao TDF e explico o porquê considero essa característica como uma vantagem. Pode vir a existir gente que vai dizer que to forçando a barra pra mostrar vantagens, mas é minha opinião esse post:

1- Não é side car

O DRC BR não é side-car (como o TDF) e por isso não há necessidade de instalar um outro netweaver ou usar SLT e nem de RFC para acessar dados em programas Z, no TDF isso às vezes era necessário (um alô para quem precisava buscar dados das tabelas STXH/STXL no ERP).

Claro que não ser side-car é uma vantagem para empresas menores ou que não tem o S/4HANA com instância única usado globalmente, pois para empresas que tem esse cenário existem as desvantagens que apontei logo antes na parte 2.

2- SE16N e SE16H estão disponíves

Dá pra usar a SE16N e SE16H para visualizar os dados nas tabelas shadow com o DRC BR, isso é muito melhor que SE16 tradicional… Como o TDF não tinha o SAP_APPL nem o S4CORE essas duas transações não existiam no ambiente do TDF…

3- Framework de relatórios melhor do que TDF

O framework para criar novos reports no DRC é infinitamente melhor do que o do TDF, em teoria daria para usar as calculation views e criar um report novo usando o app de “Define Statutory Reports” de uma maneira mais simples para atender a apuração das obrigações acessórias.

Nesse post antigo aqui mostrei um pouco da idéia do que é possível fazer no framework usando um exemplo hipotético bem simples:

4- Uniformidade de processos com outros países

O app para gerar os arquivos no formato legal de cada país é o mesmo globalmente, então pelo menos os passos de executar o relatório e gerar o arquivo TXT são muito parecidos em todos os países (embora os passos antes de executar o relatório e conteúdo dele sejam completamente diferentes).

Por exemplo, gerar o txt da obrigação de retenções americana 1099 MISC é feito com os mesmos passos e no mesmo app que gerar o XML do REINF do Brasil.

5- Não tem app UI5 de OrgStr

Não tem mais o ORGSTR como um app Ui5. O app do ORGSTR sempre teve comportamento exótico com algumas validações meio problemáticas, agora a SAP criou uma visão na SM34 pura e simplesmente. Infelizmente não tem programa standard pra carregar as entradas das empresas/filiais para o ORGSTR.

Um tempo atrás fiz um post falando sobre o ORGSTR no DRC:

6- Não usa mais o TOM

Não tem o TOM pois agora as funcionalidades de execução/visualização dos arquivos estão agrupadas no app “Run Statutory/Compliance Reports” no S/4HANA. Isso é bom porque o app é o mesmo usado em todos os países, então é fácil entender o seu funcionamento, controlar acessos e tudo o mais. Um ponto importante é que, apesar dos relatórios terem a execução (geração do arquivo TXT) similar a de outros países, todos os passos de pré-apuração e preenchimento das shadows continuam sendo necessários. Além disso, outra mudança importante é que agora os arquivos são salvos usando o DMS/attachment server da SAP (CV03N para quem já usou isso).

Comparação do DRC BR com DRC em outros países

O DRC é uma solução global que atende relatórios de mais de 50 países, então já vi gente comentando que por saber DRC BR talvez possa fazer projetos de DRC em outros países, CALMA LÁ PESSOAL! Rapadura é doce, mas não é mole não…

Por ser muito parecido com a solução disponível no TDF, os relatórios e toda a localização por trás deles é muito diferente de qualquer outro país, então conhecer o DRC BR não garante que consultor está apto a implementar outros países ou que entende o framework para outros países de maneira ampla.

Na maioria dos países que eu trabalhei (ex: México, Argentina, Chile, Peru, Alemanha, Russia, Colombia, USA ) os relatórios foram desenhados para o DRC usando CDS views e classes/métodos próprios (no lugar de programas ABAP clássicos e calculation views no HANA) e estão baseados nos dados de FI (BSET/ACDOCA/BKPF) e não nos dados da nota fiscal (que só existe pelas bandas do BR).

Então alguém que conhece do DRC BR para os processos fiscais do BR ainda está anos-luz de distância dos processos de declarações contábeis e de impostos do resto do mundo. Dá para aprender? Dá, mas é um trabalho grande para quem conhece só a parte fiscal do BR.

Conclusão

Implementar DRC continua sendo difícil assim como era implementar TDF, tem todo o rolê técnico de instalação, notas, visualização das views, decisões de arquitetura dificeis (com ou sem BTP e como fazer extensões) fora o escopo de negócio.

Funcionalmente as duas soluções tem escopos parecidos para os SPED EFD’s, ECD e ECF compartilhando basicamente todo o CTR e mudanças funcionais maiores só no REINF mesmo.

Implementar o produto vai continuar exigindo especialistas que conhecem a parte fiscal, a parte técnica e sabem (de preferência) como funciona a localização Brasil e como devem ser preenchidas as notas fiscais, os dados mestres de clientes/fornecedores/materiais e os lançamentos contábeis para diminuir ao máximo o uso de shadows de maneira desnecessária.

Valeu Gurizada,

Renan Correa

Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube

Mais infos sobre a localização Brasil no ERP, direto da sap, vocês podem conferir no SAP community na tag de S/4HANA logistics for Brazil

Outros posts sobre Localização você pode conferir filtrando pela categoria NFE/CTE ou Localização BR Geral.

Outros posts sobre TDF você pode conferir filtrando pela categoria TDF/DRC.