Cada fato da relação de trabalho (admissão, afastamento, folha, pagamento, desligamento) vira um evento do eSocial. E todo evento, seja qual for o layout, percorre o mesmo ciclo de quatro fases. Entender esse ciclo é o que separa "o eSocial rejeitou, e agora?" de "sei exatamente o que corrigir e onde", porque o painel do eSocial deixa de ser uma caixa preta no momento em que se sabe em qual das quatro fases um problema pode acontecer.
Fase 1: gerar
O sistema monta o XML do evento a partir dos dados cadastrais e da folha. É aqui que a consistência do cadastro é testada: CBO, categoria do trabalhador, natureza da rubrica, dados do dependente, vínculo. Se falta ou está inconsistente, o problema aparece já na geração, antes de qualquer envio ao governo, o que é uma vantagem: um erro pego na geração custa só o tempo de corrigir o cadastro, sem gerar histórico de rejeição nenhum.
Fase 2: assinar
O XML precisa ser assinado digitalmente com um certificado válido. Na transmissão nativa, esse certificado é o do próprio sistema, amparado pela procuração eletrônica que a empresa outorgou no e-CAC. Sem procuração ativa, ou com certificado vencido, a assinatura falha e nada é transmitido, então o evento fica retido nessa fase até a procuração ser renovada ou o certificado ser atualizado, sem depender de o operador refazer um cadastro que já estava correto.
Fase 3: transmitir
O evento assinado é enviado ao ambiente do eSocial. O governo devolve um protocolo (o evento foi recebido para processamento) ou uma recusa imediata (o lote está malformado, a empresa não está habilitada). Essa recusa imediata é diferente de uma rejeição: ela acontece antes mesmo de o conteúdo do evento ser validado contra as regras de negócio, geralmente por um problema estrutural do envio em si, não do dado que ele carrega.
Fase 4: consultar o retorno
Depois de transmitido, o evento fica em processamento no eSocial. É preciso consultar o resultado, que vem em um de dois estados:
- Aceito: o evento entrou na base do governo. Aparece no painel como aceito, com o recibo, e a partir daí é considerado parte definitiva do histórico daquela competência.
- Rejeitado: o evento não passou nas regras de validação. Vem com um código e uma descrição do erro: qual campo, qual regra, qual valor esperado, o que evita ter que adivinhar o motivo a partir de uma mensagem genérica.
Rejeição quase sempre é dado de cadastro: um CPF de dependente inválido, uma data de admissão fora de faixa, uma rubrica sem incidência informada. A correção é no cadastro, não no evento em si; depois de corrigido, gera-se e transmite-se de novo, repetindo as quatro fases desde o início.
Erros comuns que aparecem como rejeição
Alguns problemas de cadastro se repetem entre as rejeições mais comuns do eSocial:
- CPF de dependente com dígito ou nome divergente da base da Receita. O eSocial valida o CPF do dependente contra o cadastro oficial, e uma pequena divergência de nome já é suficiente para rejeitar o evento.
- Data de admissão ou desligamento fora da faixa esperada. Datas retroativas além do prazo aceito, ou incoerentes com outro evento já aceito para o mesmo colaborador, costumam gerar rejeição imediata.
- Rubrica sem natureza ou incidência informada. Toda rubrica da folha precisa apontar para um código de natureza do eSocial, e uma rubrica criada sem essa referência trava o evento de folha inteiro, não só o colaborador daquela rubrica.
- CBO desatualizado ou incompatível com a categoria do trabalhador. Uma mudança de função sem atualizar o CBO correspondente pode passar despercebida na tela do colaborador e só aparecer como rejeição na hora de gerar o evento.
Esses quatro pontos têm algo em comum: nenhum deles é um problema do eSocial em si, e sim do cadastro que alimenta o evento. É por isso que a Fase 1, gerar, é o momento mais barato para corrigir um problema, e a Fase 4, consultar, é o momento mais caro, porque nesse ponto o evento já foi transmitido e a correção exige repetir o ciclo inteiro.
Por que presumir que passou é o hábito mais caro
Um evento transmitido não é, ainda, um evento aceito. Entre a fase 3 e a fase 4 existe uma janela de processamento, e é comum alguém acompanhar o envio, ver que não deu erro imediato, e seguir para a próxima tarefa presumindo que está tudo certo. O problema é que a confirmação real só vem na consulta, e uma rejeição que aparece ali, sem ninguém revisando, só é descoberta quando alguém tenta encerrar a competência ou quando chega uma notificação inesperada, dias ou semanas depois do envio original.
Os status no painel
Um painel de eSocial bem feito mostra, por competência, cada evento em um destes status: pendente (ainda não gerado), enviado (transmitido, aguardando retorno), aceito (com recibo) ou rejeitado (com o motivo). O encerramento da competência só deve liberar quando não há mais nada pendente nem rejeitado, o que funciona como uma segunda camada de proteção contra o hábito de presumir que tudo passou: se algo ainda está rejeitado, o sistema não deixa a competência seguir como se estivesse resolvida.
As quatro fases, de ponta a ponta
No ActaOne, o eSocial é nativo. Cada evento da competência aparece no painel com o status, e as ações de gerar, assinar, transmitir e consultar estão embutidas nos próprios modais de Ausências, Férias, Afastamentos, Exames e no fluxo de folha, sem exigir que o operador saia do contexto onde o evento nasceu para acompanhar o restante do ciclo. O encerramento da competência só libera quando o painel do eSocial não tem mais nada pendente, incluindo o S-1299 de fechamento. A assinatura usa o certificado do sistema, amparado pela procuração eletrônica outorgada no e-CAC.
Um evento não "dá certo" ou "dá errado". Ele passa por quatro fases, e cada rejeição vem com um motivo específico que aponta o campo a corrigir.
Transmitir e presumir que passou é o hábito que mais atrasa a descoberta de uma rejeição: ela só aparece na hora de fechar a competência, ou numa notificação que ninguém esperava. O antídoto é simples, mesmo que exija disciplina: acompanhar cada evento até o status "aceito", não parar em "enviado".