Rejeição: GTIN (cEAN) com prefixo inválido NF 250 produtos

[Igor Bastos]

Olá, estou recebendo o erro de "Rejeição: GTIN (cEAN) com prefixo inválido" em uma NF com 250 produtos, ou seja, após passar pela validação do sistema utilizando ValidarGTIN, inicio a transmissão e o SEFAZ me retorna o erro.

Código de Validação: http://textuploader.com/dfgfo

Segue o XML em questão.

Ambiente de Homologação, Goiás.

A questão é, como descobrir qual produto exatamente teve o erro no GTIN e pq? (Visto que a validação local passou normalmente)

 

NFe52180514100847000152550010000000051251817470.xml

[Felipe E. Resende Mesquita]

  Em 16/05/2018 at 19:51, Igor Bastos disse:

Olá, estou recebendo o erro de "Rejeição: GTIN (cEAN) com prefixo inválido" em uma NF com 250 produtos, ou seja, após passar pela validação do sistema utilizando ValidarGTIN, inicio a transmissão e o SEFAZ me retorna o erro.

Código de Validação: http://textuploader.com/dfgfo

Segue o XML em questão.

Ambiente de Homologação, Goiás.

A questão é, como descobrir qual produto exatamente teve o erro no GTIN e pq? (Visto que a validação local passou normalmente)

 

NFe52180514100847000152550010000000051251817470.xmlFetching info...

Expandir  

Boa tarde, Igor Bastos

Esse gtin existe?

 

-<det nItem="127">
-<prod>

<cProd>420129</cProd>

<cEAN>94201291</cEAN>

<xProd>NEOSORO SOL NASAL AD 30ML OEC6</xProd>

[Igor Bastos]

  Em 16/05/2018 at 20:26, Felipe E. Resende Mesquita disse:

Boa tarde, Igor Bastos

Esse gtin existe?

 

-<det nItem="127">
-<prod>

<cProd>420129</cProd>

<cEAN>94201291</cEAN>

<xProd>NEOSORO SOL NASAL AD 30ML OEC6</xProd>

Expandir  

Agora que vc citou... Não, ele não existe, mas o 0000094201291, aparentemente existe!

Como vc chegou até esse número?

Será que devo preencher zeros à esquerda até dar 13?

[Igor Bastos]

Testei aqui completando o EAN com zeros à esquerda, ate dar 13 dígitos, mas continua retornando o msm erro

Editado 16 Maio, 2018 por Igor Bastos

[BigWings]

  Em 16/05/2018 at 19:51, Igor Bastos disse:

A questão é, como descobrir qual produto exatamente teve o erro no GTIN e pq?

Expandir  

A mensagem de rejeição da SEFAZ devia conter o número do item:

Se não está retornando, uma alternativa nesse caso é comparar o prefixo do GTIN informado no XML com a tabela de prefixos disponível pra download no portal da NFe.

[Igor Bastos]

  Em 16/05/2018 at 21:06, BigWings disse:

A mensagem de rejeição da SEFAZ devia conter o número do item:

Se não está retornando, uma alternativa nesse caso é comparar o prefixo do GTIN informado no XML com a tabela de prefixos disponível pra download no portal da NFe.

Expandir  

A comparação é feita pelo fxPrefixIni com os 3 primeiro valores do EAN sem zeros à esquerda?

[BigWings]

  Em 16/05/2018 at 22:26, Igor Bastos disse:

A comparação é feita pelo fxPrefixIni com os 3 primeiro valores do EAN sem zeros à esquerda?

Expandir  

Pelo que entendi é a faixa entre o prefixo inicial e o final.

Assim o GTIN 94201291 seria válido, por ter 8 dígitos, caracterizando o GTIN-8, o dígito verificador confere segundo o validador https://www.gs1.org/services/check-digit-calculator#gtin e o prefixo está na faixa entre 940 e 949 (GS1 New Zealand).

[Igor Bastos]

Será que é alguma falha no ambiente de Homologação? Pode ser?

[BigWings]

  Em 16/05/2018 at 23:10, Igor Bastos disse:

Será que é alguma falha no ambiente de Homologação? Pode ser?

Expandir  

Não informar o item com erro no prefixo do GTIN eu considero uma falha, sim.

Sem essa informação você precisa comparar os prefixos de todos os GTIN informados no XML com a tabela. Como disse, esse GTIN destacado parece estar correto.

[Igor Bastos]

Talvez não é esse o produto. Vou testar emitir em grupos de produto e venho dar o Feedback

[Dércio Luis Zanatta]

Bom dia

Estou enviando Cean em branco na NFCe 4.0 e está autorizando normalmente aqui no RS

[Igor Bastos]

  Em 16/05/2018 at 22:59, BigWings disse:

Pelo que entendi é a faixa entre o prefixo inicial e o final.

Assim o GTIN 94201291 seria válido, por ter 8 dígitos, caracterizando o GTIN-8, o dígito verificador confere segundo o validador https://www.gs1.org/services/check-digit-calculator#gtin e o prefixo está na faixa entre 940 e 949 (GS1 New Zealand).

Expandir  

Pelo que percebi ele apenas valida o Digito Verificado e não necessariamente o GTIN em si.

  Em 17/05/2018 at 11:49, Dércio Luis Zanatta disse:

Bom dia

Estou enviando Cean em branco na NFCe 4.0 e está autorizando normalmente aqui no RS

Expandir  

A questão é que não posso enviar vazio "SEM GTIN"

  Em 17/05/2018 at 00:58, Igor Bastos disse:

Talvez não é esse o produto. Vou testar emitir em grupos de produto e venho dar o Feedback

Expandir  

Fiz o teste até descobrir os GTINs que falharam:

http://textuploader.com/dfubj

Basta deixar um desses EAN e dá falha na SEFAZ. Estou entrando em contato com o Cliente para confirmar os Códigos de Barra.

[BigWings]

  Em 17/05/2018 at 13:01, Igor Bastos disse:

Pelo que percebi ele apenas valida o Digito Verificado e não necessariamente o GTIN em si.

Expandir  

Correto.

São várias validações, a sua rejeição foi referente ao prefixo.

Pra ser autorizado na NFe o GTIN ainda deve estar cadastrado no GS1, caso contrário você deve informar a tag cEAN e cEANTrib em branco ou com a informação SEM GTIN.

[Igor Bastos]

Em análise mais específica identifiquei que são estes EANs com falha: http://textuploader.com/dfue7

Aparentemente a verificação é a mais simples possível: se o DV estiver correto, verifica os três primeiros números com a tabela de prefixo GS1. Fiz testes deixando os inválidos como "SEM GTIN" e a NF passou normalmente.

É possível adicionarem essa solução no ACBr ValidarGTIN?

[BigWings]

  Em 17/05/2018 at 14:13, Igor Bastos disse:

É possível adicionarem essa solução no ACBr ValidarGTIN?

Expandir  

Acredito que não pois depende de uma tabela externa.

[Igor Bastos]

Fiz uma validação local baseada no arquivo disponibilizado pela GS1, mas existe uns Códigos que não foram validados, por exemplo: 382904918019. Mas na SEFAZ ele passa normalmente. Acontece que eu achei este link  http://www.codigodebarras.net.br/varios/codigo_de_barras_ean13.htm com a informação de que o prefixo 382 está sendo implantado.

Na minha opinião aconteceu assim: o GS1 está implantando os prefixos mas não atualizou o arquivo, mas a SEFAZ já atualizou a validação dos GTIN com os códigos a implantar. Isso é baseado na situação de que o prefixo é inválido baseado no arquivo mas a SEFAZ aceita ele normalmente.

Como solucionar a situação? Já que, aparentemente, a SEFAZ vai sempre estar "atualizada" e a validação local não poderia impedir a transmissão, já que a SEFAZ aceita o GTIN

[Igor Bastos]

Solução que desenvolvi:

Fiz uma função de validação do Prefixo GTIN (baseado na Tabela de Prefixos da GS1 e nesse link), coloquei o retorno como Aviso, ou seja, não impedirá de transmitir a NFe e permitirá que o usuário escolha entre não transmitir para corrigir ou transmitir com os Avisos.

Nos casos em que realmente não são validados localmente (por exemplo se retornar erro no ACBr.ValidarGTIN), retorna erro real e impede de transmitir. Se o usuário decidir transmitir msm com os Avisos, pode ser que retorne os erros da SEFAZ, daí é com o usuário trabalhar nas alterações manuais dos EANs.

[Riquena]

Igor Bom dia.

Também estou desenvolvendo a mesma função. Não seria interessante incorporar essa validação nos fontes do acbrvalidador?

É possível @BigWings?

Abraço.

[simons]

da uma olhada nessa tabela se o prefixo dos ean estão nela, http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=mpYVEbsVRuE=.

[Igor Bastos]

  Em 25/06/2018 at 16:16, simons disse:

da uma olhada nessa tabela se o prefixo dos ean estão nela, http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=mpYVEbsVRuE=.

Expandir  

@simons na época trabalhei em cima desse XLS (que no meu ponto de vista não ajudou muito), demorei horas de análise do XLS e testes até chegar em uma solução viável.

 

  Em 25/06/2018 at 14:38, Riquena disse:

Igor Bom dia.

Também estou desenvolvendo a mesma função. Não seria interessante incorporar essa validação nos fontes do acbrvalidador?

É possível @BigWings?

Abraço.

Expandir  

Apesar de eu achar que seria interessante ter essa função no fontes, entendo a dificuldade de implementá-la, visto que é uma tabela externa (pelo que entendi de utilização e atualização mundial) e pode ser atualizada constantemente. Imagina a dificuldade para os desenvolvedores manterem ela atualizada o tempo todo para suprir nossas necessidades?! O custo/benefício não vale a pena.

 

@Riquena, se quiser eu posto minha solução, mas ficou bem simples mesmo.

[simons]

e qual seria a solução viavel?

[Igor Bastos]

 

  Em 26/06/2018 at 12:58, simons disse:

e qual seria a solução viavel?

Expandir  

 

  Em 18/05/2018 at 15:48, Igor Bastos disse:

Solução que desenvolvi:

Fiz uma função de validação do Prefixo GTIN (baseado na Tabela de Prefixos da GS1 e nesse link), coloquei o retorno como Aviso, ou seja, não impedirá de transmitir a NFe e permitirá que o usuário escolha entre não transmitir para corrigir ou transmitir com os Avisos.

Nos casos em que realmente não são validados localmente (por exemplo se retornar erro no ACBr.ValidarGTIN), retorna erro real e impede de transmitir. Se o usuário decidir transmitir msm com os Avisos, pode ser que retorne os erros da SEFAZ, daí é com o usuário trabalhar nas alterações manuais dos EANs.

Expandir  

Minhão opinião de Solução Viável!