BigWings

Veja o aviso no portal do MDFe:

As DLLs da pasta MinGW substituem essas da pasta LibXML2, você pode usar libWinCrypt normalmente. Veja a unit libxml2.pas: {$IFDEF MSWINDOWS} {$IFDEF USE_MINGW} LIBXML2_SO = 'libxml2-2.dll'; {$ELSE} LIBXML2_SO = 'libxml2.dll'; {$ENDIF} {$ELSE} LIBXML2_SO = 'libxml2.so'; {$ENDIF} Com MINGW ativado, a libxml2.dll não é usada, mas sim a libxml2-2.dll.

Invertido. Dessa forma você só poderá usar CAPICOM e MSXML, já que está desativando OpenSSL, XmlSec e LibXML2. Você não precisa dessas DLLs se vai ativar MinGW. Contei 12 DLLs aí, na pasta ACBr\DLLs\XMLSec\MinGW\32 (assumindo que vai compilar para 32 bits) tem 14, você deve distribuir todas elas junto a sua aplicação.

3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. Favor leia as regras do fórum.

Qual o erro usando WinCrypt?

Apesar do OpenSSL ter mais indicado, por não depender do Windows, você pode usar certificado A1 com qualquer configuração do ACBr. Basta configurar as propriedades ArquivoPFX e Senha.

Veja este tópico:

Use o enumerado para a configuração da versão do QrCode. ACBrNFe1.Configuracoes.Geral.VersaoQrCode := veqr200; Ainda está usando QrCode 1.00? Você pode alterar o ACBrNFeServicos.ini, incluindo a tag URL-ConsultaNFCe_1.00 e removendo o "s" do https: [NFCe_PA_H] Usar=NFCe_SVRS_H URL-QRCode=https://appnfc.sefa.pa.gov.br/portal-homologacao/view/consultas/nfce/nfceForm.seam URL-ConsultaNFCe=https://appnfc.sefa.pa.gov.br/portal-homologacao/view/consultas/nfce/consultanfce.seam URL-ConsultaNFCe_1.00=http://appnfc.sefa.pa.gov.br/portal-homologacao/view/consultas/nfce/consultanfce.seam URL-ConsultaNFCe_2.00=http://www.sefa.pa.gov.br/nfce/consulta A tag URL-ConsultaNFCe_1.00 seria usada para NFCe 4.00 com versão do QRCode 1.00. Após alterar o ACBrNFeServicos.ini, execute o Compila_RES.bat para gerar o ACBrNFeServicos.res e recompile a sua aplicação.

Já temos a explicação de como o aplicativo gratuito consegue retornar a situação da manifestação: se trata de uma funcionalidade não documentada, a famosa gambiarra, por parte da SEFAZ-SP.

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;