1.3) Regras de envio da informação ao eSocial:

1.3.1) Preenchimento dos campos do leiaute - obrigatoriedade:

A obrigatoriedade de envio de informação para cada grupo é determinada na Tabela de Resumo dos Registros de cada um dos leiautes de acordo com a coluna Condição. Por sua vez a obrigatoriedade de envio de informação para cada um dos campos é determinada de acordo com a coluna “ocor” constante na Tabela de Registro dos Eventos.

As colunas "Ocorrência" e "Condição" devem ser observadas (vide item 1.1 sobre o conteúdo destas colunas), quanto à obrigatoriedade ou não de uma informação.

No caso da coluna “Ocorrência”, quando a quantidade mínima for zero, o declarante somente deve prestar a informação se, de fato, ela existir, caso contrário nada deve ser informado, nem mesmo informação zerada. Contudo se esta informação for obrigatória de forma condicional descrita na coluna "Condição", uma vez efetivada a condição, a informação deve ser prestada.

Exemplo:

Na Tabela de Resumo dos Registros o “Reg” {dadosProcJud} do evento S-1070 tem ocorrência 0-1, significando se o campo deve ser preenchido ou não.

Na coluna "condição" consta "O" de obrigatório se tipo de processo {tpProc} for preenchido com [2] e "N" de não informar (vedado) para os demais casos. Ou seja, se o campo {tpProc} for preenchido com [2], o preenchimento das Informações Complementares do Processo Judicial é obrigatório, caso contrário, o preenchimento do registro é vedado.

1.3.2) Formato dos registros nos arquivos XML:

Alguns caracteres especiais devem ser evitados para não gerar erros quanto à codificação do documento enviado ao sistema eSocial. Para isto é necessário substituir os caracteres pelas sequências de “caracteres x escape” adequadas, conforme a tabela diante demonstrada:

Alguns desses caracteres, no entanto, podem constar especialmente no campo de Razão Social ou Endereço, entre outros. Por exemplo, a denominação DIAS & DIAS LTDA deve ser informada como: DIAS &am p; DIAS LTDA no arquivo XML gerado.

O sistema do declarante pode fazer o processo de substituição de forma automática, a fim de evitar a necessidade de alterações nas informações constantes das bases dos declarantes e contribuintes.

No Capítulo seguinte deste Manual são apresentadas as orientações específicas para cada Evento, as quais foram estruturadas em cinco partes, conforme os itens a seguir:

• Quem está obrigado;
• Prazo de envio;
• Pré-requisitos; e
• Informações adicionais.

1.3.3) Esclarecimentos referentes à utilização de casa decimais em campos numéricos do leiaute do eSocial:

Todos os campos numéricos do eSocial têm a definição de um tamanho máximo, ou seja, de um número máximo de algarismos que podem formar aquele número.

Exemplo 1

O campo {dia} do evento S-1200 tem tamanho igual a 002, conforme recorte adiante:

O declarante deve informar, nesse campo, os dias trabalhados pelo empregado intermitente no mês e, portanto, como o valor máximo que pode ser informado nesse campo é 31, o tamanho máximo do campo é um numeral formado por dois algarismos, sem casas decimais.

Exemplo 2

O número de casas decimais integra a quantidade máxima de algarismos do tamanho do campo. E, além disso, a informação de casas decimais não é obrigatória, ou seja, num campo de tamanho 1-4, se forem informados 4 algarismos sem ponto para separar casas decimais, o sistema entende aqueles 4 algarismos como um número inteiro. Tomemos o exemplo do campo adiante {qtdHrsSem} do evento de admissão:

O campo permite a informação de um número com 1 a 4 algarismos podendo ter 2 casas decimais. Então, se o declarante informar 4400, está informando que a quantidade média de horas semanais do empregado é de 4400 (quatro mil e quatrocentas) horas. Caso ele queira informar 44 (quarenta e quatro) horas semanais ele pode informar de uma destas três maneiras:

44 (quarenta e quatro inteiros sem casas decimais).

44.0 (quarenta e quatro inteiros com uma casa decimal), ou

44.00 (quarenta e quatro inteiros com duas casas decimais.

Em resumo, é importante destacar aos declarantes que, se o número informado possuir casas decimais, estas devem ser separadas da parte inteira do numeral através de um ponto, respeitando o tamanho máximo do campo. Caso contrário, o declarante está informando um numeral constituído de um número inteiro formado por todos os algarismos informados.

Exemplo 3

Nos casos em que o campo numérico pode ser informado com casas decimais, o leiaute define, além do tamanho mínimo e máximo do campo, o número de casas decimais que podem compor o numeral a ser informado. Vejamos o exemplo do campo {percAliment} adiante:

O declarante, nesse caso, deve informar o percentual de FGTS destinado à pensão alimentícia e, portanto, o campo pode ter até duas casas decimais, ex.: 33,33%. Nesse exemplo, o campo tem tamanho mínimo de 1 e máximo de 5 porque o valor máximo que pode ser informado, com duas casas decimais, é 100,00. Ou seja, um numeral formado por cinco algarismos, podendo ter até duas casas decimais, lembrando que o ponto não é considerado como caractere.

Nesse exemplo, o declarante que queira enviar o percentual de 33,33% pode fazê-lo preenchendo o campo do seguinte modo: [33.33] ou [033.33].

1.3.4) Esclarecimentos referentes à utilização de casa decimais em campos numéricos do leiaute do eSocial:

A configuração padrão utilizada no eSocial é "Case Insensitive" para diferenciação entre maiúsculo e minúsculo. Isso significa que a utilização de letras maiúsculas ou minúsculas no preenchimento dos campos é indiferente para a base de dados. Por exemplo, os códigos de rubrica a serem informados na tabela de rubricas não diferencia: "Rubrica001" de "rubrica001" e de "RUBRICA001". Caso seja enviada uma rubrica com o código (codRubr) “Rubrica001” e, na sequência, o empregador tentar enviar outra rubrica com o código “RUBRICA001”, o sistema deve informar que já existe registro com o mesmo código de identificação.

Entretanto, é importante destacar que, embora a base de dados não seja sensível a caracteres maiúsculos ou minúsculos, as regras de validação dos arquivos XML definidos no esquema XSD (XML Schema Definition) do eSocial podem exigir determinado formato de dados que envolvam maiúsculos ou minúsculos. Exemplo: campo {evtRemun} do evento S-1299 permite preenchimento apenas com as opções "S" ou "N" (Sim/Não). Este campo deve ser preenchido com "S" ou com "N" em letra maiúscula. Se for preenchido com letra minúscula haverá erro. O mesmo ocorre com os estados brasileiros, cuja sigla também deve ser preenchida com letras maiúsculas. Exemplo: "AM", "RJ", "SP".

Além disso, como regra geral, os campos do tipo C (caractere) não devem possuir quebra de linha. Excepcionalmente, os campos do tipo C de tamanho máximo 80, 100, 150, 200, 255 e 999 permitem quebra de linha no meio do texto. No entanto, esses campos não podem começar com espaço ou quebras de linha.

Outra configuração padrão utilizada na base de dados do eSocial refere-se ao caractere “Espaço”. Tal caractere é considerado tanto quando digitado antes da sequência de caracteres quanto ao final da sequência de caracteres (string). Exemplo: o espaço digitado à esquerda da sequência de caracteres “ Vendedor” é aceito na base de dados. Caso haja uma nova inclusão com os caracteres "Vendedor", o eSocial aceita a inclusão como uma descrição de cargo diferente, ambas válidas: " Vendedor" e "Vendedor".

(Excluído)

Observação: cabe destacar que de acordo com a REGRA_CARACTERE_ESPECIAL a utilização do "Espaço" à direita ou à esquerda da sequência de caracteres é vedada nos seguintes campos: S-1010: {codRubr} e {ideTabRubr} no grupo {inclusao}; S-1020: {codLotacao} no grupo {inclusao}; S-1200, S-1202, S-1207, S-2299 e S-2399: {ideDmDev}; S-2190, S-2200 e S-2300: {matrícula}.

1.3.5) Orientações sobre o procedimento de alteração de CPF do trabalhador ou de beneficiário:

Em situações raras e excepcionais o número de CPF de uma pessoa pode ser alterado pela Receita Federal do Brasil. O CPF, contudo, é utilizado pelo eSocial como o principal identificador do trabalhador e com base nele são aplicadas inúmeras regras e validações, portanto, qualquer solução para a situação de fato - alteração de CPF - tem que levar em consideração que: o CPF é chave, e é necessária a vinculação entre o CPF antigo e o novo. Por esta razão, apesar de tratar-se de um dado pessoal do trabalhador ou beneficiário, essa alteração não pode ser feita através de um evento S-2205 (Alterações cadastrais) ou S-2405 (Alteração de dados de beneficiário).

Assim, para evitar que o declarante tenha que excluir e reenviar com o novo CPF todos os eventos do trabalhador ou beneficiário, foi criado um procedimento especial para tratar esses casos excepcionais de alteração de número de CPF, baseado no envio de um evento de S-2299 (Desligamento) seguido de um novo evento de S-2200 (Admissão), nos moldes do procedimento utilizado para o trabalhador transferido entre empresas de um mesmo grupo econômico ou no caso de sucessão de declarantes ou baseado no envio de um evento S-2420 (Término de benefício), seguido de um S-2410 (Cadastro de benefício).

Como é sabido, quando ocorre transferência de um empregado de um declarante para outro do mesmo grupo econômico, deve ser enviado ao eSocial um evento S-2299 com motivo [11] – “Transferência de empregado para empresa do mesmo grupo empresarial (...)” e, em seguida, deve ser enviado o evento S-2200 na empresa que está recebendo o trabalhador, com o campo {tpAdmissao} preenchido com [2] - “Transferência de empresa do mesmo grupo econômico”, mantendo a data da admissão inicial e informando a data da transferência.

Nesse caso, o contrato de trabalho não sofre qualquer alteração, afinal, as empresas que formam um grupo econômico são consideradas um empregador único e o que ocorre no sistema é apenas a alteração do número de identificação do empregador.

A mesma lógica foi aplicada para a mudança do número de identificação do trabalhador, ou seja, quando o CPF de um trabalhador é alterado, o empregador em vez de excluir todas as informações enviadas com o CPF antigo e reenviá-las com o novo CPF, deve executar procedimento análogo ao da transferência de empregados entre declarantes, ou seja, deve seguir os seguintes passos:

1 – Enviar evento de S-2299 (Desligamento) com o motivo [36] – “Mudança de CPF”, indicando no campo {novoCPF} o novo número de inscrição do empregado;

2 – Em seguida, deve enviar evento S-2200 (Admissão), com o campo {tpAdmissao} preenchido com [6] – “Mudança de CPF”, mantendo a data de admissão original do trabalhador. Deve, ainda, preencher o grupo [mudancaCPF] com os números de CPF e matrícula anteriores e com a data em que houve a alteração. O eSocial não permite que uma matrícula seja reaproveitada, portanto, quando o CPF é alterado, nova matrícula deve ser atribuída ao trabalhador.

Da mesma forma como ocorre na transferência de empregados, apesar de existir um novo evento de admissão, o vínculo contratual do trabalhador não é alterado, sendo considerado desde a data de admissão original e transpassando a data de transferência ou mudança de CPF.

Assim, caso haja uma alteração contratual, por exemplo, com data de efeito anterior à data de mudança de CPF, o sistema recepciona normalmente o evento, desde que essa data de efeito seja posterior a sua admissão. Qualquer informação de pagamento retroativo, informada no grupo [remunPerAnt], pode indicar período de referência {perRef} anterior a mudança de CPF, desde que a competência seja igual ou posterior a sua admissão.

Ressalte-se que os eventos extemporâneos referentes ao período anterior à mudança de CPF devem ser enviados com o CPF antigo do trabalhador.

É importante frisar que, como o vínculo/contrato não sofre alteração com a mudança do CPF, todas as informações cadastrais e contratuais do novo evento S-2200 devem ser idênticas àquelas vigentes no contrato anterior, exceto a matrícula. O sistema realiza validações para garantir que a data de admissão, que a categoria do trabalhador e que o tipo de regime de trabalho e de previdência sejam mantidos idênticos. O sistema também faz validação para garantir que o evento de admissão por mudança de CPF seja enviado no dia imediatamente seguinte ao evento de desligamento pelo mesmo motivo.

O mesmo procedimento descrito também se aplica para TSVE – Trabalhadores Sem Vínculo de Emprego nos eventos S-2300 e S-2399. O evento S-2399 deve ser enviado com o campo {mtvDesligTSV} preenchido com [7] – “Mudança de CPF” e a informação do novo CPF preenchida no grupo [mudancaCPF]. O novo evento S-2300 deve ser enviado no dia imediatamente seguinte com o grupo [mudancaCPF] preenchido, desta vez com os dados do CPF anterior. Os seguintes campos do novo evento S-2300 devem ser idênticos aos existentes no RET: {codCateg} e {dtInicio}.

No caso de alteração de CPF de beneficiário informado no evento S-2400, também é aplicado tratamento análogo. Deve ser enviado o evento S-2420 (Benefício – Término), seguido de um novo S-2400 (Cadastro de beneficiário) e, ainda, de um novo S-2410 (Cadastro de benefício). O evento S-2420 deve ser enviado com o campo {mtvTermino} preenchido com [10] – “Mudança de CPF” e a informação do novo CPF preenchida no campo {mudancaCPF}. O novo S-2400 deve ser enviado com o CPF alterado. O novo S-2410 deve ser enviado com o campo {indSitBenef} preenchido com [3] – “Mudança de CPF” do beneficiário e o grupo [mudancaCPF] preenchido, dessa vez com os dados do CPF anterior. Os seguintes campos do novo S-2410 devem ser idênticos aos informados no S-2420: {dtIniBeneficio} e {tpBeneficio}.