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

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

Minha idéia original nesse post era responder tudo que as pessoas me perguntam sobre SAP DRC para relatórios legais e não está escrito explicitamente e de fácil acesso na na internet. Mas ao longo dos meses que passei escrevendo esse artigo notei que não ia conseguir botar tantos detalhes em um post só, não teria como esgotar esse assunto e o post nunca iria ficar pronto.

Então a idéia agora é mostrar, na minha opinião, numa sequerência de artigos algumas características importantes e que podem influenciar uma decisão de implementar ou não o DRC Brazil no S/4HANA on-premise e private cloud para relatórios legais.

Aproveitei também para destacar pontos que afetam a implementação, a operação e atualização do sistema na visão de consultor/consultoria (e não só na visão do cliente).

Para tentar facilitar a compreensão do assunto trago várias vezes comparações entre o TDF (que hoje possui mais implementações e é mais conhecido ainda) e o DRC BR.

Reports de BR no DRC

O DRC é a solução da SAP para relatórios legais e documentos eletrônicos no mundo todo, essa solução está localizada para BR para atender NF-e de saída e entradas (parcialmente usando o framework de documentos eletrônicos) e atender os relatórios SPED (parcialmente usando o framework de relatórios estatutários, nome horroso diga-se de passagem).

Aqui fica o link para uma apresentação de overview da solução:

Preparei também essa imagem para ilustar uma arquitetura possível de DRC BR considerando todos os módulos dele (NF-e entradas, NF-e saídas e relatórios). No restante do blog vou me concentrar na parte do DRC Reporting (do meio para cima da imagem) e não na parte de DRC eInvoice (do meio para baixo ).

Então agora vamos aos detalhes do DRC BR focando em SPED e tributos.

Arquitetura do DRC BR standard e recomendações para soluções fiscais

O DRC BR é embedded no S/4HANA, ou seja, está dentro do core do sistema (pacote S4CORE) diferentemente do TDF que era um side-car ou seja, estava em um pacote próprio (TMFLOCBR) e em uma outra instalação de BASIS/Netweaver (podendo ainda ter um banco separado no caso de usar SLT).

Implementar uma nota no TDF era implementar uma nota em sistema APARTADO do ERP, apesar de existirem pré-requisitos de ERP como tabelas e campos de tabela que precisavam estar em sincronia. Caso existisse algum error no framework do TDF ou uma mudança legal que exigisse uma atualização isso era uma preocupação para o sistema do TDF, não para a instalação do ERP da empresa. Agora a conversa é outra, qualquer atualização do DRC BR em termos de views e tabelas shadow está dentro do S4CORE e vai precisar respeitas janelas de atualização e os requisitos de governança do S/4HANA da empresa.

Além dessa diferença, agora a recomendação para solução fiscal complementar é que ela seja implementada no BTP, fazendo update das shadows via API no S/4HANA e lendo os dados de um “mini CTR” no BTP usando o SDA. Isso é diferente do modelo usado normalmente no TDF, onde o add-on fiscal está instalado junto com o TDF.

No momento existem poucas soluções parceiras certificadas usando esse modelo, mas esse é o target operating model proposto pela SAP para homologar produtos de parceiros.

Um resumo bem simples dessa arquitetura está na imagem abaixo:

Como são estruturados os reports do DRC Brazil?

A maior parte dos relatórios do SPED no DRC BR usa o modelo de relatório clássico, apenas o REINF é diferente e foi re-desenhado usando o conceito mais atual do DRC. Vamos ver um pouco mais de detalhes e o que isso significa na prática.

Reports Clássicos

Essa conversa do report clássico se aplica para o SPED EFD-ICMS, Contribuições, ECD e ECF.

Isso na prática significa que esses relatórios são programas ABAP clássicos (muito similares aos do TDF) com algumas alterações apenas para utilizar o framework do DRC, que possui suas tabelas/classes próprias para controle das execuções, definições dos relatórios bem como para armazenar os arquivos no attachment server.

O TDF foi desenvolvido vários anos atrás usando tecnologia que na época era “estado da arte” em termos de SAP HANA (HANA graphical calculation views). Essas CV’s, as tabelas shadow e os reports do SPED foram re-utilizadas no DRC BR, quase que na íntegra, com pequenas adaptações e ajustes.

Isso significa que, funcionalmente, uma boa parte do DRC roda igual ao TDF, embora a arquitetura técnica tenha mudado bastante do Hana Repository (tecnologia usada no TDF) para o container HDI (tecnologia usada no S/4HANA e DRC).

Então, resumidamente, posso dizer para quem conhece o TDF que o CTR existe lá e está todo baseado em calculation views no HANA exatamente assim como era no TDF. Se você sabe como funciona a view NF_DOCUMENTO_ITEM_IMPOSTO no TDF, PARABÉNS, você já sabe como funciona a view NF_DOCUMENTO_ITEM_IMPOSTO no DRC.

Isso por um lado é uma vantagem muito grande, já que o consultor que conhece o TDF pode aproveitar a maior parte do conhecimento das shadows e do CTR para fazer um projeto de DRC BR.

Abaixo um screenshot da definição de um report clássico no DRC, no caso o EFD-ICMS:

Para quem é bom de memória, sim, é o mesmo nome do programa no TDF que gera o EFD-ICMS, mas o conteúdo ABAP é ligeiramente ajustado já que precisa utilizar o novo framework para aparecer no app de statutory reports e gravar os arquivos no attachment server (DMS). Esse app de “Run Statutory Reports” é o substituto do TOM (Tax Obligation Monitor), todas as execuções e downloads dos relatórios são feitos por ele.

Mas, nem tudo são flores, assim como por um lado existe a vantagem das calculation views serem muito parecidas com as do TDF, por outro lado essa tecnologia (graphical calculation view) hoje em dia não é tão estado-da-arte assim e não é empregada em muitas aplicações (salvo BW e algumas outras raras aplicações analíticas) o que faz com que continuem existindo poucos especialistas no mercado com conhecimento amplo no assunto se comparado com CDS View (usada amplamente em desenvolvimentos com Fiori/UI5 no S/4HANA e no BTP). Por isso o range de especialistas técnicos para fazer desenvolvimentos continua sendo limitado assim como no TDF. Além disso, vamos ver mais adiante que não tem mais o HANA studio, então acessar as views é mais complicado no DRC BR.

Reports novos (REINF)

Como mencioniei anteriormente a exceção dos relatórios do DRC BR é o REINF, pois ele foi, de fato, redesenhado usando o framework completo do DRC, o conceito de staging tables foi jogado fora e toda a parte da mensageria foi refeita, dessa vez direto na nuvem usando o BTP e integrado como um produto chamado DRC service.

Abaixo vocês podem ver a definição de um dos reports do REINF:

Dessa maneira a geração do relatório está baseada em queries no DRC e mapeamento dos dados das queries para as respectivas tags do XSD dos eventos. Essas queries utilizam calculation views do HANA (praticamente iguais as do TDF). A SAP desenhou todo um framework de execução de queries e mapeamento dos dados dessas queries para o formato de documento definido no DRC e o REINF está usando essa solução técnica.

Aqui tem um outro ponto interessante, como não existe mais uma mensageria on-premise disponível (como existia no TDF) é necessário adquirir também uma licença do DRC Service (SLH-ACR Service antigamente), configurar uma conta no BTP para o serviço, configurar o serviço com CNPJ’s e certificados digitais, e criar RFC do S/4HANA para a respectiva sub-account para executar o envio dos eventos. A comunicação se dá apenas pela plataforma da SAP e não exige esforço de configuração/manutenção da interface com o governo via SOA Manager ou PI/PO.

O programa de pré-processamento do REINF inicialmente tinha ido para o espaço, mas com os novos eventos R-4000 a SAP trouxe um novo programa de pré-processamento para o REINF e inseriu ele dentro das etapas de geração dos novos eventos R-4000. Esse relatório é novo e o R-4000 é um capítulo a parte, vai ficar para um post futuro.

Alterações técnicas do TDF para o DRC – HDI, XSA e WebIDE

Já que falei um pouco de tecniquês vamos a uma mudança importantíssima que houve na camada do banco, agora não temos mais HANA Repository e por isso não é mais possível usar o HANA Studio para visualizar graficamente as calculation views (isso também tem impacto na forma como são feitos desenvolvimentos, mas esse tema vou abordar mais pra frente ).

A forma de acessar as views agora é através do XSA / WebIDE no ambiente on-premise pois só assim é possível acessar o conteúdo do container HDI (Hana Deployment Infrastructure) onde as CV’s ficam agora.

Mais explicações sobre HDI você encontra no google, tipo essa: https://blog.sap-press.com/the-sap-hana-deployment-infrastructure.

Mais detalhes sobre HDI, XSA e WebIDE

XSA e WebEDI são componentes pouco utilizados no mundo hoje e por isso também existem poucos especialistas com experiência no uso e na instalação/configuração deles. Uma das primeiras experiências que tive com a ferramenta foi muito ruim, pois BASIS nunca havia instalado e configurado e sofreu muito com o sistema (não é instalador com NEXT, NEXT, NEXT). Uma das primeiras coisas que aconteceu comigo e levou tempo até basis corrigir foi problemas de autorização:

No portal Help e no portal de suporte da SAP tem alguns documentos interessantes para ajudar na instalação, mas ainda não vi nenhum documento BALA de prata explicando tudo tin tin por tin tin:

https://support.sap.com/content/dam/support/en_us/library/ssp/tools/Software-logistic-tools/hta-for-hdi-guide-v1.pdf

Outra dica importante, aprenda a usar isso daqui caso você queira trabalhar com WebIDE e DRC BR:

call SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS (‘GUID OF THE MESSAGE’, ?)

Aqui embaixo tem a cara do WebIDE (depois de instalado e configurado com as views do container HDI SAPTMF_RT):

Abaixo tem uma tela mostrando a visualização de uma calculation view no WebIDE, esse ponto é bem parecido com o Hana Studio:

Essa imagem aqui é de um blog post da SAP bem interessante:

https://blogs.sap.com/2021/02/01/sap-s-4hana-for-advanced-compliance-reporting-brazil-option-on-premise-como-estender-ou-customizar-utilizando-as-sap-hana-calculation-views-do-hdi/

A instalação, criação das autorizações e configuração inicial do XSA, do WebIDE e do Database Explorer (para acessar as views) é um tópico a parte. Todos os projetos que participei o pessoal de BASIS teve muitas dificuldades de entender e executar essa instalação. Abaixo um exemplo de um dos erros que passamos durante o projeto:

O WebIDE é uma ferramenta acessada pelo browser e (assim como o XSA) utiliza portas específicas, então para a equipe da consultoria acessar isso através de VPN’s do cliente precisa de liberações específicas feitas equipe de redes/Infraestrutura, outro ponto de atenção importante. Na instalação disso daí ainda precisa que sejam liberadas autorizações no banco para executar queries e é um misto de instalação de BASIS com passos específicos do DRC (como fazer o check-out das views e/ou criar um container específico para os desenvolvimentos próprios) então não é algo que o BASIS vai fazer tudo sozinho, o projeto precisa dar um guidance e executar algumas atividades por conta própria.

Continua na Parte 2… Semana que vem…

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/DRR.