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]

31 minutos atrás, 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.xml

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]

4 minutos atrás, 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>

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]

1 hora atrás, Igor Bastos disse:

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

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]

1 hora atrás, 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.

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

[BigWings]

32 minutos atrás, Igor Bastos disse:

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

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]

7 minutos atrás, Igor Bastos disse:

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

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]

13 horas atrás, 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).

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

1 hora atrás, Dércio Luis Zanatta disse:

Bom dia

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

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

11 horas atrás, Igor Bastos disse:

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

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]

1 minuto atrás, Igor Bastos disse:

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

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]

15 minutos atrás, Igor Bastos disse:

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

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]

7 horas atrás, 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=.

@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.

 

8 horas atrás, 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.

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]

 

1 hora atrás, simons disse:

e qual seria a solução viavel?

 

Em 18/05/2018 at 12: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.

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