REPORTE SHALOM PRO

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

1) Nombre del reporte

Nombre: Reporte Shalom Pro
Código/Alias: report_shalom_pro
Responsable: Equipo de Reportes Cloud
Propósito:

2) Alcance temporal

Campo(s) de fecha utilizados:

first_date
second_date
created_date

Tipo de rango (diario / mensual / personalizado): No especifica, posiblemente se ejecute en un CRON
Inclusión de horas (sí/no). Si sí: first_date y second_date [00:00:00 – 23:59:59]
Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: Plataforma Pro

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

email → Correo/email
verification_cell → Numero celular
status → Estado
person_id → Identificador de Persona
id → Identificado

Condiciones (WHERE) aplicadas:

Filtra los registros que tengan fecha de creación del 1ro de Enero del año actual en adelante.

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones (ej. particiones, índices): El ordenamiento que tiene es Por ID de mayor a menor (Ubica al comienzo de la lista los últimos registros.)

3.2 Conexión / Base: Plataforma Pro

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

document → Documento de Identidad
name → Nombre
last_name → Apellido Paterno
sur_name → Apellido Materno
id → Identificador de registro

Condiciones (WHERE) aplicadas:

Filtra Por ID en lotes de 2000 registro de la tabla person

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones (ej. particiones, índices): Sin obs

3.3 Conexión / Base: Empresarial (Centos - Srv. Notificaciones)

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

correo → Correo/email vinculado/registrado en usuario pro

Condiciones (WHERE) aplicadas:

Filtra Por correo en lotes de 2000 registro de la tabla users (usuarios pro)
Filtra los registros que tengan estado SMS == 2

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones (ej. particiones, índices): Sin obs

3.4 Conexión / Base: Plataforma Pro

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

email → email del usuario de shalom Pro

Condiciones (WHERE) aplicadas:

Filtra Por email en lotes de 2000 registro de la tabla users (usuarios pro)

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones (ej. particiones, índices): Sin obs

3.5 Conexión / Base: Plataforma Pro

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

user_id → Identificador de usuario
type_product → Tipo de Producto

Condiciones (WHERE) aplicadas:

Filtra los ID de usuarios en lotes de 2000
Si el campo send_shalom de la tabla os es igual a 1 / True
Si el campo document_converted_service_order de la tabla os es igual a 1 / True
Si el campo check_send_package de la tabla os es igual a 1 / True
Si el campo status de la tabla os es igual a 1 / True

Tipo de unión con otras fuentes (JOIN y llave): Une los registros de las tablas service_order y detail_service si coinciden en ID (os.id = det.service_order_id )
Observaciones (ej. particiones, índices): Ordenamiento de Forma descendente. Los nuevos registros se ubicaran en la parte de arriba y los antiguos al final.

3.6 Conexión / Base: Plataforma Pro

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

user → Identificador de usuario

Condiciones (WHERE) aplicadas:

Filtra los ID de usuarios en lotes de 2000
Solo filtrara los registros con campos “confirm” = 1

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones (ej. particiones, índices): Sin Obs

3.7 Conexión / Base: Plataforma Pro

Tabla / Recurso: error_reports emp_reportes_validation
Alias (si aplica): no aplica
Campos utilizados (clave → descripción):

first_date → Primera fecha
second_date → Segunda Fecha
created_date → Fecha de creacion
status → Estado

Condiciones (WHERE) aplicadas: No aplica.

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones (ej. particiones, índices): Sin Obs

4) Filtros globales del reporte

Inclusiones (must-have):

Usuarios creados a partir del primer día del año en curso
Filtros relacionados con los datos de la tabla service_order

Exclusiones (reglas de descarte):

Usuarios sin ID en la tabla person
Correos vacíos ó 0

Reglas por estado / habilitado:

status == 0 del usuario marca al registro como eliminado:
Validación de verification_cell para considerar al usuario como pro (usuario_pro = 1).

Parámetros externos (si el usuario puede filtrarlo): No hay parámetros externos

5) Transformaciones y Reglas de negocio

Derivaciones de campos (cómo se calculan): Se crean campos a partir de otros datos antes de insertarlos en la tabla:

"usuario" = $mail (clave del arreglo original).
"usuario_pro" = $pro_data["usuario_pro"] (derivado de validación verification_cell).
"eliminado" se define según $val->status.
"created_date" se fuerza al valor actual con date('Y-m-d H:i:s').
"status" = 1 (fijo en la carga inicial).

Mapeos de estado:

status == 0 → eliminado = 1.
verification_cell == true → usuario_pro = 1.
Otros flags (agregar_contacto, actualizacion_telefono, restablecer_contrasenia, etc.) se marcan con 0/1 dependiendo de condiciones previas.

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

Si no existe person_id, se hace continue.
Si el email está vacío o es "0", también se descarta (continue).
Se usa confirm = 1 para aceptar cambios de contacto válidos.

Reglas condicionales (si X entonces Y):

if($val->status==0) → eliminado = 1.
if(!$persons->person_id) → continuar (no se procesa registro).
if($format_email=="" || $format_email=="0") → continuar.
if($verify["new"]) → se agrega índice created_date.
if($verify["status"]) → insertar datos, else → registrar error.

6) Estructura de salida

Tabla/archivo destino: report_shalom_pro
Particionado / sufijo: No aplica
Clave(s) primaria(s) o únicas: ID
Columnas del reporte (nombre → tipo → descripción):

id → INT → Identificador único, autoincremental.
usuario → VARCHAR(100)→Correo electrónico del usuario.
usuario_pro → VARCHAR(2) → Indicador de celular validado (0 / 1).
nro_documento → VARCHAR(15) → Número de documento del usuario.
agregar_contacto → VARCHAR(5) → Indicador de confirmación de contacto (0 / 1).
actualizacion_telefono → VARCHAR(5)→ Indicador de actualización de número telefónico.
eliminado→VARCHAR(2)→Estado de usuario eliminado (0 / 1).
restablecer_contrasenia→VARCHAR(3)→Indicador de restablecimiento de contraseña.
sobre→VARCHAR(5)→Indicador de envío tipo "Sobre".
paquete_xxs→VARCHAR(5)→Indicador de envío de paquete XXS.
paquete_xs→VARCHAR(5)→Indicador de envío de paquete XS.
paquete_s→VARCHAR(5)→ Indicador de envío de paquete S.
paquete_m→VARCHAR(5)→Indicador de envío de paquete M.
paquete_l→VARCHAR(5)→Indicador de envío de paquete L.
otro→VARCHAR(5)→Indicador de otro tipo de envío.
created_date→DATETIME→Fecha y hora de ejecución/carga.
status TINYINT(4)→Estado de validez de la carga (1 activo / 0 error).

Ordenamiento por defecto: ORDER BY created_date DESC (Registros más recientes se listan primeros)

7) Frecuencia y operación

Frecuencia de actualización: No espesifica (Se puede que se ejecutar en un CRON)
Ventana que recalcula (días/meses): Personalizado (Recalcula tomando en cuenta la fecha del 1ero de Enero del año actual hasta la fecha actual)
Tamaño de lote / paginado (chunking):

Personas (person_id) → procesadas en bloques de 2000 IDs (array_chunk($json_person_id, 2000)).
Emails de usuarios → bloques de 2000 correos.
Detalles insertados en tabla final → bloques de 900 registros (array_chunk($detail, 900)).

Tolerancia a fallos / reintentos: Aplica try catch. Si encuentra un error devuelve un log a la tabla mp_reportes_validation con status = 0
Tiempos de ejecución esperados: Depende de la cantidad de usuarios.

8) Calidad y controles

Validaciones previas/post:

Válida si la tabla destino existe, si no existe la crea.
$verify = $this->verifyExistTable($db_name, $sql);
Post–ejecución, se inserta un log en la tabla emp_reportes_validation con status=1 (éxito) o status=0 (fallo), incluyendo fecha/hora.

Controles de duplicados: El proceso recalcula siempre desde el 1° de enero y reinserta los datos en la tabla report_shalom_pro
Métricas de completitud (qué se monitorea):

Se guarda en emp_reportes_validation:

Nombre del reporte (report_shalom_pro),
Fecha de inicio y fin del recalculo (first_date, second_date),
Fecha/hora de ejecución (created_date),
Estado final (status).

9) Dependencias externas

APIs / servicios y endpoints: No consume apis externas. Viene de BDs internas:

dbpronew
detail_service
centos
reports

Autenticación / headers: No aplica
Mapeos y contratos de datos:

El código establece un contrato interno:

Cada correo electrónico (usuario) es la clave lógica.
Los campos procesados deben cumplir el contrato de salida de la tabla report_shalom_pro:

usuario (email del user)
usuario_pro (0/1 → validado por verificación de celular)
nro_documento (documento desde tabla person)
agregar_contacto (conteo en contact_change)
actualizacion_telefono (conteo en emp_service_empresarial_notification)
eliminado (1 si status=0 en users)
restablecer_contrasenia (conteo en password_reset_history)
sobre, paquete_xxs, paquete_xs, paquete_s, paquete_m, paquete_l, otro (conteos por tipo de producto en detail_service)
created_date (fecha de inserción)
status (1 fijo).

10) Historial de cambios

2025-09-17 12:00 - Elian Franco Arroyo Roda - Documentación inicial