Novo projeto

[JoséQuintas]

Detalhe: Pra capicom é a mesma coisa.
A instalação automática da capicom não obedece 64 bits.
Mas estranho funcionar com ACBR e não com Harbour.

[JoséQuintas]

Achei estas instruções com este alerta, que estranhei, porque não precisei disso aqui.
Please ensure in your internet explorer popup bloker is off(as shown in the attached jpg)

http://164.100.181.16/SSDGSAP/RegisterDLL.htm

Mas me chamou a atenção a um detalhe: instalar como administrador

[JoséQuintas]

Não tem a ver com o seu erro, apenas sobre o que falei da classe não estar preparada pro envelope desse retorno.

Alterei no método XmlSoapPost() isto, acrescentando o bloco ELSEIF com esse "novo" envelope:

   IF "<soap:Body>" $ ::cXmlRetorno .AND. "</soap:Body>" $ ::cXmlRetorno
      ::cXmlRetorno := XmlNode( ::cXmlRetorno, "soap:Body" )
   ELSEIF "<soapenv:Body>" $ ::cXmlRetorno .AND. "</soapenv:Body>" $ ::cXmlRetorno
      ::cXmlRetorno := XmlNode( ::cXmlRetorno, "soapenv:Body" )
   ELSE
      ::cXmlRetorno := "Erro SOAP: XML retorno não está no padrão " + ::cXmlRetorno
   ENDIF

E está aí uma coisa que mencionei: Encontramos uma diferença entre SP e MS.
Tem um padrão nacional? Tem, mas... acontece.

Nota:
Criei essa rotina pra facilitar analisar o XML de retorno, pra retirar a parte do envelope, deixando o XML menor.
Sem ela, tudo bem, vém o retorno completo, com envelope e tudo.
E com ela, se o retorno for diferente, também vém completo.
De qualquer forma, o importante continua sendo a comunicação.

E outra coisa que mencionei: novamente "letras". 3 letras
SP usa "soap" e MS usa "soapenv"

Até pensei se no envio não poderia ser algo desse tipo causando erro.... mas se fosse, aqui também daria erro.

Um teste interessante: abrir o webservice direto no navegador. Geralmente o webservice fornece um manual.

[JoséQuintas]

Consultando o webservice de MS:

Consultando o webservice de SP:

E clicando no link:

Só pra reforçar que há diferenças entre UFs.
E pra algumas é mais fácil encontrar documentação, no caso de SP até mesmo o próprio webservice ajuda.

Mas consultei MS daqui e funcionou.
Seria muito estranho se dependendo da origem da consulta fosse necessário um XML diferente.

[JoséQuintas]

Opa, peguei o webservice errado de SP pra comparação.
Agora o correto, de status:

[fladimir]

Baixei o Capicom pra win64 do link q vc passou e rodei o bat como administrador depois rodei o Teste e pra MS da erro SOAP pra SP retorna o XML com erro

Vou testar depois numa outra maquina e retorno o q deu

[fladimir]

Testei numa maquina XP e da os mesmos erros.

Tem algo errado nisso tudo

Manda teu EXE pra eu testar com ele aki.

Vou te mandar o meu, como vc quer q mande?

[JoséQuintas]

Pergunta idiota, mas o certificado que usou está na validade??

Testei numa máquina virtual com XP, mas já tinha instalado capicom e xml5.
Só precisei instalar um certificado válido.
Testei direto o EXE sem a alteração que fiz depois daquilo do soap e soapenv.

Dá até pra ver o que faz a rotina que alterei ontem:
No MS ainda tem a parte com ":envelope"

O Exe aqui está pequeno. vou anexar.
O mesmo que usei pra esse teste, sem alterações.
É o exemplo que está na classe.
É selecionar certificado, e depois consultar.

[JoséQuintas]

Pegando agora uma máquina virtual pelada com Windows 10.
É o que tenho pronto, pra não ter que instalar um Windows do zero.
Sem certificado dá erro.
Instalei as DLLs capicom e msxml5.
Errei no manual, a msxml5R.dll não precisa registrar, e dá até erro se tentar, mas tudo bem não atrapalha em nada isso.

E depois de instalar o certificado

[JoséQuintas]

No Windows Explorer, ferramentas, opções, conteúdo, certificados.
O certificado tem que aparecer lá, e a validade ok.

[JoséQuintas]

Nunca tentei com certificado A3, somente A1.
O A1 é só instalar no Windows e pronto.

No A3, entra a parte de segurança, de itoken, etc. e complica.

[fladimir]

Validade 2016
Tipo A1
Instalado esta pq o ACBr usa ele
Testei com mais outros A1 validos (não vencidos) e tb não deu.

Com teu EXE mesma coisa

É algo aki agora não sei o q pq no ACBr funciona mas usando a classe tem algo q bloqueia

Como saber?

[JoséQuintas]

Como estou acostumado, acabei não destacando uma coisa:

É um programa de teste.
Obrigatoriamente a primeira coisa ao carregar o EXE de teste, sempre, é chamar a primeira opção e selecionar o certificado.

Depois disso é à vontade, qualquer opção em qualquer ordem.

Vou instalar um W7 do zero aqui no virtual e fazer o teste, só pra tirar a dúvida.

Quem faz o papel intermediário é o Windows.
Tem que aparecer lá no Windows, e uma das opções de consultar o certificado e pelo internet explorer, como mencionei.

[fladimir]

Sim José bem observado, tem q escolher primeiro a opção de escolher o certificado e depois as outras.

É assim q estou fazendo e mesmo assim o erro persiste, mas diante dos testes q estamos fazendo vc dai e eu daki e como vc mandou o teu EXE, não sei explicar o q é, mas tudo indica q é algo aki, só não entendo pq o ACBr funciona.

Algo q vc poderia fazer seria instalar o ACBr e escolher o certificado pelo ACBrNFeMonitor e depois ir em Status do Serviço (q seria o Consulta Status NFe) e ver se depois do ACBrrNFeMonitor instalado se o programa de testes q estamos baseando do projeto roda sem problemas, só pra desencargo.

[JoséQuintas]

Bom.... instalei a máquina virtual W7 64bits.
Criei uma imagem de CD pra poder acessar pela máquina virtual, contendo capicom, xml5, certificado, e o teste.exe.
depois abri o prompt como administrador:

cd \Windows\syswow64
copy d:\*.dll
regsvr32 capicom.dll
regsvr32 msxml5.dll

depois instalei o certificado

depois executei o teste.exe
d:\teste.exe

Depois refiz o teste usando um usuário comum, pra não ser como administrador.
Tudo ok.

Depois do teste tinha apagado tudo, vou reinstalar o W7x64 novamente.
Algum link em especial pra baixar o ACBR monitor?

Por falar nisso.... tentou com o ACBR temporariamente desativado?
É provável que o acesso ao respositório seja "multiusuário", mas vai saber.