Árvore de páginas

O eSocial me retorna o erro 537, o que devo fazer?

Produto:

TOTVS Automação Fiscal

SegmentoServiços

Versões:

11 e 12

Ocorrência:

O eSocial me retorna o erro 537, o que devo fazer?

Solução

O retorno do erro 537 pode ter diversas origens, segue abaixo algumas possibilidades que devem ser avaliadas:


1 - Meu evento tem uma rejeição 537 e não possuo no TSS um registro autorizado para este evento

Uma das possibilidades de erro 537 é o envio de um evento que não possui um recibo válido retornado pelo eSocial nas tabelas SPED400 e SPED400A. Isso ocorre normalmente quando um evento é transmitido para a base de dados do eSocial e obtém em seu retorno o código de erro 203 - Este lote ja foi recebido anteriormente e ainda esta na fila de processamento. Logo após obter este retorno, caso seja realizada nova tentativa de transmissão, todas as próximas respostas do eSocial serão Erro 537 - Duplicidade.

Para conseguir obter o retorno de evento autorizado, será necessário seguir os procedimentos abaixo:

ATENÇÃO!

Após atualização do TSS com RPO disponibilizado no Portal no dia 20/02/2018, quando houve transmissão de novos eventos, a ocorrência 203 passa a ser tratada pelo próprio processamento do TSS, fazendo-se desnecessários os procedimentos abaixo.

1. Na tabela SPED400

-Identificar na tabela SPED400 o registro com retorno 537;

-Copiar o conteúdo do campo ID;

 2. Na tabela SPED400A

-Utilizar o conteúdo do campo ID copiado na tabela SPED400 para filtrar o mesmo campo na SPED400A;

-Identificar na tabela SPED400A, após execução do filtro, no campo CODRECEITA o registro com código de retorno 203 (no campo DSCRECEITA haverá o texto "Este lote já foi recebido anteriormente e ainda está na fila de processamento");

-Copiar o conteúdo do campo XMLRET para um arquivo TXT e depois copiar o conteúdo da tag <protocoloEnvio>;

-Colar o conteúdo da tag no campo PROTOCOLO do mesmo registro;

-Copiar o conteúdo do campo LOTE deste mesmo registro;

 3. Na tabela SPED400B

-Utilizar o conteúdo do campo LOTE copiado na tabela SPED400A para filtrar o mesmo campo na SPED400B. Deve ser retornado um único registro para o lote;

-Preencha o campo PROTOCOLO deste registro com o mesmo PROTOCOLO recuperado na tabela SPED400A;

4. Volte para a tabela SPED400 e SPED400A e altere o campo “STATUS” do registro de 5 para 4;

5. Aguarde o processamento do TSS autorizar o evento;

6. Faça nova consulta do TAF com o TSS e obtenha o status atualizado e o recibo do evento.

Obs. O RPO do TSS tem que estar atualizado conforme o do portal, no mínimo com a data do dia 20/02/2018.



ATENÇÃO!

Este procedimento só se aplica nos casos em que:

    • Não há registro válido e autorizado para o ID em questão na tabela SPED400A;
    • Existe 1 registro com código de erro 203 para o ID em questão na tabela SPED400A;
    • O registro possui retorno com erro 537 na tabela SPED400.



2 - Meu evento tem uma rejeição 537 e não possuo uma ocorrência 203 na tabela SPED400A

Normalmente isso ocorre quando, de fato, está sendo transmitido um evento em duplicidade. Para chegar a esta conclusão, é sugerido seguir o seguinte procedimento:

    1. Pesquisar na tabela SPED400 o registro que está sendo retornado com o erro 537. Uma forma fácil de encontrar o registro é utilizando a composição da chave do TAF no TSS → TAF0134 Identificação de registros entre TAF e TSS
    2. Obter, neste registro da SPED400, o XML enviado para o Governo. Na mensagem XML, procure pela tag chave do evento. Por exemplo: Na tabela de rubricas utilizar a tag <codRubr>. Guarde o conteúdo desta tag;
    3. Extraia toda a tabela SPED400A e faça uma pesquisa no conteúdo do campo XMLERP, procurando por todas as ocorrências da chave obtida no passo 2;
    4. Após filtrar a tabela SPED400A com a pesquisa acima, verifique se existem registros com o campo ID diferente. Se sim, significa que foram transmitidos do TAF para o TSS registros distintos que possuem a mesma chave;
    5. Utilize a composição de chave ( TAF0134 Identificação de registros entre TAF e TSS ) para encontrar os registros na tabela correspondente do TAF e verifique o motivo do sistema possuir chaves em duplicidade na tabela.

Exemplo:

Foram importados para o TAF duas Rubricas idênticas, para filiais distintas.

Filial do TAFTabela do TAFID TAFVersão TAFCódigoPer. Ini. Vld.Id. Tab. Rubr.ID TSSTags Chave no XML enviado do TAF para o TSS
01C8R0016851801201810461702301/2018000002S101000168518012018104617 <codRubr>023</codRubr><ideTabRubr>000002</ideTabRubr><iniValid>2018-01</iniValid>
02C8R0008771801201812281502301/2018000002S101000087718012018122815 <codRubr>023</codRubr><ideTabRubr>000002</ideTabRubr><iniValid>2018-01</iniValid>

No caso acima, somente uma das rubricas será autorizada, a outra sempre será retornada com erro 537, pois são exatamente iguais.

Para resolver essa questão, basta que o ERP envie os dados da tabela somente para a filial Matriz do TAF, ou que a tabela no TAF seja compartilhada a nível de empresa, impedindo assim que os dados fiquem em duplicidade.


ATENÇÃO!

Este problema pode ocorrer quando o compartilhamento da tabela T3M ( Códigos Identificadores de Rúbrica ) estiver Exclusiva no nível de Filial. Com esta configuração, pode ocorrer o cenário abaixo:

- A tabela T3M é utiliza para realizar um de/para do código de Id. Tab. Rubrica enviada do ERP para o TAF, ou seja, para cada código enviado pelo ERP, o TAF gera um ID, que é utilizada na transmissão do XML;

- Para um cenário onde a tabela T3M é configurada para trabalhar de forma exclusiva e o sistema possui Rubricas de mesmo código em filiais diferentes;

- Ainda que o ERP envie ao TAF códigos de Id. Tab. Rubricas distintos, o TAF pode gerar ID's iguais, gerando assim erro 537 na transmissão desses Eventos.

- Para esses casos será necessário excluir as Rubricas enviadas anteriormente, realizar o compartilhamento da tabela T3M e realizar novo envio das Rubricas ao Governo.

O compartilhamento deve ser feito conforme imagens abaixo:

  1. Acessar o Configurador (SIGACFG);
  2. Acessar Base de Dados → Dicionário → Bases de dados;






  • Sem rótulos