BigWings

Nesse caso não devia estar carregando essa URL. A URL correta conforme definida no ACBrNFeServicos.ini: [NFCe_SVRS_H] [...] NfeConsultaProtocolo_4.00=https://nfce-homologacao.svrs.rs.gov.br/ws/NfeConsulta/NfeConsulta4.asmx Tente o debug.

Essa URL é de versões antigas da NFe e já foi desativada. Veja se está configurando a versão do layout do XML corretamente. ACBrNFe1.Configuracoes.Geral.VersaoDF := ve400;

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.

No grupo [infCIOT001] o campo CPFCNPJ está com o nome errado, o correto é CNPJCPF.

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.

Para MDFe use esta página: https://mdfe-portal.sefaz.rs.gov.br/site/validadorxml

Parece tudo certo com o arquivo. Validando conta os schemas do ACBr validou normalmente, já no validador da SEFAZ-RS acusou erro por o emitente ser CPF: Você já havia conseguido fazer encerramento de MDFe sendo o emitente CPF? Pode ser apenas uma falha do validador, em todo caso tente contato com a SEFAZ.

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:

Vi que alterou também a URL de consulta em produção. Fez testes em produção também?

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?

Você está informando o CST do PIS inválido: [PIS001] CST=1 Sendo o correto nesse caso: [PIS001] CST=01

É o correto, nada mais a fazer.