REPORTE VULNERACIONES FINANZAS 2

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

1) Nombre del reporte

• Nombre: Reporte Vulneraciones FInanzas 2

• Código / Alias:  report_vulneraciones_finanzas2_YYYY_MM

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: fecha (varios orígenes: emp_code_attemp.fecha, emp_cambio_precio.fecha, Solicitud de Pagos.fecha)

• Tipo de rango (diario / mensual / personalizado): Mensual (por año y mes, dinámico según fecha actual).

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: CENTOS

• Tabla / Recurso: emp_code_attemp

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción): 

• ter_id → Terminal

• user_attempt → Usuario

• fecha → Fecha del intento

• id → Identificador único (usado en COUNT)
  
  

• Condiciones (WHERE) aplicadas: Rango de fechas entre fecha inicio y fecha fin.

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

• Observaciones (ej. particiones, índices): Se usa groupBy(ter_id, user_attempt, DATE(fecha)).

3.2 Conexión / Base: CAPACITACION

• Tabla / Recurso: Solicitud de Pagos (API → resource/Solicitud de Pagos)

• Alias (si aplica): sp

• Campos utilizados (clave → descripción):

• name → Identificador del registro

• id_de_sucursal → Sucursal asociada

• usuario_que_registro_el_pago → Usuario que registró el pago

• fecha → Fecha de registro

• Condiciones (WHERE) aplicadas:

• concepto = "Transacción / Compensaciones"

• fecha >= fecha_inicio

• fecha <= fecha_fin

• docstatus != 2

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (consulta directa a recurso vía API).

• Observaciones: usuario_que_registro_el_pago se limpia quitando el dominio (@xxx).

3.3 Conexión / Base: ERP EMPRESARIAL

• Tabla / Recurso: emp_cambio_precio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• usuariocambia → Usuario que realiza el cambio de precio

• fecha → Fecha del cambio

• id → Identificador único (usado en COUNT)

• Condiciones (WHERE) aplicadas: Rango de fechas entre fecha inicio y fecha fin.

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

• Observaciones: Se agrupa por usuario y fecha.

3.4 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador del terminal

• ter_nombre → Nombre del terminal

• Condiciones (WHERE) aplicadas: Ninguna.

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

• Observaciones: Sirve para enriquecer con nombre de terminal en los reportes.

3.5 Conexión / Base: CAPACITACION

• Tabla / Recurso: Branch (API → resource/Branch)

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ideentificador → ID de la sucursal

• name → Nombre de la sucursal

• agente → Indicador si es agente

• concesionario → Indicador si es concesionario

• Condiciones (WHERE) aplicadas: Ninguna (trae todos).

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

• Observaciones: Se usa para distinguir si la sucursal es agente o concesionario.

3.6 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_usuario

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• usr_terminalid → Terminal asignado al usuario

• usr_rol → Rol del usuario

• usr_id → Identificador del usuario

• usr_alias → Nombre o alias del usuario

• Condiciones (WHERE) aplicadas: usr_id IN (usuarios encontrados en las otras consultas).

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (pero conceptualmente enriquece con info de usuario).

• Observaciones: Se usa para obtener detalles adicionales del usuario que aparecen en el reporte final.

4) Filtros globales del reporte

• Inclusiones (must-have): Registros dentro de rango de fechas.

• Exclusiones (reglas de descarte): docstatus != 2 en Solicitud de Pagos.

• Reglas por estado / habilitado: Se guarda status = 1 (ok) o 0 (error).

• Parámetros externos (si el usuario puede filtrarlo): No expuestos al usuario (definidos internamente).

5) Transformaciones y Reglas de negocio

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

• usuario_que_registro_el_pago → antes del @ (si aplica).

• Mapeo de usuario ↔ terminal desde varias fuentes.

• Mapeos de estado:

• tipo = cambio_precio | compensaciones_transacciones | error_clave.

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

• Verifica existencia de tabla destino (verifyExistTable).

• Si no existe, se crea con índices (fecha, created_date, status).

• Reglas condicionales (si X entonces Y): Si usuario no está en array_usuario_agencia, se asignan valores vacíos.

6) Estructura de salida

• Tabla/archivo destino: report_vulneraciones_finanzas2_YYYY_MM

• Particionado / sufijo: Por año y mes (YYYY_MM).

• Clave(s) primaria(s) o únicas: id (autoincrement).

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

• id → INT → PK autoincrement

• fecha → DATE → fecha de registro

• terminal → VARCHAR(20) → id terminal

• terminal_nombre → VARCHAR(255) → nombre terminal

• usuario → VARCHAR(255) → id usuario

• nombre_completo → VARCHAR(255) → alias

• cargo → VARCHAR(255) → rol usuario

• tipo → VARCHAR(255) → categoría del evento

• cantidad → VARCHAR(20) → ocurrencias

• created_date → DATETIME → fecha inserción

• status → tinyint(4) → 1=activo
  
  

• Ordenamiento por defecto: No explícito (se asume fecha).

7) Frecuencia y operación

• Frecuencia de actualización: PENDIENTE (Esperando info de Eduardo)

• Ventana que recalcula (días/meses):  Últimos 2–3 meses (dependiendo del mes actual).

• Tamaño de lote / paginado (chunking):  Inserciones en lotes de 900 registros.

• Tolerancia a fallos / reintentos: No especificado, pero registra en emp_reportes_validation.

• Tiempos de ejecución esperados: PENDIENTE (Esperando info de Eduardo)

8) Calidad y controles

• Validaciones previas/post:

• Validación de existencia de tabla.

• Inserción de estado en emp_reportes_validation.
  
  

• Controles de duplicados: Truncate si la tabla existe antes de insertar.

• Métricas de completitud (qué se monitorea): cantidad por usuario/terminal/fecha.

9) Dependencias externas

• APIs / servicios y endpoints:

• Apis: 

• APICAPACITACION/resource/Solicitud de Pagos

• APICAPACITACION/resource/Branch

• Autenticación / headers: Token fijo → token fc60669957e6bdc:b207d472e96c9df

• Mapeos y contratos de datos: Respuesta esperada con campo data

10) Historial de cambios

2025-09-30 18:13 - Elian Franco Arroyo Rodas - Documentación inicial