REPORTE FACTURA DE COMPRA

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

1) Nombre del reporte

• Nombre: Reporte Factura de Compra

• Código / Alias: report_factura_de_compra

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• first_date → Fecha inicio

• second_date → Fecha Fin

• created_date → Fecha de creacion

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

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

• Tabla / Recurso: tabPurchase Invoice

• Alias (si aplica): mr

• Campos utilizados (clave → descripción):

• id → Identificador

• name →Identificador de registro

• docstatus → Estado del registro

• supplier → Nombre del proveedor

• company→ Compañía

• fecha → Fecha de registro/creacion

• caja_chica →Monto Caja chica

• grand_total → Monto total

• currency → Moneda

• estado_general → Estado general

• fecha → Fecha 

• created_date → Fecha de creacion

• status → stado técnico (1 activo)

 

• Condiciones (WHERE) aplicadas: El filtro pide todos los registros de la tabla mr que estén entre las fechas $inicio y $fin, y además que estén confirmados (docstatus = 1)

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

• Observaciones (ej. particiones, índices): Hay un particionado temporal: los ranges calculados con first_day y last_day. Se usa para cortar la data por meses.

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): Si, 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_factura_de_compra

• Particionado / sufijo: no aplica

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

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

• id → INT AUTO_INCREMENT → Identificador único

• name → VARCHAR(50) → Nombre/ID de la factura

• docstatus → VARCHAR(2) → Estado documental (0,1,2)

• supplier → VARCHAR(255) → Proveedor

• company → VARCHAR(255) → Empresa asociada

• fecha → VARCHAR(20) → Fecha de emisión

• caja_chica → VARCHAR(20) → Relación con caja chica

• grand_total → VARCHAR(20) → Importe total

• estado → VARCHAR(100) → Estado de negocio (ej. aprobado)

• currency → VARCHAR(100) → Moneda

• created_date → DATETIME DEFAULT CURRENT_TIMESTAMP → Fecha de creación del registro

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

• Ordenamiento por defecto: No ampl ORDER BY

7) Frecuencia y operación

• Frecuencia de actualización: Al ejecutarse la funcion updateFacturaCompra()

• 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

CDT ERPNext – Factura de Compra

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

•  "sql_query" => "name,

•     docstatus,

•     supplier,

•     company,

•     posting_date as 'fecha',

•     caja_chica,

•     base_total as 'grand_total',

•     estado_del_documento as 'estado',

•     currency",

10) Historial de cambios

2025-09-19 13:08 - Elian Franco Arroyo Rodas - Documentación inicial