BigWings

Realmente não faz sentido se realmente está setando essa configuração. Use o debug.

Se a NFCe foi emitida em contingência, a observação no DANFE deve aparecer, de acordo com o manual. Não há necessidade de reimprimir o DANFE após a autorização da nota, nenhuma previsão quanto a isso no manual.

Acho que não. Tem um PDF na raiz dos fontes com a hierarquia de dependência dos pacotes. Você pode abrir os arquivos .dpk da pasta Pacotes\Delphi na sequencia descrita no PDF e usar a opção Compilar e, quando a opção estiver disponível disponível, Instalar.

Você está usando uma versão trial do Delphi: Essa versão não suporta compilação por linha de comando, então o instalador não vai funcionar. Você pode instalar os pacotes manualmente, ou experimente baixar o Delphi Community Edition, que tem o suporte. Se você tem uma licença do Delphi, baixe um .iso não-trial para instalação.

As URL com o sufixo "-nac" são um serviço da SEFAZ-AM que permitem que desenvolvedores de todo o país possam testar os webservices da NFCe em homologação, usando certificado digital próprio. Com as URL sem o sufixo, apenas certificados digitais com inscrição estadual no AM podem consumir os webservices. Você pode editar o arquivo ACBrNFeServicos.ini e copiar ele para o diretório da aplicação, ou executar o arquivo Compila_RES.bat que vai gerar o ACBrNFeServicos.res. O arquivo res vai ser usado pelo compilador para incluir as URL no executável. Talvez você tenha que copiar os arquivos ACBrNFeServicos.* da pasta Source para a pasta Lib\LibXX caso use essa opção no instalador.

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:

A tag dhIniViagem tem nível 2 então no XML ela vai estar no grupo de nível 1 acima dele, que é Ide. Acredito que o manual esteja incorreto também, afinal nos fontes ele é lido desse grupo também: Ide.dhIniViagem := StringToDateTime(INIRec.ReadString('ide', 'dhIniViagem', '0')); Um adendo: lembre que o campo dhIniViagem é data e hora, então a hora de início da viagem também deve ser informada: Como exemplo, tente informar no .ini: [Ide] dhIniViagem=04/02/2017 10:30:00

Veja a página: https://www.sefaz.rs.gov.br/NFE/NFE-CER.aspx

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.