cancel
Showing results for 
Search instead for 
Did you mean: 

Erro validação: ID CT-e não corresponde ao formato autorids.fiscais

0 Kudos

Bom dia,

Estou com uma NF-e rejeitada pelo GRC com o erro:  Erro validação: ID CT-e não corresponde ao formato autorids.fiscais ( Nº mensagem J1B_NFE_ERP_GRC217).

O erro trata como se fosse uma CT-e, porém o documento em questão é uma NF-e de devolução de entrada, portanto, uma saída normal.

Quando tentamos inutilizar a NF-e (skip number) a SEFAZ rejeita com erro 502 - Rejeição: Erro Chave Acesso - Campo Id ñ corresponde à conct. dos campos corresp

Abri chamado na SAP e as resposta até o momento não foram úteis, pois infelizmente não é possível reproduzir o erro.

Alguém já viu esse erro?

Podem me ajudar?

Grata,

Ludmila Milochi

Accepted Solutions (0)

Answers (2)

Answers (2)

Renan_Correa
Active Contributor

Oi Ludmila,

Neste caso você precisa ter as notas abaixo implementadas no ERP:

2048658 [3.10] Wrongly access key validation in the last day of month

2050660 [3.10] Wrongly access key validation with incorrect UTC

att,

Renan Correa

0 Kudos

Boa Tarde Renan,

Ambas já estão implementadas.

As mesmas foram aplicadas quando implementamos a 3.10 em novembro.

Att,

Ludmila

Renan_Correa
Active Contributor
0 Kudos

O Ludmila,

1- Pode confirmar se no include LJ_1B_NFEF72 do ERP há a seguinte declaração?

  gs_rfc_ide-dh_emi = wk_header-DOCDAT.

2- Se sim, e se você tem um SP antigo do GRC confirme se a a nota 2052421 está implementada. No lado do GRC ela também é necessária.

3- Se a nota está implementada então o único jeito de ter certeza é o debugger.

A validação ocorre na função /XNFE/OUTNFE_VALIDATION, no FORM check_id

usando o código abaixo:

  MOVE is_nfe_header-accesskey TO lv_id.

  CLEAR lv_id_fields.

  lv_serie = is_nfe_ide-serie.

  lv_id_fields(2)     = is_nfe_ide-c_uf.       "Region

  lv_id_fields+02(02) = lv_local_dh_emi+2(2). "Year

  lv_id_fields+04(02) = lv_local_dh_emi+4(2). "Month

  lv_id_fields+06(14) = is_nfe_partner-cnpj.  "CNPJ of issuer

  lv_id_fields+20(02) = is_nfe_ide-mod.       "model

  lv_id_fields+22(03) = lv_serie.             "serie

  lv_id_fields+25(09) = is_nfe_ide-n_nf.       "NFe number

  lv_id_fields+34(01) = is_nfe_ide-tp_emis.    "Issing type

  lv_id_fields+35(08) = is_nfe_ide-c_nf.     "random number (except first digit fixed zero)

  lv_id_fields+43(01) = is_nfe_ide-c_dv.       "control digit

O programa basicamente compara a chave de acesso recebida do ERP com a concatenação das tags que formam a chave de acesso. Qualquer diferença causa a rejeição que você está tendo pelo GRC.

att,

Renan Correa

0 Kudos

Renan,

Debuggamos usando o caminho que mencionou e encontramos o problema.

Apesar de as OSS notes, que você sugeriu, estarem implementadas, o erro foi na formação da chave de acesso.

A chave montada na J1B3N não estava compatível com a montada no include. Debuggando descobrimos que a data utilizada na formação da chave de acesso estava incorreta, acredito que a mesma esteja puxando a data do documento de referência a ser devolvido e não a data de criação da nota de devolução, porém não sei o por que da intermitência.

Muito obrigada pela ajuda!

Att,

Ludmila

Former Member
0 Kudos

Ludmila,

Encontrei o mesmo problema em outro cliente.

Aparentemente, se alteramos a data de uma NF via writer, em alguns casos, a tabela J_1BNFE_ACTIVE não está sendo atualizada com os campos NFYEAR e NFMONTH, só a tabela j_1BNFDOC é atualizada..

Como a chave é montada com os dados da tabela J_1BNFE_ACTIVE, ocorre a inconsistência na validação no GRC.

Como solução, estonamos a NF e emitimos uma nova com a data já corrigida.

Espero ter ajudado.

Former Member
0 Kudos

Oi Ludmila

por favor dê um feedback na thread.

Grato

Eduardo Chagas