Notícia eSocial: Nota Técnica 12/2019 corrige erros em eventos de SST -
Metadados

Notícia eSocial: Nota Técnica 12/2019 corrige erros em eventos de SST

O Comitê Gestor do eSocial publicou no dia 21 de março de 2019 a Nota Técnica nº 12/2019 que traz correções de erros em eventos de Saúde e Segurança do Trabalho (SST), além de ajustes referentes às informações do evento S-1210 e ao fechamento de folha de empregador pessoa física que possui empregados domésticos.

Segundo informações do próprio Comitê, os erros em eventos de SST foram identificados e informados pelas empresas ao realizarem testes nos eventos no ambiente de Produção Restrita, além de outros constatados pela equipe técnica do eSocial.

Você já sabe quais são esses ajustes e quais os impactos no envio das informações? Confira o artigo, produzido pela Metadados — empresa que desenvolve Sistema de RH — e entenda tudo!

Ajustes na versão 2.5 do layout

Antes de elencarmos os ajustes trazidos pela NT 12/2019, é importante destacar quais são os eventos de SST no eSocial. Confira:

  • S-1060 – Tabela de Ambientes de Trabalho
  • S-2240 – Condições Ambientais do Trabalho – Fatores de Risco
  • S-2220 – Monitoramento da Saúde do Trabalhador
  • S-2221 – Exame Toxicológico do Motorista Profissional
  • S-2245 – Treinamentos, Capacitações e Exercícios Simulados
  • S-2210 – Comunicação de Acidentes de Trabalho

Destes seis eventos que compõem o SST no eSocial, praticamente todos devem receber os ajustes. Entenda o que mudou e cada um deles:

S-1060

No campo {codLotacao}, passou DE “Informar o código atribuído pela empresa para a lotação tributária. Validação: Preenchimento obrigatório e exclusivo se {localAmb} = [2]. Se informado, deve ser um código existente em S-1020 – Tabela de Lotações Tributárias”, PARA “Se informado, deve ser um código existente em S-1020 – Tabela de Lotações Tributárias com o campo {tpLotacao} = [03,04,05,06,07,08,09]”.

Motivo: Restringir o preenchimento do campo no caso de {localAmb} = [2] para as lotações tributárias do evento S-1020 definidas com os tipos 3 a 9.

• S- 1210

No campo {detPgatoF1/perRef}, passou DE “Informar a competência à qual se refere a folha de pagamento no formato AAAA-MM, se for relativa a folha de pagamento normal (mensal, quinzenal, etc.) ou AAAA, se for relativa a folha de 13° salário. Validação: Informação obrigatória se {tpPgto} = [1,5]. Não pode haver informação nos demais casos. Deve estar no formato AAAA-MM ou AAAA”, PARA “Informar a competência declarada no campo {perApur} do evento remuneratório a que se refere o pagamento, no formato AAAA-MM, se for relativa a folha de pagamento normal…”

Motivo: Alteração de redação para dirimir dúvidas.

• S-2210

Este evento foi o que mais teve mudanças: seis, ao todo. Confira cada uma delas.

  • No campo {codSitGeradora}, passou DE “Preencher com o código da situação geradora do acidente, conforme Tabela 16. Validação: Deve ser um código existente na Tabela 16 – Situação Geradora do Acidente de Trabalho”, PARA “Preencher com o código da situação geradora do acidente ou da doença profissional, conforme Tabelas 15 ou 16. Validação: Deve ser um código existente na Tabela 15 – Agente Causador / Situação Geradora de Doença Profissional ou na Tabela 16 – Situação Geradora do Acidente de Trabalho”.

Motivo: A tabela 15 também apresenta situações geradoras de doença profissional, podendo ser necessária para o preenchimento do campo.

  • No campo {indCatObito}, passou DE “Houve Óbito? S – Sim; N – Não. Validação: Se o {tpCat} for igual a [3], o campo deverá sempre ser preenchido com [S]. Valores Válidos: S, N”, PARA “Houve Óbito? S – Sim; N – Não. Validação: Se o {tpCat} for igual a [3], o campo deverá sempre ser preenchido com [S]. Se o {tpCat} for igual a [2], o campo deverá sempre ser preenchido com [N]. Valores Válidos: S, N”.

Motivo: Impedir informação inconsistente. Tipo de CAT = [2] é incompatível com a informação de que houve óbito.

  • No campo {dtAcid}, passou DE “Data do Acidente. Validação: Deve ser uma data válida, igual ou anterior à data atual e igual ou posterior à data de admissão do trabalhador e à data de início da obrigatoriedade deste evento para o empregador no eSocial”, PARA “Data do Acidente. Validação: Deve ser uma data válida, igual ou anterior à data atual e igual ou posterior à data de admissão do trabalhador e à data de início da obrigatoriedade deste evento para o empregador no eSocial. Se {tpCat} = [2,3] deve ser informado valor igual ao preenchido no evento de CAT anterior, quando informado em {nrRecCatOrig}”.
  • No campo {hrAcid}, passou DE “Hora do Acidente, no formato HHMM. Validação: Preenchimento obrigatório se {tpAcid} <> [2.0.01, 2.0.02, 2.0.03, 2.0.04, 2.0.05, 2.0.06, 4.0.01, 4.0.02]. Se informada, deve estar no intervalo entre [0000] e [2359], criticando inclusive a segunda parte do número, que indica os minutos, que deve ser menor ou igual a 59, PARA “Hora do Acidente, no formato HHMM. Validação: Preenchimento obrigatório se {tpAcid} <> [2.0.01, 2.0.02, 2.0.03, 2.0.04, 2.0.05, 2.0.06, 4.0.01, 4.0.02]. Se informada, deve estar no intervalo entre [0000] e [2359], criticando inclusive a segunda parte do número, que indica os minutos, que deve ser menor ou igual a 59. Se {tpCat} = [2,3] deve ser informado valor igual ao preenchido no evento de CAT anterior, quando informado em {nrRecCatOrig}”.

Motivos: Criada validação para exigir que a data e hora do acidente informada na CAT de reabertura e de comunicação de óbito seja igual à da CAT inicial, haja vista ser essa a orientação de preenchimento do campo para evitar inconsistências.

  • No campo {indAfast}, passou DE “Indicativo de afastamento do trabalho durante o tratamento: S – Sim; N – Não. Valores Válidos: S, N”, PARA “Indicativo de afastamento do trabalho durante o tratamento: S – Sim; N – Não. Valores Válidos: S, N. Validação: Se o campo {indCatObito} for igual a [S], o campo deve sempre ser preenchido com [N]”.

Motivo: Em caso de óbito não é possível haver indicativo de afastamento do trabalho preenchido com o valor [S].

  • No campo {nrRecCatOrig}, passou DE “Ocorrência: 1 – 1 Informar o número do recibo da última CAT referente ao mesmo acidente/doença relacionada ao trabalho, nos casos: a) de CAT de reabertura; b) de óbito, quando houver CAT anterior. Validação: Deve corresponder ao número do recibo do arquivo relativo à CAT informada anteriormente, pertencente ao mesmo trabalhador”, PARA “ Ocorrência: 1 – 1 Informar o número do recibo da última CAT referente ao mesmo acidente/doença relacionada ao trabalho, nos casos: a) de CAT de reabertura; b) de óbito, quando houver CAT anterior. Validação: Deve corresponder ao número do recibo do arquivo relativo à CAT informada anteriormente, pertencente ao mesmo trabalhador. A validação não deve ser realizada quando {dtAcid} for anterior a data de transferência no evento de admissão”.

Motivo: Exclusão da validação do número do recibo para os casos em que houver sucessão e a sucessora tenha que enviar reabertura ou comunicação de óbito de CAT enviada anteriormente pela sucedida

• S-2220

  • No Grupo {exame}, passou DE “Registro que detalha as avaliações clínicas e os exames complementares porventura realizados pelo trabalhador em virtude do determinado nos Quadros I e II da NR7 do MTb, além de outros solicitados pelo médico e os referentes ao ASO. O não preenchimento sinaliza a não realização de avaliações clínicas ou exames complementares”, PARA “Registro que detalha as avaliações clínicas e os exames complementares porventura realizados pelo trabalhador em virtude do determinado nos Quadros I e II da NR7 do MTb, além de outros solicitados pelo médico e os referentes ao ASO”, retirando a última frase.

Motivo:  Item 9: Correção de erro: o grupo é de preenchimento obrigatório, motivo pelo qual não há possibilidade de não preenchimento.

  • No campo {tpExameOcup}, passou DE Tipo do exame médico ocupacional, conforme opções abaixo: 0 – Exame médico admissional; 1 – Exame médico periódico, conforme NR7 do MTb e/ou planejamento do PCMSO; 2 – Exame médico de retorno ao trabalho; 3 – Exame médico de mudança de função; 4 – Exame médico de monitoração pontual, não enquadrado nos demais casos; 9 – Exame médico demissional. Valores Válidos: 0, 1, 2, 3, 4, 9”, PARA “Tipo do exame médico ocupacional, conforme opções abaixo: 0 – Exame médico admissional; 1 – Exame médico periódico, conforme NR7 do MTb e/ou planejamento do PCMSO; 2 – Exame médico de retorno ao trabalho; 3 – Exame médico de mudança de função; 4 – Exame médico de monitoração pontual, não enquadrado nos demais casos; 9 – Exame médico demissional. Valores Válidos: 0, 1, 2, 3, 4, 9. Validação: Se informado [0], não pode existir outro evento S-2220 para o mesmo vínculo com {dtAso} anterior.

Motivo: Impedir que seja enviado ASO admissional com data de realização posterior à da realização de outros tipos de ASOs.

S-2240

  • No Grupo {fatRisco} foi criado o novo campo {dscFatRisc}. Elem: E / Tipo: C / Ocorr: 0-1 / Tam: 999 /Dec:- Descrição do fator de risco. Preenchimento obrigatório e exclusivo se {codFatRis} = [01.01.999, 02.01.999, 03.01.999, 04.01.999, 04.02.999, 04.03.999, 04.04.999, 04.05.999, 05.01.999].

Motivo: Permitir a utilização, mais de uma vez, dos códigos referentes a fatores de risco definidos na tabela como “outros”.

  • No campo {aposentEsp}, passou DE “A exposição ao fator de risco/execução da atividade enseja recolhimento do adicional para o financiamento da aposentadoria especial? S – Sim; N – Não. Validação: Preenchimento obrigatório caso uma das situações abaixo seja atendida: a) Se o campo {matricula} for informado, referente a trabalhador com {tpRegPrev} = [1], exceto se {codCateg} = [104]; ou b) Se {codCateg} = [201,202,731,734,738]. Valores Válidos: S, N”, PARA “A exposição ao fator de risco/execução da atividade enseja recolhimento do adicional para o financiamento da aposentadoria especial? S – Sim; N – Não. Validação: Preenchimento obrigatório e exclusivo caso uma das situações abaixo seja atendida: a) Se o campo {matricula} for informado, referente a trabalhador com {tpRegPrev} = [1], exceto se {codCateg} = [104]; ou b) Se {codCateg} = [201,202,731,734,738]. Valores Válidos: S, N”.

Motivo: Os campos devem ser preenchidos exclusivamente para as categorias descritas.

• S-2245 

  • No campo{CpfProf}, passou DE “Preencher com o CPF do profissional responsável pelo treinamento/capacitação/exercício simulado. Validação: Preenchimento obrigatório se {nacProf} = [1]. Se informado, deve ser um CPF válido”, PARA “Preencher com o CPF do profissional responsável pelo treinamento/capacitação/exercício simulado. Validação: Preenchimento obrigatório se {nacProf} = [1]. Se informado, deve ser um CPF válido e diferente do informado em {cpfTrab}”.

Motivo: Impedir que o profissional que oferece o curso e o empregado que realiza o curso sejam a mesma pessoa.

  • No campo {dtTreiCap}, passou DE “Informar a data de início do treinamento/capacitação/autorização/exercício simulado ou a data de início da obrigatoriedade deste evento para o empregador no eSocial, a que for mais recente. Validação: Deve ser uma data válida, igual ou anterior à data atual e igual ou posterior à data de admissão do vínculo a que se refere. Não pode ser anterior à data de início da obrigatoriedade deste evento para o empregador no eSocial”, PARA “Informar a data de início do treinamento/capacitação/autorização/exercício simulado ou a data de início da obrigatoriedade deste evento para o empregador no eSocial, a que for mais recente. Validação: Deve ser uma data válida, igual ou anterior à data atual e igual ou posterior à data de admissão do vínculo a que se refere. Não pode ser anterior à data de início da obrigatoriedade deste evento para o empregador no eSocial. Se {indTreinAnt} = [S], a data deve ser igual à data de admissão do vínculo”.
  • No grupo {infoComplem}, foi criado um novo campo denominado {indTreinAnt}. Indicar se o treinamento ocorreu antes da admissão, em outro empregador: S – Sim; N – Não. Valores Válidos: S, N.

Motivo: Em algumas hipóteses previstas na legislação o treinamento/capacitação/exercício simulado pode ser realizado em data anterior à admissão.

  • Nos campos {durTreiCap}, {modTreiCap},{tpTrei Cap} foi alterada a ocorrência e incluída a validação, passando DE “0-1 Validação: O campo não deve ser preenchido se {codTreiCap} for igual a [1006,1207]. O preenchimento é obrigatório nos demais casos”, PARA 0-1 Validação: O campo não deve ser preenchido se {codTreiCap} for igual a [1006, 1207, 3719]. O preenchimento é obrigatório nos demais casos”.
  • No grupo {ideProfResp} foram alteradas ocorrência, chave e condição, passando DE “0-99 Chave: nmProf N (se {codTreiCap} = [1006,1207]); O (nas demais situações)”, PARA “0-99 Chave: nmProf N (se {codTreiCap} = [1006,1207, 3719]); O (nas demais situações).

Motivos: Incluir nas validações o código de registro obrigatório de Operador de Guindar

Regras

A Nota Técnica traz ainda a criação de regra em REGRA_EVENTO_POSTE RIOR_CAT_OBITO – Não deve existir qualquer evento não periódico para o vínculo indicado no evento de CAT com {indCatObito}=[S] com data de ocorrência posterior a {dtObito}. Também não deve existir qualquer evento periódico para o vínculo indicado no evento com período de apuração que compreenda ou seja posterior a {dtObito}. As exceções a essa regra se restringem a alguns tipos de remuneração (S-1200), conforme definidos na REGRA_REMUN_JA_EXISTE_DESLIGAMENTO, Pagamentos (S-1210), e Alteração Contratual (S-2206), quando {dtEf} desse evento for igual ou anterior a {dtObito}.

Motivo: Impedir o envio de eventos incompatíveis com a morte de um trabalhador com data posterior a seu falecimento informada em uma CAT com indicativo de óbito.

  • Na REGRA_VALIDA_FECHA MENTO_FOPAG, foi acrescido mais um subitem no item b, ficando: (…) b3) Para o fechamento da folha de pessoa física, empregador doméstico, em que todos os trabalhadores categoria [104] tenham remuneração enviada, não é necessário haver eventos de remuneração (S-1200) para trabalhadores com categoria diferente de [104] em período de apuração menor que o início da respectiva obrigatoriedade dos eventos periódicos. (…)

Motivo: Permitir que o empregador pessoa física que tenha empregados domésticos ativos consiga fechar a folha sem remuneração enviada para demais trabalhadores vinculados a CAEPF ou CNO.

Tabela 04

Na tabela 04, a mudança ocorreu no Código FPAS 612, excluindo o Código de Terceiros 0000, ficando: 0001, 0002, 0064, 1024, 2048 e 3139.

Motivo: adequar a tabela à nova validação do campo codTeres do evento S-1020.

Você pode conferir a Nota Técnica na íntegra aqui.

Datas em ambientes

Os eventos de SST estão disponíveis para testes em ambiente de Produção Restrita para todas as empresas desde o dia 18/03/2019. As datas previstas para a implantação das correções são:

  • Itens 1 a 8 (exceto 2) – 25/04/2019 – ambiente de Produção Restrita
  • Itens 1 a 18 (exceto 2) – 10/07/2019 – ambiente de Produção
  • Item 19 – 10/04/2019 – ambiente de Produção
  • Itens 2 e 20 – Implantação imediata

Procura segurança no eSocial?

O envio dos eventos de SST ao eSocial ocorre para o primeiro grupo apenas em julho de 2019, mas já é possível constatar a complexidade. Por isso, é necessário ter segurança nos processos; buscar interação entre os documentos e um gerenciamento adequado.

Aqui na Metadados, desenvolvemos um Sistema Gerenciador do eSocial para que os profissionais de RH tenham total segurança para executar os processos. Com eles as informações podem ser geradas de forma automática e transformadas em arquivos compatíveis com os exigidos pelo eSocial (XML), além de auditar campos e validar inconsistências. Conheça mais sobre ele aqui e tenha segurança no eSocial.