12. Datas
12.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 deverá 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.
12.2. Registro de data inicial do evento
Na implantação do eSocial existirão 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 INF EMPREGADOR, constante da Tabela de Regras do eSocial, determina que um evento somente pode ser recepcionado se existir informações cadastrais do empregador vigente para a data do evento, ou seja, a data do evento (ou período de apuração, no caso de evento “S-1200 – Remuneração de Trabalhador vinculado ao Regime Geral de Previdência Social” e no “S-1202 - Remuneração de servidor vinculado a Regime Próprio de Previdência Social” trabalhadores RPPS”) deve estar compreendida entre o {iniValid} e {fimValid} do evento S-1000 - Informações do Empregador/Contribuinte/Órgão Público.
No que tange ao campo início de validade {iniValid} do evento S-1000 – Informações do Empregador/Contribuinte/Órgão Público, deve-se observar a REGRA_INFO_EMP_VALIDA_DTINICIAL, que estabelece que o campo {iniValid} deverá ser sempre igual ou posterior à data de início das atividades da empresa e para os Órgãos Púbicos será 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 este empregador] ou, no caso do empregador 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 abaixo 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 este empregador = 01/01/2018.
Evento S-1000 - Informação do Empregador/Contribuinte/Órgão Público – 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 - Informação do Empregador/Contribuinte/Órgão Público – {iniValid} = 2018-05.
12.3. Data-início-validade e Data-fim-validade nas Tabelas
Todos os eventos de tabela do eSocial, S-1005 a S-1080, incluindo ainda o evento “S-1000 - Informações do Empregador/Contribuinte/Órgão Público”, 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 “guardarão um histórico” das informações transmitidas, vinculado ao respectivo “período de validade”.
A regra geral para estes 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 novo 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;
d) Exclusão: utilizada para excluir uma determinada ocorrência de uma tabela.
Identificador Tabela de Rubricas Início de Validade Fim de validade Incidência Contr. Previdenciária Incidê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
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.
Exemplos:
a) Para inserir uma rubrica 004 na tabela de rubricas, o empregador/contribuinte/órgão público deve utilizar o grupo inclusão;
b) Para o empregador/Órgão Público 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 empregador/Órgão Público 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 empregador/contribuinte/órgão público deve utilizar o subgrupo nova validade, do grupo alteração. Desta forma, o usuário 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 empregador/contribuinte/órgão público deve utilizar o subgrupo nova validade, do grupo alteração;
f) Para excluir a rubrica 003, o empregador/contribuinte/órgão público deve utilizar o grupo exclusão.
Todas as tabelas S-1005 a S-1080 devem estar com INÍCIO-VALIDADE maior ou igual à data de início da obrigatoriedade do eSocial para este empregador/contribuinte/órgão público ou, no caso de ele ter iniciado suas atividades posteriormente à obrigatoriedade de implantação do eSocial, a data de início de sua atividade ou mesmo a data do seu primeiro vínculo.
13. Retificações e Alterações
O procedimento ALTERAÇÃO das informações transmitidas ao eSocial ocorre somente nos eventos de Tabelas (S-1005 a S-1080) e no evento “S-1000 - Informações do Empregador/Contribuinte/Órgão Público”, 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 “alteração” nas informações transmitidas serão tratados pelo eSocial como procedimentos de RETIFICAÇÃO, ou mesmo de EXCLUSÃO. Esta questão será 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 empregador/contribuinte/órgão público encontra orientação quanto às repercussões de eventuais alterações.
13.1. Alterações de informações de tabelas
Como mencionado acima os eventos de tabelas do eSocial, S-1005 a S-1080 (incluindo ainda o evento S-1000 - Informações do Empregador/Contribuinte/Órgão Público/Órgão Público), possuem um atributo de vigência ou “Período de validade das informações” representado nos campos início de validade {iniValid} e {fimValid}.
Neste sentido, todos os eventos Tabelas possuem um grupo específico para as informações de alteração.
No procedimento de alteração dos eventos de Tabelas o empregador/contribuinte/órgão público transmitirá as informações preenchendo o grupo de campos relativos a “Alteração” (a identificação “Alteração” consta no grupo de registros PAI do leiaute das tabelas – ver Capítulo II, item 1.2, deste manual).
13.2. Alterações de informações transmitidas em eventos não periódicos específicos
Os eventos não periódicos, relacionados abaixo, têm como função a alteração de informações relevantes para determinado vínculo do trabalhador, devendo ser utilizados nessas situações específicas:
· S-2205 - Alteração de Dados Cadastrais do Trabalhador
· S-2206 - Alteração de Contrato de Trabalho
· S-2306 - Trabalhador Sem Vínculo de Emprego/Estatutário - Alteração Contratual
NOTA: Esses eventos de alteração, também não aceitam data futura, salvo se expressamente mencionado no próprio campo.
As alterações das informações dos eventos “S-2230 - Afastamento Temporário”, “S-2240 - Condições Ambientais do Trabalho - Fatores de Risco” e “S-2241 – Insalubridade, Periculosidade e
Aposentadoria Especial” deverão ser realizadas por meio do envio desses mesmos eventos com a nova informação, pois não há evento específico de alteração das informações constantes nesses eventos.
14. Retificações
As alterações de informações já transmitidas ao eSocial que não se enquadram nos itens 13.1 (Alterações de Informações de Tabelas) e 13.2 (Alterações transmitidas em eventos não periódicos específicos) são tratadas como RETIFICAÇÃO da informação já enviada.
O primeiro evento enviado com o campo indicação de retificação - {IndRetif} = 1 será 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 devolverá mensagem com alerta desta situação e o declarante deverá 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 – deverá enviar o evento que contempla a informação a ser retificada com o campo {indRetif} = 2, constando no campo número de recibo {nrRecibo} o número do recibo do arquivo originalmente enviado a ser retificado.
Se o evento “S-1299 - Fechamento dos Eventos Periódicos” 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-1280, para aquele período de apuração, o respectivo movimento deverá ser reaberto utilizando-se o evento “S-1298 - Reabertura dos Eventos Periódicos”, possibilitando o envio de retificações ou novos eventos referentes à remuneração dos segurados naquele período.
Enquanto o movimento estiver "aberto", o envio de um segundo evento do mesmo tipo para o mesmo período de apuração poderá ser efetuado mediante retificação. Ou seja, se a empresa enviou o primeiro evento “S-1200 – Remuneração de Trabalhador vinculado ao Regime Geral de Previdência Social” (caracterizando abertura de movimento), e antes do "encerramento" daquele período decide retificar o evento encaminhado, é necessário o reenvio do evento S-1200 com indicativo de retificação, indicando o número do recibo original.
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.
15. Tratamento das inconsistências geradas pelo envio extemporâneo de eventos:
O evento é considerado extemporâneo quando a data de seu envio for posterior à data de sua ocorrência e outro evento com data de ocorrência posterior já tiver sido recepcionado (no caso de evento periódico, considera-se como data de ocorrência seu período de apuração).
O envio de evento extemporâneo deve observar o que segue, conforme a regra “REGRA_EVENTOS_EXTEMP”:
a) O evento não periódico extemporâneo só será recepcionado após validação com os eventos não periódicos anteriores e com o primeiro posterior de cada tipo (ex.: primeiro afastamento posterior, primeira alteração cadastral, primeira alteração contratual, primeiro desligamento, primeira CAT, etc.);
b) Quando validada pela regra do item 'a', serão recepcionados apenas os eventos não periódicos extemporâneos que atenderem:
b.1) Às regras de validação do fechamento das folhas de todo o período afetado, cujo movimento já esteja fechado se o evento extemporâneo incluir trabalhador (ou ampliar no RET o seu período de contrato ativo);
b.2) Às regras REGRA_REMUN_JA_EXISTE_DESLIGAMENTO e REGRA_REMUN_TRAB_EXISTENTE_RET de todo o período afetado, se o evento extemporâneo excluir trabalhador (ou reduzir no RET o seu período de contrato ativo).
Período Afetado: Meses em que a alteração pode tornar as informações do RET incompatíveis com as regras de validação do fechamento da folha ou com as regras mencionadas no item b2). Exemplos: inclusão ou exclusão de evento de admissão, retificação de data de admissão, envio/retificação de evento de desligamento, etc.);
c) A retificação ou exclusão extemporânea de evento remuneratório (S-1200/S-1202/S-1207/S-2299/S-2399) que implique modificação do valor líquido de determinado demonstrativo exigirá a exclusão prévia do correspondente evento de pagamento S-1210, quando existente. Não se aplica esta regra no caso de pagamentos parciais (S-1210, campo {indPgtoTt} = [N]}.
Esta regra só entrará em vigor após 03/2018, nos termos de Nota Técnica a ser expedida pelo Comitê Gestor do eSocial.
15.1. Considerações sobre o tratamento da extemporaneidade no eSocial:
15.1.1. Coerência lógica de encadeamento de eventos.
A recepção dos eventos extemporâneos (assim considerados aqueles que se enquadram na definição da REGRA_EVENTOS_EXTEMP) 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 será rejeitado, desde que mantenha a coerência fática de encadeamento dos eventos.
Por exemplo: empregador que envia uma alteração contratual (S-2206) com aumento salarial para um empregado já demitido com data de ocorrência anterior ao desligamento. Esta alteração potencialmente torna equivocados os valores previamente lançados no evento de desligamento (S-2299), contudo, tal fato não traz qualquer incompatibilidade lógica entre os eventos e, por isso, ele será recepcionado.
Exemplo de envio extemporâneo de evento que será rejeitada por contrariar a coerência de encadeamento seqüencial 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.
15.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 permanecerão hígidas.
Por exemplo: a admissão de um empregado faz referência a um determinado item da tabela de cargos (S-1030). Quando o evento de admissão é enviado, o sistema verifica se a data de admissão está compreendida no período de validade daquele cargo, 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 cargo, a integridade referencial restaria violada e o evento recusado. O sistema realizará uma espécie de simulação de recepção dos eventos antes de sua efetiva acolhida e recusará aqueles que quebrarem a integridade inter-relacional de quaisquer outros eventos.
15.1.3. Re-aplicação da regra de fechamento da folha
Para a recepção de qualquer evento extemporâneo o sistema re-aplicará a regra de fechamento da folha (REGRA_VALIDA_FECHAMENTO_FOPAG) em todo o período potencialmente afetado por
aquele evento, caso a alteração proposta torne o movimento de determinado mês impossível de ser fechado, pela aplicação da regra citada, o evento será recusado.
Exemplo: Empregador envia afastamento por doença não relacionada ao trabalho pelo período de um mês e fecha a folha de pagamento sem enviar a remuneração (S-1200) deste trabalhador. O fechamento será aceito porque o sistema não exige o envio de remuneração para empregado com esse tipo de afastamento.
O envio extemporâneo de um evento de exclusão desse afastamento temporário seria recusado uma vez que ele tornaria o fechamento da folha daquela competência impossível sem o envio da remuneração para aquele trabalhador.
Nesse caso o empregador deveria reabrir a folha de pagamento afetada para efetuar a mudança pretendida. O novo fechamento da folha só será bem-sucedido após o envio da remuneração daquele trabalhador.
Fonte: Manual eSocial 2.4 - Março/2018
14/03/2018 09:24 | eSocial