BigWings

Você sempre pode usar a opção "Update to revision" do Tortoise para voltar para uma versão anterior dos fontes. Só precisa saber qual era a revisão anterior que tinha, ou seja, qual a última atualização que tinha feito antes de perceber o problema. Como você pode ver próprio tópico que citou, o problema com os caminhos UNC já tinham sido identificados em março, sendo que a opção xsLibXML2 para SSLXMLSignLib foi criada em dezembro, não foi coisa de uma semana ou um mês atrás. Uma pergunta: você configurava explicitamente a propriedade SSLXmlSignLib? Ou apenas definia SSLLib como libWinCrypt e deixava ela definir as demais? Pergunto porque até um tempo atrás com SSLLib = libWinCrypt, a propriedade SSLXmlSignLib era definida como xsMsXML e depois passou a ser xsLibXML2. Com xsMsXML esse problema não ocorre.

Anexe o log do instalador.

Se acha que foi após a atualização dos fontes do ACBr, volte para a versão anterior e teste.

Como explicado no tópico que foi encerrado, isso é uma limitação da libxml2.dll. Você terá o mesmo problema, com uma mensagem de erro diferente, caso use xsXmlSec. O que você pode fazer: - Mapear o caminho de rede para uma letra de unidade nas estações e informar a propriedade PathSchemas do componente com a letra de unidade mapeada; - Incluir uma rotina no seu aplicativo para copiar automaticamente os arquivos de schema para uma unidade local; - Usar XMLSignLib = xsMSXML (desaconselhado por ter problemas sérios com certificados A3); - Colaborar com o desenvolvimento da libxml2 introduzindo o suporte a caminhos UNC. http://xmlsoft.org/downloads.html

Nesse caso o erro é por duplicidade com uma NFCe emitida em 15/10/2018:

O componente já lê esse retorno, descompacta o XML das notas e se o componente estiver configurado para tal, salva os XML em disco. Para saber o tipo do retorno, veja minha resposta neste tópico: Usando a mesma lógica, o XML do documento retornado você pode acessar pela propriedade: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items.XML

Você está informando município de descarregamento em UFs diferentes. <cMunDescarga>3170206</cMunDescarga><xMunDescarga>UBERLANDIA</xMunDescarga> <cMunDescarga>3304904</cMunDescarga><xMunDescarga>SAO GONCALO</xMunDescarga> Para cada UF de entrega da carga é preciso emitir um novo MDFe.

O erro é retornado pela SEFAZ ou no momento da validação local pelo ACBr? Anexe os arquivos de envio e retorno do webservice para análise.

Provavelmente está com a pasta de Schemas desatualizada mesmo. Verifique tambse está configurando a propriedade PathSchemas do componente corretamente.

DF-e / WebServices / NF-e/CT-e/MDF-e [ ] Salvar Arquivos Enviados/Recebidos p/WebServices

Essa mensagem é retornada pela SEFAZ, não quer dizer que o ACBr gerou essa chave. Como disse mais acima, acredito que a SEFAZ está gerando a chave com o mês anterior, caso informe data e hora próxima a virada do mês, por causa do fuso horário a nota cai no mês anterior ou posterior. Caso informe hora 00:00:00 e esteja com o fuso horário incorreto já foi mostrado pelos demais colegas que causa o erro. Anexe os arquivos de envio e retorno da SEFAZ.

Interessante. Parece que o problema ocorre em virada de mês, nas horas finais ou iniciais do dia. Dependendo o fuso horário a SEFAZ-GO pode estar interpretando que a nota foi emitida num mês ou no outro, o que alteraria a chave de acesso da nota. Alguém tem os XML de envio e retorno com essa rejeição?

Esse pacote é dependente do Fortes Report. https://www.projetoacbr.com.br/forum/announcement/12-novo-fortes-report-ce-e-projeto-acbr/ Se você não tem o Fortes instalado, desmarque no instalados as opções referentes a ele.

Veja o tópico abaixo:

Você pode usar a tag de informações complementares para informar a quantidade total, será impresso no rodapé do DANFE NFCe.

Não, a implementação atual segue a determinação do manual: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=/xyXbAFZ71k=

Veja minha resposta no tópico abaixo:

Veja qual componente DANFE está associado ao ACBrNFe, alguns deles são específicos para NFCe.

Como você está informando a propriedade PathSchemas?

Se você recebeu o resumo da NFe, então ela é destinada ao CNPJ informado. Se você recebeu a NFe completa, carregue o XML no componente ACBrNFe e verifique a propriedade ACBrNFe1.NotasFiscais.Items[0].NFe.Dest.CNPJCPF.

Está configurando a versão do componente para o layout 4.00? ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400;

Não há como fazer o que quer pelo FormatDateTime. Uma forma de fazer seria usando o componente ACBrExtenso. uses ACBrExtenso; [...] function DataPorExtenso(const AData: TDateTime): String; var ACBrExtenso: TACBrExtenso; Y, M, D: Word; begin ACBrExtenso := TACBrExtenso.Create(nil); try ACBrExtenso.StrMoeda := ''; ACBrExtenso.StrMoedas := ''; DecodeDate(AData, Y, M, D); Result := Trim(ACBrExtenso.ValorToTexto(D)) + ' de ' + FormatDateTime('mmmm', AData) + ' de ' + Trim(ACBrExtenso.ValorToTexto(Y)); finally ACBrExtenso.Free; end; end;

Você pode verificar o tipo do documento no retorno do método DistribuicaoDFe. ACBrNFe1.DistribuicaoDFe(cUF, CNPJCPF, UltNSU, ''); case ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.cStat of 138: begin for I := 0 to ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count - 1 do begin case ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[I].schema of schprocNFe: ; // NFe completa schresNFe: ; // resumo da NFe schprocEventoNFe: // evento schresEvento: // resumo de Evento [...]

Apliquei essa correção ontem, inserindo a validação pelo protocolo, para não mostrar mais a mensagem quando a NFCe já está autorizada. Você afirma que mesmo com a correção, continua aparecendo a mensagem de pendente de autorização? Se sim, por favor, informe quando arquivo .fr3 está usando e anexe o XML.

Aqui tem uma forma localizar o número de série do certificado pelo CNPJ, você pode adaptar o método para procurar pelo SubjectName: Note que o SubjectName pode mudar caso seja um novo certificado.