E aí pessoal!
Nesse blog post vou mostrar algumas dicas sobre o CTR e como analisar os dados nas calculation views do TDF/ACR Brazil.
A idéia não é ser um guia definitivo sobre todos os cenários, mas sim um ponto de partida para fomentar discussões sobre o tema e quem sabe encontrar outras práticas para fazer análises nos dados do CTR.
Um dos conceitos centrais do TDF (e agora do ACR Brazil) é o que a SAP chamou de "CTR - Central Tax Repository".
Apesar dessa importância do CTR, não existe muito material disponível (principalmente em português) para consulta falando sobre a sua estrutura e como entendê-lo melhor.
Usando um exemplo simples vou ilustrar como normalmente um consultor pode entender a origem do VL_ICMS no registro C100 do SPED EFD.
Consultor TDF buscando a origem do VL_ICMS no CTR pela primeira vez !
Fonte: Pexels Images
Não precisa da bola de cristal, mas esse trabalho de entender o CTR exige bastante engenharia reversa para conhecer as views e interpretar o conteúdo delas.
No SAP Inside Track Joinville de 2016 foi apresentado esse slide abaixo ( Obrigado, google! ) e depois variações dele foram mostradas em várias apresentações e adaptadas por consultores e parceiros. A imagem é originalmente criada pela SAP:
Fonte: Autor desconhecido (provavelmente algum desenvolvedor do time do TDF)
Essa imagem mostra uma idéia interessante de como funcionam as views do CTR, e como eles são os dados são consumidos da origem ( tabela do ERP ) até a sua saída ( relatório SPED EFD, registro C100 ) .
O que não temos como saber claramente a partir dessa imagem é como exatamante os dados são mapeados dentro das view ( como são calculados e manipulados ). Essa imagem nos dá a cara para a estrutura de relacionamentos de alto nível entre as views, mas não mostra ( e nem teria espaço em um slide só ) o interior da solução.
Segue lendo as dicas...
Se não há um campo específico no banco, é possível inferir que o TDF deve fazer algum cálculo em algum lugar para transformar essa informação do tipo de imposto do item no VL_ICMS do item.
Voltando ao desenho do CTR podemos inferir que VL_ICMS no registro C100 deve vir da view NF_DOCUMENTO_ITEM_IMPOSTO (por ser um dado de impostos e que é a soma dos itens) e consequentemente da view NF_IMPOSTO ( que buscou dados tanto da shadow como da tabela J_1BNFSTX, a que vemos na aba de impostos do item da nota ).
Para facilitar, modifiquei o slide da SAP e adicionei mais uma view que não estava lá originalmente, a NF_IMPOSTO_CALCULO, essa view é bem importante porque ela transforma os dados de impostos do formato ERP ( Tipo de Imposto, Base, Alíquota, Valor ) para o formato que você vê na NF_DOCUMENTO_ITEM_IMPOSTO (VL_ICMS, VL_ALIQ, VL_BC_ICMS ) :
A SAP tem algumas ferramentas para ajudar a encontrar a origem de informações como o programa CTR Tech Info no TDF. Mas existem outras maneiras que vou listar abaixo.
Para quem conhece como utilizar o hana studio no lugar do programa "CTR tech info" é possível fazer acessos no HANA com as consultas SQL abaixo ( ou via data preview usando a view VIEWS_CADEIA_DE_CONSUMO 😞
Com isso é possível identificar ( mais ou menos como no Tech Info ) de onde (view ou tabela) as informações são buscadas.
É interessante guardar um catálogo seu de consultas SQL, para os casos mais usados. Provavelmente será mais rápido trocar dois valores no WHERE da consulta do que sempre fazer um data preview e adicionar todos os filtros manualmente.
Mas ainda não chegamos no detalhe dos campos e dos cálculos. Para isso podemos usar outra funcionalidade.
Se você já sabe a view de onde o campo vem, a próxima opção seria abrir o campo e utilizar o botão 'lineage' para identificar de onde vem o dado.
Na estrutura do CTR se você não sabe onde achar um campo você pode começar na view do SPED ( como as EFD's ou PCO's ) e ir procurando o campo via lineage e descendo os níveis até chegar na origem ( pode ser uma view de reuso ou uma private.
Preciso clicar campo a campo em cada nodo da view e das views consumidas pra achar de onde ele foi mapeado? Depende.
Clicando campo a campo que nem um pombo procurando milho na praça certamente é uma maneira de olhar todos os cálculos, mas existem outras maneiras que podem ser mais efetivas.
Então tem outro jeito de buscar isso?
Bom, ter, tem...
No HANA Studio/Eclipse temos uma opção de visualizar as views em formato XML.
E aí, qual a vantagem disso?
Nesse caso buscando por VL_ICMS encontramos o campo e ( PASMEM! ) a fórmula utilizada para o cálculo do valor.
Abaixo tem o exemplo com o campo VL_ICMS. Esse campo é calculado e a fórmula pode ser visualizada no XML ( claro que você pode ir abrindo os nodos e clicar no campo e abrir a fórmula )
Então, resumidamente, o preenchimento do campo VL_ICMS depende da categoria de imposto ICMS, se a BASE está preenchida, se o campo subdivisão está em branco e se VALOR_IMP está preenchendo.
As sap notes que tem alterações de calculation views não mostram no Launchpad o conteúdo da alteração de maneira completa:
Isso quer dizer que somente na transação SNOTE é possível ver o conteúdo completo da alteração.
No SNOTE você irá ver o seguinte dentro da Correction Instruction:
Então nesse ponto você tem tanto o XML alterado como o antigo. Assim é possível comparar qual a alteração que foi feita entre uma versão e outra.
É possível também comparar uma view de QAS (por causa de diferenças em regression tests após aplicar SP ou conjunto de notas) e a mesma view de PRD.
E aí, vocês tem alguma dica extra? Ou tem alguma fórmula muito complicado que você já achou numa view? Se sim, adiciona nos comentários e podemos discutir mais sobre o assunto.
att,
As imagens da estrutura do CTR usadas nesse blog post são simplificações da realidade, essas views são bem mais complexas que o mostrado na imagem. Por exemplo, se olharmos a view EFD_C100 atual no HANA ela é assim:
Por aqui já é possível ver que existem nodos que contêm projeções, joins, agregações, cálculos e filtros que não estão incluídos na imagem inicial.
Nesse blog post vou mostrar algumas dicas sobre o CTR e como analisar os dados nas calculation views do TDF/ACR Brazil.
A idéia não é ser um guia definitivo sobre todos os cenários, mas sim um ponto de partida para fomentar discussões sobre o tema e quem sabe encontrar outras práticas para fazer análises nos dados do CTR.
Um dos conceitos centrais do TDF (e agora do ACR Brazil) é o que a SAP chamou de "CTR - Central Tax Repository".
O CTR é um conjunto de views de banco de dados e tabelas com o objetivo de armazenar centralmente os dados fiscais e permitir a criação de relatórios reutilizando estes conceitos, garantindo consistência e padronização na apresentação dos SPED e obrigações acessórias.
Apesar dessa importância do CTR, não existe muito material disponível (principalmente em português) para consulta falando sobre a sua estrutura e como entendê-lo melhor.
Usando um exemplo simples vou ilustrar como normalmente um consultor pode entender a origem do VL_ICMS no registro C100 do SPED EFD.
Consultor TDF buscando a origem do VL_ICMS no CTR pela primeira vez !
Fonte: Pexels Images
Dica 1 - Entenda primeiro a visão geral da estrutura
Não precisa da bola de cristal, mas esse trabalho de entender o CTR exige bastante engenharia reversa para conhecer as views e interpretar o conteúdo delas.
No SAP Inside Track Joinville de 2016 foi apresentado esse slide abaixo ( Obrigado, google! ) e depois variações dele foram mostradas em várias apresentações e adaptadas por consultores e parceiros. A imagem é originalmente criada pela SAP:
Visão Resumida do CTR para o registro EFD_C100
Fonte: Autor desconhecido (provavelmente algum desenvolvedor do time do TDF)
Essa imagem mostra uma idéia interessante de como funcionam as views do CTR, e como eles são os dados são consumidos da origem ( tabela do ERP ) até a sua saída ( relatório SPED EFD, registro C100 ) .
O exemplo é do C100 do SPED, mas vale a pena lembrar da hierarquia da view NF_DOCUMENTO_ITEM_IMPOSTO pois ela é uma view central para a maioria dos dados que são provenientes de Documentos Fiscais.
O que não temos como saber claramente a partir dessa imagem é como exatamante os dados são mapeados dentro das view ( como são calculados e manipulados ). Essa imagem nos dá a cara para a estrutura de relacionamentos de alto nível entre as views, mas não mostra ( e nem teria espaço em um slide só ) o interior da solução.
Então como identificar a origem exata do VL_ICMS de um registro C100 para um determinado documento fiscal?
Segue lendo as dicas...
Dica 2 - Conheça a view NF_IMPOSTO_CALCULO
Se não há um campo específico no banco, é possível inferir que o TDF deve fazer algum cálculo em algum lugar para transformar essa informação do tipo de imposto do item no VL_ICMS do item.
Voltando ao desenho do CTR podemos inferir que VL_ICMS no registro C100 deve vir da view NF_DOCUMENTO_ITEM_IMPOSTO (por ser um dado de impostos e que é a soma dos itens) e consequentemente da view NF_IMPOSTO ( que buscou dados tanto da shadow como da tabela J_1BNFSTX, a que vemos na aba de impostos do item da nota ).
Para facilitar, modifiquei o slide da SAP e adicionei mais uma view que não estava lá originalmente, a NF_IMPOSTO_CALCULO, essa view é bem importante porque ela transforma os dados de impostos do formato ERP ( Tipo de Imposto, Base, Alíquota, Valor ) para o formato que você vê na NF_DOCUMENTO_ITEM_IMPOSTO (VL_ICMS, VL_ALIQ, VL_BC_ICMS ) :
Dica 3 - Use a consulta via Cadeia de consumo no HANA ( e outras consultas )
A SAP tem algumas ferramentas para ajudar a encontrar a origem de informações como o programa CTR Tech Info no TDF. Mas existem outras maneiras que vou listar abaixo.
Para quem conhece como utilizar o hana studio no lugar do programa "CTR tech info" é possível fazer acessos no HANA com as consultas SQL abaixo ( ou via data preview usando a view VIEWS_CADEIA_DE_CONSUMO 😞
select
*
from
_sys_bic."sap.glo.tmflocbr.ctr/VIEWS_CADEIA_DE_CONSUMO"
where caller_name like 'sap%EFD_C100'
order by nivel_consumo
Select
*
from
_sys_bic."sap.glo.tmflocbr.ctr/VIEWS_CADEIA_DE_CONSUMO"
where table_or_view = '/TMF/D_NF_IMPOST'
and caller_name like 'sap.glo%'
order by nivel_consumoCom isso é possível identificar ( mais ou menos como no Tech Info ) de onde (view ou tabela) as informações são buscadas.
É interessante guardar um catálogo seu de consultas SQL, para os casos mais usados. Provavelmente será mais rápido trocar dois valores no WHERE da consulta do que sempre fazer um data preview e adicionar todos os filtros manualmente.
Mas ainda não chegamos no detalhe dos campos e dos cálculos. Para isso podemos usar outra funcionalidade.
Dica 4 - Use a função "Show Lineage"
Se você já sabe a view de onde o campo vem, a próxima opção seria abrir o campo e utilizar o botão 'lineage' para identificar de onde vem o dado.
Na estrutura do CTR se você não sabe onde achar um campo você pode começar na view do SPED ( como as EFD's ou PCO's ) e ir procurando o campo via lineage e descendo os níveis até chegar na origem ( pode ser uma view de reuso ou uma private.
Preciso clicar campo a campo em cada nodo da view e das views consumidas pra achar de onde ele foi mapeado? Depende.
Clicando campo a campo que nem um pombo procurando milho na praça certamente é uma maneira de olhar todos os cálculos, mas existem outras maneiras que podem ser mais efetivas.
Então tem outro jeito de buscar isso?
Bom, ter, tem...
Dica 5 - Acesse o XML das views para fazer comparações/CTRL+F
No HANA Studio/Eclipse temos uma opção de visualizar as views em formato XML.
E aí, qual a vantagem disso?
Nesse caso buscando por VL_ICMS encontramos o campo e ( PASMEM! ) a fórmula utilizada para o cálculo do valor.
Abaixo tem o exemplo com o campo VL_ICMS. Esse campo é calculado e a fórmula pode ser visualizada no XML ( claro que você pode ir abrindo os nodos e clicar no campo e abrir a fórmula )
XML da fórmula
Então, resumidamente, o preenchimento do campo VL_ICMS depende da categoria de imposto ICMS, se a BASE está preenchida, se o campo subdivisão está em branco e se VALOR_IMP está preenchendo.
DICA 6 - Entenda as alterações feitas pelas SAP Notes nas calculation views
As sap notes que tem alterações de calculation views não mostram no Launchpad o conteúdo da alteração de maneira completa:
Isso quer dizer que somente na transação SNOTE é possível ver o conteúdo completo da alteração.
No SNOTE você irá ver o seguinte dentro da Correction Instruction:
Detalhes do SNOTE
Então nesse ponto você tem tanto o XML alterado como o antigo. Assim é possível comparar qual a alteração que foi feita entre uma versão e outra.
É possível também comparar uma view de QAS (por causa de diferenças em regression tests após aplicar SP ou conjunto de notas) e a mesma view de PRD.
E aí, vocês tem alguma dica extra? Ou tem alguma fórmula muito complicado que você já achou numa view? Se sim, adiciona nos comentários e podemos discutir mais sobre o assunto.
att,
Renan Correa
Observação:
As imagens da estrutura do CTR usadas nesse blog post são simplificações da realidade, essas views são bem mais complexas que o mostrado na imagem. Por exemplo, se olharmos a view EFD_C100 atual no HANA ela é assim:
Por aqui já é possível ver que existem nodos que contêm projeções, joins, agregações, cálculos e filtros que não estão incluídos na imagem inicial.
- SAP Managed Tags:
7 Comments
