6.10. Flujo validación dolly
Este documento migra el endpoint legacy:
GET /recoleccion_movil/ValidaPKG_RS/valida?tractor&dolly=1234&pipa&prov=ALPURA
que devuelve:
{ "tipo": "dolly", "descripcion": "" }
al nuevo servicio de validación de activos/catálogos y su mapeo a la base de datos.
1) Nuevo servicio equivalente
Servicio: Reference Data Catalog Service (v1)
Endpoint: POST /reference-data/v1/equipment/_validate
Descripción: Valida existencia/estatus de unidades de transporte (tractor, pipa, dolly) y proveedores.
Auth/Headers: OAuth2 (reference-data.read), X-Trace-Id.
El legacy recibía los elementos como query params. En el modelo nuevo, se unifica en un JSON indicando
tipoycodigo(oproveedor).
1.1 Request (nuevo) — equivalente a la URL de ejemplo
POST /reference-data/v1/equipment/_validate
Content-Type: application/json
{
"tipo": "dolly",
"codigo": "1234"
}
Para proveedor:
{ "tipo": "proveedor", "codigo": "ALPURA" }
1.2 Response (nuevo — equivalente)
{
"tipo": "dolly",
"descripcion": "Dolly operativo",
"valido": true,
"detalles": {
"estatus": "ACTIVO",
"ultima_actualizacion": "2025-09-01T10:35:00Z"
}
}
2) Mapeo a Base de Datos
La validación se resuelve contra catálogos maestros de unidades y proveedores. Los nombres pueden variar por instancia; aquí se muestra una convención típica.
2.1 Tablas involucradas (propuesta estándar)
- CAT_UNIDADES_TRANSPORTE
TIPO_UNIDAD(values:TRACTOR|PIPA|DOLLY)CLAVE_UNIDAD(código/placa/número económico)DESCRIPCIONESTATUS(ACTIVO/INACTIVO)LAST_UPDATE_DATE
- CAT_PROVEEDORES_TRANSPORTE
CLAVE_PROVEEDOR(e.g.,ALPURA)NOMBRE_PROVEEDORESTATUSLAST_UPDATE_DATE
2.2 Mapeo de campos (API ↔ BD)
| Campo (API) | Tabla.Columna | Notas |
|---|---|---|
tipo | CAT_UNIDADES_TRANSPORTE.TIPO_UNIDAD | constante proveedor | Determina la tabla y filtro |
codigo | CAT_UNIDADES_TRANSPORTE.CLAVE_UNIDAD | CAT_PROVEEDORES_TRANSPORTE.CLAVE_PROVEEDOR | Input de búsqueda |
descripcion | CAT_UNIDADES_TRANSPORTE.DESCRIPCION | CAT_PROVEEDORES_TRANSPORTE.NOMBRE_PROVEEDOR | Texto legible |
valido | Derivado (ESTATUS = 'ACTIVO') | Booleano |
detalles.* | ESTATUS, LAST_UPDATE_DATE | Metadatos útiles |
Si tus catálogos usan otro esquema (por ejemplo,
ALP_*o FND Flex Values), ajusta los nombres a:ALP_FND_FLEX_VALUES/ALP_FND_FLEX_VALUES_TLpara equivalentes de código/descripcion/estatus.
3) SQL de referencia
3.1 Validación de dolly/tractor/pipa
SELECT
TIPO_UNIDAD,
CLAVE_UNIDAD,
DESCRIPCION,
ESTATUS,
LAST_UPDATE_DATE
FROM CAT_UNIDADES_TRANSPORTE
WHERE TIPO_UNIDAD = :tipo_unidad -- 'DOLLY' | 'TRACTOR' | 'PIPA'
AND CLAVE_UNIDAD = :codigo
FETCH FIRST 1 ROWS ONLY;
3.2 Validación de proveedor
SELECT
CLAVE_PROVEEDOR,
NOMBRE_PROVEEDOR AS DESCRIPCION,
ESTATUS,
LAST_UPDATE_DATE
FROM CAT_PROVEEDORES_TRANSPORTE
WHERE CLAVE_PROVEEDOR = :codigo
FETCH FIRST 1 ROWS ONLY;
4) Reglas de negocio sugeridas
- Normalización de
tipo: mapeartractor|pipa|dolly|proveedora mayúsculas:TRACTOR|PIPA|DOLLY|PROVEEDOR. - Booleano
valido:ESTATUS = 'ACTIVO'→true; de lo contrariofalseydescripcionopcionalmente con motivo. - Fallback de descripción: si
DESCRIPCIONesNULL, usarCLAVE_UNIDADoNOMBRE_PROVEEDOR. - Auditoría/Telemetry: registrar
X-Trace-Id, latencia y origen de la solicitud.