REPORTE CAMBIO DE CLAVE

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

1) Nombre del reporte

Nombre: Reporte Cambio de Clave
Código / Alias: update_clave
Responsable: Equipo de Reportes Cloud
Propósito (1 línea):

2) Alcance temporal

Campo(s) de fecha utilizados: cc.fecha_crea
Tipo de rango (diario / mensual / personalizado): mensual (primer día y último día del mes)
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)

3.1 Conexión / Base: EMPRESARIAL

Tabla / Recurso: emp_informacion_cambio_clave
Alias (si aplica): cc
Campos utilizados (clave → descripción):

cc_id → Identificador del cambio de clave
cc_tipo_documento → Tipo de documento
cc_guia → Guía de proceso
cc_codigo → Código de cambio de clave
cc_aprobacion → Estado de aprobación
cc_motivo → Motivo del cambio de clave
cc_ose_id → Identificador de la orden de servicio relacionada
cc_estado → Estado del cambio de clave
cc_fecha_reevalua → Fecha de re-evaluación
fecha_crea → Fecha de creación
cc_user_actualiza → Usuario que actualiza
usr_alias → Alias del usuario (COALESCE con "SIN ATENDER")
cc_user_reevalua → Usuario que reevalúa
cc_medio_utilizado → Medio utilizado
us.cc_id (de tabla emp_user_gets_code) → Relación con código de usuario
cc_reenvio → Reenvío del cambio de clave

Condiciones (WHERE) aplicadas:

cc.cc_motivo NOT IN ('Motivo de la Gestión', 'Olvido de clave de seguridad')
cc.fecha_crea BETWEEN $first_date AND $second_date

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

LEFT JOIN emp_usuario as usr → usr.usr_id = cc.cc_user_actualiza
LEFT JOIN emp_user_gets_code as us → cc.cc_id = us.cc_id

Observaciones (ej. particiones, índices): Usa COALESCE para alias de usuario.

3.2 Conexión / Base: EMPRESARIAL

Tabla / Recurso: emp_ordenservicio
Alias (si aplica): No aplica
Campos utilizados (clave → descripción):

ose_id → Identificador de la orden de servicio

Condiciones (WHERE) aplicadas:

ose_id IN (lista de ose_id obtenidos en la primera consulta)
ose_estado = 1
eliminado = 0
ose_estadoPago != 'AN'
ose_remitecontactofono = 'REGISTRA'
ose_tipoanulado = ''

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones: Valida solo órdenes activas, no anuladas.

3.3 Conexión / Base: CENTOS

Tabla / Recurso: emp_messages_code_attempts
Alias (si aplica): No aplica
Campos utilizados (clave → descripción):

ose_id → Identificador de orden de servicio
usuario → Usuario que intentó reenvío de código

Condiciones (WHERE) aplicadas:

ose_id IN (lista de ose_id obtenidos en la primera consulta)
status = 1
usuario NOT NULL

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones: Se registran intentos de reenvío de SMS de código.

3.4 Conexión / Base: ERP REPORTS

Tabla / Recurso: report_cambio_clave_<anio_mes>
Alias (si aplica): No aplica
Campos utilizados (clave → descripción):

id → Identificador del registro
periodo → Periodo de reporte (año-mes)
motivo → Motivo del cambio de clave
usuario → Usuario vinculado al cambio de clave

Condiciones (WHERE) aplicadas: Ninguna explícita (solo SELECT)
Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones: Tabla dinámica que se genera por periodo (YYYY_MM).

4) Filtros globales del reporte

Inclusiones (must-have): Registros con cc.fecha_crea dentro del rango mensual, ose_id válido y status=1 en reenvío.
Exclusiones (reglas de descarte): Motivos Motivo de la Gestión, Olvido de clave de seguridad.
Reglas por estado / habilitado: ose_estado=1, eliminado=0.
Parámetros externos (si el usuario puede filtrarlo): hasta_anio, $hasta_mes.

5) Transformaciones y Reglas de negocio

Derivaciones de campos (cómo se calculan):

Agrupación por periodo (Y-m de fecha_crea).
Conteo cantidad_cambio_clave_envia si el ose_id se encuentra en emp_ordenservicio.

Mapeos de estado: COALESCE(usr_alias, "SIN ATENDER") para usuario.
Reglas de validación (p.ej., sólo registros validados): Sólo considera usuario no nulo en reenvío SMS.
Reglas condicionales (si X entonces Y): Si cc_ose_id está en lista enviada, se incrementa el contador.

6) Estructura de salida

Tabla/archivo destino: report_cambio_clave_{anio}_{mes} (dinámica).
Particionado / sufijo: Mensual (anio_mes).
Clave(s) primaria(s) o únicas: periodo + motivo + usuario
Columnas del reporte (nombre → tipo → descripción):

periodo → string (ej. "2025-09")
motivo → string (motivo de la gestión)
usuario → string (alias de usuario)
cantidad_cambio_clave_envia → int (conteo)

Ordenamiento por defecto: No definido en código.

7) Frecuencia y operación

Frecuencia de actualización: Mensual (parámetros de entrada)
Ventana que recalcula (días/meses): Todo el mes (first day → last day).
Tamaño de lote / paginado (chunking): No aplica (usa get()->toArray()).
Tolerancia a fallos / reintentos: No aplica
Tiempos de ejecución esperados: PENDIENTE (Esperando info de Eduardo)

8) Calidad y controles

Validaciones previas/post: Verifica existencia de registros en tabla destino antes de actualizar.
Controles de duplicados: Evita duplicar reenvíos agrupando por ose_id + usuario.
Métricas de completitud (qué se monitorea): Conteo de cantidad_cambio_clave_envia

9) Dependencias externas

APIs / servicios y endpoints: No aplica (todo SQL interno).
Autenticación / headers: Credenciales internas de conexión DB.
Mapeos y contratos de datos: Dinámica de tablas mensuales en reports.

10) Historial de cambios

2025-09-30 11:32 - Elian Franco Arroyo Rodas - Documentación inicial

2025-10-15 10:32 - Elian Franco Arroyo Rodas - Documentación inicial