REPORTE DESECHOS

Fuente:  /var/www/html/web-services-qa/app/Http/Controllers/Cloud/ReportController.php

1) Nombre del reporte

• Nombre: Reporte Desechos

• Código / Alias: report_desecho

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• ose_fhpreferenciapartida (ordenes de servicio)

• fecha_registro (procesos en inventario)

• created_date (registro de inserción en tablas de reporte y validación)

• Tipo de rango (diario / mensual / personalizado): Mensual y diario (se construyen periodos por mes y se recorren días dentro del rango).

• Inclusión de horas (sí/no).: Sí → [00:00:00 – 23:59:59]

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: CENTOS

• Tabla / Recurso: emp_reportes_validation

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• report → Nombre del reporte (report_desecho)

• first_date → Fecha de inicio del rango

• second_date → Fecha de fin del rango

• created_date → Fecha de creación del registro en la tabla de validación

• status → Estado de ejecución (1 = correcto, 0 = error)

• Condiciones (WHERE) aplicadas: No aplica (solo inserción directa de datos procesados)

• Tipo de unión con otras fuentes (JOIN y llave): No aplica

• Observaciones (ej. particiones, índices): Tabla usada como bitácora/validación de ejecución de reportes.

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador de terminal

• ter_nombre → Nombre de la terminal

• Condiciones (WHERE) aplicadas:Excluye terminales con IDs [210, 248, 259, 268, 269, 349, 351, 352, 353, 354, 367].

• Tipo de unión con otras fuentes (JOIN y llave): No aplica

• Observaciones (ej. particiones, índices): Se usa para armar catálogo de terminales.

3.3 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): Ninguno (se usa sin alias)

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden de servicio

• ose_termdestinoentrega → Terminal destino de entrega

• ose_termorigenatencion → Terminal origen de atención

• ose_observacion_cambioprecio → Tipo de orden de servicio

• ose_estadoPago → Estado de pago

• ose_fhpreferenciapartida → Fecha preferencial de partida

• ose_remitecontactomail → Correo de contacto remitente (confirmado)

• ose_remitecontactofono → Teléfono de contacto remitente

• ose_entregadopersonadni → DNI de quien recibe entrega

• ose_estadoentregado → Estado de entrega

• Condiciones (WHERE) aplicadas:

• ose_estadoPago != 'AN'

• ose_tipoanulado = ''

• ose_estado = '1'

• eliminado = '0'

• ose_fhpreferenciapartida entre first_date y second_date

• Tipo de unión con otras fuentes (JOIN y llave): No aplica

• Observaciones: Filtra OS activos, no anulados y dentro del rango de fechas.

3.4 Conexión / Base: CENTOS

• Tabla / Recurso: emp_embarque_desecho (alias embdes)

• Alias (si aplica): embdes

• Campos utilizados (clave → descripción):

• embdes.ose_id → ID de orden de servicio

• embdes.fecha → Fecha de embarque de desecho

• Condiciones (WHERE) aplicadas: embdes.estado = 1

• Tipo de unión con otras fuentes (JOIN y llave): No aplica

• Observaciones: Trae embarques confirmados como desecho.

3.4 Conexión / Base: CENTOS

• Tabla / Recurso: emp_os_desechos_confirmados

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• idos → Identificador de OS confirmado como desecho

• terminal → Terminal relacionada

• Condiciones (WHERE) aplicadas: status = 1

• Tipo de unión con otras fuentes (JOIN y llave): No aplica

• Observaciones: Refuerza confirmación de OS en desecho.

3.5 Conexión / Base: CENTOS / CENTOS2 OLD

• Tabla / Recurso: emp_procesos_historial_app

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• idose → ID de OS

• nombre_metodo → Método registrado (ej. registrar_Entrega)

• fecha_registro → Fecha de registro

• proceso → Proceso ejecutado (ej. inventario)

• Condiciones (WHERE) aplicadas:

• idose = valor de OS pendiente

• status = 1

• proceso = 'inventario'

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (consulta individual por OS pendiente)

• Observaciones: Permite detectar entregas en inventario y calcular pendientes.

4) Filtros globales del reporte

• Inclusiones (must-have):

• Solo órdenes activas y no eliminadas

• Rango de fechas válido

• Exclusiones (reglas de descarte):

• Destino = 74

• Tipo de OS = "Retiro de mercadería"

• Reglas por estado / habilitado:

• ose_estadoPago == "DA" → Desecho

• ose_estadoentregado != 1 → Pendiente de entrega

• Inventario con más de 7 días sin actualización → Pendiente de actualización

• Parámetros externos (si el usuario puede filtrarlo): Fecha ($first_date, $second_date)

5) Transformaciones y Reglas de negocio

• Derivaciones de campos (cómo se calculan): 

• Conteo de métricas por terminal y periodo: 

• recibidos 

• desecho 

• pend_entrega 

• pend_actualizacion 

• proceso_embarque_lima 

• confirma_desecho
  
  

• Mapeos de estado: 

• "DA" → Desecho

• Otros valores → Pendiente o entregado según reglas.

• Reglas de validación (p.ej., sólo registros validados): Contacto obligatorio (mail o fono) para algunos casos.

• Reglas condicionales (si X entonces Y): Diferente conexión de BD según año/mes.

6) Estructura de salida

• Tabla/archivo destino: report_desecho_YYYY_MM

• Particionado / sufijo: Por año y mes (YYYY_MM)

• Clave(s) primaria(s) o únicas: id (autoincremental)

• Columnas del reporte (nombre → tipo → descripción):

• periodo → VARCHAR → Fecha agrupada

• id_agencia → VARCHAR → ID de la agencia

• agencia → VARCHAR → Nombre de la agencia

• recibidos → VARCHAR → OS recibidas

• desecho → VARCHAR → OS desechadas

• proceso_embarque_lima → VARCHAR → Procesos de embarque

• confirma_desecho → VARCHAR → OS confirmadas como desechos

• pend_entrega → VARCHAR → Pendientes de entrega

• pend_actualizacion → VARCHAR → Pendientes de actualización (>7 días)

• created_date → DATETIME → Fecha de inserción

• status → TINYINT → Estado del registro (1 = activo, 0 = inactivo)

• Ordenamiento por defecto: No explícito; implícitamente por periodo y id_agencia

7) Frecuencia y operación

• Frecuencia de actualización: PENDIENTE (Esperando info de Eduardo)

• Ventana que recalcula (días/meses): Dependiendo del rango (meses o días dentro del mes)

• Tamaño de lote / paginado (chunking): 20,000 (pendientes) y 900 (inserciones)

• Tolerancia a fallos / reintentos: Control con try/catch, rollback en transacciones

• Tiempos de ejecución esperados: PENDIENTE (Esperando info de Eduardo)

8) Calidad y controles

• Validaciones previas/post: Verificación de existencia de tabla (verifyExistTable)

• Controles de duplicados: Agrupamiento de órdenes por ose_id

• Métricas de completitud (qué se monitorea): Conteo de estados por terminal y periodo

9) Dependencias externas

• APIs / servicios y endpoints: Ninguno explícito; todo interno a BD

• Autenticación / headers: Acceso por conexiones DB internas (empresarial, centos, reportes)

• Mapeos y contratos de datos: Tablas dinámicas creadas con estructura fija

10) Historial de cambios

2025-10-02 17:59 - Elian Franco Arroyo Rodas - Documentación inicial