REPORTE VIATICOS SUPERVISORES

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

1) Nombre del reporte

• Nombre: Reporte Viaticos Supervisores

• Código / Alias: report_viaticos_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: tabViaticos a Supervisores

• Alias (si aplica): vsp

• Campos utilizados (clave → descripción):

• vsp.name → Identificador del registro 

• vsp.estado_del_documento → Estado del Viatico

• vsp.nombre_completo → Nombre completo Empleado

• vsp.monto_general → Monto General / Monto Total

• vsp.monto_restante → Monto Restante

• vsp.estado_del_documento → Estado del documento

• vspm.motivo → Motivo Viatico

• vspm.numero → Numero Comprobante

• vspm.tipo_de_documento → Tipo Documento

• vspm.monto → Monto del Registro Comprobante

• vspm.serie → Numero serie Comprobante

• vspm.fecha_de_emisión → Fecha Emision Comprobante

• vspm.archivo → Archivo Adjunto / Foto del comprobante

• vspm.supervision → Identificador del registro de Supervisor

• vsp.creation → Fecha de creación del registro
  
  

• 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): Sin obs

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_viaticos_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

• identificador → VARCHAR → 50 NULL

• estado → VARCHAR → 100 NULL

• nombre_completo → VARCHAR → 255 NULL

• monto_general → INT → NULL

• monto_restante → INT → NULL

• estado_del_documento → VARCHAR → 100 NULL

• motivo → VARCHAR → 255 NULL

• numero → VARCHAR → 100 NULL

• tipo_de_documento → VARCHAR → 100 NULL

• monto → INT → NULL

• serie → VARCHAR → 100 NULL

• fecha_de_emision → VARCHAR → 255 NULL

• archivo → VARCHAR → 255 NULL

• supervision → VARCHAR → 500 NULL

• creation → VARCHAR → 100 NULL

• created_date → DATETIME → DEFAULT CURRENT_TIMESTAMP

• status → TINYINT → 4 DEFAULT 1

• 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 – CAPACITACION

• 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 → identificador

• aprobación_del_informe → aprobacion_del_informe

• prog_supervisores → tipo_de_programacion

• zonaa_nacional → zona_nacional

• creation → creado_el

• owner → creado_por

10) Historial de cambios

2025-09-20 13:00 - Elian Franco Arroyo Rodas - Documentación inicial