Skip to Content

O OrgStr é um nome resumido de “Organizational Structure”, e contém as informações de empresa e filiais organizadas de forma unificada com foco fiscal.

1. Mas isso já não existe no ERP? Por que tudo novamente? Dupla manutenção?

Estas informações existem no ERP, e foram originalmente mapeadas no TDF (veja view sap.glo.tmflocbr.ctr/EMPRESA), no ERP é muito comum consumir os dados pela separação tradicional de empresa e filial que doravante chamarei de BUKRS / BRANCH seus nomes técnicos.

Há situações de negócio nas empresas que um mesmo CNPJ ou IE possa ser usado em mais de um BUKRS / BRANCH, seja por necessidade de logística, controles internos ou regimes especiais que permitem uma centralização report fiscal.

No TDF com a possibilidade de consolidar informações vindas de mais de uma fonte, seja ERP SAP ou non-SAP, a situação pode ficar ainda pior visto que uma empresa pode representar outro conjunto com código diferente de MANDT / BUKRS / BRANCH.

/wp-content/uploads/2015/08/fig1_767962.png

Foto: SM34 – J_1BBRANVC

/wp-content/uploads/2015/08/fig2_768038.png

Foto: SM34 – J_1BBRANVC – Detalhe

2. Qual o endereço correto? Qual a situação correta? E quando que é ou foi correto?

Ao gerar as informações para o governo, outro ponto aparece: Qual entre o conjunto de BUKRS / BRANCH possíveis tem o nome válido, o endereço, a situação, o indicador válido, em suma que tem as informações corretas do ponto de vista FISCAL.

Com as tabelas originais também era impraticável manter informações com foco nos entregáveis fiscais, controlando suas vigências. Especialmente para os cenários que eventualmente demandem uma fiscalização do histórico de modificações dos campos destas entidades, ou ainda nos processos de retificação de documentos.

3. Nasceu o OrgStr!

Para cobrir estes pontos foram desenhados novos cadastros, diretamente no TDF, fazendo a ponte entre o MANDT / BUKRS / BRANCH do sistema ERP com as informações das inscrições nos órgãos governamentais, leia-se CNPJ, Inscrição Estadual (IE) e Inscrição Municipal (IM) cobrindo as esferas federais, estaduais e municipais. O dono destes cadastros é o setor fiscal então pode mantê-lo independente das necessidades de negócio necessárias ao ERP.

Contextualizando então, ao se reportar um SPED ECD, ECF, Contribuições, que são federais, a informação a ser reportada vem das fichas relativas ao CNPJ, raiz basicamente. E ao se reportar um SPED EFD ICMS/IPI, que é estadual, as informações são obtidas da ficha de IE.

/wp-content/uploads/2015/08/fig3_768039.png

URL: https://<servidor>:<host>/sap/bc/ui5_ui5/tmf/OrgStr01/index.html?sap-client=100

Transação: /TMF/ORGSTR01

4. E esta ligação ERP x OrgStr como se dá?

A Karen Rodrigues e a Karla Reis já nos presentearam com posts (link no final) com as configurações que precisam ser feitas para o preenchimento, então vou escrever para a audiência mais técnica atendendo a algumas dúvidas recorrentes.

Configuração Accounting -> Tax Declaration Framework for Brazil -> Reporting -> Maintain External Systems Mapping – Nesta configuração obrigatória que você ensina o TDF quais dos dados transacionais serão relevantes preenchendo a tabela /TMF/D_SYS_INF.

Aqui cabe uma explicação mais detalhada sobre as formas de preenchimento possíveis, no quadro abaixo temos um mesmo BUKRS / BRANCH vindo de 4 fontes diferentes, para o consumo é o mesmo BUKRS / BRANCH mas veja que estarão gravados/replicados em 4 mandantes, neste forçado exemplo.

/wp-content/uploads/2015/08/fig_sys_inf_4_768040.png

SE16 – Tabela /TMF/D_SYS_INF (manutenção via SM30, caminho na SPRO)

 

 

MANDT = Mandante do netweaver onde o TDF está (no exemplo será sempre 100)

BUKRS = Código da empresa

BRANCH = Código do estabelecimento

MANDT_TDF = Sobre qual mandante as informações são conhecidas dentro do TDF, o comum será sempre ser igual a MANDT_ORIGINAL

MANDT_ORIGINAL = Qual o mandante que a informação está no sistema fonte

DESTINATION = RFC destination para que o SAP TDF possa chamar webservices de correção (só válido para SAP ERP)

IS_SAP = Indica se o sistema fonte é SAP ERP e pode ser acionado para correções automáticas

As quatro entradas, neste forçado cenário, representam então:

1) Fonte SAP ERP (XPTO) cliente 100 e encontrado como cliente 100 nas tabelas replicadas

2) Fonte SAP ERP (LT_QCC_400) cliente 400 e encontrado como cliente 400 nas tabelas replicadas

3) Fonte SAP ERP (LT_RCC_400) cliente 400 na fonte, com o detalhe de que nas tabelas replicadas ele será encontrado como 600

a. Se mantido o cliente 400 original gera conflito com a segunda fonte

b. Esta transformação de 400 para 600 deve ser configurada no SLT

4) Fonte non SAP que foi gravada nas shadows no TDF como mandante 800

Observação: Este é um exemplo forçado sendo que o comum seria apenas um dos exemplos acima.

Programa /TMF/INITIAL_LOAD – A execução deste programa é opcional, você pode cadastrar diretamente no OrgStr. Mas, se seu objetivo é fazer a importação de dados existentes nas tabelas T001, T001Z, J_1BBRANCH, etc…. automaticamente em tabelas do OrgStr /TMF/D_ESTABELEC, /TMF/D_CNPJ, /TMF/D_IE….  Sua utilização vai depender de cada caso, porém é provável que seja feito apenas em um primeiro momento já que a informação passará a ser mantida pela área fiscal.

A partir do TDF SP04, haverá a opção de importação delta, ou seja, somente daqueles registros que ainda não foram migrados ao TDF, isto se faz útil se você se “esqueceu” de configurar a D_SYS_INF para uma das filiais, ou se, novas filiais foram criadas no ERP após sua última importação de dados. Importante lembrar que este programa migra apenas os dados mapeáveis e, por não “conhecer” qual entidade é a mais “oficial” (num cenário de múltiplos CNPJs ou IEs), pode migrar dados incorretos, portanto, após a execução deste programa deve-se fazer os ajustes necessários e complementação de dados somente existentes no TDF.

/wp-content/uploads/2015/08/fig6_768041.png

5. Manutenção das informações

Apenas dois artefatos fazem manutenção no OrgStr sendo:

– o programa de carga /TMF/INITIAL_LOAD

– a transação UI5 /TMF/ORGSTR01 que faz validações de preenchimento

6. Interface de Manutenção em UI5 (/TMF/OrgStr01)

6.1. CNPJ – Ficha federal (visão estabelecimento) – principal tabela /TMF/D_CNPJ

/wp-content/uploads/2015/08/fig8_768042.png

* Dados são falsos gerados a partir de geradores encontrados na internet, se esbarrou em alguma informação real me avise para desqualificar nas imagens

Observe que os dados são da visão CNPJ, sem fazer menção aos códigos do ERP

/wp-content/uploads/2015/08/fig9_768043.png

O Root é criado automaticamente com dados básicos, que voltaremos para complementar depois de informado o estabelecimento.

/wp-content/uploads/2015/08/fig_cnpj_root_768048.png

6.2. IE – Inscrição Estadual – Ficha estadual – principal tabela /TMF/D_IE

/wp-content/uploads/2015/08/fig_ie_768049.png

/wp-content/uploads/2015/08/fig16_768050.png

Pesquisando

/wp-content/uploads/2015/08/fig_ie_2_768051.png

6.3. Estabelecimento (Business Place) – principal tabela /TMF/D_ESTABELEC

Ligação lógica do OrgStr (CNPJ / IE/ IM) com a física das informações transacionais (MANDT / BUKRS / CNPJ).

Essa visão é a ponte entre os dados lógicos da ficha federal (CNPJ) e estadual (IE) com os dados transacionais.

/wp-content/uploads/2015/08/fig_bp_768052.png

Observação: A abrangência deste 8013 / 0001 ainda vai considerar o que inicialmente foi configurado em /TMF/D_SYS_INF

6.4. Raiz do CNPJ – Ficha federal (visão empresa) – principal tabela /TMF/D_CNPJ_ROOT

Há uma criação automática ao se criar um CNPJ que não possui ainda seu CNPJ_ROOT, porém deve-se voltar nesta ficha para terminar a configuração.

Informar o nome, BUKRS / BRANCH da matriz e demais configurações específicas dos SPED’s

/wp-content/uploads/2015/08/fig_cnp_root_2_768053.png

6.4.1. SPED EFD Contribuições (internamente PCO):

/wp-content/uploads/2015/08/fig11_768054.png

6.4.2. SPED ECD Contábil:

/wp-content/uploads/2015/08/fig12_768055.png

6.4.3. SPED ECF Contábil Fiscal:

/wp-content/uploads/2015/08/fig13_768056.png

6.5. Centralização – tabela principal /TMF/D_CENTRAL_EFD

Usada em casos especiais para reportar o SPED Fiscal unificando informações de mais de um estabelecimento:

/wp-content/uploads/2015/08/fig19_768057.png

7. Consumo das informações pelos SPED’s

7.1. Consumo das informações pelo SPED EFD, por ser um report estadual ele permite execução por Estabelecimento, por Inscrição Estadual ou Central EFD (centralização):

/wp-content/uploads/2015/08/fig_efd_768058.png

7.2. Consumo pelo SPED ECD ou SPED Contribuições, permitem seleção pela empresa ou pelo CNPJ root

/wp-content/uploads/2015/08/fig21_768059.png

7.3. Consumo pelo SPED ECF, já vem pré-selecionadas as informações conforme a escrituração seja necessária (separação por situação especial)

/wp-content/uploads/2015/08/fig_22_ecf_768060.png

7.4. Exemplo de consumo por SPED

As informações transacionais (NF’s, lançamentos contábeis, etc.) permanecem como no sistema ERP fonte MANDT / BUKRS / BRANCH. Ao se executar o SPED ECF, por exemplo, é escolhido um CNPJ_ROOT equivalente a empresa a ser reportada. O aplicativo irá identificar estas chaves tradicionais MANDT / BUKRS / BRANCH através de views específicas, neste caso EMPRESA_FEDERAL e os pares obtidos usados na seleção transacional.

/wp-content/uploads/2015/08/fig_23_empresa_federal_768061.png

As views são então consultadas por seleção que identifica todas as possibilidades.


WHERE (MANDT='800' and EMPRESA='8013' and ESTABELECIMENTO='0001')
        OR (MANDT='600' and EMPRESA='8013' and ESTABELECIMENTO='0001')
        OR (MANDT='400' and EMPRESA='8013' and ESTABELECIMENTO='0001')
        OR (MANDT='100' and EMPRESA='8013' and ESTABELECIMENTO='0001')

Observação: As ligações não requerem que a parte transacional pertença à mesma EMPRESA e ESTABELECIMENTO e somente variando MANDT como neste exemplo. Os 3 campos podem variar, basta estarem assignados no business place ao IE ou CNPJ ou IM.

8. Detalhes da view de consumo OrgStr

As views HANA de consumo de OrgStr são EMPRESA_FEDERAL e EMPRESA_ESTADUAL, elas tem como particularidade parâmetros de vigência P_DT_INI e P_DT_FIM opcionais. Se nada informado ele busca a informação do dia atual.

Para exemplificar vamos modificar a visão de Inscrição Estadual (IE), que irá criar uma nova vigência:

fig_24_new interval.png

Criada ficha começando em 01/Julho/2015, modificado nome e perfil para B:

/wp-content/uploads/2015/08/frirg25_new_validity_768063.png

Existem dois casos de uso para passar parâmetros:

8.1. Obter a ficha unívoca para reporting (informar a data final do período em DE igual ATÉ). É assim que os SPED’s são chamados.

Exemplo de uma consulta de ficha válida em Dezembro (Exibe a nova)

/wp-content/uploads/2015/08/fig26_768064.png

Exemplo de uma consulta de ficha válida em Maio (Exibe a anterior)

/wp-content/uploads/2015/08/fig27_768065.png

8.2. Levantar todas as fichas que tiveram validade dentro de um período (informar DE e ATÉ nos parâmetros). Obs.: É assim que o ECF identifica automaticamente os regimes especiais ocorridos em um ano;

Exemplo de consulta de todas as fichas válidas durante o ano (exibe ambas as fichas)

/wp-content/uploads/2015/08/fig28_768066.png

Para saber mais:

Maintain Organizational Structures – SAP Tax Declaration Framework for Brazil (SAP TDF) – SAP Library

TDF – Por onde começar?

TDF – Passo-a-passo para gerar o ECF

Passo-a-passo para execução do SPED EFD ICMS/IPI no TDF

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Marcos Passos de Oliveira

    Olá, boa tarde!

    Muito útil as informações aqui prestadas, estão me ajudando bastante!!!

    Porém, estou encontrando um pouco de dificuldades com o EFD-Central…se alguém puder me ajudar eu agradeço?

    Criei uma EFD-Central com o local de negócios centralizador e N locais de negócios centralizados, porém, quando executo o SPED-EFD (ICMS/IPI) só estão sendo reportados os lançamentos das notas fiscais do local de negócio centralizador e os demais não…

    Alguém já passou por isso ou tem alguma dica?

    Desde já agradeço,

    Marcos Passos

    (0) 

Leave a Reply