manual eSocial 1 0

tabela de rubricas, o declarante deve utilizar o grupo 
[inclusão]; 
34 
 
b) Para o declarante modificar o atributo incidência da contribuição previdenciária da rubrica 
001, a partir de 2016.01, foi utilizado o grupo [inclusão], com a nova ocorrência da rubrica 001; 
c) Para alterar o atributo incidência de FGTS da rubrica 003, que estava incorreto desde o início 
da validade, o declarante deve utilizar o grupo [alteração], informando a chave e alterando o atributo. 
Esta alteração vale para todo o período de validade informado na chave; 
d) Para modificar a validade da rubrica 002, que foi informada incorretamente, o declarante deve 
utilizar o subgrupo [novaValidade], do grupo [alteração]. Desta forma, o declarante está mantendo os 
atributos e modificando a validade da ocorrência; 
e) Para informar o fim da validade da ocorrência da rubrica 003, sem incluir uma nova ocorrência, 
o declarante deve utilizar o subgrupo [novaValidade], do grupo [alteração]; 
f) Para excluir a rubrica 003, o declarante deve utilizar o grupo [exclusão]. 
Todas as tabelas S-1005 a S-1070 devem estar com início de validade maior ou igual à data de 
início da obrigatoriedade do eSocial para esse declarante ou, no caso de ele ter iniciado suas atividades 
posteriormente à obrigatoriedade de implantação do eSocial, a data de início de vigência do seu 
cadastro (S-1000). 
 
15. Alterações e retificações 
 
O procedimento de alteração das informações transmitidas ao eSocial ocorre somente nos 
eventos de tabelas e no evento S-1000, atreladas à respectiva vigência ou período de validade. 
Também é prevista a alteração por meio de eventos não periódicos específicos, constantes neste 
Manual. 
Todos os demais casos de necessidade de mudança das informações transmitidas são tratados 
pelo eSocial como procedimentos de retificação, ou mesmo de exclusão. Esta questão é tratada com 
detalhes nos itens específicos deste Manual. 
As alterações em eventos não periódicos, e principalmente em eventos de tabelas, podem trazer 
consequências nos cálculos e apurações de fechamento dos eventos periódicos. Assim sendo, é 
necessário rigoroso controle para que uma alteração não torne inconsistente um movimento de evento 
periódico já fechado para determinado período de apuração. Para cada evento, nas “Informações 
adicionais” dos Leiautes apresentados no capítulo III, o declarante encontra orientação quanto às 
repercussões de eventuais alterações. 
 
35 
 
15.1. Alterações de informações transmitidas em eventos não periódicos específicos 
 
Os eventos não periódicos, relacionados adiante, têm como função a modificação de 
informações relevantes para determinado vínculo do trabalhador, devendo ser utilizados nessas 
situações específicas: 
• S-2205 - Alteração de Dados Cadastrais do Trabalhador 
• S-2206 - Alteração de Contrato de Trabalho 
• S-2306 - Trabalhador Sem Vínculo de Emprego/Estatutário - Alteração Contratual 
Esses eventos retratam a modificação de uma condição cadastral ou contratual de um 
trabalhador, sem que se trate de uma correção, ou seja, aquela condição era válida até um 
determinado momento e sofreu modificação a partir daquela data. Por exemplo, um empregado 
exercia o cargo de vendedor até uma data e a partir de então foi promovido a gerente. Essa alteração 
é informada ao esocial por meio do envio do evento S-2206. 
As alterações das informações constantes no evento S-2240 (Condições Ambientais do Trabalho 
- Agentes Nocivos) devem ser realizadas por meio do envio desse mesmo evento com a nova 
informação, pois não há evento específico de alteração das informações constantes nesse evento. 
 
15.2. Retificações 
 
A correção de informações já transmitidas ao eSocial relativa a eventos periódicos e não 
periódicos é realizada por meio do envio do mesmo evento com o campo {IndRetif} preenchido com 
[2] e a informação do número do recibo no campo {nrRecibo} do evento que está sendo corrigido. 
O primeiro evento enviado com o campo indicação de retificação - {IndRetif} preenchido com [1] 
é recepcionado como original. No caso em que já houver um evento informado, e houver a tentativa 
de envio do mesmo evento como original, o eSocial devolve mensagem com alerta desta situação e o 
declarante deve verificar se: 
a) trata-se de duplicidade da informação – nesse caso, descartar o arquivo rejeitado, mantendo-
se o registro já enviado; 
b) trata-se de retificação de informação – deve enviar o evento que contempla a informação a 
ser retificada com o campo {indRetif} preenchido com [2], constando no campo {nrRecibo} o número 
do recibo do arquivo originalmente enviado a ser retificado. É importante destacar que o evento 
retificador sobrepõe o retificado. Portanto, todos os campos do evento devem ser preenchidos, 
36 
 
inclusive os que não estão sofrendo modificação. Cabe lembrar que os campos chave, que variam de 
evento a evento, devem ser preenchidos com a mesma informação constante no evento retificado. 
Se o evento S-1299 já foi enviado, encerrando o movimento para determinado período de 
apuração, em caso de qualquer retificação no grupo de eventos periódicos S-1200 a S-1270, para 
aquele período de apuração, exceto para o S-1210, o respectivo movimento deve ser reaberto 
utilizando-se o evento S-1298, possibilitando o envio de retificações. 
Em regra, somente é permitido retificar evento não periódico ou periódico com o mesmo 
{procEmi} do evento original, exceto: 
a) Evento enviado por WS-WebService pode ser retificado no Web Geral e vice-versa; 
b) Evento S-2230 relacionado a férias enviado por WS-WebService ou Web Geral pode ser 
retificado nos módulos Web Simplificados; e 
c) Evento enviado pelo aplicativo operacionalizado pela Junta Comercial pode ser retificado por 
WS-WebService, Web Geral ou nos módulos Web Simplificados (a possibilidade de envio pelo balcão 
único ainda não tem previsão para entrar em produção). 
Para as informações enviadas anteriormente à entrada em produção do eSocial, por meio de 
procedimentos que foram por ele substituídos, por exemplo, a GFIP, as eventuais retificações devem 
ser encaminhadas por meio do mesmo procedimento utilizado para encaminhar a informação original. 
Só devem ser enviadas ao eSocial as retificações de informações que originalmente foram 
encaminhadas por esse mesmo sistema. 
A retificação substitui integralmente o evento original, ou seja, o eSocial entende que aquela 
retificação passa a ser o evento original. Caso seja realizada a exclusão de um evento que foi retificado, 
o evento deixa de existir no eSocial. 
Ao excluir um evento retificador o evento retificado não volta a ser válido. 
 
16. Tratamento das inconsistências geradas pelo envio extemporâneo de eventos 
 
O evento é considerado extemporâneo quando for enviado fora da ordem normal de 
sequenciamento de eventos para um determinado trabalhador, ou seja, quando, independentemente 
de ter ou não se esgotado o prazo para o seu envio, outro evento, com data de ocorrência posterior 
àquele, já tenha sido recepcionado. O tratamento dos eventos extemporâneos observa a 
“REGRA_EVENTOS_EXTEMP” da tabela de regras do eSocial. 
 
37 
 
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