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
