Item 16.1 do Manual do eSocial - Considerações sobre o tratamento da extemporaneidade dos eventos no eSocial

16.1. Considerações sobre o tratamento da extemporaneidade dos eventos no eSocial:

16.1.1. Coerência lógica de encadeamento de eventos não periódicos.:

A recepção dos eventos extemporâneos observa uma validação de coerência de encadeamento de eventos e não de legalidade.

Ou seja, o envio de um evento extemporâneo que potencialmente torne os eventos posteriores ilegais, não é rejeitado, desde que mantenha a coerência fática de encadeamento dos eventos.

Por exemplo: um empregador envia uma alteração contratual com aumento salarial para um empregado já demitido com data de ocorrência anterior ao desligamento. Esta alteração potencialmente torna inconsistentes os valores previamente lançados no evento de desligamento, contudo, tal fato não traz qualquer incompatibilidade lógica entre os eventos e, por isso, ele é recepcionado.

Exemplo de envio extemporâneo de evento que é rejeitado por contrariar a coerência de encadeamento sequencial de eventos: retificação de data de admissão de um trabalhador para data posterior à data de início de um afastamento deste mesmo empregado.

16.1.2. Preservação da integridade referencial:

Integridade referencial é um conceito que garante que todos os inter-relacionamentos entre eventos propostos no sistema sejam respeitados, dando a certeza que as informações referenciadas em um evento permanecem válidas.

Por exemplo: o evento da admissão de um empregado faz referência a um determinado estabelecimento do declarante (S-1005). Quando o evento de admissão é enviado, o sistema verifica se a data de admissão está compreendida no período de validade daquele estabelecimento, caso contrário, o evento é recusado.

Se o evento extemporâneo de retificação alterar a data de admissão do trabalhador para uma data fora do período de validade do estabelecimento, a integridade referencial resta violada e o evento recusado. O sistema realiza uma espécie de simulação de recepção dos eventos antes de sua efetiva acolhida e recusa aqueles que quebram a integridade relacional de quaisquer outros eventos.

16.1.3. Reaplicação das regras de envio de remuneração e de fechamento da folha:

Quando um evento não periódico extemporâneo atende à regra de compatibilidade com os demais eventos não periódicos para determinado trabalhador, o sistema ainda avalia a compatibilidade desse evento com os eventos periódicos existentes para aquele período afetado da seguinte forma:

1. Quando a ação extemporânea reduz ou exclui o período ativo de algum trabalhador no RET (exemplo: exclusão de admissão, ou retificação de data de admissão para dia posterior à data original ou retificação de data de desligamento para data anterior a data original):

Nesse caso, o eSocial reexecuta, para o(s) período(s) de apuração reduzido(s) do contrato, as regras que exigem que o trabalhador esteja ativo para o recebimento de um evento periódico (REGRA_REMUN_JA_EXISTE_ DESLIGAMENTO e REGRA_REMUN_TRAB_EXISTENTE_RET). Caso a ação extemporânea pretendida faça com que um evento periódico de algum movimento afetado deixe de atender a essas regras o evento é recusado. Não é necessário que a(s) folha(s) de pagamento do(s) período(s) afetado(s) esteja(m) fechada(s) para a aplicação dessas regras.

Exemplo: um empregado havia sido admitido em 01/01/2020 e tinha informação de remuneração em 01/2020 e 02/2020. O declarante, envia um evento de retificação da admissão desse trabalhador modificando a data de admissão para 01/02/2020. Nesse caso, o período de apuração reduzido do contrato foi 01/2020, portanto, o eSocial reexecuta para este mês as regras de recepção de remuneração. Como havia sido enviada remuneração em 01/2020 que ficou inconsistente com a ação pretendida, esse evento é recusado.

2. Quando a ação extemporânea cria ou amplia o período ativo de algum trabalhador no RET (exemplo: envio de admissão com data retroativa, retificação de data de admissão para dia anterior à data original ou exclusão de evento de desligamento):

Nesse caso o eSocial reexecuta, para o(s) período(s) de apuração criado(s) ou ampliado(s) do contrato, a regra de fechamento da folha que exige a informação de remuneração para todos os vínculos ativos (REGRA_VALIDA_FECHAMENTO_ FOPAG). Caso a ação extemporânea pretendida implique alguma violação a essa regra o evento não é recusado, é gerado apenas uma advertência na recepção do evento indicando quais períodos de apuração restaram inconsistentes com aquela ação. É necessário que a(s) folha(s) de pagamento do(s) período(s) afetado(s) esteja(m) fechada(s) para a aplicação dessa regra. Caso as folhas do período estejam abertas, o evento é recebido sem nenhum problema.

Exemplo 1: um empregado havia sido admitido em 01/01/2020, tinha informação de remuneração em 01/2020 e desligamento datado de 10/02/2020. O empregador havia fechado as folhas de 03/2020 e 04/2020 sem informação de remuneração para esse trabalhador, uma vez que ele não estava ativo no RET. O declarante envia, em 04/2020, um evento de exclusão do desligamento desse trabalhador. Nesse caso, os períodos de apuração ampliados do contrato foram 03/2020 e 04/2020 cujas folhas estavam fechadas, portanto, o eSocial reexecuta para estes meses as regras de fechamento da folha. Como nessas competências não havia informação de remuneração desse trabalhador, o evento de exclusão é recepcionado, mas o declarante recebe uma advertência informando a inconsistência gerada nas folhas de 03/2020 e 04/2020.

Exemplo 2: um declarante informou remuneração para seus 10 trabalhadores referente a 01/2020, 02/2020 e 03/2020 e fechou a folha de todas essas competências. Em 04/2020 envia a admissão de outro empregado, retroativa a 15/01/2020. Nesse caso, os períodos de apuração ampliados do contrato foram 01/2020, 02/2020, 03/2020 e 04/2020. O eSocial reexecuta para o período com folha encerrada (janeiro a março) as regras de fechamento da folha. Como nessas competências não havia informação de remuneração desse trabalhador, o evento de admissão retroativa é recepcionado pelo eSocial, mas o declarante recebe uma advertência informando a inconsistência gerada nas folhas de 01/2020 a 03/2020. Nessa situação, para que não fosse gerado nenhuma advertência, bastaria que o declarante reabrisse as folhas do período antes do envio da admissão.

16.1.4. Inalterabilidade de cálculos dos totalizadores após recepção dos eventos:

Os eventos totalizadores por trabalhador (S-5001, S-5002 e S-5003) são devolvidos na medida em que o declarante envia os eventos de remuneração e pagamento dos trabalhadores.

A alteração extemporânea de qualquer item de tabela que afete o cálculo desses totalizadores é recepcionada pelo sistema, contudo os cálculos já efetuados e devolvidos ao declarante através dos totalizadores não são sensibilizados.

Por exemplo: empregador envia as remunerações e pagamentos efetuados a 300 de seus 1.000 empregados. Depois disto, retira a incidência de Contribuição Previdenciária da rubrica de "salário base" a partir da competência atual e envia a remuneração dos outros 700 empregados. Nesse caso, apenas o salário base dos 300 empregados para os quais ele já havia enviado remuneração, tem incidência de Contribuição Previdenciária. Para os demais, os cálculos levam em conta o atributo alterado da tabela de rubricas.

Para que a alteração tenha efeito para todos os empregados, o empregador deve excluir a remuneração dos 300 inicialmente enviados antes de fazer a alteração da incidência da referida rubrica (ou retificá-las após essa alteração).

Cumpre ressaltar que como os cálculos dos eventos S-5011 e S-5013 levam em conta os dados das tabelas do empregador no momento da recepção dos eventos remuneratórios, esses totalizadores restam inconsistentes caso não seja feita a retificação dos eventos de remuneração enviados antes da alteração dos parâmetros da tabela.

Por exemplo: empregador envia remuneração de 20 empregados e recebe os eventos S-5001 e S-5003. Após isso, envia o evento S-1000 alterando sua classificação tributária, mudando do código 01 (Empresa do simples com tributação previdenciária substituída) para 02 (Empresa do simples com tributação previdenciária não substituída). Em seguida, envia o evento de fechamento de folha. O cálculo constante no evento totalizador S-5011 recebido leva em conta o código 01, apesar da modificação efetuada, porque era o parâmetro vigente na época da recepção dos eventos remuneratórios. Para que a alteração da classificação tributária tenha efeito no totalizador, é necessário o reenvio dos eventos remuneratórios dos 20 empregados e de um novo evento de fechamento.

Com relação à necessidade de alteração de CNAE e código FPAS anteriormente informado, após o fechamento dos eventos periódicos, o tratamento deve ser o seguinte:

Se a necessidade de alteração é relativa ao CNAE informado no evento S-1005, basta que seja reenviado o evento S-1005 com a informação correta do CNAE e, após, deve ser enviado o evento S-1298 e, em seguida, um novo evento S-1299. Não há necessidade de verificação dos eventos periódicos.

Por exemplo: uma empresa tem matriz e uma filial. No S-1005 da filial foi informado o CNAE preponderante considerando a atividade principal que consta no CNPJ, quando deveria ser o da atividade que utiliza a maior quantidade de empregados. Após envio de todos os eventos S-1200 e do S-1299 verifica no totalizador que foi calculada o GILRAT errado. Nesse caso, deve ser reenviado o evento S-1005 com o CNAE correto e, em seguida, os eventos S-1298 e um novo evento S-1299.

Se a necessidade é relativa à criação de mais uma lotação tributária, deve ser enviado um novo evento S-1020, criando uma lotação tributária. Após, deve ser enviado o evento S-1298 e retificados todos os eventos S-1200/S-2299/S-2399 em que há necessidade de alteração da lotação tributária e, em seguida, deve ser enviado outro evento S-1299. Só com esse procedimento é que os cálculos dos totalizadores são refeitos.

Por exemplo: uma empresa do ramo do comércio tem matriz em Natal e uma filial em Recife. Em Recife, há convênio para recolher SESC e SENAC diretamente. No entanto, foi criada apenas uma lotação tributária do tipo 01. Após envio de todos os eventos S-1200 e do S-1299 verifica no totalizador que foi calculado SESC e SENAC relativo aos empregados da filial Recife. Para que seja corrigida a situação, deve ser enviado um novo S-1020 com o código de terceiros 0067. Em seguida, deve ser enviado o evento S-1298 e retificar os S-1200 dos empregados de Recife (passando a constar a nova lotação tributária criada). Após, deve ser enviado um novo evento S-1299. No S-5011 não vai mais constar os valores de SESC e SENAC relativos aos empregados de Recife.

16.1.5. Avaliação individual dos eventos extemporâneos:

A avaliação para recepção dos eventos extemporâneos é feita de forma individual. Portanto, caso o início e fim de um afastamento tiverem sido enviados no mesmo evento, esse, via de regra, pode ser excluído extemporaneamente.

Caso o início e o término de um afastamento tenham sido enviados em eventos separados, a exclusão de um desses eventos, via de regra, é recusada. Isto porque, ao tentar enviar o evento de exclusão do início do afastamento, o sistema não aceitaria pela existência de um evento posterior de retorno de afastamento incongruente com o encadeamento lógico dos eventos, já que não pode haver retorno de afastamento sem início. E, por sua vez, a exclusão do fim do afastamento só é aceita se não houver nenhum outro evento posterior incompatível com de afastamento do empregado (exemplo: outro afastamento, desligamento, aviso prévio...).

16.1.6. Limitação de efeitos dos eventos de alteração cadastral e alteração contratual:

Os eventos de alteração cadastral e contratual (S-2205 e S-2206, respectivamente) enviados extemporaneamente são sempre aceitos (desde que posteriores à admissão do trabalhador), dada a sua compatibilidade com os demais eventos, ou seja, esses eventos não geram qualquer incongruência de encadeamento. Contudo, uma alteração contratual/cadastral extemporânea só tem efeito até a próxima alteração do mesmo tipo.

Por exemplo:

Empregador envia a admissão de um trabalhador com cargo de vendedor em 01/01/2017 com salário de R$ 2.000,00.

Em 01/03/2017 envia uma alteração contratual aumentando o salário para R$ 2.200,00.

Em 01/06/2017 envia uma outra alteração contratual aumentando o salário para R$ 2.500,00.

Em 09/2017 envia um evento extemporâneo de alteração contratual, com data de alteração em 01/02/2017, alterando o cargo desse empregado de Vendedor para Gerente.

Este evento extemporâneo é aceito com sucesso, contudo, a alteração de cargo produz efeitos apenas até a alteração contratual seguinte, em 01/03/2017, já que, ao enviar a alteração contratual de salário, o evento reenvia todas as informações de contrato do trabalhador, inclusive do cargo, que era, à época de "vendedor".

Portanto, nesse caso, se o empregador quiser alterar o cargo do empregado a partir de 02/2017, deve efetuar a retificação em todas as subsequentes alterações contratuais para aquele empregado.

16.1.7. Envio de eventos com data de ocorrência situada em período de versão anterior do leiaute:

O que determina a versão do leiaute a ser utilizada pelo usuário é sempre a data do envio do evento e não a data da ocorrência do fato a que ele se refere. Ou seja, caso seja enviado em 05/2019 um evento de admissão ocorrida em 06/2018, a versão do leiaute a ser utilizada é a 2.5, vigente em 05/2019, e não a versão 2.4.02, vigente em 06/2018.

Cabe destacar alguns pontos:

- Quando há implementação de nova versão do leiaute é definido um período de convivência de versões (com duração variável em função da extensão das modificações) e, neste período, é permitido o envio dos eventos em qualquer uma das versões, tanto na versão nova quanto na que está sendo substituída (para maiores informações, consultar o item 21.1 do Capítulo I deste Manual), salvo quando a nova versão contém novos campos necessários à elaboração de cálculos. Nesse caso, para que os cálculos considerem a nova informação, o declarante tem de utilizar a nova versão.

- Quando campos obrigatórios são criados em determinada versão do leiaute com exigência de informações que não eram exigidas na versão anterior, a validação do campo criado deve definir um marco temporal a partir do qual essa informação passa a ser obrigatória, para evitar que a retificação ou o envio extemporâneo de evento referente ao passado obrigue o usuário à prestação de uma informação que não era exigível à época e que ele pode não possuir.

Segue exemplo deste tipo de validação, retirada do evento S-2200.

16.1.7.1. Envio extemporâneo de evento cadastral com data de ocorrência anterior à mudança de nome do trabalhador.:

Para a recepção de evento cadastral (S-2200, S-2300 e S-2205) o sistema faz validação das informações do CPF, nome e data de nascimento do trabalhador na base cadastral da Receita Federal do Brasil, contudo, é importante esclarecer que esta validação tem como base a data de envio do evento e não a data de sua ocorrência. Exemplo: Uma empregada foi admitida em 01/05/2018 com nome: Julia Santos. Na data de sua admissão o sistema validou o nome no CPF e, somente após a sua confirmação, o evento foi aceito. Em 01/11/2018 essa empregada se casou e incluiu o sobrenome do marido. Diante disso foi enviado um evento S-2205 para atualização cadastral de seu estado civil e nome. O evento foi aceito após confirmação na base do CPF, onde seu nome já havia sido atualizado para Julia Santos Matos. Em 12/2018 o empregador percebeu que deveria ter lançado, em 07/2018, uma atualização de endereço da empregada, através de um evento de alteração cadastral (S-2205). Apesar de a empregada utilizar seu nome de solteira naquela data, o evento deve ser enviado com seu nome atual, porque o sistema faz a integração com o cadastro CPF tendo como base a data de envio do evento extemporâneo.