Historial de cambios

Cambios importantes del API de TEALCA.

[Sin publicar]

GET /store, GET /store/{code} y GET /store/coverage: cada tienda incluye el campo is_platform.
POST /shipment, GET /shipment/{shipment_identification}, POST /shipment/cancel, GET /customer/{customer_identification}/shipments, POST /preshipment y GET /preshipment/{preshipment_identification}: origin_store y destination_store incluyen el campo is_platform.
GET /location: default_destination_store incluye el campo is_platform.
GET /store/coverage: nuevo parámetro opcional location_code. Cuando las coordenadas no resuelven a una sola tienda de esa localidad, el endpoint devuelve la plataforma que la atiende.

GET /location: default_destination_store se resuelve con el nuevo algoritmo de cobertura, por lo que puede ser una tienda distinta, puede ser una plataforma y es nulo cuando la localidad no tiene cobertura.
POST /shipment, POST /preshipment, POST /shipment/price-calculation, GET /shipment/{shipment_identification}/price-calculation, POST /warehouse/delivery-order y POST /shipment-bulk/{header_id}/execute: cuando se omite origin.store o destination.store en un servicio de oficina, la tienda siempre se resuelve por cobertura, por lo que la tienda asignada puede ser distinta a la asociada a la localidad y puede ser una plataforma.
En esos mismos endpoints, la tienda resuelta por cobertura también se valida contra las tiendas bloqueadas, por lo que ahora se rechaza una guía que llega a una tienda bloqueada sin indicarla.
En esos mismos endpoints, los errores de cobertura se reportan según su motivo, que incluye zonas sin cobertura, tiendas inactivas, tiendas bloqueadas, tiendas fuera del catálogo y localidades cubiertas por varias tiendas sin una plataforma. El mensaje indica las tiendas candidatas.
POST /shipment, POST /document, POST /manifest y POST /preshipment: la lista de la respuesta mantiene el orden de la lista enviada en la solicitud.
GET /store/coverage: un location_code que no existe se reporta con el error de localidad inexistente, y un punto fuera de cobertura se reporta como no ubicado dentro de un área de cobertura de TEALCA.

POST /shipment, POST /preshipment, POST /shipment/price-calculation, GET /shipment/{shipment_identification}/price-calculation, POST /warehouse/delivery-order y POST /shipment-bulk/{header_id}/execute: enviar origin.coordinates o destination.coordinates para recolección o entrega a domicilio ya no produce un error del servidor.
En esos mismos endpoints, cada guía se tarifa con la zona que le corresponde, lo que evita que una guía se tarife con la zona de otra.

POST /shipment, POST /preshipment y POST /document: el nombre de una persona natural debe contener al menos dos palabras, y el nombre de una cuenta jurídica acepta además el carácter +.

POST /shipment, POST /preshipment y PUT /shipment/{shipment_header_id}/shipment-parcel: El mensaje de error al intentar crear guías de clientes corporativos con un factor volumétrico igual o menor a cero ahora indica el código de línea de facturación y el factor configurado, en lugar de ser un mensaje genérico.
POST /shipment, POST /preshipment y POST /document: el mensaje de error para nombres inválidos distingue entre cuentas naturales y jurídicas.

GET /tracking/shipment/{shipment_identifier_list}: cada guía en la respuesta incluye los campos preshipment_number y shipment_partner_id, vacíos cuando la guía no los tiene.
POST /shipment, POST /preshipment y POST /warehouse/delivery-order: los campos shipment_list, preshipment_list y delivery_order_list aceptan un máximo de 20 elementos por solicitud.

POST /shipment: los campos shipper.name y consignee.name aceptan los caracteres ñ y Ñ.

Todos los endpoints están disponibles también bajo el prefijo /api/v1/.
Nuevo endpoint GET /customer/{customer_identification}/shipments: lista las guías donde el cliente es el remitente o el destinatario, con paginación por cursor.

Registrar un POD (prueba de entrega) mediante POST /pod también actualiza el estatus y la información de tracking de la guía.
POST /pod: el campo account_id acepta un UUID en cualquier formato estándar. Los valores mal formados se rechazan durante la validación de la solicitud en lugar de causar un error del servidor.
POST /shipment: la creación de guías corporativas se rechaza cuando la tienda destino (destination.store) no está disponible, o está bloqueada, para el contrato de la línea de facturación. El mensaje de error identifica la guía, la tienda y el motivo.

Las rutas sin el prefijo /api/v1/ se eliminarán próximamente. Se recomienda migrar a las rutas versionadas.

PUT /shipment/{shipment_header_id}/shipment-parcel: el parámetro de la ruta acepta el ID de la guía o el número de guía.
POST /shipment: los valores de shipment_header_reference usados por guías anuladas o sustituidas pueden reutilizarse en nuevas guías.

Nuevo endpoint GET /preshipment: devuelve las preguías creadas entre date_from y date_to, cada una con su remitente, destinatario, estado actual, la fecha en que alcanzó cada etapa y los pesos declarado, validado y facturado. Los resultados se paginan con cursor y page_size. El rango máximo por consulta es de 31 días.
Nuevos endpoints /shipment-bulk para el nuevo proceso de carga masiva de guías en MiTealca: POST /shipment-bulk, GET /shipment-bulk/list, GET /shipment-bulk/{header_id}, GET /shipment-bulk/{header_id}/progress y GET /shipment-bulk/{header_id}/file.

GET /tracking/shipment/{shipment_identifier_list}: cada registro de tracking incluye el campo event_id, junto con event y event_category, para que los sistemas que lo consumen puedan reaccionar sin depender del texto.

Correcciones de errores en cotización (POST /shipment/price-calculation y GET /shipment/{shipment_identification}/price-calculation), creación de guías (POST /shipment) y la documentación pública en /api/docs.