eSocial SST: como o sistema gera e controla os eventos S-2210, S-2220 e S-2240

Eventos de SST do eSocial automatizados

O eSocial SST reúne os eventos de Segurança e Saúde no Trabalho que a empresa presta ao eSocial. Na plataforma NR-01/SIGSSST, esses eventos são responsabilidade do módulo M21 — Integração com eSocial SST, cujo objetivo declarado é automatizar a geração dos eventos, a validação prévia, o acompanhamento de status, a guarda de recibos e o controle de retificações. Em vez de digitar o mesmo dado em dois lugares, a empresa registra o fato uma vez na rotina de SST e o evento é derivado dali.

O princípio é não redigitar. Cada evento nasce a partir do módulo que já é dono do dado — a fonte única de verdade, ou SSOT: o acidente registrado em Acidentes e Investigações (M06), a entrega de EPI no Controle de EPI (M13) e a exposição descrita no Inventário de Riscos Ocupacionais (M02). O M21 é dono apenas do que é seu: o evento eSocial em si — tipo, status, tentativas, número do recibo e código de erro —, além dos lotes e recibos e da trilha completa de envio e retificação.

S-2210 (CAT), S-2220 (saúde) e S-2240 (agentes nocivos)

O módulo cobre os três eventos de SST do eSocial. Cada evento é identificado por tipo, módulo de origem e ID da entidade de origem, e carrega ainda, em campos próprios, o prazo legal, o número do recibo e o código de erro:

• S-2210 — Comunicação de Acidente de Trabalho (CAT): registra o acidente de trabalho ou a doença ocupacional. É gerado a partir da ocorrência lançada em Acidentes e Investigações (M06).
• S-2220 — Monitoramento da Saúde do Trabalhador: consolida os dados de saúde ocupacional (ASO/PCMSO). Depende da recepção estruturada do laudo clínico e integra a evolução prevista do módulo.
• S-2240 — Condições Ambientais do Trabalho / Agentes Nocivos: descreve a exposição do trabalhador a agentes nocivos. É alimentado pelo Inventário de Riscos Ocupacionais (M02) e pelo Controle de EPI (M13).

Cada evento é único pela combinação de tipo, módulo de origem, entidade de origem e sequência de retificação. Essa regra de unicidade evita duplicidade e garante que o evento sempre aponte para o registro operacional que o originou — mesmo depois de sucessivas retificações.

Origem nos módulos M06 e M13/M02

O evento não nasce no M21: ele é derivado de um módulo operacional que já detém o dado. O campo de módulo de origem aceita M02 (inventário de riscos), M06 (acidentes e investigações), M13 (controle de EPI) e M20 (inspeções de segurança), de modo que o evento eSocial sempre carrega o vínculo com a sua fonte.

No caso do acidente, o fluxo é encadeado: do registro em Acidentes e Investigações (M06) para o evento S-2210 (CAT) no M21, que por sua vez alimenta ações corretivas (M03), a atualização de riscos (M02) e os indicadores (M10). Já o S-2240 é montado a partir das condições ambientais e dos agentes nocivos do inventário de riscos (M02) e das entregas registradas no controle de EPI (M13). Assim, a mesma informação percorre a cadeia — do risco à evidência — sem ser recontada.

Validação prévia e painel de status

Antes de qualquer envio, o M21 executa uma validação prévia de consistência sobre os dados mínimos do evento, reduzindo a chance de rejeição. O acompanhamento do dia a dia é feito por um painel de status que resume os eventos em quatro situações: Pendente, Enviado, Aceito e Rejeitado.

O ciclo de vida completo do evento tem seis estados — Pendente, Validado, Enviado, Aceito, Rejeitado e Retificação pendente. Cada transição tem efeito na cadeia: o prazo legal do evento é controlado e gera pendências e notificações no cronograma de SST (M09), e a mudança de status atualiza os indicadores (M10). O campo de prazo legal deixa explícito até quando o evento precisa ser transmitido, para que nenhum vencimento passe despercebido.

Recibos, protocolos e retificações

Todo envio guarda protocolo e recibo de processamento como evidência no módulo de Documentos e Evidências (M11); quando existe, o XML ou o lote também é arquivado ali. No próprio evento ficam registrados o número do recibo e, se houver, o código de erro retornado pelo eSocial — os dois campos que tornam qualquer resultado rastreável.

As retificações preservam o histórico. É uma regra dura da cadeia de dados: a retificação não pode apagar o histórico de tentativas. Cada correção gera uma nova sequência de retificação, e recibos e justificativas são mantidos como evidência. Com isso, a trilha do que foi enviado, rejeitado e corrigido permanece íntegra e auditável, sem sobrescrever o que já aconteceu.

Rejeição gera ação corretiva (M03)

Quando o eSocial rejeita um evento, o erro não fica solto. A mudança de status para Rejeitado dispara a criação (ou a sugestão) de uma ação corretiva no plano de ação (M03), sempre com referência ao código de erro e ao recibo. O prazo e a pendência entram no cronograma (M09) e o resultado alimenta os indicadores (M10), inclusive o de eventos eSocial rejeitados ou com prazo em risco.

Na prática, eSocial rejeitado deixa de ser um problema esquecido em uma caixa de e-mail e vira uma tarefa com responsável, prazo e evidência de correção — o mesmo tratamento que a plataforma dá a qualquer não conformidade da rotina de SST.