REPORTE LICENCIA CERTIFICADOS

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

1) Nombre del reporte

• Nombre: Report licencias certificados
  
  

• Código/Alias: report_licencias_certificados
  
  

• Responsable: Equipo de Reportes Cloud
  
  

• Propósito: Ejecutar la actualización del reporte de licencias y certificados, registrando en la tabla emp_reportes_validation el estado (éxito o error) de la ejecución.

2) Alcance temporal

• Campo(s) de fecha utilizados (base): 

• "first_date" → date("Y-m-d")

• "second_date" → date("Y-m-d")

• "created_date" → date("Y-m-d H:i:s")
  
  

• Tipo de rango: Diarioo ( firstDate y secondDate se generan con la fecha actual ("Y-m-d"))
  
  

• Inclusión de horas (sí/no):

• "created_date" sí incluye horas → formato Y-m-d H:i:s. (00:00:00 – 23:59:59)

Zona horaria: Servidor (igual a sistema)

3) Origen de datos (tablas/APIs)

3.1 Cargueros programados

• Conexión/Base: empresarial
  
  

• Tabla: emp_reportes_validation
  
  

• Campos utilizados (clave → descripción):

• "report" → nombre o alias del reporte ejecutado.

• "first_date" → fecha de inicio (en este caso, fecha actual).

• "second_date" → fecha de fin (misma fecha actual).

• "created_date" → fecha y hora exacta de la ejecución.

• "status" → estado de la ejecución (1 = éxito, 0 = error)
  
  

• Condiciones (WHERE) aplicadas:

• Ninguna, solo se realiza un insert directo en la tabla.
  
  

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

• No hay uniones (JOIN) en este bloque.

4) Filtros globales del reporte

• Inclusiones (must-have):

• No hay filtros de inclusión aplicados en este bloque.

• El único “must-have” implícito es que siempre se inserta un registro en emp_reportes_validation al ejecutar el método.
  
  

• Exclusiones (reglas de descarte): No existen reglas de exclusión en el código (ningún WHERE ni condición de descarte sobre datos externos).
  
  

• Reglas habilitado/estado:
  
  

• Se maneja el campo "status":

• 1 → ejecución correcta del reporte.

• 0 → ejecución fallida (capturada en el catch).
  
  

• No hay validación de “habilitado” en la tabla ni en el código.
  
  

• Parámetros externos (si el usuario puede filtrar): 

• No hay parámetros externos.
  
  

• Fechas (first_date y second_date) se fijan automáticamente al día actual, sin posibilidad de modificar por entrada externa.

5) Transformaciones y Reglas de negocio

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

• "first_date" y "second_date" → se derivan de la fecha actual con date("Y-m-d").
  
  

• "created_date" → se deriva del momento exacto de ejecución con date("Y-m-d H:i:s").
  
  

• "status" → se asigna en función del resultado de la ejecución:

• 1 si no hay excepción.

• 0 si se captura una excepción.
  
  

• Mapeos de estado:

• status = 1 → reporte generado / ejecución exitosa.

• status = 0 → error durante la ejecución (capturado en el catch)
  
  

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

• No existen validaciones explícitas sobre los datos antes de insertarlos en la tabla.
  
  

• Se asume que los valores generados son siempre válidos porque provienen del sistema (date() y constantes).

• Reglas condicionales (si X entonces Y):

• Si el bloque try se ejecuta sin errores, entonces se inserta un registro con status = 1.
  
  

• Si ocurre una excepción (catch), entonces se inserta un registro con status = 0.
  
  

• Si $response_service contiene al menos un elemento, el método retorna "status" => true, de lo contrario "status" => false.

6) Estructura de salida

• Tabla/archivo destino: emp_reportes_validation (tabla de reportes)
  
  

• Particionado / sufijo: No hay, todo se inserta directamente en emp_reportes_validation
  
  

• Clave(s) primaria(s) o únicas: No se especifica, pero se asume que la tabla tiene un campo autoincremental (ej. id) como clave primaria.
  
  

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

• report → string → alias/nombre del reporte (report_licencias_certificados).
  
  

• first_date → date → fecha de inicio (en este caso, fecha actual).
  
  

• second_date → date → fecha de fin (igual a la fecha actual).
  
  

• created_date → datetime → momento exacto de la ejecución.
  
  

• status → int → estado de la ejecución (1 = éxito, 0 = error).

• Ordenamiento por defecto: no aplica para este reporte.

7) Frecuencia y operación

• Frecuencia de actualización:  No está definida en el código. Se puede ejecutar en un cron.
  
  

• Ventana que recalcula (días/meses): Se ejecuta diariamente.
  
  

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

• No hay procesamiento en lotes ni paginado.
  
  

• Sólo registra un único resultado en emp_reportes_validation por ejecución.
  
  

• Tolerancia a fallos / reintentos: Si ocurre una excepción, se captura en el catch y se inserta igualmente un registro con status = 0
  No hay Reintentos

• Tiempos de ejecución esperados: No se especifica en el código.

UTF-8: force_utf8mb4 = true.

8) Calidad y controles

• Validaciones previas/post:

• Previas: No existen validaciones antes de ejecutar reportLicenciasCertificados() ni antes de insertar en la tabla.
  
  

• Post: El único control es verificar si $response_service tiene elementos (count($response_service) > 0) para retornar status = true/false.
  
  

• Controles de duplicados: No hay controles para evitar duplicados en la tabla
  
  

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

• Solo se monitorea un campo: status (1 = ejecución exitosa, 0 = fallida).
  
  

9) Dependencias externas

• ERPNext – Licencias y Certificados
  
  

• Endpoint: method/send-query-database
  
  

• Request: 

• filters → JSON vacío ([]).

• where → "where definido_para_la_sucursal = 'SI'".

• sql_query → listado de campos (ej. name, sucursal, id_sucursal, etc.).

• tables → `tabLicencias y Certificados`.
  
  

• Contrato: retorna estado_documento, n_serie, number_factura.
  
  

• Autenticación / headers: No se maneja ningún esquema de autenticación ni headers en este código.
  
  

• Mapeos y contratos de datos:

• El “contrato de datos” que este método garantiza es la inserción en emp_reportes_validation con los campos:
  
  

• report → string (nombre del reporte).
  
  

• first_date → date.
  
  

• second_date → date.
  
  

• created_date → datetime.
  
  

• status → int (0/1).
  
  

• Este contrato sirve como registro estándar para saber si el reporte se ejecutó y con qué resultado.

10) Historial de cambios

2025-09-10 17:00 - Elian Franco Arroyo Rodas - Documentación inicia