REPORTE MAPA DE CALOR

Fuente:  /var/www/html/qareportes/app/Http/Controllers/Cloud/ReportController.php

1) Nombre del reporte

• Nombre: Reporte Mapa de Calor

• Código / Alias: report_mapa_calor

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• os.ose_fhemision (Órdenes)

• ent.ent_fecha (Entregas)

• comp.cop_fechaemision (Comprobantes)

• Tipo de rango (diario / mensual / personalizado): Mensual (automático, abarca los últimos 2 meses o más si inicio de año)

• 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: Empresarial

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica):  os

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden de servicio

• ose_montototal → Monto total de la orden

• ose_fhemision → Fecha de emisión de la orden

• usercreaid → Usuario creador

• ose_estadoPago → Estado de pago

• ose_tipoanulado → Tipo de anulación

• ose_estado → Estado activo o inactivo

• eliminado → Indicador de eliminación lógica

• Condiciones (WHERE) aplicadas: 

• Se filtran solo las órdenes de servicio que estén activas, no anuladas y no eliminadas, creadas por usuarios válidos, y cuya fecha de emisión esté dentro del rango de fechas seleccionado (desde la fecha inicial hasta la fecha final del reporte).
  
  

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

• Observaciones (ej. particiones, índices):

• Se agrupa por fecha y usuario (GROUP BY fecha, usuario).

• Los resultados se ordenan por fecha DESC.

• Usa agregaciones COUNT() y SUM().

3.2 Conexión / Base: Empresarial

• Tabla / Recurso: emp_entrega

• Alias (si aplica):  ent

• Campos utilizados (clave → descripción):

• ent_fecha → Fecha de entrega

• ent_user → Usuario que realizó la entrega

• ent_osid → Relación con emp_ordenservicio (FK)

• ent_eliminado → Indicador de eliminación lógica

• Condiciones (WHERE) aplicadas:  Se seleccionan únicamente las entregas registradas por usuarios válidos, que no estén eliminadas, y cuya fecha de entrega esté dentro del rango de fechas del reporte.

• Además, solo se consideran aquellas entregas vinculadas a órdenes de servicio que también estén activas, no anuladas y no eliminadas.
  
  

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

• emp_ordenservicio as os Llave de unión: os.ose_id = ent.ent_osid

• ose_id → Identificador de orden

• ose_montototal → Monto total

• ose_estadoPago → Estado de pago

• ose_tipoanulado → Tipo de anulación

• ose_estado → Estado de registro

• eliminado → Indicador de eliminación

• Observaciones (ej. particiones, índices):

• Se agrupa por fecha y usuario.

• Se utilizan funciones COUNT() y SUM().

3.3 Conexión / Base: Empresarial

• Tabla / Recurso: emp_comppago

• Alias (si aplica):  comp

• Campos utilizados (clave → descripción):

• cop_id → Identificador del comprobante

• cop_montoTotal → Monto total del comprobante

• cop_fechaemision → Fecha de emisión

• usercreaid → Usuario creador

• cop_estado_pago → Estado de pago

• cop_estado → Estado activo

• eliminado → Indicador de eliminación

• Condiciones (WHERE) aplicadas: Se incluyen solo los comprobantes de pago activos, no anulados, no eliminados, registrados por usuarios válidos, y emitidos dentro del rango de fechas del reporte.
  
  

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

• Observaciones (ej. particiones, índices):

• Agrupación por fecha y usuario.

• Ordenamiento por usuario DESC.

3.4 Conexión / Base: Empresarial

• Tabla / Recurso: emp_usuario

• Alias (si aplica):  No aplica

• Campos utilizados (clave → descripción):

• usr_id → Identificador del usuario

• usr_terminalid → Terminal asignada al usuario

• usr_rol → Rol o perfil del usuario

• Condiciones (WHERE) aplicadas:  No se aplica ningún filtro. Se obtienen todos los usuarios registrados para agruparlos y asociarlos con sus terminales.
  
  

• Tipo de unión con otras fuentes (JOIN y llave):  Se usa como referencia para asociar usuario → terminal.

• Observaciones (ej. particiones, índices): El resultado se agrupa por ID para crear $users_group.

3.5 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 del terminal

• ter_zona → Zona asignada

• Condiciones (WHERE) aplicadas:  No hay condición aplicada. Se obtienen todos los terminales existentes para mostrar su nombre y zona en el reporte.
  
  

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

• Observaciones (ej. particiones, índices): Se usa para asignar nombre de terminal en el reporte.

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Órdenes, entregas y comprobantes activos y no anulados.

• Usuarios con terminal asociada.

• Exclusiones (reglas de descarte):

• Estados de pago “DA” o “AN”.

• Eliminados (eliminado = 0).

• Reglas por estado / habilitado: Solo status = 1 (activos).

• Parámetros externos (si el usuario puede filtrarlo): Ninguno (fechas automáticas generadas por lógica interna).

5) Transformaciones y Reglas de negocio

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

• acciones = suma de todas las horas (0–23) por terminal y día.

• qty y amount acumulados por hora.

• Tablas creadas mensualmente con sufijo YYYY_MM.

• Mapeos de estado:

• status = 1 → correcto

• status = 0 → error al generar

• Reglas de validación (p.ej., sólo registros validados):

• Se ignoran registros sin fecha, usuario o terminal.

• Rango horario debe estar entre 0–23.

• Reglas condicionales (si X entonces Y):

• Si no existe la tabla → crearla.

• Si existe → truncarla antes de insertar.

6) Estructura de salida

• Tabla/archivo destino: report_mapa_calor_YYYY_MM

• Particionado / sufijo: Mensual (YYYY_MM)

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

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

• terminal_id → VARCHAR(255) → ID de terminal

• terminal → VARCHAR(255) → Nombre

• fecha → DATE → Día

• 0–23 → VARCHAR(20) → Cantidad de acciones por hora

• acciones → VARCHAR(20) → Total diario

• created_date → DATETIME → Fecha de creación

• status → TINYINT(4) → Estado (1 activo, 0 error)

• Ordenamiento por defecto: fecha DESC

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 2 meses (con excepción de inicio de año)

• Tamaño de lote / paginado (chunking): array_chunk($detail, 900)

• Tolerancia a fallos / reintentos: Inserta registro en error_reports y continúa.

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

8) Calidad y controles

• Validaciones previas/post:

• Verificación de tabla (verifyExistTable)

• Inserción de validaciones en emp_reportes_validation

• Controles de duplicados: Truncado antes de reinserción mensual

• Métricas de completitud (qué se monitorea):

• Conteo de rangos procesados

• Estado de inserción (status)

9) Dependencias externas

• APIs / servicios y endpoints: No aplica (solo BD locales)

• Autenticación / headers: No aplica

• Mapeos y contratos de datos: Interno entre conexiones empresarial, centos, reportes

10) Historial de cambios

2025-16-01 18:00 - Elian Franco Arroyo Rodas - Documentación inicial