Do you want to read this in English? Click here.

Neste blog será detalhado como você pode transmitir os eventos da EFD-Reinf utilizando a comunicação assíncrona via HTTP Client.

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:

Definições Gerais

Mesmo antes dos novos eventos da série 4000, a EFD-Reinf já possuía um evento que era assíncrono –  o evento R-2099. No R-2099, o evento era enviado, um protocolo era retornado e, após algum tempo, o retorno final após o processamento do lado da Receita Federal retornava o R-5011.

A partir do leiaute R2.1.1, essa forma de envio vale para todos os eventos. Isso significa que após os eventos serem enviados, você receberá um protocolo e, com essa informação, consultas poderão ser realizadas. Em um momento futuro (quando o processamento do lado da Receita Federal tiver sido concluído) será enviado os evento de retorno de acordo com o evento enviado.

Durante alguns meses do leiaute corrente (atualmente o 2.1.2), os eventos poderão ser enviados tanto de forma síncrona quanto assíncrona. Depois desse período, a Receita Federal irá receber os eventos somente na forma assíncrona. Essa informação pode ser verificada no Manual de Orientação do Desenvolvedor. Mais detalhes Manual de Orientação do Desenvolvedor 2.2 – Cápitulo 6.

Figura 1

Convívio de modelos síncrono e assíncrono segundo a Receita Federal

A preferência da Receita Federal é indicado que seja enviado sempre que possível por meio assíncrono, juntamente com a definição que será mantido somente o envio por meio assíncrono. Seguindo esse preferência, a SAP está disponibilizando somente o envio de todos os eventos no formato assíncrono deste então.

Configuração Necessária

Após a aplicação das SAP Notes informadas na seção de pré-requisitos, fique atento ao passo manual da SAP Note 3305556 que explica dois pontos principais necessários para que seja possível a transmissão dos eventos: criação de uma Remote Function Call (RFC) e um ajuste em uma configuração.

Abrindo a configuração Government Communication using Local System (/TMF/MD_SOACOMM), será possível perceber a inclusão de uma nova coluna, Remote Function Call (RFC) Destination (RFC_DESTINATION).

Figura 2

Detalhes da configuração Government Communication using Local System

Se você utilizava o envio dos eventos exclusivamente através do SOAMANAGER, você deve preencher esse campo com a RFC criada em seu sistema. A Receita Federal agora utiliza o protocolo REST, que inviabiliza a utilização do SOAMANAGER devido incompatibilidades.

Logo, a SAP entrega duas formas de enviar os eventos, via HTTP Client (Creating the HTTP Client), onde é selecionada a URL de destino utilizando uma RFC, como está sendo descrito agora e via Process Integration (PI). Esse segundo modelo será entregue em breve.

Com essa atualização, a seguinte regra é aplicada para determinar qual forma de comunicação (PI ou HTTP Client) será utilizada:

Como Transmitir os Eventos

Mesmo com as novidades descritas nesse blog, a experiência geral de se enviar eventos da EFD-Reinf através do SAP TDF Messaging Framework não foi alterada.

A experiência de fato funcionará como já funcionava para o evento R-2099 como mencionado anteriormente nesse blog.

Abaixo será demonstrado como ficou o envio dos eventos da EFD-Reinf em geral utilizando a configuração para enviar os eventos via HTTP Client.

Neste exemplo foi gerado um R-4010.

Figura 3

Evento R-4010 no SAP TDF Messaging Framework

Após a geração do evento, você deverá processar a transação TDF Messaging – Flow Execution (/TMF/MF_FLOW_EXEC), esse processamento pode ser feito ativamente ou via JOB.

Figura 4

Transação TDF Messaging – Flow Execution

Nessa etapa será visto a diferença de envio entre os modelos síncronos e assíncronos. No modelo assíncrono, você receberá o protocolo do envio do lote contendo os eventos transmitidos. Também é possível perceber que em um primeiro momento, a Receita Federal irá retornar com o protocolo mais o status 1 – O lote está aguardando processamento.

Figura 5

Detalhes do lote enviado no TDF Messaging Framework

Após o recebimento do protocolo, será necessário repetir o passo da transação TDF Messaging – Flow Execution (/TMF/MF_FLOW_EXEC) para que seja feito uma consulta a partir do protocolo que foi enviado e está no lote atualmente.

Nessa segunda etapa é necessário o preenchimento do campo Flow com o valor BATCHR.

Para o campo Filter Steps, duas opções podem ser utilizadas: Deixar o campo vazio ou pode ser criado um novo JOB para somente realizar a etapa de consulta e atualizar os eventos, onde o campo Filter Step pode ser preenchido com o valor BATCH_RESP.

Figura 6

Detalhe de filtro utilizado na transação TDF Messaging – Flow

Após o processo acima ter sido realizado e se o processamento estiver concluído, o lote será atualizado com o status 2 – Lote processado com sucesso – Todos os eventos processados com sucesso.

Figura 7

Lote processado com sucesso no TDF Messaging Framework

Na aba Batch Events, é possível ver que além dos eventos que foram enviados, também é possível ver os eventos retorno. No exemplo abaixo, foram enviados eventos R-4010 e seus respectivos R-9005.

Figura 8

Lista de eventos enviados e de retorno no TDF Messaging Framework

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