Ir al contenido principal

REPORTE OT MECANICO

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

1) Nombre del reporte

  • Nombre:  Reporte OT Mecanico

  • Código / Alias:  report_ot_mecanico

  • Responsable:  Equipo de Reportes Cloud

  • Propósito (1 línea):


2) Alcance temporal

  • Campo(s) de fecha utilizados:

    • fecha_trabajo_termino 

    • first_day 

    • last_day 

    • fecha

  • Tipo de rango (diario / mensual / personalizado):  Mensual dinámico (últimos 2 meses, con extensión al año anterior si aplica enero o febrero)

  • 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):

    • ser.nombre_de_servicio → Nombre del servicio ejecutado por el mecánico

    • ser.precio → Precio unitario o costo asociado al servicio

    • ser.parent → Identificador que relaciona el servicio con su orden de trabajo

  • Condiciones (WHERE) aplicadas: Se filtran los registros cuya fecha de término de trabajo (ord.fecha_trabajo_termino) se encuentre entre la fecha de inicio (fecha_ini) y la fecha de fin (fecha_fin) recibidas como parámetros del servicio. Es decir, solo se traen órdenes de trabajo ejecutadas dentro del rango de fechas especificado.

  • Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN con la tabla tabOrden de Trabajo 2 usando la llave ser.parent = ord.name, que permite obtener la información de la orden asociada a cada servicio.

  • Observaciones (ej. particiones, índices): Sin observaciones relevantes. No se definen índices explícitos en la consulta.



3.2 Conexión / Base: CDTALLERES

  • Tabla / Recurso: tabOrden de Trabajo 2

  • Alias (si aplica): ord

  • Campos utilizados (clave → descripción):

    • ord.name → Identificador único de la orden de trabajo

    • ord.lugar → Ubicación o taller donde se ejecutó la orden

    • ord.dias_de_atraso → Número de días de retraso en la entrega del trabajo

    • ord.estado_ot → Estado actual de la orden (Aprobado, En taller, etc.)

    • ord.fecha_trabajo_termino → Fecha de culminación del trabajo


  • Condiciones (WHERE) aplicadas: Se consideran únicamente las órdenes cuya fecha de término (fecha_trabajo_termino) esté dentro del rango de fechas definido por las variables fecha_ini y fecha_fin.

  • Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN con tabList Servicios a través de ser.parent = ord.name. Esto permite combinar información de los servicios asociados con los datos generales de cada orden.

  • Observaciones (ej. particiones, índices): Sin observaciones. Las tablas son de tipo ERPNext (tab*) y se utilizan como fuentes directas del módulo de talleres.


4) Filtros globales del reporte

  • Inclusiones (must-have): 

    • Registros dentro del rango de fechas dinámico calculado.

    • Estados Aprobado y EN TALLER se consideran pendientes.

  • Exclusiones (reglas de descarte): Días de atraso vacíos o nulos ("", null, "Al dia") no se cuentan como atraso. 

  • Reglas por estado / habilitado:  Se registra con status = 1 si el proceso fue exitoso; status = 0 si falló.

  • Parámetros externos (si el usuario puede filtrarlo): fecha_inicio, fecha_fin (definidos por cada rango mensual)


5) Transformaciones y Reglas de negocio

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

    • universo = conteo total de órdenes por servicio.

    • pendiente = conteo de órdenes con estado Aprobado o EN TALLER.

    • atraso = conteo de órdenes con días de atraso válidos.

    • monto = suma de precios por servicio.

  • Mapeos de estado:

    • "Aprobado", "EN TALLER" → Pendiente

    • "Al día", "", null → No atraso

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

    • Se valida que las tablas destino existan; si no, se crean.

    • Si falla la creación de tabla, se registra en error_reports.

  • Reglas condicionales (si X entonces Y):

    • Si la tabla mensual existe → inserta datos.

    • Si ocurre error → rollback y registro de error.


6) Estructura de salida

  • Tabla/archivo destino: report_ot_mecanico_YYYY_MM

  • Particionado / sufijo: 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 autoincremental  

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

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

    • pendiente → VARCHAR(10) → Cantidad de pendientes  

    • atraso → VARCHAR(10) → Cantidad de atrasos registrados  

    • monto → VARCHAR(10) → Valor monetario asociado  

    • lugar → VARCHAR(100) → Taller o ubicación correspondiente  

    • fecha → DATE → Fecha del registro  

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

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


  • Ordenamiento por defecto: Por created_date DESC


7) Frecuencia y operación

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

  • Ventana que recalcula (días/meses): 2 meses (o 3 si incluye diciembre del año anterior)

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

  • Tolerancia a fallos / reintentos: Rollback automático y registro en tabla de errores

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


8) Calidad y controles

  • Validaciones previas/post: 

    • Validación de existencia de tabla destino

    • Validación de creación y alteración de índices


  • Controles de duplicados: Revisión de existencia de tabla (evita reinsertar datos previos)

  • Métricas de completitud (qué se monitorea): Inserciones exitosas vs errores registrados en emp_reportes_validation


9) Dependencias externas

  • APIs / servicios y endpoints:

    • https://recursoshumanos.shalom.com.pe/service-ordenWork3/<first_date>/<second_date>

    • APICDTALLERES . "method/send-query-database" (ERPNext remoto).


  • Autenticación / headers: 

    • Accept: application/json

    • Content-Type: application/json


  • Mapeos y contratos de datos:

    • Entrada: JSON con filtros { fecha_ini, fecha_fin }.

    • Salida: arreglo JSON con campos de orden/servicio.


10) Historial de cambios

2025-10-18 12:23 - Elian Franco Arroyo Rodas - Documentación inicial



No hay comentarios para mostrar

Volver arriba