Notícias Trabalhistas

Manual de Orientação do eSocial - INFORMAÇÕES GERAIS

CAPÍTULO I - INFORMAÇÕES GERAIS

(Manual de Orientação do eSocial - Versão S-1.0 Consol. até a NO S-1.0 - 08.2021)


Índice
  1. 1. Apresentação, conteúdo e princípios do eSocial
    1. 1.1. Simplificação do eSocial
  2. 2. Quem está obrigado ao eSocial
  3. 3. O eSocial x EFD-Reinf: sistemas complementares
  4. 4. Forma de substituição das informações da GFIP, outras declarações e formulários, pelas informações constantes do eSocial
    1. 4.1. Implementação progressiva do eSocial: “faseamento”
  5. 5. Ambientes do eSocial
  6. 6. Lógica do sistema e Recomendações
  7. 7. Identificadores
    1. 7.1. Declarantes
    2. 7.2. Trabalhadores
    3. 7.3. Qualificação cadastral
      1. 7.3.1.Validações do nome do trabalhador
      2. 7.3.2.Ferramenta “Consulta Qualificação Cadastral - CQC”
  8. 8. Modelo Operacional do eSocial
    1. 8.1. Descrição simplificada
    2. 8.2. Acesso ao eSocial
      1. 8.2.1. Certificação Digital
        1. 8.2.1.1. Utilização de Certificado Digital por prestadores de serviço de Contabilidade, Administração de Condomínios, Gestores de RH e SST
      2. 8.2.2. Código de acesso para o Portal eSocial
    3. 8.3. Transmissão dos arquivos - sequência lógica
    4. 8.4. Protocolo de envio e Recibo de entrega
    5. 8.5. Constituição de créditos e geração de guias de recolhimento
    6. 8.6. Diferença entre advertências e erros
  9. 9. Tabelas do eSocial
  10. 10. Eventos do eSocial
    1. 10.1. Tabelas do Empregador
    2. 10.2. Eventos Não Periódicos
    3. 10.3. Eventos Periódicos
      1. 10.3.1. Movimento e período de apuração para os eventos periódicos
      2. 10.3.2. Folha de Pagamento
      3. 10.3.3. Remuneração e Pagamento no eSocial
      4. 10.3.4. Orientações sobre a folha de 13º salário
        1. 10.3.4.1. Adiantamento integral do décimo terceiro salário antes do mês de dezembro
  11. 11. Registro de Eventos Trabalhistas – RET
    1. 11.1. Trabalhadores não incluídos no RET
  12. 12. Situação “Sem Movimento”
  13. 13. Indicação de requisitos para envio dos eventos
  14. 14. Datas
    1. 14.1. Preenchimento geral dos campos com data
    2. 14.2. Registro de data inicial do evento
    3. 14.3. Data-início-validade e Data-fim-validade nas Tabelas
  15. 15. Alterações e retificações
    1. 15.1. Alterações de informações transmitidas em eventos não periódicos específicos
  16. 16. Tratamento das inconsistências geradas pelo envio extemporâneo de eventos
    1. 16.1. Considerações sobre o tratamento da extemporaneidade dos eventos no eSocial
      1. 16.1.1. Coerência lógica de encadeamento de eventos não periódicos.
      2. 16.1.2. Preservação da integridade referencial
      3. 16.1.3. Reaplicação das regras de envio de remuneração e de fechamento da folha
      4. 16.1.4. Inalterabilidade de cálculos dos totalizadores após recepção dos eventos
      5. 16.1.5. Avaliação individual dos eventos extemporâneos
      6. 16.1.6. Limitação de efeitos dos eventos de alteração cadastral e alteração contratual
      7. 16.1.7. Envio de eventos com data de ocorrência situada em período de versão anterior do leiaute
        1. 16.1.7.1. Envio extemporâneo de evento cadastral com data de ocorrência anterior à mudança de nome do trabalhador.
  17. 17. Exclusão de eventos
  18. 18. Consulta das informações e download dos arquivos transmitidos
  19. 19. Informações Gerais Sobre os Eventos de Segurança e Saúde no Trabalho – SST
    1. 19.1. Eventos de SST no âmbito dos órgãos públicos
  20. 20. Órgãos Públicos
    1. 20.1 Cadastramento inicial de vínculos, beneficiários, benefícios e estágios
    2. 20.2 Prazo para envio de informações sobre vínculos, benefícios e estágios iniciados após o início da obrigatoriedade do envio dos eventos não periódicos e antes da obrigatoriedade do envio dos eventos periódicos
  21. 21. Orientações Transitórias
    1. 21.1. Orientações sobre o período de convivência de versões do leiaute no eSocial.
      1. 21.1.1. Sobre o processamento de eventos extemporâneos
      2. 21.1.2. Sobre os módulos Web
      3. 21.1.3. Período de convivência entre as versões 2.5 e S-1.0
  22. 22. Lista de siglas

1. Apresentação, conteúdo e princípios do eSocial

O eSocial é um projeto do governo federal, instituído pelo Decreto nº 8.373, de 11 de dezembro de  2014,  que  tem  por  objetivo  desenvolver  um  sistema  de coleta  de  informações  trabalhistas, previdenciárias e tributárias, armazenando-as em um Ambiente Nacional Virtual, a fim de possibilitar aos órgãos participantes do projeto, na medida da pertinência temática de cada um, a utilização de tais informações para fins trabalhistas, previdenciários, fiscais e para a apuração de tributos e da contribuição para o FGTS.

O eSocial estabelece a forma com que passam a ser prestadas as informações trabalhistas, previdenciárias, tributárias e fiscais relativas à contratação e utilização de mão de obra onerosa, com ou sem vínculo empregatício, e de produção rural. Portanto, não se trata de uma nova obrigação tributária acessória, mas uma nova forma de cumprir obrigações trabalhistas, previdenciárias e tributárias já existentes. Com isso, ele não altera as legislações específicas de cada área, mas apenas cria uma forma única e mais simplificada de atendê-las.

São princípios do eSocial:

  • Dar maior efetividade à fruição dos direitos fundamentais trabalhistas e previdenciários dos trabalhadores;
  • Racionalizar e simplificar o cumprimento de obrigações previstas na legislação pátria, relativa à cada matéria;
  • Eliminar a redundância nas informações prestadas pelas pessoas físicas e jurídicas obrigadas;
  • Aprimorar a qualidade das informações referentes às relações de trabalho, previdenciárias e fiscais; e
  • Conferir tratamento diferenciado às ME/EPP.

A prestação das informações pelo eSocial substitui, na forma disciplinada pelos órgãos e entes partícipes, o procedimento do envio das mesmas informações por meio de diversas declarações, formulários, termos e documentos relativos às relações de trabalho.

As informações referentes a períodos anteriores à implantação do eSocial devem ser enviadas pelos sistemas utilizados à época.

A recepção dos eventos pelo eSocial não significa o reconhecimento da legalidade dos fatos neles informados.

Os  arquivos  complementares  anexos  a  este  Manual,  bem  como  o  próprio  Manual, estão disponíveis no portal do eSocial, no sítio https://www.gov.br/esocial/.

1.1. Simplificação do eSocial

O eSocial passou por um amplo processo de simplificação, tendo ocorrido exclusão de eventos e de campos,  causando uma diminuição do volume de informações até então prestadas pelos declarantes. Além disso, houve flexibilização de várias regras de validação, diminuindo a quantidade de erros que impedem o recebimento de arquivos, transformando algumas inconsistências que gerariam a recusa do evento em simples advertências ao usuário. Por exemplo, a informação de remuneração relativa a todos os empregados ativos no RET era condição para o recebimento do evento de fechamento da folha e agora com a simplificação o evento é recebido com a geração de alerta ao declarante sobre os empregados com ausência de remuneração.

Mas é importante se frisar que o envio das informações seguindo o novo leiaute deve ocorrer apenas em relação aos fatos ocorridos a partir da data de entrada em produção da versão simplificada do eSocial. Além disso, há um período de convivência entre as versões antigas e a simplificada (ver item 21.1 deste capítulo).

As informações já enviadas seguindo a versão antiga não precisam ser reenviadas na versão simplificada. Ou seja, o eSocial simplificado aproveita todas as informações já recebidas pelo eSocial. Por exemplo: um empregador enviou um evento de admissão de um empregado em outubro de 2019. Neste evento, o cargo exercido pelo empregado foi informado mediante a referência a um dos códigos existentes na tabela de cargos. Já o horário contratual do empregado foi informado mediante a indicação do código relativo a um dos horários existentes na tabela de horários do empregador. Na versão simplificada do eSocial essas duas tabelas deixaram de existir e essas informações passaram a ser prestadas mediante utilização de campos textos dentro do próprio evento de admissão. Mas isso não significa que os declarantes têm de reenviar os eventos de admissão dos empregados. Apenas os empregados admitidos a partir da entrada em produção da versão do leiaute simplificada é que tem suas informações de cargo e horário contratual prestadas seguindo essa nova sistemática. Todavia, caso haja uma alteração contratual do empregado a que se refere o exemplo, após essa entrada em produção, deve ser enviado um evento S-2206 seguindo a versão simplificada, com os cargos e horário contratual informados mediante utilização de campos textos {nmCargo} e {dscJorn}, respectivamente. O mesmo procedimento deve ser adotado em caso de retificação.

2. Quem está obrigado ao eSocial

Todo aquele que contratar prestador de serviço pessoa física e possua alguma obrigação trabalhista, previdenciária ou tributária, em função dessa relação jurídica de trabalho, inclusive se tiver natureza administrativa, conforme a legislação pertinente, está obrigado a enviar informações decorrentes desse fato por meio do eSocial.

O obrigado pode figurar nessa relação como empregador, nos termos definidos pelo art. 2º da CLT ou como contribuinte, conforme delineado pela Lei nº 5.172, de 1966 (CTN), na qualidade de empresa, inclusive órgão público, ou de pessoa física equiparada a empresa, conforme prevê o art. 15 da Lei nº 8.212, de 1991.

Estão obrigados ainda os contribuintes que comercializam produção rural nas situações descritas no Capítulo III deste Manual.

Também devem enviar informações ao Ambiente Nacional do eSocial os contribuintes na situação “Sem Movimento” detalhada no item 12 do Capítulo I deste Manual. Excetuam-se dessa obrigação:

a) A pessoa física que, no início da obrigatoriedade do eSocial, encontra-se na situação “Sem Movimento”, enquanto essa situação perdurar;

b) O MEI sem empregado que não possua obrigação trabalhista, previdenciária ou tributária; e c)  Os Fundos de Investimento, os quais não são revestidos de personalidade jurídica e, portanto, não podem contratar. As informações devem ser prestadas pela instituição financeira administradora do fundo.

Doravante, nesse Manual, é utilizado o termo “declarante” para fazer referência a qualquer dos obrigados ao eSocial. Quando for utilizado a indicação específica de um dos obrigados ao eSocial, estar- se-á fazendo menção expressa a ele, por exemplo “empregador”, “órgão público”, “órgão gestor de mão de obra”.

3. O eSocial x EFD-Reinf: sistemas complementares

Por meio do Sistema Simplificado de Escrituração Digital das Obrigações Previdenciárias, Trabalhistas e Fiscais - eSocial os obrigados enviam as informações relativas às relações de trabalho, que no campo da tributação previdenciária, abrangem, como regra, as informações necessárias para a apuração das contribuições previdenciárias e das contribuições das outras entidades e fundos (Terceiros) incidentes sobre a folha de pagamento ou remunerações pagas, devidas ou creditadas aos trabalhadores contratados.

Os obrigados enviam, também, ao eSocial as informações relativas às retenções de imposto de renda incidente sobre rendimentos do trabalho, bem como a data do efetivo pagamento ao trabalhador.

No caso das informações necessárias para a apuração da retenção do art. 31 da Lei nº 8.212, de

1991, das contribuições previdenciárias substitutivas, incidentes, em regra, sobre a receita bruta, estas devem ser encaminhadas por meio da EFD-Reinf.

4. Forma de substituição das informações da GFIP, outras declarações e formulários, pelas informações constantes do eSocial

A substituição das informações que são prestadas aos órgãos e entes integrantes do Comitê Gestor do eSocial em outras declarações e formulários pelas informações do eSocial, definida no § 1º do art. 2º do Decreto nº 8.373, de 11 de dezembro de 2014, se dá com base na regulamentação de cada órgão ou ente, conforme competência legal para exigência dessas obrigações.

Cada órgão dá publicidade da substituição de suas obrigações por meio de ato normativo específico da autoridade competente, a ser expedido de acordo com a oportunidade e conveniência administrativa.

4.1. Implementação progressiva do eSocial: “faseamento”

Com o objetivo de garantir segurança e eficiência para a entrada em operação do eSocial foi definido que o início de envio de obrigações para cada grupo de obrigados deve ser feito em etapas, ou seja, definiu-se a implementação progressiva do eSocial (faseamento).

Este faseamento é dividido por grupos de obrigados e, dentro de cada grupo, por tipo de evento: na primeira fase devem ser enviados os eventos de tabela, na segunda os não periódicos, na terceira os eventos periódicos e na quarta fase os eventos de Segurança e Saúde no Trabalho. Cada período de obrigatoriedade de eventos, dividido por grupo de obrigados, é definido em legislação específica.

Cabe destacar a peculiaridade quanto aos eventos de Desligamento (S-2299) e de Término de Trabalhador Sem Vínculo de Emprego/Estatutário (S-2399) dada a sua natureza híbrida. Apesar de serem considerados eventos não periódicos, podem conter, também, informações de remuneração, característica própria dos eventos periódicos. Portanto, estes eventos, S-2299 e S-2399, devem ser enviados na segunda fase, com a obrigatoriedade dos eventos não periódicos, contudo, sem o grupo referente às informações de remuneração, até a data fixada para o envio dos eventos periódicos. Para tanto, foi incluída no leiaute a seguinte condição no grupo [verbasResc]: “não deve ser informado se:

{dtDeslig} ou  {dtTerm} for anterior ao início de obrigatoriedade dos eventos periódicos para o empregador”. Isto significa que, no período entre a obrigatoriedade dos eventos não periódicos e a obrigatoriedade dos eventos periódicos, e somente nesse período, os eventos S-2299 e S-2399, que deveriam ter informações de parcelas remuneratórias, devem ser enviados sem o grupo [verbasResc].

5. Ambientes do eSocial

Existem duas espécies de ambientes no eSocial, a saber:

a) Produção  –  Ambiente  destinado  para  processamento  e  apuração  das  informações  do declarante que produz todos os efeitos jurídicos.

b) Produção restrita – Ambiente de teste no qual as informações não produzem efeitos jurídicos.

6. Lógica do sistema e Recomendações

O eSocial foi concebido para transmitir informações agrupadas por meio de eventos, os quais devem ser encaminhados em uma sequência lógica, conforme toda a dinâmica das contratações dos trabalhadores, desde o seu início até o seu término, como a identificação do declarante e dos dados gerais das contratações realizadas por este, a admissão dos trabalhadores, os dados específicos da contratação dos trabalhadores, a gestão dos serviços prestados e do prestador de serviços, o pagamento da remuneração e o término da relação contratual.

Essa  sequência  a  ser observada conduz  ao  conceito de  “empilhamento”, de modo que as informações transmitidas em eventos podem ser usadas em eventos seguintes e para se alterar um dado de evento antigo há que se verificar as consequências/repercussões nos eventos posteriores. Havendo necessidade de envio de informação fora da sequência cronológica de encadeamento de eventos, devem ser observadas as regras para envio de eventos extemporâneos, descritas no item “16 Tratamento das inconsistências geradas pelo envio extemporâneo de eventos” do Capítulo I deste Manual.

Quando for preciso informar o código do município constante na tabela do IBGE e essa ainda não estiver atualizada em razão de desmembramento de município, o declarante deve, até que ela seja atualizada, utilizar  o código do município desmembrado. Nos demais casos em que o nome do município não conste na tabela de código do município do IBGE, o declarante deve verificar se não houve alteração na denominação do município, pois, nesse caso, deve usar o código da denominação anterior.

7. Identificadores

7.1. Declarantes

Os declarantes pessoa jurídica são identificados apenas pelo CNPJ e os declarantes pessoa física, apenas pelo CPF.

O identificador chave {nrInsc} para as pessoas jurídicas é o CNPJ-Raiz/Base de oito posições, exceto se a natureza jurídica for de administração pública federal, situação em que o campo deve ser preenchido com o CNPJ completo com 14 posições.

As pessoas físicas que exercem atividade econômica, ainda que possuam CNPJ, e que contratem segurados, devem utilizar o CAEPF (antiga matrícula CEI), como estabelecimento vinculado ao seu CPF. Nessa situação estão o contribuinte individual (Natureza jurídica 408-1), o produtor rural pessoa física (Natureza jurídica 412-0), o segurado especial (Natureza jurídica 402-2), o produtor rural pessoa física encarregado de contratar e gerir empregados de consórcios simplificados de empregadores rurais (Natureza jurídica 228-3) e o titular de cartório (Natureza jurídica 303-4).

Para as obras de construção civil, o declarante deve utilizar o CNO como estabelecimento ou lotação tributária, vinculados a um CNPJ ou a um CPF.

7.2. Trabalhadores

O termo “trabalhador” utilizado nesse Manual compreende toda pessoa física inserida em uma relação de trabalho, inclusive de natureza administrativa, como os empregados, os servidores públicos, os militares e os “trabalhadores sem vínculo de emprego ou estatutário – TSVE”.

Os trabalhadores têm como identificador obrigatório o CPF. Um CPF pode ter mais de um vínculo com um mesmo declarante, sendo cada vínculo identificado pelo número da matrícula.

7.3. Qualificação cadastral

Uma das premissas para o envio de informações e recolhimento das obrigações por meio do eSocial é a consistência dos dados cadastrais enviados pelo declarante relativos aos trabalhadores a seu serviço. Esses dados são validados na base do CPF (nome, data de nascimento e CPF) e qualquer divergência impossibilita o envio dos eventos S-2190, S-2200, S-2205, S-2300, S-2400 ou S-2405.

7.3.1.Validações do nome do trabalhador

O nome do trabalhador a ser utilizado deve ser o seu nome civil, mesmo que o nome social já tenha sido atualizado na base do CPF, considerando que quando da consulta cadastral, a validação do nome é realizada na base do CPF que retorna sempre o nome civil do trabalhador. Somente nas situações em que houver retificação/substituição judicial do nome civil é que o novo nome deve ser utilizado na consulta qualificação cadastral.

Para o preenchimento do “Nome” devem ser observadas as seguintes configurações:

  • formato alfanumérico sem acentuação;
  • não utilização de caracteres numéricos ou especiais (“, ', !, @, #, $,%, ¨, &, ?, ...);

As regras adotadas pelo eSocial para validação do nome do trabalhador são:

a)   Apenas o primeiro e o último nome são validados. Os intermediários não, exceto se o primeiro nome for “Maria”, “José”, “João” ou “Ana”, quando o nome imediatamente posterior é validado e se o último nome for “Filho”, “Neto”, “Bisneto”, “Trineto”, “Tetraneto”, “Sobrinho” ou “Junior”, quando o nome imediatamente anterior é validado.

b)  São aceitas trocas de letras nas seguintes situações:

  • no início do nome: de “i” para “y”; de “y” para “i”; de “v” para “w”; de “w” para “v”; de “th” para “t”; de “t” para “th”; de “k” para “c”; de “c” para “k”; de “ç” para “c”; é desconsiderada a consoante “h”;
  • no meio do nome: de “z” para “s”; de “s” para “z”; de “i” para “y”; de “y” para “i”; de “th” para “t”; de “t” para “th”; de “sc” para “c”; de “c” para “sc”; de “x” para “ss”; de “ss” para “x”; de “c” para “ss”; de “ss” para “c”; de “u” para “w”; de “w” para “u”; de “d” para “dh”; de “dh” para “d”; de “ph” para “f”; de “f” para “ph”;
  • no final do nome: de “m” para “n”; de “n” para “m”; de “th” para “te”; de “te” para “th”; de “e” para “i”; de “i” para “e”; de “i” para “y”; de “y” para “i”;

c)   Em caso de consoantes dobradas, são aceitos com uma ou duas consoantes;

d)   Não são considerados acentos e cedilha.

7.3.2.Ferramenta “Consulta Qualificação Cadastral - CQC”

Aos declarantes é oferecida uma ferramenta para identificar previamente possíveis divergências entre os dados de seus cadastros internos e aqueles constantes no CPF e no CNIS, a fim de garantir que os dados informados no eSocial são apropriados corretamente na base do CNIS, garantindo assim o reconhecimento do direito aos benefícios previdenciários e trabalhistas. Nesse sentido, sempre que o trabalhador possuir NIS, a CQC deve ser realizada com a informação do NIS.

Com a versão simplificada do eSocial, o NIS não mais será informado, portanto, possíveis inconsistências na base do PIS/PASEP/CNIS, não serão impeditivas para o envio dos eventos de admissão/cadastramento inicial.

A validação de consistência de dados cadastrais será feita exclusivamente na base do CPF. Apesar de o eSocial não utilizar mais o NIS – Número de Identificação Social, a qualificação cadastral continua sendo imprescindível para que os eventos enviados ao eSocial sejam apropriados corretamente pelo CNIS, sobretudo para identificação de inconsistências no cadastro referentes a trabalhadores que já possuíam vínculo anterior ao eSocial.

Ressaltamos a necessidade da consulta e saneamento dos dados cadastrais principalmente para os trabalhadores do serviço público. Pelo fato de a grande maioria destes trabalhadores não terem os seus beneficios concedidos pelo INSS, a possibilidade de existência de inconsistências cadastrais é muito grande.

Para os trabalhadores que ingressarem no mercado de trabalho após a dispensa do NIS no eSocial, a qualificação do cadastro deve ser feita apenas do CPF. Para atender a necessidade de consulta dos dados de trabalhadores e beneficiários que não possuem NIS, a Consulta Qualificação Cadastral - CQC foi adaptada para permitir a informação de um NIS padrão, a saber: 13333333332.

O NIS padrão pode ser utilizado tanto na consulta online quanto na consulta em lote.

Em um mesmo lote é possível inserir dados de trabalhadores com NIS real e com o NIS Padrão. Quando o NIS Padrão for informado, a validação dos dados cadastrais será realizada apenas na base do CPF

O leiaute da CQC encontra-se disponível no Portal eSocial, na aplicação de consulta, no seguinte endereço: https://www.gov.br/esocial/pt-br/empresas/consulta-qualificacao-cadastral.

8. Modelo Operacional do eSocial

8.1. Descrição simplificada

O declarante gera um arquivo eletrônico, no formato XML, contendo as informações previstas nos leiautes, assina-o digitalmente, transformando-o em um documento eletrônico nos termos da legislação, objetivando garantir a integridade dos dados e a autoria do emissor. Este arquivo eletrônico é transmitido pela Internet para o Ambiente Nacional do eSocial que, após verificar a integridade formal, emite o protocolo de envio e o envia ao declarante.

O eSocial não funciona por meio de um Programa offline Gerador de Declaração – PGD ou Validador e Assinador – PVA, ou seja, não possui um aplicativo para download no ambiente do declarante que importe o arquivo e faça as validações antes de transmitir.

O arquivo pode ser gerado e enviado por diversos caminhos (procEmi). Para os declarantes em geral, os mais comuns são:

a) Pelo sistema de propriedade do declarante ou contratado de terceiros, assinado digitalmente (obrigatoriamente com utilização de certificado digital) e transmitido ao eSocial por meio de WS- Webservice, recebendo um recibo de entrega (comprovante). Esse caminho é o que consta nos leiautes como procEmi = 1;

b) Diretamente no Portal do eSocial na internet - https://www.gov.br/esocial/, cujo preenchimento e salvamento dos campos e telas já operam a geração e transmissão do evento. Nessa hipótese, pode ser utilizado certificado digital ou, para os dispensados de ter esse certificado, o código de acesso. Nos leiautes esse caminho consta como procEmi = 3;

Os demais caminhos de geração e envio dos arquivos são citados nos leiautes com os seguintes códigos de procEmi:

2 - Aplicativo governamental - Simplificado Pessoa Física: aplicativo disponibilizado aos empregadores domésticos e segurados especiais. Esse aplicativo, além de gerar e enviar os arquivos também permite o gerenciamento de empregados e realiza os cálculos de verbas e de descontos, bem como efetua a geração de guias de recolhimento. Para o segurado especial, o aplicativo também permite a informação acerca da comercialização da sua produção rural.

4 - Aplicativo governamental - Simplificado Pessoa Jurídica: aplicativo disponibilizado às Microempresas e Microempreendedores individuais que além de gerar e enviar os arquivos também facilitará o gerenciamento de empregados.

22 - Aplicativo governamental para dispositivos móveis - Empregador Doméstico: aplicativo disponibilizado aos empregadores domésticos para utilização em dispositivos móveis que permite o fechamento de folha de pagamento e geração de guias, bem como a geração e envio de arquivos ao eSocial.

81 - Aplicativo governamental para envio de eventos pelo Judiciário: aplicativo que permite ao Poder Judiciário Trabalhista a geração e envio de informações ao eSocial, com o fim de suprir obrigação de prestação de informações não cumpridas pelos declarantes diretamente.

91 - Aplicativo governamental - Integração com a Junta Comercial: aplicativo que possibilita aos empresários o envio de informações relativas à admissão de empregados ao eSocial no processo de constituição de empresas.

No momento da transmissão, o Ambiente Nacional do eSocial retorna o protocolo de envio. Após a realização das validações, o eSocial retorna o recibo de entrega ou mensagem de erro.

O número do recibo de entrega é a referência a ser utilizada em eventuais retificações ou exclusões.

8.2. Acesso ao eSocial

8.2.1. Certificação Digital

O certificado digital utilizado no sistema eSocial deve ser emitido por Autoridade Certificadora credenciada pela ICP-Brasil. Este deve pertencer à série “A”, do tipo A1 ou A3. Certificados digitais de tipo A1 ficam armazenados no próprio computador a partir do qual ele é utilizado. Certificados digitais do tipo A3 são armazenados em dispositivo portátil inviolável do tipo smart card ou token, que possuem um chip com capacidade de realizar a assinatura digital.

Os certificados digitais são exigidos em dois momentos distintos:

a) Transmissão:  antes  de  ser  iniciada  a  transmissão  de  solicitações  ao  sistema  eSocial,  o certificado digital do solicitante é utilizado para garantir a segurança do tráfego das informações na internet. Para que um certificado seja aceito na função de transmissor de solicitações este deve ser do tipo e-CPF (e-PF) ou e-CNPJ (e-PJ).

b) Assinatura de documentos: para os declarantes pessoas jurídicas, os eventos podem ser gerados por qualquer estabelecimento do declarante ou seu procurador, mas o certificado digital assinante destes deve pertencer à matriz, ao representante legal desta ou ao procurador substabelecido, outorgado por meio de procuração eletrônica ou não-eletrônica. Para os Órgãos Públicos, os eventos podem ser gerados pelo representante autorizado para efetuar a transmissão das respectivas unidades administrativas.

Para os declarantes pessoas físicas, os eventos devem ser gerados pelo próprio declarante ou seu  procurador  ou,  ainda,  pelo  procurador  substabelecido, outorgado por  meio  de  procuração eletrônica ou não-eletrônica, assinados, em todos os casos, por meio de certificado digital.

Os certificados digitais utilizados para assinar os eventos enviados ao eSocial devem  estar habilitados para a função de assinatura digital, respeitando a Política do Certificado.

São aceitas somente procurações eletrônicas outorgadas perante a RFB.

Está prevista a utilização de procuração com diferentes níveis de perfis, conforme tabela a seguir, valendo destacar que cada perfil que o outorgado possuir, permite a inclusão, alteração e exclusão. Com isso, para o evento S-3000 (Exclusão), o eSocial verifica qual o tipo de evento que se pretende excluir e identifica se há permissão no perfil outorgado na procuração.

DescriçãoGrupo PerfilNome do perfilNúmero
S-2190 Registro Preliminar de Trabalhador Grupo Preliminar 1
S-1010 Tabela de Rubricas Grupo Rotinas 2
S-1020 Tabela de Lotações Tributárias
S-1070 Tabela de Processos Administrativos/Judiciais
S-1200 Remuneração do Trabalhador vinculado a Regime Geral de Previdência Social - RGPS
S-1202 Remuneração do Trabalhador vinculado a Regime Próprio de Previdência Social - RPPS
S-1207 Benefícios Previdenciários – RPPS
S-1210 Pagamentos de Rendimentos do Trabalho
S-1260 Comercialização da Produção Rural Pessoa Física
S-1270 Contratação de Trabalhadores Avulsos Não Portuários
S-2190 Registro Preliminar de Trabalhador
S-2200 Cadastramento Inicial do Vínculo e Admissão/Ingresso] de Trabalhador
S-2205 Alteração de Dados Cadastrais do Trabalhador
S-2206 Alteração de Contrato de Trabalho
S-2230 Afastamento Temporário
S-2231 Cessão/Exercício em outro órgãos
S-2298 Reintegração
S-2300 Trabalhador Sem Vínculo de Emprego/Estatutário – Início
S-2306 Trabalhador Sem Vínculo de Emprego/Estatutário - Alteração Contratual
S-2400 Cadastro de Beneficiário - Entes Públicos – Início
S-2405 Cadastro de Beneficiário - Entes Públicos – Alteração
S-2410 Cadastro de Benefício - Entes Públicos – Início
S-2416 Cadastro de Benefício - Entes Públicos – Alteração
S-2418 Reativação de Benefício - Entes Públicos
S-2420 Cadastro de Benefício - Entes Públicos – Término
S-2210 Comunicação de Acidente de Trabalho Grupo SST 3
S-2220 Monitoramento da saúde do trabalhador
S-2230 Afastamento Temporário
S-2240 Condições Ambientais do Trabalho - Agentes Nocivos
S-2299 Desligamento Grupo Desligamento 4
S-2399 Trabalhador Sem Vínculo de Emprego/Estatutário – Término
S-1298 Reabertura dos Eventos Periódicos Grupo Especial 5
S-1299 Fechamento dos Eventos Periódicos
S-1000 Informações do Empregador/Contribuinte e Órgão Público
S-1005 Tabela de Estabelecimentos, Obras de Construção Civil ou Unidades de Órgãos Públicos
Todos os eventos Acesso WEB Web Geral 6
8.2.1.1. Utilização de Certificado Digital por prestadores de serviço de Contabilidade, Administração de Condomínios, Gestores de RH e SST

O declarante envia os respectivos eventos no WS-Webservice, assinando-os com seu certificado digital.

Os atos da vida civil são praticados mediante assinatura da pessoa (física ou jurídica) titular da obrigação. O certificado digital é basicamente um arquivo eletrônico que funciona como se fosse uma assinatura digital, com validade jurídica, e que garante proteção às transações eletrônicas e outros serviços via internet, identificando o responsável pelo ato. Para sua utilização no sistema eSocial o certificado deve ser emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil, e ser do tipo A1 ou A3.

Quando uma pessoa (física ou jurídica) pratica atos em nome de outra, o faz por meio de procuração: quem assina é o procurador, representando o outorgante, com o dever de praticar os atos em seu interesse, restritos ao objeto da outorga, sob pena de responsabilidade. Em se tratando de transações no mundo digital, para esta situação, existe a figura da procuração eletrônica.

O envio de eventos para o eSocial pode ser feito tanto pela pessoa física ou jurídica sujeito passivo da obrigação, como por um terceiro com poderes outorgados para tal. Esta representação por um terceiro é uma situação rotineira na área trabalhista e tributária como, por exemplo, nos casos de escritórios de contabilidade, gestores de recursos humanos, empresas de medicina e engenharia de segurança do trabalho, ou administradoras de condomínios edilícios, todos representando seus respectivos clientes. Estes são cenários típicos em que deve ser utilizada a citada procuração eletrônica.

Ressalte-se que é irregular, embora frequente no âmbito das prestadoras de serviço supracitadas, a situação em que o certificado digital do titular da obrigação (e sua senha) são entregues ao terceiro que seria seu representante – quando o correto seria a procuração eletrônica. O representante, de posse do certificado e senha da pessoa obrigada, estaria enviando os eventos assinando-os como se fosse o titular, com o certificado digital do titular. Este procedimento implica violação das diretrizes de segurança do certificado digital, recaindo a responsabilidade sobre o titular do certificado.

8.2.2. Código de acesso para o Portal eSocial

Os declarantes não obrigados à utilização do certificado digital podem gerar Código de Acesso ao Portal eSocial, como alternativa ao certificado digital. São eles:

a) O segurado especial e o empregador doméstico;

b) A ME/EPP optantes pelo Simples Nacional, que possuam até um empregado, não incluídos os empregados afastados em razão de aposentadoria por invalidez;

c)  O MEI com até um empregado, não incluídos os empregados afastados por motivo legal. Mesmo para os mencionados acima, a utilização do código de acesso é exclusiva para os módulos web. Para WS-Webservice, é obrigatória a utilização de certificado digital. Sendo assim, mesmo que uma ME possua apenas um empregado e vá prestar suas informações por WS- Webservice, ela tem de utilizar certificado digital.

A obtenção do Código de Acesso para pessoa física exige o registro do número do CPF, data de nascimento e o número dos recibos de entrega da DIRPF dos dois últimos exercícios. Não possuindo as DIRPF, em seu lugar, deve ser registrado o número do Título de Eleitor. Para pessoa jurídica, são exigidas essas mesmas informações, sendo que relativas ao CPF do seu responsável perante a RFB. Caso o empregador pessoa física ou o responsável pela pessoa jurídica  não possua as DIRPF e

tampouco o título de eleitor, o acesso ao Portal do eSocial só pode ser feito mediante utilização de Certificação Digital.

Não é possível o envio de informações por procurador utilizando código de acesso.

8.3. Transmissão dos arquivos - sequência lógica

O declarante, ao transmitir suas informações relativas ao eSocial, deve considerar a sequência lógica descrita neste tópico, pois as informações constantes dos primeiros arquivos são necessárias ao processamento das informações constantes nos arquivos a serem transmitidos posteriormente.

As informações relativas à identificação do declarante (evento S-1000), que fazem parte dos eventos de tabelas, devem ser enviadas previamente à transmissão de todas as demais informações.

Considerando que as informações integrantes dos eventos de tabelas são utilizadas nos eventos periódicos e não periódicos, elas devem ser enviadas logo após a transmissão das informações relativas à identificação do declarante.

Em seguida devem ser enviadas, caso existam, as informações previstas nos eventos não periódicos e, por último, as informações previstas nos eventos periódicos, conforme os exemplos adiante:

1 - Ao enviar as informações de remuneração dos trabalhadores/servidores (folha de pagamento), as rubricas da folha devem constar da tabela de rubricas.

2 - Ao transmitir um arquivo com informações de alteração de dados cadastrais de um determinado empregado, este deve constar do RET como empregado ativo. Para constar no RET, há necessidade de ter sido transmitido previamente o evento de S-2200 (Admissão de Trabalhador).

3 - Ao enviar a remuneração de determinado empregado na folha de pagamento, esse trabalhador já deve constar do RET.

8.4. Protocolo de envio e Recibo de entrega

O protocolo de envio é uma informação transitória, indicando que um lote de evento(s) foi transmitido ao Ambiente Nacional do eSocial e que são aplicadas as correspondentes validações.

O recibo de entrega só é emitido após o evento ser validado e recepcionado pelo Ambiente Nacional. O efetivo cumprimento da obrigação de prestar informação se dá com a emissão do recibo de entrega.

Para cada evento recepcionado é gerado um número de recibo de entrega, enquanto que o protocolo de envio é único para um lote de até 50 eventos.

Exemplo: foi enviado um lote com 30 eventos de admissão. É gerado um número de protocolo de envio. Se desses 30 eventos, apenas 28 foram validados e recepcionados, são gerados 28 recibos de entrega e duas mensagens de erro.

Quando se pretende efetuar a retificação ou exclusão de determinado evento deve ser informado o número do recibo de entrega do evento que se pretende retificar ou excluir.

8.5. Constituição de créditos e geração de guias de recolhimento

As informações constantes do eSocial são recepcionadas pelo Ambiente Nacional, sendo que o declarante utiliza as ferramentas de constituição de crédito tributário e emissão de guias de recolhimento na DCTFWeb para as contribuições previdenciárias e contribuições para terceiros e posteriormente para o imposto de renda referente à remuneração do trabalhador.

Paralelamente, está em desenvolvimento a Plataforma FGTS Digital, aprovada pelas Resoluções CCFGTS nº 926, de 28 de maio de 2019 e 935, de 27 de agosto de 2019. Até que seja disponibilizada essa ferramenta, o recolhimento do FGTS continua a ser feito mediante a geração da GFIP, no ambiente da CAIXA.

O eSocial não apura as contribuições previdenciárias devidas aos RPPS para fins de constituição de crédito e geração de guias de recolhimento.

8.6. Diferença entre advertências e erros

Ao processar um evento o eSocial pode encontrar inconsistências impeditivas ou não impeditivas para sua recepção. Quando a inconsistência é impeditiva o usuário recebe a descrição da ocorrência com o tipo "1 - Erro" e o evento é recusado, ou seja, o usuário precisa corrigir o defeito apontado para que ele seja posteriormente recepcionado. Quando o processamento encontra uma inconsistência não impeditiva, o usuário recebe uma mensagem de sucesso mas com uma ou mais ocorrências do tipo "2

– Adverrtência". Essas advertências não interferem na recepção com sucesso dos eventos. O objetivo desse alerta é apenas chamar a atenção do usuário para situações de prováveis incongruências. Exemplo de advertência não impeditiva: recepção de um evento S-1299 com ausência de evento de remuneração de um trabalhador ativo no RET na correspondente competência.

9. Tabelas do eSocial

O eSocial trabalha com dois grupos de tabelas: eventos de tabelas ou tabelas do empregador e as tabelas do eSocial.

As tabelas do eSocial são um grupo de tabelas padronizadas, constantes no anexo I do Leiaute do eSocial. Seu conteúdo não sofre alteração pelo declarante e sim apenas mediante publicação de nova versão desse anexo do Leiaute. As tabelas do eSocial são as adiante listadas.

TABELADESCRIÇÃO
Tabela 1 Categorias de Trabalhadores
Tabela 2 Financiamento da Aposentadoria Especial e Redução do Tempo de Contribuição
Tabela 3 Natureza das Rubricas da Folha de Pagamento
Tabela 4 Códigos e Alíquotas de FPAS/Terceiros
Tabela 5 Tipos de Inscrição
Tabela 6 Países
Tabela 7 Tipos de Dependente
Tabela 8 Classificação Tributária
Tabela 9 Tipos de Arquivo do eSocial
Tabela 10 Tipos de Lotação Tributária
Tabela 11 Compatibilidade entre Categoria de Trabalhadores, Classif. Tributária e Tipos de Lotação
Tabela 12 Compatibilidade entre Tipos de Lotação e Classificação Tributária
Tabela 13 Parte do corpo atingida
Tabela 14 Agente causador do Acidente de Trabalho
Tabela 15 Agente Causador/Situação Geradora de Doença Profissional
  Excluído
Tabela 17 Descrição da Natureza da Lesão
Tabela 18 Motivos de Afastamento
Tabela 19 Motivos de Desligamento
Tabela 20 Tipos de Logradouros
Tabela 21 Códigos de incidência tributária da rubrica para IRRF
Tabela 22 Compatibilidade entre FPAS e Classificação Tributária
Tabela 23 Relacionamento entre tipo de valor do FGTS, Categoria, Origem, Código de incidência do FGTS e condição
Tabela 24 Agentes Nocivos e Atividades - Aposentadoria Especial
Tabela 25 Tipos de Benefícios
Tabela 26 Motivos de Cessação de Benefícios
Tabela 27 Procedimentos Diagnósticos
Tabela 28 Treinamentos, Capacitações, Exercícios simulados e outras anotações

10. Eventos do eSocial

As informações são prestadas ao eSocial por meio de eventos. Tratam-se esses eventos de arquivos com informações dos declarantes, elaborados de acordo com uma estrutura específica e pré- determinada.

A forma como os dados devem ser dispostos num evento, as regras de validação de preenchimento dos campos e a estrutura dessas informações, necessárias à composição de um evento, são chamadas de leiaute.

Todos os eventos (de tabelas, não periódicos e periódicos) possuem um leiaute específico e o conjunto desses leiautes, com seus anexos, são publicados e ficam disponíveis no sítio do eSocial.

As informações requeridas nos eventos devem ser preenchidas com a observância de dois tipos de regras: as regras de validação constantes nos próprios grupos e campos do leiaute e as regras gerais, constantes de uma tabela específica de regras, publicadas em documento anexo ao arquivo onde constam os leiautes dos eventos (Anexo II).

As regras são dispostas de forma clara nesses documentos e, portanto, não são repetidas neste manual a não ser que demandem algum esclarecimento adicional ou sua referência seja necessária para o entendimento de algum outro conceito.

10.1. Tabelas do Empregador

É o primeiro grupo de eventos a ser transmitido ao Ambiente Nacional do eSocial. O evento S-1000 identifica o declarante, contendo dados básicos de sua classificação fiscal e de sua estrutura administrativa. Além do evento S-1000, as tabelas do empregador são: tabelas de estabelecimentos (S-1005), rubricas da folha de pagamento (S-1010), lotações tributárias (S-1020) e informações de processos administrativos e judiciais (S-1070).

Estes eventos complementam a estrutura da base de dados, sendo responsáveis por uma série de informações que validam os eventos não periódicos e periódicos, e buscam otimização na geração dos arquivos e no armazenamento das informações no Ambiente Nacional do eSocial, por serem utilizadas em mais de um evento do sistema ou por se repetirem em diversas partes do leiaute. Nesse sentido, só precisam ser enviados quando suas informações forem referenciadas em outros eventos. A tabela S-1005, por exemplo, pode ser enviada no momento imediatamente anterior ao do envio do evento S-2200 relativo a um empregado, ainda que na fase de cadastramento inicial, já que suas informações só têm valor jurídico quando referenciadas em outros eventos.

A perfeita manutenção dessas tabelas é fundamental para a recepção dos eventos periódicos e não periódicos e à adequada apuração das bases de cálculo e dos valores devidos de tributos e FGTS.

A administração do período de validade das informações é importante pois impacta diretamente os demais eventos que as utilizam.

Quando da primeira informação dos itens que compõem uma tabela, deve ser preenchido obrigatoriamente o campo data de início da validade {iniValid}. Caso haja necessidade de corrigir informação específica de uma tabela enviada anteriormente deve ser utilizado o grupo [alteracao] do evento da tabela, com o item que deve ser alterado. Nessa hipótese, a informação anterior do evento de tabela é sobreposta pelo novo evento.

Caso seja necessário alterar algum atributo de uma tabela a partir de uma determinada data, mantendo a informação histórica, deve ser enviado um novo evento com o mesmo código, mas com nova vigência no grupo [inclusão]. Nessa hipótese, a data de fim de validade da informação prestada anteriormente passa a ser o mês/ano imediatamente anterior ao da data de início da nova informação. Não é necessário o envio de evento específico para informar a data de fim de validade do item enviado anteriormente, no entanto o seu envio tem o mesmo efeito do procedimento anterior.

Não há necessidade de ser informada ao eSocial a baixa do CNPJ. Mas, em caso de o declarante optar por prestar essa informação, deve primeiro encerrar todas as suas tabelas e, na sequência, enviar o evento S-1000, com o grupo de informações relativas à alteração, com a data fim de validade, do subgrupo nova validade, preenchida.

10.2. Eventos Não Periódicos

São aqueles que não têm uma data pré-fixada para ocorrer, pois dependem de acontecimentos na relação entre o declarante e o trabalhador que influenciam no reconhecimento de direitos e no cumprimento de deveres trabalhistas, previdenciários e fiscais como, por exemplo, a admissão/ingresso de um empregado/servidor, a alteração de salário, a exposição do trabalhador a agentes nocivos e o desligamento, dentre outros.

Inclui-se neste grupo o cadastramento inicial dos vínculos dos empregados ativos, servidores ativos, mesmo que afastados, dos militares e dos beneficiários dos RPPS. Tais informações são enviadas no evento S-2200 após o envio do grupo de eventos de tabelas. O cadastramento inicial é enviado pelo declarante no início da implantação do eSocial, com todos os vínculos ativos, com seus dados cadastrais atualizados, e servem de base para construção do RET, o qual é utilizado para validação dos eventos de folha de pagamento e demais eventos enviados posteriormente.

10.3. Eventos Periódicos

São aqueles cuja ocorrência tem periodicidade previamente definida, compostos por informações de folha de pagamento, de apuração de outros fatos geradores de contribuições previdenciárias como, por exemplo, os incidentes sobre  comercialização de produção rural por pessoas física.

Saliente-se que o eSocial recepciona e registra os fatos geradores relativos aos eventos periódicos S-1200, S-1202,   S-1207,   S-1260, S-1270 ou S-1280 utilizando-se do regime de competência, enquanto que o evento periódico S-1210 se submete ao regime de Caixa.

10.3.1. Movimento e período de apuração para os eventos periódicos

Considerando as consequências tributárias e fundiárias (FGTS) dos eventos periódicos, com sua respectiva vinculação ao “período de apuração” do tributo ou do FGTS devido, podemos dizer que um conjunto de eventos periódicos referentes ao mesmo período de apuração corresponde a um “movimento”.

Presume-se aberto o movimento de um período de apuração com o envio de qualquer evento periódico a ele relativo. Especificamente em relação à Folha de Pagamento presume-se aberto o movimento com o envio do primeiro evento S-1200, S-1202 ou S-1207. O evento S-1299 é utilizado para informar ao Ambiente Nacional do eSocial o encerramento da transmissão dos eventos periódicos de um movimento relativo a determinado período de apuração.

A aceitação do evento de fechamento pelo eSocial, após processadas as devidas validações, conclui a totalização das bases de cálculo contempladas naquele movimento, possibilita a constituição dos créditos e os recolhimentos de contribuições previdenciárias do RGPS e do FGTS, quando for o caso.

O eSocial não apura as contribuições previdenciárias devidas ao RPPS para fins de constituição de crédito e geração de guias de recolhimento.

Caso sejam necessárias retificações, exclusões ou envio de novos eventos referentes a um movimento já encerrado, o mesmo deve ser reaberto com o envio do evento S-1298. Efetivada uma reabertura para o movimento, torna-se necessário um novo envio do evento fechamento.

O evento de fechamento tem como objetivo sinalizar que as informações que afetam o cálculo de débitos tributários foram todas transmitidas.

10.3.2. Folha de Pagamento

O eSocial é uma nova forma de prestação das informações que devem constar na folha de pagamento do empregador. O evento S-1200, S-1202 ou S-1207 concentra as informações inerentes à folha de pagamento, com interação com os eventos de tabelas e com os eventos não periódicos que interferem na remuneração mensal do trabalhador (por exemplo o S-2200, S-2206, ou mesmo o evento S-2230).

A Folha de Pagamento no eSocial é um conjunto de informações que reflete a remuneração de todos os trabalhadores que estiveram a serviço do declarante naquela competência. Entretanto, cada trabalhador é tratado individualmente, de forma que a retificação da remuneração de um trabalhador não afeta os demais. A Folha de Pagamento, com eventos por trabalhador, deve ser enviada compondo um movimento com prazo para transmissão e fechamento até o dia 15 (quinze) do mês seguinte ao do período de apuração, antecipando-se o vencimento para o dia útil imediatamente anterior, em caso de não haver expediente bancário.

O movimento relativo à Folha de Pagamento presume-se aberto com o envio do primeiro evento S-1200, S-1202 ou S-1207 para aquele período de apuração. O encerramento da transmissão dos eventos periódicos com informações da Folha de Pagamento daquele movimento é feito pelo evento S-1299.

A transmissão do evento S-1299 ao eSocial, após processadas as devidas validações, conclui a totalização das bases de cálculo contempladas naquela folha de pagamento, possibilita a constituição do crédito e os recolhimentos das respectivas contribuições previdenciárias e FGTS.

10.3.3. Remuneração e Pagamento no eSocial

A informação declarada como folha de pagamento no eSocial serve de base para os cálculos da Contribuição Previdenciária e FGTS, e posteriormente de IRRF. Seguindo a premissa de unicidade na informação originada na folha de pagamento, como regra as rubricas de remuneração da folha – regime de competência - devem ser informadas em um só evento, o S-1200, S-1202 ou S-1207. A data de pagamento efetivo ao empregado é informada no evento S-1210.

10.3.4. Orientações sobre a folha de 13º salário

O eSocial possui dois tipos de eventos periódicos de folha de pagamento: mensal (AAAA-MM) e de 13º salário (período de apuração anual – AAAA). Ambas folhas são informadas por meio do evento S-1200 respectivo no mês de dezembro.

A apuração da CP e do IRRF incidentes sobre o 13º salário é feita apenas na folha de 13º (anual). Nesse caso, o empregador deve gerar a folha do 13º levando em consideração o adiantamento efetuado até o mês de novembro, conforme orientações contidas neste Manual (ver item 19 das “Informações  adicionais”  do evento S-1200), e transmitir  à DCTFWeb para geração da guia de recolhimento da contribuição previdenciária. Vale dizer, no mês de dezembro são geradas duas folhas pelo eSocial: dezembro e 13º salário, ambas recepcionadas pela DCTFWeb, sendo que o contribuinte deve transmiti-las de forma independente.

Já o FGTS tem tratamento diferente. Apesar de não existir uma competência “13” para o recolhimento do FGTS, as informações constantes na folha de 13º salário do eSocial são incluídas na guia da competência “dezembro”, juntamente com os valores da remuneração do próprio mês. Mas ressalte-se que isso só irá ocorrer após a substituição da GFIP pelo FGTS Digital. Até lá, a geração da guia de recolhimento do FGTS continua a ser gerada com base nas informações da GFIP.

É de se destacar que o FGTS, ao contrário da CP e do IRRF, incide sobre a parcela do adiantamento do 13º salário no mês em que for paga. Por exemplo, um adiantamento feito em novembro tem incidência de FGTS, mas não de CP ou IRRF. Assim, o FGTS incidente sobre a folha do

13º salário é calculado apenas sobre a diferença entre o valor da gratificação natalina e a primeira parcela (no exemplo, o adiantamento feito em novembro).

Caso haja ajustes de 13º salário decorrentes do recebimento de remuneração variável (comissões sobre vendas, por exemplo), o complemento deve ser pago até o dia 10 de janeiro e informado na folha mensal da respectiva competência (dezembro ou janeiro), em rubrica específica (natureza de rubrica 5005 –13º salário complementar) previamente cadastrada no evento S-1010 com as incidências de 13º para os campos {codIncCP}, {codIncFGTS} e {codIncIRRF}.

10.3.4.1. Adiantamento integral do décimo terceiro salário antes do mês de dezembro

Os declarantes que, por liberalidade ou por força de convenção ou acordo coletivo, realizam o pagamento do 13º salário de forma integral, antes do mês de dezembro devem observar as seguintes orientações:

a)    De acordo com a legislação vigente, o valor do 13º salário deve ser calculado com base no salário devido em dezembro e ser pago em duas parcelas: a primeira entre os meses de fevereiro a novembro e a segunda em dezembro, até o dia 20.

b)    O desconto da contribuição previdenciária deve ocorrer no pagamento da segunda parcela do 13º salário e o seu recolhimento deve ser feito na competência anual, cujo vencimento é o dia 20 de dezembro.

Todavia, na prática, é muito comum o pagamento do 13º integral antes do mês de dezembro. Conceitualmente, contudo, o que ocorre nesses casos não é o pagamento integral e sim um adiantamento superior ao valor devido e, assim, deve ser declarado na folha do mês em que esse pagamento ocorre.

O declarante que antecipar o pagamento integral do 13º salário até o mês de novembro deve pagar o correspondente ao líquido devido, ou seja, valor obtido após a dedução da contribuição previdenciária e, quando for o caso, da retenção do imposto de renda. Dessa forma, na folha do 13º salário, em dezembro, ao descontar o valor adiantado em mês anterior, o valor líquido restaria zerado. Mas ressalte-se que esse pagamento anterior a dezembro deve ocorrer na rubrica correspondente a adiantamento.

No eSocial, o declarante deve informar o adiantamento (correspondente ao valor líquido) no evento S-1200 referente à remuneração da competência em que esse adiantamento foi incluído e, em dezembro, deve enviar o evento S-1200 referente à competência anual com o valor do 13º salário devido e o valor dos descontos do adiantamento, de contribuição previdenciária e de retenção de imposto de renda.

Saliente-se que, na competência em que o valor do adiantamento for declarado, há a incidência do FGTS (nesse caso calculado sobre o valor do adiantamento) e na folha anual há a incidência da contribuição previdenciária e do imposto de renda, calculados sobre o valor total e, ainda, a do FGTS, calculado sobre a diferença entre o valor total e o do adiantamento.

Por exemplo, o valor do 13º salário de um empregado é R$ 1.045,00. O desconto correspondente à contribuição previdenciária é de R$ 78,37. Se o empregador vai pagar o valor integral do 13º na competência novembro de 2020, deve incluir no S-1200 da competência 11/2020 a rubrica de “Adiantamento 13º salário” (Natureza 5001) no valor de R$ 966,63.

No período de apuração anual, no mês de dezembro, o declarante deve lançar como vencimento o valor total do 13º devido (R$ 1.045,00) e como descontos: o valor do adiantamento do 13º pago em novembro (R$ 966,63) e o valor da contribuição previdenciária (R$ 78,37). A folha anual, portanto, ficaria com valor líquido zerado, considerando-se que não houve dedução de imposto de renda na fonte.

No exemplo acima, a base de cálculo do FGTS incidente sobre o 13º salário na competência 11/2020 seria de R$ 966,63 e o valor na competência anual seria de R$ 78,37.

Caso o declarante prefira recolher o FGTS integralmente no mês em que o 13º salário foi adiantado, deve lançar o valor total (bruto) como rubrica de adiantamento de 13º com incidência do FGTS e o desconto da provisão de contribuição previdenciária com o código de incidência [00].

Registre-se que, caso o empregado tenha um aumento salarial no mês de dezembro, o cálculo do 13º salário deve ser refeito considerando esse valor, o que implica diferença a pagar ao empregado. O mesmo vale para os trabalhadores que recebem remuneração variável, quando incide a hipótese do art. 2º do Decreto nº 57.155, de 3 de novembro de 1965, caso em que os dados devem ser declarados na competência em que for devido o pagamento.

Ilustrativamente, caso o ajuste tenha sido apurado e pago ao empregado após o fechamento da folha do 13º, mas ainda no mês de dezembro, o ajuste deve ser informado na folha do mês de dezembro. Caso o ajuste tenha sido efetuado no mês de janeiro, deve ser informado na folha de janeiro. Em ambos os casos deve ser utilizada rubrica específica (natureza de rubrica 5005 – 13º salário complementar).

Alternativamente à solução aqui exposta, o declarante pode pagar o adiantamento do 13º salário normalmente e realizar o pagamento da segunda parcela nos primeiros dias do mês de dezembro. Cabe destacar que os eventos S-1200 e S-1299 referentes ao período de apuração anual devem ser enviados entre os dias 01 e 20 de dezembro.

É importante lembrar que não há período de apuração anual para o evento S-1210, ou seja, nesse evento devem ser informados todos os pagamentos efetuados no mês indicado no campo {perApur} e o prazo para seu envio segue a regra geral, ou seja, deve ser enviado até o dia 15 (quinze) do mês seguinte ou até o fechamento da folha deste mês, o que ocorrer primeiro.

Com relação ao 13º salário, no evento S-1210 deve constar um demonstrativo da folha de pagamento de folha anual (13º salário), com a indicação do período de referência {perRef} informado no formato AAAA.

11. Registro de Eventos Trabalhistas – RET

As informações dos eventos não periódicos alimentam a base de dados no Ambiente Nacional do eSocial, denominada RET.

Todos os arquivos de eventos não periódicos, ao serem transmitidos ao eSocial, são submetidos às regras de validação e somente são aceitos se estiverem consistentes com o RET.

Exemplo 1: o evento de desligamento de empregado somente é aceito se, para aquele empregado/servidor, tiver sido enviado anteriormente, o evento de admissão/ingresso.

Exemplo 2: um evento de reintegração somente é aceito se o empregado/servidor já estiver desligado.

O RET também é utilizado para validação da folha de pagamento, composta pelos eventos de remuneração e pagamento dos trabalhadores, que fazem parte dos eventos periódicos.

Além dos empregados/servidores, também alimentam o RET, os trabalhadores sem vínculo empregatício/estatutário pelo envio do evento TSVE – Início. Os TSVE incluem obrigatoriamente os trabalhadores avulsos, os dirigentes sindicais, os estagiários, os servidores cedidos em relação ao órgão público cessionário e algumas categorias de contribuintes individuais, como diretores não empregados e cooperados. Porém, todos os contribuintes individuais, mesmos os não abrangidos pelas atividades específicas obrigatórias supracitadas, podem ser incluídos como TSVE, de forma opcional.

No fechamento dos eventos periódicos, o eSocial verifica se foi informada a remuneração de todos os empregados/servidores relacionados no RET como ativos, com exceção dos trabalhadores que estejam afastados  sem  remuneração devida  ou  os  intermitentes. No  caso  de  ausência de remuneração de um empregado/servidor ativo, o evento de fechamento é recepcionado, mas gera uma advertência para o declarante. Já para os trabalhadores cadastrados por meio do evento S-2300, não é aplicada a regra acima.

Para fins de validação na base do RET é considerado apenas o trabalhador ativo no respectivo período de apuração. Considera-se ativo o empregado/servidor não desligado e o trabalhador sem vínculo antes do término da prestação de serviço ou cessão. Nos casos de quarentena, conforme definido em lei, considera-se ativo até a data de término da quarentena.

11.1. Trabalhadores não incluídos no RET

Os trabalhadores sem vínculo de emprego, que não se enquadram nas categorias de envio obrigatório de informações pelo S-2300, e para os quais o declarante também não se utilizou da faculdade de enviar suas informações no citado evento s-2300, devem obrigatoriamente ter suas informações preenchidas no grupo [infoComplem]: nome, data de nascimento etc e no grupo [InfoComplCont]: CBO, natureza da atividade etc, quando do envio do evento S-1200, para a correta identificação deste trabalhador que não está no RET.

12. Situação “Sem Movimento”

A situação “Sem Movimento” para o declarante só ocorre quando não há informação a ser enviada, para o grupo de eventos periódicos S-1200 a S-1280, em relação a todos os estabelecimentos, obras ou unidades do declarante. Neste caso, o declarante, exceto o MEI, envia o evento S-1299 como “Sem Movimento” na primeira competência do ano em que esta situação ocorrer. Caso esta situação ocorra antes do início da obrigatoriedade do envio da DCTFWeb, o declarante deve enviar o S-1299 como “Sem Movimento” na competência do início dessa obrigatoriedade.

O envio dessa informação é obrigatório caso os campos {evtRemun}, {evtAqProd}, {evtComProd},{evtContratAvNP}, {evtInfoComplPer} forem preenchidos com [N].

Caso o declarante possua um ou mais estabelecimentos com movimento, não deve ser enviada a situação “Sem movimento” no evento S-1299, conforme descrito acima.

Os obrigados ao eSocial, que no início da utilização não tiverem empregados, nem quaisquer fatos geradores de contribuição previdenciária, nem de imposto de renda, devem enviar, durante a implementação progressiva do eSocial, o evento S-1000 na primeira fase de envio dos eventos e o evento S-1299 sem movimento na primeira competência em que o envio dos eventos periódicos se tornar obrigatório. Para a declaração de situação “Sem movimento” é desnecessário o envio de qualquer outro evento, como por exemplo as tabelas de estabelecimentos e de rubricas.

O declarante constituído após o início da obrigatoriedade de utilização do eSocial que não tenha movimento no mês de sua constituição deve adotar o procedimento descrito no parágrafo anterior nessa mesma competência.

Caso a situação “Sem movimento” do declarante, nas três situações acima, persista nos anos seguintes, o declarante deve repetir o procedimento de envio do S-1299 sem movimento na competência janeiro de cada ano, exceto para empregador pessoa física, cuja informação é facultativa.

Em razão de legislação específica, o Microempreendedor individual - MEI que não tem empregado está dispensado de enviar os eventos S-1000 e S-1299, com a informação “Sem movimento”. Também está dispensada do envio dessa mesma informação a pessoa física, ainda que tenha inscrição no CAEPF, que no início da obrigatoriedade do eSocial, encontra-se na situação “Sem Movimento”.

Em razão de serem dispensadas da DCTFWeb, as entidades adiante relacionadas não precisam enviar os eventos S-1000 e S-1299, com a informação “Sem movimento”:

  • Os fundos especiais de natureza contábil ou financeira, não dotados de personalidade jurídica, criados no âmbito de qualquer dos poderes da União, dos estados, do Distrito Federal e dos municípios;
  • As comissões sem  personalidade  jurídica  criadas  por  ato  internacional  celebrado  pela

República Federativa do Brasil e um ou mais países, para fins diversos;

  • Os fundos de investimento imobiliário ou os clubes de investimento registrados em Bolsa de Valores, segundo as normas fixadas pela CVM ou pelo Bacen, cujas informações, quando existirem, são prestadas pela instituição financeira responsável pela administração do fundo; e
  • Os organismos oficiais internacionais ou estrangeiros em funcionamento no Brasil que não tenham trabalhador segurado do RGPS que lhes preste serviços.

13. Indicação de requisitos para envio dos eventos

Os eventos do eSocial devem ser transmitidos com estrita observância da forma e condições impostas pelos leiautes de cada evento e há um encadeamento entre os eventos, tornando necessária a observância de uma ordem cronoloógica para o seu envio. Por exemplo, um evento de admissão de um trabalhador não pode ser enviado antes de pelo menos um evento de tabela de estabelecimentos, pois no evento de admissão deve ser referenciado um estabelecimento como local de trabalho do empregado.

A indicação dos requisitos necessários para cada evento está descrita no capítulo III deste Manual.

14. Datas

14.1. Preenchimento geral dos campos com data

Como regra, nas situações em que não houver indicação expressa do formato do campo data, esta deve ser registrada no formato: AAAA-MM-DD.

No caso de “competência” (Indicativo de período de referência: 1 - Folha de Pagamento Mensal) deve se registrar AAAA-MM e para o 13º Salário (Indicativo de período de referência: 2 - Folha do Décimo Terceiro Salário) registrar AAAA. Também para Período de Apuração deve ser informado o ano/mês (formato AAAA-MM) de referência das informações.

Para os campos data não são aceitas informações de datas futuras, exceto se expressamente mencionado no próprio campo.

14.2. Registro de data inicial do evento

Na implantação do eSocial existem eventos em que a data inicial se refere a período anterior ao início do eSocial.

Uma regra de validação básica do eSocial – REGRA_EXIST_INFO_EMPREGADOR, constante da Tabela de Regras do eSocial, determina que um evento somente pode ser recepcionado se existir informações cadastrais do declarante vigente para a data do evento, ou seja, a data do evento (ou período de apuração, no caso de evento S-1200 e no S-1202 deve estar compreendida entre o {iniValid} e {fimValid} do evento S-1000.

No que tange ao campo início de validade {iniValid} do evento S-1000, deve-se observar a REGRA_INFO_EMP_VALIDA_DTINICIAL, que estabelece que o campo {iniValid} deve ser sempre igual ou posterior à data de início das atividades da empresa e para os Órgãos Púbicos é a data de criação do Ente Federativo, constante na base de dados do CNPJ. Assim, a Data de Início de Validade deve ser a [Data de Início da obrigatoriedade do eSocial para esse declarante] ou, no caso do declarante ter iniciado suas atividades posteriormente à obrigatoriedade de implantação do eSocial, a [Data de Início de Atividade do Empregador] ou mesmo a [Data do seu primeiro vínculo empregatício].

Seguem adiante alguns exemplos ilustrativos: Exemplo 1:

Início de atividade da empresa “A” constante na base de dados do CNPJ = 01/05/2005. Início da

obrigatoriedade do eSocial para esse empregador = 01/01/2018.

Evento S-1000 – início de validade {iniValid} = 2018-01. Exemplo 2:

Início de atividade da empresa “B”, constante na base de dados do CNPJ = 01/05/2018. Início do

eSocial 01/01/2018

Evento – S-1000 – {iniValid} = 2018-05.

14.3. Data-início-validade e Data-fim-validade nas Tabelas

Todos os eventos de tabela do eSocial, S-1005 a S-1070, incluindo ainda o evento S-1000, possuem um atributo de vigência ou “Período de validade das informações” representado nos campos início de validade {iniValid} e {fimValid}, preenchidos no formato AAAA-MM.

Esses eventos de tabelas “guardam um histórico” das informações transmitidas, vinculado ao respectivo “período de validade”.

A regra para esses casos é que não deve existir outro registro na tabela com o mesmo código de identificação (chave) em período de vigência conflitante com o período informado no registro atual.

Neste sentido, todos os eventos de tabela possuem 4 grupos de informações:

a) Inclusão:  utilizada  para  inserir  item  na  tabela  ou  modificar  um  atributo  de  um  item  já existente, com uma nova vigência;

b) Alteração: utilizada para alterar os atributos de um item que estavam incorretos para um determinado período que se quer alterar;

c) Nova validade: utilizada para modificar a validade de uma ocorrência da tabela e, inclusive, para informar data fim de validade de uma ocorrência;

Identificador Tabela de RubricasInício de ValidadeFim de validadeIncidência  Contr. PrevidenciáriaIncidência FGTS
Rubrica 001 2015.10 2015.12 SIM NÃO
Rubrica 001 2016.01   NÃO NÃO
Rubrica 002 2015.10 2016.01 SIM SIM
Rubrica 003 2015.10   SIM SIM

d) Exclusão: utilizada para excluir uma determinada ocorrência de uma tabela. Exemplo de informação de início e fim de validade de tabelas:

Sendo:

I. Itens da tabela: rubricas 001, 002, 003;

II. Ocorrências da rubrica 001: períodos 2015.10 a 2015.12 e a partir de 2016.01; III. Atributos: incidência de contribuição previdenciária e incidência de FGTS;

IV. Chave: identificador, início e fim de validade. Observações:

a) Para  inserir  uma  rubrica  004  na  tabela  de  rubricas,  o  declarante  deve  utilizar  o  grupo [inclusão];

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.

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 doTrabalhador
  • 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 advertência 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, 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.

Os campos que compõem a identificação de um vínculo (por exemplo, CPF e matrícula de trabalhador informado no evento S-2200) e o período de apuração dos eventos de remuneração (por exemplo, campo {perApur} no evento S-1200 ou {dtDeslig} no eventos S-2299 quando implicar mudança de mês) não podem ser retificados. Havendo necessidade de alteração do conteúdo desses campos, o evento deve ser excluído e enviado um novo.

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.

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:

a) 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.

b) 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.

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.

tmpResid trabImig E N 0-1 001 -

Tempo de residência do trabalhador imigrante:

1 - Prazo indeterminado;

2 - Prazo determinado.

Validação: Preenchimento obrigatório se ({dtAdm} ou {dtExercicio}) >= [2021-03-08].

Valores Válidos: 1, 2.

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.

17. Exclusão de eventos

Para exclusão de eventos transmitidos indevidamente, faz-se necessária a transmissão de arquivo no leiaute previsto em S-3000, observando as regras dispostas neste Manual.

No caso de exclusão o procedimento do declarante é o de enviar o evento S-3000 identificando o evento a ser excluído nos campos tipo de evento {tpEvento} e no campo {nrRecEvt} o número do recibo do arquivo originalmente enviado a ser excluído.

Somente é permitida a exclusão de eventos não periódicos e periódicos. Para proceder a uma exclusão de tabelas o declarante transmite o evento tabela respectivo preenchendo as informações no grupo [exclusao].

A exclusão dos eventos obedece às seguintes regras:

a) não é possível excluir nenhum dos eventos periódicos – S-1200 a S-1270 – relativos a um período de apuração que se encontre "encerrado", ou seja, para o qual já exista evento S-1299, antes do envio do evento de reabertura respectivo S-1298.

b) não é possível a exclusão de um evento de remuneração quando houver evento de pagamento (S-1210) a ele vinculado. Portanto, para essa exclusão o evento de pagamento deve ser previamente excluído.

c) a exclusão de alguns tipos de eventos não periódicos pode ser rejeitada em algumas situações, quando sua exclusão gerar inconsistência no encadeamento de eventos posteriores. Por exemplo, não é possível excluir um evento de admissão se já houver outro evento não periódico posterior para o mesmo CPF/Vínculo.

d) em caso de exclusão de qualquer evento não periódico ou periódico, as informações de CPF do trabalhador, indicados no evento de exclusão, devem ser os mesmos que constam no evento objeto de exclusão.

e) somente é permitido excluir evento não periódico ou periódico com o mesmo {procEmi} do evento original, exceto:

1) Evento enviado por WS-WebService pode ser excluído no Web Geral e vice-versa;

2) Evento enviado pelo aplicativo operacionalizado pela Junta Comercial pode ser excluído por WS-WebService, Web Geral ou nos módulos WS-Simplificados (a possibilidade de envio pelo balcão único ainda não tem previsão para entrar em produção).

18. Consulta das informações e download dos arquivos transmitidos

Existem duas formas de o declarante consultar as informações transmitidas ao Ambiente Nacional do eSocial. A primeira delas é acessar o Web Geral e fazer uma simples visualização individual de qualquer evento transmitido, podendo consultar:

  • qualquer item de tabela, pesquisando por seu código de identificação, quando são exibidas todas as vigências daquele determinado item;
  • todos os eventos não periódicos, separados por trabalhador, devendo a pesquisa ser feita por CPF, quando é exibida uma relação com todos os eventos não periódicos, originais e retificados, em ordem cronológica; e
  • todos os eventos periódicos, separados por período de apuração e por CPF do trabalhador.

A segunda opção é a solicitação dos arquivos XML dos eventos do Ambiente Nacional através de um “baixador” assíncrono, ou seja, uma ferramenta que viabiliza, sob demanda, a transferência (download) dos arquivos de determinado período do Ambiente Nacional para o usuário solicitante. Nessa ferramenta, disponível no Web Geral, o usuário registra a solicitação de arquivos de determinado tipo/período e o eSocial disponibiliza o lote de arquivos que atendem esses critérios para o download do solicitante. Cabe ressaltar que os arquivos não são disponibilizados de forma imediata, os pedidos são atendidos de forma assíncrona, ou seja, os pedidos são registrados em determinado momento pelo usuário e o resultado da solicitação é disponibilizado em momento posterior, cujo tempo de retorno depende da quantidade de arquivos solicitados e da abrangência do pedido.

Os parâmetros para solicitação destes arquivos são:

  • cada pedido pode solicitar eventos de período de até a 35 dias;
  • podem ser registrados até 12 pedidos por dia; e
  • podem ser solicitados todos os eventos de cada período ou a solicitação pode ser filtrada por tipo de evento (tabela de rubricas, por exemplo), por trabalhador, por número de recibo ou por eventos enviados via aplicativo governamental (procEmi = 3, 4 ou 5).

Após registrado o pedido, ele é exibido na tela do Web Geral com um dos seguintes estados: “solicitado”, “em processamento”, “disponível para baixar” (quando o arquivo está pronto), “baixado” e “expirado” (depois de alcançado o tempo de guarda).

19. Informações Gerais Sobre os Eventos de Segurança e Saúde no Trabalho – SST

São definidos como eventos de Segurança e Saúde no Trabalho – SST os adiante elencados:

  • S-2210 - Comunicação de Acidente de Trabalho;
  • S-2220 - Monitoramento da Saúde do Trabalhador;
  • S-2240 - Condições Ambientais do Trabalho - Agentes Nocivos;

Os eventos de SST possuem como finalidade principal a substituição dos atuais formulários utilizados para envio da CAT e do PPP. Tais eventos estão diretamente relacionados à SST, porém existem dados em outros eventos que são utilizados para compor as informações exigidas pelos formulários substituídos.

Os eventos de SST estão estruturados na forma adiante descrita:

  • Evento S-2210: utilizado para o envio da CAT pelo empregador/tomador de mão-de-obra de trabalhador avulso e empregador doméstico.
  • Evento S-2220: neste evento é feito o acompanhamento da saúde do trabalhador durante o seu contrato de trabalho, com as informações relativas aos ASO e seus exames complementares. Tais informações correspondem àquelas exigidas no PPP.
  • Evento S-2240: são prestadas as informações da exposição do trabalhador aos agentes nocivos, conforme “Tabela 24 – Agentes Nocivos e Atividades - Aposentadoria Especial” do eSocial e identificados os agentes nocivos aos quais o trabalhador está exposto. Deve também ser declarada a existência de EPC instalados, bem como os EPI disponibilizados. A informação relativa aos EPIs não substitui a obrigatoriedade do registro de entrega destes equipamentos conforme disposição normativa.

Importante esclarecer que nos eventos acima elencados é constituído o histórico das exposições a agentes nocivos para fins de aposentadoria especial, sendo que a declaração relativa ao adicional para o financiamento da aposentadoria especial é feita quando informado o grau de exposição no evento S-1200, utilizando-se dos códigos previstos na “Tabela 02 - Financiamento da Aposent. Especial e Redução do Tempo de Contrib. do eSocial”.

Destaca-se que a “Tabela 24 – Agentes Nocivos e Atividades - Aposentadoria Especial”, inclui somente os agentes nocivos e atividades elencados no anexo IV do Decreto nº. 3.048, de 1999.

Ressalta-se ainda que, para os estagiários, não é obrigatório o envio dos eventos de SST.

As informações são obrigatórias só para segurados vinculados ao RGPS, mas é possível a informação relativa a servidores vinculados a RPPS, para fins de cumprimento do que dispõe a Nota Técnica 2/2014/CGNAL/DRPSP/SPPS/MPS.

Resumo da obrigatoriedade de envio das informações de SST, por categoria:

CategoriaS-2210S-2220S-2240
1XX Obrigatório Obrigatório Obrigatório
2XX Obrigatório Obrigatório Obrigatório
3XX Obrigatório, emrelação a servidores vinculados ao RGPS. Facultativo em relação aos demais Facultativo Obrigatório, emrelação a servidores vinculados ao RGPS. Facultativo em relação aos demais
4XX Facultativo Facultativo Facultativo
701 a 781, exceto 731a 738 Facultativo Facultativo Facultativo
731 a 738 Facultativo Facultativo Obrigatório
9XX Facultativo Facultativo Facultativo

19.1. Eventos de SST no âmbito dos órgãos públicos

As regras acima explicitadas são gerais, no entanto, no caso dos órgãos públicos, algumas particularidades devem ser observadas, pois existem diferentes modalidades de contratação e de Regimes de Previdência coexistindo em um mesmo período, motivo pelo qual esses contribuintes devem atender às seguintes regras:

  • Órgão público que contrata pelas regras da CLT (emprego público) e que, consequentemente, possui empregados vinculados ao RGPS: nessa hipótese o envio de todas as informações de segurança e saúde no trabalho é obrigatório;
  • Órgão público no qual seus servidores, embora sejam estatutários, encontram-se vinculados ao RGPS: devem ser enviados todos os eventos de SST, exceto o evento S-2220;
  • Órgão público que instituiu RPPS, mas possua servidores obrigatoriamente vinculados ao RGPS: nesse caso aplica-se a mesma regra de obrigatoriedade do item anterior.
  • Órgão público cujos  servidores  estatutários  estejam  vinculados  a  um  RPPS:  não  há obrigatoriedade de envio dos eventos de SST.

As  regras elencadas nos  itens acima  aplicam-se  aos servidores conforme  o seu  regime  de contratação (ex.: celetista ou estatutário) e o seu regime de previdência (RGPS ou RPPS), sendo que diferentes regimes e combinações podem coexistir em um mesmo órgão público. Assim, para conhecer a regra de obrigatoriedade do envio dos eventos de SST, deve ser analisado o regime de contratação e de previdência de cada servidor, e não do órgão como um todo.

Para exemplificar o acima exposto, podemos citar o caso de um órgão público que instituiu o Regime Estatutário e o RPPS e que possui 2 servidores em cargo em comissão sem vínculo efetivo, ou seja, vinculados ao RGPS. Nesse caso, somente é necessário enviar os eventos S-2210 e S-2240 desses dois servidores vinculados ao RGPS. Para os demais servidores, vinculados ao RPPS, não há obrigatoriedade de enviar os eventos de SST.

Tais especificidades existem, pois, o PPP e a CAT, obrigações previdenciárias/tributárias que são substituídas pelo eSocial, somente se aplicam para segurados vinculados ao RGPS.

20. Órgãos Públicos

Os órgãos públicos da administração direta e indireta (autárquica e fundacional) da União, Estados, Distrito Federal e Municípios podem prestar suas informações de forma descentralizada.

Nesse caso, cada órgão que corresponda a uma unidade administrativa dentro do ente federado responsável pode enviar suas próprias informações a partir de seus sistemas informatizados e utilizando-se de suas próprias estruturas de dados, seguindo o padrão definido nos leiautes do eSocial. Assim, cada unidade administrativa 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, deve ser indicado o identificador do EFR. Por exemplo, se a Secretaria de Finanças de um município prestar suas informações de forma autônoma, ela indica o EFR do município;

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 (naturezas jurídicas 101-5, 104-0,

107-4, 116-3 e 134-1), esses devem enviar suas informações no CNPJ (14 dígitos) de cada órgão ou unidade administrativa.

Se a opção for pelo envio centralizado, apenas um conjunto de tabelas pode ser utilizado para todas as informações.

Apesar de as empresas públicas e sociedades de economia mista, assim como suas subsidiárias, não fazerem parte do grupo 4 do eSocial, elas também são obrigadas ao envio dos eventos S-24XX quando tiverem a seu cargo o pagamento de benefícios não previdenciários de natureza indenizatória (Grupo 10 da Tabela 25 do eSocial).

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.

20.1 Cadastramento inicial de vínculos, beneficiários, benefícios e estágios

A partir do início da obrigatoriedade do envio dos eventos não periódicos ao eSocial, todo ente da administração pública direta, autárquica, fundacional e outros é obrigado a enviar as informações relativas aos vínculos empregatícios e estatutários (S-2200), a outros vínculos (S-2300), a estágios em curso (S-2300), bem como a beneficiários e benefícios previdenciários a cargo de regimes próprios, do Sistema de Proteção Social dos Militares e não previdenciários a cargo de entes da administração pública direta ou indireta (S-2400 e S-2410), vigentes no primeiro dia do início da obrigatoriedade desses eventos, constituindo o cadastramento inicial. Essas informações devem ser sempre enviadas com o campo {cadIni} preenchido com “S”.

Os vínculos de emprego e estatutários, trabalhistas, estágios e benefícios que tiverem findado antes dessa data não devem integrar o cadastramento inicial, salvo nos casos em que for necessária a informação de algum evento periódico, posterior a data de obrigatoriedade deste. Por exemplo, o vínculo estatutário foi extinto em setembro de 2021. A princípio esse vínculo não deve ser informado ao eSocial. Mas, se por exemplo, em julho de 2022, depois do início da obrigatoriedade do envio dos eventos periódicos, o órgão público tem de informar valores de diferenças de vencimentos retroativos ao período de julho de 2020 a setembro de 2021, o órgão público tem de enviar o cadastramento inicial desse servidor, com o campo relativo a data do desligamento devidamente preenchido.

O prazo para envio do cadastramento inicial dos vínculos, estágios e benefícios, é o dia anterior ao início da obrigatoriedade dos eventos periódicos. Ressalte-se que embora haja esse prazo, as informações prestadas devem retratar a situação existente no dia do início da obrigatoriedade do envio dos eventos não periódicos e não a do dia do envio das informações. Eventuais alterações cadastrais ou contratuais ocorridas entre essas duas datas devem ser retratadas por meio do envio dos correspondentes eventos de alteração (S-2205, S-2206, S-2306, S-2406 ou S-2416). O mesmo procedimento deve ser observado em relação a afastamentos temporários, cessões, desligamentos ou términos, os quais devem ser retratados por meio do envio dos correspondentes eventos (S-2230, S-2231, S-2299, S-2399 ou S-2420).

Exemplos:

1) Um servidor estatutário tem vínculo ativo no dia 22/11/2021. Em 01/02/2022, o servidor passou a ter direito de receber abono de permanência. O órgão público enviou o S-2200 com o cadastramento inicial deste servidor em 01/03/2022. Neste evento, o campo relativo ao recebimento de abono de permanência deve preenchido com “N”, pois essa era a situação do servidor no dia

22/11/2021. O órgão público deve enviar um evento S-2206 com data de alteração em 01/02/2022 com o campo relativo ao recebimento de abono de permanência preenchido com “S”.

2) Um beneficiário tem direito a pensão por morte e esse benefício está ativo no dia 22/11/2021. Em 15/02/2022, esse beneficiário foi a óbito, sendo que até então o órgão público ainda não havia enviado os eventos S-2400 e S-2410 relativos ao benefício devido ao falecido. Mesmo assim, o órgão público deve enviar os eventos S-2400 e S-2410 retratando as condições existentes no dia 22/11/2021 e, também, o evento 2420, para informar a cessação do benefício.

3) Em 20/01/2022, termina a cessão de um trabalhador cedido por outro órgão desde 01/2019. O  cessionário  ainda  não  havia enviado  o evento  S-2300  relativo ao cadastramento  inicial desse trabalhador. Mesmo assim, o cessionário terá de enviar esse evento com as informações vigentes em

22/11/2011 e, também, o evento S-2399 com data do término em 20/01/2022.

4) O valor da bolsa de um estágio iniciado em 01/2021 foi alterado em 01/01/2022. Até então, o órgão público não havia encaminhado o evento S-2300 relativo ao cadastramento inicial desse estagiário.  Quando  o  órgão  for  enviá-lo  deve  fazê-lo  informando  o  valor  da  bolsa  vigente  em

22/11/2011. Deve ser enviado, também, o evento S-2306 com data de alteração em 01/01/2022, constando o valor atualizado da bolsa de estágio.

20.2 Prazo para envio de informações sobre vínculos, benefícios e estágios iniciados após o início da obrigatoriedade do envio dos eventos não periódicos e antes da obrigatoriedade do envio dos eventos periódicos

As informações relativas aos vínculos, benefícios ou estágios iniciados durante esse período devem ser sempre enviadas com o campo {cadIni} preenchido com “N”.

Com relação aos vínculos de emprego iniciados a partir do dia seguinte ao do início da obrigatoriedade do envio dos eventos não periódicos, o prazo de envio do evento S-2200 segue a regra geral aplicável a este evento, ou seja, o dia anterior ao do início da prestação dos serviços.

Em relação aos vínculos estatutários (S-2200), trabalhistas (S-2300), estágios (S-2300) e benefícios (S-2400 e S-2410) iniciados entre o dia seguinte ao do início da obrigatoriedade do envio dos eventos não periódicos e o último dia do mês anterior ao do início da obrigatoriedade do envio dos eventos periódicos, as informações devem ser enviadas até o dia anterior ao início da obrigatoriedade dos eventos periódicos. Ocorrendo mais de um evento não periódico nesse lapso temporal, esses devem ser enviados observando-se o encadeamento cronológico.

Registre-se que as informações prestadas devem retratar a situação existente no dia do início do vínculo, do benefício ou do estágio e não a do dia do envio das informações. Eventuais alterações cadastrais ou contratuais ocorridas entre essas duas datas devem ser retratadas por meio do envio dos correspondentes eventos de alteração (S-2205, S-2206, S-2306, S-2406 ou S-2416). O mesmo procedimento deve ser observado em relação a afastamentos temporários, cessões, desligamentos ou términos, os quais devem ser retratados por meio do envio dos correspondentes eventos (S-2230, S-2231, S-2299, S-2399 ou S-2420).

Exemplos

1) Um servidor estatutário entrou em exercício no dia 01/12/2021. Em 15/01/2022, o servidor passou a residir em outro endereço. O órgão público enviou o S-2200 relativo a esse servidor em 01/02/2022. Neste evento, o endereço do servidor a ser informado deve ser o que ele possuía no dia da entrada em exercício. O órgão público deve enviar um evento S-2205 com data de alteração em 15/01/2022 com o novo endereço do servidor.

2) Um beneficiário passou a ter direito a uma aposentadoria do RPPS em 14/12/2021. Em 08/02/2022, esse benefício foi suspenso, sendo que o órgão público só enviou os eventos S-2400 e S-2410 relativos a esse benefício no dia 25/03/2022. Nesses eventos, não deve ser mencionada a ocorrência da suspensão do benefício. Tal suspensão deve ser retratada por meio do envio do evento S-2416, com indicação de data de alteração em 08/02/2022.

3) Um servidor estatutário entrou em exercício no dia 22/12/2021. Em 01/03/2022, o servidor foi cedido para outro órgão. O órgão público cedente enviou o S-2200 relativo a esse servidor em 23/02/2022. Neste evento, não deve ter o grupo [cessão] preenchido. O órgão público cedente deve enviar um evento S-2231 com data de início da cessão em 23/02/2022. Já o cessionário tem de enviar o evento S-2300 com data de início em 02/03/2022, observadaos os demais procedimentos em relação à cessão.

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.

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 na 2.5 ou na S-1.0, inclusive em um 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 e de retificação em ambas as versões durante o período de convivência, e, após 09/03/2022, somente na versão S-1.0.

Os eventos S-3000 serão permitidos em ambas as versões durante o período de convivência e somente na versão S-1.0 após o período de convivência.

A partir de 19/07/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:

Ref.Situação de convivênciaConvivê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 (19/07/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 06/2021 e somente até o dia 20/07/2021. As informações contempladas no S-1250 passam a ser enviadas pelo evento R-2055 na EFD-Reinf.

A  partir  de  21/07/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/07/2021   não   pode   ser   considerado   “convivência   de versões”, pois o evento R-2055 não integra o eSocial.

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 S1299 (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 informações de eventos S-1250 recebidos até 20/07/2021 continuam sendo consideradas para apuração e integração com a DCTFweb.

A adoção deste procedimento equivale a utilizar o S-3000 para excluir o S-1250, sendo a única forma de desconsiderar a informação a partir de 21/07/2021.

JUSTIFICATIVA: O envio das informações contempladas no S-1250, mesmo para {perApur} anterior a 07/2021, passa a ser exclusivamente através do evento R-2055 na EFD-Reinf - inclusive no caso de retificações que se fizerem necessárias. Contudo, tanto no caso de retificação de um S-1250 enviado, como no caso de necessidade da sua exclusão, o contribuinte precisa sinalizar que a apuração referente ao S-1250, efetivada no eSocial, e encaminhada para a DCTFweb, deve ser desconsiderada – pois a DCTFweb não aceitará uma apuração para determinado {perApur} e CR, originária do R-2055, se já existir para o mesmo {perApur} e CR apuração já encaminhada pelo S-1250. Seria uma quebra na integridade.

5 Eventos periódicos de empregador segurado especial

Eventos    periódicos    de    empregador    segurado    especial (classificação   tributária   igual   a   22)   somente   devem   ser enviados por Web Service na versão S-1.0, o que ocorrerá a partir do Período de Apuração em que DCTFWeb passa a ser obrigatória para os empregadores pessoas físicas em substituição à GFIP (data a ser definida pela RFB). JUSTIFICATIVA: Os empregadores pessoas físicas (PF) estão no Grupo 3, cuja obrigatoriedade no envio de eventos periódicos coincide com a implantação da versão S-1.0. Porém o empregador doméstico, também PF, já envia eventos ao eSocial desde 2015. Foi identificada uma situação para as PF: um mesmo empregador remunera trabalhador doméstico e também se enquadra na obrigatoriedade do grupo 3 (como contribuinte individual equiparado a empresa, empregador rural, etc).

A peculiaridade desta situação é que empregadores domésticos e segurados especiais por legislação específica recolhem no documento de arrecadação DAE, enquanto as PF fora desta situação recolhem por DARF. A solução de sistema para a situação apontada está na versão S-1.0. O empregador segurado especial poderá utilizar o mesmo módulo simplificado disponível para o Doméstico para envio de eventos periódicos, a partir do Período de Apuração em que DCTFWeb passa a ser obrigatória para os empregadores pessoas físicas em substituição à GFIP (data a ser definida pela RFB).

6 S-2190 e S-2200

O evento S-2200 original (indRetif=1) deve ser enviado na mesma versão do leiaute que o evento S-2190 do respectivo vínculo.

JUSTIFICATIVA:  O  evento  S-2190,  na  versão  S-1.0,  recebe

informações adicionais que não constavam na versão 2.5. Estas informações permitem que algumas validações sistêmicas se baseiem apenas no S-2190, assim sendo é necessário manter a versão nos dois eventos sob pena de comprometer os interrelacionamentos previstos no eSocial.

7 S-2190 e S-1200

Se um evento S-1200 da versão S-1.0 se referir a um vínculo para o qual foi enviado apenas o S-2190 (sem o S-2200/S-2300 que o complementa), o evento S-2190 deve ter sido enviado também na versão S-1.0.

JUSTIFICATIVA: O evento S-2190, na versão S-1.0, recebe informações adicionais que não constavam na versão 2.5. São estas informações que permitem que algumas validações do S1200 aceitem o S-2190 prescindindo do evento complementar S2200/S-2300.

8 Eventos de SST

Os eventos de SST (S-2210, S-2220 e S-2240) somente devem ser enviados na versão S-1.0.

JUSTIFICATIVA: Os eventos em questão nunca foram enviados na versão 2.5. Além disso, sofreram simplificações estruturais importantes. Assim sendo, é inviável o envio destes eventos na versão 2.5.

9 Eventos referentes ao grupo 4 (órgãos públicos e organizações internacionais)

Os eventos referentes ao grupo 4 (órgãos públicos e organizações internacionais) somente devem ser enviados na versão S-1.0.

JUSTIFICATIVA: Os eventos em questão nunca foram enviados na versão 2.5. Além disso, sofreram alterações importantes para a versão S-1.0. Assim sendo, é inviável o envio destes eventos na versão 2.5.

10 Tabela de Natureza Jurídica(Tabela 21 na versão 2.5)

Aplicável somente na versão 2.5.

JUSTIFICATIVA: Como a versão S-1.0 busca esta informação no cadastro da RFB, prescinde desta tabela.

11 Tabela 21 - Códigos de IncidênciaTributária da Rubrica para o IRRF

Aplicável somente versão S-1.0.

JUSTIFICATIVA: Na versão 2.5 a relação de {codIncIRRF} aceitos consta na descrição do próprio campo no evento S-1010.

12 Tabela 23 – Relacionamento entre Tipo de Valor do FGTS, Categoria, Origem, Código de Incidência do FGTS e Condição

Aplicável somente na versão S-1.0

JUSTIFICATIVA: Na versão 2.5 a validação deste relacionamento consta na própria descrição dos campos {remFGTS} e {remFGTSE} do evento S-5003.

13 Tabelas do empregador descontinuadas na versão S-1.0

As tabelas S-1030, S-1040, S-1050 e S-1080 somente poderão ser excluídas na versão 2.5.

JUSTIFICATIVA: Como a exclusão em tabelas se dá com o envio do próprio evento, e este foi descontinuado, não haverá como efetuar esta exclusão na versão S-1.0.

14 Tabela S-1080 x Tabela S-1020 (informações referentes ao Operador Portuário)

As informações referentes ao operador portuário, que eram enviadas na tabela S-1080 da versão 2.5, passaram a ser contempladas no  grupo  dadosOpPort  da  tabela S-1020  na versão S-1.0.

As validações e relacionamentos destas informações, no período de convivência, terão o seguinte comportamento:

A versão do S-1280 (2.5 ou S-1.0) indicará qual tabela será referenciada S-1080 (se 2.5) ou S-1020 (se S-1.0); nos casos em que o S-1280 não foi enviado, se houver informação ativa para o   período   tanto   no   S-1080   quanto   no   S-1020   v.S-1.0, preponderará  a  informação  de  tabela  constante  no  grupo dadosOpPort do S1020 v.S-1.0.

Havendo informação de Operador Portuário no S-1280 (grupo infoSubstPatrOpPort), o S-1280 e o S-1299 devem estar na mesma versão.

JUSTIFICATIVA: Com a mudança na estrutura da informação, referenciada no S-1080 pelo CNPJ do operador portuário e no S1020 pelo código da lotação, os relacionamentos e validações devem ser compatíveis com o respectivo modelo.

15 Eventos extemporâneos e de retificação

A partir de 19/07/2021, serão desabilitadas as regras de validação do NIS no RET (independentemente de os eventos serem ou não extemporâneos).

JUSTIFICATIVA: A decisão de não mais validar o NIS na versão S1.0 foi estendida à versão 2.5 durante o período de convivência.

16 Exclusão de eventos

Será possível excluir os eventos S-1300, S-2250 e S-2260 na versão S-1.0. A partir de 19/07/2021, serão desabilitadas as regras relativas ao NIS do evento S-3000 da versão 2.5. JUSTIFICATIVA: A decisão de não mais validar o NIS na versão S1.0  foi  estendida  à  versão  2.5  durante  o  período  de convivência.

22. Lista de siglas

ASO Atestado de Saúde Ocupacional
Bacen Banco Central do Brasil
CA Certificado de Aprovação
CAEPF Cadastro de Atividades Econômicas da Pessoa Física
CAIXA Caixa Econômica Federal
CAT Comunicação de Acidente de Trabalho
CEBAS Certificado de Entidade Beneficente de Assistência Social
CEI Cadastro Especial Individual
CLT Consolidação das Leis do Trabalho
CNAE Classificação Nacional de Atividades Econômicas
CND Certidão Negativa de Débitos
CNIS Cadastro Nacional de Informações Sociais
CNO Cadastro Nacional de Obras
CNPJ Cadastro Nacional de Pessoas Jurídicas
CP Contribuição Previdenciária
CPF Cadastro de Pessoas Físicas
CQC Consulta Qualificação Cadastral
CTN Código Tributário Nacional
CVM Comissão de Valores Mobiliários
DAE Documento de Arrecadação do eSocial
DCTFWeb Declaração de Débitos e Créditos Tributários Federais Previdenciários e de Outras Entidades e Fundos
DIRF Declaração do Imposto de Renda Retido na Fonte
DIRPF Declaração do Imposto de Renda Pessoa Física
EBAS Entidade Beneficente de Assistência Social
EFD-Reinf Escrituração Fiscal Digital de Retenções e Outras Informações Fiscais
EFR Ente Federativo Responsável
EPP Empresa de Pequeno Porte
EPC Equipamento de Proteção Coletiva
EPI Equipamento de Proteção Individual
eSocial Sistema Simplificado de Escrituração Digital das Obrigações Previdenciárias, Trabalhistas e Fiscais
FAPI Fundo de Aposentadoria Programada Individual
FAP Fator Acidentário de Prevenção
FPAS Fundo da Previdência e Assistência Social
GFIP Guia de Recolhimento do FGTS e de Informações à Previdência Social
GILRAT Grau de Incidência de Incapacidade Laborativa decorrente dos Riscos Ambientais do Trabalho
IBGE Instituto Brasileiro de Geografia e Estatística
ICP-Brasil Infraestrutura de Chaves Públicas Brasileira
IR Imposto de Renda
IRRF Imposto de Renda Retido na Fonte
ISS Imposto sobre Serviços
LTCAT Laudo Técnico de Condições Ambientais de Trabalho
ME Microempresas
MEI Microempreendedor Individual
MOS Manual de Orientação do eSocial
MTE Ministério do Trabalho e Emprego
NR Norga Regulamentadora
NTEP Nexo Técnico Epidemiológico Previdenciário
OGMO Órgao Gestor de Mão de Obra
PASEP Programa de Formação do Patrimônio do Servidor Público
PCMSO Programa de Controle Médico e Saúde Ocupacional
PGD Programa offline Gerador de Declaração
PIS Programa de Integração Social
PPP Perfil Profissiográfico Previdenciário
PPRA Programa de Prevenção de Riscos Ambientais
PVA Programa Validador e Assinador
RET Registro de Eventos Trabalhistas
RFB Receita Federal do Brasil
RGPS Regime Geral de Previdência Social
RPPS Regime Próprio de Previdência Social
SAL Sistema de Acréscimos Legais
SENAC Serviço Nacional de Aprendizagem Comercial
SENAI Serviço Nacional de Aprendizagem Industrial
SENAR Serviço Nacional de Aprendizagem Rural
SENAT Serviço Nacional de Aprendizagem do Transporte
SEPRT Secretaria Especial de Previdência e Trabalho
SESC Serviço Social do Comércio
SESI Serviço Social da Indústria
SEST Serviço Social do Transporte
SST Segurança e Saude no Trabalho
TSVE Trabalhador Sem Vínculo de Emprego/Estatutário

Informação

DP Objetivo foi criado com o objetivo de auxiliar contadores, advogados, profissionais da classe e dentre outros na esfera trabalhista com o intuito de ser um site simples e objetivo.

Fica autorizada a divulgação e publicação de qualquer conteúdo deste site desde que não sejam para fins comerciais e sejam citadas as fontes.

Os conteúdos deste site não substituem ou dispensam a consulta a um profissional especializado.

Fale conosco

Email: contato@dpobjetivo.com.br

Contato para parcerias, dúvidas, sujestões, anúncio e demais outros assuntos.