Ir al contenido principal

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 

No hay comentarios para mostrar

Volver arriba