BigWings

Pela regra de validação N23d-10, o cálculo do vFCPST deve se a multiplicação entre o vBCFCPST e pFCPST, descontando o valor o vFCP. Assim: <vFCP>0.80</vFCP> [...] <vBCFCPST>86.59</vBCFCPST> <pFCPST>2.0000</pFCPST> <vFCPST>3.72</vFCPST> O valor correto do vFCPST deveria ser 86.59 * (2/100) - 0.80 = 0,93. Aqui o vFCPST seria 0,00.

Tópico dividido e movido por se tratar de assunto específico.

Sempre fiz pelo Windows Update, nunca tentei a instalação off-line.

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

Você precisa atualizar o IE no PC e inserir as chaves no registro para o TWebBrowser emular a versão mais nova.

Na aba certificado do demo você deve definir uma configuração CryptLib diferente de cryCapicom, já que este não tem suporte a SHA256.

Tentou fazer o que diz a mensagem?

Campos opcionais vazios não são gerados no XML. E o grupo card deve ser informado dentro do grupo detPag. Pode haver no máximo um grupo card para cada detPag. Para a leitura correta do indPag você deve usar uma versão atualizada do ACBrMonitorPLUS.

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.

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