BigWings

Teste com o arquivo anexo por favor. DACTE_Retrato.fr3

Analisando melhor, o XML que você anexou não é o XML da NFe e sim o XML NFeDFe que agrupa o XML da NFe e a lista de eventos do mesmo: Ele é gerado com a extensão *-NFeDFe.xml. Você deve ter também um XML *-nfe.xml que é o XML da NFe com o protocolo de autorização apenas. O ACBr está montando normalmente o arquivo para os dois estados, mas como o retorno de MG vem fora do padrão (contendo os prefixos ns0:) acaba tornando o XML inválido. Fazer uma reclamação na SEFAZ-MG a respeito dos prefixos, ou retirar manualmente os mesmos.

Não entendi. O XML que você anexou está modificado. O correto na verdade é deixar essa propriedade como False, ela existe apenas por compatibilidade com versões antigas da NFe onde ainda não existia o cancelamento por eventos. O correto é manter o XML original inalterado, apenas armazenar também o XML do evento de cancelamento.

Esse já é outro caso, já foi corrigido.

Se você tem a propriedade AtualizarXMLCancelado ativada, o ACBr vai alterar o XML da nota inserindo o protocolo de cancelamento. O problema é que a SEFAZ-MG está retornando indevidamente prefixos ns0: para as tags do XML no retorno da consulta. Isso faz com que o XML final montado pelo XML fique inválido.

Como parece ter ficado claro no tópico, caso haja essa rejeição é porque a SEFAZ encontrou IE ativa para o CNPJ informado. Basta informar a IE e indIEDest como 1.

Por favor, atualize os fontes e faça novo teste. Foi enviado um ajuste para uso do ACBr com Lazarus em 64 bits.

O primeiro XML que anexou não tem o procotolo. O segundo não é o XML de um MDFe, e sim o retorno da consulta de situação do mesmo. Você precisa do XML do MDFe completo, com o protocolo de autorização, e fazer o encerramento por ele. Se tem o protocolo em banco de dados, pode informar o mesmo antes de executar o método de encerramento, veja a rotina de encerramento por chave do demo.

Como se trata de DANFE NFe essa propriedade realmente não era utilizada, nem fazia sentido manter. Foi sim removida e mantida apenas para os componentes NFCe.

A mensagem indica que não foi informado o protocolo de autorização, que é obrigatório no pedido de encerramento. Se está encerrando pela chave deve informar também o número do protocolo. Se está encerrando pelo XML verifique se o mesmo contém o protocolo de autorização.

O MA usa SVAN para NFe e SVRS para NFCe. A imagem mostrada no primeiro post mostra endereço da SVRS. O MDFe também todos os estados são atendidos pela SVRS. Se está copiando as DLLS MinGW, fez alteração no ACBr.inc para ativar a diretiva {$DEFINE USE_MINGW}? Para qual diretório está copiando as DLLs? Em se tratando de Lazarus já tem menos usuários... pode ser algo relacionado ao ambiente Lazarus e 64bits...

Atualizei agora e parece normal: Veja se o objeto que está tentando alterar é realmente da classe ACBrNFeDANFCeFortes.

A SVRS que é usada pelo MA para NFCe também é usada na maioria dos estados do Brasil. Então é estranho que só você esteja com problemas... Como está configurando as propriedades SSLLib? Como copiou as DLLs da OpenSSL/LibXML/XmlSec? Já tentou isolar a conexão de Internet? Usando uma ponte 3G/4G por exemplo? Vi que está testando pelo demo... anexe os arquivos XML *-ped-eve.xml

A propriedade se chama ImprimeEmUmaLinha. Foi renomeada há quase um ano:

Na minha interpretação desse trecho, significa: vProd = 121,95, vNF = 100,00 ==> vProd contém o valor do ICMS desonerado a ser subtraído ==> deve subtrair vProd = 100,00, vNF = 100,00 ==> vProd não contém o valor do ICMS desonerado, ou seja, já está considerando o abatimento ==> não deve subtrair A palavra CASO é onde entendi que pode ser feito da primeira forma. O resultado será o mesmo, de qualquer forma.

Na parte em que diz que foi considerada a exceção 3 da regra de validação.

Quando você subtrai o valor do ICMS desonerado precisa fazer o cálculo inverso pra saber o valor que o produto teria sem a desoneração, e informar no vProd. Digamos que uma mercadoria é precificada a R$ 100,00, com CST 40, nela o vendedor já está considerando a desoneração de 18% de ICMS. Subtraindo a desoneração do total da nota: vProd = 100,00 / (1 - 0,18) ==> 100,00 / 0,82 ==> 121,95 vICMSDesonerado := 21,95 vNF = 100,00 Não subtraindo a desoneração, precisa calcular apenas o vICMSDesonerado, e informar vProd e vNF = 100,00. Na minha interpretação da resolução, o correto é não subtrair, mas não proíbe expressamente fazer da primeira forma.

Sobre a TRetConsReciCTe, veja: A TRetConsStatServ ainda existe nos fontes, na unit pcnRetConsStatServ.pas.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

O ajuste sugerido pelo @Daniel Simoes foi aplicado no repositório. Favor atualizar novamente os fontes e testar.

Qual cidade/provedor? Já tentou informar o código do IBGE da cidade em vez do literal do nome?

O método DistribuicaoDFe não permite que o próprio emitente baixe o XML novamente. Apenas o destinatário, transportador e terceiros informados na tag autXML podem se utilizar do serviço para baixar o XML. O emitente vai receber pelo método DistribuicaoDFe os eventos emitidos pelo destinatário ou pelo fisco referentes as notas que emitiu, por exemplo, a manifestação do destinatário.

Favor anexar o XML para teste.

Deve ser informado o número, a série e a chave da nfe cancelada, além do código de situação e indicação de tipo de emissão própria ou terceiros. Os demais campos em branco. Se está informando dessa forma e tendo erro, favor mostrar qual erro está sendo mostrado.

Acredito que seja a NT 2016.002 v1.61.