Ir al contenido principal

REPORTE ORDENES DE TRABAJO - SERVICIOS

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

1) Nombre del reporte

  • Nombre:  Reporte de Órdenes de Trabajo – Servicios

  • Código / Alias: updateOtServicio

  • Responsable:  Equipo de Reportes Cloud

  • Propósito (1 línea):


2) Alcance temporal

  • Campo(s) de fecha utilizados: first_day, last_day, fecha_trabajo_termino

  • Tipo de rango (diario / mensual / personalizado): Mensual (automático según el mes actual y hasta 12 meses previos)

  • Inclusión de horas (sí/no).: Si [00:00:00 – 23:59:59]

  • Zona horaria: La del servidor


3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: CDTALLERES

  • Tabla / Recurso: tabList Servicios

  • Alias (si aplica): ser

  • Campos utilizados (clave → descripción):

    • name → Identificador único del servicio registrado.

    • precio → Precio del servicio (puede ser nulo, reemplazado por 0 si no existe).

    • nombre_de_servicio → Nombre del servicio realizado.

    • mecanico → Código o identificador del mecánico asignado.

    • nombre_mecanico → Nombre del mecánico que realizó el trabajo.

    • tercero → Indicador si el servicio fue realizado por un tercero (1 = sí, 0 = no).

    • parent → Llave foránea que enlaza con la tabla tabOrden de Trabajo 2.

  • Condiciones (WHERE) aplicadas: 

    • Se filtran los registros de servicios cuyos trabajos terminados (fecha_trabajo_termino) se encuentren entre la fecha de inicio y la fecha de fin especificadas.

    • Adicionalmente, se excluyen los registros sin fecha de término (IS NOT NULL).

    • En otras palabras: Sólo se consideran los servicios con una fecha de término válida y dentro del rango de fechas solicitado.

  • Tipo de unión con otras fuentes (JOIN y llave): INNER JOIN implícito mediante una unión LEFT JOIN con la tabla tabOrden de Trabajo 2, utilizando la llave:

 

  • Observaciones (ej. particiones, índices):

    • Se agrupan los resultados posteriormente por nombre de mecánico o por tipo de servicio ("TERCEROS").

    • Se calculan indicadores de atraso, pendientes y montos.

    • No se especifican índices directos, pero en la creación dinámica de tablas (report_ot_servicio_YYYY_MM) se añaden índices a:

      • nombre_de_servicio

      • status

      • created_date


3.2 Conexión / Base: CDTALLERES

  • Tabla / Recurso: tabOrden de Trabajo 2

  • Alias (si aplica): ord

  • Campos utilizados (clave → descripción):

    • name → Identificador de la orden de trabajo.

    • lugar → Lugar o taller donde se ejecutó el trabajo.

    • dias_de_atraso → Número de días de atraso de la orden.

    • estado_ot → Estado actual de la orden (Abierto, Cerrado, etc.).

    • fecha_trabajo_termino → Fecha en que el trabajo fue finalizado.

  • Condiciones (WHERE) aplicadas: 

    • Filtra las órdenes de trabajo que:

      • Tienen una fecha de término no nula.

      • Se encuentran entre la fecha de inicio y la fecha fin indicadas (fecha_trabajo_termino >= fecha_ini y <= fecha_fin).

  • Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN con la tabla tabList Servicios mediante la llave:

    • ord.name = ser.parent.


  • Observaciones (ej. particiones, índices):

    • La información resultante se agrupa y transforma para formar el reporte report_ot_servicio_YYYY_MM.

    • Los datos consolidados se almacenan en tablas mensuales con índices sobre nombre_de_servicio, status y created_date.

    • No se aplican filtros adicionales por estado o taller.


 

4) Filtros globales del reporte

  • Inclusiones (must-have): Registros con fecha de término (fecha_trabajo_termino no nula)

  • Exclusiones (reglas de descarte): Ninguna explícita, excepto exclusión implícita por ausencia de fecha

  • Reglas por estado / habilitado: Campo status = 1 (activos)

  • Parámetros externos (si el usuario puede filtrarlo): Fechas de inicio y fin (definidas por cada iteración del rango mensual)


5) Transformaciones y Reglas de negocio

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

    • universo: contador total de registros agrupados por mecánico o tercero

    • pendiente: 1 si estado_ot ≠ ‘Cerrado’

    • atraso: 1 si dias_de_atraso no está en [‘Al día’, ‘’, null]

    • monto: suma acumulada de precio

  • Mapeos de estado:

    • estado_ot = Cerrado → pendiente = 0

    • tercero = 1 → grupo TERCEROS

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

    • Verifica existencia de tabla antes de insertar

    • Crea índices (nombre_de_servicio, status, created_date)

  • Reglas condicionales (si X entonces Y):

    • Si la tabla no existe → se crea

    • Si ya existe → se trunca y reutiliza

    • Si ocurre error → rollback y registro en error_reports


6) Estructura de salida

  • Tabla/archivo destino: report_ot_servicio_YYYY_MM

  • Particionado / sufijo: Mensual (por año y mes)

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

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

    • id → INT → Identificador único del registro  

    • nombre_de_servicio → VARCHAR(255) → Nombre del servicio o del mecánico  

    • universo → VARCHAR(10) → Total de registros agrupados  

    • pendiente → VARCHAR(10) → Indicador de registros pendientes  

    • atraso → VARCHAR(10) → Indicador de registros con atraso  

    • monto → VARCHAR(10) → Monto monetario acumulado  

    • lugar → VARCHAR(100) → Taller o sede correspondiente  

    • fecha → DATE → Fecha de referencia del registro  

    • created_date → DATETIME → Fecha de inserción en la base de datos  

    • status → TINYINT → Estado del registro (1 = activo, 0 = inactivo)


  • Ordenamiento por defecto: created_date ASC


7) Frecuencia y operación

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

  • Ventana que recalcula (días/meses): Hasta 12 meses atrás

  • Tamaño de lote / paginado (chunking): 900 registros por bloque (array_chunk)

  • Tolerancia a fallos / reintentos: Rollback y registro en tabla error_reports

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


8) Calidad y controles

  • Validaciones previas/post:

    • Verificación de tabla (verifyExistTable)

    • Inserción en emp_reportes_validation

  • Controles de duplicados: Truncado previo si la tabla ya existía

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

    • Validación de status (1 = correcto, 0 = error)

    • Log de errores en error_reports


9) Dependencias externas

  • APIs / servicios y endpoints:

    • https://recursoshumanos.shalom.com.pe/service-ordenWork2/{inicio}/{fin}

    • APICDTALLERES/method/send-query-database

  • Autenticación / headers:

    • {

    •   "Accept": "application/json",

    •   "Content-Type": "application/json"

    • }


  • Mapeos y contratos de datos:

    • Formato JSON → decode → inserción directa en tabla

    • Campos estandarizados entre service-ordenWork2 y service_ordenWork3


10) Historial de cambios

2025-10-21 11:37 - Elian Franco Arroyo Rodas - Documentación inicial



No hay comentarios para mostrar

Volver arriba