(Scroll down for the English version.)
Olá pessoal,
Temos recebido casos de clientes que executam cálculos retroativos de folhas por motivo de dissídio combinado com algum outro motivo, mas o comportamento do sistema é diferente do esperado, mesmo que o cliente tenha criado as entradas corretamente na visão
Dissídio (V_T7BRDISSIDIO). Você já passou por esta situação? Então, o post de hoje é para você.
Como o problema se dá no sistema
Vamos explicar o problema por meio de um exemplo. Na folha de 08/2018, você tem o seguinte:
- Cálculo retroativo por motivo de dissídio válido a partir de 06/2018
- Pagamento de diferenças de horas extras de 05/2018
Você identificou a folha de pagamento com dissídio na atividade de customizing
Cálculo das folhas de pagamento -> Cálc.folha pagamento Brasil -> eSocial -> Dados de folha -> Inserir dados de dissídio (visão V_T7BRDISSIDIO).
O comportamento esperado é que a folha de 05/2018 seja aberta e retificada, e que o sistema trate as folhas 06/2018 e 07/2018 como cálculo retroativo por motivo de dissídio.
No entanto, o comportamento do sistema é tratar todos os motivos de cálculo retroativo como dissídio de forma errada, inclusive a folha de 05/2018, apesar de que as entradas na visão V_T7BRDISSIDIO terem a validade de 06/2018 a 08/2018.
Como tratar este cenário
Para que o sistema tenha o comportamento esperado, você deve seguir estes passos:
- Escolha em qual ordem deseja corrigir as folhas calculadas retroativamente. No nosso exemplo, corrigiremos primeiro a folha de pagamento de diferenças de horas extras, e depois corrigiremos o dissídio.
- Exclua a folha calculada de forma errada - no nosso exemplo, é a folha de 08/2018, que inclui os períodos retroativamente calculados desde 05/2018. Se desejar, crie uma entrada no infotipo Cálculo retroativo (0262) com um motivo diferente do padrão para o período 08/2018.
- Desfaça as alterações em dados mestre referentes ao cálculo retroativo por motivo de dissídio válido a partir de 06/2018.
- Execute a folha do período 08/2018. Como você vai executar esta folha também no passo 6, escolha se esta é uma folha regular ou uma folha off-cycle de ajuste. Do contrário, haverá duas folhas iguais, e o sistema sobrescreverá esta folha com a do passo 6.
- Refaça as alterações em dados mestre referentes ao cálculo retroativo por motivo de dissídio válido a partir de 06/2018. Não deixe de criar uma entrada no infotipo 0262 com o seu motivo de dissídio para o período 08/2018.
- Execute a folha do período 08/2018. Como você já executou esta folha no passo 4, escolha se esta é uma folha regular ou uma folha off-cycle de ajuste. Do contrário, haverá duas folhas iguais, e o sistema sobrescreverá a folha do passo 4 com esta.
- Gere o evento no report eSocial: Gerador de eventos de folha/periódicos (RPC_PAYBR_EFD_PAY_GENERATOR, transação PC00_M37_EFD_PAY_GEN).
Note bem as observações dos passos 4 e 6! Ao escolher qual dos motivos de cálculo retroativo é executado em uma folha regular e qual é executado em uma folha off-cycle de ajuste, você evita que as folhas sejam iguais e, portanto, nenhuma folha sobrescreve a outra.
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,
We have received cases for customers who run retroactive accounting due to collective bargaining combined with other retroactive calculation reasons, but the system behavior is different than expected, even if the customer has created the correct entries in the
Dissídio (V_T7BRDISSIDIO) view. Did you face this situation? So, then today’s post is for you.
How the problem happens in the system
Let’s explain the issue with an example. On the 08/2018 payroll, you have the following:
- Retroactive accounting due to collective bargaining as of 06/2018
- Payment of overtime differences from 05/2018
You have identified payroll with collective bargaining in the Customizing activity
Payroll -> Payroll Brazil -> eSocial -> Payroll data -> Insert bargaining data (view V_T7BRDISSIDIO).
The expected behavior is that the 05/2018 payroll is opened and rectified, and that the system handles the 06/2018 and 07/2018 payroll runs as retroactive accounting due to collective bargaining.
However, the system behavior is to incorrectly handle all retroactive accounting reasons as collective bargaining, including the payroll run for 05/2018, although the entries in the V_T7BRDISSIDIO view have the validity from 06/2018 to 08/2018.
How to handle this scenario
To ensure that the system has the expected behavior, you must follow these steps:
- Choose in which order you want to correct the retroactively calculated payroll runs. In our example, first we will correct the payroll for overtime differences, and then correct the collective bargaining.
- Delete the incorrectly calculated payroll run - in our example, this is the payroll for 08/2018, which includes retroactively calculated periods since 05/2018. If you want, create an entry in the Retroactive accounting (0262) infotype with a reason other than the standard reason for period 08/2018.
- Undo the master data changes related to the retroactive accounting due to collective bargaining valid as of 06/2018.
- Run the payroll period 08/2018. Because you will run this payroll also on step 6, choose whether this is a regular payroll run or an adjustment off-cycle run. Otherwise, there will be two equal payroll runs, and the system will overwrite this payroll run with the one on step 6.
- Redo the master data changes related to the retroactive accounting due to collective bargaining valid as of 06/2018. Don’t forget to create an entry in infotype 0262 with your collective bargaining reason for period 08/2018.
- Run the payroll period 08/2018. Because you have run this payroll in step 4, choose whether this is a regular payroll run or an adjustment off-cycle run. Otherwise, there will be two equal payroll runs, and the system will overwrite the payroll run of step 4 with this one.
- Generate the event in the report eSocial: Payroll event generator/periodic (RPC_PAYBR_EFD_PAY_GENERATOR, transaction PC00_M37_EFD_PAY_GEN).
Pay attention to the notes of steps 4 and 6! By choosing which of the retroactive accounting reasons is a regular payroll run and which is an adjustment off-cycle run, you avoid payroll runs from being equal and, therefore no payroll runs overwrite other ones.
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
