BigWings

Também já houve relatos de acontecer esse erro caso esteja usando DLLs desatualizadas.

@Italo Jurisato Junior Na verdade nenhum deles usa o layout ABRASF. Havia uma implementação anterior para o provedor Agili que era baseado no ABRASF, mas quando tive que fazer a implantação em Ariquemes tive que criar uma unit separada para geração do XML. Quando foi feito o ajuste para funcionar também em Sorriso e outras cidades que tinham o mesmo provedor mas layout diferente por causa da diferença de versão acabou ficando o layout de Sorriso com o "v2".

Sorriso usava anteriormente o provedor Agiliv2 que na verdade era uma versão mais antiga do sistema de NFSe deles. Agora houve uma atualização e agora estão usando o provedor Agili. O erro retornado é o erro genérico deles, pode ser algum problema no próprio webservice ou alguma informação incorreta no XML que eles não estão tratando. Já tive esse erro por não informar base de cálculo e informar alíquota, ou vice-versa, por exemplo. O mais indicado ainda é entrar em contato com o suporte através da prefeitura, para que possam validar o XML.

Apenas lembrando: Se o campo referente ao valor do IPI devolução está sendo gerado no XML, e impresso no DANFE como informações complementares, não vejo o porquê ser recusada. Provavelmente é falta de atualização do fornecedor ou seu contador com o novo layout da NFe. Se você sabe que não é o correto, na minha opinião já tem a sua resposta. Ainda estará correndo o risco de ter a empresa autuada por imprimir informação no DANFE que não consta no XML (no caso a tag vIPI estará zeradada e o campo destinado a ela no DANFE terá valor).

Estão na pasta ACBr\Exemplos\ACBrDFe\Schemas\NFe.

Qual componente DANFE está usando?

Qualquer alteração no código de barras altera o DV geral. Corrija o vencimento e provavelmente ele será ajustado.

Está com os fontes atualizados? As URL para GO foram atualizadas recentemente no arquivo ACBrNFeServicos.ini.

A única diferença nesses códigos de barras é o fator de vencimento. Foi usada a mesma data de vencimento na comparação?

Além de definir o tpEmis do XML, o arquivo também deve ser enviado para o webservice correto. Isso é feito configurando o componente: ACBrNFe1.Configuracoes.Geral.FormaEmissao := teSVCAN;

Pelo erro é um problema na SEFAZ, que não está validando, aparentemente, o XML de retorno. E especificamente num campo do tipo TRec (Número do recibo). Esse campo não é gerado no retorno quando em modo síncrono. Analise o XML retornado pelo webservice, anexe aqui se desejar. Veja também se o mesmo erro ocorre se usar o modo assíncrono.

Validou normalmente aqui. Veja se a sua pasta de Schemas está atualizada.

O mesmo problema ocorre usado o demo do ACBrNFe? Pela mensagem, parece estar havendo quebra de linha no lugar dos pipe "|" separadores dos campos do QRCode. Pode ser alguma configuração especial ou alteração sua nesse sentido. De qualquer forma, anexe o arquivo XML gerado.

A causa mais comum para esse erro é a configuração da pasta de Schemas estar no formato \\servidor\compartilhamento. A libxml2.dll tem problemas para localizar os arquivos usando esse formato. Se os schemas estão em uma pasta compartilhada na rede, você pode mapear para uma letra de unidade. O XML validou normalmente aqui.

Muito simples: Adaptando um pouco o código do demo do ACBrNFe: NotaF.NFe.Total.ICMSTot.vNF := 100; [..] // YA. Informações de pagamento Pagamento := NotaF.NFe.pag.Add; Pagamento.indPag := ipVista; Pagamento.tPag := fpCheque; Pagamento.vPag := 150.00; NotaF.NFe.pag.vTroco := 50.00;

O QRCode deve ser mostrado para o consumidor, seja na impressão do DANFE ou em tela para permitir que ele faça a consulta da nota. Se entendi bem, você esperava que aparecesse a imagem do QRCode na página de consulta da SEFAZ, isso não acontece, nem há necessidade.

Peça para o contador emitir a nota em homologação. Se autorizada, veja em qual exceção à regra ela se enquadra.

Essa regra foi alterada na versão 1.61 da NT. Ela agora aplica-se somente a NFCe. E como não existe NFCe sem pagamento, ou NFCe de ajuste ou devolução as exceções da regra não fazem sentido.

Analisando o código não encontrei base nas notas técnicas que suportassem a lógica usada. Subi para o svn minhas próprias correções de acordo com a NT para as validações. Favor atualizar os fontes e proceder com os testes.

Obrigado por reportar. Para novas dúvidas crie novo tópico.

Não foi gerado o arquivo LOG.txt após a execução do comando?

Anexe o log.

Segundo a NT 2016.002 v.1.61: Em relação a NFC-e, os prazos previstos são: - Desativação do versão 3.10 do leiaute da NFC-e: 01/10/2018; - Layout do QR-Code (tag: qrCode, Id:ZX02), versão “2.00”: - Ambiente de Homologação: 04/06/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Ambiente de Produção: 02/07/2018 (aceita NFC-e na versão 4.00 com o leiaute do QR-Code na versão “1.00” e versão “2.00”); - Desativação da versão “1.00” do QR-Code em produção: 01/10/2018. O QRCode é gerado no XML, dependendo da tag tpEmis. A impressão no DANFE NFCe é feita de acordo com o XML.

MG? Veja o tópico: