FIRST_REAL_GLS_SYNC_REPORT

Conclusion

06/11/2026. Prueba funcional NO SUPERADA. Se realizaron exactamente tres GetExpCli en PRODUCCION, sin reintentos ni operaciones auxiliares GLS. Las tres respuestas fueron HTTP 200 con el error de negocio:

> No se encuentra la expedicion

El original conserva la tilde de "expedicion". No es un SOAP Fault ni una respuesta con datos parciales de expedicion: no hay ningun nodo exp. No se importaron expediciones, bultos, referencias ni acontecimientos. No se ha demostrado todavia el circuito de normalizacion/persistencia de una expedicion real con el nuevo trabajador. Si se han comprobado limites de ejecucion, transporte, captura duradera, tratamiento de error y consumo.

Consultas realizadas

Registro horario Europe/Madrid: 06/11/2026 11:47:18.164, 11:47:18.434 y 11:47:18.731, respectivamente. Son timestamps del registro posterior a la respuesta; los inicios precisos estan en las evidencias privadas por intento. API requests 22, 23 y 24; correlaciones independientes y trabajo local 1.

Endpoint: https://ws-customer.gls-spain.es/b2b.asmx . Metodo POST, SOAP 1.2, action http://www.asmred.com/GetExpCli . TLS validado, conexion 5 s, total 20 s. Sin redirecciones ni reintentos automaticos. No se utilizo TH-P-001.

Fragmento de peticion representativo; el prefijo agencia-CODEXP se envio literalmente en cada caso, no el CODEXP numerico aislado:

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <GetExpCli xmlns="http://www.asmred.com/">
      <codigo>[NUMERO_COMPUESTO_ENVIADO]</codigo>
      <uid>[REDACTED]</uid>
    </GetExpCli>
  </soap12:Body>
</soap12:Envelope>

Las tres respuestas completas tienen 432 bytes, Content-Type application/soap+xml; charset=utf-8, Content-Length 432 y el mismo SHA-256: 989703fef1c881364eeb5ed26cb3b194d63e456f272e83ac754d86e452030d40.

Fragmento de resultado, sin informacion personal:

<GetExpCliResponse xmlns="http://www.asmred.com/">
  <GetExpCliResult>
    <expediciones xmlns="">
      <Error>No se encuentra la expedicion</Error>
    </expediciones>
  </GetExpCliResult>
</GetExpCliResponse>

El texto exacto UTF-8 original conserva la tilde; no se ha sustituido el original por este fragmento documental. No hay codigo numerico de resultado GLS ni Resultado@return en estas respuestas. No inventar un -1 o resultado 0.

Precondiciones y protecciones

• PostgreSQL y readiness correctos, migraciones 18 al dia.
• Backup nuevo verificado mediante restauracion: 56 tablas y 115 indices,

recuentos/huellas iguales. Dump SHA-256: 488b37366094be3cd28ce553fbd9f31d766a9d5dc88ae3b833c86799cf37ec7e.

• Cuenta local GLS 2004/35, familia iClientes, entorno production y referencia

al secreto correspondiente. UID recuperable internamente y distinto de TEST.

• Las tres expediciones estaban ausentes del repositorio antes de la prueba.
• No habia trabajadores ni trabajos pendientes/activos que pudieran consumir.
• Politica de cuota existente: oficial desconocida, limite interno 20,

porcentaje ordinario 50 y reserva 5. No se inventa una cuota oficial iClientes.

• Autorizacion de un solo uso con lista cerrada de tres identificadores.

Marcador fsync previo a cada intento; una segunda ejecucion queda bloqueada.

• Cinco pruebas offline del control: tres unicos permitidos, bloqueo de otros

identificadores, escrituras y UID distinto, timeout sin retry y metadatos sin UID. No se usaron credenciales reales en estos tests.

• Se habilitaron temporalmente solo lectura y su scope en este proceso manual;

nunca creacion. Todos los valores originales se restauraron al terminar.

Persistencia y validacion

En un proceso nuevo se recuperaron los tres registros API, los resultados del trabajo y las reservas ya liquidadas. No hay expediciones cuya persistencia tras reinicio pueda afirmarse validada: no se recibieron datos para ello.

Buscar envios del puerto 80 se consulto autenticado con GET, por cada numero, en modo live. Tres HTTP 200 y cero filas, con el mensaje de ausencia de datos. No se uso el eco del identificador del formulario como prueba de existencia. Numero, referencia, destinatario, fecha, estado, cronologia y ultima sincronizacion de las expediciones no pueden verificarse sin una respuesta GLS con datos. Sus estados quedan NO DETERMINADOS, no entregadas/no entregadas. Los datos previos de Extranet no se insertaron manualmente para hacer pasar esta prueba ni se tomo un cierre administrativo como una entrega.

Consumo y auditoria

Tres reservas del gestor central, usadas 3, retenidas 0, disponible interno estimado 17. Scope nuevamente inactivo; oficial restante NO DETERMINADO. El resultado legado correcto de api_requests refleja HTTP 200, no importacion correcta. Cada fila tiene error_sanitized y detalles adicionales con gls_business_result=not_found y functional_import_success=false. La distincion se mantiene en este informe; no se presenta el HTTP como exito funcional.

Originales cifrados en el mecanismo existente, copia SOAP sanitizada y peticiones con UID eliminado en los marcadores de un solo uso. Sin tokens, UID, nombres, direcciones, telefonos o firmas en esta publicacion.

Interpretacion y siguiente paso

Confirmado: la respuesta negativa procede de GLS y no de haber descartado localmente nodos exp existentes. Los XML no contienen esos nodos. La causa exacta de la ausencia de resultados NO ESTA DETERMINADA.

Se eligio el numero compuesto agencia-CODEXP para esta ejecucion. Las dos consultas anteriores del laboratorio con tracking positivo usaron barcode numerico. El manual oficial admite codigo GLS/barcode/referencia, pero la documentacion revisada no acredita expresamente el formato compuesto como selector de codigo. Aceptacion por el validador local no prueba aceptacion GLS.

El contraste mas prudente siguiente seria una sola consulta por el CODEXP numerico [IDENTIFICADOR OMITIDO], sin prefijo. NO SE HA EJECUTADO: requiere nueva autorizacion. Tampoco puede asegurarse por anticipado que ese cambio baste. No concluir que las expediciones no existen, que el UID sea invalido o que falte autorizacion contractual basandose solo en estas tres respuestas.

Incidencia de acceso local

Tras terminar la prueba y restaurar los bloqueos, el canal QMP del agente QEMU dejo de responder. La VM y la web permanecieron operativas; el servicio del agente figura activo. No se reinicio ni reconfiguro la VM o el agente. Se recupero SSH con la identidad codex existente y confianza de servidor verificada mediante lectura estrictamente RO de su clave publica; sin leer claves privadas del disco ni introducir claves nuevas en la VM. La referencia segura de acceso queda registrada con confianza estricta. Esta incidencia no justifica repetir ninguna consulta GLS.

Cierre

No se han creado, modificado, anulado ni cerrado expediciones; tampoco se ha consultado REST, descargado POD, recuperado etiquetas o imprimido. No hay tareas masivas ni procesos de lectura activos. Tres llamadas agotadas. Prueba detenida a la espera de revision y, si procede, autorizacion nueva.