Do you want to read this in English? Click here.
Olá.
Neste blog continuaremos falando sobre o pré-processamento com ênfase nos cenários suportados pelo mesmo.
Sugerimos a leitura dos seguintes blogs para ajudar na contextualização do assunto: TDF: EFD-Reinf 2.1.1 – Análise de Cenário e TDF: EFD-Reinf 2.1.1 – Novidades no Pré-processamento.
Pré-requisitos
Você deve ter o Support Package 17 do TDF instalado e atualizado conforme lista de notas de pré-requisitos para a instalação da SAP note:
Cenários Suportados
Abaixo, serão descritos os cenários suportados. Já adianto que nem todos os cenários são cobertos pelo processo, porém os que serão descritos a seguir são resultado de uma união entre SAP e vários clientes, onde trabalhando juntos para cobrir os cenários mais comuns a fim de facilitar o dia a dia dos clientes que precisam reportar a EFD-Reinf.
Regras Gerais
Como regra geral, para identificar durante o pré-processamento que o dado é para o R-4010, se faz necessário que o campo Natural Person (LFA1-STKZN) esteja marcado no cadastro do fornecedor.
Figura 1
Tela do Cadastro de Fornecedor indicando o campo Natural Person
É importante salientar que, devido a possibilidade de um fornecedor ser do exterior, não necessariamente o campo de CPF (LFA1-STCD2) estará preenchido.
Outro ponto importante é que esse cenário deve ter informações na tabela WITH_ITEM. Esse dado é criado automaticamente quando o fornecedor tem os dados de impostos retidos cadastrados e o processo é realizado pelo processo standard de compras:
Figura 2
Tela de Cadastro de Fornecedores com as informações de Imposto Retidos cadastrados
No exemplo acima, esse tipo de imposto está cadastrado no momento de fatura:
Figura 3
Tela demonstrando imposto cadastrado para ser utilizado em momento de fatura.
Com isso, o sistema entende que o pré-processamento irá reconhecer essa data como a data do fato gerador <dtFG> no momento de contabilização da fatura.
Sem uso da BADI, é necessário configurar a Income Nature (/TMF/D_R_NATREND) no ambiente SAP TDF. Utilize o campos TIPO_DOC , COD_PART, COD_CTA_DESP, NAT-REND e NAT_REND_OBS para selecionar os documentos fiscais corretamente e determinar a natureza de rendimento conforme a necessidade.
Para entender da configuração citada acima e também como determinar a natureza de rendimento, acesse o blog TDF: EFD-Reinf 2.1.1 – Como Determinar a Natureza de Rendimento.
Caso o pré-processamento do documento contábil tenha imposto retido mas não tenha encontradou nenhuma regra na Income Nature , o sistema irá criar uma linha na Lançamentos de Rendimento/Pagamentos com Retenção (/TMF/D_LCTO_RENRT), mas não irá preencher o campo NAT_REND. Neste caso, recomendamos as regras configurados na Nature Income e/ou reveja a implementação da BADi de pré-processamento.
É importante observar qual documento será colocado na configuração Income Nature. Caso seja colocado o documento da fatura e o documento da compensação e o processo de retenção seja baseado em pagamento, teremos um lançamento duplicado.
Figura 4
Tela demonstrado documento de fatura no SAP
Figura 5
Tela demonstrando documento de pagamento no SAP
Figura 6
Configuração considerando tanto documento de Fatura e Pagamento
Portanto, não é recomendado colocar na configuração o tipo de documento de pagamento e sim somente o tipo de documento da fatura.
Essa linha criada pode ser eliminada posteriormente. Supondo que a linha não existia e que não tenha a entrada com tipo de documento do pagamento (no cenário tipo de documento ZP), teríamos o seguinte resultado esperado:
Observar que na configuração Nature Income, apesar de ter entrada do COD_PART, as regras são:
- TIPO_DOC vs COD_PART vs COD_CTA_DESP
- TIPO_DOC vs COD_CTA_DESP
Se houver uma linha somente com COD_PART, esse dado não será usado, pois não será suportado neste momento.
Entrada de fatura com mais de um item, com entrada de mercadoria e reconhecimento do IR em momento de fatura
Nesse cenário, para a revisão de fatura de MM, foram registradas entradas no pedido de compra e posteriormente foram realizadas a entrada de mercadoria.
Figura 7
Pedido de Compra no SAP
Com isso, é criado o documento contábil no momento da entrada de fatura.
Figura 8
Invoice demonstrando Documento Contábil criado no SAP
Se observarmos o documento contábil da entrada de fatura, é possível identificar que a contrapartida do fornecedor são as contas do imposto retido e a transitória de recebimento.
Figura 9
Documento Contábil no SAP
Nesse cenário, observarmos que temos a conta de despesa correta associada ao processo no pedido de compra:
Figura 10
Pedido de Compra no SAP demonstrando a conta razão
É importante informar que não será suportado de forma standard um hipotético cenário em que tenha mais de uma conta do razão para o mesmo item.
Isso acontece pois os impostos retidos são tratados a nível de documento e como foi colocado pelos clientes nas reuniões de desenvolvimento da solução, esse cenário não será tratado de forma standard pelo pré-processamento. Caso tenha esse cenário no seu processo, você deve implementar a BAdI para tratar corretamente o seu cenário.
Por outro lado, caso tenha mais de um objeto de custo com a mesma conta de despesa, esse cenário será suportado.
Figura 11
Pedido de Compra com dois objetos de custo diferentes no SAP
Neste caso, o sistema irá realizar a leitura do campo da conta de despesa no pedido de compra para comparar com os dados na Income Nature no TDF.
No próximo blog, seguiremos falando sobre os cenários suportados pelo pré-processamento, só que para o evento R-4020.
Gostaríamos muito de saber o seu feedback. Deixe seu comentário abaixo caso tenha alguma dúvida ou sugestão para um próximo post. E não esqueça de seguir a tag SAP Tax Declaration Framework for Brazil aqui na SAP Community para ficar ligado nas últimas notícias sobre o Tax Declaration Framework (TDF).
Além dos comentários, você pode entrar em contato conosco através da plataforma Customer Influence. Lá você pode propor ideias para melhorar o nosso produto, votar em outras ideias já lançadas e acompanhar ideias em implementação.
Até a próxima!
Rodolfo Felipe Celante
Time de desenvolvimento do TDF
#SAPGoGlobal #SAPLocalization
- SAP Managed Tags:
1 Comment
