Investigacion completa de descubrimiento GLS

Exportacion para revision: 05/11/2026, Europe/Madrid. Contenido completo de los informes fuente, no resumen. No se alteran los originales. Los nombres personales no imprescindibles se sustituyen por etiquetas; los ejemplos tecnicos y la estructura se conservan. No se exportan credenciales ni evidencias crudas. Las conclusiones, contadores y autorizaciones de cada informe son HISTORICOS: no habilitan operaciones. El encargo actual prioriza exclusivamente enumeracion por fechas. La fecha mas reciente y el suplemento de esta revision prevalecen sobre planes anteriores.

Fuentes completas incluidas

---

Documento fuente: 02_DOCUMENT_INVENTORY.md

Inventario documental y evidencias

Captura 05/11/2026, antes de incorporar este dossier. Solo metadata/hashes; no se exportan originales con credenciales.

Originales registrados

16 registros: 13 iClientes, 2 OpenAPI REST y 1 referencia Zebra. La columna SHA corresponde al original; IN Anula se conserva cifrado.

IN Anula registro42: 862 bytes originales, hash13972b75..., recepcion04/11 segun procedencia y fecha incorporated_at; version no declarada. Ruta .xml.enc, downloadable=false y preview=false verificados; descifrado en memoria preserva bytes/CRLF. OUT registro41: 1390 bytes, hash724d3d..., original XML legible. No se reimportan.

Fichas autenticadas: IN, solo metadata y OUT. No se anade una ruta de descifrado ni descarga del IN desde la interfaz. El hash completo figura en la tabla anterior.

Otras ubicaciones

ZIP [RUTA INTERNA OMITIDA] 510067 bytes, SHA-256 3c3e65841f2bf24b647d47518225bcab04a265e8c1cdf4e1c12d899b2541b9df. Sus 11 miembros utiles coinciden byte a byte con vendor; manifiesto con source/archive_sha256/documents. No GetEnvios/GetManifiesto adicional. samples vacio. production-authorizations contiene 21 artefactos de guardas/resultados; no es un almacen de expediciones operativas.

Articulos previos revisados

54 Markdown sobre fases, WSDL/campos, pilotos, UID, conectores, impresoras, seguridad e infraestructura. Se conservan fechados. Los indices SQL documents/knowledge_articles contienen31: no se actualizan por esta auditoria. El descubridor filesystem de KB mostrara el maestro y nuevos informes.

Solo se actualizan articulos de entrada 000_Introduccion,030_ShipIT,130_Cache y160_Lessons_Learned para apuntar al conocimiento vigente; el resto de informes historicos se mantiene. No se altera ningun original proveedor.

Respuestas originales SOAP verificadas

15 respuestas cifradas descifrables, con hash de body y metadata. Eso no acredita que todas las pruebas antiguas tengan captura completa: cuando falte una parte, explicitarlo sin reconstruirla como original.

No se vuelcan binarios ni datos personales completos en el inventario. Etiquetas originales y derivados permanecen en sus almacenes privados. Nuevas afirmaciones GLS/Extranet se registran por procedencia en informe15, no se inventan archivos de correo/captura.

Integridad y referencias

El paquete conserva inventarios JSON estructurales en consolidation/2026-11-05/evidence/. No contienen valores de claves/UID/tokens. Los hashes de filas son controles, no dumps de datos. El esquema completo se presenta en anexo16. Fecha de recepcion != version/fecha de emision desconocida.

---

Documento fuente: 03_OPERATIONS_MATRIX.md

Operaciones GLS: contrato, implementacion y evidencia

Fecha 05/11/2026. D=documentado; O=observado por prueba TH; G=confirmado por GLS segun comunicacion de Juan; P=pendiente. Una firma WSDL es D de estructura externa, no de semantica/seguridad completa.

iClientes: las 25 operaciones

Endpoint comun b2b.asmx, namespace asmred, SOAP 1.2 utilizado. Credencial de cliente salvo GetExp, cuyo uid es GUID de expedicion. docIn generico no permite asumir la posicion de UID en operaciones sin ejemplo oficial.

ShopReturn/ShopToX: G condiciones e IDs particulares, detalle insuficiente en los dos nuevos XML para generalizarlos; fuera de la prueba Envio codigo. No mapear solucion 33 ANULADA a una orden universal de anulacion.

REST disponible, no sustitucion automatica

T&T OAuth v1 independiente: catalogo 336 y dataset oficial O, no cuenta productiva completa demostrada. GET trackids/references admite maximo 10 identificadores segun OpenAPI; no son filtros por cuenta/fecha. References son tipos definidos de tracking, no cualquier referencia ERP/C de SOAP.

ShipIT OAuth v2 sandbox O200, API O401. Contratos v1: tracking/parcels con DateFrom/DateTo, parceldetails, parcelpod, alta, cancel/{trackID}, reprint, updateparcelweight, allowedservices, endofday, validate y recogida. No acceso productivo observado; G no recomendado para esta operativa espanola. Se conserva investigacion sin seguir intentando habilitarlo por nuestra cuenta.

Matriz funcional seleccionada

No considerar una respuesta 200 igual a exito de negocio, un borrado igual a entrega ni una declaracion de capacidades una autorizacion de ejecucion.

---

Documento fuente: 04_GETENVIOS_AND_DISCOVERY.md

GetEnvios y busqueda por fechas: investigacion local

Fecha 05/11/2026. No se realizaron llamadas GLS, al portal, ni a URLs publicas. No se descarta GetEnvios por ser XML generico: se buscaron fuentes adicionales en originales, registros, importaciones y Knowledge Base.

Resultado de la investigacion

WSDL offline original: GetEnvios lineas 204-229; GetManifiesto 178-203. Ambos tienen docIn y Result con XML mixto s:any, sin tipo nombrado interno. No hay import/include XSD ni esquema local adicional para esos filtros. Se inspeccionaron los seis tipos complejos nombrados; no contienen rango de fechas, cursor, limite o filtro de estado de estas operaciones.

Los dos PDF completos, siete XML iniciales, dos originales Anula, maestro de ocho hojas y 54 articulos previos no aportan un IN/OUT nuevo de GetEnvios o GetManifiesto. Los nuevos XML solo completan Anula. Los indices SQL documentales tampoco acreditan otra fuente. La carencia esta localizada, no se concluye que GLS no pueda ofrecer la funcion.

GetEnvios: firma y SOAPAction http://www.asmred.com/GetEnvios D; falta contenido de docIn, autenticacion interna, semantica de salida y efectos. No usar DateFrom/DateTo REST, campos del alta ni Codigo vacio como supuesto contrato SOAP. minOccurs=0 no acredita enumeracion al omitir el parametro. La copia WSDL tiene defectos standalone y no se repara ni descarga online.

GetExpCli: codigo conocido + UID; GetExp: GUID conocido. Varias expediciones relacionadas por referencia no equivalen a listar una cuenta. No hay filtro documentado de fechas, estados o paginacion en sus firmas. La recomendacion de consultar no definitivos se refiere a seleccionar conocidos LOCALMENTE.

GetManifiesto: candidata, pero no se acredita listado general, cierre o lectura pura. Estado/Tracking/TrackingUid no aportan contratos internos completos. Ninguna operacion opaca se ejecuta para adivinar su comportamiento.

Extranet frente a API domestica

Otra via conocida, no seleccionada

ShipIT POST /rs/tracking/parcels si documenta DateFrom/DateTo, pero su backend sandbox rechazo llamadas, no acredita cuenta Extranet y GLS Iberia no lo recomienda para esta operativa. No es sustituto automatico de la API domestica ni razon para repetir OAuth o pruebas. T&T no enumera por cuenta. La interfaz Extranet no autoriza scraping ni inspeccion de APIs internas para reconstruir un contrato publico.

Solicitud tecnica concreta, no enviada

> Necesitamos listar las expediciones de nuestra cuenta domestica entre > dos fechas, sin conocer CODEXP/GUID/barcode/referencia. Facilitad la > operacion aplicable (especialmente confirmar GetEnvios), XML SOAP 1.2 > IN/OUT o XSD de docIn/Result, ubicacion del identificador de cuenta, > filtros obligatorios/opcionales y valores/formato. Confirmad lectura > sin cierre ni modificacion; cobertura de envios Extranet, anulados, > diferidos, estados incluidos y alcance historico de la cuenta actual > desde agosto 2025. Indicad fecha usada, timezone/extremos, limites, > paginacion/cursor, truncamiento, orden, cuota y retencion de datos/POD.

No pedir de nuevo URL del webservice, UID o documentacion basica de alta ya conocida. Si la cuenta no dispone de listado, solicitar alternativa oficial (exportacion o push acordado), con formato/alcance. Una exportacion autorizada podria sembrar conocidos sin scraping; no existe importador validado ni autorizacion para importarla ahora.

Prueba minima futura: una primera consulta acotada a un dia/cuenta y con contrato completo; una sola pagina/llamada y parada antes de continuar. No hay XML interno exacto listo para enviar hoy sin inventar informacion.

---

Documento fuente: 05_HISTORICAL_PROSPECTION_PLAN.md

Plan de prospeccion historica, pendiente de autorizacion

No se ejecuta ninguna llamada ni descarga en esta fase. Descubrir IDs y recuperar un ID conocido son capacidades independientes. Cuenta actual desde aproximadamente agosto 2025; cuenta anterior no comparte permisos por suposicion. No barridos ni numeros deducidos por secuencia.

Limites de la evidencia actual

• SOAP recupero 2004-[IDENTIFICADOR OMITIDO], fecha 26/10/2026, entregada. No demuestra

limite de retencion ni acceso API a noviembre/agosto 2025.

• Extranet devolvio 61 expediciones entre 04/11/2025 y 04/12/2025, segun

Juan; no equivalencia de API, retencion de todos los POD ni volumen anual.

• Los tres casos nuevos entregados del 04/11 son datos de Extranet aportados;

no resultados API nuevos. TH-P-001 tiene evidencia API y seguimiento Extranet posterior aportado, con discrepancia temporal ya documentada.

Pruebas propuestas y presupuesto maximo

Maximo sumado del plan base, si se autorizan TODOS los bloques, con IDs pendientes resueltos y contratos compatibles: 8 llamadas. No es permiso para consumirlas ni un solo job automatico. Recomendacion: autorizar solo R1 inicialmente; cada bloque posterior tiene su propia decision y alcance. No obtener tokens REST ni llamar a ShipIT/T&T para estas pruebas SOAP.

Ejecucion y parada futura

Sin retries, redirects ni llamadas dependientes ocultas; TLS, conexion 5 s y total 20 s aplicados. Identidad de cuenta/entorno, contraejemplos de otra cuenta bloqueados y guarda contra repeticion. Conservar HTTP/resultado de negocio, XML original cifrado, copia sanitizada, duracion y correlacion.

Parar ante error de autenticacion/contrato, timeout, respuesta incompleta, IDs conflictivos, alcance inesperado, truncamiento o presupuesto agotado. No interpretar 200 vacio como registro anulado, historico borrado ni limite de antiguedad. No seguir automaticamente un cursor o enlace de POD.

Un resultado positivo prueba ese ID/rango y momento, no todos los de ese mes ni toda la cuenta. Un negativo necesita distinguir permiso, canal, identificador, retencion y origen antes de atribuirlo a antiguedad.

Matriz de conclusion que se completara despues

Para cada periodo: cuenta, ID real/rango, descubierto o conocido, ficha, referencias, eventos, estado, enlace POD, binario NO solicitado, fecha de consulta y fuente. Guardar desconocido/no retornado por separado de vacio. No fijar una retencion de 365 dias por un TTL configurado en TH.

La carga desde agosto 2025 depende de este resultado y del contrato de listado/exportacion. Su presupuesto se estimara con volumen real y cuotas acordadas, no con suposiciones de 61 expediciones por cada mes.

---

Documento fuente: 15_GLS_COMMUNICATIONS_AND_REFERENCE_CASES.md

Comunicaciones GLS y casos de referencia, 05/11/2026

Fuente: instrucciones de Juan del 05/11/2026, preservadas en el adjunto del encargo. Son conclusiones oficiales GLS Iberia comunicadas por el responsable; no se adjunto correo original con headers ni nuevas capturas Extranet. Separacion expresa entre comunicacion, observacion humana y prueba API local.

CONFIRMADO POR GLS, segun comunicacion recibida

• ShipIT Farm no recomendado para nuestra operativa: limitacion nacional,

BusinessParcel/Shop Delivery, soporte y documentacion limitados.

• API domestica iClientes y documentos ya utilizados adecuados; endpoint

https://ws-customer.gls-spain.es/b2b.asmx.

• POD recuperable mediante GetExp y GetExpCli. No se presupone formato

uniforme, retencion ilimitada ni que el enlace de descarga sea esa operacion.

• Anula permite envios y recogidas; registros permanecen. No admite tracking

operativo ni diferidos. GetExpCli puede devolver anulados.

• Correccion mediante anulacion y otra alta es posible; son dos operaciones

con efectos, no un upsert ni autorizacion para encadenarlas automaticamente.

• Evento documentado: ESTADO / ANULADA / 5. ShopReturn y ShopToX tienen

condiciones/identificadores especificos que no deben inferirse de Envio codigo.

Caso 1: TH-P-001, fuente mixta trazable

Numero 2004-[IDENTIFICADOR OMITIDO]; CODEXP [IDENTIFICADOR OMITIDO]; barcode [IDENTIFICADOR OMITIDO]; GUID [IDENTIFICADOR OMITIDO]; referencia TH-P-001; destinataria [DESTINATARIA PILOTO]. Alta 03/11/2026, BusinessParcel 96/18, 1 bulto, 1 kg, sin paquete fisico segun Juan.

No corregir retrospectivamente el original API inmediato. La aparicion posterior en Extranet resuelve la falta de reflejo en ese canal, no demuestra una consulta posterior API ni la causa de la diferencia temporal. Conservar 1 bulto/1 kg de creacion y 0/0 finales como observaciones de momentos/fuentes distintos. No afirmar ausencia de cargos: no se revisaron facturas.

CERRADO DEFINITIVO no equivale a ENTREGADO. Proyeccion conceptual: admin anulacion aceptada; resultado anulada comunicado por Extranet; ciclo cerrado; no entrega. El valor borrado=S ya existia antes de Anula: no usarlo como unica prueba de anulacion ni como orden para eliminar el historico TH.

Casos 2-4: conjunto nuevo aportado, no consultado por TH

Los nombres son etiquetas humanas; el identificador operativo es el numero GLS completo. No se inventan GUID, barcode, CP o contactos para estos casos. No se afirma que iClientes haya confirmado aun sus entregas o POD. Los cuatro casos son conjunto inicial de validacion futura, no filas nuevas creadas en shipments. No se ejecutaron consultas ni descargas hoy.

Evidencia historica y enlace publico comunicados

Extranet: busqueda 04/11/2025 a 04/12/2025 devuelve 61 expediciones, con fichas/acontecimientos/POD cuando corresponde. Cuenta actual desde aprox. agosto 2025; antes otra agencia/cuenta. No extrapolar permisos o retencion API.

Ejemplo: [ENLACE PERSONAL OMITIDO] . El patron parece CODEXP/CP, pero no se ha abierto ni existe garantia documental general de que el ultimo segmento siempre sea CP, sin excepciones internacionales/servicio.

Decision y supersesion

El maestro reemplaza como recomendacion actual la expectativa anterior de habilitar ShipIT. Los informes de 03/11-04/11 siguen siendo evidencia historica. Las operaciones oficiales nuevas no se deducen de nombres WSDL; requieren fuente y pruebas separadas. Las comunicaciones originales adicionales que lleguen se incorporaran sin modificar ni duplicar innecesariamente lo existente.

---

Documento fuente: GLS_ACCOUNT_DISCOVERY_INVESTIGATION_2026_11_03.md

Descubrimiento GLS por cuenta y fecha: investigacion documental

Fecha: 2026-11-03. Zona: Europe/Madrid. Resultado: no se ha ejecutado ninguna llamada GLS en esta investigacion. Este informe no modifica codigo, contratos, arquitectura, datos de envios, migraciones, configuracion ni tareas automaticas.

1. Objetivo corregido y conclusion

Juan confirma que 2004-[IDENTIFICADOR OMITIDO], 2004-[IDENTIFICADOR OMITIDO] y 2004-[IDENTIFICADOR OMITIDO] son expediciones antiguas eliminadas desde Extranet. NO son los tres envios nuevos creados el 03/11/2026 y escaneados por el conductor. No se han reutilizado esos identificadores ni se pide conocer los nuevos: el objetivo es descubrirlos por cuenta y fecha, sin CODEXP, GUID, barcode ni referencia.

La autorizacion vigente es UNA consulta de PRODUCCION, solo si existe contrato suficiente, lectura inequivoca, parametros validos y alcance confirmado de cuenta y fecha. No se ha consumido: esas condiciones no quedan acreditadas para ninguna via operativa disponible.

Conclusion diferenciada:

• iClientes SOAP: no tenemos un contrato documentado utilizable para

enumerar por cuenta/fecha. GetEnvios y GetManifiesto existen, pero su XML interno no esta definido en las fuentes disponibles.

• REST Track And Trace: sus rutas requieren un identificador conocido;

no documentan enumeracion de la cuenta por fecha o estado.

• REST ShipIT: SI existe un listado documentado con DateFrom/DateTo,

POST /rs/tracking/parcels. Es un producto y autenticacion diferentes. No se acredita su vinculacion a la cuenta iClientes de PRODUCCION, su cobertura de los envios Extranet ni autorizacion backend operativa. La UID iClientes no es una credencial OAuth ShipIT.

Por tanto no puede afirmarse que GLS carezca de una API de enumeracion. Lo que falta es un contrato iClientes suficiente o una via ShipIT autorizada y vinculada documentalmente a esta cuenta y este objetivo.

2. Fuentes efectivamente revisadas

En [RUTA INTERNA OMITIDA]:

• b2b.wsdl: las 25 operaciones, bloques de entrada/salida, tipos nombrados,

bindings y referencias internas. Lectura literal sin reparar namespaces.

• Los dos PDF oficiales completos, 11 y 6 paginas, incluidos los apartados

de consulta, seguridad, seguimiento, Extranet, manifiesto y push.

• Los siete XML oficiales: dos ejemplos IN/OUT, DOC IN/OUT y respuesta

GetExp/GetExpCli; estructuras y comentarios, no solo nombres de fichero.

• ES-GLS-Maestros_V2.xlsx, con sus ocho hojas de estados, incidencias,

soluciones, recogidas, servicios, paises y formatos/CP.

Ademas:

• [RUTA INTERNA OMITIDA].
• [RUTA INTERNA OMITIDA].
• Inventario official_documents, catalogo local iClientes, Knowledge

Base y auditorias previas. No aparece un manual adicional de GetEnvios o GetManifiesto ni un XSD especifico para su docIn.

• Codigo vigente de SOAP, diagnosticos REST, clientes, entornos, auditoria

de consumo y resultados anteriores. No se invoco ningun cliente remoto.

Hashes SHA-256 de las fuentes principales, sin modificaciones:

Limitaciones de formato de las copias recibidas:

• WSDL: texto inicial y prefijos no declarados; no es XML standalone valido.

Se inspecciono lo literal, no se reconstruyo ni se obtuvo otro online.

• T&T YAML: una primera linea ajena a OpenAPI impide parsear todo el fichero.

Para el analisis se leyo en memoria el bloque desde openapi: de la linea 2, sin guardar ni alterar la copia preservada.

• El XML de ejemplo de respuesta GetExp contiene un error de parseo en

linea 130, columna 254. Ese ejemplo se inspecciono literalmente sin repararlo; no se uso para inventar entradas de otras operaciones.

3. GetEnvios y GetManifiesto: hallazgo tecnico exacto

En WSDL original, GetEnvios aparece en lineas 204-229 y GetManifiesto en 178-203. Ambos tienen un unico parametro docIn, con la misma forma:

<s:element minOccurs="0" maxOccurs="1" name="docIn">
  <s:complexType mixed="true">
    <s:sequence>
      <s:any/>
    </s:sequence>
  </s:complexType>
</s:element>

Las respuestas tienen un Result especifico de operacion que contiene tambien XML mixto con s:any. No hay una referencia a un tipo nombrado que describa filtro por cuenta, fecha, estado o paginacion. No aparecen imports/includes de XSD que permitan resolverlo con otra fuente local.

Hechos acreditados:

• Nombre de operacion, wrapper SOAP y parametro docIn.
• Actions literales: http://www.asmred.com/GetEnvios y

http://www.asmred.com/GetManifiesto.

• Endpoint SOAP del contrato y manual general:

https://ws-customer.gls-spain.es/b2b.asmx.

Lo que NO esta acreditado:

• Raiz/namespaces del XML dentro de docIn y posicion/nombre de la UID.
• Filtros admitidos, formatos, campos obligatorios y valores por defecto.
• Fecha de creacion, expedicion, admision o modificacion a la que filtra.
• Alcance de cliente/agencia y inclusion de otros canales como Extranet.
• Limites, paginacion, truncamiento, orden, retencion y timezone.
• Esquema de resultados, IDs retornados y catalogo de errores.
• Lectura pura o generacion de manifiesto/cierre/otro efecto.

mixed=true permite contenido XML mixto; s:any no define sus elementos. minOccurs=0 significa que docIn es opcional sintacticamente en la firma, NO que omitirlo autorice listar toda la cuenta. El nombre Get tampoco acredita ausencia de efectos. No hay peticion segura ejecutable con esto.

Los dos PDF no mencionan GetEnvios ni GetManifiesto por nombre. Los XML y el maestro tampoco aportan un ejemplo de entrada, filtros o paginacion de esas operaciones. Las fichas locales del catalogo los clasifican A-parcial, no implementados/no probados; la Knowledge Base refleja la misma carencia, sin una fuente oficial nueva que la resuelva.

4. Revision de todas las operaciones y tipos WSDL

Firmas de entrada: los parametros son cadenas salvo indicacion. XML* es contenido generico no resuelto, no un contrato de filtros.

Los seis tipos complejos nombrados son ArrayOfBase64Binary, ValidateUidClienteRequest, ValidateUidClienteResponse, ArrayOfString, GetTSPRequest y GetTSPResponse. El simple nombrado es TiposEtiqueta.

Ninguno define un DateFrom/DateTo, rango, cursor, pagina o filtro de expediciones. Agency_Code y Client_Code pertenecen a validacion de UID; CodPaisOrg/CPOrg/CodPaisDst/CPDst/CodServicio/CodHorario son de GetTSP. No se trasladan de una operacion a otra para construir GetEnvios.

GetExp/GetExpCli devuelven estado, referencias y eventos de conocidos. La consulta por referencia puede devolver padre/retornos relacionados; no significa enumeracion de todas las expediciones del cliente. No se documentan comodines, codigo vacio, rango numerico o prefijos.

M1 p.11 y M2 p.3 aconsejan consultar conocidos no definitivos unas 4-5 veces/dia. Esa seleccion es local al sistema del cliente, no un filtro remoto de todas las no entregadas. El maximo de 20 de GrabaServicios es de insercion, no paginacion de GetEnvios/GetExpCli.

5. APIs REST disponibles: distinguir listado de tracking

Track And Trace V1

Rutas del OpenAPI conservado:

• GET /tracking/simple/trackids/{unitnos}.
• GET /tracking/simple/references/{references}.
• GET /tracking/deliveryinfo/parcelid/{unitno}.
• GET /tracking/events/codes.

Las dos primeras requieren identificadores, la tercera un unitno y la ultima enumera codigos de eventos, NO expediciones. No existe en este OpenAPI un selector de cuenta/cliente/agencia/fecha/estado de expedicion.

references admite los tipos concretos descritos: Parcel Number, Track ID, Notification Card ID y Digital Notification Card ID. No equivale a referencia C/0/S de iClientes ni referencia libre de cliente. No asumir CODEXP SOAP = unitno REST ni que un barcode numerico de 14 caracteres sea una Digital Notification Card ID por coincidir solo su longitud.

La agrupacion de hasta 10 identificadores/referencias permite recuperar conocidos eficientemente; no descubre los identificadores desconocidos. showEvents y showLinks cambian contenido, no son filtros de enumeracion.

La copia documenta por defecto 500 solicitudes/dia; es cuota T&T, no SOAP iClientes. Los servidores incluyen produccion, sandbox y QAS, y una nota general recomienda produccion. Nada de ello crea una operacion de listado.

ShipIT-Farm: listado por fechas SI documentado

Contrato: POST /rs/tracking/parcels, operationId findParcels. Request: application/glsVersion1+json, esquema TULReferenceData. Obligatorios: DateFrom y DateTo, cadenas con formato date-time. Opcionales: TrackID, ShipmentReference, ShipmentUnitReference, ParcelNumber, PartnerParcelNumber. Pueden omitirse en la propuesta minima.

Response: TUListResponse.UnitItems[], con TrackID, InitialDate, Status y otros identificadores/referencias. No es la estructura SOAP expediciones. No hay en esa firma un parametro UIDCLIENTE iClientes ni filtro explicito de cuenta/agencia/estado, ni paginacion documentada.

Peticion documental minima candidata, NO enviada ni declarada lista para produccion por faltar las garantias de cuenta/alcance indicadas abajo:

POST https://api.gls-group.net/shipit-farm/v1/backend/rs/tracking/parcels
Authorization: Bearer [REDACTED]
Accept: application/glsVersion1+json
Content-Type: application/glsVersion1+json

{
  "DateFrom": "2026-11-03T00:00:00+01:00",
  "DateTo": "2026-11-03T23:59:59+01:00"
}

UTC equivalente: inicio 2026-11-02T23:00:00Z; fin 2026-11-03T22:59:59Z. La inclusividad de extremos, precision fraccionaria y semantica de la fecha deben confirmarse antes de garantizar cobertura completa de un dia. InitialDate en salida no define por si sola el filtro.

Por que no se ejecuto:

• La autorizacion y UID de PRODUCCION confirmadas son de iClientes SOAP.

No se ha acreditado vinculacion ShipIT a esa misma cuenta ni cobertura de expediciones creadas desde Extranet GLS Espana.

• El antecedente de backend ShipIT es HTTP 401 en sandbox. No se ha probado

produccion ni se presupone que la autorizacion iClientes lo resuelva.

• La implementacion actual de ShipIT usa configuracion/credenciales del

laboratorio sandbox. No se reutilizaron para un acceso productivo. Esto no afirma que falte una clave: falta acreditar la via autorizada, su alcance y vinculacion, no adivinar una identidad alternativa.

• La copia OpenAPI referencia OAuthPROD en seguridad global pero declara

OAuth y OAuthSandbox como esquemas; no se reparo ni se invento un binding.

• Obtener OAuth seria otra llamada externa. No se oculta como parte de

una supuesta consulta unica ni se consume para comprobar una via no acreditada. No se lanzaron OAuth, DNS/TLS remotos ni llamadas auxiliares.

El resto de rutas ShipIT son Parcel Shops, detalle/POD de conocido, servicios o operaciones de escritura. endofday no se usa para descubrir: cerrar dia esta expresamente prohibido. Parcel Shops enumera puntos, no expediciones de cliente. No se ha probado nada de ello en esta fase.

Matriz de posibilidades

6. Payload SOAP: por que no hay uno valido preparado

Se conoce el transporte: POST al endpoint iClientes, SOAP 1.2, namespace http://www.asmred.com/ y action http://www.asmred.com/GetEnvios.

Solo puede representarse esta envoltura INCOMPLETA, NO enviable:

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <GetEnvios xmlns="http://www.asmred.com/">
      <docIn>
        <!-- Falta el contrato oficial del XML interno. NO ENVIAR. -->
      </docIn>
    </GetEnvios>
  </soap12:Body>
</soap12:Envelope>

No se introduce UID en un campo supuesto ni se trasladan DateFrom/DateTo de REST a SOAP. No se inventan FechaDesde/FechaHasta, Cliente, Agencia o Estado. La envoltura no es un payload valido de consulta ni una propuesta para probar docIn vacio. Falta precisamente la parte que decide alcance, autenticacion, fecha y efectos.

7. Otras vias y significado de la evidencia anterior

M1 v1.12 p.2 relaciona NO Diferido con MiraEnvios y YourGLS/Buscar envios, con condiciones de cierre. No define el protocolo de enumeracion ni un traspaso automatico entre todos los estados/canales. No se usara el cierre como experimento ni se accedera mediante scraping/automatizacion.

M1 p.10 describe un proyecto acordado donde GLS llama al webservice del cliente, para clientes con mas de 500 envios/dia, transmitiendo eventos e identificadores. Es una modalidad push potencialmente util, no contratada aqui ni un endpoint pull ya habilitado. No garantiza historico completo.

Las pruebas anteriores demuestran consulta de una historica entregada de Extranet y de TH-P-001 creada por API. No demuestran descubrimiento sin ID. Los tres vacios de los antiguos [IDENTIFICADOR OMITIDO]/[IDENTIFICADOR OMITIDO]/[IDENTIFICADOR OMITIDO] siguen siendo respuestas reales, pero Juan aclara ahora su eliminacion. No permiten atribuir el vacio exclusivamente a "Pendiente Grabar", ni evaluar los tres nuevos. Tampoco consta por API cuando se eliminaron respecto a la consulta.

El escaneo del conductor se conoce por comunicacion de Juan, no por un evento recibido en esta investigacion. No se ha localizado ni descartado ninguna de las tres expediciones nuevas mediante API.

8. Peticion minima y concreta a GLS

Texto propuesto para soporte; no enviado:

> Necesitamos descubrir por API todas las expediciones de nuestra cuenta > iClientes de PRODUCCION creadas desde Extranet en una fecha o rango, > sin conocer previamente CODEXP, GUID, barcode, albaran ni referencia. > El objetivo inicial es 03/11/2026, Europe/Madrid, sin crear, modificar, > cerrar ni manifestar expediciones. > > El WSDL offline declara GetEnvios(docIn) y GetManifiesto(docIn), pero > docIn y Result son XML mixto s:any. Rogamos confirmar cual es la operacion > de lectura aplicable a nuestra cuenta y aportar un ejemplo completo > SOAP 1.2 IN/OUT o XSD del XML interno, posicion del UIDCLIENTE y filtros > exactos de cuenta/fecha/estado, campos obligatorios y formatos. > > Confirmad que no tiene efectos de cierre, grabacion o manifiesto; que > incluye expediciones de Extranet y desde que momento; semantica y zona > horaria de la fecha, limites, paginacion/truncamiento y cuota. La salida > debe permitir obtener CODEXP y los identificadores relacionados. > > Si iClientes no ofrece este listado, indicad la alternativa oficial: > autorizacion/vinculacion ShipIT para POST /rs/tracking/parcels y su > cobertura de Extranet de esta cuenta, o exportacion/push oficial.

No es necesario solicitar numeros de los tres envios para resolver este contrato. La solicitud no debe incluir UID, tokens ni otras credenciales. El ejemplo debe usar marcadores y GLS puede validar internamente el ambito.

9. Respuestas a las diez preguntas

1. Operacion documentada para enumerar? En iClientes no hay contrato suficiente disponible. GetEnvios/GetManifiesto son candidatas. En ShipIT si hay listado documentado por fechas, no demostrado operativo para nuestra cuenta/canal Extranet. 2. Filtra por fecha? GetExp/GetExpCli no. GetEnvios es desconocido por falta de docIn. ShipIT admite DateFrom/DateTo. 3. Filtra por cuenta/cliente? No existe un filtro de enumeracion iClientes documentado. UIDCLIENTE delimita consultas por codigo, no lista sola los envios. Ambito ShipIT OAuth pendiente de acreditacion. 4. Podemos descubrir los tres sin numeros? No con una via actualmente acreditada y utilizable. No se demuestra imposibilidad general de GLS. 5. Operacion a usar? Solicitar primero el contrato de GetEnvios; valorar GetManifiesto solo si GLS confirma lectura pura. Alternativa: findParcels de ShipIT tras confirmar autorizacion y cobertura. 6. Parametros exactos? En GetEnvios solo se conoce docIn, no su contenido. Para ShipIT los dos campos obligatorios son DateFrom/DateTo mas autenticacion OAuth independiente; no UID iClientes en el JSON. 7. Se ejecuto una consulta valida? NO. No se cumplian las condiciones de autorizacion condicional; no se envio ninguna consulta especulativa. 8. Expediciones devueltas? No aplica: no hubo llamada. No equivale a HTTP 200 con lista vacia ni a tres expediciones buscadas y no encontradas. 9. Limitacion concreta? Falta contrato interno y garantias de lectura, cuenta/fecha de GetEnvios/GetManifiesto. Tracking conocido no enumera; ShipIT tiene otra autenticacion y alcance no acreditado para esta cuenta. 10. Documentacion minima? Operacion oficial de listado, IN/OUT/XSD, ubicacion del UID, filtros obligatorios, semantica de fechas/ambito, lectura sin efectos, cobertura Extranet, IDs de salida, limites y paginacion. O vinculacion y contrato de cobertura de alternativa REST.

Fuente principal futura: GetExpCli es candidata para ACTUALIZAR conocidos, no para descubrirlos. La fuente de descubrimiento no puede seleccionarse como resuelta hasta recibir el contrato o habilitacion correspondiente. No se implementa cache ni sincronizacion en esta fase.

10. Codigo, contadores y limites

La inspeccion detecta que el diagnostico REST existente obtiene OAuth internamente antes de tracking, registra el tracking con etiqueta sandbox y no contabiliza esa obtencion auxiliar en ese mismo metodo. Su transporte general usa urllib, que puede seguir redirecciones. No se lanzo ese flujo para esta autorizacion de una unica consulta, ni se modifico su codigo. Antes de una futura prueba limitada hay que contar todos los HTTP reales y preservar evidencia, sin ocultar OAuth/redirecciones como una consulta.

No se descargaron especificaciones, accedio a GLS, hizo OAuth, repitieron CODEXP antiguos, crearon/modificaron/anularon/cerraron envios, solicitaron etiquetas, imprimieron trabajos, cambiaron secretos, aplicaron migraciones ni crearon jobs. No se utilizo ninguna UID TEST para operar en PRODUCCION.

El historico T&T registrado es 3 HTTP: OAuth, catalogo y dataset, todos con etiqueta sandbox historica. No se reclasifica. Las 5 filas REST historicas totales incluyen ademas OAuth ShipIT y Parcel Shops. api_requests global permanece en 18; separar estos datos del contador SOAP productivo.

No se generan nuevas evidencias remotas porque no hubo llamadas. Se conservan intactas las evidencias anteriores y este informe de analisis. Trabajo detenido; la autorizacion condicional de consulta no se consume para suplir la documentacion ausente con pruebas a ciegas.

---

Documento fuente: GLS_DISCOVERY_CACHE_DESIGN_2026_11_03.md

GLS: descubrimiento, Pendiente Grabar y diseno de cache local

Fecha: 2026-11-03. Zona operativa: Europe/Madrid. Alcance: tres consultas expresamente autorizadas en PRODUCCION y, despues, analisis exclusivamente local. Este documento es una propuesta, no una implementacion de cache, sincronizacion ni interfaz.

1. Resumen ejecutivo

• Se enviaron exactamente tres GetExpCli, uno por cada CODEXP autorizado.

Los tres respondieron HTTP 200, SOAP valido y lista de expediciones vacia.

• No se observo diferencia entre los dos casos de Extranet situados en

"Envios pendientes despues de Cierre" y el situado en "Envios en Cierre".

• La prueba demuestra ausencia de resultados para esos identificadores,

esa UID de PRODUCCION y ese instante. No explica por si sola la causa ni el significado tecnico general de "Pendiente Grabar".

• GetExpCli documenta consulta por identificador conocido, no un listado

por fechas o estado. GetEnvios y GetManifiesto existen en el WSDL, pero falta su contrato interno y no son ejecutables de forma fundada con las fuentes disponibles. Tampoco se presume que sean de solo lectura.

• La cache puede almacenar todo el historico conocido, sin tope de 100.

No resuelve por si sola el descubrimiento de expediciones desconocidas.

• Contadores finales: PRODUCCION 7; TEST/laboratorio historico 11.

2. Parte A: resultados de las tres consultas

Endpoint: https://ws-customer.gls-spain.es/b2b.asmx

Metodo POST, SOAP 1.2, action http://www.asmred.com/GetExpCli. UID de PRODUCCION recuperada internamente; no se usaron credenciales TEST en las peticiones. TLS verificado; conexion 5 s, total 20 s; sin reintentos, redirecciones ni operaciones auxiliares. El criterio fue exclusivamente CODEXP, sin prefijo de agencia, barcode, albaran ni referencia.

Timestamps de inicio Europe/Madrid:

• Caso 1: 2026-11-03T16:36:24.853709+01:00; api_requests.id = 16.
• Caso 2: 2026-11-03T16:36:25.046194+01:00; api_requests.id = 17.
• Caso 3: 2026-11-03T16:36:25.246471+01:00; api_requests.id = 18.

Las tres respuestas fueron completas, de 432 bytes, con la estructura SOAP GetExpCliResponse/GetExpCliResult y una lista expediciones sin exp. No hubo errores de lectura ni errores GLS extraidos. No existe aqui un Resultado@return numerico: no debe confundirse lista vacia con resultado 0 de GrabaServicios ni HTTP 200 con expedicion encontrada.

Por no existir registros, GLS NO devolvio estado/codigo de estado, CODEXP, barcode, GUID, albaran, referencias, servicio/horario, bultos/peso, fecha de expedicion ni eventos. Los identificadores y fechas de la tabla son datos del caso de prueba aportados por Juan, no campos confirmados por GLS.

Peticion sanitizada representativa; solo cambia codigo entre casos:

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

Cabecera: Content-Type: application/soap+xml; charset=utf-8; action="http://www.asmred.com/GetExpCli".

Evidencia preservada

Directorio privado: [RUTA INTERNA OMITIDA]. Cada original de respuesta se conserva cifrado; cada JSON es evidencia sanitizada independiente. Ambos con permisos 400.

SHA-256 del body recibido, identico en los tres casos: 989703fef1c881364eeb5ed26cb3b194d63e456f272e83ac754d86e452030d40.

Resumen privado del lote, parametros, contadores e integridad: [RUTA INTERNA OMITIDA]. Las guardas persistentes del lote y de cada caso impiden repetir esta autorizacion al volver a ejecutar accidentalmente el auxiliar de auditoria.

Comparacion e interpretacion acotada

Resultado observado: 0/2 recuperables despues de Cierre y 0/1 en Cierre. No hay diferencia observable en esta muestra. Tampoco se ha observado una transicion del mismo envio entre ambos grupos, ni se ha efectuado cierre.

El caso 3 ya habia dado vacio por barcode; la consulta actual por CODEXP es una prueba diferente y se registra separadamente. No se considera que una sustituya a la otra.

La expedicion historica 2004-[IDENTIFICADOR OMITIDO] si fue recuperada anteriormente por CODEXP: HTTP 200, un envio, ENTREGADO (7). TH-P-001, creada por TRANSPORT HUB, tambien se recupero. Por tanto, no corresponde concluir que iClientes no consulta Extranet en general ni que la UID sea invalida.

No demostrado: que todo "Pendiente Grabar" sea invisible, que un cierre lo publique necesariamente, que la causa sea el grupo de Extranet, ni que Extranet e iClientes sean sistemas independientes. El vacio tambien deja sin resolver alcance de cuenta, correspondencia de identificadores y momento de publicacion de estos casos. Debe preguntarse a GLS, no inferirse de tres respuestas ni resolverse con nuevas llamadas no autorizadas.

3. Parte B: fuentes oficiales y metodo de auditoria

Se contrastaron los 11 originales de [RUTA INTERNA OMITIDA], el ZIP original preservado, los dos manuales, XML IN/OUT y ejemplos, las ocho hojas del maestro, las 25 operaciones literales de b2b.wsdl, el cliente vigente y evidencia local. No se consulto la version online del WSDL ni se reparo la copia recibida.

Referencias utilizadas:

• M1: ES-GLS-iClientes (WS-Envios_InsercionyTracking).docx.pdf, v1.12,

paginas 2, 3, 10 y 11 especialmente.

• M2: ES-GLS-WS_GetExp_GetExpCli.docx.pdf, paginas 1 a 6.
• R: GLS_WS_GetExp_GetExpCli_Response_Example.xml.
• IN/OUT: GLS-DOC_Shipment_English-IN.xml y -OUT.xml.
• B-IN/OUT y E2-IN/OUT: ejemplos Basic y ReturnLabelsOnInsert.
• X: ES-GLS-Maestros_V2.xlsx.
• W: b2b.wsdl, 63.502 bytes, 1.974 lineas; SHA-256

3ea7a6edcd64c5756e1ccd5da8883823900406c130f8f150b9d9d97ead17b6cd.

La copia W contiene texto inicial y prefijos sin declarar; no es XML standalone valido. Se leyeron literalmente bloques y firmas, sin inventar namespaces. Una firma XML mixta con s:any NO define sus campos internos. minOccurs=0 en la firma no acredita que un codigo vacio enumere la cuenta.

Clasificacion: DOCUMENTADA = capacidad expresamente descrita; POSIBLE PERO DOCUMENTACION INSUFICIENTE = candidata que requiere contrato; NO SOPORTADA = no cabe en la firma/uso documentado concreto, no negacion de capacidades globales de GLS; DESCONOCIDA = no hay evidencia suficiente.

Auditoria de las 25 operaciones

XML* indica XML mixto/arbitrario, no un esquema conocido de filtros. La funcion deducida por nombre no se trata como capacidad documentada.

Los bindings SOAP 1.1/1.2 repiten esas 25 operaciones, no son operaciones adicionales. Ninguna candidata opaca se probo durante este estudio.

Posibilidades por criterio de consulta

Respuestas expresas a las ocho preguntas

1. Todas mis expediciones entre A y B: no hay contrato acreditado en los documentos disponibles. GetEnvios es candidata, no solucion validada. 2. Todas mis no entregadas: no hay consulta global documentada. M1 p.11 y M2 p.3 aconsejan refrescar envios conocidos no definitivos; no describen un filtro remoto que los descubra. 3. Enumerar recientes: no se acredita una operacion utilizable con seguridad con el material actual. No significa que GLS no la ofrezca. 4. Paginacion/limite: no se documentan cursor, pagina, offset, tamano de pagina, truncamiento ni maximo de resultados de GetExpCli/listados. Varios exp por referencia son envios relacionados, no paginacion. Maximo 20 de GrabaServicios es de insercion, no limite de consulta. 5. Manifiesto/cierre como descubrimiento: GetManifiesto existe, pero docIn/salida, permisos y efectos no estan documentados suficientemente. M1 p.2 menciona una limitacion de listado de manifiesto en NO Diferido; no permite concluir que esta operacion funcione para nuestra cuenta ni que cierre o publique expediciones. No ejecutar para averiguarlo. 6. GetExpCli amplio sin identificador: no documentado. La posibilidad de varios envios por referencia no transforma el metodo en un listado de cuenta. No usar secuenciales, comodines o codigo vacio. 7. Identificador minimo: GetExpCli requiere UIDCLIENTE segura + uno de codigo GLS/CODEXP, barcode o referencia unica conocida. GetExp requiere el GUID de la expedicion, no la UID de cliente. M2 p.6 prefiere conservar GUID/barcode del original para distinguirlo de retornos por referencia. 8. Obtener CODEXP recientes: la respuesta de GrabaServicios aporta IDs de lo que crea TRANSPORT HUB; no descubre otros canales. M1 p.10 describe envio de eventos/identificadores desde GLS a un webservice del cliente, para proyectos acordados y clientes con mas de 500 envios/dia: no esta contratado/configurado aqui ni garantiza carga historica completa. No tenemos actualmente un listado pull documentado de todos los recientes.

M1 p.2 relaciona Webservice NO Diferido con MiraEnvios y YourGLS/Buscar envios, con una condicion de cierre. Ese texto no garantiza simetricamente que cada borrador/pendiente de Extranet sea consultable por iClientes. La recuperacion historica es evidencia puntual positiva, no un contrato general sobre todos los grupos, estados o canales.

Estrategia recomendada para adquirir conocidos y descubrir nuevos

Separar lookup (recuperar conocido), discovery (encontrar IDs nuevos) y refresh (actualizar cache). Solo el primero esta acreditado hoy.

• Capturar IDs de cada alta propia autorizada y conservar sus respuestas.
• Reutilizar las respuestas utiles YA cifradas mediante una futura ingesta

local auditada; no volver a llamar a GLS para importar la misma evidencia.

• Admitir semillas aportadas manualmente con fuente/fecha/verificacion.

Un futuro importador de exportacion oficial, si existe y se autoriza, seria otra via; no hay formato/importador validado en esta fase.

• Solicitar primero contratos completos de GetEnvios y GetManifiesto y

alcance de la UID. Solo entonces decidir descubrimiento incremental.

• Valorar push acordado con GLS si aplica; no desarrollar ahora endpoint

receptor, prometer cobertura ni asumir el requisito de volumen satisfecho.

• No scraping, automatizacion de Extranet, fuerza bruta de CODEXP/albaranes,

enumeracion secuencial, ni nuevas pruebas para adivinar filtros.

4. Parte C: arquitectura propuesta, NO implementada

Separacion de responsabilidades

1. Conector por carrier/familia API/entorno/cuenta: capacidades declaradas de lookup, discovery, refresh y escrituras separadas. No un cliente GLS que acople UI, SOAP, cuotas y entidades de negocio. 2. Captura y auditoria: una fila api_requests por peticion HTTP real, evidencia original cifrada y derivacion sanitizada, correlacion y actor. 3. Ingestor idempotente local: validacion de identidad/ambito, normalizacion versionada y transaccion de cache, sin nuevas llamadas remotas. 4. Repositorio PostgreSQL y consultas de UI exclusivamente locales. 5. Planificador futuro separado, desactivado hasta autorizacion y contrato de limites; nunca ejecutado por abrir una pagina o hacer una busqueda.

Ya existen prototipos carriers, shipments, parcels, tracking_events, synchronizations y cache_resources. Actualmente las cuatro tablas de expediciones/paquetes/eventos/sincronizaciones estan vacias. Se propone evolucionarlas, no crear en paralelo otro nucleo incompatible de GLS. Los ensayos y etiquetas del laboratorio siguen siendo registros distintos.

Entidades logicas y campos

SHIPMENTS (evolucion de shipments):

• id, carrier_id, carrier_account_id, environment,

carrier_shipment_id como cadenas tipadas por conector, no enteros.

• Identificadores CODEXP, GUID, barcode, numero visible de expedicion y

albaran disponibles mediante coleccion tipada y proyeccion de consulta. No exigir GUID a otros carriers ni confundirlo con UIDCLIENTE secreta.

• origin: transport_hub / gls_extranet / imported / unknown;

origin_confidence, origin_source, actor, evidencia y fecha de atribucion.

• Fecha de expedicion; destinatario minimo operativo, CP, poblacion, pais;

servicio y horario con codigo/literal originales; bultos y peso decimal.

• Reembolso: importe decimal, moneda y presencia conocida/desconocida;

retorno con valor original y significado conocido/desconocido. Campo ausente no se convierte automaticamente en cero, falso o sin retorno.

• Estado actual: API/catalogo, codigo/literal originales, estado interno,

is_terminal, motivo, fecha efectiva y version de mapeo aplicada.

• created_at local, first_seen_at, last_seen_at,

last_gls_sync_at de ultimo refresco remoto valido, last_sync_attempt_at, next_sync_at, sync_status, error sanitizado, hash de ultimo contenido y version de normalizador.

Una tabla logica SHIPMENT_IDENTIFIERS preservaria cada tipo/valor, namespace API y origen. Unicidad condicionada por carrier, cuenta, entorno y tipo de identificador fuerte. Conservar ceros iniciales y valor original. CODEXP/numero sin agencia no se declaran globalmente unicos por conjetura. Referencias/albaranes no se usan solos como clave universal de fusion. Conflictos entre GUID/CODEXP/barcode se ponen en revision, no se sobrescriben.

PARCELS reutiliza la entidad existente para identificadores de bulto y estado por unidad cuando GLS los distinga. Un envio con varios bultos no se multiplica artificialmente por cada referencia o evento de expedicion.

SHIPMENT_EVENTS (evolucion de tracking_events):

• shipment_id; parcel_id solo si el evento se refiere realmente a uno;

carrier, cuenta, entorno, familia API y namespace de catalogo.

• Codigo original, tipo (estado/incidencia/administrativo/otro), descripcion

sanitizada, timestamp GLS original, timezone conocida o incertidumbre, timestamp normalizado cuando se pueda justificar, ubicacion si existe.

• first_seen_at, ID externo si existe, huella semantica de deduplicacion,

evidencia/observacion de origen, version de parser/mapeo.

• Unicidad por ID externo en su ambito o huella de envio+tipo+codigo+fecha+

ubicacion/contenido estable; no por codigo solamente. Repeticiones de una incidencia en momentos distintos deben conservarse.

SHIPMENT_REFERENCES:

• shipment_id, tipo C/0/S/otros, valor original, campo/namespace de origen,

fuente, fechas first/last_seen, relacion con observacion.

• No unicidad global de valor. Referencias heredadas por devoluciones

pueden apuntar a varias expediciones, con relacion padre/hija separada.

• No convertir automaticamente albaran, refS o refC en tipo 0: conservar

la semantica que devuelve cada API y confirmar equivalencias.

OBSERVACIONES Y CAMBIOS:

• Observaciones append-only con respuesta normalizada versionada, hash,

peticion auditada, referencia de evidencia cifrada, procedencia y tiempos.

• Historial de cambios de estado con valor anterior/nuevo, fecha efectiva,

fecha de deteccion, fuente y reglas aplicadas. Nunca reconstruirlo solo desde el ultimo estado ni borrar eventos al refrescar.

• Separar candidatos/observaciones externas no confirmados: los tres

"Pendiente Grabar" no son envios confirmados por API. Guardar en una futura cola de candidatos el dato Extranet y su evidencia negativa, no inventar un estado GLS ni una expedicion recuperada.

• Una lista vacia es una observacion de lookup, no prueba de borrado,

anulacion, desaparicion definitiva ni cambio a PENDING. Si antes habia resultado positivo, conservarlo con advertencia de ultima consulta vacia.

Ingesta de cada respuesta util

Flujo futuro: captura remota unica -> evidencia cifrada duradera y registro API -> validacion completa -> transaccion local de todos los exp recibidos, identificadores, referencias, eventos, snapshot y cambios de estado. Actualizar last_gls_sync_at solo tras lectura valida y commit; una vista de cache no renueva esa fecha. Separar recepcion, procesado y frescura.

Si falla PostgreSQL o el parser, mantener bandeja de evidencia pendiente para reprocesado LOCAL idempotente; no repetir el HTTP para recuperar una respuesta ya recibida. Respuestas parciales/error no reemplazan estado valido por datos incompletos. Un error no cuenta como refresco satisfactorio.

Las altas propias y consultas manuales tambien alimentaran la cache en su ambito, con niveles de completitud: respuesta de alta no equivale a tracking completo. No depender unicamente del planificador para mantenerla.

Historico, integridad y privacidad

• Sin limite fisico ni purga a 100 registros. Los ultimos 100 conocidos

pueden ser ventana inicial de trabajo o paginacion local, no un parametro remoto inventado ni un requisito de borrar el resto.

• Claves foraneas, transacciones y unicidad por ambito; indices de IDs,

fecha, estado/terminal y next_sync_at; paginacion estable local. Evaluar particionamiento solo cuando volumen real lo justifique.

• TEST y PRODUCCION separados en claves, permisos, consultas, auditoria,

presupuesto y trabajos. Una UID vive en el mecanismo seguro, nunca en entidades de cache, snapshots sanitizados ni claves de busqueda.

• UI autenticada con permisos; logs sin direccion completa, contactos ni

secretos. Original completo solo cifrado conforme al mecanismo existente; no descarga automatica de POD, firma ni enlaces externos.

• Para busqueda parcial de destinatario se propone conservar solo nombre,

CP y poblacion operativos autorizados, con acceso restringido y cifrado de almacenamiento/backup. La politica de datos debe aprobarse antes de la implementacion. Si exige cifrado de campo, hay que resolver de forma explicita el indice de busqueda: Fernet no permite ILIKE sobre el cifrado. No prometer ambas cosas ni inventar criptografia propia.

• Capacidad de historico indefinido no significa retencion perpetua de

datos personales: proponer politica aprobada de retencion/anonimizacion.

5. Politica futura de sincronizacion, desactivada en esta fase

El scheduler futuro reclamaria cada trabajo de forma exclusiva, evitando solapamiento manual/periodico y consultas duplicadas al mismo envio. Los cambios de configuracion no arrancan sincronizaciones por si solos.

La frecuencia de los manuales es recomendacion de uso razonable; no es cuota contractual ni autorizacion actual para activarla. M2 pide pactar frecuencia y subconjunto. No se ha creado ningun cron, timer o tarea.

Cuotas y eficiencia:

• No hay cuota numerica iClientes acreditada en estos documentos. Limite

desconocido no equivale a ilimitado. Definir presupuesto local y reserva aprobados; modelo futuro debe representar limite remoto desconocido.

• La politica actual de 500 solicitudes/dia y 10 IDs por solicitud es de

REST Track And Trace, no se traslada a iClientes ni GetExpCli.

• No existe lote GetExpCli documentado. 100 conocidos x 5 refrescos supondria

hasta 500 POST SOAP/dia: es estimacion de carga, NO cuota GLS ni permiso.

• Reusar datos locales frescos, deduplicar IDs conocidos, no descargar

etiquetas/POD para refrescar estado ni repetir llamadas para cada vista.

• Contabilizar cada HTTP real por producto/cuenta/entorno, con actor,

correlacion, resultado e items; una respuesta con varios exp sigue siendo una sola peticion, y su reprocesado local no consume otra llamada.

• Futuro 401/403: pausar cuenta y revisar autorizacion; 429: respetar limite

e instrucciones si se reciben; errores transitorios: backoff y presupuesto acotados. Nunca retries automaticos de GrabaServicios. No retries ahora.

6. Normalizacion de estados sin mezclar catalogos

Clave de catalogo: carrier + familia API + namespace + tipo + codigo + idioma. Los 336 codigos REST existentes siguen siendo REST; los estados del maestro iClientes y las etiquetas de Extranet son dominios distintos. Se preservan siempre codigo, literal, tipo, catalogo, fecha y version de mapeo originales.

Propuesta inicial basada en X, hoja Envios(Estados):

Estado normalizado e is_terminal son campos diferentes. No deducir el segundo solo del primero. Versionar y probar los mapeos antes de usarlos para detener refrescos. Servicios de retorno no demuestran por si solos que el envio original haya sido devuelto definitivamente.

No derivar estado actual del ultimo evento cronologico sin discriminar su tipo. El historico entregado tenia eventos administrativos posteriores a la entrega; FACTURA o disponibilidad de POD no revierten ENTREGADO. Eventos fuera de orden se conservan sin regresion automatica de estado.

7. UI futura: TRANSPORT HUB > Expediciones

No implementada en esta fase. Tabla operativa sobre PostgreSQL, sin llamada remota al entrar, paginar, filtrar, abrir detalle ni buscar por nombre.

Vistas: TODOS, EN CURSO, INCIDENCIAS, PENDIENTES, ENTREGADOS; filtros de otros estados/terminales y candidatos externos no confirmados separados. No mezclar una lista vacia de API con una expedicion pendiente confirmada.

Filtros: fecha desde/hasta (aclarar fecha de expedicion), destinatario parcial, poblacion, CP, numero expedicion, CODEXP, barcode, albaran, referencia tipada, estado, servicio y origen; tambien cuenta y entorno. IDs como texto con ceros conservados. SQL parametrizado; indices B-tree y, si se aprueba/justifica, busqueda trigram/acento en campos autorizados. No instalar extensiones ni crear indices en esta fase.

Columnas: estado/codigo original y normalizado, fecha, destinatario minimo, poblacion/CP, servicio/horario, bultos/peso, ultima sincronizacion GLS, fuente/procedencia, CACHE, frescura y ultimo error sin trazas internas. Detalle: identificadores y referencias tipadas, timeline, cambios de estado, origen conocido o unknown, y acceso autorizado a evidencia sanitizada.

Sin Internet o con GLS caido, la UI local sigue consultando cache si la aplicacion y PostgreSQL estan disponibles. Mostrar siempre:

> DATOS DE CACHE > Ultima sincronizacion GLS: [fecha/hora Europe/Madrid]

La indisponibilidad de PostgreSQL es distinta: no prometer cache accesible sin su almacenamiento. Si un dato nunca se sincronizo, indicarlo en vez de mostrar una hora inventada. Vigencia configurable por clase/recurso.

Accion manual Actualizar: permiso, CSRF, confirmacion y presupuesto; no recuperar POD/etiquetas ni encadenar mas consultas implicitamente. La peticion util resultante se ingiere una vez en cache, sin segundo HTTP.

8. Riesgos y preguntas concretas para GLS

1. Facilitar XML IN/OUT y manual vigente de GetEnvios y GetManifiesto: autenticacion, ambito, efectos, autorizacion y ejemplos completos. 2. Existe consulta read-only de todos los envios de esta cuenta entre fechas, recientes, pendientes/no definitivos o modificados desde una marca? Que campo de fecha usa, timezone, bordes inclusivos y orden? 3. Limites: ventana maxima, filas, cuota/rate limit, concurrencia, pagina, cursor, senal de truncamiento, expiracion, retencion y cambios tardios. Como obtener cobertura completa sin saltos/duplicados? 4. Que significa Pendiente Grabar en cada grupo de Extranet y cuando pasa a ser consultable? Confirmar si los numeros [IDENTIFICADOR OMITIDO], [IDENTIFICADOR OMITIDO] y [IDENTIFICADOR OMITIDO] son CODEXP de iClientes o identificadores de otra fase. 5. Confirmar ambito de cuenta/agencia de la UID, visibilidad cruzada de canales y relacion con usuario Extranet, sin enviar secretos en soporte. 6. Como se obtiene la lista completa de CODEXP recientes y sus GUID/barcode? Hay exportacion oficial o push aplicable a nuestro volumen y cuenta? 7. Precisar relacion entre referencia C/0/S, albaran, numero visible, agencia, CODEXP y devoluciones; unicidad/estabilidad por ambito. 8. Confirmar catalogos vigentes, terminalidad, estado 5 y tratamiento de eventos administrativos, tardios y correcciones tras entrega. 9. Acordar frecuencia, presupuesto de consultas y alcance de reintentos; si existe push, contrato de entrega/repeticion, autenticacion, replay y carga inicial. No extrapolar semantica de envio una vez a garantia tecnica.

Riesgos clave: dar por completa una cache parcial, adivinar filtros XML, mezclar cuentas/entornos, fusionar por referencias no unicas, confundir lista vacia con borrado o estado, convertir una recomendacion en cuota y dar por definitivo ANULADA 5. El diseno los contempla, no los declara resueltos por esta muestra.

9. Verificaciones y limites respetados

• Comprobacion local con dobles: solo los tres CODEXP permitidos; bloqueo

de repeticion, barcode, albaran, numero con agencia, otro CODEXP y GetExp.

• Tres transmisiones, cero retries y cero operaciones GLS adicionales.
• Antes/despues de las llamadas: mismos hashes de filas de ensayos,

shipments, parcels, tracking_events y synchronizations. Filas de estas cuatro ultimas: 0; ensayos: 3; etiquetas originales: 4; trabajos de impresion: 6. Ninguna etiqueta, impresion ni expedicion nueva.

• Ningun cambio de codigo de aplicacion, configuracion, UID, infraestructura,

esquema SQL, migraciones, UI, scheduler o tablas de cache.

• Se conserva auditoria de las consultas y este unico informe documental;

no se importaron respuestas a un repositorio de expediciones.

• No se ha ejecutado una bateria completa de tests de la aplicacion:

no hay cambios funcionales. Se comprobaron offline las restricciones del auxiliar de consulta y se verificaron resultados e integridad local.

Contadores del lote:

El historico 11 incluye 6 iClientes TEST y 5 REST sandbox ya existentes; no se reclasifica ni se mezcla con PRODUCCION.

Decision propuesta: solicitar a GLS el contrato de descubrimiento; aprobar despues una implementacion incremental de cache de conocidos y su politica de datos. No activar sincronizacion ni realizar mas llamadas para suplir documentacion ausente. Trabajo detenido con este informe.

---

Suplemento prioritario: enumeracion por fechas, 05/11/2026

Este suplemento prevalece sobre las propuestas de pruebas anteriores. No autoriza consultas individuales ni ShipIT. Trabajo documental y local, sin llamadas de negocio GLS.

Resumen ejecutivo

1. Busqueda por fechas mediante API domestica: NO se ha encontrado un contrato utilizable. No equivale a demostrar que GLS no disponga de esa capacidad. 2. Operacion: GetEnvios es candidata, no confirmada. GetManifiesto tampoco esta acreditada. 3. Prueba nueva: 0 llamadas. No hay contrato interno ni garantia de lectura/alcance suficiente. 4. Las 61 expediciones del 04/11/2025 al 04/12/2025: NO DEMOSTRADO por API. La evidencia positiva de Extranet procede de Juan, no de una nueva consulta nuestra. 5. GLS debe facilitar el IN/OUT/XSD del listado por cuenta/fechas, su semantica y completitud. 6. Se entregan cuatro informes completos, indice, manifiesto SHA-256 y ZIP privado descargable. 7. El repositorio puede disenarse e implementarse en una fase posterior autorizada con fuentes desacopladas y cobertura explicita. No puede declararse completa la importacion/sincronizacion.

Alcance realmente inspeccionado

Nueva inspeccion read-only en la VM 214: 316 archivos documentales/de codigo/evidencia/log, dos archivos TAR de respaldo y el ZIP original GLS_API. Se inspeccionaron tambien las copias de despliegue y .backups dentro del proyecto, los tests/fixtures, catalogos y fuentes actuales. No se recorrieron historiales o credenciales ajenas al proyecto.

• WSDL original completo, 25 operaciones unicas; elementos, mensajes, portTypes, bindings,

tipos nombrados, referencias, anotaciones, acciones y direcciones.

• Dos PDF completos (11 y 6 paginas), siete XML iniciales y originales de Anula; XLSX,

todas sus ocho hojas y XML internos. No nuevo contrato de listado en el maestro.

• ZIP original: 23 entradas contando directorios, 11 documentos originales utiles;

el unico miembro que menciona GetEnvios/GetManifiesto es b2b.wsdl.

• Codigo actual y respaldos: las unicas menciones exactas en las fuentes activas son

del catalogo iclientes_catalog.json. No hay constructor/parser/fixture de listado oculto. El cliente reutilizable valida GrabaServicios, GetExpCli y EtiquetaEnvioV2; el auxiliar de Anula previo no convierte el resto de firmas en operaciones implementadas.

• Logs locales, articulos KB, indices documents/knowledge_articles/official_documents,

registros de llamadas y 15 respuestas SOAP originales cifradas. No hay ejecucion historica de GetEnvios o GetManifiesto en las evidencias observadas.

• Documentacion publica oficial/host historico ASM: se revisaron las ayudas y el indice,

sin descargar WSDL online, sin portal automatizado, sin scraping Extranet ni SOAP/REST/OAuth.

Evidencia mecanica local, no incluida como respuesta masiva de clientes: [RUTA INTERNA OMITIDA] y [RUTA INTERNA OMITIDA]. No se afirma una revision universal de fuentes privadas externas no preservadas.

Contrato real: seguimiento de referencias, no solo firma superficial

Fuente primaria W: [RUTA INTERNA OMITIDA]. 63502 bytes; SHA-256 3ea7a6edcd64c5756e1ccd5da8883823900406c130f8f150b9d9d97ead17b6cd. La copia tiene texto inicial/prefijos no declarados: se contrasto literalmente, sin repararla.

No hay import/include/schemaLocation de XSD ni anotaciones documentation en esta copia. No aparece un XSD adicional en [RUTA INTERNA OMITIDA] Se siguieron todos los seis tipos complejos nombrados: ArrayOfBase64Binary, ValidateUidClienteRequest/Response, ArrayOfString, GetTSPRequest/Response. El tipo simple TiposEtiqueta solo enumera formatos de etiqueta. Ninguno resuelve el XML interno de las dos operaciones candidatas.

No consta campo de fecha, cuenta, estado, limite, pagina o cursor aplicable al listado. Los datos de cliente/agencia en ValidateUidCliente y de pais/CP/servicio en GetTSP no pueden trasladarse a GetEnvios. El s:any permite XML arbitrario sintacticamente, pero no documenta que el servidor lo acepte ni que sea una consulta sin efectos. No usar docIn vacio, asteriscos, rangos de CODEXP o referencias como sustituto de contrato.

Evaluacion funcional de alternativas

La matriz completa de las 25 operaciones se conserva arriba, con input/output y evidencias. Para el objetivo concreto:

M1 p.2 explica NO diferido, YourGLS y restricciones del listado de manifiesto. Esa explicacion no define una llamada inversa para listar todo lo creado desde Extranet. M1 p.11 y M2 p.3 recomiendan refrescar conocidos no definitivos; es seleccion local, no prueba de que el servidor filtre todas las expediciones activas de la cuenta. M2 p.2/p.6 documenta codigo/UID y expediciones relacionadas; no fechas ni comodines.

Ampliacion publica oficial: resultado y limites

Consulta documental el 05/11/2026; ninguna llamada de negocio ni descarga de WSDL. Las ayudas publicas historicas corroboran el wrapper de entrada/salida, pero siguen representando el contenido como XML indeterminado; no aportan un ejemplo de fechas:

• Ayuda ASM GetEnvios.
• Ayuda ASM GetManifiesto.
• Indice publico b2b ASM.

El indice publico y sus versiones indexadas muestran ademas nombres no presentes en la copia offline: EtiquetaEnvioBultoV2, GetZonaCloser, GetZonaCloserPS; otra version indexada menciona GetCloserInfoOffline y GetMaestroValijas. Las ayudas de esos nombres no pudieron recuperarse mediante el servicio web de consulta documental (cache miss). No se han probado, no se trasladan al endpoint contratado, no se atribuye lectura o enumeracion a sus nombres y no se sustituye el WSDL offline por este indice variable. No se ha localizado una especificacion publica oficial IN/OUT de listado por fechas.

Las busquedas abarcaron nombres exactos, docIn, uidcliente, fechas, XML IN/OUT, iClientes, listado, rangos y manifiestos en dominios GLS/ASM y busqueda general. Se descartaron coincidencias de otros transportistas/Notifica y APIs de otros paises: compartir el nombre GetEnvios no acredita el contrato domestico de GLS Espana. Una busqueda negativa no prueba inexistencia del servicio ni falta de habilitacion.

Decision de prueba y unica preparacion admisible

NO EJECUTADA: contrato interno no acreditado. No se ha gastado el presupuesto en GetExpCli de conocidos, OAuth ni pruebas ShipIT. La ausencia de un listado utilizable es bloqueo documental, no un nuevo HTTP 401/500 ni una prueba de credencial.

La futura consulta 1 se acotaria a la cuenta 2004/35 y al 04/11/2026, sin CODEXP, GUID, barcode, albaran ni referencia. Fecha propuesta, pendiente de contrato GLS; no hay payload exacto seguro que pueda generarse con las fuentes actuales.

Transporte conocido: POST al endpoint domestico, SOAP 1.2, TLS validado, action GetEnvios solo si GLS confirma que es la operacion correcta. UID desde el almacen seguro en el campo que confirme su IN oficial. Timeout configurado, sin retries, sin redirecciones ni llamadas auxiliares. Una peticion como maximo y parada.

Antes de autorizar envio: validar XML/XSD, cuenta, campo temporal, extremos, zona, fecha corta, estados incluidos, ausencia de cierres/efectos, limite y completitud. Capturar HTTP/negocio/conteo/IDs/latencia/paginacion y original cifrado antes del parser. Un HTTP 200 o varios resultados NO bastan si el resultado puede estar truncado. Si existe paginacion, registrar cursor/has_more/total y detenerse tras la primera llamada: no consumir una segunda pagina automaticamente bajo este presupuesto.

La consulta historica 04/11/2025-04/12/2025 queda pendiente de revision y otra autorizacion, aun si la primera funcionase. Para contrastar 61 hay que igualar cuenta, criterio de fecha, inclusividad, estados/canales y unidad expedicion (no bultos/eventos), y comprobar que se recuperaron todas las paginas. Igualdad de conteo sola no demuestra igualdad de conjuntos: contrastar tambien identificadores contra exportacion autorizada.

Matriz de profundidad historica: tres capacidades distintas

Plan futuro, no ejecutado: tras contrato y prueba reciente, comparar el periodo de 61 con autorizacion; despues bloques temporales progresivos hasta agosto 2025 segun limites GLS. Registrar por ventana/cuenta/criterio las tres profundidades por separado. Respuesta vacia no es retencion demostrada: distinguir falta de datos, permiso, filtro/fecha equivocado, cuenta anterior, truncamiento y purga documental.

Correo tecnico a GLS Iberia (BORRADOR, NO ENVIADO)

Asunto: iClientes - listado por cuenta y fechas sin identificadores (agencia 2004 / cliente 35)

Hola:

Usamos la API domestica iClientes recomendada para nuestra cuenta. GetExpCli ya recupera expediciones conocidas de Extranet. Necesitamos descubrirlas sin conocer CODEXP, GUID, barcode ni referencia.

Que operacion permite listar todas las expediciones de nuestra cuenta entre dos fechas? El WSDL offline declara GetEnvios/GetManifiesto con docIn generico, sin su contrato interno. Necesitamos XML IN/OUT o XSD y confirmacion de lectura sin creacion, modificacion ni cierre, autenticacion y alcance a nuestra cuenta.

Como contraste, Extranet devuelve 61 expediciones del 04/11/2025 al 04/12/2025. Confirmad junto al contrato:

• Cobertura de altas Extranet e iClientes, incluidas pendientes, grabadas, activas,

entregadas, anuladas y diferidas, y cuando pasan a ser visibles.

• Campo temporal filtrado, formato, zona horaria e inclusividad de extremos.
• Paginacion/limites/truncamiento y procedimiento para garantizar todos los resultados.
• Retencion de listado, ficha y eventos desde agosto 2025; retencion distinta de POD si existe.
• Cuotas/frecuencia recomendada para descubrimiento y refresco diario.
• Si la cuenta anterior de otra agencia requiere su propia UID/autorizacion.

Si esta API no ofrece listado, indicad la alternativa oficial para obtener todos los identificadores por cuenta/fechas (exportacion o suministro acordado).

Gracias. No adjuntamos ni solicitamos reenviar credenciales en este correo.

Contadores y limites de esta entrega

Al inicio: iClientes PRODUCCION 10; iClientes TEST 6; REST registrados 5; historico TEST/laboratorio 11; global api_requests 21. Cero llamadas nuevas. No se envian correos, no se implementa repositorio ni conector, no se migra, no se reinicia, no se imprime ni se modifica configuracion/credenciales. Solo se crean/actualizan copias documentales de exportacion en la ubicacion solicitada. La comprobacion final de integridad y contadores se incorpora al indice de entrega.