BigWings

Está passando o "role" RDB$ADMIN ao conectar no banco com o novo usuário?

Verifique se está informando a hora e fuso horário de emissão corretamente: <dhEmi>2018-11-07T23:03:00-03:00</dhEmi> Já houve relatos no fórum de problemas com o webservice de GO com notas com emissão próxima a virada do mês, acredito que possa ser o mesmo problema, dado o fuso horário diferente do webservice ele pode estar esperando que a data de emissão seja na verdade no dia 08 nesse caso.

Faça a consulta pela chave de acesso e veja o conteúdo da tag qrCode, e compare com a URL que foi lida do QRCode impresso no DANFE.

Não, a única forma de visualizar os dados da NFCe pela chave de acesso é via consulta pública no portal NFCe no site da SEFAZ estadual.

Não. A consulta por chave traz somente os dados referentes ao protocolo de autorização de uso e informações do evento de cancelamento, se houver.

Usando o CSOSN900 todas estas tags deveriam aparecer no XML, então acredito que haja algo de errado na sua rotina.

Verifique se a pasta de Schemas e DLLs estão atualizadas.

Esses são alertas gerados pelo ACBr, na imagem não é possível ver o erro de validação real. Anexe o XML.

Na coluna 109 do segmento P deve constar o tipo de aceite "A" ou "N". No seu arquivo de remessa ele não está sendo gerado. Verifique o TXT enviado ao ACBrMonitorPLUS.

Não entendi se o problema está ocorrendo também em produção... Além de alterar para httpWinHttp, não tenho nada a sugerir.

Está testando em homologação ou produção? Que saiba GO nunca funcionou com OpenSSL em homologação.

A diferença está no campo COD_SIT que nesse arquivo foi informado como 08 - Documento Fiscal emitido com base em Regime Especial ou Norma Específica.

Agora ficou mais claro... Achei que estava sendo gerado o registro C176 no TXT, o que não é o caso. O validador está esperando o registro C176 pois foi informado o C170, que não deve ser feito em caso de NFe de emissão própria. Veja a exceção do guia prático versão 2.0..22, página 41, referente ao registro C100:

Não entendi o que validar no PVA faria diferença, mas sim, validou normalmente o txt gerado pelo demo do ACBr. Coloque um breakpoint na unit ACBrEFDBloco_C_Class.pas, no início do método: function TBloco_C.RegistroC176New: TRegistroC176; E rode o debug, se ele parar no método é porque está sendo chamada a geração do registro, basta analisar o callstack para saber qual rotina está fazendo isso.

Fiz teste com o demo do ACBr e gerou normalmente o registro C170 sem o C176. Provavelmente é algo na sua rotina que está explicitamente fazendo a geração do registro.

Evite usar essa configuração pois ela é baseada na msxml5.dll que está depreciada pela MS e segundo relatos aqui no fórum é a responsável por esse problema. Prefira usar SSLXmlSignLib = xsLibXML2.

Qual configuração SSLXmlSignLib está usando?

É o correto, nada mais a fazer.

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.