BigWings

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.

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.

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

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.

Corrigido no svn.

Tem um (longo) tópico sobre esse assunto:

Pode estar relacionado com o assunto deste tópico:

Isso é alguma instabilidade no webservice da SEFAZ-MG: Fiz teste de envio do teu XML e aconteceu como você disse, hora funcionava com a rejeição do NCM, hora retornava o seguinte XML: Arquivo: *-rec-soap.xml. <?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Unmarshalling Error: Unexpected close tag </COF>; expected </COFINSOutr>. at [row,col {unknown-source}]: [1,8186] </soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope> Quando o retorno do webservice vem em formato não esperado pelo ACBr, ocorre a mensagem de exceção em branco.

Atualize os fontes.

Provavelmente é (mais um) problema com a SEFAZ.

Além do .ini desatualizado, nenhuma ideia. Tente o debug.

Enviei alteração para o repositório para gerar novamente os campos: Favor atualizar os fontes e testar novamente.

Está usando o DANFE em FastReport? Qual arquivo .fr3 está carregando?

O seu arquivo está correto. Faça o teste informando a configuração de versão do QR-Code no componente: ACBrNFe.Configuracoes.Geral.VersaoQrCode := veqr100; Veja também se não há um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação.

A rejeição só passou a existir a partir dessa versão da NT. O problema é que não é esclarecido sobre o que é um número de parcela válido ou não. Em outro tópico há orientação de se informar em sequencial numérico, com 3 algarismos, "001", "002", "003" e assim por diante.

A resposta não faz sentido já que a mensagem de rejeição foi introduzida na NT 2016.002 v. 1.50. Se a SEFAZ não implantou as novas regras, a rejeição não deveria existir. Quanto aos prazos de implantação, homologação e produção foram prorrogados para 21/05 e 04/06, respectivamente, então ainda pode haver novos atrasos.

Como estão as configurações SSL?

Se está usando o DANFE em FastReport use o arquivo DANFENFCe4_20.fr3.

Tente informar cOrgao = 91 para a manifestação. Ao contrário dos outros eventos, a manifestação do destinatário é enviada ao ambiente nacional e não à SEFAZ do estado.

A mensagem de contingência é normal visto que ela é gerada no XML no momento da emissão. Mas esse modelo de DANFE NFCe é antigo e não é mais usado no componente.

O arquivo está validando normalmente. Tente atualizar a pasta de Schemas.

Como CAPICOM depende das configurações do Windows é preciso ver se o mesmo tem suporte a TLS 1.2 que é obrigatório na NFe 4.00. Windows XP e 2003, por exemplo, só funcionarão com OpenSSL. E Windows 7 ou 2008, em muitos casos aqui no fórum foi necessário fazer as atualizações de segurança.

O arquivo está validando normalmente. Atualize a pasta de Schemas.

Esse erro pode ocorrer se você estiver enviado um XML da NFe 3.10 para um webservice da 4.00 ou vice-versa, então é possível que você esteja forçando a geração do XML na versão errada ou esteja com o arquivo .ini desatualizado nos fontes do ACBr ou no diretório da aplicação.