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:
| Dica |
|---|
|
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. |
- Identificar na tabela SPED400 o registro com retorno 537;
- Utilizar o conteúdo do campo ID deste registro e realizar Filtro na tabela SPED400A com este ID;
- Identificar na tabela SPEd400A, após execução do filtro, o registro com código de retorno 203 (no campo DSCRECEITA haverá o texto "Este lote ja foi recebido anteriormente e ainda esta na fila de processamento");
- Acessar o XML de retorno deste registro e obter o conteúdo da tag <protocoloEnvio>;
- O conteúdo da tag deve ser copiado para o campo PROTOCOLO do mesmo registro;
- Obtenha o lote deste registro, através do campo LOTE;
- Utilize o código do lote e filtre a tabela SPED400B. Deve ser retornado um único registro para o lote;
- Preencha o campo PROTOCOLO deste registro com o mesmo PROTOCOLO recuperado na tabela SPED400A;
- Volte para a tabela SPED400 e altere o STATUS do registro de 5 para 4;
- Aguarde o processamento do TSS autorizar o evento;
- Faça nova consulta do TAF com o TSS e obtenha o status atualizado e o recibo do evento.
| Aviso |
|---|
|
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:
- 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
- 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;
- 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;
- 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;
- 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 TAF | Tabela do TAF | ID TAF | Versão TAF | Código | Per. Ini. Vld. | Id. Tab. Rubr. | ID TSS | Tags Chave no XML enviado do TAF para o TSS |
|---|
| 01 | C8R | 001685 | 18012018104617 | 023 | 01/2018 | 000002 | S101000168518012018104617 | <codRubr>023</codRubr><ideTabRubr>000002</ideTabRubr><iniValid>2018-01</iniValid> |
| 02 | C8R | 000877 | 18012018122815 | 023 | 01/2018 | 000002 | S101000087718012018122815 | <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.
| Aviso |
|---|
|
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: - Acessar o Configurador (SIGACFG);
- Acessar Base de Dados → Dicionário → Bases de dados;
 Image Removed
|
Image Added
Image Removed
Image Added
Image Removed
Image Added
Image Removed
Image Added
Image Removed
Image Added
