Erro de validação: campo Chave de acesso de 44 caracteres. ID NF-e não corr

[Former Member]

Bom dia.

Estou tendo o seguinte erro de validação em algumas notas de entrada:

Erro de validação: campo Chave de acesso de 44 caracteres. ID NF-e não corresponde ao formato Processamento N (campo IS_NFE_HEADER-ID, ID campo A003)

Até retirei o validador para ver o que aconteceria e a SEFAZ rejeitou pelo motivo 227 - Rejeição: Erro na Chave de Acesso - Campo ID

De acordo com o manual de integração, o problema é que esta faltando o literal "NFe". Porem verifiquei no XML e não esta. Veja o inicio:

<infNFe versao="1.10" Id="NFe31100817469......etc.

Alguma idéia? Existe difenrença na validação de nota de entrada para nota de saida? (pois tem nota de saida quase identica - os dados - que passaram sem problemas).

At.,

Bernardo Braga

[henrique_pinto · Accepted solution]

Nota de entrada nao passa no validador! Só notas que vc gera.

Tem ctz que é de entrada?

Se for, tem algum erro, pra estar sendo enviada pra SEFAZ.

Ou é uma nota de um processo de MM, mas que vc emite a nota (tipo importação)?

Se for, daí tudo bem. Mas a regra de validacao é a mesma pra ambos os casos.

Abs,

Henrique.

[Former Member · Accepted solution]

É um nota MM, categoria FF.

Estava suspeitando era uma das datas que estavam compondo erroneamente a chave:

A chave da nota é 311008.......

Ou seja:

31 - MG

10 - Mês

08 - Ano

Data de saída: 31.08.2010

Data documento: 02.09.2010

Data de envio: 02.09.2010

Porém, uma nota de saída com dados semelhantes passou normalmente.

At.,

Bernardo Braga

[former_member193386 · Accepted solution]

mas isso é nota de entrada ou de saida?

[Former Member · Accepted solution]

É uma nota de entrada emitida pela nossa empresa (nota MM).

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

Essa rejeição informa que a concatenação dos campos em separado não corresponde à chave de acesso.

A partir do SP13 este tipo de problema não chega até a Sefaz, veja SAP Note 1404542.

CUF + YEAR (2 digits year from DEMI) + MONTH (2 digits month from DEMI) + C_CNPJ + MODEL + SERIE +  NFE NUMBER + RANDOM NUMBER + CHECK DIGIT. The problem occurs, if the part of the ID differs from   

É provável que após a geração da chave de acesso o usuário modificou a data de emissão.

Atenciosamente, Fernando Da Ró

[Former Member]

Oi Bernardo

O erro 227 pode ser tanto pela falta do literal "NFe" quanto pela Chave de Acesso diferir da concatenação dos campos correspondentes como o Fernando mencionou.

Verifique cada um dos componentes gerados na chave com os valores que você tem na tab nf-e da J1B3N.

Abraço

Eduardo

[former_member182114]

Bom dia Pessoal,

@Eduardo, sugiro até pegar os dados por debug no call_xi da função J_1BNF_MAP_TO_XML logo antes de sair para a mensageria. Pois no visor até pode estar certo mas está indo errado. Tem algumas notas que tratam do tema (tpEmis) no ERP, veja:

1505115 NF-e: Check- and Random Number are shown for Cancelled NF-is

1497422 TPEMIS wrong default value (0) for incoming NF-e

1489116 NF-e: Issuing type not correct for SCAN and non-decouple

1486401 NF-e: Issuing type not filled in accordance to XML-Version

1485996 NF-e: Issuing type in status contingency not correct

1470661 NF-e: Flexible XML-Version in Nota Fiscal-Writer

1454408 Nf-e: Change of access key: tpEmis and random number

1443089 NFe: Inclusion of NF-e issuing type in Access Key - Part 1

@Henrique, a nota que sugeri é justamente para "implementar" a validação, por isso chegou à Sefaz.

@Bernardo, além desta nota tem uma mais nova que checa conforme layout 2.0, veja:

1500046 Upgrade validation rule for field ID for version 2.00

@All, procurem manter-se atualizados lendo, planejando e aplicando as SAP Notes XX-CSC-BR-NFE. No caso GRC basicamente siga os SP's.

Atenciosamente, Fernando Da Ró

[henrique_pinto]

Fernando,

ele já teve o erro de validacao, como ele mesmo comentou.

Erro de validação: campo Chave de acesso de 44 caracteres. ID NF-e não corresponde ao formato Processamento N (campo IS_NFE_HEADER-ID, ID campo A003)

Na verdade, ele falou que desativou o validador pra testar e eu que comi bola e nao tinha lido essa parte.

Um problema que eu vi acontecer com notas de entrada emitidas foi o caso de ele mandar o CNPJ da planta e nao do fornecedor na chave de acesso. Verifique isso.

Abs,

Henrique.

[former_member182114]

Sim sim, também comi bola na análise.

Se o próprio validador já está rejeitando, deve-se verificar o catatau de notas do ERP que passei no outro post.

[AlexandreMendes]

Olá SRS!

@Bernardo: Verifique na parametrização da filial, se foi alterado a versão do XML 1,10 para 2,00.

Se não me engano é o mesmo erro que estou tendo quando envio nota fiscal em versão 1,10.

Abri um "chamado" na SAP pois talvez exista um erro no validador para notas em versão 1,10.

Aqui no nosso cenário, emitiremos a partir de Outubro, notas em 2,00 de ambientes ECC 600 e ECC 604 e notas em 1,10 de ambientes 46B e quando fizemos um teste das notas em 1,10 tivemos um problema no validador, pois ele está comparando os valores 1,10 com 005A (versão de XML x versão do XSD).

Nosso ambiente GRC está com SP15 e todas as OSS Notes seguintes.

@Fernando: Se puder nos ajudar a agilizar o processo, lhe agradeço, pois talvez seja também a solução desta thread

Segue o texto abaixo onde explica exatamente o ponto do programa.

@Bernardo, depure o programa até este ponto.

-

-

---

Message: 714834 / 2010

Short Text

Error on validation program running XML 1.10 version

Long Text

The validation program is not working with XML 1.10 version. Maybe, there

is an error in /XNFE/LNFE_VALIDATIONF01 include, FORM check_id.

We've already implemented all oss notes regarding to SAP GRC NF-e 1.0

product.

These updates has changed it when it is checking the access key fields.

For the 2.0 version the field TPEMIS has to be checked but for the 1.10

version this field do not have to be checked.

For our production environment, we are going to have two ERP sending NF-es

and one of them sending 1.10 version and in our tests, we've checked that

the validation is using the value 005A instead of 1.10 (previously

customized on the spro)

Steps for Reconstruction

To reproduce it we have to create a NF-e 1.10 version and check the form

check_id in the /XNFE/LNFE_VALIDATIONF01 include. (check out the attachment).

-

-

---

Abs a todos!

[former_member182114]

Bom dia Alexandre,

Aqui no nosso cenário, emitiremos a partir de Outubro, notas em 2,00 de ambientes ECC 600 e ECC 604 e notas em 1,10 de ambientes 46B e quando fizemos um teste das notas em 1,10 tivemos um problema no validador, pois ele está comparando os valores 1,10 com 005A (versão de XML x versão do XSD).

Você teve problemas de emissão 1.10 no ECC 600/604 ?

Como você colocou o 46B para funcionar com NF-e standard ? A versão inicialmente suportada é a 46C...

Verifique em seu sistema 46B se:

1) Você está passando o valor 005A no parametro IV_VERSION da função /XNFE/NFE_CREATE e

1) Se está passando IV_VERSION = vazio na chamada da função /XNFE/NFE_CREATE

2) Se está passando '1.10' no valor XMLH-VERSION

Ambos falam de versão mas são conteúdos diferentes.

Atenciosamente, Fernando Da Rós

PS: Seu chamado está em Customer Action, aguardando sua ação.

Edited by: Fernando Ros on Sep 9, 2010 8:05 PM - Sobre o preenchimento do IV_VERSION

[Former Member]

Opa. Voltei.

Esse problema ocorreu em nosso ambiente de produção (SP13) XML 1.10.

A nota parou no validador. Retirei o validador para confirmar se a SEFAZ iria rejeitar. E rejeitou.

A solução que a consultora MM deu foi alterar no SAP a data do SAP e gerar novamente a chave e digito verificador.

A nota foi autorizada, porém não sei explicar o motivo da rejeição original.

Como tambem foi rejeitado pela SEFAZ, concluí que não é problema no validador e sim nos dados da nota que não estava correto (pois a nota foi rejeitada pela SEFAZ).

Provavelmente foi o que o Fernando falou: "É provável que após a geração da chave de acesso o usuário modificou a data de emissão."

Em síntese: no meu caso (Ambiente Produtivo com SP13 emitindo XML 1.10) concluo que não tem nenhum problema.

O problema do Alexandre parece ser outro completamente diferente. Mas poste aqui a resposta pois fiquei curioso...rs.

At.,

Bernardo Braga

[Former Member]

Opa. Voltei.

Esse problema ocorreu em nosso ambiente de produção (SP13) XML 1.10.

A nota parou no validador. Retirei o validador para confirmar se a SEFAZ iria rejeitar. E rejeitou.

A solução que a consultora MM deu foi alterar no SAP a data do SAP e gerar novamente a chave e digito verificador.

A nota foi autorizada, porém não sei explicar o motivo da rejeição original.

Como tambem foi rejeitado pela SEFAZ, concluí que não é problema no validador e sim nos dados da nota que não estava correto (pois a nota foi rejeitada pela SEFAZ).

Provavelmente foi o que o Fernando falou: "É provável que após a geração da chave de acesso o usuário modificou a data de emissão."

Em síntese: no meu caso (Ambiente Produtivo com SP13 emitindo XML 1.10) concluo que não tem nenhum problema.

O problema do Alexandre parece ser outro completamente diferente. Mas poste aqui a resposta pois fiquei curioso...rs.

At.,

Bernardo Braga

[henrique_pinto]

Oi Bernardo,

notei que a chave de acesso tinha ano e mes como "1008" (ou seja, AA = 10 e MM = 08), mas a data que vc postou a mensagem já era setembro (MM deveria ser "09").

É possível que essa nota tenha sido iniciada a ser criada no fim de agosto mas só foi emitida em setembro?

Entao pode ter sido um problema com as datas, no campo dEmi ele estava indo atualizado (e.g. mês 09) mas na chave de acesso, que já tinha sido criada antes, ainda estava com "08".

Se nao me engano, tem nota que corrige isso (ele mantem sempre sincronizado a chave e o dEmi com o document date).

@Alexandre,

acho que seu problema é outro, provavelmente por mismatch de versao na chamada Z da RFC na 4.6B. Abra outra thread.

Abs,

Henrique.

[Former Member]

Meu problema parece ter sido exatamente isso.

At.,

Bernardo Braga

[henrique_pinto]

Aliás, em sendo nota de entrada, acho que tinha outro complicometro.

Acho que pra notas de MM ele pegava o dEmi do document date e a chave de acesso do posting date, ou vice versa.

Se nao me engano, foi corrigido em alguma nota mais recente.

Abs,

Henrique.

[former_member182114]

Bom dia Alexandre,

Estou debugando um sistema atualizado SP15+Notas que está com este mesmo sintoma, a primeira impressão é que a SAP Note 1500046 "Upgrade validation rule for field ID for version 2.00" saiu com um código antigo, estou tentando verificar o que pode ter acontecido mas de qualquer forma parece que vai precisar de envolver o development team para corrigir.

Na SAP Note tem:

AND is_nfe_header-version NE gc_govvers-vers_005 )  "only for newer version then 005a

Deveria ser:

AND is_nfe_header-version NE gc_xmlvers1_erp )  "only for newer version then 1.10 (005a)

Manterei vocês atualizados.

Atenciosamente, Fernando Da Ró

[former_member182114]

Bom dia Alexandre,

A SAP Note 1500046 tinha um erro em sua liberação, implemente a versão 2 desta nota e o problema se resolverá.

Atenciosamente, Fernando Da Ró

[AlexandreMendes]

Olá SRS

@Fernando: Desculpe por não responder a thread no mesmo time que você.

O chamado estava em customer action porque a SAP estava pedindo para acessar o nosso ambiente para simular o problema, porém aqui a burocracia é um pouco grande até liberarem acesso, usuário etc...

Obrigado pelo retorno! Acabei de realizar um teste e está tudo funcionando.

Da versão 46B, como a principio a idéia é de não alterarmos nada, o campo IV_VERSION não é enviado, porém, do jeito que foi criada a lógica dentro da funcão NFE_CREATE, ela sempre carregará como 005A quando vier vazio.

Da versão 600, o campo IV_VERSION também não vem preenchido quando é enviada uma nota fiscal na versão 1,10 e sendo assim, a NFE_CREATE trata da mesma forma, carregando a variável para 005A.

Da versão 600, para notas fiscais com versão 2,00, o campo IV_VERSION já vem preenchido com 006.

Dentro da função de validação, percebi que foi alterada a variável para verificar pelo valor 1.10 ao invés de 005A.

Portanto, o problema foi solucionado com sucesso apenas reaplicando a segunda versão da OSS note 1500046.

Aparentemente o Bernardo também passou pelo mesmo problema, pois ele estava enviando nota 1,10, porém, como visto, outros problemas também estavam ocorrendo em sua nota fiscal.

Para a versão 46B, criamos a solução de comunicação com o GRC através do programa de impressão da DANFE.

Desde já, agradeço a atenção!

[henrique_pinto]

Bernardo,

como que a nota é de entrada emitida por vocês, mas vc já tem o XML??

Se deu erro de validacao, o XML nunca nem deveria chegar a ser gerado.

Algo parece estranho.

Abs,

Henrique.