# 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