Ir al contenido principal

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



No hay comentarios para mostrar

Volver arriba