JSantos

Acho que o ideal seria entrar em contato com o fabricante destes produtos e verificar se o mesmo possui registro de inscrição no GS1. Se não tiver registro, usar SEM GTIN. Se tiver, entrar em contato com a Receita e pedir para eles corrigirem mais esta palhaçada. Será que o fabricante não trocou o 8 e o 9 de posições não??? rsrsrs

Sim, nós usamos também para alertar o usuário. A tabela vc pode obter direto no portal da NFe. Segue o link: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=mpYVEbsVRuE=

@licerio, Na tabela de prefixos que tenho aqui, códigos iniciados com 751 (no seu exemplo 7513206660259) não são válidos. Veja o trecho da tabela próximo a este código: CTRGTI_DfTb(746,746,"GS1 Republica Dominicana") CTRGTI_DfTb(750,750,"GS1 Mexico") CTRGTI_DfTb(754,755,"GS1 Canada") CTRGTI_DfTb(759,759,"GS1 Venezuela") Bem provável que seja esse o problema.

Boas Notícias !!! Em SP está autorizando NFe com vDesc = 0.00 (Fatura) em ambiente de produção. Isso significa que não será preciso esperar a SEFAZ virar a chave para mudarmos configurações (poupa um desconforto enorme com suporte de madrugada!!!) Se vai rejeitar quando esta tag não for enviada a partir de 03/09 é um outro mistério. Já estamos alterando nossos sistemas aqui.

Pessoal, abri esse tópico para levantar uma possível paralisação dos sistemas de NFe, com relação a tag vDesc do grupo Cobrança. Até onde sei, se informarmos a tag vDesc com valor '0.00' recebemos hoje uma rejeição. Porém, segunto a NT 2016/002 V1.60, a partir de 03/09/2018 haverá rejeição se essa tag não for informada (mesmo com valor '0.00'). Se isso ocorrer desta forma, teríamos que modificar nossos sistemas no momento exato em que a alteração for feita pela SEFAZ e seria inevitável a paralisação para ajuste. Pergunto: Hoje em SP, estão sendo aceitos XMLs em produção com a tag vDesc com valor '0.00' no grupo Cobrança? (Se sim, teríamos um tempo de coexistência das duas possibilidades para uma transição normal sem interrupções).

A NFe 3.10 deve continuar no ar para não revelar a farsa bolinhas verdes ... Se a NFe 3.10 sair do ar, ficará evidente que as bolinhas verdes quase sempre mentem com relação ao status do serviço. Vejam vcs são 18h59 do dia 02/08 e as bolinhas verdes estão lá firmes e fortes (com exceção da Bahia é claro que eles colocaram em vermelho no intuito de nos confundirem).

Começou a aceitar o evento de ciência por aqui, mas está levando de 6 a 10 segundos para cada documento.

Porque eu quero deixar meu coração funcionando para outras coisas!!!

Pessoal, Erro ocorrendo na operação de registro de evento de ciência. Outros tipos de erros ocorrendo também de forma aleatória: 12002 - TimeOut de Requisicao 999-Rejeicao: Erro nao catalogado 2254 - Falha na validação de esquema Xml 2220 - Falha na conexao com o banco de dados Componente configurado para ve400 (Versão 4.00) Mais alguém por aí com o mesmo problema?

Pessoal, cuidado com relação a NFe 4.00 e protocolos. De acordo com especificação, os WS da NFe 4.00 só irão funcionar com protocolo TLS 1.2 ou maior. De acordo com essa especificação o SSL não irá funcionar. Amanhã (02/08/18) o SSL não será mais aceito para processamento da NFe.

Vale a pena investigar o XML que vc está submetendo à consulta. Se o monitor indica que o Digest Value não confere, pode ser que existe divergência entre o XML exposto à consulta e o XML que foi autorizado anteriormente.

Pessoal, Para funcionar o TLS 1.2 no Windows 7 é necessário que as atualizações estejam em dia ok? (SP1 + Atualizações).

Michel, Vc está procurando uma tabela desse tipo para obter o código GTIN ou obter NCM e CEST? Se for para obter o código GTIN eu acho muito difícil, já que NCMs e CESTs são códigos gerais e GTIN é um código por fabricante e produto. Dessa forma, para um mesmo NCM vc pode ter diversos GTIN.

Houve mudança sim... a constante "_C" que vc usa está comentada no código original. tem um trecho no código da unit ACBrMonitor1 que faz um tratamento para uso de uma variável fsHashSenha, veja se ajuda para entendimento { Lendo Senha } fsHashSenha := StrToIntDef(HashSenha, -1); if (fsHashSenha < 1) then { INI antigo não tinha essa chave } begin wSenha := Senha; if (wSenha <> '') then fsHashSenha := StringCrc16(wSenha); end; if (fsHashSenha > 0) then begin cbSenha.Checked := True; edSenha.Text := 'NADAAQUI'; end;

Olá, não seria melhor vc rodar uma instância do monitor para cada empresa?

Olha, desde a história do CEST, do DIFAL eles só têm crescido em uma coisa - A INSEGURANÇA que eles conseguem nos transmitir com atualizações. Tá faltando regra e respeito desse pessoal com a gente... e faz tempo!

Oá @systux Obrigado pela resposta! No xml que vc está gerando em produção para SEFAZ-SP está presente a tag vDesc com valor 0.00 dentro do grupo Fatura? Parece que isso está dando problema meio que geral para os outros usuários veja aqui Abraço!

Alguém sabe informar se a tag vDesc está sendo aceita com valor 0.00 no ambiente de produção da SEFAZ-SP ?

Diante dessa postergação, seria bem razoável estenderem novamente o prazo da 3.10. Que bagunça que esses caras fazem!

Realizando testes com NFe 4.0 SEFAZ SP, observei rejeição quando a tag fatura/vDesc não estava presente no XML. Provavelmente a NT não está correta em indicar que a ocorrência das filhas de fatura seriam 0-1, acredito que o correto seria 1-1. pcnNFeW.pas

Segue uma sugestão para implementação do comando setmodelo no objeto POSPRINTER. DoPosPrinterUnit.pas

Tente dar um CLEAN BUILD se não funcionar, tente abrir os formulários que contém o componente NFe para edição, provavelmente neste momento vc terá a opção IGNORE

Como vc está preenchendo o campo "cNf"?

Seja o que for que aconteceu, foi temporário. Aparentemente voltou ao normal, exigindo TLSv1.2.

Testei aqui agora e todos esses protocolos estão funcionando com a NFe 4.00 em Produção e Homologação (Status do Serviço) Peguei até uma máquina virtual com Windows XP e funcionou. Alguém consegue verificar isso agora por favor? Qual seria o motivo? Será que desistiram de usar somente TLS1.2?