Ir al contenido principal

REPORTE VULNERACIONES FINANZAS

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

1) Nombre del reporte

  • Nombre: Reporte Vulneraciones Finanzas

  • Código / Alias: report_vulneraciones_finanzas_YYYY_MM (Tablas dinámicas)

  • Responsable:  Equipo de Reportes Cloud

  • Propósito (1 línea):


2) Alcance temporal

  • Campo(s) de fecha utilizados: 

    • cop_fechaemision

    • cop_fhanulado 

    • re_datesys 

    • created_date 

    • list_fecha 

    • fecha_crea

    • fecha

  • Tipo de rango (diario / mensual / personalizado): Mensual (construido dinámicamente entre first_day y last_day por mes).

  • 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 (agrupada con DATE(fecha))

    • id → Identificador único del intento (para conteo COUNT)


  • Condiciones (WHERE) aplicadas: Registros cuya fecha esté entre first_date y second_date.

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

  • Observaciones (ej. particiones, índices): Usa groupBy sobre ter_id, usuario y fecha.


3.2 Conexión / Base: CAPACITACION (API)

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

  • Alias (si aplica): sp

  • Campos utilizados (clave → descripción):

    • name → Identificador de registro

    • id_de_sucursal → Sucursal asociada

    • usuario_que_registro_el_pago → Usuario que registró el pago

    • fecha → Fecha de creación del registro

  • Condiciones (WHERE) aplicadas: 

    • concepto = "Transacción / Compensaciones"

    • fecha entre first_date y second_date

    • docstatus != 2

  • Tipo de unión con otras fuentes (JOIN y llave): No aplica (se integra por lógica en código).

  • Observaciones: Se limpia el campo usuario_que_registro_el_pago para remover @dominio.


3.3 Conexión / Base: EMPRESARIAL

  • Tabla / Recurso: emp_cambio_precio

  • Alias (si aplica): No aplica

  • Campos utilizados (clave → descripción):

    • usuariocambia → Usuario que realizó el cambio

    • fecha → Fecha (agrupada con DATE(fecha))

    • id → Identificador único (para conteo COUNT)


  • Condiciones (WHERE) aplicadas: Registros cuya fecha esté entre first_date y second_date.

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

  • Observaciones: Agrupado 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 → Terminal

    • ter_nombre → Nombre de la terminal


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

  • Tipo de unión con otras fuentes (JOIN y llave): Se cruza lógicamente con Branch para asignar tipo (agente/concesionario).

  • Observaciones: Se usa como catálogo para complementar datos de sucursal.


3.5 Conexión / Base: CAPACITACION (API)


  • Tabla / Recurso: Branch (resource/Branch)

  • Alias (si aplica): No aplica

  • Campos utilizados (clave → descripción):

    • ideentificador → Identificador de sucursal

    • name → Nombre de la sucursal

    • agente → Flag si es agente

    • concesionario → Flag si es concesionario


  • Condiciones (WHERE) aplicadas: Ninguna (se trae todo).

  • Tipo de unión con otras fuentes (JOIN y llave): Relación lógica con emp_terminal.

  • Observaciones: Se arma diccionario para marcar sucursales agente/concesionario.



3.6 Conexión / Base: EMPRESARIAL

  • Tabla / Recurso: emp_usuario

  • Alias (si aplica): No aplica

  • Campos utilizados (clave → descripción):

    • usr_id → Identificador de usuario

    • usr_terminalid → Terminal asignada al usuario

    • usr_rol → Rol del usuario

    • usr_alias → Alias o nombre corto


  • Condiciones (WHERE) aplicadas: Usuarios incluidos en array_usuario_agencia.

  • Tipo de unión con otras fuentes (JOIN y llave): Se cruza por usr_id con los usuarios recogidos en otras consultas.

  • Observaciones: Completa información de detalle de usuario.


4) Filtros globales del reporte

  • Inclusiones (must-have): Registros activos, notas de crédito, anulaciones, reimpresiones, intentos válidos.

  • Exclusiones (reglas de descarte): status = 0 o eliminado = 1.

  • Reglas por estado / habilitado: Considera cop_estado = 1, cop_estado_pago = 'AN', re_status = 0.

  • Parámetros externos (si el usuario puede filtrarlo): Mes/año calculados dinámicamente.


5) Transformaciones y Reglas de negocio

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

    • Conteo de operaciones por día y terminal (COUNT).

    • Ajuste de reimpresiones (cantidad – 1).

    • Acumulación en $nc_list[fecha][terminal][tipo].

  • Mapeos de estado: Notas de crédito, reimpresiones QR, comprobantes anulados, caja eliminada, pinpad anulados, egresos anulados, intentos sesión, anulados store.

 

  • Reglas condicionales (si X entonces Y): 

    • Si la tabla no existe → CREATE TABLE.

    • Si es nueva → ALTER TABLE con índices (fecha, created_date, status).


6) Estructura de salida

  • Tabla/archivo destino: report_vulneraciones_finanzas_YYYY_MM (Tablas dinámicas)

  • Particionado / sufijo: Por mes (YYYY_MM)

  • Clave(s) primaria(s) o únicas: id autoincremental

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

    • fecha → DATE → fecha del registro o movimiento

    • terminal → VARCHAR → identificador del terminal o punto de venta

    • nota_credito → VARCHAR(20) → indicador si aplica nota de crédito

    • reimpresion_qr → VARCHAR(20) → flag de reimpresión de código QR

    • comprobantes_anulados → VARCHAR(20) → cantidad de comprobantes anulados

    • eliminacion_caja_diaria → VARCHAR(20) → marca de eliminación en cierre de caja

    • comprobantes_anulados_pinpad → VARCHAR(20) → comprobantes anulados en Pinpad

    • intentos_session → VARCHAR(20) → número de intentos de sesión fallidos o registrados

    • egresos_anulados → VARCHAR(20) → número de egresos anulados

    • anulados_store → VARCHAR(20) → anulaciones registradas en la tienda

    • created_date → DATETIME → fecha y hora de creación del registro

    • status → TINYINT → estado del registro (activo/inactivo)


  • Ordenamiento por defecto: no definido (se inserta en bulk).


7) Frecuencia y operación

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

  • Ventana que recalcula (días/meses): Últimos 2 meses + ajuste si enero/febrero.

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

  • Tolerancia a fallos / reintentos: Manejo con try/catch → inserta en emp_reportes_validation con status = 0 si falla.

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


8) Calidad y controles

  • Validaciones previas/post: 

    • Verifica existencia de tabla antes de insertar.

    • Aplica índices en creación.

  • Controles de duplicados: Evita duplicados mediante groupBy y having.

  • Métricas de completitud (qué se monitorea): Se monitorea en emp_reportes_validation.


9) Dependencias externas

  • APIs / servicios y endpoints: ERPNext (APICAPACITACION).

    • Endpoints: /resource/POS Invoice, /resource/Branch

  • Autenticación / headers: No especificada (se asume token en ServiceErp).

  • Mapeos y contratos de datos: Respuestas JSON → campos name, sucursal, ideentificador.


10) Historial de cambios

2025-09-30 17:33 - Elian Franco Arroyo Rodas - Documentación inicial



No hay comentarios para mostrar

Volver arriba