Skip to Content

Olá pessoal,

A fase 2018/02 parte 3 do eSocial foi liberada esta semana – confira o resumo das entregas na SAP Note 2589483.

Nesta fase, contemplamos um cenário específico dos eventos de tabela: quando uma exclusão de evento de tabela é aceita, se o evento que foi excluído estipulou uma data de fim de validade para outros eventos, a data de fim de validade desses outros eventos é zerada. A SAP Note 2588278 entrega este comportamento no controle de alterações do eSocial.

Este cenário inclusive parece com o cenário que descrevemos há algumas semanas em outro blog post. Mas vamos olhar um exemplo específico para este caso, para que você entenda em detalhes o comportamento do sistema.

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 eSocial: Gerador de eventos de tabelas (RPC_PAYBR_EFD_ER_GENERATOR) gera o evento correspondente com estas datas:

Início da validade Fim da validade Operação Status
Evento 1 01.01.2018 Inserção 3 Aceito

(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.05.2018
Entrada 2 01.06.2018 31.12.9999

O report RPC_PAYBR_EFD_ER_GENERATOR gera o evento correspondente com estas datas:

Início da validade Fim da validade Operação Status
Evento 1 01.01.2018 Inserção 3 Aceito
Evento 2 01.06.2018 Inserção 3 Aceito

A data de fim da validade do evento 1 não é atualizada – 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 A 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ê cria uma nova entrada na tabela A:

Início da validade Fim da validade
Entrada 1 01.01.1800 31.05.2018
Entrada 2 01.06.2018 31.03.2019
Entrada 3 01.04.2019 30.06.2019

E o report RPC_PAYBR_EFD_ER_GENERATOR gera estes eventos para a tabela A:

Início da validade Fim da validade Operação Status
Evento 1 01.01.2018 Inserção 3 Aceito
Evento 2 01.06.2018 Inserção 3 Aceito
Evento 3 01.04.2019 30.06.2019 Inserção 1 Pronto para enviar

Quando o evento 3 é aceito no ambiente do eSocial, os eventos da tabela A são atualizados da seguinte forma:

Início da validade Fim da validade Operação Status
Evento 1 01.01.2018 30.06.2019 Inserção 3 Aceito
Evento 2 01.06.2018 30.06.2019 Inserção 3 Aceito
Evento 3 01.04.2019 30.06.2019 Inserção 3 Aceito

Note que estas datas são para controle interno do SAP ERP HCM eSocial, e não para os eventos no ambiente nacional do eSocial.

Neste ponto, você exclui a entrada 3 da tabela A, assim:

Início da validade Fim da validade
Entrada 1 01.01.1800 31.05.2018
Entrada 2 01.06.2018 31.12.9999

O evento 4 é gerado como exclusão do evento 3, e aceito. A lista de eventos da tabela A, então, passa a ser a seguinte:

Início da validade Fim da validade Operação Status
Evento 1 01.01.2018 Inserção 3 Aceito
Evento 2 01.06.2018 Inserção 3 Aceito
Evento 3 01.04.2019 30.06.2019 Inserção 6 Obsoleto
Evento 4 01.04.2019 30.06.2019 Exclusão 3 Aceito

Neste caso, o fim da validade dos eventos 1 e 2 não é mais definido, e sim restaurado, como se o evento 3 nunca tivesse sido gerado.

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,

Alice

—-

Hi everyone,

Phase 2018/02 part 3 of eSocial was released this week – check out the delivery overview on SAP Note 2589483.

On this phase, we have addressed a specific scenario for table events: when you accept a deletion table event, in case the event that was deleted has set the end date to other events, these other events are restored. SAP Note 2588278 delivers this behavior on the eSocial change manager.

This scenario is actually like the one we described a few weeks ago, in another blog post. But let’s have a look at a specific example for this case, so that you can understand the system behavior in detail.

You have the following information on table A:

Start date End date
Entry 1 01.01.1800 31.12.9999

And you have the following event for table A:

Start date End date Operation Status
Event 1 01.01.2018 Insertion 3 Accepted

(We consider 01.01.2018 as the start date of eSocial table events.)

Then, you create a new entry in table A, changing the information as follows:

Start date End date
Entry 1 01.01.1800 31.05.2018
Entry 2 01.06.2018 31.12.9999

Your events for table A are now the following:

Start date End date Operation Status
Event 1 01.01.2018 Insertion 3 Accepted
Event 2 01.06.2018 Insertion 3 Accepted

In this case, event 1 is not updated with the end date, which means that two events are valid in the system for table A.

Besides, when you set an end date in table A, the corresponding event has an end date, and, as soon as this event is accepted by the government, all the events will have the end date set. For example, a new entry is created in table A, changing the information as follows:

Start date End date
Entry 1 01.01.1800 31.05.2018
Entry 2 01.06.2018 31.03.2019
Entry 3 01.04.2019 30.06.2019

So, you have the following events for table A:

Start date End date Operation Status
Event 1 01.01.2018 Insertion 3 Accepted
Event 2 01.06.2018 Insertion 3 Accepted
Event 3 01.04.2019 30.06.2019 Insertion 1 Ready to send

When event 3 is accepted, events for table A will be updated as follows:

Start date End date Operation Status
Event 1 01.01.2018 30.06.2019 Insertion 3 Accepted
Event 2 01.06.2018 30.06.2019 Insertion 3 Accepted
Event 3 01.04.2019 30.06.2019 Insertion 3 Accepted

Note that these dates are for internal control of SAP ERP HCM eSocial, not for events in the eSocial national environment.

Then you delete the third entry of the table as follows:

Start date End date
Entry 1 01.01.1800 31.05.2018
Entry 2 01.06.2018 31.12.9999

A fourth event is generated as deletion of event 3, and it is accepted. The list of events for table A then is the following:

Start date End date Operation Status
Event 1 01.01.2018 Insertion 3 Accepted
Event 2 01.06.2018 Insertion 3 Accepted
Event 3 01.04.2019 30.06.2019 Insertion 6 Obsolete
Event 4 01.04.2019 30.06.2019 Deletion 3 Accepted

In this case, the end date of events 1 and 2 is no longer defined, but it is restored, as if event 3 had never existed.

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,

Alice

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply