A maior rede de estudos do Brasil

Grátis
265 pág.
manual eSocial 1 0

Pré-visualização | Página 15 de 50

pode enviar suas próprias tabelas, bem como todos os demais 
eventos periódicos e não periódicos. Suas informações, porém, são vinculadas ao ente federativo por 
meio da informação do CNPJ do EFR. 
Importante destacar alguns pontos que são fundamentais para entendimento do processo de 
transmissão descentralizada: 
a) mesmo a informação sendo prestada descentralizadamente pela unidade administrativa, ela 
é feita em nome do ente responsável e não em nome da unidade administrativa. Por exemplo, se a 
Secretaria de Finanças de uma determinada Unidade da Federação prestar suas informações de forma 
autônoma, ela o faz em nome do ente responsável e não em seu nome; 
b) o EFR só cumpre com suas obrigações após todas as suas unidades administrativas vinculadas 
prestarem suas informações; 
c) a CND da RFB só é disponibilizada para o EFR se esse tiver cumprido com suas obrigações, 
conforme descrito no item anterior. 
Quanto aos órgãos públicos da administração direta federal, esses devem enviar suas 
informações no CNPJ de cada órgão ou unidade administrativa - (14 dígitos). 
Se a opção for pelo envio centralizado, apenas um conjunto de tabelas pode ser utilizado para 
todas as informações. 
48 
 
Nesse Manual, há subdivisões do item “Informações adicionais” dentro de cada evento. 
Esclarecemos que as orientações que constam no item “Orgãos Públicos” são as que representam as 
especificidades dessa categoria de declarante, o que não afasta a necessidade de que sejam 
observadas as orientações constantes nos demais itens, inclusive em relação aos empregados 
celetistas, para o caso de contratação de trabalhadores nesse regime por órgãos públicos. 
 
21. Orientações Transitórias 
 
21.1. Orientações sobre o período de convivência de versões do leiaute no eSocial. 
 
 É importante ressaltar que, via de regra, o eSocial suporta uma única versão vigente do leiaute. 
 Porém, nos momentos de implantação de nova versão, é possível que os ambientes de Produção 
Restrita e Produção permitam a convivência de duas versões por um determinado período. O objetivo 
da convivência de versões é prover flexibilidade para os declarantes realizarem a migração da versão 
anterior para a nova. Esse período de convivência não é fixo, sendo que a sua definição depende do 
impacto e complexidade de cada nova versão. 
 Segue adiante o comportamento do eSocial convivendo com duas versões baseado em um 
exemplo de evolução de versão: 
 Condições: 
• Versão X em vigência. 
• Versão Y vigente a partir de 01/01/2019. 
• Prazo de convivência das versões X e Y: 2 meses. 
Comportamento até 31/12/2018: o eSocial aceita eventos somente na versão X. 
Comportamento de 01/01/2019 a 28/02/2019: o eSocial aceita eventos nas versões X e Y. 
Comportamento a partir de 01/03/2019: o eSocial aceita somente eventos na versão Y. 
As retificações, alterações e envio de eventos extemporâneos podem ser feitos nas duas versões. 
Um evento enviado em qualquer versão anterior à versão X pode ser retificado ou alterado nas versões 
X e Y. Não existe dependência com a data em que o evento original foi transmitido e validado. As 
versões vigentes determinam o processamento baseado na data de envio do evento. 
 Normalmente, o sistema do declarante está operacional na versão X e é todo migrado para a 
versão Y. Com isso, o declarante pode continuar enviando eventos na versão X até a data 28/02/2019. 
49 
 
 Caso o declarante opte por uma migração parcial para a versão Y, o eSocial aceita normalmente 
os eventos nas duas versões, durante o período de convivência. Por exemplo, uma admissão pode ser 
transmitida na versão X e a respectiva alteração contratual ou remuneração pode ser enviada na versão 
Y. 
 
21.1.1. Sobre o processamento de eventos extemporâneos 
 
Sobre o processamento de eventos extemporâneos, o comportamento padrão do eSocial, seja 
operando com versão única ou suportando a convivência de duas versões, é o seguinte: 
O evento extemporâneo é processado de acordo com as regras da versão em que foi enviado, 
em caso de convivência, versão X ou Y. 
• Os eventos que são revalidados, em virtude do envio extemporâneo, devem atender às 
regras da versão em que foram enviados à época. 
 
21.1.2. Sobre os módulos Web 
 
 Todos os módulos Web operam na versão mais recente do eSocial, como por exemplo, o WEB-
Geral, o do segurado especial e o do MEI. 
 
21.1.3. Período de convivência entre as versões 2.5 e S-1.0 
 
A regra geral é que durante o período de convivência entre as versões 2.5 e S-1.0 do eSocial, os 
eventos podem ser recebidos em uma dessas duas versões, sendo que num mesmo conjunto de 
eventos, alguns podem estar em uma versão e outros na outra. 
As regras de validação, aplicadas no processamento da recepção do evento, serão aquelas da 
versão em que o evento foi enviado. 
Serão permitidos eventos extemporâneos, de retificação e de exclusão (S-3000) em ambas as 
versões durante o período de convivência, e, após esse período, somente na versão S-1.0. 
A partir de 10/05/2021, as tabelas do eSocial vigentes - relacionadas no Anexo I do Leiaute - serão 
as da versão S-1.0, independentemente da versão do evento transmitido. 
Quanto ao período de convivência, existem regras específicas que precisam ser aplicadas: 
 
50 
 
 
Ref. Situação de convivência Convivência implementada 
1 Eventos remuneratórios (S-1200, S- 
2299 e S-2399) e evento de 
pagamento(S-1210) enviados em 
versões distintas. 
Se o evento de pagamento (S-1210) referenciar demonstrativos 
informados em eventos remuneratórios (S-1200, S-2299, S-2399) 
enviados em versão diferente da utilizada no S-1210 o totalizador 
S-5002 retornará “zerado” (no grupo infoIR, o campo 
{valor} retornará com ZERO). 
 
A alínea C da REGRA_EVENTOS_EXTEMP, reproduzida abaixo, só 
entrará em vigor após o término do período de convivência: 
c) A retificação ou exclusão extemporânea de evento 
remuneratório (S-1200/S-1202/S-1207/S-2299/S-2399) 
exigirá a exclusão prévia do correspondente evento S- 
1210, quando existente. 
 
JUSTIFICATIVA: a estrutura do S-1210 v.S-1.0 é incompatível com 
os cálculos retornados no S-5002 para eventos remuneratórios 
enviados na versão 2.5, e vice versa. 
OBS: O retorno do S-5002 “zerado” não compromete a apuração 
do IRRF, uma vez que tal apuração ainda não é efetuada pelo 
eSocial. Esta apuração é feita pela RFB, por meio da DCTF(PGD) e 
pela DIRF. 
2 Evento S-1299 enviado na versão 
2.5. 
A partir da implantação da versão S-1.0 (10/05/2021), quando o 
evento S-1299 for enviado na versão 2.5 (período de 
 convivência) o respectivo totalizador S-5012 será retornado 
“vazio” (o grupo infoCRContrib não será retornado). 
JUSTIFICATIVA: O evento S-5012 não existe na versão S-1.0, e não 
está sendo utilizado para apuração do IRRF no eSocial. Esta 
apuração é feita pela RFB, por meio da DCTF(PGD) e pela DIRF. 
3 Evento S-1250 não existe mais no 
eSocial a partir da implantação da 
versão S-1.0. 
O evento S-1250 (versão 2.5) poderá ser recebido com {perApur} 
igual ou anterior a 04/2021 e somente até o dia 20/05/2021. As 
informações contempladas no S-1250 passam a ser enviadas pelo 
evento R-2055 na EFD-Reinf. 
A partir de 21/05/2021, não serão permitidos o envio, a 
retificação e a exclusão de S-1250. 
 
JUSTIFICATIVA: O S-1250 não existe mais no eSocial a partir da 
implantação da versão S-1.0. O envio do S-1250 a partir de 
21/05/2021 não pode ser considerado “convivência de versões”, 
pois o evento R-2055 não integra o eSocial. 
51 
 
4 Tratamento das informações do 
evento S-1250, já enviadas na 
versão 2.5 do eSocial, com a 
respectiva apuração encaminhada 
para a DCTFweb. 
Será criado o campo opcional {indExcApur1250} no evento S- 
1299 (versões 2.5 e S-1.0), para indicar que as informações do 
evento S-1250 já transmitidas não devem ser utilizadas nos 
cálculos de fechamento de folha e envio para DCTF Web. Se este 
campo não for enviado, as

Crie agora seu perfil grátis para visualizar sem restrições.