FiveTech Support Forums

Antes de revisar el error: en el volcado aparecen un valor etiquetado como token de sesión y datos del documento/empresa. Por favor, edita el mensaje para retirarlos, incluidas las repeticiones en las variables locales y el XML. Revisa también tu XML anterior en este hilo, donde quedó otro token.

Si esos valores todavía permiten acceso, revócalos o renueva la sesión mediante el servicio correspondiente. No sabemos si siguen vigentes ni hay evidencia aquí de que alguien los haya usado. Borrarlos del foro no los invalida por sí solo.

Para seguir con el diagnóstico no hacen falta tokens, XML de producción ni el listado completo de variables; basta el código recortado con esos valores sustituidos por marcadores.

FiveTech AI

Sobre el error técnico: el volcado sitúa el fallo en la llamada COM a SETREQUESTHEADER, no en la separación del PDF. No muestra una respuesta HTTP del servicio que permita atribuirlo al servidor.

setRequestHeader sí existe en ServerXMLHTTP de MSXML 6.0, según la documentación de Microsoft. DISP_E_MEMBERNOTFOUND no basta para concluir que falta MSXML, que Windows dejó de admitirlo o que haya que registrar/reinstalar DLL.

Hay un detalle que conviene comprobar: Microsoft documenta que los nombres de los métodos de ServerXMLHTTP distinguen mayúsculas/minúsculas, a diferencia de XMLHTTP. El nombre documentado es setRequestHeader. En el código anterior del hilo utilizabas XMLHTTP; en este volcado aparece SERVERXMLHTTP. Ese cambio merece revisarse, pero el nombre SETREQUESTHEADER en el error, por sí solo, no demuestra cómo lo está resolviendo tu versión de TOleAuto. No lo presento como causa confirmada ni como arreglo probado en tu kit.

Para acotarlo, basta con estos datos, sin información de producción:

• El bloque actual desde CreateObject y su TRY/CATCH hasta Open, las llamadas a las cabeceras y Send. Sustituye URL, credenciales, token y cuerpo por marcadores; conserva los nombres de métodos y el orden.
• ¿Es el mismo EXE, sin recompilar, en el mismo equipo donde funcionó los días anteriores? ¿O cambió el ejecutable/equipo o el objeto COM elegido por alguna rama del programa?

SOAPAction llega como cadena vacía, pero eso no demuestra la causa de un error de miembro COM. No cambiemos su valor, desactivemos validaciones ni reinstalemos componentes sin separar antes la llamada local del contrato del servicio.

Referencias:
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ms754586(v=vs.85)
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ms764715(v=vs.85)?redirectedfrom=MSDN

FiveTech AI

es el mismo equipo con windows 11 donde ha trabajado durante 15 dias, y hoy da ese error

probe cambiando el
oHttp := CreateObject( 'MSXML2.serverXMLHTTP.6.0' ) por oHttp := CreateObject( 'MSXML2.serverXMLHTTP.5.0' )
y funciona en algunos computadores, en otros da el error antes mencionado

Error description: Error MSXML2.serverXMLHTTP.5.0/3 DISP_E_MEMBERNOTFOUND: SETREQUESTHEADER
Args:
[ 1] = C SOAPAction
[ 2] = C

este es el programa que funciona en algunos computadores y otros no

cXmlBody:= '' +;
'<?xml version="1.0" encoding="utf-8"?>' + ;
'<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cl="cl.zofri.sve" xmlns:wsn="http://cl/zofri/sve/prd/wsn">'+;
' <soapenv:Header>'+;
' <cl:token>'+v_token+'</cl:token>'+;
' </soapenv:Header>'+;
' <soapenv:Body>'+;
' <wsn:emisionDocumento>'+;
' <wsn:codigoAduaneroDoc>'+v_docto+'</wsn:codigoAduaneroDoc>'+;
' <wsn:tipoEmision>'+v_tipo+'</wsn:tipoEmision>'+;
' </wsn:emisionDocumento>'+;
' </soapenv:Body>'+;
'</soapenv:Envelope>'

TRY
oHttp := CreateObject( 'MSXML2.serverXMLHTTP.5.0' )
CATCH
TRY
oHttp := CreateObject( 'MSXML2.XMLHTTP.6.0' )
CATCH
oHttp := CreateObject( 'Microsoft.XMLHTTP' )
END
END

doc = CreateObject("MSXML2.DOMDocument.6.0")

oHttp:open( "POST" , v_url, .F. )
oHttp:setRequestHeader( "Accept-Encoding","gzip,deflate" )
oHttp:setRequestHeader( "Content-Type" , "text/xml; charset=utf-8" )
oHttp:setRequestHeader( "SOAPAction", "" )

doc:LoadXML( cXmlbody )

TRY
oHttp:send(doc:xml)
CATCH
msginfo('Imposible Enviar Documento','ERROR')
RETURN .T.
END

IF oHttp:Status == 200
cXml := oHttp:ResponseBody
cType := oHttp:GetResponseHeader( "Content-Type" )
RCruda:=v_dir+"RC"+v_docto+".TXT"
hb_memowrit( rCruda, oHttp:ResponseBody )
cResponseStr := oHttp:ResponseBody

Gracias por el bloque. Hay dos detalles concretos para comparar los equipos sin seguir cambiando versiones a ciegas:

1. El TRY/CATCH solo cambia de objeto si falla CreateObject. Si ServerXMLHTTP.5.0 se crea, pero luego falla una cabecera, ese código no pasa a XMLHTTP.6.0. Por tanto, que funcione en algunos equipos no demuestra todavía que todos estén utilizando el mismo objeto: unos podrían entrar en una rama alternativa al crearlo.

2. Las tres cabeceras usan el mismo método. Según el orden que has pegado, antes de SOAPAction se llaman Accept-Encoding y Content-Type. Si el fallo ocurre exactamente en SOAPAction y las dos anteriores terminan bien sobre ese mismo objeto, no encajaría con afirmar simplemente que no existe setRequestHeader. También aparece ya escrito con el nombre documentado. Eso limita la hipótesis de las mayúsculas que señalé antes; no basta para explicarlo.

La comparación útil ahora es, en un equipo que funciona y otro que falla con el mismo EXE:

• Qué rama de CreateObject se ejecuta realmente.
• Si ambas llamadas a cabeceras anteriores terminan bien y el fallo se produce en la tercera, o si el código ejecutado tiene otro orden.

Basta indicar esos dos resultados; no hace falta otro volcado de variables ni datos del documento. Mantén el token y el cuerpo reales fuera de lo que publiques. No añadas un reenvío automático del documento como prueba.

No doy por solucionado el problema cambiando 6.0 por 5.0, ni atribuyo todavía el fallo a Windows 11. Con esa comparación podremos distinguir la elección del objeto de la invocación concreta que falla.

FiveTech AI

La solucion era solo usar esta linea

oHttp := CreateObject( 'Microsoft.XMLHTTP' )