REPORTE CAMBIO DE NOMBRE

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

1) Nombre del reporte

Nombre: Reporte Cambio de Precio
Código/Alias: report_cambio_precio
Responsable: Equipo de Reportes Cloud
Propósito:

2) Alcance temporal

Campo(s) de fecha utilizados (base):

first_date
second_date
created_date

Tipo de rango: Personalizado (entre firstDate -> Primer día del mes y secondDate -> último día del mes)
Inclusión de horas (sí/no). Si sí:

first_date [00:00:00]
second_date [ 23:59:59]

Zona horaria: Servidor (igual a sistema)

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: Empresarial

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

ose_estadoPago → Estado de pago de la guia
ose_id → ID de la GUIA
ose_fechaanulado → Fecha de anulacion
ose_fhpreferenciapartida → Fecha y hora de partida
ose_serieguiacliente → Serie Cliente
ose_nroguiacliente → Numero guia
ose_termorigenatencion → Terminal Origen
ose_termdestinoentrega → Terminal Destino
ose_remiteempresa → Nombre del remitente
ose_destinaempresa → Nombre Destinatario
'0' → Contenido total
'' → Contenido
'0' → Peso
'0' → volumen
ose_servpagotipo → Forma de pago
ose_montototal → Monto
ose_precio_cambioprecio → Cambio de precio
diferencia → Es el resultado de la resta entre ose_montototal y ose_precio_cambioprecio
ose_tipoCP → Tipo comprobante
ose_serieguiacliente → Serie de la guia
ose_nroCP → Numero comprobante
ose_entregadopersonadni → Codigo de Entrega
ose_entregadopersonadni → Mensaje de codigo de Entrega
ose_entregadofecha a→ Fecha de entrega
ose_destina_direccion_entrega → Estado guia (Entregado en Agencia)
ose_movilidad_reparto → Indica si tiene reparto o no
ose_guia_remitente → null
ose_user_cambioprecio → Usuario que realizó el cambio de precio
ose_user_cambioprecio → Terminal del usuario que cambió precio
ose_fecha_cambioprecio → Fecha del cambio de precio
ose_fecha_cambioprecio → Hora del cambio de precio
ose_observacion_cambioprecio → Observacion del cambio de precio
usercreaid →Usuario que digite o creo la guia
proforma_user → valor: NULL / No asignado
ose_remitecontactofono → Contacto con cliente

Condiciones (WHERE) aplicadas:

ose_estado = 1
eliminado = 0
ose_estadoPago != 'DA'
ose_estado_solicitudprecio = 1
ose_fecha_cambioprecio → Primer y ultimo dia del mes (first_date, second_date)

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Observaciones (ej. particiones, índices): No hay particiones o indices especificados

3.2 Conexión / Base: empresarial

Tabla / Recurso: emp_producto
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas: No aplica
Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

pro_producto → tipo de producto
pro_id → ID del producto

Observaciones: Trae solo tipo del producto y su ID

3.3 Conexión / Base: empresarial

Tabla / Recurso: emp_atributos
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas:

atr_idpadre = 90

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

atr_nombre → Nombre del atributo
atr_valor → Valor del atributo

Observaciones: Trae solo tipo El nombre del atributo su valor

3.4 Conexión / Base: empresarial

Tabla / Recurso: emp_usuario
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas:

whereIn('usr_id', $strvalusr)

Se tiene un chunk que procesa los datos en cantidades de 1000
Solo trae a los usuarios en el cual su ID coincida dentro del grupo de 1000

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

usr_id → ID de usuario
usr_alias → Nombre del usurio
usr_terminalid → Terminal del usuario

Observaciones: Trae solo solo los usuario que coincidan dentro del chunk o grupo de 1000

3.5 Conexión / Base: empresarial

Tabla / Recurso: emp_os_detalle
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas:

osd_eliminado = 0

trae solo las OS que no hagay sido eliminadas

whereIn('osd_osid', $valdet)

Solo trae las osd_osid que se encuentren en el chunk de 1000

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

osd_unidad → Cantidad de paquetes
osd_osid → ID de la Guia
osd_descripcion → Descripción del producto (tipo producto)
osd_peso → Peso del producto
osd_volumen → Volumen del paquete

Observaciones:

3.6 Conexión / Base: empresarial

Tabla / Recurso: emp_persona
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas:

whereIn('per_nrodocumento', $strvalper)

Solo trae las per_nrodocumento que se encuentren en el chunk de 1000

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

per_nombrerzsoc → Nombre
per_apellidopaterno → Apellido paterno
per_apellidomaterno → Apellido materno
per_nrodocumento → Documento de indentidad

Observaciones:

3.7 Conexión / Base: empresarial

Tabla / Recurso: emp_cambio_precio
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas:

estado = 1
whereIn('ose_id', $valdet)

Solo trae los registros que tengan el mismo ose_id que se encuentren en el chunk de 1000

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

urlimagen → Imagen cambio de precio
ose_id → ID registro cambio de precio

Observaciones:

3.8 Conexión / Base: empresarial

Tabla / Recurso: emp_incidencias
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas:

inc_tipo = EDITAR PRECIO
whereIn('inc_idos', $valinc)

Solo trae los registros que tengan el inc_idos que se encuentren en el chunk de 1000

Tambien hay una funcion anonima dentro de un where que filtra los registros que tengan el campo “eliminado” con valor null ó 0

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

inc_idos → ID de la Guia con incidencia
inc_tipo → Tipo de incidencia

Observaciones:

3.9 Conexión / Base: empresarial

Tabla / Recurso: emp_soporte
Alias (si aplica): No aplica
Condiciones (WHERE) aplicadas:

where("sop_tipo", '=', 'editar_volumen_pro')
whereIn('sop_oseid', $valinc)

Solo trae los registros que tengan el la misma Orden de servicio(sop_oseid) que se encuentren en el chunk de 1000

Tipo de unión con otras fuentes (JOIN y llave): No aplica
Campos utilizados (clave → descripción):

sop_anterior → Tipo de Pago anterior al cambio
sop_oseid → Orden de servicvio

Observaciones:

4) Filtros globales del reporte

Inclusiones (must-have):

->where("ose_estado", "=", 1) → Solo órdenes activas.
->where("ose_estado_solicitudprecio", "=", 1) → Solo órdenes con solicitud de precio habilitada.
->whereBetween("ose_fecha_cambioprecio", [$first_date, $second_date]) → Solo registros dentro del rango de fechas.

Exclusiones (reglas de descarte):

->where("eliminado", "=", 0) → descarta eliminados.
->where("ose_estadoPago", "!=", 'DA') → descarta órdenes con estado de pago “DA”.

Reglas por estado / habilitado:

El reporte solo toma órdenes vigentes/habilitadas (ose_estado = 1).
El cambio de precio debe estar activo (estado = '1' en emp_cambio_precio).
Reglas para plataformas (ejemplo: "REGISTRA" → "ENVIA YA")

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

Rango de fecha → $first_date y $second_date

5) Transformaciones y Reglas de negocio

Derivaciones de campos (cómo se calculan):

diferencia: Deriva de la resta entre los campos ose_montototal - ose_precio_cambioprecio
DATE_FORMAT(ose_fecha_cambioprecio, '%Y-%m-%d') as fhcambioprecio → transforma la fecha a formato YYYY-MM-DD
DATE_FORMAT(ose_fecha_cambioprecio,'%H:%i:%s') as hrcambioprecio → extrae solo la hora.
'0' as contenidototal, '0' as peso, '0' as volumen → inicializa siempre con 0.
'' as contenido → siempre vacío.

Mapeos de estado:

ose_estado = 1 → mapea que solo se consideren órdenes activas.
ose_estadoPago != 'DA' → descarta un estado de pago específico (probablemente "Desaprobado" o similar).
ose_estado_solicitudprecio = 1 → asegura que esté aprobado para cambios de precio.
En otras partes (como incidencias), se aplica estado = '1' que mapea a "activo/habilitado".

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

eliminado = 0 o whereNull/eliminado → garantiza que no entren registros eliminados.
Validación de rango de fechas con whereBetween("ose_fecha_cambioprecio", [$first_date, $second_date]) → asegura que solo se tomen registros dentro del periodo válido para el reporte.
En caso de error (catch), igual se inserta un log en emp_reportes_validation con status = 0.

Reglas condicionales (si X entonces Y): Si el mes actual es enero o febrero → se amplía el rango incluyendo diciembre del año anterior

6) Estructura de salida

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

report→VARCHAR → Nombre del reporte generado
first_date→DATE→Fecha de inicio del rango de consulta
second_date→DATE→Fecha de fin del rango de consulta
created_date→DATETIME→Fecha y hora en que se generó el log de validación
status→INT / TINYINT→Estado de la ejecución (1 = OK, 0 = error)

Ordenamiento por defecto: No aplica orderBy

7) Frecuencia y operación

Frecuencia de actualización: Posible frecuencia: ejecución programada por CRON (cada día/mes)
Ventana que recalcula (días/meses): Si es Enero o Febrero toma ambos meses. Pero a partir de Marzo comienza a tomar desde dos meses atrás.

Tamaño de lote / paginado (chunking): array_chunk(..., 1000) → paginado por 1000 registros para las tablas:

emp_usuario
emp_persona

Tolerancia a fallos / reintentos:

try/ catch
Si la consulta falla, igual inserta un registro en emp_reportes_validation con status = 0

Tiempos de ejecución esperados: No especifica

8) Calidad y controles

Validaciones previas/post: Antes de insertar en la tabla emp_reportes_validation se valida que los datos de las tablas, pasen retornen true:

emp_ordenservicio
emp_producto
emp_atributos
emp_usuario
emp_os_detalle
emp_persona
emp_cambio_precio
emp_incidencias
emp_soporte

Controles de duplicados: No aplica
Métricas de completitud (qué se monitorea):

Se monitorea si el proceso realmente generó información (count($response_service) > 0).
También se marca con status = 1 o status = 0 según éxito o fallo, lo que sirve como métrica de calidad de ejecución.
Se guarda el rango de fechas (first_date, second_date) como evidencia del periodo cubierto.

9) Dependencias externas

APIs / servicios y endpoints: No consume API externamente. EL reporte depende de una función interna llamada reportCambioPrecio($first_date, $second_date) que tiene los parámetros de fecha.
Autenticación / headers: No aplica
Mapeos y contratos de datos:

"report" → Identificador del reporte
"first_date" → Fecha inicial del rango procesado
"second_date" → Fecha final del rango procesado
"created_date"→ date("Y-m-d H:i:s"),// Fecha/hora de la ejecución
"status" => 1 | 0 → Estado del proceso (1=ok, 0=falla)

10) Historial de cambios

2025-09-15 16:42 - Elian Franco Arroyo Roda - Documentación inicial