REPORTE SHIPPING AMOUNT PART TREE

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

1) Nombre del reporte

• Nombre: Reporte Shipping Amount PartThee

• Código / Alias: 

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecharegistro, 

• first_date, 

• second_date, 

• created_date, 

• fecha

• Tipo de rango (diario / mensual / personalizado): Mensual (por iteración de mes dentro del año 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: Empresarial

• Tabla / Recurso: emp_reclamo

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• fecharegistro → Fecha de registro del reclamo.

• Sucursal → Identificador o nombre de la sucursal donde se generó el reclamo.

• estado_eliminacion → Indicador del estado lógico del reclamo (0 = activo).

• Condiciones (WHERE) aplicadas:

• estado_eliminacion = '0'

• fecharegistro >= first_date

• fecharegistro <= second_date

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

• Observaciones (ej. particiones, índices): 

• Filtrado por rango de fechas (mensual).

• No se evidencian índices adicionales definidos desde código.

3.2 Conexión / Base: Empresarial

• Tabla / Recurso: emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador único del terminal.

• ter_nombre → Nombre del terminal.

• ter_habilitado → Indicador de habilitación (1 = activo).

• Condiciones (WHERE) aplicadas:

• No hay condiciones directas (SELECT general para todos los terminales).

• Posteriormente, en código, se filtran los terminales con ter_habilitado != '1'.

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

• Observaciones (ej. particiones, índices): 

• Sin índices explícitos.

• Los resultados se usan para generar estructuras en memoria ($grpTerminales).

4) Filtros globales del reporte

• Inclusiones (must-have):

• Terminales con ter_habilitado = 1

• Reclamos con estado_eliminacion = 0

• Exclusiones (reglas de descarte):

• Sucursales con valor "0"

• Terminales no mapeados o sin coincidencia

• Reglas por estado / habilitado: Solo terminales habilitados participan en el cálculo. 

• Parámetros externos (si el usuario puede filtrarlo): No hay parámetros manuales (todo automático por fecha).

5) Transformaciones y Reglas de negocio

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

• fechareg → se transforma a primer día del mes (Y-m-01)

• eficiencia_marcacion → 1 - (pendiente / universo) (valor redondeado a 2 decimales)

• cantidad_total_reclamos → contador acumulativo por terminal y mes

• Mapeos de estado: status = 1 éxito, status = 0 error
  
  

• Reglas de validación (p.ej., sólo registros validados): Si el año ≤ 2023 y mes ≤ 9 → usar conexiones _old
  
  

• Reglas condicionales (si X entonces Y):

• Si no existe tabla destino → crearla

• Si existe → truncarla antes de insertar

• Si no se puede crear tabla → registrar error en error_reports

6) Estructura de salida

• Tabla/archivo destino: report_shipping_amount_part_three_YYYY_MM

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

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

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

• id → INT → Identificador único del registro  

• fecha → DATE → Fecha base del reporte  

• terminal_id → VARCHAR(20) → Identificador del terminal  

• terminal_nombre → VARCHAR(100) → Nombre descriptivo del terminal  

• cantidad_total_reclamos → VARCHAR(10) → Total de reclamos registrados  

• eficiencia_marcacion → VARCHAR(10) → Porcentaje de eficiencia calculada  

• created_date → DATETIME → Fecha de generación del registro  

• status → TINYINT(4) → Estado del registro (1 = OK, 0 = Error)

• Ordenamiento por defecto: no aplica

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses):  3 meses previos (rango calculado dinámicamente)

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

• Tolerancia a fallos / reintentos:

• Try/catch por bloque mensual

• Registro en emp_reportes_validation o error_reports

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

8) Calidad y controles

• Validaciones previas/post:

• Verificación de existencia de tabla (verifyExistTable)

• Creación automática si no existe
  
  

• Controles de duplicados: Truncamiento previo antes de insertar nuevos datos

• Métricas de completitud (qué se monitorea): 

• Inserción total exitosa

• Registro de estado (status = 1/0)

9) Dependencias externas

• APIs / servicios y endpoints: APICAPACITACION (servicio de asistencia / ERPNext HR)

• Autenticación / headers: No explícitos (uso directo de guzzle->request)

• Mapeos y contratos de datos: Se espera respuesta JSON con campo message → array de estaciones (pendiente, universo)

10) Historial de cambios

2025-10-01 17:59 - Elian Franco Arroyo Rodas - Documentación inicial

2025-10-15 16:05 - Elian Franco Arroyo Rodas - Documentación