Skip to Content

Olá pessoal,

Há alguns dias, liberamos a parte 1 da fase 2018/01 do eSocial. Uma das SAP Notes desta fase, 2569972, se refere ao gerenciamento de alterações (change manager) para os eventos de tabela.

Com esta entrega, o report eSocial: Gerador de eventos do empregador e de tabelas (RPC_PAYBR_EFD_ER_GENERATOR) considera praticamente todos os eventos de tabelas do eSocial com a data de fim da validade igual a 31.12.9999, fazendo com que o campo fimValid não apareça no arquivo XML gerado para o evento.

Por que fizemos esta alteração? Conforme as validações do eSocial, os eventos com validade fechada são rejeitados caso haja informações relacionadas em datas posteriores. A validade do evento até pode ser fechada, mas não pode haver dados relacionados em datas posteriores.

Para entender o comportamento do sistema depois que você aplicar a solução, vejamos um exemplo. Na tabela A, você tem as seguintes datas:

  Início da validade Fim da validade
Entrada 1 01.01.1800 31.12.9999

O report RPC_PAYBR_EFD_ER_GENERATOR gera o evento correspondente com estas datas:

  Início da validade Fim da validade
Evento 1 01.01.2018

(Aqui, consideramos 01.01.2018 como a data de início do eSocial para os eventos de tabela.)

Você altera a tabela A da seguinte maneira:

  Início da validade Fim da validade
Entrada 1 01.01.1800 31.12.2020
Entrada 2 01.01.2021 31.12.9999

O report RPC_PAYBR_EFD_ER_GENERATOR gera o evento correspondente com estas datas:

  Início da validade Fim da validade
Evento 2 01.01.2021

O evento 1 não foi gerado, porque o gerenciamento de alterações do eSocial identifica que ele seria igual ao evento que foi enviado anteriormente. O evento 1 também não foi atualizado com a data de fim da validade – isso quer dizer que há dois eventos válidos para a tabela A.

Além disso, quando você delimita o fim da validade na tabela com uma data fechada (diferente de 31.12.9999), o evento correspondente também fica com uma data de fim de validade. Assim que o evento correspondente é aceito no ambiente nacional do eSocial, todos os eventos relacionados passam a ser delimitados também. No nosso exemplo, você altera a tabela A novamente:

  Início da validade Fim da validade
Entrada 1 01.01.1800 31.12.2020
Entrada 2 01.01.2021 31.12.2025

E o report RPC_PAYBR_EFD_ER_GENERATOR gera estes eventos:

  Início da validade Fim da validade
Evento 2 01.01.2021 31.12.2025

Quando o evento 2 é aceito no ambiente do eSocial, o sistema delimita a validade dos eventos aceitos anteriormente. Então, os eventos no sistema ficam assim:

  Início da validade Fim da validade
Evento 1 01.01.2018 31.12.2025
Evento 2 01.01.2021 31.12.2025

Gostou desse post? Dê um Like e compartilhe o conteúdo com seus colegas.

Fique à vontade para deixar um feedback, comentário ou pergunta no espaço abaixo. E não esqueça de seguir a tag HCM Payroll Brazil na SAP Community para ficar ligado nas últimas notícias sobre o eSocial.

Um abraço,

Leandro D’Avila

 


Hi everyone,

Just a few days ago, we have released part 1 of eSocial phase 2018/01. One of the SAP Notes for this phase, 2569972, refers to change manager for table events.

With this delivery, the Generate Employer and Table Events (RPC_PAYBR_EFD_ER_GENERATOR) report considers practically all table events with end date 31.12.9999, which causes the fimValid field not to appear in the XML file generated for the event.

Why did we make this change? According to eSocial validations, events with start and end date are rejected if there is related information on later dates. The event may have start and end dates, but there can’t be related information on later dates.

To better understand the way that the system works after you implement the solution, let’s see an example. On table A, you have the following dates:

  Start date End date
Entry 1 01.01.1800 31.12.9999

Report RPC_PAYBR_EFD_ER_GENERATOR generates the corresponding event with these dates:

  Start date End date
Event 1 01.01.2018

(Here, we consider 01.01.2018 as the eSocial start date for table events.)

You change table A as follows:

  Start date End date
Entry 1 01.01.1800 31.12.2020
Entry 2 01.01.2021 31.12.9999

Report RPC_PAYBR_EFD_ER_GENERATOR generates the corresponding event with these dates:

  Start date End date
Event 2 01.01.2021

Event 1 was not generated because the eSocial change manager detects that it would be the same event that was already sent previously. Event 1 was also not updated with the end date – this means that there are two valid events for table A.

Besides, when you delimit a table entry with an end date different than 31.12.9999, the corresponding event also has an end date. As soon as the corresponding event is accepted on the eSocial national environment, all related events are delimited, too. Back to our example, you change table A again:

  Start date End date
Entry 1 01.01.1800 31.12.2020
Entry 2 01.01.2021 31.12.2025

And report RPC_PAYBR_EFD_ER_GENERATOR generates the following events:

  Start date End date
Event 2 01.01.2021 31.12.2025

When event 2 is accepted on the eSocial national environment, the system delimits the validity of the events that were previously accepted. So, the events in the system are now like this:

  Start date End date
Event 1 01.01.2018 31.12.2025
Event 2 01.01.2021 31.12.2025

Did you enjoy this post? Choose “Like” and share the content with your colleagues.

Feel free to leave your feedback, comment or question in the space provided below. And don’t forget to follow the tag HCM Payroll Brazil in SAP Community to stay tuned on eSocial latest news.

All the best,

Leandro D’Avila

To report this post you need to login first.

1 Comment

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

  1. Manter Accenture

    Leandro, bom dia

    Fiquei na dúvida como o Governo irá aceitar dois eventos válidos, e a regra do manual Regra_tabgeral_alteracao_periodo_conflitante  ?

    Início da validade Fim da validade
    Evento 1 01.01.2018 31.12.2025
    Evento 2 01.01.2021 31.12.2025

    Obrigado

    Mauro Silva

     

    (0) 

Leave a Reply