eSocial rejeitou o evento: leia a mensagem e o Anexo II | Alexandre Freire
Antes de alterar o XML: copie a mensagem completa, identifique o ambiente e localize a regra no Anexo II do leiaute usado. Uma rejeição do eSocial raramente se resolve chutando um campo; ela pede o cruzamento entre retorno, evento, versão e contexto.
A anatomia de uma rejeição
Um retorno útil tem pelo menos quatro pistas: o evento recebido, o identificador da mensagem, o campo ou grupo citado e a descrição da condição que falhou. Registre o XML enviado, a resposta, a data, o ambiente e o pacote de leiaute antes de reproduzir.
Não confunda uma indisponibilidade ou instabilidade do ambiente com erro de conteúdo. Se o mesmo XML falha apenas em um ambiente, compare endpoint, certificado, pacote e janela de implantação.
Mensagem × Anexo II × leiaute
A mensagem aponta o sintoma. O Anexo II explica a regra. O leiaute mostra os nomes, tipos e ocorrências disponíveis para o evento. A correção confiável aparece quando os três contam a mesma história.
Método fixo em seis passos
- Congele a evidência: salve request, response, ambiente, data e versão.
- Extraia o ponto: identifique evento, grupo, campo e condição mencionados.
- Abra o Anexo II: busque a regra pelo nome ou por um trecho distintivo da mensagem.
- Compare dependências: confira datas, tabelas, eventos anteriores e relações entre campos.
- Valide o schema: rode o XSD correspondente ao ambiente, sem tratá-lo como substituto das regras.
- Reproduza na restrita: teste o cenário de sucesso e a borda que provocou a rejeição antes de publicar.
Três exemplos genéricos
Campo ausente
Se a mensagem disser que um grupo é obrigatório, confira a condição no Anexo II. O grupo pode ser obrigatório apenas para uma categoria, período ou combinação de campos. Torná-lo obrigatório para todos pode criar uma nova rejeição.
Data incompatível
Compare a data informada com o evento anterior, a competência e a data atual exigida pela regra. Validar apenas o formato AAAA-MM-DD não cobre a relação entre datas.
Campo válido no schema, mas inválido segundo a regra de negócio
Um valor pode estar na enumeração do XSD e ainda depender de categoria, classificação tributária ou outro cadastro. Nesse caso, o ajuste pertence ao motor de regras e à massa de testes, não ao serializador.
Como separar bug de ambiente
Compare o pacote XSD, a versão do leiaute, a URL do ambiente, o certificado e a data de implantação. Se o erro apareceu após uma virada de calendário, confirme a agenda oficial antes de alterar a regra do produto.
O hub do eSocial mantém a documentação oficial agrupada e o radar de status mostra o status verificado. Acesse também a documentação oficial de Mensagens do Sistema.
Onde olhar: Mensagens do Sistema (oficial) ↗, Anexo II — regras de validação (oficial) ↗ e leiaute oficial S-1.3 ↗.
O próximo passo
Transforme cada rejeição em um caso reproduzível: entrada mínima, regra, ambiente, versão e resultado esperado. Esse registro reduz correções duplicadas e dá ao suporte uma resposta verificável.
