Ir al contenido principal

REPORTE PROGRAMACION SUPERVISORES

Fuente:  /var/www/html/horario_salida/app/Http/Controllers/RecursosController.php

1) Nombre del reporte

  • Nombre: Reporte Programación Supervisores

  • Código / Alias: report_programacion_supervisores

  • Responsable:  Equipo de Reportes Cloud

  • Propósito (1 línea):


2) Alcance temporal

  • Campo(s) de fecha utilizados:

    • fecha_inicio

    • fecha_fin

  • Tipo de rango (diario / mensual / personalizado): Mensual

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

  • Zona horaria: La del servidor


3) Origen de datos (tablas/APIs)

  • Conexión / Base: RECURSOS HUMANOS

  • Tabla / Recurso: tabProgramacion de Supervisores

  • Alias (si aplica): No aplica

  • Campos utilizados (clave → descripción):

    • name → Identificador del registro

    • nombre_supervisor →Nombre del Supervisor

    • sucursal → Nombre de la Terminal/Sucursal

    • fecha_programada → Fecha programada

    • supervisor → Codigó de empleado

    • aprobación_del_informe → Estado de Aprobación

    • prog_supervisores → Tipo de Programación

    • fecha_1era_reprogramacion → Fecha 1era Reprogramación

    • fecha_real_de_la_supervicion →  Fecha Real de la Supervisión

    • zonaa_nacional → Registro/tipo de Zona nacional

    • creation → Fecha de creación del registro

    • owner → Usuario que creó el registro

    • tipo_de_emergencia → Tipo Emergenci(select)

    • fecha → Fecha Programada

    • subir_archivo →Informe final(Archivo adjunto)

    • id_sucursal →  IDe de Terminal/Sucursal

    • adjuntar_foto → Foto Adjunta

    • adjuntar_foto_banner → Adjuntar una foto

  • Condiciones (WHERE) aplicadas: Filtra en un rango definido por parámetros externos ($fecha_inicio y $fecha_fin)

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

  • Observaciones (ej. particiones, índices): No aplica



4) Filtros globales del reporte

  • Inclusiones (must-have): 

    • Depende de lo que reciba dateUnlimited y el rango de fecha (first_day y last_day)

  • Exclusiones (reglas de descarte): No aplica

  • Reglas por estado / habilitado: No aplica

  • Parámetros externos (si el usuario puede filtrarlo): Sí, el usuario puede incluir la fecha inicio y fecha fin en el rango de búsqueda.


5) Transformaciones y Reglas de negocio

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

  • Mapeos de estado: No aplica

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


  • Reglas condicionales (si X entonces Y):

    • Si $dateUnlimited == "TODOS" → recorrer todos los años desde 2021.

    • Si $dateUnlimited == "12" → generar rangos mes a mes desde la fecha pivote 2023-09-01.

    • Si $dateUnlimited == "8" → tomar últimos 8 meses.

    • Si no se cumple ninguno → tomar mes actual y posiblemente diciembre del año anterior.


6) Estructura de salida

  • Tabla/archivo destino: report_programacion_supervisores

  • Particionado / sufijo: no aplica

  • Clave(s) primaria(s) o únicas: no aplica

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

    • id → INT AUTO_INCREMENT PRIMARY KEY → id de la fila  

    • identificador → VARCHAR(50) NULL → identificador único  

    • nombre_supervisor → VARCHAR(255) NULL → nombre del supervisor  

    • sucursal → VARCHAR(100) NULL → sucursal asignada  

    • fecha_programada → VARCHAR(100) NULL → fecha programada  

    • supervisor → VARCHAR(255) NULL → supervisor asignado  

    • aprobacion_del_informe → VARCHAR(255) NULL → aprobación del informe  

    • tipo_de_programacion → VARCHAR(255) NULL → tipo de programación  

    • fecha_1era_reprogramacion → VARCHAR(100) NULL → fecha de la primera reprogramación  

    • fecha_real_de_la_supervicion → VARCHAR(100) NULL → fecha real de la supervisión  

    • zona_nacional → VARCHAR(100) NULL → zona nacional  

    • creado_el → VARCHAR(100) NULL → fecha de creación  

    • creado_por → VARCHAR(100) NULL → usuario que creó el registro  

    • tipo_de_emergencia → VARCHAR(255) NULL → tipo de emergencia  

    • fecha → VARCHAR(100) NULL → fecha general  

    • informe_final → VARCHAR(255) NULL → informe final  

    • id_sucursal → VARCHAR(50) NULL → identificador de la sucursal  

    • adjuntar_foto → VARCHAR(255) NULL → archivo de foto adjunto  

    • adjuntar_foto_banner → VARCHAR(255) NULL → archivo de foto banner adjunto  

    • created_date → DATETIME DEFAULT CURRENT_TIMESTAMP → fecha y hora de creación  

    • status → tinyint(4) DEFAULT '1' → estado del registro  


  • Ordenamiento por defecto: No aplica ORDER BY


7) Frecuencia y operación

  • Frecuencia de actualización: Al ejecutarse la función updateProgSupervisores()

  • Ventana que recalcula (días/meses):

    • Depende de dateUnlimited:

      • "TODOS" → recalcula desde 2021 hasta la fecha actual.

      • "12" → recalcula desde un pivote (2023-09-01) mes por mes hasta hoy.

      • "8" → últimos 8 meses.

      • Vacío o default → solo el mes actual (con excepción de enero/febrero que arrastra diciembre del año anterior).


  • Tamaño de lote / paginado (chunking): 

    • Se usa array_chunk($result, 900) → divide la data en lotes de 900 registros antes de insertarlos en BD.

  • Tolerancia a fallos / reintentos: Se manejan excepciones con try/catch y \PDOException

  • Tiempos de ejecución esperados: No se especifica


8) Calidad y controles

  • Validaciones previas/post:

    • Previas:

      • Se valida si la tabla existe antes de insertar ($verify = $this->verifyExistTable(...)).

      • Si no existe, se inserta un registro en error_reports y se hace continue → es una validación previa para garantizar que la tabla destino esté lista.

      • Se maneja el caso especial de enero/febrero para incluir datos del año anterior → valida consistencia temporal.


  • Post: 

    • Tras cada inserción en lote (insert($arr)), se hace commit() de la transacción.

    • Si hay error (catch (\PDOException $e)), se hace rollBack() y se registra el fallo en emp_reportes_validation.


  • Controles de duplicados:

    • En la lógica de creación de tablas particionadas (CREATE TABLE {$db_name}), que evita que se inserten datos de un rango en la misma tabla dos veces.

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

    • Se insertan logs en emp_reportes_validation con campos:

      • report → nombre del reporte.

      • first_date, second_date → ventana procesada.

      • created_date → cuándo se ejecutó.

      • status → 1 (éxito) o 0 (error).


9) Dependencias externas

ERPNext – Programación de Supervisores

  • APIs / servicios y endpoints: method/send-query-database

  • Autenticación / headers: 

    • Se envían headers básicos: 

      • $options = [

      •    'headers' => [

      •        "Accept" => "application/json",

      •        "Content-Type" => "application/json"

      •    ]

      • ];


  • No aparece un Authorization: Bearer <token> ni otra forma de autenticación explícita.

  • Mapeos y contratos de datos: 

    • name as identificador,

    • nombre_supervisor,

    • sucursal,

    • fecha_programada,

    • supervisor,

    • aprobación_del_informe as aprobacion_del_informe,

    • prog_supervisores as tipo_de_programacion,

    • fecha_1era_reprogramacion,

    • fecha_real_de_la_supervicion,

    • zonaa_nacional as zona_nacional,

    • creation as creado_el,

    • owner as creado_por,

    • tipo_de_emergencia,

    • fecha,

    • subir_archivo as informe_final,

    • id_sucursal,

    • adjuntar_foto,

    • adjuntar_foto_banner


10) Historial de cambios

2025-09-19 18:00 - Elian Franco Arroyo Rodas - Documentación inicial



No hay comentarios para mostrar

Volver arriba