Reporteria

• REPORTE DE GASTOS
• REPORTE DE PERDIDAS
• REPORTE DE REQUERIMIENTO PERSONAL
• REPORTE BALANCE DE BANCOS
• REPORTE TERMINALES
• REPORTE LICENCIA CERTIFICADOS
• REPORTE CAMBIO DE NOMBRE
• REPORTE SHALOM PRO
• REPORTE CIRCUITO COMPRAS
• REPORTE DEMORA
• REPORTE FACTURA DE COMPRA
• REPORTE FACTURA DE VENTA
• REPORTE PROGRAMACION SUPERVISORES
• REPORTE VIATICOS SUPERVISORES
• REPORTE SOLICITUD DE MATERIALES
• REPORTE SOLICITUD DE PAGOS
• REPORTE MANTENIMIENTO TERCEROS
• REPORTE NOTA DE ENTREGA
• REPORTE DE MONITOREO
• REPORTE ESCALAS
• REPORTE REQUERIMIENTO PERSONAL LIMA
• REPORTE DOCUMENTO CHOFERES
• REPORTE VULNERACIONES FINANZAS
• REPORTE VULNERACIONES FINANZAS 2
• REPORTE INSPECCIONES
• REPORTE MATRIZ CONDICIONES
• REPORTE SHIPPING AMOUNT PART TREE
• REPORTE DESECHOS
• REPORTE CAMBIO DE CLAVE
• REPORTE DE RECLAMOS
• REPORTE FLOTA
• REPORTE DENUNCIAS
• REPORTE SHIPPING AMOUNT PARTTOW
• REPORTE MAPA DE CALOR
• REPORTE RAKKI
• REPORTE INFORMATION
• REPORTE AMOUNT PLATAFORMAS
• REPORTE ABASTECIMIENTO TIENDA
• REPORTE OT MECANICO
• REPORTE ABASTECIMIENTO
• REPORTE ORDENES DE TRABAJO - SERVICIOS
• REPORTE CENTRO COSTO AGENCIAS
• REPORTE DE COSTO STORE ESPECIFICO 2
• REPORTE CENTRO DE COSTO AEREO
• REPORTE CENTRO COSTO DHL 2
• PLANTILLA REPORTES
• REPORTE ENVIOS COMERCIAL CORPORATIVO
• REPORTE CRM PERSONA
• REPORTE CONTROL LEGAL
• REPORTE SHIPPING AMOUNT INFORMATION
• Reporte Shipping Amount Worker

REPORTE DE GASTOS

Fuente: App\Http\Controllers\Cloud\Reports\Gastos

1) Nombre del reporte

• Nombre: Reporte de Gastos por Carguero Programado
  

• Código/Alias: report_gastos
  

• Responsable: Equipo de Reportes Cloud
  

• Propósito: Consolidar gastos de ruta por carguero programado, con detalle de documentos, validación, estado de pago y datos del chofer/proveedor.
  
  

2) Alcance temporal

• Campo(s) de fecha utilizados (base): cp.cap_fhsalidaprogramada (salida programada del carguero)
  

• Tipo de rango: Personalizado (entre firstDate y secondDate)
  

• Horas: Sí, se incluye día completo por fecha (00:00:00 – 23:59:59)
  

• Zona horaria: Servidor (igual a sistema)
  
  

3) Origen de datos (tablas/APIs)

3.1 Cargueros programados

• Conexión/Base: empresarial
  

• Tabla: emp_cargprogramado (alias cp)
  

• JOIN: LEFT JOIN emp_carguero_new car ON cp.cap_cargid = car.id
  

• Campos:
  

• cp.cap_id (ID carguero programado)
  

• cp.cap_fhsalidaprogramada (fecha/hora base del rango)
  

• cp.cap_rutacarguero (ruta)
  

• cp.cap_tipo_grupo_id (FK a grupo)
  

• car.car_codigo (para “placa” mostrada junto con cap_cargueroid)
  
  

• Condiciones: cp.cap_fhsalidaprogramada BETWEEN [firstDate 00:00:00] AND [secondDate 23:59:59]
  

• Observaciones: Lista base; luego se filtra a los que tienen gastos.
  
  

3.2 Estado de ruta (km final, estado)

• Conexión/Base: choferes
  

• Tabla: emp_ruta_estado
  

• Campos: ruta_estado, kilometraje_arrive, cap_id
  

• Condiciones: ruta_habilitado = '1' y cap_id IN [caps]
  
  

3.3 Grupos de ruta

• Conexión/Base: empresarial
  

• Tabla: emp_grupo_general
  

• Campos: id, nombre
  

• Condiciones: habilitado = 1
  
  

3.4 Abastecimientos (para km final alternativo)

• Conexión/Base: choferes
  

• Tabla: emp_abastecimiento
  

• Campos: kilometraje_fin, cap_id
  

• Condiciones: habilitado = '1' y cap_id IN [caps]
  
  

3.5 Gastos de ruta (detalle principal)

• Conexión/Base: choferes
  

• Tabla: emp_ruta_gastos
  

• Campos:
  

• Chofer: gast_chofer_id AS id_chofer
  

• Documento comprobante: gast_tipo_doc AS tipo_doc, gast_serie AS serie, gast_num_doc AS num_doc
  

• ERP: gast_serie_erp, gast_numero_erp
  

• Gasto: gast_fecha AS fecha, gast_monto AS monto, gast_tipo_gasto AS tipo_gasto, gast_observ AS observacion, gast_galones AS galones, gast_ruta_comp AS foto, gast_validado, gast_id
  

• Relación: cap_id, ruc
  
  

• Condiciones: gast_habilitado = '1' y cap_id IN [caps]
  

• Orden: ORDER BY gast_fecha DESC
  
  

3.6 Motivos de rechazo (gastos no validados)

• Conexión/Base: choferes
  

• Tabla: emp_gastos_motivos
  

• Campos: gast_id, motivo
  

• Condiciones: status = 1 y gast_id IN [ids de gastos]
  
  

3.7 Personas (choferes / proveedores)

• Conexión/Base: empresarial
  

• Tabla: emp_persona
  

• Campos: per_nrodocumento, per_nombrerzsoc, per_apellidopaterno, per_apellidomaterno
  

• Condiciones: per_nrodocumento IN [dni/ruc recolectados]
  
  

3.8 Estados de pago (ERP – Solicitud de Pagos)

• Fuente externa: API ERPNext (Capacitación)
  

• Tabla remota: tabSolicitud de Pagos
  

• Endpoint: method/send-query-database
  

• Consulta: columnas name, estado_documento, number_factura, n_serie
  

• Filtros: number_factura IN %(numero)s AND n_serie IN %(serie)s
  

• Mapeo de Estados:
  

• Por Pagar → PENDIENTE
  

• Pagado → CANCELADO
  

• Pago Rechazado → RECHAZADO
  
  

4) Filtros globales del reporte

• Inclusiones: Sólo cargueros con al menos un gasto asociado.
  

• Exclusiones: Cargueros cuya “placa” (texto en cap_cargueroid) contenga "CARRE" (carretas).
  

• Reglas habilitado/estado:
  

• ruta_habilitado = '1' (estado ruta)
  

• habilitado = 1 (grupos)
  

• gast_habilitado = '1' (gastos)
  

• status = 1 (motivos)
  
  

• Parámetros externos: firstDate, secondDate.
  
  

5) Transformaciones y Reglas de negocio

• Nombre del chofer: concatena per_nombrerzsoc + apellidos por id_chofer desde emp_persona.
  

• Razón social (RUC): idem con ruc.
  

• Fecha/Hora de gasto: gast_fecha → [fecha_gasto, hora_gasto].
  

• Factura (texto): trim(gast_serie_erp + ' - ' + gast_numero_erp, ' - ').
  

• Validación: gast_validado → "SI" / "NO".
  

• Motivo de rechazo: sólo si gast_validado = false, recogido de emp_gastos_motivos.
  

• Estado de pago: por (serie, número) vía API ERP y mapeo de estados.
  

• Km final mostrado: si existe abastecimiento para el cap_id y el gasto tiene galones, dejar vacío; si no, usar kilometraje_arrive de emp_ruta_estado.
  

• Tipo de grupo: buscar nombre por cap_tipo_grupo_id.
  
  

6) Estructura de salida

• Destino: report_gastos (tabla de reportes)
  

• Particionado / sufijo: por mes ($month = Y_m).
  

• Escritura: writeReport('report_gastos', rows, true, 'fecha', $month)
  

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

• id_carguero → int → ID del carguero programado
  

• fecha → date → Fecha de cap_fhsalidaprogramada
  

• hora → time → Hora de cap_fhsalidaprogramada
  

• ruta → string → cap_rutacarguero
  

• tipo_grupo → string → Nombre del grupo (lookup)
  

• placa → string → cap_cargueroid / car_codigo
  

• doc_chofer → string → DNI del chofer (gast_chofer_id)
  

• nombre_chofer → string → Nombre completo (lookup persona)
  

• tipo_doc_comp → string → Tipo de comprobante (gast_tipo_doc)
  

• serie → string → Serie (gast_serie)
  

• numero → string → Número (gast_num_doc)
  

• tipo_gasto → string → Tipo de gasto
  

• ruc → string → RUC del proveedor
  

• razon_social → string → Nombre/razón social (lookup persona)
  

• observacion → string → Observaciones del gasto
  

• monto → decimal(12,2) → Monto del gasto
  

• fecha_gasto → date → Fecha de gast_fecha
  

• hora_gasto → time → Hora de gast_fecha
  

• galones → decimal(10,2) → Galones (si aplica)
  

• km_final → int/string → Km final (según regla de abastecimiento)
  

• validacion → enum('SI','NO') → Validado por ruta
  

• factura → string → Texto “SERIE - NÚMERO” (ERP)
  

• motivo_rechazo → string → Motivo si no validado
  

• estado → enum('PENDIENTE','CANCELADO','RECHAZADO','') → Estado ERP
  

• created_date → datetime → Timestamp de generación
  

• status → tinyint → 1 = activo
  

• Orden por defecto: fecha asc / hora asc (o el que defina el consumidor).
  
  

7) Frecuencia y operación

• Ejecución normal: método update() recorre del mes actual hacia 1 mes atrás.
  

• Frecuencia sugerida: diaria (cierre de día) y mensual (cierre de mes).
  

• Chunking:
  

• IDs (cap_id, gast_id) en bloques de 5000 (array_chunk).
  

• Personas en bloques de 200.
  
  

• Reintentos: rename_retries = 4, rename_backoff_ms = 300.
  

• UTF-8: force_utf8mb4 = true.
  

8) Calidad y controles

• Sólo registros habilitados en cada fuente.
  

• Descartar carretas ("CARRE" en placa).
  

• Evitar filas sin gastos (no se emite para cap_id sin gastos).
  

• Series y números ERP: filtrar vacíos antes de consultar estados.
  

• Consistencia nombres (upper/trim).
  
  

9) Dependencias externas

• ERPNext – Solicitud de Pagos
  

• Endpoint: method/send-query-database
  

• Request: headers con X-API-Key, body con filters, where, sql_query, tables
  

• Contrato: retorna estado_documento, n_serie, number_factura.

10) Historial de cambios

2025-09-01 13:58 - Gian Piero Villanueva Gastello - Documentación inicial

REPORTE DE PERDIDAS

Fuente: App\Http\Controllers\Cloud\Reports\Perdidas

/var/www/html/qareportes

1) Nombre del reporte

• Nombre: Reporte de Pérdidas
  
  

• Código/Alias: report_perdidas
  
  

• Responsable: Equipo de Reportes Cloud
  
  

• Propósito:
  
  

2) Alcance temporal

• Campo(s) de fecha utilizados (base): 

• os.ose_fhpreferenciapartida (Fecha de traslado)
  
  

• inc. fhcrea (Fecha creación incidencia)
  
  
  

• Tipo de rango: Personalizado (entre firstDate y secondDate)
  
  

• Horas: No, se toma en cuenta el rango de fecha.
  
  

• Zona horaria: Lima - Perú
  
  
  

3) Origen de datos (tablas/APIs)

3.1 Terminales

• Conexión/Base: empresarial
  
  

• Tabla: emp_terminal
  
  

• JOIN: LEFT JOIN emp_ordendeservicio os ON inc.inc_idos = os.ose_id
  
  

• Campos:
  
  

• ter_nombre (Nombre de la terminal)
  
  

• ter_id  (ID de la terminal)
  
  

• ter_habilitado (Estado de la terminal)
  
  
  

• Condiciones: Trae toda la información sin condición
  
  
  

3.2 Incidencias

• Conexión/Base: empresarial
  
  

• Tabla: emp_incidencias
  
  

• Campos:
  
  

• ose_fhpreferenciapartida (Fecha de traslado)
  
  

• ose_nroguiacliente (Numero de guia)
  
  

• ose_termorigenatencion (Terminal de Origen)
  
  

• ose_termdestinoentrega (terminal de Destino)
  
  

• fhcrea (Fecha Creación Incidencia)
  
  

• inc_descripcion (Descripcion/ subtipo)
  
  

• inc_tipo (Tipo de incidencia)
  
  

• inc_responsable_terminal (Terminal responsable)

• Condiciones: inc.fhcrea [first_date] BETWEEN [second_date]
  
  

 

3.2 Reclamos

• Conexión/Base: empresarial
  
  

• Tabla: emp_reclamos
  
  

• Campos:
  
  

• Campo vacío “ ”  (Fecha de traslado)
  
  

• rec_numeroguia (Numero de guia)
  
  

• Campo vacío “ ” (Origen)
  
  

• Campo vacío “ ” (Destino)
  
  

• fecharegistro (Fecha Creacion incidencia)
  
  

• PERDIDA (Subtipo)
  
  

• tipo_reclamo (Tipo)
  
  

• Sucursal (Terminal responsable)
  
  

• Condiciones: inc.fecharegistro [first_date] BETWEEN [second_date]
  
  

3.3 Orden de servicio

• Conexión/Base: empresarial
  
  

• Tabla: emp_ordenservicio
  
  

• Campos:
   

• ose_id (ID de Guia)
  
  

• ose_termorigenatencion (Terminal Origen)
  
  

• ose_termdestinoentrega (Terminal Destino)
  
  

• ose_fhpreferenciapartida (Fecha Traslado)
  
  

• ose_nroguiacliente (Numero de Guia)
  
  

• Condiciones: No se aplican condiciones
  
  

4) Filtros globales del reporte

• Inclusiones:
  
  

• Exclusiones:
  
  

• Reglas habilitado/estado:
  
  

• inc.rec_numeroguia = “ ” (Obligatorio/ NO NULL)
  
  

• inc.tipo_reclamo = “RECLAMO” (Tipo)
  
  

• Parámetros externos: firstDate, secondDate.
  
  

5) Transformaciones y Reglas de negocio

• Tablas Por meses: concatena el prefijo report_centralizacion_perdidas_ + con el formato “Y-M”
  
  

• Tipo:
  
  

• REVISAR se mostrará como INCIDENCIA

• COMPENSACIONES se mostrara como COMPENSACION
  
  

• Fechas:
  
  

• fecha_crea_incidencia → [YYYY-MM-DD]

• fecha_traslado → [YYYY-MM-DD]
  
  

• Terminal:
  
  

• ID terminal Origen → Nombre de Terminal Origen

• ID terminal Destino → Nombre de Terminal Destino
  
  

• General: 

• fecha_traslado → [YYYY-MM-DD]
  
  

• Estado: status → 1
  
  

• Crea un formato: date[YYYY-MM-DD H:I:S]

6) Estructura de salida

• Destino: report_centalizacion_perdidas  (tabla de reportes)
  
  

• Particionado / sufijo: por mes ($month = Y_m).
  
  

• Escritura: writeReport('report_centalizacion_perdidas',$detail, true, 'fecha', $partition_month)
  
  

• Columnas (nombre → tipo → descripción): No cuenTa con columnas
  
  

• Orden por defecto: 

• inc.fhcrea (fecha de creación de la incidencia)  desc

• inc.fecharegistro ( Fecha de creación de la incidencia)  desc
  
  
  

7) Frecuencia y operación

• Ejecución normal: No tiene método update()
  
  

• Chunking:
  
  

• IDs (n_ids_guias) en bloques de 2000 (array_chunk).
  
  

• 
  
  

• Reintentos: rename_retries = 4, rename_backoff_ms = 300.
  
  

• UTF-8: force_utf8mb4 = true.

8) Calidad y controles

Controles, filtros o condiciones establecidas

• Sólo incluye incidencias o reclamos según fecha filtrada 

• Fecha de creación y fecha de registro [$first_date, $second_date]
  
  

• No considera en el reporte registros eliminados

• Solo se considera los registros con una orden de servicio vinculado

• Solo se consideran incidencias tipo ["REVISAR","COMPENSACIONES"]

• Solo consideran reclamos con tipo de reclamos ["RECLAMO”]

• Se considera las incidencias con tipo de descripción: 

•     "ROBO: MERCADERIA ROBADA POR INTERNO",

•     "MERCADERIA EXTRAVIADA.",

•     "MERCADERIA EXTRAVIADA",

•     "FALTANTE INTERNO",

•     "1.4 M. FALTANTE: FALTANTE INTERNO",

•     "1. M. FALTANTE: AUN NO SE SABE DONDE ESTA."

9) Dependencias externas

• No consume información externa

10) Historial de cambios

2025-09-02 13:06 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE DE REQUERIMIENTO PERSONAL

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

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

1) Nombre del reporte

• Nombre: Reporte Requerimiento Personal
  
  

• Código/Alias: report_requerimientos_personal_
  
  

• Responsable: Equipo de Reportes Cloud
  
  

• Propósito:
  
  

2) Alcance temporal

• Campo(s) de fecha utilizados (base): 

• fecha_creacion
  
  

• fecha_atencion
  
  

• fecha_de_cierre_de_vacante
  
  

• fecha_de_proceso
  
  

• tiempo_de_cobertura
  
  

• fecha_de_cubierto
  
  
  

• Tipo de rango:  firstDate [YYYY-MM]
  
  

• Horas: No, se toma en cuenta el rango de fecha.
  
  

• Zona horaria: Lima - Perú
  
  

3) Origen de datos (tablas/APIs)

• Tablero: report_requerimientos_personal_YYYY_MM

• Alias: 

• "fecha_creacion" => fechaPart[0]

• "fecha_atencion" => fechaProcesoSolo

• Campos utilizados (clave → descripción):
  
  

• name → Identificador del requerimiento.
  
  

• creation → Se transforma en fecha_creacion (solo la fecha, sin hora).
  
  

• agencia → Agencia solicitante.
  
  

• data_3 → Número de vacantes (n_vacantes).
  
  

• tipo_de_reclutamiento → Tipo de reclutamiento.
  
  

• estado_rp → Estado del requerimiento.
  
  

• prioridad → Prioridad.
  
  

• cv_aceptados → CV aceptados (vacío si NULL).
  
  

• fecha_historial_atencion → Usado como fallback para fecha_atencion si no existe en $fechaProcesoData.
  
  

• cv_filtrado → CV filtrados (vacío si NULL).
  
  

• posicion_solicitada → Posición solicitada.
  
  

• vacantes_cubiertas → Vacantes cubiertas.
  
  

• fecha_de_cierre_de_vacante → Fecha de cierre.
  
  

• sexo → Sexo solicitado.
  
  

• turno → Turno solicitado.
  
  

• compromiso_cobertura → Compromiso de cobertura.
  
  

• tiempo_de_cobertura → Tiempo de cobertura.
  
  

• fecha_de_cubierto → Fecha en que se cubrió la vacante.
  
  

• _assign → JSON con asignados → convertido a string separado por comas.
  
  

• branch_id → ID de sucursal.

 

4) Filtros globales del reporte

• Inclusiones: Solo filtra o trae información de los 4 últimos meses. Lo mismo aplica para la api de Recursos humanos
  
  

• Exclusiones: Ningún registro se descarta según estado, valores de campos o validación.

• Estado: “estatus” → se asigna 1 por defecto a todos los registros

• Parámetros externos: El único parámetro externo es el rango de fechas (dateCreationIni, dateCreationFin) que el usuario o quien llame la función puede definir.
  
  
  

5) Transformaciones y Reglas de negocio

• Campos:
  
  

• fecha_creacion: Extrae la fecha [YYYY-MM-DD]
  
  

• fecha_de_proceso Extrae la fecha [YYYY-MM-DD]
  
  

• fecha_atencion: Extrae la fecha [YYYY-MM-DD]
  
  

• asignado_a: De un JSON a String
  
  

• cv_filtrados: Si es Null se pasa a un string vacío
  
  

• cv_aceptados: Si es Null se pasa a un string vacío
  
  

• Estado: status: 1 → Activo por defecto
  
  

• Validación: 

• cv_aceptados  (El contenido del campo no debe ser igual a null)

• cv_filtrados  (El contenido del campo no debe ser igual a null)

6) Estructura de salida

• Destino: report_requerimientos_personal_YYYY_MM
  
  

• Particionado / sufijo: Cada mes (date = Y_m).
  
  

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

• id →primary key → Auto incrementa
  
  

• name → string → Nombre
  
  

• fecha_creacion → date → fecha
  
  

• agencia  → string → Nombre
  
  

• n_vacantes → string → Cantidad
  
  

• tipo_reclutamiento → string → puede ser Null

• estado → string → Nombre del estado
  
  

• prioridad → string → Null
  
  

• cv_aceptados → string → Null
  
  

• fecha_atencion → date → Null
  
  

• cv_filtrados → string → Null
  
  

• posicion_solicitado →string → Null
  
  

• vacantes_cubiertas →string → Null
  
  

• fecha_de_cierre_de vacantes → string → Null
  
  

• fecha_de_proceso →string → Null
  
  

• sexo →string → Null
  
  

• turno →string → Null
  
  

• compromiso_de_cobertura →string → Null
  
  

• tiempo_de_cobertura →string → Null
  
  

• fecha_de_cubierto →string → Null
  
  

• asignado_a →string → Null
  
  

• id_sucursal →string → Null
  
  

• created_date →dateTime→ Null
  
  

• status → tintin(4) → default 1
  
  

• Observación: hay campos con nombre fecha qué son tipos string 

• Condiciones: Trae toda la información sin condición
  
  

7) Frecuencia y operación

• Ventada que recalcula(Días/meses): El rango se controla con los parámetros externos que se ingresen.
  
  

• UTF-8: force_utf8mb4 = true.
  
  

8) Calidad y controles

• Validaciones previas/post: 

• Se validan indirectamente fechas ingresadas en los parámetros.

• Post: Se valida la respuesta de la API
  
  

• Controles de duplicado: No se encontró.

• Sobrescribe sobre la última información.
  
  

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

• Existen pequeños controles que detectan los null y los transforman en strings vacíos

9) Dependencias externas

• API: Descarga datos de la API  de Recursos Humanos “api/report-requerimiento-personal-lima” en un rango del primer y último día.
  
  

• Endpoint: APICAPCITACION method/send-query-database
  
  

• Contrato: Retorna (name, agencia, tipo_reclutamiento, estado_erp, fecha_creacion)

10) Historial de cambios

2025-09-02 19:15 - Elian Franco Arroyo Rodas - Documentación inicial

 

REPORTE BALANCE DE BANCOS

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

1) Nombre del reporte

• Nombre: Reporte de Balance de Bancos
  
  

• Código/Alias: report_bank_balance
  
  

• Responsable: Equipo de Reportes Cloud
  
  

• Propósito: 

2) Alcance temporal

• Campo(s) de fecha utilizados (base): 

• created_date  (Fecha y hora de la creación del reporte)
  
  

• Tipo de rango: Mensual

• Si es Enero y Febrero abarca esos dos meses

• Si es el mes actual es otro abarca 2 meses posteriores y el actual (3 meses)
  
  

• Horas: Sí, se abarca un rango completo por día [00:00:00 – 23:59:59]
  
  

• Zona horaria: Servidor (igual a sistema)

3) Origen de datos (tablas/APIs)

• Conexión / Base: Empresarial
  
  

• Tabla/Recurso: emp_reportes_validation
  
  

• Alias: No hay
  
  

• Campos utilizados (clave → descripción):

• report ( nombre del reporte report_bank_balance)

• created_date (Fecha y hora en que se inserta el registro)

• status (Estado de ejecución: [1 = éxitoso, 0 = error ])
  
  

• Condiciones (WHERE) aplicadas: No aplica, solo utiliza un realiza un insert con los campos report, create d_date y status en la tabla emp_reportes_validation
  
  

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

4) Filtros globales del reporte

• Inclusiones: Solo inserta datos en la tabla emp_reportes_validation

• report (“report_bank_balance”)

• created_date (Fecha y hora de la ejecución)

• status (1 = si el proceso fue éxitoso y 0 = error/falló )
  
  

• Exclusiones: No hay regla que excluya registros para este reporte
  
  

• Reglas habilitado/estado:

• status = 1 → Ejecución correcta del bankBalance()

• status = 0 → Ejecución capturada en el catch
  
  

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

5) Transformaciones y Reglas de negocio

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

• created_date: Fecha y hora de ejecución [YYYY-MM-DD H: i: s]
  
  

• first_month: Toma de $last_month y la regla que resta 2 meses para establecer el rango del reporte
  
  

• last_month: Mes [date(“m”)]
  
  

• year: año [date(“Y”)]
  
  

• Mapeos de estado:

• status 1 =  éxitoso

• status 0 =  fallo
  
  

• Reglas de validación (p.ej., sólo registros validados): Solo existe la validacion al llamar la funcion bankBalance() regresando como respuesta el status = 1 ó 0
  
  

• Reglas condicionales (si X entonces Y): La única condicional se la del status

 

6) Estructura de salida

• Tabla/archivo destino: emp_reportes_validatio ()

• Particionado / sufijo: No tiene
  
  

• Clave(s) primaria(s) o únicas: No cuentan con PK o FK
  
  

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

• report → Nombre fijo del reporte (report_bank_balance)

• created_date → Fecha y hora de ejecucion

• status → Estado de ejecución
  
  

• Ordenamiento por defecto: No aplica

7) Frecuencia y operación

• Ejecución normal: Método update() recorre 2 meses posteriores más el mes actual (3 meses)
  
  

• Ventana que recalcula (días/meses): Si el mes es Enero o Febrero solo calcula la información para esos meses. Si es otro mes calcula 3 meses tomando el mes actual (3 meses)
  
  

• Chunking: En bloques de 9000 registros antes de insertar (array_chunk).
  
  

• Tolerancia a fallos / reintentos: 

• Maneja try–catch con rollback

• Si falla la creación o inserción se guarda en error_reports
  
  

• Tiempos de ejecución esperados: No hay
  
  

• UTF-8: force_utf8mb4 = true.
  
  

8) Calidad y controles

• Validaciones previas/post: 

• Verificación de existencia de la tabla antes de insertar(Si no existe la crea): $verify = $this->verifyExistTable($db_name, $sql);

• Controles de duplicados: 

• No hay controles duplicados

• Observación: Si se ejecuta por segunda vez el reporte con el mismo rango de fecha, no sobre escribe, elimina la data anterior o actualiza. Crea un duplicado de los registros que se apila a los registros de la primera ejecución.

• Métricas de completitud (qué se monitorea): Se monitorea solo el estado del reporte

• status = 1 → reporte creado correctamente.

• status = 0 → error en ejecución.
  
  
  

9) Dependencias externas

• ERPNext – Bancos
  
  

• Endpoint: method/send-query-database

• Contrato: retorna valor(status), response.

10) Historial de cambios

2025-09-03 12:00 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE TERMINALES

Fuente:/var/www/html/emprsarial-sys/app/Models/Reportes/Reports.php

1) Nombre del reporte

• Nombre: Reporte Terminales
  
  

• Código/Alias: report_terminals
  
  

• Responsable: Equipo de Reportes Cloud
  
  

• Propósito: 

2) Alcance temporal

• Campo(s) de fecha utilizados:

• "fecha" => date("Y-m-d") (fecha del día de ejecución).

• "created_date" => date("Y-m-d H:i:s") (fecha y hora exacta de ejecución).

• "fecha_creacion" => $valor->fhcrea desde la BD.
  
  

• Tipo de rango (diario / mensual / personalizado): Diario
  
  

• Inclusión de horas (sí/no). 

• "created_date" [00:00:00 – 23:59:59]
  
  

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: empresarial

• Tabla: emp_terminal
  
  

• Alias: ter
  
  

• Campos utilizados (clave → descripción):   

• Todos los campos de la tabla emp_terminal (emp_terminal *)
  
  

• Condiciones (WHERE) aplicadas:  (Terminales habilitadas que no estén eliminadas)

• ter_habilitado = 1  (Filtra terminales habilitadas)

• eliminado = 0     (Filtra terminales que no estén eliminadas)
  
  
  

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

• LEFT JOIN emp_liqui_cons con ON con.ter_id = ter.ter_id

• LEFT JOIN emp_persona per ON per.per_nrodocumento = con.emp_nro_ruc

• Observaciones (ej. particiones, índices):    De la tabla principal emp_terminal trae todas los campos con la condición de que la terminal esté habilitada poro no haya sido eliminada.

3.2 Conexión / Base: empresarial 

• Tabla / Recurso: emp_liqui_cons

• Alias (si aplica): con

• Campos utilizados (clave → descripción):

• emp_nro_ruc (numero RUC)

• correo (dirección de correo)

• comision (monto de comision)

• pinpad_pre (Precio PINPAD)

• pinpad_cant (cantidad de PINPADS)

• igv (IGV)

• Condiciones (WHERE) aplicadas: 

• con.ter_id = ter.ter_id
  
  

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

• LEFT JOIN emp_liqui_cons con ON con.ter_id = ter.ter_id

• Observaciones (ej. particiones, índices): 

• Si la tabla emp_liqui_cons no encuentra un el valor del campo ter_id el los valores que se setearan en el campo seran iguales a NULL

3.3 Conexión / Base: empresarial

• Tabla / Recurso: emp_persona

• Alias (si aplica): per

• Campos utilizados (clave → descripción):

• per_nombrerzsoc (Nombre  RUC)

• Condiciones (WHERE) aplicadas:

• per.per_nrodocumento = con.emp_nro_ruc

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

• LEFT JOIN emp_persona per on(per.per_nrodocumento = con.emp_nro_ruc)

• Observaciones (ej. particiones, índices):

• Si la tabla emp_persona no encuentra un el valor del campo ter_id el los valores que se setearan en el campo seran iguales a NULL

3.4 Conexión / Base: empresarial

• Tabla / Recurso: emp_ciudad_ubigeo

• Alias (si aplica): No se asigna un alias a la tabla

• Campos utilizados (clave → descripción):

• ubi_id (ID)

• ubi_departamento (Departamento)

• ubi_provincia (Provincia)

• ubi_distrito (Distrito)

• Condiciones (WHERE) aplicadas: No aplica condiciones 

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

• Observaciones (ej. particiones, índices): Ninguna

3.5 Conexión / Base: ERP

• Tabla / Recurso: tabTabla de Sucursales

• Alias (si aplica): tbs

• Campos utilizados (clave → descripción):

• id (ID)

• parent ()

• Condiciones (WHERE) aplicadas:  No aplica condiciones

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

• LEFT JOIN `tabZonas Nacional` tbz on (tbz.name = tbs.parent)

• Observaciones (ej. particiones, índices): Ninguna

 

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Todos los registros de la tabla emp_terminal

• Exclusiones (reglas de descarte): 

• Terminales deshabilitadas

• Terminales eliminadas

• Terminales sin supervisor asignado

• Reglas por estado / habilitado:

• ter.ter_habilitado = 1 (solo terminales habilitados.)

• ter.eliminado = 0 (excluye eliminados.)

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

5) Transformaciones y Reglas de negocio

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

• tipo  -> 1/0 Transforma a “AGENTE” / “AGENCIA”

• conexion -> 1/0 Transforma a “SI” / “NO”

• habilitado_os -> 1/0 Transforma a “SI” / “NO”

• habilitado -> 1/0 Transforma a “SI” / “NO”

• reparto -> 1/0 Transforma a “SI” / “NO”

• departamento -> busca en ubigeosJSON el ubig_id y lo deriva en string

• provincia -> busca en ubigeosJSON el ubig_id y lo deriva en string

• distrito ->  busca en ubigeosJSON el ubig_id y lo deriva en string

• razon_social -> se transforman a null en si no hay void

• ruc -> se transforman a null en si no hay void

• correo -> se transforman a null en si no hay void

• Mapeos de estado:

• habilitado → 1 = "SI", 0 = "NO"

• habilitado_os → 1 = "SI", 0 = "NO"

• reparto → igual. → 1 = "SI", 0 = "NO"

• tipo_destino → 1 = "SI", 0 = "NO"
  
  

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

• where ter.ter_habilitado=1 and ter.eliminado=0 → Solo terminales activos.

• WHERE ter.ter_supervisor IS NOT NULL → Solo terminales con supervisor asignado.
  
  

• Reglas condicionales (si X entonces Y):

• Si ter_estado_agente == 1 → tipo = AGENTE.

• Si ter_tipo_local == Concesionario → tipo = CONCESIONARIO, sino AGENCIA.

• Si ter_tipo_conexion == 1 → "SI", sino "NO".

• Si existe clave en $supervisores_json o $sups_group → asigna supervisor, sino "".

6) Estructura de salida

• Tabla/archivo destino: report_terminals

• Particionado / sufijo: No se incluye 

• Clave(s) primaria(s) o únicas: No se especifica

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

• fecha  →  DATE  → Fecha de ejecución/corte del reporte.

• terminal_id → INT → Identificador único del terminal.

• terminal_nombre  → VARCHAR  →Nombre del terminal.

• tipo  → VARCHAR → Clasificación: AGENTE / CONCESIONARIO / AGENCIA.

• codigo → VARCHAR  →Código del terminal.

• direccion → VARCHAR → Dirección física.

• ubigeo  → VARCHAR  → Código de ubigeo.

• departamento → VARCHAR → Departamento (map a ubigeo).

• provincia  → VARCHAR → Provincia (map a ubigeo).

• distrito → VARCHAR → Distrito (map a ubigeo).

• telefono  → VARCHAR  → Teléfono del terminal.

• horario_atencion  → VARCHAR  → Horario de atención.

• documento_administrador  → VARCHAR  → DNI/RUC del administrador.

• abreviatura  → VARCHAR  → Abreviatura del terminal.

• fecha_creacion  → DATETIME  → Fecha de creación del terminal.

• usuario_creacion  → VARCHAR  → Usuario que creó el registro.

• serie_comprobantes  → VARCHAR  → Serie de comprobantes asociados.

• serie_os  → VARCHAR  → Serie de órdenes de servicio.

• zona  → VARCHAR  → Zona a la que pertenece.

• conexion  → VARCHAR(2)  → SI / NO según ter_tipo_conexion.

• tipo_destino  → VARCHAR  → Categoría: Destinos 24h / 48h / etc.

• habilitado_os  → VARCHAR(2)  → SI / NO según habilitación OS.

• habilitado  → VARCHAR(2)  → SI / NO según habilitación terminal.

• razon_social  → VARCHAR  → Razón social asociada.

• ruc  → VARCHAR(11)  → Número de RUC.

• correo → VARCHAR  → Correo asociado.

• comision  → DECIMAL  → Comisión asociada al terminal.

• pinpad  → VARCHAR  → Tipo o configuración de pinpad.

• cantidad  → INT  → Cantidad de pinpads.

• igv  → DECIMAL  → Porcentaje de IGV.

• reparto → VARCHAR(2)  → SI / NO según habilitación de reparto.

• supervisor  → VARCHAR  → Supervisor directo (de Branch).

• n_zona  → VARCHAR  → Zona obtenida del JSON de terminales.

• sup_supervisor  → VARCHAR  → Supervisor de Zonas Nacional.

• sup_zona  → VARCHAR  → Zona del supervisor de Zonas Nacional.

• salida_terminal  → VARCHAR  → Información sobre salida de terminal.

• subgrupo_embarque  → VARCHAR  → Subgrupo de embarque.

• created_date  → DATETIME  → Fecha/hora de generación del reporte.

• Ordenamiento por defecto: No Aplica

7) Frecuencia y operación

• Frecuencia de actualización: Diaria

• Ventana que recalcula (días/meses): No aplica

• Tamaño de lote / paginado (chunking): Está comentado

• si la tabla de terminales es muy grande, el proceso dividiría en bloques de 900 registros para insertar
  
  

• Tolerancia a fallos / reintentos: No hay aplica

• Tiempos de ejecución esperados: No especifica

8) Calidad y controles

• Validaciones previas/post: 

• where ter.ter_habilitado=1 and ter.eliminado=0" ( solo se procesan terminales activos y no eliminados.)

• Controles de duplicados: Sobrescritura de registros, tomando ter_id e identificador

• Métricas de completitud (qué se monitorea): indirectas, basadas en is_null, reemplazos por valores vacíos, y banderas SI/NO que aseguran datos legibles.

9) Dependencias externas

• ERPNext – Zona Nacional
  
  

• APIs / servicios y endpoints: api/method/send-query-database
  
  

• Autenticación / headers: no especifica
  
  

• Contrato:

• Entrada: parámetros filters, sql_query, tables enviados al API.
  
  

• Salida: JSON estructurado (response) → se transforma en arrays asociativos ($supervisores_json, $sups_group) y se usa para enriquecer la data local.  

10) Historial de cambios

2025-09-12 04:24 - Elian franco Arroyo Rodas - Documentación inicial

 

REPORTE LICENCIA CERTIFICADOS

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

1) Nombre del reporte

• Nombre: Report licencias certificados
  
  

• Código/Alias: report_licencias_certificados
  
  

• Responsable: Equipo de Reportes Cloud
  
  

• Propósito: Ejecutar la actualización del reporte de licencias y certificados, registrando en la tabla emp_reportes_validation el estado (éxito o error) de la ejecución.

2) Alcance temporal

• Campo(s) de fecha utilizados (base): 

• "first_date" → date("Y-m-d")

• "second_date" → date("Y-m-d")

• "created_date" → date("Y-m-d H:i:s")
  
  

• Tipo de rango: Diarioo ( firstDate y secondDate se generan con la fecha actual ("Y-m-d"))
  
  

• Inclusión de horas (sí/no):

• "created_date" sí incluye horas → formato Y-m-d H:i:s. (00:00:00 – 23:59:59)

Zona horaria: Servidor (igual a sistema)

 

3) Origen de datos (tablas/APIs)

3.1 Cargueros programados

• Conexión/Base: empresarial
  
  

• Tabla: emp_reportes_validation
  
  

• Campos utilizados (clave → descripción):

• "report" → nombre o alias del reporte ejecutado.

• "first_date" → fecha de inicio (en este caso, fecha actual).

• "second_date" → fecha de fin (misma fecha actual).

• "created_date" → fecha y hora exacta de la ejecución.

• "status" → estado de la ejecución (1 = éxito, 0 = error)
  
  

• Condiciones (WHERE) aplicadas:

• Ninguna, solo se realiza un insert directo en la tabla.
  
  

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

• No hay uniones (JOIN) en este bloque.

4) Filtros globales del reporte

• Inclusiones (must-have):

• No hay filtros de inclusión aplicados en este bloque.

• El único “must-have” implícito es que siempre se inserta un registro en emp_reportes_validation al ejecutar el método.
  
  

• Exclusiones (reglas de descarte): No existen reglas de exclusión en el código (ningún WHERE ni condición de descarte sobre datos externos).
  
  

• Reglas habilitado/estado:
  
  

• Se maneja el campo "status":

• 1 → ejecución correcta del reporte.

• 0 → ejecución fallida (capturada en el catch).
  
  

• No hay validación de “habilitado” en la tabla ni en el código.
  
  

• Parámetros externos (si el usuario puede filtrar): 

• No hay parámetros externos.
  
  

• Fechas (first_date y second_date) se fijan automáticamente al día actual, sin posibilidad de modificar por entrada externa.

5) Transformaciones y Reglas de negocio

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

• "first_date" y "second_date" → se derivan de la fecha actual con date("Y-m-d").
  
  

• "created_date" → se deriva del momento exacto de ejecución con date("Y-m-d H:i:s").
  
  

• "status" → se asigna en función del resultado de la ejecución:

• 1 si no hay excepción.

• 0 si se captura una excepción.
  
  

• Mapeos de estado:

• status = 1 → reporte generado / ejecución exitosa.

• status = 0 → error durante la ejecución (capturado en el catch)
  
  

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

• No existen validaciones explícitas sobre los datos antes de insertarlos en la tabla.
  
  

• Se asume que los valores generados son siempre válidos porque provienen del sistema (date() y constantes).

 

• Reglas condicionales (si X entonces Y):

• Si el bloque try se ejecuta sin errores, entonces se inserta un registro con status = 1.
  
  

• Si ocurre una excepción (catch), entonces se inserta un registro con status = 0.
  
  

• Si $response_service contiene al menos un elemento, el método retorna "status" => true, de lo contrario "status" => false.

6) Estructura de salida

• Tabla/archivo destino: emp_reportes_validation (tabla de reportes)
  
  

• Particionado / sufijo: No hay, todo se inserta directamente en emp_reportes_validation
  
  

• Clave(s) primaria(s) o únicas: No se especifica, pero se asume que la tabla tiene un campo autoincremental (ej. id) como clave primaria.
  
  

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

• report → string → alias/nombre del reporte (report_licencias_certificados).
  
  

• first_date → date → fecha de inicio (en este caso, fecha actual).
  
  

• second_date → date → fecha de fin (igual a la fecha actual).
  
  

• created_date → datetime → momento exacto de la ejecución.
  
  

• status → int → estado de la ejecución (1 = éxito, 0 = error).

• Ordenamiento por defecto: no aplica para este reporte.

7) Frecuencia y operación

• Frecuencia de actualización:  No está definida en el código. Se puede ejecutar en un cron.
  
  

• Ventana que recalcula (días/meses): Se ejecuta diariamente.
  
  

• Tamaño de lote / paginado (chunking):
  
  

• No hay procesamiento en lotes ni paginado.
  
  

• Sólo registra un único resultado en emp_reportes_validation por ejecución.
  
  

• Tolerancia a fallos / reintentos: Si ocurre una excepción, se captura en el catch y se inserta igualmente un registro con status = 0
  No hay Reintentos

• Tiempos de ejecución esperados: No se especifica en el código.

UTF-8: force_utf8mb4 = true.

8) Calidad y controles

• Validaciones previas/post:

• Previas: No existen validaciones antes de ejecutar reportLicenciasCertificados() ni antes de insertar en la tabla.
  
  

• Post: El único control es verificar si $response_service tiene elementos (count($response_service) > 0) para retornar status = true/false.
  
  

• Controles de duplicados: No hay controles para evitar duplicados en la tabla
  
  

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

• Solo se monitorea un campo: status (1 = ejecución exitosa, 0 = fallida).
  
  

9) Dependencias externas

• ERPNext – Licencias y Certificados
  
  

• Endpoint: method/send-query-database
  
  

• Request: 

• filters → JSON vacío ([]).

• where → "where definido_para_la_sucursal = 'SI'".

• sql_query → listado de campos (ej. name, sucursal, id_sucursal, etc.).

• tables → `tabLicencias y Certificados`.
  
  

• Contrato: retorna estado_documento, n_serie, number_factura.
  
  

• Autenticación / headers: No se maneja ningún esquema de autenticación ni headers en este código.
  
  

• Mapeos y contratos de datos:

• El “contrato de datos” que este método garantiza es la inserción en emp_reportes_validation con los campos:
  
  

• report → string (nombre del reporte).
  
  

• first_date → date.
  
  

• second_date → date.
  
  

• created_date → datetime.
  
  

• status → int (0/1).
  
  

• Este contrato sirve como registro estándar para saber si el reporte se ejecutó y con qué resultado.

10) Historial de cambios

2025-09-10 17:00 - Elian Franco Arroyo Rodas - Documentación inicia

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

 

REPORTE SHALOM PRO

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

1) Nombre del reporte

• Nombre: Reporte Shalom Pro
  
  

• Código/Alias: report_shalom_pro
  
  

• Responsable: Equipo de Reportes Cloud
  
  

• Propósito: 

2) Alcance temporal

• Campo(s) de fecha utilizados:

• first_date

• second_date

• created_date
  
  

• Tipo de rango (diario / mensual / personalizado): No especifica, posiblemente se ejecute en un CRON
  
  

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

• Zona horaria: La del servidor

 

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: Plataforma Pro

• Tabla / Recurso: users 

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• email →       Correo/email

• verification_cell →  Numero celular

• status →       Estado

• person_id →        Identificador de Persona

• id →       Identificado
  
  

• Condiciones (WHERE) aplicadas: 

• Filtra los registros que tengan fecha de creación del 1ro de Enero del año actual en adelante.
  
  

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

• Observaciones (ej. particiones, índices): El ordenamiento que tiene es Por ID de mayor a menor (Ubica al comienzo de la lista los últimos registros.)

3.2 Conexión / Base: Plataforma Pro

• Tabla / Recurso: person

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• document →  Documento de Identidad

• name →         Nombre

• last_name → Apellido Paterno

• sur_name → Apellido Materno

• id →           Identificador de registro
  
  

• Condiciones (WHERE) aplicadas: 

• Filtra Por ID en lotes de 2000 registro de la tabla person

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

• Observaciones (ej. particiones, índices): Sin obs

3.3 Conexión / Base: Empresarial (Centos - Srv. Notificaciones)

• Tabla / Recurso: emp_service_empresarial_notification

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• correo → Correo/email vinculado/registrado en usuario pro
  
  

• Condiciones (WHERE) aplicadas: 

• Filtra Por correo en lotes de 2000 registro de la tabla users (usuarios pro)

• Filtra los registros que tengan estado SMS == 2 

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

• Observaciones (ej. particiones, índices): Sin obs

3.4 Conexión / Base: Plataforma Pro

• Tabla / Recurso: password_reset_history

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• email → email del usuario de shalom Pro
  
  

• Condiciones (WHERE) aplicadas: 

• Filtra Por email en lotes de 2000 registro de la tabla users (usuarios pro)

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

• Observaciones (ej. particiones, índices): Sin obs

3.5 Conexión / Base: Plataforma Pro

• Tabla / Recurso: service_order

• Alias (si aplica): os

• Campos utilizados (clave → descripción):

• user_id → Identificador de usuario

• type_product  → Tipo de Producto
  
  

• Condiciones (WHERE) aplicadas: 

• Filtra los ID de usuarios en  lotes de 2000

• Si el campo send_shalom de la tabla os es igual a 1 / True

• Si el campo document_converted_service_order de la tabla os es igual a 1 / True

• Si el campo  check_send_package de la tabla os es igual a 1 / True

• Si el campo  status de la tabla os es igual a 1 / True

• Tipo de unión con otras fuentes (JOIN y llave): Une los registros de las tablas service_order y detail_service si coinciden en ID (os.id = det.service_order_id )
  
  

• Observaciones (ej. particiones, índices): Ordenamiento de Forma descendente. Los nuevos registros se ubicaran en la parte de arriba y los antiguos al final.

3.6 Conexión / Base: Plataforma Pro

• Tabla / Recurso: contact_change

• Alias (si aplica): 

• Campos utilizados (clave → descripción):

• user  → Identificador de usuario
  
  

• Condiciones (WHERE) aplicadas: 

• Filtra los ID de usuarios en  lotes de 2000

• Solo filtrara los registros con campos “confirm” = 1

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

• Observaciones (ej. particiones, índices): Sin Obs

3.7 Conexión / Base: Plataforma Pro

• Tabla / Recurso: error_reports emp_reportes_validation

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• first_date  → Primera fecha

• second_date → Segunda Fecha

• created_date → Fecha de creacion

• status → Estado
  
  

• Condiciones (WHERE) aplicadas: No aplica. 

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

• Observaciones (ej. particiones, índices): Sin Obs
  
  

4) Filtros globales del reporte

• Inclusiones (must-have):

• Usuarios creados a partir del primer día del año en curso

• Filtros relacionados con los datos de la tabla  service_order
  
  

• Exclusiones (reglas de descarte):

• Usuarios sin ID en la tabla person

• Correos vacíos ó 0
  
  

• Reglas por estado / habilitado:

• status == 0 del usuario marca al registro como eliminado:

• Validación de verification_cell para considerar al usuario como pro (usuario_pro = 1).

• Parámetros externos (si el usuario puede filtrarlo): No hay parámetros externos

5) Transformaciones y Reglas de negocio

• Derivaciones de campos (cómo se calculan): Se crean campos a partir de otros datos antes de insertarlos en la tabla:

• "usuario" = $mail (clave del arreglo original).

• "usuario_pro" = $pro_data["usuario_pro"] (derivado de validación verification_cell).

• "eliminado" se define según $val->status.

• "created_date" se fuerza al valor actual con date('Y-m-d H:i:s').

• "status" = 1 (fijo en la carga inicial).
  
  

 

• Mapeos de estado:

• status == 0 → eliminado = 1.

• verification_cell == true → usuario_pro = 1.

• Otros flags (agregar_contacto, actualizacion_telefono, restablecer_contrasenia, etc.) se marcan con 0/1 dependiendo de condiciones previas.
  
  

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

• Si no existe person_id, se hace continue.

• Si el email está vacío o es "0", también se descarta (continue).

• Se usa confirm = 1 para aceptar cambios de contacto válidos.
  
  

• Reglas condicionales (si X entonces Y):

• if($val->status==0) → eliminado = 1.

• if(!$persons->person_id) → continuar (no se procesa registro).

• if($format_email=="" || $format_email=="0") → continuar.

• if($verify["new"]) → se agrega índice created_date.

• if($verify["status"]) → insertar datos, else → registrar error.

6) Estructura de salida

• Tabla/archivo destino: report_shalom_pro
  
  

• Particionado / sufijo: No aplica
  
  

• Clave(s) primaria(s) o únicas: ID
  
  

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

• id → INT → Identificador único, autoincremental.

• usuario → VARCHAR(100)→Correo electrónico del usuario.

• usuario_pro → VARCHAR(2) → Indicador de celular validado (0 / 1).

• nro_documento → VARCHAR(15) → Número de documento del usuario.

• agregar_contacto → VARCHAR(5) → Indicador de confirmación de contacto (0 / 1).

• actualizacion_telefono → VARCHAR(5)→ Indicador de actualización de número telefónico.

• eliminado→VARCHAR(2)→Estado de usuario eliminado (0 / 1).

• restablecer_contrasenia→VARCHAR(3)→Indicador de restablecimiento de contraseña.

• sobre→VARCHAR(5)→Indicador de envío tipo "Sobre".

• paquete_xxs→VARCHAR(5)→Indicador de envío de paquete XXS.

• paquete_xs→VARCHAR(5)→Indicador de envío de paquete XS.

• paquete_s→VARCHAR(5)→ Indicador de envío de paquete S.

• paquete_m→VARCHAR(5)→Indicador de envío de paquete M.

• paquete_l→VARCHAR(5)→Indicador de envío de paquete L.

• otro→VARCHAR(5)→Indicador de otro tipo de envío.

• created_date→DATETIME→Fecha y hora de ejecución/carga.

• status TINYINT(4)→Estado de validez de la carga (1 activo / 0 error).
  
  

• Ordenamiento por defecto: ORDER BY created_date DESC (Registros más recientes se listan primeros)

7) Frecuencia y operación

• Frecuencia de actualización: No espesifica (Se puede que se ejecutar en un CRON)

• Ventana que recalcula (días/meses): Personalizado (Recalcula tomando en cuenta la fecha del 1ero de Enero del año actual hasta la fecha actual)
  
  

• Tamaño de lote / paginado (chunking):

• Personas (person_id) → procesadas en bloques de 2000 IDs (array_chunk($json_person_id, 2000)).

• Emails de usuarios → bloques de 2000 correos.

• Detalles insertados en tabla final → bloques de 900 registros (array_chunk($detail, 900)).
  
  

• Tolerancia a fallos / reintentos: Aplica try catch. Si encuentra un error devuelve un log a la tabla mp_reportes_validation con status = 0
  
  

• Tiempos de ejecución esperados: Depende de la cantidad de usuarios.

8) Calidad y controles

• Validaciones previas/post:  

• Válida si la tabla destino existe, si no existe la crea.
  $verify = $this->verifyExistTable($db_name, $sql);

• Post–ejecución, se inserta un log en la tabla emp_reportes_validation con status=1 (éxito) o status=0 (fallo), incluyendo fecha/hora.
  
  

• Controles de duplicados: El proceso recalcula siempre desde el 1° de enero y reinserta los datos en la tabla report_shalom_pro
  
  

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

• Se guarda en emp_reportes_validation:

• Nombre del reporte (report_shalom_pro),

• Fecha de inicio y fin del recalculo (first_date, second_date),

• Fecha/hora de ejecución (created_date),

• Estado final (status).

 

9) Dependencias externas

• APIs / servicios y endpoints:  No consume apis externas. Viene de BDs internas:

• dbpronew

• detail_service

• centos

• reports
  
  

• Autenticación / headers: No aplica
  
  

• Mapeos y contratos de datos:

• El código establece un contrato interno:

• Cada correo electrónico (usuario) es la clave lógica.

• Los campos procesados deben cumplir el contrato de salida de la tabla report_shalom_pro:

• usuario (email del user)

• usuario_pro (0/1 → validado por verificación de celular)

• nro_documento (documento desde tabla person)

• agregar_contacto (conteo en contact_change)

• actualizacion_telefono (conteo en emp_service_empresarial_notification)

• eliminado (1 si status=0 en users)

• restablecer_contrasenia (conteo en password_reset_history)

• sobre, paquete_xxs, paquete_xs, paquete_s, paquete_m, paquete_l, otro (conteos por tipo de producto en detail_service)

• created_date (fecha de inserción)

• status (1 fijo).

10) Historial de cambios

2025-09-17 12:00 - Elian Franco Arroyo Roda - Documentación inicial

 

REPORTE CIRCUITO COMPRAS

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

1) Nombre del reporte

• Nombre:  Reporte Circuito de Compras

• Código / Alias:  report_circuito_Compras

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• first_date → Primer día del mes

• second_date  → Último día del mes

• created_date  → Fecha y Hora de creación

• Tipo de rango (diario / mensual / personalizado):  Personalizado (entre firstDate y secondDate)
  
  

• Inclusión de horas (sí/no). Si sí: Se incluye dia completo con formato  [00:00:00 – 23:59:59]

• Zona horaria: Hora del servidor

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: Solicitud de Compras

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del regitro

• docstatus →Estado del documento( 0 = Borrador, 1 = Validado , 2 = Cancelado)

• fecha_cracion → Fecha de creación (Editable en estado Borrador)

• fecha_solicitud → Fecha y hora de la creación del registro

• usuario_solicitud → Usuario que creó el registro

• tipo → Opciones (General/Computo)

• supplier→ Nombre Proveedor

• document_purchase_order → Identificador de Orden de compraa

• Condiciones (WHERE) aplicadas: 

• Filtra los registros que figuren del primer día del mes hasta el último día del mes(o fecha actual en ejecución) 

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

• Observaciones (ej. particiones, índices):

 

3.2 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: Purchase Order

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del registro

• creation → Fecha y hora de la creación del registro

• owner → Usuario que creo el registro

• per_billed → Porcentaje Facturado

• per_received → Porcentaje Recibido

• id_factura → Identificador de Registro de Factura

• Condiciones (WHERE) aplicadas: 

• Filtra registro identificado de de Orden de compra, que estén vinculados a una Solicitud de Compras

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

• Observaciones (ej. particiones, índices):

3.3 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: Purchase Invoice

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del registro

• solicitud_de_pago → Identificador de registro de Solicitud de Pago Vinculado

• Condiciones (WHERE) aplicadas: 

• Filtra los registros que estén vinculados a una orden de compra por el propio Identificador de Factura de compra

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

• Observaciones (ej. particiones, índices):
  
  

3.4 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: Solicitud de Pagos

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del registro

• usuario_que_registro_el_pago → Usuario que realizó el pago

• fecha_de_pago → Fecha de pago

• Condiciones (WHERE) aplicadas: 

• Filtra los registros de solicitud de pagos que se encuentren vinculados a una factura de compra.

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

• Observaciones (ej. particiones, índices):

 

3.5 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: Recibo de Compra

• Alias (si aplica): rcp

• Campos utilizados (clave → descripción):

• itm.purchase_order → Identificador de recibo de compra

• rcp.posting_date → Fecha de registro Recibo de compra

• rcp.owner → Usuario que creó el registro de Recibo de compra

• Condiciones (WHERE) aplicadas: 

• Descarta todos los registros de Orden de compra que tengan Docstatus == 2 (Estado Del documento -> cancelado) 

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

• Une los datos del doctype con la tabla hija que tiene LEFT JOIN `tabPurchase Receipt Item` itm on (rcp.name = itm.parent)
  
  

• Observaciones (ej. particiones, índices):

4) Filtros globales del reporte

• Inclusiones (must-have):

• Incluye solo los registros de Solicitud de Compra cuya fecha de creación este entre el 1ro de Enero hasta la fecha actual

• Incluye Ordenes de compra cuyo identificador de registro(name) este en un registro de Solicitud de Compras

• Incluye Facturas de compras cuyo  identificador de registro(name) este en un registro de Orden de Compra
  
  

• Exclusiones (reglas de descarte):

• Descarta todos los registros de Orden de compra que tengan Docstatus == 2 (Estado Del documento -> cancelado)
  
  

• Reglas por estado / habilitado:

• Condición de filtros por docstatus (Estado del registro del Doctype )

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

5) Transformaciones y Reglas de negocio

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

• fecha_creacion_orden_compra → se toma de orden_compra_array[$val['document_purchase_order']][0]['creation'].

• usuario_orden_compra → se toma de owner en la orden de compra.

• porcentaje_facturado → se deriva de per_billed de la orden de compra.

• porcentaje_recibido → se deriva de per_received.

• fecha_pago y usuario_pago → se obtienen cruzando factura → solicitud de pago.

• fecha_entrega y usuario_entrega → se calculan desde tabla_purchase_list.
  
  

• Mapeos de estado:

• Solicitud de Compras (search_solicitud_compra) se mapea con Purchase Order (orden_compra).

• Purchase Order se mapea con Purchase Invoice (factura_compra).

• Purchase Invoice se mapea con Solicitud de Pagos.

• Purchase Receipt se mapea con Purchase Order para obtener datos de entrega.
  
  

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

• Solo se incluyen órdenes de compra con id_factura existente (if (isset($val['id_factura']))).
  
  

• En recibos de compra (tabla_purchase), se descartan registros con docstatus = 2 (rcp.docstatus != %(docstatus)s).

• Si una orden de compra no existe en orden_compra_array, se inicializan valores en 0 o vacío (validación de fallback).

• Reglas condicionales (si X entonces Y):

• Si existe document_purchase_order válido en una solicitud de compra, entonces se enriquecen los campos con datos de la orden, factura y pagos.

• Si no existe → se rellenan campos con 0 o ''.

• Si la factura tiene solicitud de pago asociada → se obtienen fecha_pago y usuario_pago.

• Si no la tiene → se dejan vacíos.

• Si la orden tiene recibos de compra → se agregan fecha_entrega y usuario_entrega.

• Si no tiene → se dejan vacíos.

 

6) Estructura de salida

• Tabla/archivo destino: report_circuito_Compras

• Particionado / sufijo: 

• Sufijo: report_circuito_Compras + Y + M

• Particion: Cada mes tiene su propia tabla con los registros del período de fechas procesado.

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

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

• id →INT→Identificador único autoincremental (PK).

• name→VARCHAR(250)→Nombre del documento (Solicitud de compra / factura / etc.).

• docstatus→VARCHAR(250)→Estado interno del documento en ERPNext (0 = Borrador, 1 = Confirmado, 2 = Cancelado).

• estado →VARCHAR(250)→Estado de la solicitud de compras (campo del DocType).

• fecha_cracion → VARCHAR(250)→Fecha de creación original del registro. ( tiene un typo, debería ser "creación").

• fecha_solicitud→VARCHAR(250)→Fecha de la solicitud (alias de creation).

• usuario_solicitud→VARCHAR(250)→Usuario que registró la solicitud.

• tipo→VARCHAR(250)→Tipo de solicitud / compra.

• supplier→VARCHAR(250)→Proveedor asociado.

• document_purchase_order→VARCHAR(250)→ID/Name de la orden de compra vinculada.

• fecha_creacion_orden_compra→VARCHAR(250)→Fecha de creación de la orden de compra.

• usuario_orden_compra→VARCHAR(250)→Usuario que generó la orden de compra.

• porcentaje_facturado→VARCHAR(250)→Avance de facturación de la orden de compra (en %).

• porcentaje_recibido→VARCHAR(250)→Avance de recepción de la orden de compra (en %).

• fecha_entrega →VARCHAR(250)→Fecha de entrega del recibo de compra.

• usuario_entrega→VARCHAR(250)→Usuario que registró la entrega.

• fecha_pago→VARCHAR(250)→Fecha en que se registró el pago.

• usuario_pago→VARCHAR(250)→Usuario que registró el pago.

• created_date→DATETIME→Fecha de inserción en la tabla de reporte (timestamp del ETL).

• status→tinyint(4)→Estado interno de la fila en el reporte (por defecto 1 = habilitado).

• 
  

• Ordenamiento por defecto: No se especifica ORDER BY

7) Frecuencia y operación

• Frecuencia de actualización: No especifica( Posiblemente se ejecute por CRON)

• Ventana que recalcula (días/meses): 

• Si es Enero o Febrero toma los dos meses. En caso sea cualquier otro mes  le resta 2 meses al mes actual para tomar la fecha de inicio.

• $first_month = in_array($last_month, [1, 2]) ? 1 : intval(date("m", strtotime(date("Y-m-d") . "-2 month")));

• Tamaño de lote / paginado (chunking): Procesa en lotes de 900 registros.

• Tolerancia a fallos / reintentos: 

• El proceso usa try–catch y maneja transacciones

• Si ocurre un error durante la creación/inserción → se hace rollback y no se guarda información corrupta.

• Hay un registro de errores en tabla error_reports

• Tiempos de ejecución esperados: No especifica

8) Calidad y controles

• Validaciones previas/post: 

• Verifica que exista la tabla y si no existe la crea antes de insertar los datos

• $verify = $this->verifyExistTable($db_name, $sql);

• Tras insertar los datos, se confirma con commit().

• Si falla algo en medio → se hace rollback() para evitar datos inconsistentes.

• Controles de duplicados:  Se escribe una nueva tabla nueva por cada ejecucion: $db = "report_circuito_Compras_" . date("Y_m", strtotime($first_date_sin_format));

• Métricas de completitud (qué se monitorea):  Guarda un registro de validacion en la tabla “emp_reportes_validation”

•  tabla: $insert = $this->centos->table("emp_reportes_validation")->insert($body);

9) Dependencias externas

• APIs / servicios y endpoints:

• resource/Solicitud de Compras → para obtener las solicitudes de compra.

• resource/Purchase Order → para obtener órdenes de compra asociadas.

• resource/Purchase Invoice → para obtener facturas de compra.

• resource/Solicitud de Pagos → para obtener solicitudes de pago.

• method/send-query-database → para ejecutar consultas SQL personalizadas contra tablas internas (tabPurchase Receipt, tabPurchase Receipt Item).

• Autenticación / headers: Es probable que la autenticación se maneje dentro de ServiceErp o dbErp

• Mapeos y contratos de datos: JSON estructurado en filters, fields, response

10) Historial de cambios

2025-09-18 13:00 - Elian Franco Arroyo Rodas - Documentación inicial

 

REPORTE DEMORA

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

1) Nombre del reporte

• Nombre: Reporte Demora

• Código / Alias: report_demora

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• first_date → Primer día del mes

• second_date  → Último día del mes

• created_date  → Fecha y Hora de creación

• Tipo de rango (diario / mensual / personalizado): Personalizado(entre first_date y second_date)

• Inclusión de horas (sí/no). Si 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_terminal

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• ter_nombre → Nombre de terminal

• ter_id → ID de la terminal

• ter_habilitado →Estado de la terminal (1 = habilitado, 0 = deshabilitado )

• Condiciones (WHERE) aplicadas: No aplica

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

• Observaciones (ej. particiones, índices): Sin obs

3.2 Conexión / Base: Shalom choferes

• Tabla / Recurso: emp_demora

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• cap_id → Identificador Carguero Programado

• monto → Motivo (select)

• subtipo → Depende del tipo de Motivo (también es un select)

• observacion → Descripcion del Motivo/subtipo

• fecha → Fecha de registro

• user → Usuario que realiza el registro

• terminal_responsable → Terminal responsable 

• fh_inicio_demora → Fecha y hora en que se registró la demora

• fh_fin_demora →  Fecha y hora en que se finalizó la demora

• terminal_salida → ID de la terminal Origen

• terminal_llegada → D de la terminal Destino

• estado_incidencia → 1 = VÁLIDO / 0 = IVALIDO

• Condiciones (WHERE) aplicadas: 

• Filtra registro con estado = 1

• Filtra registros con fechas que están entre first_date y second_date

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

• Observaciones (ej. particiones, índices): Sin obs

3.3 Conexión / Base: Empresarial

• Tabla / Recurso: emp_cargprogramado

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• cap_id → Identificador de carguero programado

• cap_rutacarguero → Ruta de carguero

• cap_cargueroid → Identificador de carguero

• Condiciones (WHERE) aplicadas: Filtra registros de la tabla emp_cargprogramado si encuentra coincidencias en cap_id con los registros de la tabla emp_demora.

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

• Observaciones (ej. particiones, índices): Sin obs

3.4 Conexión / Base: Empresarial

• Tabla / Recurso: emp_persona

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• per_nrodocumento

• per_nombrerzsoc

• per_apellidopaterno

• per_apellidomaterno

• Condiciones (WHERE) aplicadas: Filtra los registros de la tabla emp_persona que coincidan en documento de identidad  con el usuario que registró la demora (per_nrodocumento == user)

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

• Observaciones (ej. particiones, índices): Sin obs

 

4) Filtros globales del reporte

• Inclusiones (must-have): Sólo se incluyen demoras activas (estado = 1) y dentro del rango de fechas indicado.
  
  

• Exclusiones (reglas de descarte): 

• Todo lo que no cumpla estado = 1 queda automáticamente descartado.

• Todo lo que esté fuera del rango de fechas (first_date, second_date) también se descarta.

• Reglas por estado / habilitado:

•  En la tabla de emp_demora se procesan registros con estado = 1

•  En la tabla de  emp_terminal se procesan registros con estado = 1

• Parámetros externos (si el usuario puede filtrarlo): first_date y second_date son parámetros externos que se pueden definir por el usuario que definen el rango de fecha 

5) Transformaciones y Reglas de negocio

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

• $db → "report_demora_" . date("Y_m", strtotime($demora->fecha));

• $fehca → date("Y-m-d", strtotime($demora->fecha));

• placa → id_carguero - Proviene de un json de la tabla emp_cargprogramado

• ruta → cap_rutacarguero - Proviene de un json de la tabla emp_cargprogramado

• Mapeos de estado: 

• estado_incidencia → por defecto “PENDIENTE”

• 1 == “VALIDO”

• 2 == “INVALIDO”

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

• Solo se procesan registros con estado habilitado de la tabla emp_demora

• Solo se procesan registros con estado habilitado de la tabla emp_embarque_aereo

• Reglas condicionales (si X entonces Y):

•  Si el motivo de la demora es "Demora De Terminales" se guarda la terminal de salida, caso contrario es null.

• Si el motivo de la demora es "Demora De Terminales" se guarda la terminal de llegada, caso contrario es null.

 

6) Estructura de salida

• Tabla/archivo destino: report_demora
  
  

• Particionado / sufijo: El particionado se hace por mes y año usando sufijo YYYY_MM. ( ejm: report_demora_2025_09)
  
  

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

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

• id→INT (PK) → Identificador único autoincremental

• fecha_incidencia→DATE→Fecha de la demora

• placa→VARCHAR(20)→Identificador del vehículo/carguero

• ruta→VARCHAR(100)→Ruta asignada

• tipo_de_demora→VARCHAR(50)→Categoría de demora (monto)

• incidencia→VARCHAR(100)→Subtipo de la demora

• agencia_involucrada→VARCHAR(70)→Nombre del terminal responsable

• observacion→TEXT→Observaciones registradas

• nombre_usuario→VARCHAR(100)→Usuario asociado

• terminal_salida→VARCHAR(100)→Terminal de salida (si aplica)

• terminal_llegada→VARCHAR(100)→Terminal de llegada (si aplica)

• estado→VARCHAR(10)→Estado transformado (PENDIENTE, VALIDO, INVALIDO)

• created_date→DATETIME→Fecha y hora de creación del registro en la tabla

• status→tinyint(4)→Estado de habilitación (1 = activo)

• Ordenamiento por defecto: No se especifica ORDER BY

7) Frecuencia y operación

• Frecuencia de actualización: Se ejecuta desde el método updateReportDemora().

• Ventana que recalcula (días/meses): Se realiza mensualmente tomando los parámetros first_month y last_month (primer y último día del mes).

• Tamaño de lote / paginado (chunking): 

• Se insertan máximo 900 registros por batch

• Se consulta emp_cargprogramado en lotes de 1000 IDs

• Tolerancia a fallos / reintentos: 

• Si no se puede crear/verificar la tabla:

• Inserta un registro en error_reports para auditar el fallo.

• Usa continue; para no detener todo el proceso.

• En updateReportDemora también:

• Si ocurre un error, registra en emp_reportes_validation con status = 0.

• No hay reintento automático inmediato, pero sí un log de fallos.

• Tiempos de ejecución esperados: Tiempo esperado depende de cantidad de demoras procesadas

8) Calidad y controles

• Validaciones previas/post: 

• Antes de insertar datos en las tablas dinámicas (report_demora_YYYY_MM), se valida si la tabla existe, si no existe se crea.

• Controles de duplicados: no se encontró

• Métricas de completitud (qué se monitorea): Se inserta en emp_reportes_validation el rango procesado junto al status (1 = ok, 0 = error). Eso funciona como log de validación de ejecución.

9) Dependencias externas

• APIs / servicios y endpoints:

• emp_terminal

• emp_demora

• emp_cargprogramado

• emp_persona

• Autenticación / headers: no aplica

• Mapeos y contratos de datos:

• cap_id → se busca en emp_cargprogramado para obtener cap_cargueroid y cap_rutacarguero.

• user → se mapea a per_nrodocumento en emp_persona.

• terminal_responsable, terminal_salida, terminal_llegada → se mapean a nombres de terminales ($jsonTerms).

• estado_incidencia → se transforma de numérico (1, 2) a texto (VALIDO, INVALIDO).

10) Historial de cambios

2025-09-18 18:22 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE FACTURA DE COMPRA

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

1) Nombre del reporte

• Nombre: Reporte Factura de Compra

• Código / Alias: report_factura_de_compra

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• first_date → Fecha inicio

• second_date → Fecha Fin

• created_date → Fecha de creacion

• Tipo de rango (diario / mensual / personalizado): Mensual (frist_month, last_month)

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

• Zona horaria: la del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base:  ERP

• Tabla / Recurso: tabPurchase Invoice

• Alias (si aplica): mr

• Campos utilizados (clave → descripción):

• id → Identificador

• name →Identificador de registro

• docstatus → Estado del registro

• supplier → Nombre del proveedor

• company→ Compañía

• fecha → Fecha de registro/creacion

• caja_chica →Monto Caja chica

• grand_total → Monto total

• currency → Moneda

• estado_general → Estado general

• fecha → Fecha 

• created_date → Fecha de creacion

• status → stado técnico (1 activo)

 

• Condiciones (WHERE) aplicadas: El filtro pide todos los registros de la tabla mr que estén entre las fechas $inicio y $fin, y además que estén confirmados (docstatus = 1)

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

• Observaciones (ej. particiones, índices): Hay un particionado temporal: los ranges calculados con first_day y last_day. Se usa para cortar la data por meses.

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Depende de lo que reciba dateUnlimited y el rango de fecha (first_day y last_day)

• Exclusiones (reglas de descarte): No aplica

• Reglas por estado / habilitado: No aplica

• Parámetros externos (si el usuario puede filtrarlo): Si, el usuario puede incluir la fecha inicio y fecha fin en el rango de búsqueda.

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado: No aplica

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

 

• Reglas condicionales (si X entonces Y):

• Si $dateUnlimited == "TODOS" → recorrer todos los años desde 2021.

• Si $dateUnlimited == "12" → generar rangos mes a mes desde la fecha pivote 2023-09-01.

• Si $dateUnlimited == "8" → tomar últimos 8 meses.

• Si no se cumple ninguno → tomar mes actual y posiblemente diciembre del año anterior.

6) Estructura de salida

• Tabla/archivo destino: report_factura_de_compra

• Particionado / sufijo: no aplica

• Clave(s) primaria(s) o únicas: no aplica

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

• id → INT AUTO_INCREMENT → Identificador único

• name → VARCHAR(50) → Nombre/ID de la factura

• docstatus → VARCHAR(2) → Estado documental (0,1,2)

• supplier → VARCHAR(255) → Proveedor

• company → VARCHAR(255) → Empresa asociada

• fecha → VARCHAR(20) → Fecha de emisión

• caja_chica → VARCHAR(20) → Relación con caja chica

• grand_total → VARCHAR(20) → Importe total

• estado → VARCHAR(100) → Estado de negocio (ej. aprobado)

• currency → VARCHAR(100) → Moneda

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

• status → tinyint(4) DEFAULT 1 → Flag de estado del registro

• Ordenamiento por defecto: No ampl ORDER BY

7) Frecuencia y operación

• Frecuencia de actualización: Al ejecutarse la funcion updateFacturaCompra()

• Ventana que recalcula (días/meses): 

• Depende de dateUnlimited:

• "TODOS" → recalcula desde 2021 hasta la fecha actual.

• "12" → recalcula desde un pivote (2023-09-01) mes por mes hasta hoy.

• "8" → últimos 8 meses.

• Vacío o default → solo el mes actual (con excepción de enero/febrero que arrastra diciembre del año anterior).
  
  

• Tamaño de lote / paginado (chunking): 

• Se usa array_chunk($result, 900) → divide la data en lotes de 900 registros antes de insertarlos en BD.

• Tolerancia a fallos / reintentos: Se manejan excepciones con try/catch y \PDOException
  
  

• Tiempos de ejecución esperados: No se especifica

8) Calidad y controles

• Validaciones previas/post:

• Previas:

• Se valida si la tabla existe antes de insertar ($verify = $this->verifyExistTable(...)).

• Si no existe, se inserta un registro en error_reports y se hace continue → es una validación previa para garantizar que la tabla destino esté lista.

• Se maneja el caso especial de enero/febrero para incluir datos del año anterior → valida consistencia temporal.

• Post: 

• Tras cada inserción en lote (insert($arr)), se hace commit() de la transacción.

• Si hay error (catch (\PDOException $e)), se hace rollBack() y se registra el fallo en emp_reportes_validation.

• Controles de duplicados:

• En la lógica de creación de tablas particionadas (CREATE TABLE {$db_name}), que evita que se inserten datos de un rango en la misma tabla dos veces.
  
  

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

• Se insertan logs en emp_reportes_validation con campos:

• report → nombre del reporte.

• first_date, second_date → ventana procesada.

• created_date → cuándo se ejecutó.

• status → 1 (éxito) o 0 (error).

9) Dependencias externas

CDT ERPNext – Factura de Compra

• APIs / servicios y endpoints: method/send-query-database

• Autenticación / headers:

• Se envían headers básicos: 

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• No aparece un Authorization: Bearer <token> ni otra forma de autenticación explícita.
  
  

• Mapeos y contratos de datos: 

•  "sql_query" => "name,

•     docstatus,

•     supplier,

•     company,

•     posting_date as 'fecha',

•     caja_chica,

•     base_total as 'grand_total',

•     estado_del_documento as 'estado',

•     currency",

10) Historial de cambios

2025-09-19 13:08 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE FACTURA DE VENTA

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

1) Nombre del reporte

• Nombre: Reporte Factura de Venta

• Código / Alias: report_factura_de_venta

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• first_date → Fecha inicio

• second_date → Fecha Fin

• created_date → Fecha de creacion

• Tipo de rango (diario / mensual / personalizado): Mensual (frist_month, last_month)

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

• Zona horaria: la del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base:  ERP

• Tabla / Recurso: tabSales Invoice

• Alias (si aplica): si

• Campos utilizados (clave → descripción):

• name → Identificador de registro

• docstatus → Estado del documento

• customer → Cliente

• estado → Estado

• factura_tipo → Tipo Factura

• serie → Numero de serie

• n_de_orden_venta →Registro  de Orden de venta Vinculado

• orden_de_trabajo → Registro  de  Orden De trabajo Vinculado 

• placa_id →  Identificador de placa

• placa_vehiculo → Placa de Vehiculo

• numero → Numero

• grand_total → Monto total

• currency → Moneda

• estado_general → Estado general

• posting_date → Fecha de publicacion

• Condiciones (WHERE) aplicadas: devuelve los registros cuya fecha esté dentro del rango indicado y que no tengan estado “Cancelled”

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

• Observaciones (ej. particiones, índices): Hay un particionado temporal: los ranges calculados con first_day y last_day. Se usa para cortar la data por meses.

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Depende de lo que reciba dateUnlimited y el rango de fecha (first_day y last_day)

• Exclusiones (reglas de descarte): No aplica

• Reglas por estado / habilitado: No aplica

• Parámetros externos (si el usuario puede filtrarlo): Si, el usuario puede incluir la fecha inicio y fecha fin en el rango de búsqueda.

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado: No aplica

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

• Reglas condicionales (si X entonces Y):

• Si $dateUnlimited == "TODOS" → recorrer todos los años desde 2021.

• Si $dateUnlimited == "12" → generar rangos mes a mes desde la fecha pivote 2023-09-01.

• Si $dateUnlimited == "8" → tomar últimos 8 meses.

• Si no se cumple ninguno → tomar mes actual y posiblemente diciembre del año anterior.

6) Estructura de salida

• Tabla/archivo destino: report_factura_de_venta

• Particionado / sufijo: no aplica

• Clave(s) primaria(s) o únicas: no aplica

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

• id → INT → Identificador único incremental (clave primaria)  

• name → VARCHAR(50) → Nombre o identificador del registro  

• docstatus → VARCHAR(50) → Estado documental del registro (ej. borrador, validado)  

• customer → VARCHAR(200) → Cliente asociado a la factura  

• estado → VARCHAR(200) → Estado de la factura o transacción  

• factura_tipo → VARCHAR(200) → Tipo de factura (ej. venta, compra)  

• serie → VARCHAR(200) → Serie de la factura  

• n_de_orden_venta → VARCHAR(200) → Número de orden de venta asociada  

• orden_de_trabajo → VARCHAR(200) → Orden de trabajo relacionada  

• placa_id → VARCHAR(200) → Identificador interno de la placa del vehículo  

• placa_vehiculo → VARCHAR(200) → Placa física del vehículo  

• numero → VARCHAR(200) → Número de la factura o documento  

• grand_total → VARCHAR(200) → Importe total de la factura  

• currency → VARCHAR(200) → Moneda en que se registra la transacción  

• estado_general → VARCHAR(200) → Estado general consolidado del documento  

• fecha → VARCHAR(200) → Fecha de emisión o registro  

• created_date → DATETIME → Fecha y hora de creación (por defecto actual)  

• status → TINYINT(4) → Indicador de estado activo/inactivo (1 por defecto) 

• Ordenamiento por defecto: No aplica ORDER BY

7) Frecuencia y operación

• Frecuencia de actualización: Al ejecutarse la función updateFacturaVenta()

• Ventana que recalcula (días/meses): 

• Depende de dateUnlimited:

• "TODOS" → recalcula desde 2021 hasta la fecha actual.

• "12" → recalcula desde un pivote (2023-09-01) mes por mes hasta hoy.

• "8" → últimos 8 meses.

• Vacío o default → solo el mes actual (con excepción de enero/febrero que arrastra diciembre del año anterior).
  
  

• Tamaño de lote / paginado (chunking): 

• Se usa array_chunk($result, 900) → divide la data en lotes de 900 registros antes de insertarlos en BD.

• Tolerancia a fallos / reintentos: Se manejan excepciones con try/catch y \PDOException
  
  

• Tiempos de ejecución esperados: No se especifica

8) Calidad y controles

• Validaciones previas/post:

• Previas:

• Se valida si la tabla existe antes de insertar ($verify = $this->verifyExistTable(...)).

• Si no existe, se inserta un registro en error_reports y se hace continue → es una validación previa para garantizar que la tabla destino esté lista.

• Se maneja el caso especial de enero/febrero para incluir datos del año anterior → valida consistencia temporal.

• Post: 

• Tras cada inserción en lote (insert($arr)), se hace commit() de la transacción.

• Si hay error (catch (\PDOException $e)), se hace rollBack() y se registra el fallo en emp_reportes_validation.

• Controles de duplicados:

• En la lógica de creación de tablas particionadas (CREATE TABLE {$db_name}), que evita que se inserten datos de un rango en la misma tabla dos veces.
  
  

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

• Se insertan logs en emp_reportes_validation con campos:

• report → nombre del reporte.

• first_date, second_date → ventana procesada.

• created_date → cuándo se ejecutó.

• status → 1 (éxito) o 0 (error).

9) Dependencias externas

ERPNext – Factura de venta

• APIs / servicios y endpoints: method/send-query-database

• Autenticación / headers:

• Se envían headers básicos: 

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• No aparece un Authorization: Bearer <token> ni otra forma de autenticación explícita.
  
  

• Mapeos y contratos de datos: Se especifica parcialmente en la tabla  report_factura_de_venta de la función updateFacturaVenta() 

10) Historial de cambios

2025-09-19 16:55 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE PROGRAMACION SUPERVISORES

Fuente:  /var/www/html/horario_salida/app/Http/Controllers/RecursosController.php

1) Nombre del reporte

• Nombre: Reporte Programación Supervisores

• Código / Alias: report_programacion_supervisores

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecha_inicio

• fecha_fin

• Tipo de rango (diario / mensual / personalizado): Mensual

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: RECURSOS HUMANOS

• Tabla / Recurso: tabProgramacion de Supervisores

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del registro

• nombre_supervisor →Nombre del Supervisor

• sucursal → Nombre de la Terminal/Sucursal

• fecha_programada → Fecha programada

• supervisor → Codigó de empleado

• aprobación_del_informe → Estado de Aprobación

• prog_supervisores → Tipo de Programación

• fecha_1era_reprogramacion → Fecha 1era Reprogramación

• fecha_real_de_la_supervicion →  Fecha Real de la Supervisión

• zonaa_nacional → Registro/tipo de Zona nacional

• creation → Fecha de creación del registro

• owner → Usuario que creó el registro

• tipo_de_emergencia → Tipo Emergenci(select)

• fecha → Fecha Programada

• subir_archivo →Informe final(Archivo adjunto)

• id_sucursal →  IDe de Terminal/Sucursal

• adjuntar_foto → Foto Adjunta

• adjuntar_foto_banner → Adjuntar una foto
  
  

• Condiciones (WHERE) aplicadas: Filtra en un rango definido por parámetros externos ($fecha_inicio y $fecha_fin)

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

• Observaciones (ej. particiones, índices): No aplica

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Depende de lo que reciba dateUnlimited y el rango de fecha (first_day y last_day)

• Exclusiones (reglas de descarte): No aplica

• Reglas por estado / habilitado: No aplica

• Parámetros externos (si el usuario puede filtrarlo): Sí, el usuario puede incluir la fecha inicio y fecha fin en el rango de búsqueda.

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado: No aplica

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

• Reglas condicionales (si X entonces Y):

• Si $dateUnlimited == "TODOS" → recorrer todos los años desde 2021.

• Si $dateUnlimited == "12" → generar rangos mes a mes desde la fecha pivote 2023-09-01.

• Si $dateUnlimited == "8" → tomar últimos 8 meses.

• Si no se cumple ninguno → tomar mes actual y posiblemente diciembre del año anterior.

6) Estructura de salida

• Tabla/archivo destino: report_programacion_supervisores

• Particionado / sufijo: no aplica

• Clave(s) primaria(s) o únicas: no aplica

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

• id → INT AUTO_INCREMENT PRIMARY KEY → id de la fila  

• identificador → VARCHAR(50) NULL → identificador único  

• nombre_supervisor → VARCHAR(255) NULL → nombre del supervisor  

• sucursal → VARCHAR(100) NULL → sucursal asignada  

• fecha_programada → VARCHAR(100) NULL → fecha programada  

• supervisor → VARCHAR(255) NULL → supervisor asignado  

• aprobacion_del_informe → VARCHAR(255) NULL → aprobación del informe  

• tipo_de_programacion → VARCHAR(255) NULL → tipo de programación  

• fecha_1era_reprogramacion → VARCHAR(100) NULL → fecha de la primera reprogramación  

• fecha_real_de_la_supervicion → VARCHAR(100) NULL → fecha real de la supervisión  

• zona_nacional → VARCHAR(100) NULL → zona nacional  

• creado_el → VARCHAR(100) NULL → fecha de creación  

• creado_por → VARCHAR(100) NULL → usuario que creó el registro  

• tipo_de_emergencia → VARCHAR(255) NULL → tipo de emergencia  

• fecha → VARCHAR(100) NULL → fecha general  

• informe_final → VARCHAR(255) NULL → informe final  

• id_sucursal → VARCHAR(50) NULL → identificador de la sucursal  

• adjuntar_foto → VARCHAR(255) NULL → archivo de foto adjunto  

• adjuntar_foto_banner → VARCHAR(255) NULL → archivo de foto banner adjunto  

• created_date → DATETIME DEFAULT CURRENT_TIMESTAMP → fecha y hora de creación  

• status → tinyint(4) DEFAULT '1' → estado del registro  

• Ordenamiento por defecto: No aplica ORDER BY

7) Frecuencia y operación

• Frecuencia de actualización: Al ejecutarse la función updateProgSupervisores()

• Ventana que recalcula (días/meses):

• Depende de dateUnlimited:

• "TODOS" → recalcula desde 2021 hasta la fecha actual.

• "12" → recalcula desde un pivote (2023-09-01) mes por mes hasta hoy.

• "8" → últimos 8 meses.

• Vacío o default → solo el mes actual (con excepción de enero/febrero que arrastra diciembre del año anterior).

• Tamaño de lote / paginado (chunking): 

• Se usa array_chunk($result, 900) → divide la data en lotes de 900 registros antes de insertarlos en BD.

• Tolerancia a fallos / reintentos: Se manejan excepciones con try/catch y \PDOException
  
  

• Tiempos de ejecución esperados: No se especifica

8) Calidad y controles

• Validaciones previas/post:

• Previas:

• Se valida si la tabla existe antes de insertar ($verify = $this->verifyExistTable(...)).

• Si no existe, se inserta un registro en error_reports y se hace continue → es una validación previa para garantizar que la tabla destino esté lista.

• Se maneja el caso especial de enero/febrero para incluir datos del año anterior → valida consistencia temporal.

• Post: 

• Tras cada inserción en lote (insert($arr)), se hace commit() de la transacción.

• Si hay error (catch (\PDOException $e)), se hace rollBack() y se registra el fallo en emp_reportes_validation.

• Controles de duplicados:

• En la lógica de creación de tablas particionadas (CREATE TABLE {$db_name}), que evita que se inserten datos de un rango en la misma tabla dos veces.
  
  

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

• Se insertan logs en emp_reportes_validation con campos:

• report → nombre del reporte.

• first_date, second_date → ventana procesada.

• created_date → cuándo se ejecutó.

• status → 1 (éxito) o 0 (error).

9) Dependencias externas

ERPNext – Programación de Supervisores

• APIs / servicios y endpoints: method/send-query-database

• Autenticación / headers: 

• Se envían headers básicos: 

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• No aparece un Authorization: Bearer <token> ni otra forma de autenticación explícita.
  
  

• Mapeos y contratos de datos: 

• name as identificador,

• nombre_supervisor,

• sucursal,

• fecha_programada,

• supervisor,

• aprobación_del_informe as aprobacion_del_informe,

• prog_supervisores as tipo_de_programacion,

• fecha_1era_reprogramacion,

• fecha_real_de_la_supervicion,

• zonaa_nacional as zona_nacional,

• creation as creado_el,

• owner as creado_por,

• tipo_de_emergencia,

• fecha,

• subir_archivo as informe_final,

• id_sucursal,

• adjuntar_foto,

• adjuntar_foto_banner

10) Historial de cambios

2025-09-19 18:00 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE VIATICOS SUPERVISORES

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

1) Nombre del reporte

• Nombre: Reporte Viaticos Supervisores

• Código / Alias: report_viaticos_supervisores

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecha_inicio

• fecha_fin

• Tipo de rango (diario / mensual / personalizado): Mensual

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: RECURSOS HUMANOS

• Tabla / Recurso: tabViaticos a Supervisores

• Alias (si aplica): vsp

• Campos utilizados (clave → descripción):

• vsp.name → Identificador del registro 

• vsp.estado_del_documento → Estado del Viatico

• vsp.nombre_completo → Nombre completo Empleado

• vsp.monto_general → Monto General / Monto Total

• vsp.monto_restante → Monto Restante

• vsp.estado_del_documento → Estado del documento

• vspm.motivo → Motivo Viatico

• vspm.numero → Numero Comprobante

• vspm.tipo_de_documento → Tipo Documento

• vspm.monto → Monto del Registro Comprobante

• vspm.serie → Numero serie Comprobante

• vspm.fecha_de_emisión → Fecha Emision Comprobante

• vspm.archivo → Archivo Adjunto / Foto del comprobante

• vspm.supervision → Identificador del registro de Supervisor

• vsp.creation → Fecha de creación del registro
  
  

• Condiciones (WHERE) aplicadas:  Filtra en un rango definido por parámetros externos ($fecha_inicio y $fecha_fin)

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

• Observaciones (ej. particiones, índices): Sin obs

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Depende de lo que reciba dateUnlimited y el rango de fecha (first_day y last_day)

• Exclusiones (reglas de descarte): No aplica

• Reglas por estado / habilitado: No aplica

• Parámetros externos (si el usuario puede filtrarlo): Sí, el usuario puede incluir la fecha inicio y fecha fin en el rango de búsqueda.

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado: No aplica

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

• Reglas condicionales (si X entonces Y):

• Si $dateUnlimited == "TODOS" → recorrer todos los años desde 2021.

• Si $dateUnlimited == "12" → generar rangos mes a mes desde la fecha pivote 2023-09-01.

• Si $dateUnlimited == "8" → tomar últimos 8 meses.

• Si no se cumple ninguno → tomar mes actual y posiblemente diciembre del año anterior.

6) Estructura de salida

• Tabla/archivo destino: report_viaticos_supervisores

• Particionado / sufijo: no aplica

• Clave(s) primaria(s) o únicas: no aplica

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

• id → INT → AUTO INCREMENT PRIMARY KEY

• identificador → VARCHAR → 50 NULL

• estado → VARCHAR → 100 NULL

• nombre_completo → VARCHAR → 255 NULL

• monto_general → INT → NULL

• monto_restante → INT → NULL

• estado_del_documento → VARCHAR → 100 NULL

• motivo → VARCHAR → 255 NULL

• numero → VARCHAR → 100 NULL

• tipo_de_documento → VARCHAR → 100 NULL

• monto → INT → NULL

• serie → VARCHAR → 100 NULL

• fecha_de_emision → VARCHAR → 255 NULL

• archivo → VARCHAR → 255 NULL

• supervision → VARCHAR → 500 NULL

• creation → VARCHAR → 100 NULL

• created_date → DATETIME → DEFAULT CURRENT_TIMESTAMP

• status → TINYINT → 4 DEFAULT 1

• Ordenamiento por defecto: No aplica ORDER BY

7) Frecuencia y operación

• Frecuencia de actualización: Al ejecutarse la función updateProgSupervisores()

• Ventana que recalcula (días/meses):

• Depende de dateUnlimited:

• "TODOS" → recalcula desde 2021 hasta la fecha actual.

• "12" → recalcula desde un pivote (2023-09-01) mes por mes hasta hoy.

• "8" → últimos 8 meses.

• Vacío o default → solo el mes actual (con excepción de enero/febrero que arrastra diciembre del año anterior).

• Tamaño de lote / paginado (chunking): 

• Se usa array_chunk($result, 900) → divide la data en lotes de 900 registros antes de insertarlos en BD.

• Tolerancia a fallos / reintentos: Se manejan excepciones con try/catch y \PDOException
  
  

• Tiempos de ejecución esperados: No se especifica

8) Calidad y controles

• Validaciones previas/post:

• Previas:

• Se valida si la tabla existe antes de insertar ($verify = $this->verifyExistTable(...)).

• Si no existe, se inserta un registro en error_reports y se hace continue → es una validación previa para garantizar que la tabla destino esté lista.

• Se maneja el caso especial de enero/febrero para incluir datos del año anterior → valida consistencia temporal.

• Post: 

• Tras cada inserción en lote (insert($arr)), se hace commit() de la transacción.

• Si hay error (catch (\PDOException $e)), se hace rollBack() y se registra el fallo en emp_reportes_validation.

• Controles de duplicados:

• En la lógica de creación de tablas particionadas (CREATE TABLE {$db_name}), que evita que se inserten datos de un rango en la misma tabla dos veces.
  
  

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

• Se insertan logs en emp_reportes_validation con campos:

• report → nombre del reporte.

• first_date, second_date → ventana procesada.

• created_date → cuándo se ejecutó.

• status → 1 (éxito) o 0 (error).

9) Dependencias externas

ERPNext – CAPACITACION

• APIs / servicios y endpoints: method/send-query-database

• Autenticación / headers: 

• Se envían headers básicos: 

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• No aparece un Authorization: Bearer <token> ni otra forma de autenticación explícita.
  
  

• Mapeos y contratos de datos: 

• name → identificador

• aprobación_del_informe → aprobacion_del_informe

• prog_supervisores → tipo_de_programacion

• zonaa_nacional → zona_nacional

• creation → creado_el

• owner → creado_por

10) Historial de cambios

2025-09-20 13:00 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE SOLICITUD DE MATERIALES

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

1) Nombre del reporte

• Nombre: Reporte de Solicitud de Materiales

• Código / Alias: report_solicitud_materiales

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecha_inicio

• fecha_fin

• Tipo de rango (diario / mensual / personalizado): Mensual

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: ERP CAPACITACION

• Tabla / Recurso: tabMaterial Request

• Alias (si aplica): mtr

• Campos utilizados (clave → descripción):

• material_request_type →Tipo de Proposito

• propósito_de_transferencia → Tipo de Propósito de Transferencia

• fecha_y_hora_de_transferencia →  Fecha y hora de transferencia

• status → Estado de Transferencia 

• fecha_y_hora_de_transaccion_erp → Fecha de la Transacción

• confirmar_transferencia → Confirmación de transferencia 

• numero_orden → Número de Guia asociada 

• aprobador_por_ → Usuario que aprobó la transferencia 

• aprobado_nombre_completo → Nombre completo del usuario que aprobó la transferencia

• aprobacion_de_solicitud → Tipo de Aprobación

• cancelado_por → Usuario que cancelo la solicitud

• cancelado_nombre_completo → Nombre completo del usuario que cancelo la solicitud

• detalle_cancelacion→  Detalle de la cancelación 

• id_sucursal → ID de la terminal que envía el producto (Origen)

• zona_nacional → Zona nacional a la que pertenece la terminal de Origen

• sucursal → Nombre de la terminal Origen

• division → Indica si la terminal Origen pertenece a Lima o Provincia 

• departamento → Departamento(Area) de shalom

• per_ordered → Indica un porcentaje

• ultima_actualizacion_el → Fecha y hora en que se actualizó el registro por última vez

• ultima_actualizacion_por →Usuario que actualizó el registro por última vez

• owner→ Usuario que creó el registro

• creation → Fecha de Creacion del registro

• item_code → Código del producto

• item_name → Nombre del producto

• stock_uom → Unidad de medida utilizada en el almacén

• qty → Cantidad 

• puesto → Puesto del Empleado

• sexo → Sexo del Empleado

• nombre_completo_empleado →Nombre completo Empleado

• stock_qty → Cantidad existente

• actual_qty → Cantidad actual

• no_guia as estado_de_orden → Estado de la Guia

• Condiciones (WHERE) aplicadas:

• Filtra el registro, si la fecha de creación están entre los parámetros  $fecha_inicio y $fecha_fin
  
  

• Tipo de unión con otras fuentes (JOIN y llave): Une la tabla tabMaterial Request y tabMaterial Request Item
  
  

• Observaciones (ej. particiones, índices): no se encontraron el valor exacto de actual_qty, stock_qty y per_ordered

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Depende de lo que reciba dateUnlimited y el rango de fecha (first_day y last_day)

• Exclusiones (reglas de descarte): 

• Si numero_orden es null, se descarta del reporte

• Si la API de estados devuelve un error o está vacía, el flujo corta y retorna vacío o la data sin procesar.

• Reglas por estado / habilitado: 

• mtr.status: Permite clasificar los registros en función de su estado.

• obtain_estados: Sí retorna la api de NEWWEBSERVICES validado, se sobrescribe, si no queda vacío.

• Parámetros externos (si el usuario puede filtrarlo): Sí, el usuario puede incluir la fecha inicio y fecha fin en el rango de búsqueda.

5) Transformaciones y Reglas de negocio

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

• usuario_creatransferencia se deriva de $userTransfers y $userGroups:Si existe el usuario dueño de la transferencia, se asigna su full_name, si no, queda vacío.

•  estado_de_orden Se deriva a partir de la consulta externa a otro servicio (buscar-estados-guia).

• Mapeos de estado:

• mtr.status as estado Se mapea directamente desde la tabla tabMaterial Request.

• estado_de_orden Se mapea desde el servicio externo (buscar-estados-guia)

• En la función baseReport, si la tabla es nueva se agrega un índice sobre status, reforzando que este campo es clave para consultas.

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

• Si no se ingresa un rango de fecha se retorna el siguiente mensaje: "Los campos fecha inicio y fecha fin son obligatorios"

• Si la tabla destino no se creo correctamente se inserta un registro en error_reports

• Reglas condicionales (si X entonces Y):

• Si no hay numero_orden, se salta ese registro

• Si $dateUnlimited == "TODOS", "12", "8" o cualquier otro valor → se construyen los rangos de fechas de forma distinta:

• "TODOS" → desde el 2021 hasta el año actual.

• "12" → desde un pivote hasta la fecha actual mes a mes.

• "8" → últimos 8 meses.

• Otro → mes actual y, en caso de enero/febrero, incluye diciembre del año anterior.

• Si la tabla es nueva, se aplica ALTER TABLE para agregar índice sobre status.

• Si ocurre algún error en la transacción se elimina la inserción de la tabla y se retorna un mensaje.

 

6) Estructura de salida

• Tabla/archivo destino: report_solicitud_materiales

• Particionado / sufijo: report_solicitud_materiales_YYYY_MM

• Clave(s) primaria(s) o únicas: name de la tabla “tabMaterial Request”

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

• id → INT AUTO_INCREMENT → Identificador único de la fila (PK interna)

• name → VARCHAR(50) → ID del documento Material Request en ERPNext

• material_request_type → VARCHAR(100) → Tipo de solicitud de material

• propósito_de_transferencia → VARCHAR(255) → Propósito de la transferencia

• fecha_y_hora_de_transferencia → VARCHAR(100) → Fecha/hora de la transferencia

• estado → VARCHAR(50) → Estado de la solicitud (ej. Draft, Submitted, Cancelled)

• fecha_y_hora_de_transaccion_erp → VARCHAR(100) → Fecha/hora de creación en ERP

• confirmar_transferencia → VARCHAR(50) → Indicador de confirmación

• numero_orden → VARCHAR(100) → Número de orden asociado

• aprobador_por_ → VARCHAR(100) → Usuario que aprobó

• aprobado_nombre_completo → VARCHAR(255) → Nombre completo del aprobador

• aprobacion_de_solicitud → VARCHAR(50) → Estado de la aprobación

• cancelado_por → VARCHAR(100) → Usuario que canceló

• cancelado_nombre_completo → VARCHAR(255) → Nombre completo del que canceló

• detalle_cancelacion → VARCHAR(500) → Motivo o detalle de cancelación

• id_sucursal → VARCHAR(20) → Código de la sucursal

• zona_nacional → VARCHAR(50) → Zona geográfica

• sucursal → VARCHAR(50) → Nombre de sucursal

• division → VARCHAR(50) → División interna

• departamento → VARCHAR(50) → Departamento

• per_ordered → INT → Cantidad pedida

• owner → VARCHAR(100) → Usuario creador del documento

• creation → VARCHAR(255) → Fecha de creación del documento

• item_code → VARCHAR(100) → Código del ítem

• item_name → VARCHAR(100) → Nombre del ítem

• stock_uom → VARCHAR(100) → Unidad de medida

• cantidad → INT → Cantidad solicitada

• puesto → VARCHAR(100) → Puesto del empleado asociado

• sexo → VARCHAR(50) → Sexo del empleado

• nombre_completo_empleado → VARCHAR(255) → Nombre completo del empleado

• stock_qty → INT → Cantidad en stock

• actual_qty → INT → Cantidad actual en almacén

• ultima_actualizacion_el → VARCHAR(255) → Fecha de última actualización

• ultima_actualizacion_por → VARCHAR(255) → Usuario que realizó la última actualización

• estado_de_orden → VARCHAR(255) → Estado de la orden (devuelto de API externa `buscar-estados-guia`)

• usuario_creatransferencia → VARCHAR(255) → Nombre completo del usuario que creó la transferencia

• created_date → DATETIME → Fecha de inserción en el datawarehouse

• status → tinyint(4) → Estado de la carga (1 = OK, 0 = error)

• Ordenamiento por defecto: No se especifica

7) Frecuencia y operación

• Frecuencia de actualización: Probablemente mensual( Por Cron)

• Ventana que recalcula (días/meses):  Calcula en un rango de 8 meses consecutivos tomando el 1mer y ultimo dia de cada mes.

• Tamaño de lote / paginado (chunking): Los inserts se hacen en lotes de 900 registros máximo.

• Tolerancia a fallos / reintentos: try catch para la inserción de datos.

• Tiempos de ejecución esperados: Dependerá de la cantidad de datos.

8) Calidad y controles

• Validaciones previas/post: 

• Previas:

• Se valida que $fecha_inicio y $fecha_fin existan, de lo contrario retorna un mensaje de error

• Se controla la existencia de la tabla con verifyExistTable() antes de insertar los datos

• Se encapsula la inserción de datos en transacciones con beginTransaction(), commit(), rollBack()

• Post:

• Si hay error en la consulta HTTP ($guzzle->request), se atrapa con catch (\Exception $e) y se retorna un mensaje claro.

• En caso de error de base de datos (catch (\PDOException $e)), se registra en la tabla emp_reportes_validation y se hace rollBack() para no dejar datos inconsistentes

• Controles de duplicados: Indirecta

• Creación de Tablas por sufijo

• Se usa CREATE TABLE {$db_name} LIKE report_nota_entrega; → las tablas nuevas se generan limpias
  
  

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

• error_reports → cuando falla la creación de tablas.

• emp_reportes_validation → cuando ocurre un error de inserción en la carga de datos.

• Cada registro de ejecución guarda report, first_date, second_date, created_date, y status, lo cual permite monitorear

9) Dependencias externas

ERPNext – CAPACITACION

• APIs / servicios y endpoints: method/send-query-database

• Autenticación / headers: Se envían headers básicos: 

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• No aparece un Authorization: Bearer <token> ni otra forma de autenticación explícita.
  
  

• Mapeos y contratos de datos:

• Entrada: filtros por fecha_ini, fecha_fin.

• Transformación: mapeo SQL → PHP arrays.

• Persistencia: creación de tablas dinámicas en MySQL con tipos definidos.

• Salida: array estructurado con campos enriquecidos (usuario_creatransferencia, estado_de_orden).

10) Historial de cambios

2025-09-22 13:58 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE SOLICITUD DE PAGOS

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

1) Nombre del reporte

• Nombre: Reporte Solicitud de Pagos

• Código / Alias: report_solicitud_de_pagos

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecha_inicio

• fecha_fin

• Tipo de rango (diario / mensual / personalizado): Mensual

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: ERP CDTALLERES

• Tabla / Recurso: tabSolicitud de Pagos

• Alias (si aplica): sp

• Campos utilizados (clave → descripción):

• name → Identificador de registro

• estado_de_validación →Estado de la solicitud

• validador → Select con opciones de que área o cómo fue validado

• concepto → Registro de “Concepto de solicitudes de pago”

• tipo_de_documento →  Registro de “Tipo de Documento SP”

• sucursal → Registro de “Sucursales”

• departamento → Registro de “Departamento”

• estado_documento →Estado del documento 

• fecha → Fecha de creación del registro

• ruc → Documento de identidad del proveedor

• proveedor → Nombre completo del proveedor

• porcentaje_de_detraccion → Porcentaje de detracción.

• cantidad_de_kilos → Cantidad de kilos

• n_serie - Número de Serie

• tipo_de_solicitud → Por Servicio o Producto

• number_factura → Número de documento Comprobante

• n_serie → Numero serie

• fecha_fac → Fecha emisión factura

• monto_a_pagar → Monto a pagar

• costo_x_kilo → Costo por Kilo

• monto → Monto solicitado 

• monto_facturado – Monto Facturado 

• currency →Tipo de Moneda

• fecha_de_pago →Fecha de pago

• zona → Zona (Datos del cleinte)

• banco → Banco (Select)

• factura_de_compra  → Registro de factura de compra

• tipo_de_cuenta_soles → Tipo de cuenta en soles

• cuenta_en_dólares  → Número de cuenta Dólares

• placa_de_vehiculo → Placa

• banco_dólares →Tipo de Banco Dolares

• idx → Gatos de construccion

• usuario_que_registro_el_pago → usuario que registra el pago

• orden_de_compra → Registro de orden de compra

• solicitud_con_detraccion → checkbox que se marca si la solicitud tiene detraccion

• cuenta_en_soles →Número de cuenta en soles

• banco_soles →Tipo de Banco en soles

• tipo_de_cuenta_dólares → Número de cuenta a depositar

• owner →Usuario que creó el registro

• creation →Fecha y hora de creación del registro

• modified_by →Usuario Administrador

• modified →Fecha y hora

• Condiciones (WHERE) aplicadas:Trae los registro cuya fecha de creación esté en el rango de fecha inicio y fecha fin.

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

• Observaciones (ej. particiones, índices): Sin Obs

3.2 Conexión / Base: ERP CAPACITACION

• Tabla / Recurso: tabSolicitud de Pagos

• Alias (si aplica): sp

• Campos utilizados (clave → descripción):

• name → Identificador de registro

• estado_de_validación →Estado de la solicitud

• validador → Select con opciones de que área o cómo fue validado

• concepto → Registro de “Concepto de solicitudes de pago”

• tipo_de_documento →  Registro de “Tipo de Documento SP”

• sucursal → Registro de “Sucursales”

• departamento → Registro de “Departamento”

• estado_documento →Estado del documento 

• fecha → Fecha de creación del registro

• ruc → Documento de identidad del proveedor

• proveedor → Nombre completo del proveedor

• porcentaje_de_detraccion → Porcentaje de detracción.

• cantidad_de_kilos → Cantidad de kilos

• n_serie - Número de Serie

• tipo_de_solicitud → Por Servicio o Producto

• number_factura → Número de documento Comprobante

• n_serie → Numero serie

• fecha_fac → Fecha emisión factura

• monto_a_pagar → Monto a pagar

• costo_x_kilo → Costo por Kilo

• monto → Monto solicitado 

• monto_facturado – Monto Facturado 

• currency →Tipo de Moneda

• fecha_de_pago →Fecha de pago

• zona → Zona (Datos del cleinte)

• banco → Banco (Select)

• factura_de_compra  → Registro de factura de compra

• tipo_de_cuenta_soles → Tipo de cuenta en soles

• cuenta_en_dólares  → Número de cuenta Dólares

• placa_de_vehiculo → Placa

• banco_dólares →Tipo de Banco Dolares

• idx → Gatos de construccion

• usuario_que_registro_el_pago → usuario que registra el pago

• orden_de_compra → Registro de orden de compra

• solicitud_con_detraccion → checkbox que se marca si la solicitud tiene detraccion

• cuenta_en_soles →Número de cuenta en soles

• banco_soles →Tipo de Banco en soles

• tipo_de_cuenta_dólares → Número de cuenta a depositar

• owner →Usuario que creó el registro

• creation →Fecha y hora de creación del registro

• modified_by →Usuario Administrador

• modified →Fecha y hora

• Condiciones (WHERE) aplicadas:Trae los registro cuya fecha de creación esté en el rango de fecha inicio y fecha fin.

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

• Observaciones (ej. particiones, índices): Sin Obs

4) Filtros globales del reporte

• Inclusiones (must-have): 

• La consulta de los campos que se encuentran en el punto 3. Sin estos datos la consulta esperada no devuelve los datos para el reporte.
  
  

• Exclusiones (reglas de descarte):

• Si el usuario no ingresa la Fecha de inicio y Fecha fin se descarta todo el reporte.

• Si la tabla no se crea correctamente se descarta el rango del registro.
  
  

• Reglas por estado / habilitado: 

• En baseReport cada ejecución guarda un log con estado:

• “statuts” => 1 //Exitoso 

• “statuts” => 0 //Error
  
  

• Parámetros externos (si el usuario puede filtrarlo): Si el usuario puede indicar la fecha de inicio y fecha fin.

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado: En baseReport se guarda logs con estados 0 = error y 1 = exitoso

• Reglas de validación (p.ej., sólo registros validados): Si no se especifica el rango de fecha no se ejecuta el servicio.

• Reglas condicionales (si X entonces Y):  Si dateUnlimited == "12", se generan rangos mes a mes desde 2023-09-01.

6) Estructura de salida

• Tabla/archivo destino: report_solicitud_de_pagos

• Particionado / sufijo: no aplica

• Clave(s) primaria(s) o únicas: no especifica

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

• id → INT AUTO_INCREMENT PRIMARY KEY → Identificador único de la fila

• name → VARCHAR(50) → Nombre o identificador

• estado_de_validación → VARCHAR(100) → Estado de validación del documento

• validador → VARCHAR(100) → Usuario que validó

• concepto → VARCHAR(255) → Concepto asociado al documento

• tipo_de_documento → VARCHAR(100) → Tipo de documento

• sucursal → VARCHAR(100) → Sucursal asociada

• departamento → VARCHAR(100) → Departamento asociado

• estado_documento → VARCHAR(100) → Estado actual del documento

• fecha → VARCHAR(100) → Fecha del documento

• ruc → VARCHAR(100) → Número de RUC del proveedor

• proveedor → VARCHAR(255) → Nombre del proveedor

• porcentaje → VARCHAR(20) → Porcentaje aplicado

• cantidad_de_kilos → VARCHAR(20) → Cantidad de kilos

• n_serie → VARCHAR(20) → Número de serie

• tipo_de_solicitud → VARCHAR(100) → Tipo de solicitud

• numero_documento → VARCHAR(100) → Número del documento

• fecha_emision_factura → VARCHAR(100) → Fecha de emisión de la factura

• monto_a_pagar → VARCHAR(100) → Monto a pagar

• costo_x_kilo → VARCHAR(100) → Costo por kilo

• monto → VARCHAR(100) → Monto total

• monto_facturado → VARCHAR(100) → Monto facturado

• currency → VARCHAR(100) → Moneda de la transacción

• fecha_de_pago → VARCHAR(20) → Fecha de pago

• zona → VARCHAR(100) → Zona geográfica

• banco → VARCHAR(150) → Banco asociado

• factura_de_compra → VARCHAR(150) → Número de factura de compra

• tipo_de_cuenta_soles → VARCHAR(150) → Tipo de cuenta en soles

• cuenta_en_dólares → VARCHAR(150) → Número de cuenta en dólares

• banco_dólares → VARCHAR(150) → Banco asociado a la cuenta en dólares

• idx → VARCHAR(25) → Índice o identificador auxiliar

• usuario_que_registro_el_pago → VARCHAR(100) → Usuario que registró el pago

• orden_de_compra → VARCHAR(100) → Número de orden de compra

• solicitud_con_detraccion → VARCHAR(20) → Indicador de solicitud con detracción

• cuenta_en_soles → VARCHAR(200) → Número de cuenta en soles

• banco_soles → VARCHAR(20) → Banco asociado a la cuenta en soles

• tipo_de_cuenta_dólares → VARCHAR(100) → Tipo de cuenta en dólares

• owner → VARCHAR(100) → Usuario creador del registro

• creation → VARCHAR(100) → Fecha de creación del registro

• modified_by → VARCHAR(100) → Usuario que modificó

• modified → VARCHAR(100) → Fecha de modificación

• placa_de_vehiculo → VARCHAR(100) → Placa del vehículo asociado

• created_date → DATETIME DEFAULT CURRENT_TIMESTAMP → Fecha de inserción en el datawarehouse

• status → tinyint(4) DEFAULT '1' → Estado del registro (1 = activo, 0 = inactivo)

• Ordenamiento por defecto: no especifica

7) Frecuencia y operación

• Frecuencia de actualización: Cada que se ejecuta el servicio

• Ventana que recalcula (días/meses): recalcula desde un pivote (2023-09) hasta mes actual → ~12+ meses.

• Tamaño de lote / paginado (chunking):  Los inserts se hacen en lotes de 900 registros máximo.

• Tolerancia a fallos / reintentos: try catch para la inserción de datos.

• Tiempos de ejecución esperados: Dependerá de la cantidad de datos.

8) Calidad y controles

• Validaciones previas/post: Se valida que se ingrese una fecha inicio y una fin para el rango de registros a filtrar

• Controles de duplicados: No existe un control explícito. Lo que sí hay es creación de tablas dinámicas con fecha por mes de registro.

 

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

• Se monitorea la inserción de datos en la tabla. En caso no se inserte correctamente, se guarda un log en la tabla error_reports, emp_reportes_validation.

• Se crea un log con estado (1 = exitoso  ó  0 = error) Que confirma el estado de la creación de la tabla.

9) Dependencias externas

9.1 RECURSOS HUMANOS

• APIs / servicios y endpoints:  

•  API: RECURSOS_HUMANOS = https://qahorario-salida.shalomcontrol.com/

• Servicio: Solicitud de Pagos

• Endpoint: api/getSolicitudPagos

9.2 APICDTALLERES

• APIs / servicios y endpoints:  

•  API: APICDTALLERES  = https://erp-cd-talleres-qa-21-02-2025.shalom.com.pe/

• Servicio: Ejecuta consultas SQL (tabSolicitud de Pagos)

• Endpoint: method/send-query-database

9.3 APICAPACITACION

• APIs / servicios y endpoints:  

•  API: APICAPACITACION = https://erp-git-prod.shalom.com.pe/api/

• Servicio:  Ejecuta consultas SQL (tabSolicitud de Pagos)

• Endpoint: method/send-query-database

• Autenticación / headers:

• Se define el siguiente header:

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• Mapeos y contratos de datos:

• Mapeo: En el punto 6 se ve el mapeo de datos, como llega del API y como se guarda en la BD:

• ejm: "name" => "VARCHAR(50) NULL, ",

• Contrato de datos: El API debe  entregar todos los campos indicados en el punto 6.

10) Historial de cambios

2025-09-23 10:58 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE MANTENIMIENTO TERCEROS

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

1) Nombre del reporte

• Nombre: Reporte Mantenimiento Tercero

• Código / Alias: report-mante-tercero

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecha_inicio

• fecha_fin

• Tipo de rango (diario / mensual / personalizado): Mensual

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

• Zona horaria: La del Servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: API CDTALLERES

• Tabla / Recurso: tabMantenimiento de Terceros

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• estado_flujo → Estado del documento

• name  → Identificador del registro 

• docstatus  → Estado interno de Frappe

• cliente → Tipo de cliente (Registros de Costumer)

• numero_placa  → Placa relacionada al Registro de Vehículo 

• flota → Tipo dato, Dato relacionado al registro de Vehículo

• nombre_del_usuario  → Nombre del proveedor

• costo_final  → Monto total de los productos o servicios del mantenimiento

• fecha_de_registro  → Fecha de creación del registro

• creation →Fecha y hora de creación del registro

• Condiciones (WHERE) aplicadas: Filtra los registro dentro del rango establecido en fecha_inicio y fecha_fin
  
  

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

• Observaciones (ej. particiones, índices): sin obs

 

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Ingreso de fecha_inicio y fecha_fin

• La consulta de los campos de la tabla tabMantenimiento de Terceros

• Exclusiones (reglas de descarte): Registros fuera del rango de fecha.

• Reglas por estado / habilitado: No aplica

• Parámetros externos (si el usuario puede filtrarlo): Aplica con fecha_inicio y fecha_fin

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado: En baseReport se guarda logs con estados 0 = error y 1 = exitoso

• Reglas de validación (p.ej., sólo registros validados): Si no se especifica el rango de fecha no se ejecuta el servicio.

• Reglas condicionales (si X entonces Y): no aplica

6) Estructura de salida

• Tabla/archivo destino: report-mante-tercero

• Particionado / sufijo: no aplica

• Clave(s) primaria(s) o únicas: no aplica

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

• id → INT AUTO_INCREMENT PRIMARY KEY → Identificador único de la fila

• name → VARCHAR(50) → Nombre o identificador

• estado_flujo → VARCHAR(100) → Estado del flujo del documento

• docstatus → VARCHAR(5) → Estado del documento (ej. 0 = Borrador, 1 = Enviado, 2 = Cancelado)

• cliente → VARCHAR(100) → Nombre o código del cliente

• numero_placa → VARCHAR(50) → Número de placa del vehículo

• flota → VARCHAR(50) → Flota a la que pertenece

• nombre_del_usuario → VARCHAR(255) → Nombre completo del usuario

• costo_final → VARCHAR(50) → Costo final registrado

• fecha_de_registro → VARCHAR(50) → Fecha de registro

• creation → VARCHAR(50) → Fecha de creación del registro

• created_date → DATETIME DEFAULT CURRENT_TIMESTAMP → Fecha de inserción en el datawarehouse

• status → tinyint(4) DEFAULT '1' → Estado del registro (1 = activo, 0 = inactivo)

• Ordenamiento por defecto: no aplica

7) Frecuencia y operación

• Frecuencia de actualización: Cada que se ejecuta el servicio

• Ventana que recalcula (días/meses): no aplica

• Tamaño de lote / paginado (chunking):  Los inserts se hacen en lotes de 900 registros máximo.

• Tolerancia a fallos / reintentos: try catch para la inserción de datos.

• Tiempos de ejecución esperados: Dependerá de la cantidad de datos.

8) Calidad y controles

• Validaciones previas/post: Se valida el ingreso de la fecha_inicio y fecha_fin

• Controles de duplicados: no aplica

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

• Se monitorea la inserción de datos en la tabla. En caso no se inserte correctamente, se guarda un log en la tabla error_reports, emp_reportes_validation.

• Se crea un log con estado (1 = exitoso  ó  0 = error) Que confirma el estado de la creación de la tabla.

9) Dependencias externas

• APIs / servicios y endpoints: APICDTALLERES

• API: APICDTALLERES = https://erp-cd-talleres-qa-21-02-2025.shalom.com.pe/api/

• Servicio: Consulta de Campos(tabMantenimiento de Terceros)

• endpoin: method/send-query-database

• Autenticación / headers: Se define el siguiente header:

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• Mapeos y contratos de datos: 

• Mapeo: En el punto 6 se ve el mapeo de datos, como llega del API y como se guarda en la BD:

• ejm: "name" => "VARCHAR(50) NULL, ",

• Contrato de datos: El API debe  entregar todos los campos indicados en el punto 6.

10) Historial de cambios

2025-09-23 11:55 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE NOTA DE ENTREGA

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

1) Nombre del reporte

• Nombre: Reporte Nota de Entrega

• Código / Alias: report_nota_entrega

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• fecha_inicio

• fecha_fin

• Tipo de rango (diario / mensual / personalizado):  Mensual

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

• Zona horaria: La del servidor 

3) Origen de datos (tablas/APIs)

• Conexión / Base: APICDTALLERES

• Tabla / Recurso: tabDelivery Note

• Alias (si aplica): del

• Campos utilizados (clave → descripción):

• name → Identificador del registro

• customer →Cliente

• status → Estados del registro

• currency → Tipo de Moneda

• lr_date → Fecha

• item_code  → Código de producto

• item_name → Nombre del producto

• qty → Cantidad relacionada al producto

• rate → Precio PEN

• amount → Importe PEN

• vehiculo → Placa vehículo

• Condiciones (WHERE) aplicadas: Filtra registros que tenga posting_date (fecha de creación) dentro del rango establecido (fecha_inicio y fecha_fin)

• Tipo de unión con otras fuentes (JOIN y llave): El doctype Nota de entrega(tabDelivery Note as del) y su tabla hija(tabDelivery Note Item as itm) se unirán si del.name = itm.parent

• Observaciones (ej. particiones, índices): sin OBS

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Rango de fecha (fecha_inicio, fecha_fin)

• Consulta de SQL a los campos de las tablas: tabDelivery Note y tabDelivery Note Item

• Respuesta de la API

• Exclusiones (reglas de descarte):

• Se descartan registros con fecha de creación, fuera del rango de fecha establecido(fecha_inicio, fecha_fin)
  
  

• Reglas por estado / habilitado: No aplica

• Parámetros externos (si el usuario puede filtrarlo): Aplica con fecha_inicio y fecha_fin

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado: En baseReport se guarda logs con estados 0 = error y 1 = exitoso

• Reglas de validación (p.ej., sólo registros validados): Si no se especifica el rango de fecha no se ejecuta el servicio.

• Reglas condicionales (si X entonces Y): no aplica

6) Estructura de salida

• Tabla/archivo destino:  report_nota_entrega

• Particionado / sufijo: no aplica

• Clave(s) primaria(s) o únicas: no aplica

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

• id → INT AUTO_INCREMENT PRIMARY KEY → Identificador único de la fila

• name → VARCHAR(50) → Nombre o identificador

• customer → VARCHAR(200) → Nombre o código del cliente

• estado → VARCHAR(50) → Estado del documento o registro

• currency → VARCHAR(50) → Moneda utilizada en la transacción

• lr_date → VARCHAR(50) → Fecha de la guía o documento relacionado

• item_code → VARCHAR(255) → Código del ítem

• item_name → VARCHAR(255) → Nombre del ítem

• qty → VARCHAR(10) → Cantidad

• rate → VARCHAR(10) → Tarifa o precio unitario

• amount → VARCHAR(10) → Importe total

• vehiculo → VARCHAR(10) → Identificador o referencia del vehículo

• periodo → VARCHAR(10) → Período asociado

• created_date → DATETIME DEFAULT CURRENT_TIMESTAMP → Fecha de inserción en el datawarehouse

• status → tinyint(4) DEFAULT '1' → Estado del registro (1 = activo, 0 = inactivo)

• Ordenamiento por defecto: no aplica

7) Frecuencia y operación

• Frecuencia de actualización: Cada que se ejecuta el servicio

• Ventana que recalcula (días/meses): no aplica

• Tamaño de lote / paginado (chunking):  Los inserts se hacen en lotes de 900 registros máximo.

• Tolerancia a fallos / reintentos: try catch para la inserción de datos.

• Tiempos de ejecución esperados: Dependerá de la cantidad de datos.

8) Calidad y controles

• Validaciones previas/post: Se valida el ingreso de la fecha_inicio y fecha_fin

• Controles de duplicados: no aplica

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

• Se monitorea la inserción de datos en la tabla. En caso no se inserte correctamente, se guarda un log en la tabla error_reports, emp_reportes_validation.

• Se crea un log con estado (1 = exitoso  ó  0 = error) Que confirma el estado de la creación de la tabla.

9) Dependencias externas

• APIs / servicios y endpoints: APICDTALLERES

• API: APICDTALLERES = https://erp-cd-talleres-qa-21-02-2025.shalom.com.pe/api/

• Servicio: Consulta de Campos(tabDelivery Note)

• endpoin: method/send-query-database
  
  

• Autenticación / headers: Se define el siguiente header:

• $options = [

•    'headers' => [

•        "Accept" => "application/json",

•        "Content-Type" => "application/json"

•    ]

• ];

• Mapeos y contratos de datos: 

• Mapeo: En el punto 6 se ve el mapeo de datos, como llega del API y como se guarda en la BD:

• ejm: "name" => "VARCHAR(50) NULL, ",

• Contrato de datos: El API debe  entregar todos los campos indicados en el punto 6.

10) Historial de cambios

2025-09-23 13:48 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE DE MONITOREO

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

1) Nombre del reporte

• Nombre: Reporte de Monitoreo

• Código / Alias: report_monitoreo_

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• first_date

• second_date

• Tipo de rango (diario / mensual / personalizado): Mensual

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: Empresarial

• Tabla / Recurso: emp_reportes_validation

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• report → nombre de la tabla

• first_date →Fecha inicio

• second_date →Fecha Fin

• created_date → Fecha y hora de creacion

• status → Estado
  
  

• Condiciones (WHERE) aplicadas: no aplica

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

• Observaciones (ej. particiones, índices):

• Tablas particionadas por año y mes: report_monitoreo_YYYY_MM

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Generar el rango de fecha con la función obtainRangeDaysByYear

• Registro en la tabla de validación emp_reportes_validation con estado (status = 1 o status = 0).

• Manejo de transacciones: beginTransaction, commit, rollBack

• Exclusiones (reglas de descarte): 

• Si la tabla dinámica no existe se detiene el update y ya no hace truncate

• Si no hay parámetros de fecha se corta la ejecución y se regresa un error
  
  

• Reglas por estado / habilitado:

• Si show(...) fue exitoso → se registra con status = 1.

• Si falla o lanza excepción → se registra con status = 0.
  
  

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

• $table → parámetro de entrada en truncate_bd(), permite definir qué tabla se limpia.

• Fechas derivadas del sistema (date("Y-m-d")) → afectan $year, $last_month, $first_month, por ende, los rangos de trabajo.

• Los rangos calculados ($first_date, $second_date) son dinámicos, dependen de la fecha actual.

5) Transformaciones y Reglas de negocio

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

• $first_month → derivado de $last_month.

• Si es enero o febrero, siempre vale 1.

• Si no, se calcula como el mes anterior al actual.

• $obtain_ranges → derivado de obtainRangeDaysByYear(), que devuelve un rango de fechas según $year, $last_month y $first_month.

• $table → derivado de la fecha inicial ($first_date) → "report_monitoreo_" . date("Y_m", strtotime($first_date)).

• $body["created_date"] → derivado con date("Y-m-d H:i:s").

• Mapeos de estado: En $body["status"] se mapea el resultado de la transacción:

• 1 → si el bloque try ejecuta correctamente.

• 0 → si ocurre una excepción y se hace rollBack().
  
  

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

• Antes de truncar la tabla, se valida si la tabla existe.

• También hay una validación en el try catch solo se continúa si el reporte fue generado exitosamente.
  
  

• Reglas condicionales (si X entonces Y):

• Condicional en la derivación de mes inicial:

• Si el mes es enero o febrero → $first_month = 1.

• Si no → $first_month = mes anterior.
  
  

• Condicional de rangos adicionales:

• Si el mes es enero o febrero → se agregan también los rangos de diciembre del año anterior:

• Condicional de commit/rollback:

• Si no hay error en la ejecución → se hace commit() y status = 1.

• Si hay error → rollback() y status = 0

6) Estructura de salida

• Tabla/archivo destino: report_monitoreo_ AÑO_MES (Tabla Dinamica)

• Particionado / sufijo: AAAA_MM de la tabla

• Clave(s) primaria(s) o únicas: no aplica

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

• report → VARCHAR → Nombre del reporte  

• first_date → DATE → Fecha de inicio del rango

• second_date → DATE → Fecha de fin del rango

• created_date → DATETIME → Fecha de ejecución/creación del registro de validación

• status → TINYINT → Estado de la operación (1 = éxito, 0 = falla)

• Ordenamiento por defecto: No se especifica ORDER BY

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 

• Si el mes en que se ejecuta es Enero o Febrero. Recalcula la fecha y abarca Todo Diciembre del año pasado y Todo Enero del año actual. 

• En otros meses, toma el mes anterior → mes actual.
  
  

• Tamaño de lote / paginado (chunking): No aplica paginado por cantidad de registros. Procesa los registros por mes(La cantidad de registros en un mes lo considera un lote).
  
  

• Tolerancia a fallos / reintentos: 

• En caso de errores se inserta un registro en emp_reportes_validation con status = 0
  
  

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

 

8) Calidad y controles

• Validaciones previas/post:

• Previas:

• Antes de insertar los datos en la tabla dinámica, se verifica si la tabla existe. Si existe, limpia los datos de la tabla.

• Post: 

• Se guarda un registro en la tabla emp_reportes_validation con los siguientes datos: 

• Nombre del reporte

• Fechas de inicio y fin

• Estado (status = 1 si OK, 0 si falló)

• Fecha de creación
  
  

• Controles de duplicados: No hay una validación de duplicados, pero lo que sí hay es una creación de tablas dinámicas. ejm: report_monitoreo_2025_09

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

• Se monitorea si la ejecución fue exitosa insertando datos en la tabla emp_reportes_validation con status (1 = éxito, 0 = error)

• También se guarda la ventana temporal para medir la cobertura temporal(que meses fueron procesados)

9) Dependencias externas

• APIs / servicios y endpoints: No aplica. Se procesa con métodos internos, no existe endpoint.

• Autenticación / headers: No aplica.

• Mapeos y contratos de datos:  Cada que se ejecuta el reporte se inserta los siguientes datos en la tabla emp_reportes_validation:

• report → STRING → Nombre del reporte

• first_date → DATE → Fecha de inicio

• second_date → DATE → Fecha de fin

• created_date → DATETIME → Fecha de ejecución

• status → TINYINT → Estado de la operación (1 = éxito, 0 = error)

10) Historial de cambios

2025-09-24 10:56 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE ESCALAS

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

1) Nombre del reporte

• Nombre: Reporte Escalas

• Código / Alias: report_escalas

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• first_date

• second_date

• Tipo de rango (diario / mensual / personalizado): Mensual

• Inclusión de horas (sí/no). Si 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_cargprogramado

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• cap_id → ID de carguero programado

• cap_chofer1id →ID del primer chofer del carguero programado

• cap_chofer2id →ID del segundo chofer del carguero programado

• cap_rutacarguero → Ruta del carguero programado

• cap_cargid  →  ID del carguero

• Condiciones (WHERE) aplicadas: no aplica

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

• Observaciones (ej. particiones, índices):

• Tablas particionadas por año y mes: report_monitoreo_YYYY_MM

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_reportes_validation

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• report → nombre de la tabla

• first_date →Fecha inicio

• second_date →Fecha Fin

• created_date → Fecha y hora de creacion

• status → Estado

• Condiciones (WHERE) aplicadas: no aplica

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

• Observaciones (ej. particiones, índices):

• Tablas particionadas por año y mes: report_monitoreo_YYYY_MM

4) Filtros globales del reporte

• Inclusiones (must-have):   

• En el método show() se construye obligatoriamente la data de programaciones, escalas, embarques, desembarques, retornos, etc.

• Los campos que se insertan en la tabla report_escalas_YYYY_MM son fijos y obligatorios (fecha, linea_tiempo, id_carguero, ruta, placa, etc.).

• Siempre se registra en la tabla de validación emp_reportes_validation con status = 1 (éxito) o status = 0 (falla).
  
  

• Exclusiones (reglas de descarte):

• Registros de programación de cargueros que tengan el campo “eliminado” con valor “0”.

• Reglas por estado / habilitado:

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

5) Transformaciones y Reglas de negocio

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

• km_acumulado → diferencia entre km_llegada y km_salida si es válido

• dur_emb y dur_desemb → calculados con DateTime->diff() entre fechas de embarque y desembarque.

• fecha, hora (salida/llegada, embarque, desembarque) → extraídos con explode sobre fh_*

• cantPaquetes, cantGuias → forzados a 0

• inicio_establecido, fin_establecido, dias_establecido → traídos de data_escalas
  
  

• Mapeos de estado:

• 0 = “Pendiente”

• 1 = “Proceso”

• 2 = “Completado” 

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

• La función programaciones() solo se traen registros que no hayan sido eliminados 

• ->where(“eliminados”, “0”)

• Solo se incluyen programaciones que tengan escalas activas 

• estado != 0
  
  

• Reglas condicionales (si X entonces Y):

• Si no existe tabla report_escalas_Y_m → se salta truncado.

• Si valesc no existe en escalas → se construye un objeto vacío con valores básicos.

• Si $escala["km_acumulado"] < 0 → se fuerza a vacío en lugar de un número negativo.

• Si estadoEscalaDelete == false → la programación no se agrega al JSON final.

• Si $valrel["estado"] cambia → el nombre del estado cambia (PENDIENTE, PROCESO, etc.).

6) Estructura de salida

• Tabla/archivo destino: report_escalas_AÑO_MES

• Particionado / sufijo: El particionado se logra mediante el sufijo año_mes (YYYY_MM) en el nombre de las tablas.

• Clave(s) primaria(s) o únicas: No especifica

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

• fecha → DATE → Fecha general del registro o salida

• linea_tiempo → STRING → Línea de tiempo asociada

• id_carguero → INT → Identificador del carguero

• fecha_salida_origen → DATE → Fecha de salida desde el origen

• hora_salida_origen → TIME → Hora de salida desde el origen

• fecha_llegada → DATE → Fecha de llegada

• hora_llegada → TIME → Hora de llegada

• fecha_salida → DATE → Fecha de salida

• hora_salida → TIME → Hora de salida

• ruta → STRING → Ruta asignada

• tipo_grupo → STRING → Tipo de grupo asociado

• placa → STRING → Placa del vehículo

• agencia → STRING → Nombre de la agencia

• km_acumulado → INT → Kilometraje acumulado

• km_llegada → INT → Kilometraje registrado a la llegada

• km_salida → INT → Kilometraje registrado a la salida

• fecha_inicio_emb → DATE → Fecha de inicio de embarque

• hora_inicio_emb → TIME → Hora de inicio de embarque

• fecha_fin_emb → DATE → Fecha de fin de embarque

• hora_fin_emb → TIME → Hora de fin de embarque

• duracion_emb → INT → Duración total del embarque (en horas/minutos)

• fecha_inicio_desemb → DATE → Fecha de inicio de desembarque

• hora_inicio_desemb → TIME → Hora de inicio de desembarque

• fecha_fin_desemb → DATE → Fecha de fin de desembarque

• hora_fin_desemb → TIME → Hora de fin de desembarque

• duracion_desemb → INT → Duración total del desembarque (en horas/minutos)

• estado → STRING → Estado actual de la escala

• inicio_establecido → DATE → Fecha de inicio establecida

• fin_establecido → DATE → Fecha de fin establecida

• dias_establecido → INT → Cantidad de días establecidos

• Ordenamiento por defecto: no se aplica

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses):  Recalcula desde el primer día al último día del mes. 

• Tamaño de lote / paginado (chunking):  Los datos insertados se procesan en lotes de 900 registros.

• Tolerancia a fallos / reintentos: Se guarda un log con estado 0 si hay errores y se ejecuta un rollback.

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

8) Calidad y controles

• Validaciones previas/post:

• Previas:

• Se valida si la tabla de destino existe con SHOW TABLES LIKE '{$table}'.

• Si existe, se hace un TRUNCATE antes de insertar datos nuevos.

• En programaciones() se filtra con whereBetween y eliminado = 0, y además se limpian los origenes y destinos dejando solo numéricos (array_filter + is_numeric).
  
  

• Post:

• En cada iteración se registra en la tabla emp_reportes_validation un log con status = 1 o 0, dependiendo de si el try/catch fue exitoso o falló.

• Al final, se retorna un ["status" => true] si se completó el flujo, o false si no hubo datos procesados.
  
  

• Controles de duplicados:

• Se usan array_unique y array_filter para evitar IDs repetidos en cargueros, retornos, escalas, etc.

• Se usa $data_unique para evitar procesar dos veces el mismo idcarguero.

• Se evita insertar orígenes/destinos repetidos con !in_array.

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

• cant_events inicializado en cada programación.

• km_acumulado, dur_emb, dur_desemb como métricas operativas.

• escalas_data y data_escalas para saber cuántos hitos de ruta se completaron.

• Validación de estados: PENDIENTE, PROCESO, COMPLETADO, OMITIDO.

• Fechas de embarque y desembarque (fh_emb_ini/fin, fh_desmb_ini/fin).

• En emp_reportes_validation se guarda status (1 éxito, 0 fallo).

9) Dependencias externas

• APIs / servicios y endpoints: No aplica

• Autenticación / headers: No aplica

• Mapeos y contratos de datos: 

• report      → nombre del reporte

• first_date  → fecha inicio del rango

• second_date → fecha fin del rango

• created_date→ timestamp del proceso

• status      → 0 o 1 (éxito o error)

10) Historial de cambios

2025-09-25 13:44 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE REQUERIMIENTO PERSONAL LIMA

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

1) Nombre del reporte

• Nombre: Reporte Requerimiento Personal Lima

• Código / Alias:   report_requerimiento_personal_lima_

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecha_de_requerimiento (Requerimiento de Personal Lima)

• creation (CV Filtrado)

• fecha_entrevista (Entrevista)

• fecha_inicio (Contrato de Trabajo)

• Tipo de rango (diario / mensual / personalizado): Mensual (se recalculan por mes con range_days)

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

• Zona horaria: La del servidor 

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: CAPACITACION

• Tabla / Recurso:
  method/erpnext.education.doctype.requerimiento_de_personal_lima.api.report

• Alias (si aplica): No aplica
  
  

• Campos utilizados (clave → descripción):

• name → Identificador de la solicitud

• fecha_de_requerimiento → Fecha de requerimiento

• _assign → Usuario asignado (reclutador)

• compromiso_cobertura → Fecha compromiso de cobertura

• documento_convocatoria → Documento de convocatoria

• puesto → Puesto solicitado

• estado_rp → Estado del requerimiento

• Condiciones (WHERE) aplicadas: fecha_de_requerimiento BETWEEN date_start AND date_end

• Tipo de unión con otras fuentes (JOIN y llave): Relación indirecta con CV Filtrado por campo documento_convocatoria

• Observaciones (ej. particiones, índices): Uso de alias en campo (posicion_solicitada AS puesto).

3.2 Conexión / Base: CAPACITACION

• Tabla / Recurso: CV Filtrado

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador de CV

• numero_documento → Documento del postulante

• nombre_solicitante → Nombre completo del postulante

• puesto_oportunidad → puesto (alias)

• oportunidad_empleo → Convocatoria vinculada

• creation → Fecha de registro del CV

• Condiciones (WHERE) aplicadas:oportunidad_empleo IN (documentos_convocatorias)
  
  

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

• Relación con Requerimiento de Personal Lima por documento_convocatoria.

• Relación con Entrevista por name (CV) → enlace_cv.

• Observaciones (ej. particiones, índices): Uso de alias en campo (puesto_oportunidad AS puesto).

3.3 Conexión / Base: CAPACITACION

• Tabla / Recurso: Entrevista

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador de entrevista

• fecha_entrevista → Fecha de la entrevista

• contratado → Estado de contratación (Sí/No)

• numero_de_documento → Documento del postulante

• puesto → Puesto ofertado

• enlace_cv → Relación con CV filtrado

• Condiciones (WHERE) aplicadas: enlace_cv IN (cv_filtrado_name)

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

• Relación con CV Filtrado por enlace_cv.

• Relación con Contrato de Trabajo por numero_de_documento.

• Observaciones (ej. particiones, índices): Se usa para validar si el postulante fue contratado.

3.4 Conexión / Base: CAPACITACION

Tabla / Recurso: Contrato de Trabajo

Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador de contrato

• fecha_inicio → Fecha de inicio del contrato

• labor → puesto (alias)

• dni → Documento del trabajador

• Condiciones (WHERE) aplicadas:

• dni IN (entrevista_documento)

• Tipo de unión con otras fuentes (JOIN y llave): Relación con Entrevista por dni.

• Observaciones (ej. particiones, índices): Uso de alias en campo (labor AS puesto).

4) Filtros globales del reporte

• Inclusiones (must-have):

• Rango de fecha (date_start, date_end).

• Consulta a tablas ERPNext: Requerimiento de Personal Lima, CV Filtrado, Entrevista, Contrato de Trabajo.

• Respuesta del API CAPACITACION.

• Exclusiones (reglas de descarte):

• Se descartan CVs con fecha de creación (creation) anterior a fecha_de_requerimiento.

• Reglas por estado / habilitado:

• Solo entrevistas con contratado = "Contratado" son consideradas para contratos.

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

• date_start

• date_end

5) Transformaciones y Reglas de negocio

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

• reclutador → se deriva de _assign parseado en JSON.

• f_reclutamiento → puede ser compromiso_cobertura o creation del CV.

• Mapeos de estado:

• estado_rp se mapea desde la tabla Requerimiento de Personal Lima.

• contratado se mapea desde la tabla Entrevista.

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

• Si no existe la tabla destino se inserta un error en error_reports.

• Validación de creación de tabla report_requerimiento_personal_lima_YYYY_MM.

• Reglas condicionales (si X entonces Y):

• Si no existe la tabla del mes actual → se crean hasta 12 meses atrás.

• Si no existen CVs → se guarda registro con documento, nombre_completo, entrevista y contrato en None.

• Si ocurre error → se inserta en emp_reportes_validation con status 0.

6) Estructura de salida

• Tabla/archivo destino: report_requerimiento_personal_lima_YYYY_MM

• Particionado / sufijo: report_requerimiento_personal_lima_YYYY_MM

• Clave(s) primaria(s) o únicas: No aplica

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

• rq_personal → VARCHAR(50) → ID del requerimiento de personal

• f_solicitud → DATE → Fecha de solicitud

• reclutador → VARCHAR(100) → Usuario asignado al requerimiento

• puesto → VARCHAR(100) → Puesto solicitado

• f_reclutamiento → DATETIME → Fecha compromiso de cobertura o creación del CV

• estado_rp → VARCHAR(50) → Estado del requerimiento

• documento → VARCHAR(50) → DNI del postulante

• nombre_completo → VARCHAR(255) → Nombre del postulante

• f_entrevista → DATE → Fecha de entrevista

• f_contrato → DATE → Fecha de inicio del contrato
  
  

• Ordenamiento por defecto: No se especifica ORDER BY
  
  

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Se recalcula desde el primer día al último día de cada mes.

• Tamaño de lote / paginado (chunking): Los datos se procesan en lotes de 900 registros.

• Tolerancia a fallos / reintentos: Los datos se procesan en lotes de 900 registros.

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

8) Calidad y controles

• Validaciones previas/post:

• Previas: Verificar existencia de tabla destino (exist_table_bd).

• Post: Registro en emp_reportes_validation con status=1 si es exitoso o status=0 si falla.

• Controles de duplicados: No aplica control de duplicados.

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

• Validación de estados de inserción en emp_reportes_validation (1 éxito, 0 fallo).

• Validación de existencia de tabla destino.

9) Dependencias externas

• APIs / servicios y endpoints:

• API: APICAPACITACION

• Servicio: Reporte Requerimiento de Personal Lima

• Endpoint: method/erpnext.education.doctype.requerimiento_de_personal_lima.api.report

• Autenticación / headers:  No se encontró.

• Mapeos y contratos de datos:

• Mapeo: Datos del API se insertan en tabla report_requerimiento_personal_lima_YYYY_MM.

• Contrato de datos: El API debe devolver los campos: name, fecha_de_requerimiento, _assign, compromiso_cobertura, documento_convocatoria, puesto, estado_rp.

10) Historial de cambios

2025-09-29 15:45 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE DOCUMENTO CHOFERES

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

1) Nombre del reporte

• Nombre: Reporte Documentos Choferes

• Código / Alias: report_documentos_Conductores

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• first_date

• second_date

• Tipo de rango (diario / mensual / personalizado):

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

• Zona horaria: la del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: TRANSPORTES

• Tabla / Recurso: tabDocumentos de Conductores

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):
  
  

• name → Identificador de registro

• docstatus → Estado del documento en ERPNext

• id_conductor → Identificador del conductor

• nombre_completo → Nombre completo del conductor

• dni → Documento nacional de identidad del conductor

• puesto → Puesto del conductor

• estado → Estado general del documento del conductor

• fecha_emision_documento → Fecha de emisión del documento

• fecha_vencimiento_documento → Fecha de vencimiento del documento

• fecha_emision_licencia → Fecha de emisión de la licencia

• fecha_vencimiento_licencia → Fecha de vencimiento de la licencia

• creation → Fecha y hora de creación del registro (campo del sistema ERPNext)
  
  

• Condiciones (WHERE) aplicadas: (creation <= fecha_end AND creation >= fecha_inicio) → Filtra registros cuya fecha de creación esté entre la fecha de inicio y la fecha fin.
  
  

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

• Observaciones (ej. particiones, índices): 

• En las tablas dinámicas creadas (report_documentos_Conductores_YYYY_MM) se agregan índices:

• status

• created_date
  
  

4) Filtros globales del reporte

• Inclusiones (must-have): Documentos con creation dentro del rango mensual

• Exclusiones (reglas de descarte): Implícito: fuera de rango temporal

• Reglas por estado / habilitado: Se insertan con status = 1 por defecto

• Parámetros externos (si el usuario puede filtrarlo): Si aplica first_date, second_date (rango de fechas)

5) Transformaciones y Reglas de negocio

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

• Nombre de tabla destino dinámico: "report_documentos_Conductores_" . date("Y_m", …)
  
  

• Mapeos de estado:

• status = 1 = exitoso

• status = 0 = error
  
  

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

• Verifica existencia de tabla con verifyExistTable

• Si no existe → se crea + índices

• Si existe → se trunca
  
  

• Reglas condicionales (si X entonces Y): Si creación de tabla falla → registro en error_reports

 

6) Estructura de salida

• Tabla/archivo destino: report_documentos_Conductores_YYYY_MM (dinámica por mes)

• Particionado / sufijo: Particionado por Año_Mes

• Clave(s) primaria(s) o únicas: id (AUTO_INCREMENT PRIMARY KEY)

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

• id → INT → PK autoincremental

• name → VARCHAR(250) → ID del documento

• docstatus → VARCHAR(250) → Estado ERPNext

• id_conductor → VARCHAR(250) → ID chofer

• nombre_completo → VARCHAR(250) → Nombre chofer

• dni → VARCHAR(250) → DNI chofer

• puesto → VARCHAR(250) → Puesto del chofer

• estado → VARCHAR(250) → Estado del documento/licencia

• fecha_emision_documento → VARCHAR(250) → Fecha emisión documento

• fecha_vencimiento_documento → VARCHAR(250) → Fecha vencimiento documento

• fecha_emision_licencia → VARCHAR(250) → Fecha emisión licencia

• fecha_vencimiento_licencia → VARCHAR(250) → Fecha vencimiento licencia

• created_date → DATETIME → Fecha de inserción

• status → tinyint(4) → Estado lógico (1 válido, 0 error)
  
  

• Ordenamiento por defecto: No explícito (depende de inserción, se recomienda created_date DESC)

7) Frecuencia y operación 

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

• Ventana que recalcula (días/meses): hasta 3 meses previos

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

• Tolerancia a fallos / reintentos: Manejo con try/catch, rollback si falla, inserta en error_reports

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

8) Calidad y controles

• Validaciones previas/post:

• verifyExistTable asegura estructura

• Validación de creación/alteración exitosa
  
  

• Controles de duplicados: No explícitos (solo truncado previo asegura no duplicar mes)
  
  

• Métricas de completitud (qué se monitorea): Validación en emp_reportes_validation con campo status

9) Dependencias externas

• APIs / servicios y endpoints:

• API: APITRANSPORTES 

• Servicio: Servicio DocumentoChoferes

• Endpoint:  "method/send-query-database"
  
  

• Autenticación / headers: No aplica
  
  

• Mapeos y contratos de datos:

• Entrada: filtros fecha_inicio, fecha_end

• Salida: JSON con lista de documentos de conductores

10) Historial de cambios

2025-09-30 11:03 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE VULNERACIONES FINANZAS

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

1) Nombre del reporte

• Nombre: Reporte Vulneraciones Finanzas

• Código / Alias: report_vulneraciones_finanzas_YYYY_MM (Tablas dinámicas)

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• cop_fechaemision

• cop_fhanulado 

• re_datesys 

• created_date 

• list_fecha 

• fecha_crea

• fecha
  
  

• Tipo de rango (diario / mensual / personalizado): Mensual (construido dinámicamente entre first_day y last_day por mes).
  
  

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

• Tabla / Recurso: emp_code_attemp

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Terminal

• user_attempt → Usuario

• fecha → Fecha (agrupada con DATE(fecha))

• id → Identificador único del intento (para conteo COUNT)

• Condiciones (WHERE) aplicadas: Registros cuya fecha esté entre first_date y second_date.

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

• Observaciones (ej. particiones, índices): Usa groupBy sobre ter_id, usuario y fecha.

3.2 Conexión / Base: CAPACITACION (API)

• Tabla / Recurso: Solicitud de Pagos (resource/Solicitud de Pagos)

• Alias (si aplica): sp

• Campos utilizados (clave → descripción):

• name → Identificador de registro

• id_de_sucursal → Sucursal asociada

• usuario_que_registro_el_pago → Usuario que registró el pago

• fecha → Fecha de creación del registro
  
  

• Condiciones (WHERE) aplicadas: 

• concepto = "Transacción / Compensaciones"

• fecha entre first_date y second_date

• docstatus != 2
  
  

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (se integra por lógica en código).

• Observaciones: Se limpia el campo usuario_que_registro_el_pago para remover @dominio.

3.3 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_cambio_precio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• usuariocambia → Usuario que realizó el cambio

• fecha → Fecha (agrupada con DATE(fecha))

• id → Identificador único (para conteo COUNT)

• Condiciones (WHERE) aplicadas: Registros cuya fecha esté entre first_date y second_date.

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

• Observaciones: Agrupado por usuario y fecha.
  
  

3.4 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Terminal

• ter_nombre → Nombre de la terminal

• Condiciones (WHERE) aplicadas: Ninguna (trae todos).

• Tipo de unión con otras fuentes (JOIN y llave): Se cruza lógicamente con Branch para asignar tipo (agente/concesionario).

• Observaciones: Se usa como catálogo para complementar datos de sucursal.

3.5 Conexión / Base: CAPACITACION (API)

• Tabla / Recurso: Branch (resource/Branch)

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ideentificador → Identificador de sucursal

• name → Nombre de la sucursal

• agente → Flag si es agente

• concesionario → Flag si es concesionario

• Condiciones (WHERE) aplicadas: Ninguna (se trae todo).

• Tipo de unión con otras fuentes (JOIN y llave): Relación lógica con emp_terminal.

• Observaciones: Se arma diccionario para marcar sucursales agente/concesionario.

3.6 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_usuario

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• usr_id → Identificador de usuario

• usr_terminalid → Terminal asignada al usuario

• usr_rol → Rol del usuario

• usr_alias → Alias o nombre corto

• Condiciones (WHERE) aplicadas: Usuarios incluidos en array_usuario_agencia.

• Tipo de unión con otras fuentes (JOIN y llave): Se cruza por usr_id con los usuarios recogidos en otras consultas.

• Observaciones: Completa información de detalle de usuario.

4) Filtros globales del reporte

• Inclusiones (must-have): Registros activos, notas de crédito, anulaciones, reimpresiones, intentos válidos.

• Exclusiones (reglas de descarte): status = 0 o eliminado = 1.

• Reglas por estado / habilitado: Considera cop_estado = 1, cop_estado_pago = 'AN', re_status = 0.

• Parámetros externos (si el usuario puede filtrarlo): Mes/año calculados dinámicamente.

5) Transformaciones y Reglas de negocio

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

• Conteo de operaciones por día y terminal (COUNT).

• Ajuste de reimpresiones (cantidad – 1).

• Acumulación en $nc_list[fecha][terminal][tipo].
  
  

• Mapeos de estado: Notas de crédito, reimpresiones QR, comprobantes anulados, caja eliminada, pinpad anulados, egresos anulados, intentos sesión, anulados store.

 

• Reglas condicionales (si X entonces Y): 

• Si la tabla no existe → CREATE TABLE.

• Si es nueva → ALTER TABLE con índices (fecha, created_date, status).

6) Estructura de salida

• Tabla/archivo destino: report_vulneraciones_finanzas_YYYY_MM (Tablas dinámicas)

• Particionado / sufijo: Por mes (YYYY_MM)

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

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

• fecha → DATE → fecha del registro o movimiento

• terminal → VARCHAR → identificador del terminal o punto de venta

• nota_credito → VARCHAR(20) → indicador si aplica nota de crédito

• reimpresion_qr → VARCHAR(20) → flag de reimpresión de código QR

• comprobantes_anulados → VARCHAR(20) → cantidad de comprobantes anulados

• eliminacion_caja_diaria → VARCHAR(20) → marca de eliminación en cierre de caja

• comprobantes_anulados_pinpad → VARCHAR(20) → comprobantes anulados en Pinpad

• intentos_session → VARCHAR(20) → número de intentos de sesión fallidos o registrados

• egresos_anulados → VARCHAR(20) → número de egresos anulados

• anulados_store → VARCHAR(20) → anulaciones registradas en la tienda

• created_date → DATETIME → fecha y hora de creación del registro

• status → TINYINT → estado del registro (activo/inactivo)

• Ordenamiento por defecto: no definido (se inserta en bulk).

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Últimos 2 meses + ajuste si enero/febrero.

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

• Tolerancia a fallos / reintentos: Manejo con try/catch → inserta en emp_reportes_validation con status = 0 si falla.

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

8) Calidad y controles

• Validaciones previas/post: 

• Verifica existencia de tabla antes de insertar.

• Aplica índices en creación.

• Controles de duplicados: Evita duplicados mediante groupBy y having.

• Métricas de completitud (qué se monitorea): Se monitorea en emp_reportes_validation.

9) Dependencias externas

• APIs / servicios y endpoints: ERPNext (APICAPACITACION).

• Endpoints: /resource/POS Invoice, /resource/Branch

• Autenticación / headers: No especificada (se asume token en ServiceErp).

• Mapeos y contratos de datos: Respuestas JSON → campos name, sucursal, ideentificador.

10) Historial de cambios

2025-09-30 17:33 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE VULNERACIONES FINANZAS 2

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

1) Nombre del reporte

• Nombre: Reporte Vulneraciones FInanzas 2

• Código / Alias:  report_vulneraciones_finanzas2_YYYY_MM

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: fecha (varios orígenes: emp_code_attemp.fecha, emp_cambio_precio.fecha, Solicitud de Pagos.fecha)

• Tipo de rango (diario / mensual / personalizado): Mensual (por año y mes, dinámico según fecha 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: CENTOS

• Tabla / Recurso: emp_code_attemp

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción): 

• ter_id → Terminal

• user_attempt → Usuario

• fecha → Fecha del intento

• id → Identificador único (usado en COUNT)
  
  

• Condiciones (WHERE) aplicadas: Rango de fechas entre fecha inicio y fecha fin.

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

• Observaciones (ej. particiones, índices): Se usa groupBy(ter_id, user_attempt, DATE(fecha)).

3.2 Conexión / Base: CAPACITACION

• Tabla / Recurso: Solicitud de Pagos (API → resource/Solicitud de Pagos)

• Alias (si aplica): sp

• Campos utilizados (clave → descripción):

• name → Identificador del registro

• id_de_sucursal → Sucursal asociada

• usuario_que_registro_el_pago → Usuario que registró el pago

• fecha → Fecha de registro

• Condiciones (WHERE) aplicadas:

• concepto = "Transacción / Compensaciones"

• fecha >= fecha_inicio

• fecha <= fecha_fin

• docstatus != 2

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (consulta directa a recurso vía API).

• Observaciones: usuario_que_registro_el_pago se limpia quitando el dominio (@xxx).

3.3 Conexión / Base: ERP EMPRESARIAL

• Tabla / Recurso: emp_cambio_precio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• usuariocambia → Usuario que realiza el cambio de precio

• fecha → Fecha del cambio

• id → Identificador único (usado en COUNT)

• Condiciones (WHERE) aplicadas: Rango de fechas entre fecha inicio y fecha fin.

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

• Observaciones: Se agrupa por usuario y fecha.

3.4 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador del terminal

• ter_nombre → Nombre del terminal

• Condiciones (WHERE) aplicadas: Ninguna.

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

• Observaciones: Sirve para enriquecer con nombre de terminal en los reportes.

3.5 Conexión / Base: CAPACITACION

• Tabla / Recurso: Branch (API → resource/Branch)

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ideentificador → ID de la sucursal

• name → Nombre de la sucursal

• agente → Indicador si es agente

• concesionario → Indicador si es concesionario

• Condiciones (WHERE) aplicadas: Ninguna (trae todos).

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

• Observaciones: Se usa para distinguir si la sucursal es agente o concesionario.

 

3.6 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_usuario

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• usr_terminalid → Terminal asignado al usuario

• usr_rol → Rol del usuario

• usr_id → Identificador del usuario

• usr_alias → Nombre o alias del usuario

• Condiciones (WHERE) aplicadas: usr_id IN (usuarios encontrados en las otras consultas).

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (pero conceptualmente enriquece con info de usuario).

• Observaciones: Se usa para obtener detalles adicionales del usuario que aparecen en el reporte final.

4) Filtros globales del reporte

• Inclusiones (must-have): Registros dentro de rango de fechas.

• Exclusiones (reglas de descarte): docstatus != 2 en Solicitud de Pagos.

• Reglas por estado / habilitado: Se guarda status = 1 (ok) o 0 (error).

• Parámetros externos (si el usuario puede filtrarlo): No expuestos al usuario (definidos internamente).

5) Transformaciones y Reglas de negocio

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

• usuario_que_registro_el_pago → antes del @ (si aplica).

• Mapeo de usuario ↔ terminal desde varias fuentes.

• Mapeos de estado:

• tipo = cambio_precio | compensaciones_transacciones | error_clave.

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

• Verifica existencia de tabla destino (verifyExistTable).

• Si no existe, se crea con índices (fecha, created_date, status).

• Reglas condicionales (si X entonces Y): Si usuario no está en array_usuario_agencia, se asignan valores vacíos.

 

6) Estructura de salida

• Tabla/archivo destino: report_vulneraciones_finanzas2_YYYY_MM

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

• Clave(s) primaria(s) o únicas: id (autoincrement).

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

• id → INT → PK autoincrement

• fecha → DATE → fecha de registro

• terminal → VARCHAR(20) → id terminal

• terminal_nombre → VARCHAR(255) → nombre terminal

• usuario → VARCHAR(255) → id usuario

• nombre_completo → VARCHAR(255) → alias

• cargo → VARCHAR(255) → rol usuario

• tipo → VARCHAR(255) → categoría del evento

• cantidad → VARCHAR(20) → ocurrencias

• created_date → DATETIME → fecha inserción

• status → tinyint(4) → 1=activo
  
  

• Ordenamiento por defecto: No explícito (se asume fecha).

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses):  Últimos 2–3 meses (dependiendo del mes actual).

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

• Tolerancia a fallos / reintentos: No especificado, pero registra en emp_reportes_validation.

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

8) Calidad y controles

• Validaciones previas/post:

• Validación de existencia de tabla.

• Inserción de estado en emp_reportes_validation.
  
  

• Controles de duplicados: Truncate si la tabla existe antes de insertar.

• Métricas de completitud (qué se monitorea): cantidad por usuario/terminal/fecha.

 

9) Dependencias externas

• APIs / servicios y endpoints:

• Apis: 

• APICAPACITACION/resource/Solicitud de Pagos

• APICAPACITACION/resource/Branch

• Autenticación / headers: Token fijo → token fc60669957e6bdc:b207d472e96c9df

• Mapeos y contratos de datos: Respuesta esperada con campo data

10) Historial de cambios

2025-09-30 18:13 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE INSPECCIONES

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

1) Nombre del reporte

• Nombre: Reporte de Inspecciones

• Código / Alias:  report_inspecciones_

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• fecha_guardar (ejecución de inspección)

• creation (fecha de registro en ERP)
  
  

• Tipo de rango (diario / mensual / personalizado): mensual (primer mes hasta último mes dinámico).

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

• Tabla / Recurso: tabBranch

• Alias (si aplica): brn

• Campos utilizados (clave → descripción):

• brn.name → Identificador de la sucursal

• brn.ideentificador → Código de la sucursal

• brn.zona_nacional → Zona nacional
  
  

• Condiciones (WHERE) aplicadas: ins.acceso = %(acceso)s

• Tipo de unión con otras fuentes (JOIN y llave):  LEFT JOIN tabInspeccion SSOMA ins ON brn.name = ins.parent

• Observaciones (ej. particiones, índices): Se filtra con filters = {"acceso": 1} en la API
  
  

3.2 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion de Primeros Auxilios

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspeccionado_por → Responsable de la inspección

• dct.nombre_del_responsable → Nombre del responsable

• dct.fecha → Fecha inspección (se usa como fecha_guardar)

• dct.agencia → Agencia vinculada

• dct.codigo → Registro

• min.correcto → Estado correcto/incorrecto

• dct.name → Identificador único

• dct.creation → Fecha de creación

• dct.week → Semana

• dct.realized → Estado de ejecución

• Condiciones (WHERE) aplicadas: dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabTabla de Resumen min ON dct.name = min.parent

• Observaciones (ej. particiones, índices): 

• Se construye campo mes = 01-mm-YYYY.

• Se normaliza tipo_de_inspeccion = "Inspeccion de Primeros Auxilios"

3.3 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion Equipos de Emergencia 

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspeccionado_por → Responsable de la inspección

• dct.nombre_del_responsable → Nombre del responsable

• dct.fecha → Fecha inspección (se usa como fecha_guardar)

• dct.agencia → Agencia vinculada

• dct.codigo → Registro

• min.correcto → Estado correcto/incorrecto

• dct.name → Identificador único

• dct.creation → Fecha de creación

• dct.week → Semana

• dct.realized → Estado de ejecución

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabTabla de Resumen min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "Inspeccion Equipos de Emergencia".

3.4 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion de Puerta Corrediza Electrica

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspector → Responsable de la inspección

• dct.nombre_del_responsable → Nombre del responsable

• dct.fecha → Fecha inspección (se usa como fecha_guardar)

• dct.agencia → Agencia vinculada

• dct.codigo → Registro

• min.correcto → Estado correcto/incorrecto

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabIInspeccion de Puerta Corrediza Electrica min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "Inspeccion de Puerta Corrediza Electrica".

3.5 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion de Apilador Electrico

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspector → Responsable de la inspección

• dct.nombre_del_responsable → Nombre del responsable

• dct.fecha → Fecha inspección (se usa como fecha_guardar)

• dct.agencia → Agencia vinculada

• dct.codigo → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion de Apilador Electrico min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "Inspeccion de Apilador Electrico".

3.6 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion de Apilador Hidraulico Manual

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspeccionado  → Responsable

• dct.nombre_del_responsable → Responsable asignado

• dct.fecha_guardar → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion de Apilador Hidraulico Manual min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspeccion de Apilador Hidraulico Manual".

3.7 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspecciones de Extintores

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspeccionado  → Responsable

• dct.nombre_del_responsable → Responsable asignado

• dct.fecha_guardar → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspecciones de Extintores min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspecciones de Extintores".

3.8 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion  de Orden y Limpieza

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.nombre_del_inspector  → Responsable

• dct.data_72 → Responsable asignado

• dct.guardar_fecha → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion  de Orden y Limpieza min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspeccion  de Orden y Limpieza".

3.9 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion del Grupo Electrogeno

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspector  → Responsable

• dct.nombre_del_responsable → Responsable asignado

• dct.fecha → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion del Grupo Electrogeno min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspeccion del Grupo Electrogeno".

3.10 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabUniformes y Epp

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspeccionado_por → Responsable

• dct.data_12 → Responsable asignado

• dct.fecha → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabUniformes y Epp min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabUniformes y Epp".

 

3.11 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion Carritos

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspector → Responsable

• dct.nombre_responsable → Responsable asignado

• dct.fecha → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion Carritos min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspeccion Carritos”

3.12 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion de Estocas

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspector → Responsable

• dct.nombre_responsable → Responsable asignado

• dct.fecha → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion de Estocas  min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspeccion de Estocas”

 

3.13 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion de Montacargas

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspector → Responsable

• dct.nombre_responsable → Responsable asignado

• dct.fecha → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion de Montacargas  min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspeccion de Montacargas”

3.14 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabInspeccion de Gabinete Contra Incendio

• Alias (si aplica): dct

• Campos utilizados (clave → descripción):

• dct.inspector → Responsable

• dct.nombre_responsable → Responsable asignado

• dct.fecha → Fecha de inspección

• dct.agencia → Agencia

• dct.codigo  → Registro

• min.correcto → Estado correcto/incorrecto
  
  

• Condiciones (WHERE): dct.creation >= %(fecha_ini)s and dct.creation<= %(fecha_fin)s

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabInspeccion de Gabinete Contra Incendio  min ON dct.name = min.parent

• Observaciones (ej. particiones, índices):  tipo_de_inspeccion = "tabInspeccion de Gabinete Contra Incendio”

4) Filtros globales del reporte

• Inclusiones (must-have): 

• acceso = 1 (Branch).

• Fechas por rango.
  
  

• Exclusiones (reglas de descarte):  registros sin realizado → marcados como VENCIDO o POR VENCER.
  
  

• Reglas por estado / habilitado: 

• status = 1 para válidos.

• status = 0 en validación de errores.
  
  

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

• Fechas (fecha_inicio, fecha_fin).

• Doctype y tabla resumen (dinámicos).

• IMPORTANTE: Si en el reporte aparecen columnas vacías y en la columna de inspecciones indica “NO” no significa que está fallando el reporte sino que para esa fecha no existe registro de inspección.
  
  Linea de codigo: 8539
  RUTA: /var/www/html/horario_salida/app/Http/Controllers/ERPNextController.php

5) Transformaciones y Reglas de negocio

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

• mes = 01-MM-YYYY desde creation.

• tipo_de_inspeccion = nombre de doctype.

• inspeccion_realizada = SI/NO según existencia.

• cumplimiento_inspeccion = 100% o 0%.

• semana_ejecutada = calculada desde fecha_guardar.

• porcentaje_levantamiento_observacion_anterior = observaciones_levantas / levantamiento_observacion_anterior

• Mapeos de estado: realizado = null/"" → POR VENCER o VENCIDO según semana vs día actual.
  
  

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

• Creación de tabla mensual con índices status, created_date.

• Inserción en emp_reportes_validation (control de ejecución).
  
  

• Reglas condicionales (si X entonces Y):

• Si no existe tabla → crear.

• Si existe → truncar y reinsertar.

• Si error → insertar en error_reports.

6) Estructura de salida

• Tabla/archivo destino: report_inspecciones_YYYY_MM

• Particionado / sufijo: por mes (sufijo YYYY_MM)

• Clave(s) primaria(s) o únicas: id (auto_increment).

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

• id → INT AUTO_INCREMENT PRIMARY KEY → Identificador único de la fila

• agencia → VARCHAR(255) → Nombre de la agencia

• name → VARCHAR(255) → Identificador del registro

• codigo → VARCHAR(255) → Código asociado

• zona → VARCHAR(255) → Zona geográfica

• responsable → VARCHAR(255) → Código o identificador del responsable

• nombre_del_responsable → VARCHAR(255) → Nombre completo del responsable

• fecha_guardar → VARCHAR(255) → Fecha registrada para guardar información

• registro → VARCHAR(255) → Registro asociado

• correcto → VARCHAR(10) → Indicador de validez o corrección

• parentfield → VARCHAR(255) → Campo padre asociado en la estructura

• creation → VARCHAR(255) → Fecha de creación del registro

• week → VARCHAR(255) → Semana registrada

• realizado → VARCHAR(255) → Indicador de ejecución realizada

• mes → VARCHAR(255) → Mes registrado

• tipo_de_inspeccion → VARCHAR(255) → Tipo de inspección

• inspeccion_realizada → VARCHAR(255) → Resultado de la inspección realizada

• cumplimiento_inspeccion → VARCHAR(255) → Nivel de cumplimiento de la inspección

• semana_programada_inspeccion → VARCHAR(255) → Semana programada de la inspección

• semana_ejecutada → VARCHAR(255) → Semana en la que se ejecutó la inspección

• observaciones_levantas → VARCHAR(10) → Indicador de observaciones levantadas

• levantamiento_observacion_anterior → VARCHAR(10) → Indicador de levantamiento de observaciones anteriores

• fecha_de_ejecucion → VARCHAR(255) → Fecha de ejecución de la inspección

• vencimiento → VARCHAR(255) → Fecha de vencimiento

• porcentaje_levantamiento_observacion_anterior → VARCHAR(255) → Porcentaje de levantamiento de observaciones anteriores

• created_date → DATETIME DEFAULT CURRENT_TIMESTAMP → Fecha de inserción en el datawarehouse

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

• Ordenamiento por defecto:  no explícito; implícito por created_date.

7) Frecuencia y operación

• Frecuencia de actualización: mensual (últimos 2–3 meses según lógica)

• Ventana que recalcula (días/meses): 2 meses atrás hasta mes actual.

• Tamaño de lote / paginado (chunking): comentado (array_chunk 900).

• Tolerancia a fallos / reintentos:  inserción en emp_reportes_validation con status=0.

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

8) Calidad y controles

• Validaciones previas/post: existencia de tabla (verifyExistTable).

• Post: índices en tabla (status, created_date).

• Controles de duplicados: agrupación por name (última inspección prevalece)

• Métricas de completitud (qué se monitorea):  validación en emp_reportes_validation

9) Dependencias externas

• APIs / servicios y endpoints:

• Apis: 

• RECURSOS_HUMANOS/api/getInspecciones/{fecha_ini}/{fecha_fin}.

• APICAPACITACION/method/send-query-database (ERP)

• Autenticación / headers: Headers fijos → Accept: application/json, Content-Type: application/json

• Mapeos y contratos de datos: JSON con inspecciones por agencia, zona, tipo de inspección

10) Historial de cambios

2025-10-01 11:53 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE MATRIZ CONDICIONES

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

1) Nombre del reporte

• Nombre: Reporte Matriz Condiciones

• Código / Alias:  report_matriz_condiciones_

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• first_date, second_date (calculados con utils->range_days)

• fecha_de_inspeccion (en consulta a ERP).

• fecha_limite_entrega (normalizada y desglosada en mes/año).

• Tipo de rango (diario / mensual / personalizado): Mensual (últimos 8 meses, retroactivos).

• Inclusión de horas (sí/no).: Sí, en created_date (usa DATETIME). En filtros principales, no.

• Zona horaria: La del servidor 

3) Origen de datos (tablas/APIs)

3.1 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabMatriz de Condiciones

• Alias (si aplica): cnd

• Campos utilizados (clave → descripción):

• cnd.agencia → Agencia

• cnd.id_sucursal → Código

• cnd.division_nacional → Zona

• cnd.nombre_completo → Responsable

• Condiciones (WHERE) aplicadas:

• fecha_de_inspeccion >= fecha_ini

• fecha_de_inspeccion <= fecha_fin

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabTabla Matriz de Condiciones mtr ON cnd.name = mtr.parent

• Observaciones (ej. particiones, índices):

• Se calcula mes_entrega y anio_entrega a partir de la fecha límite.

• Se marca campo calculado medidas_correctivas = "SI" cuando al menos una acción a tomar está llena, caso contrario "NO".

• Índices añadidos en tablas dinámicas: status, created_date.

3.2 Conexión / Base:   CAPACITACION

• Tabla / Recurso: tabTabla Matriz de Condiciones

• Alias (si aplica): mtr

• Campos utilizados (clave → descripción):

• mtr.tipo → Tipo de peligro

• mtr.peligro → Tipo de riesgo

• mtr.area → Zona de observación

• mtr.condicion_matriz → Condición de observación

• mtr.nivel_de_avance → Nivel de avance

• mtr.riesgo → Riesgo

• mtr.acciones_a_tomar_1 → Acción a tomar 1

• mtr.acciones_a_tomar_2 → Acción a tomar 2

• mtr.acciones_a_tomar_3 → Acción a tomar 3

• mtr.fecha_limite → Fecha límite de entrega

• Condiciones (WHERE) aplicadas: Se heredan del filtro general aplicado en cnd.fecha_de_inspeccion (rango de fechas).

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN con cnd (llave: cnd.name = mtr.parent).

• Observaciones (ej. particiones, índices): 

• El reporte construye tablas dinámicas mensuales report_matriz_condiciones_YYYY_MM.

• Se agrega truncado de tabla en recreaciones (TRUNCATE).

• Los índices aplicados en la creación de tabla: status, created_date.

4) Filtros globales del reporte

• Inclusiones (must-have): Registros dentro del rango de fechas válidas.

• Exclusiones (reglas de descarte): Si la tabla no se crea correctamente → va a error_reports

• Reglas por estado / habilitado: Campo status (1 = OK, 0 = error).

• Parámetros externos (si el usuario puede filtrarlo): fecha_inicio, fecha_fin (en getMatrizCondiciones).

5) Transformaciones y Reglas de negocio

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

• mes_entrega → mes textual desde fecha_limite_entrega.

• anio_entrega → año de fecha_limite_entrega.

• Mapeos de estado:

• medidas_correctivas = 'SI' si alguna acción (acciones_a_tomar_1/2/3) no está vacía; caso contrario 'NO'.

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

• Inserta en emp_reportes_validation cada corrida.

• Verifica existencia de tabla con verifyExistTable.

• Reglas condicionales (si X entonces Y):

• Si tabla no existe → se crea.

• Si ya existe → se trunca.

• Si falla creación → registra error.

6) Estructura de salida

• Tabla/archivo destino: report_matriz_condiciones_YYYY_MM

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

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

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

• id → INT PRIMARY KEY → Identificador único del registro

• agencia → VARCHAR → Nombre de la agencia

• codigo → VARCHAR → Código asociado

• zona → VARCHAR → Zona geográfica

• responsable → VARCHAR → Responsable asignado

• tipo_de_peligro → VARCHAR → Tipo de peligro identificado

• tipo_de_riesgo → VARCHAR → Tipo de riesgo asociado

• zona_observacion → VARCHAR → Zona donde se realizó la observación

• condicion_de_observacion → VARCHAR → Condición observada

• nivel_de_avance → VARCHAR → Nivel de avance en la corrección

• riesgo → VARCHAR → Riesgo identificado

• acciones_a_tomar_1 → VARCHAR → Primera acción correctiva a tomar

• acciones_a_tomar_2 → VARCHAR → Segunda acción correctiva a tomar

• acciones_a_tomar_3 → VARCHAR → Tercera acción correctiva a tomar

• fecha_limite_entrega → DATE → Fecha límite de entrega de acciones

• medidas_correctivas → VARCHAR → Medidas correctivas propuestas

• mes_entrega → VARCHAR → Mes de la entrega

• anio_entrega → VARCHAR → Año de la entrega

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

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

• Ordenamiento por defecto: No definido en código.

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 8 meses atrás.

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

• Tolerancia a fallos / reintentos: Si falla API → guarda status 0 en emp_reportes_validation.

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

8) Calidad y controles

• Validaciones previas/post:  Validación de tabla creada (verifyExistTable).

• Controles de duplicados: Truncado de tabla al recrear evita duplicados.

• Métricas de completitud (qué se monitorea): Registro en emp_reportes_validation (incluye status y fechas).

9) Dependencias externas

• APIs / servicios y endpoints:

• APIS: 

• RECURSOS_HUMANOS/api/matriz_condiciones/{first_date}/{second_date}

• APICAPACITACION/method/send-query-database

• Autenticación / headers:

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

• Mapeos y contratos de datos: JSON devuelto por APIs, convertido a registros de tablas.

10) Historial de cambios

2025-10-01 13:35 - Elian Franco Arroyo Rodas - Documentación inicial

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 

REPORTE DESECHOS

Fuente:  /var/www/html/web-services-qa/app/Http/Controllers/Cloud/ReportController.php

1) Nombre del reporte

• Nombre: Reporte Desechos

• Código / Alias: report_desecho

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• ose_fhpreferenciapartida (ordenes de servicio)

• fecha_registro (procesos en inventario)

• created_date (registro de inserción en tablas de reporte y validación)

• Tipo de rango (diario / mensual / personalizado): Mensual y diario (se construyen periodos por mes y se recorren días dentro del rango).

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

• Tabla / Recurso: emp_reportes_validation

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• report → Nombre del reporte (report_desecho)

• first_date → Fecha de inicio del rango

• second_date → Fecha de fin del rango

• created_date → Fecha de creación del registro en la tabla de validación

• status → Estado de ejecución (1 = correcto, 0 = error)

• Condiciones (WHERE) aplicadas: No aplica (solo inserción directa de datos procesados)

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

• Observaciones (ej. particiones, índices): Tabla usada como bitácora/validación de ejecución de reportes.

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador de terminal

• ter_nombre → Nombre de la terminal

• Condiciones (WHERE) aplicadas:Excluye terminales con IDs [210, 248, 259, 268, 269, 349, 351, 352, 353, 354, 367].

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

• Observaciones (ej. particiones, índices): Se usa para armar catálogo de terminales.

3.3 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): Ninguno (se usa sin alias)

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden de servicio

• ose_termdestinoentrega → Terminal destino de entrega

• ose_termorigenatencion → Terminal origen de atención

• ose_observacion_cambioprecio → Tipo de orden de servicio

• ose_estadoPago → Estado de pago

• ose_fhpreferenciapartida → Fecha preferencial de partida

• ose_remitecontactomail → Correo de contacto remitente (confirmado)

• ose_remitecontactofono → Teléfono de contacto remitente

• ose_entregadopersonadni → DNI de quien recibe entrega

• ose_estadoentregado → Estado de entrega

• Condiciones (WHERE) aplicadas:

• ose_estadoPago != 'AN'

• ose_tipoanulado = ''

• ose_estado = '1'

• eliminado = '0'

• ose_fhpreferenciapartida entre first_date y second_date

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

• Observaciones: Filtra OS activos, no anulados y dentro del rango de fechas.

3.4 Conexión / Base: CENTOS

• Tabla / Recurso: emp_embarque_desecho (alias embdes)

• Alias (si aplica): embdes

• Campos utilizados (clave → descripción):

• embdes.ose_id → ID de orden de servicio

• embdes.fecha → Fecha de embarque de desecho

• Condiciones (WHERE) aplicadas: embdes.estado = 1

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

• Observaciones: Trae embarques confirmados como desecho.

 

3.4 Conexión / Base: CENTOS

• Tabla / Recurso: emp_os_desechos_confirmados

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• idos → Identificador de OS confirmado como desecho

• terminal → Terminal relacionada

• Condiciones (WHERE) aplicadas: status = 1

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

• Observaciones: Refuerza confirmación de OS en desecho.

3.5 Conexión / Base: CENTOS / CENTOS2 OLD

• Tabla / Recurso: emp_procesos_historial_app

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• idose → ID de OS

• nombre_metodo → Método registrado (ej. registrar_Entrega)

• fecha_registro → Fecha de registro

• proceso → Proceso ejecutado (ej. inventario)

• Condiciones (WHERE) aplicadas:

• idose = valor de OS pendiente

• status = 1

• proceso = 'inventario'

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (consulta individual por OS pendiente)

• Observaciones: Permite detectar entregas en inventario y calcular pendientes.

4) Filtros globales del reporte

• Inclusiones (must-have):

• Solo órdenes activas y no eliminadas

• Rango de fechas válido

• Exclusiones (reglas de descarte):

• Destino = 74

• Tipo de OS = "Retiro de mercadería"

• Reglas por estado / habilitado:

• ose_estadoPago == "DA" → Desecho

• ose_estadoentregado != 1 → Pendiente de entrega

• Inventario con más de 7 días sin actualización → Pendiente de actualización

• Parámetros externos (si el usuario puede filtrarlo): Fecha ($first_date, $second_date)

5) Transformaciones y Reglas de negocio

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

• Conteo de métricas por terminal y periodo: 

• recibidos 

• desecho 

• pend_entrega 

• pend_actualizacion 

• proceso_embarque_lima 

• confirma_desecho
  
  

• Mapeos de estado: 

• "DA" → Desecho

• Otros valores → Pendiente o entregado según reglas.

• Reglas de validación (p.ej., sólo registros validados): Contacto obligatorio (mail o fono) para algunos casos.

• Reglas condicionales (si X entonces Y): Diferente conexión de BD según año/mes.

6) Estructura de salida

• Tabla/archivo destino: report_desecho_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):

• periodo → VARCHAR → Fecha agrupada

• id_agencia → VARCHAR → ID de la agencia

• agencia → VARCHAR → Nombre de la agencia

• recibidos → VARCHAR → OS recibidas

• desecho → VARCHAR → OS desechadas

• proceso_embarque_lima → VARCHAR → Procesos de embarque

• confirma_desecho → VARCHAR → OS confirmadas como desechos

• pend_entrega → VARCHAR → Pendientes de entrega

• pend_actualizacion → VARCHAR → Pendientes de actualización (>7 días)

• created_date → DATETIME → Fecha de inserción

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

• Ordenamiento por defecto: No explícito; implícitamente por periodo y id_agencia

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Dependiendo del rango (meses o días dentro del mes)

• Tamaño de lote / paginado (chunking): 20,000 (pendientes) y 900 (inserciones)

• Tolerancia a fallos / reintentos: Control con try/catch, rollback en transacciones

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

8) Calidad y controles

• Validaciones previas/post: Verificación de existencia de tabla (verifyExistTable)

• Controles de duplicados: Agrupamiento de órdenes por ose_id

• Métricas de completitud (qué se monitorea): Conteo de estados por terminal y periodo

9) Dependencias externas

• APIs / servicios y endpoints: Ninguno explícito; todo interno a BD

• Autenticación / headers: Acceso por conexiones DB internas (empresarial, centos, reportes)

• Mapeos y contratos de datos: Tablas dinámicas creadas con estructura fija

10) Historial de cambios

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

REPORTE CAMBIO DE CLAVE

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

1) Nombre del reporte

• Nombre: Reporte Cambio de Clave

• Código / Alias: update_clave

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: cc.fecha_crea

• Tipo de rango (diario / mensual / personalizado): mensual (primer día y último día del mes)

• Inclusión de horas (sí/no). Si 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_informacion_cambio_clave

• Alias (si aplica): cc

• Campos utilizados (clave → descripción):

• cc_id → Identificador del cambio de clave

• cc_tipo_documento → Tipo de documento

• cc_guia → Guía de proceso

• cc_codigo → Código de cambio de clave

• cc_aprobacion → Estado de aprobación

• cc_motivo → Motivo del cambio de clave

• cc_ose_id → Identificador de la orden de servicio relacionada

• cc_estado → Estado del cambio de clave

• cc_fecha_reevalua → Fecha de re-evaluación

• fecha_crea → Fecha de creación

• cc_user_actualiza → Usuario que actualiza

• usr_alias → Alias del usuario (COALESCE con "SIN ATENDER")

• cc_user_reevalua → Usuario que reevalúa

• cc_medio_utilizado → Medio utilizado

• us.cc_id (de tabla emp_user_gets_code) → Relación con código de usuario

• cc_reenvio → Reenvío del cambio de clave
  
  

• Condiciones (WHERE) aplicadas:  

• cc.cc_motivo NOT IN ('Motivo de la Gestión', 'Olvido de clave de seguridad')

• cc.fecha_crea BETWEEN $first_date AND $second_date

 

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

• LEFT JOIN emp_usuario as usr → usr.usr_id = cc.cc_user_actualiza

• LEFT JOIN emp_user_gets_code as us → cc.cc_id = us.cc_id

• Observaciones (ej. particiones, índices): Usa COALESCE para alias de usuario.

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ose_id → Identificador de la orden de servicio
  
  

• Condiciones (WHERE) aplicadas:

• ose_id IN (lista de ose_id obtenidos en la primera consulta)

• ose_estado = 1

• eliminado = 0

• ose_estadoPago != 'AN'

• ose_remitecontactofono = 'REGISTRA'

• ose_tipoanulado = ''

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

• Observaciones: Valida solo órdenes activas, no anuladas.

3.3 Conexión / Base: CENTOS

• Tabla / Recurso: emp_messages_code_attempts

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden de servicio

• usuario → Usuario que intentó reenvío de código

• Condiciones (WHERE) aplicadas:

• ose_id IN (lista de ose_id obtenidos en la primera consulta)

• status = 1

• usuario NOT NULL

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

• Observaciones: Se registran intentos de reenvío de SMS de código.

 

3.4 Conexión / Base: ERP REPORTS

• Tabla / Recurso: report_cambio_clave_<anio_mes>

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• id → Identificador del registro

• periodo → Periodo de reporte (año-mes)

• motivo → Motivo del cambio de clave

• usuario → Usuario vinculado al cambio de clave

• Condiciones (WHERE) aplicadas: Ninguna explícita (solo SELECT)

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

• Observaciones: Tabla dinámica que se genera por periodo (YYYY_MM).

4) Filtros globales del reporte

• Inclusiones (must-have):  Registros con cc.fecha_crea dentro del rango mensual, ose_id válido y status=1 en reenvío.

• Exclusiones (reglas de descarte): Motivos Motivo de la Gestión, Olvido de clave de seguridad.

• Reglas por estado / habilitado: ose_estado=1, eliminado=0.

• Parámetros externos (si el usuario puede filtrarlo): hasta_anio, $hasta_mes.

5) Transformaciones y Reglas de negocio

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

• Agrupación por periodo (Y-m de fecha_crea).

• Conteo cantidad_cambio_clave_envia si el ose_id se encuentra en emp_ordenservicio.
  
  

• Mapeos de estado: COALESCE(usr_alias, "SIN ATENDER") para usuario.
  

• Reglas de validación (p.ej., sólo registros validados): Sólo considera usuario no nulo en reenvío SMS.
  
  

• Reglas condicionales (si X entonces Y): Si cc_ose_id está en lista enviada, se incrementa el contador.

 

6) Estructura de salida

• Tabla/archivo destino: report_cambio_clave_{anio}_{mes} (dinámica).

• Particionado / sufijo: Mensual (anio_mes).

• Clave(s) primaria(s) o únicas: periodo + motivo + usuario

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

• periodo → string (ej. "2025-09")

• motivo → string (motivo de la gestión)

• usuario → string (alias de usuario)

• cantidad_cambio_clave_envia → int (conteo)
  
  

• Ordenamiento por defecto: No definido en código.

7) Frecuencia y operación

• Frecuencia de actualización: Mensual (parámetros de entrada)

• Ventana que recalcula (días/meses): Todo el mes (first day → last day).

• Tamaño de lote / paginado (chunking): No aplica (usa get()->toArray()).

• Tolerancia a fallos / reintentos: No aplica

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

8) Calidad y controles

• Validaciones previas/post: Verifica existencia de registros en tabla destino antes de actualizar.

• Controles de duplicados: Evita duplicar reenvíos agrupando por ose_id + usuario.

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

9) Dependencias externas

• APIs / servicios y endpoints: No aplica (todo SQL interno).

• Autenticación / headers: Credenciales internas de conexión DB.

• Mapeos y contratos de datos: Dinámica de tablas mensuales en reports.

10) Historial de cambios

2025-09-30 11:32 - Elian Franco Arroyo Rodas - Documentación inicial

2025-10-15 10:32 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE DE RECLAMOS

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

1) Nombre del reporte

• Nombre: Reporte de Reclamos

• Código / Alias: no aplica

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• rec.fecharegistro (campo principal de filtrado)

• rec_fecha_reclamo_atendido (fecha de atención reclamo)

• ose_fhemision, ose_fhpreferenciapartida (guía asociada)

 

• Tipo de rango (diario / mensual / personalizado):

• Mensual (procesa rangos dinámicos de meses según el día y hora del servidor).
  
  

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

• Campos utilizados (clave → descripción): 

• id_reclamo → Identificador del reclamo

• clasificacion_reclamo → Tipo o categoría del reclamo

• detalle_reclamo → Detalle del reclamo

• pedido_reclamo → Pedido asociado al reclamo

• estado_reclamo → Estado del reclamo (Pendiente, Atendido, Cerrado, etc.)

• Empresa → Empresa a la que pertenece el reclamo

• fecharegistro → Fecha de registro del reclamo

• reclamo_code → Código interno del reclamo

• rec_serie / rec_numeroguia → Serie y número de guía del reclamo

• monto_producto → Monto asociado al producto reclamado

• ruta_reclamo → Ruta o procedimiento asociado

• tipo_reclamo → Tipo (por producto, servicio, otros)

• imagen_reclamo → Imagen adjunta (si aplica)

• Sucursal → ID o nombre de sucursal

• user_contacta_cliente_reclamo → Usuario que atendió o contactó al cliente

• rec_descargo → Descargo registrado

• respuesta_reclamo_cliente → Respuesta final del cliente
  
  

• Condiciones (WHERE) aplicadas: 

• Filtra registros activos (estado_eliminacion = 0) y dentro del rango de fechas entre $first_date y $second_date.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN emp_cliente cli ON rec.id_cliente = cli.id_cliente
  
  

• Observaciones (ej. particiones, índices): Tabla principal para el reporte; campo fecharegistro usado para filtrado. No se definen índices adicionales.

3.2 Conexión / Base: Empresarial

• Tabla / Recurso: emp_cliente

• Alias (si aplica): cli

• Campos utilizados (clave → descripción): 

• id_cliente → Identificador único del cliente

• provincia_cli → Provincia del cliente

• distrito_cliente → Distrito del cliente

• domicilio_cliente → Domicilio completo del cliente

• telefono_cliente → Teléfono de contacto

• email_cliente → Correo electrónico

• razonSocial_cliente → Razón social

• ruc_cliente → RUC del cliente

• dni_cliente → Documento nacional de identidad

• nombre_cliente, apellido_paterno, apellido_materno → Componentes del nombre del cliente
  
  

• Condiciones (WHERE) aplicadas: Los registros se obtienen mediante JOIN con emp_reclamo.id_cliente
  
  

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN emp_reclamo rec ON cli.id_cliente = rec.id_cliente
  
  

• Observaciones (ej. particiones, índices): Usada como tabla de referencia para enriquecer datos del reclamo.

3.3 Conexión / Base: Empresarial

• Tabla / Recurso: emp_terminal

• Alias (si aplica): term

• Campos utilizados (clave → descripción): 

• ter_id → Identificador del terminal o sucursal

• ter_nombre → Nombre de la terminal o sucursal
  
  

• Condiciones (WHERE) aplicadas: eliminado = 0 y ter_id = sucursal (relación con campo del reclamo).
  
  

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

• Observaciones (ej. particiones, índices): Sirve para reemplazar el ID de sucursal por su nombre legible.

3.4 Conexión / Base: Empresarial

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción): 

• ose_nroguiacliente → Número de guía de cliente

• ose_fhemision → Fecha de emisión del documento

• ose_fhpreferenciapartida → Fecha de traslado preferente
  
  

• Condiciones (WHERE) aplicadas: Filtra por número de guía (ose_nroguiacliente = rec.guiareclamo).
  
  

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

• Observaciones (ej. particiones, índices): 

• Conexión dinámica:

• Si año = 2023 y mes ≤ 9 → EMPRESARIAL_OLD
  
  

• Caso contrario → EMPRESARIAL

4) Filtros globales del reporte

• Inclusiones (must-have):  Solo reclamos con estado_eliminacion = 0.

• Exclusiones (reglas de descarte): Reclamos eliminados (estado_eliminacion = 1).

• Reglas por estado / habilitado: No explícitas.

• Parámetros externos (si el usuario puede filtrarlo): Rango de fechas ($first_date, $second_date) calculado automáticamente.

5) Transformaciones y Reglas de negocio

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

• codigo_reclamo = "AC-" + id_reclamo

• fecha_estado = rec_fecha_reclamo_atendido si existe.

• sucursal → se transforma en texto a partir del ID o del string delimitado por “ - ”.

• fhcontrataservicio, fhservicio extraídos de emp_ordenservicio.

• Mapeos de estado: Campos estadoreclamo, tiporeclamo, origen_doc en mayúsculas.

• Reglas de validación (p.ej., sólo registros validados):  Valida existencia de sucursal y guía antes de asignar fechas.

• Reglas condicionales (si X entonces Y):

• Si día = domingo → usa rangos fijos (3–12) según hora.

• Si no es domingo → procesa los últimos 6 meses.

• Si no se puede crear tabla → registra error en error_reports.

6) Estructura de salida

• Tabla/archivo destino: report_reclamos_YYYY_MM

• Particionado / sufijo: Mensual (_YYYY_MM según fechaReclamo).

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

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

• id_reclamo → VARCHAR → ID original del reclamo

• codigo_reclamo → VARCHAR → Código generado prefijado

• fecha_reclamo → DATE → Fecha del registro original

• guia → VARCHAR → Número o código de guía del reclamo

• ruta → VARCHAR → Ruta asociada al reclamo o entrega

• monto → DECIMAL → Monto del reclamo o servicio

• ruc → VARCHAR → RUC del cliente o empresa

• razon_social → VARCHAR → Razón social del cliente o empresa

• dni_cliente → VARCHAR → DNI del cliente

• nombre_cliente → VARCHAR → Nombre completo del cliente

• estado → VARCHAR → Estado actual del reclamo

• fecha_estado → DATE → Fecha de cambio de estado

• tipo → VARCHAR → Tipo de reclamo o categoría

• atendido → TINYINT → Indicador si el reclamo fue atendido (1 = sí, 0 = no)

• user_atendido → VARCHAR → Usuario que atendió el reclamo

• sucursal → VARCHAR → Nombre o código de la sucursal

• medio_utilizado → VARCHAR → Medio utilizado para la atención (teléfono, correo, presencial, etc.)

• descargo → VARCHAR → Descargo o justificación registrada

• respuesta → VARCHAR → Respuesta final al reclamo

• fecha_contrata → DATE → Fecha de contacto o contratación del servicio

• hora_contrata → TIME → Hora de contacto o contratación

• fecha_servicio → DATE → Fecha del servicio asociado

• hora_servicio → TIME → Hora del servicio asociado

• descripcion_bien → VARCHAR → Descripción del bien o producto involucrado

• created_date → DATETIME → Fecha de inserción en el datawarehouse o registro del sistema

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

• Ordenamiento por defecto: No explícito en el SQL, pero el flujo indica orden cronológico por fecha_reclamo.

 

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Últimos 6 meses (o rangos fijos si domingo).

• Tamaño de lote / paginado (chunking): array_chunk($detail, 900) (procesa en bloques de 900 registros).

• Tolerancia a fallos / reintentos: Manejo de excepción con rollback y registro en emp_reportes_validation.

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

8) Calidad y controles

• Validaciones previas/post: Verifica existencia de tabla destino antes de insertar (verifyExistTable).

• Controles de duplicados: No hay control explícito; se asume partición mensual evita duplicados.

• Métricas de completitud (qué se monitorea): Registro de cada ejecución en emp_reportes_validation con status = 1 o 0.

9) Dependencias externas

• APIs / servicios y endpoints: No se consumen APIs externas.

• Autenticación / headers: No aplica (conexión directa a BD).

• Mapeos y contratos de datos:

• emp_reclamo ↔ emp_cliente ↔ emp_ordenservicio ↔ emp_terminal.

10) Historial de cambios

2025-10-15 12:46 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE FLOTA

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

1) Nombre del reporte

• Nombre: Reporte de Flota

• Código / Alias: report_flota

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• created_date (fecha de generación del registro)

• first_date, second_date (fechas de validación del reporte)

• Tipo de rango (diario / mensual / personalizado): Diario (usa date("Y-m-d") para ambos límites)

• Inclusión de horas (sí/no).: Sí → Y-m-d H:i:s (rango implícito [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_carguero_new

• Alias (si aplica): car

• Campos utilizados (clave → descripción):

• car_placa → Placa del vehículo

• car_codigo → Código interno del carguero

• car_telefono → Teléfono asociado al carguero

• car_tipoCarguero → Tipo de unidad (camión, camioneta, etc.)

• car_pesobruto → Peso bruto total

• car_cargautil → Capacidad de carga útil

• car_modelo → Modelo del vehículo

• car_marca → Marca del vehículo

• car_tarjeta_circulacion → Número de tarjeta de circulación

• car_tipo_grupo → Tipo de grupo (categoría del vehículo)

• car_habilitado → Estado de habilitación (activo/inactivo)

• car_terminal → Llave foránea que enlaza con emp_terminal.ter_id

• Condiciones (WHERE) aplicadas: Se obtiene todo el registro de la tabla emp_carguero_new.

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

• LEFT JOIN emp_terminal AS ter ON ter.ter_id = car.car_terminal

• Llave principal: ter.ter_id

• Llave foránea: car.car_terminal
  
  

• Observaciones (ej. particiones, índices): 

• Índices agregados posteriormente en report_flota sobre:

• codigo, placa, habilitado, created_date

• No se mencionan particiones.

3.2 Conexión / Base: Empresarial

• Tabla / Recurso: emp_terminal

• Alias (si aplica): ter

• Campos utilizados (clave → descripción):

• ter_nombre → Nombre del terminal

• ter_id → Identificador del terminal

• Condiciones (WHERE) aplicadas: No se aplican condiciones adicionales; los registros se enlazan únicamente por la relación LEFT JOIN con emp_carguero_new.

• Tipo de unión con otras fuentes (JOIN y llave): Unión con emp_carguero_new mediante: car.car_terminal = ter.ter_id
  
  

• Observaciones (ej. particiones, índices): Sin observaciones adicionales.

4) Filtros globales del reporte

• Inclusiones (must-have): Todos los vehículos registrados en emp_carguero_new

• Exclusiones (reglas de descarte): No aplica

• Reglas por estado / habilitado: Se conserva car_habilitado como campo; no se filtra

• Parámetros externos (si el usuario puede filtrarlo): No aplica (ejecución interna, sin filtros dinámicos)

5) Transformaciones y Reglas de negocio

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

Cada campo pasa por validación → si está vacío (!trim(...)) se asigna null o 0

• habilitado se normaliza a 0 si está vacío

• Se agrega created_date = date('Y-m-d H:i:s')

• Se agrega status = 1 por defecto

• Mapeos de estado: habilitado → 0/1

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

• Solo registros con estructura válida (no se descartan por condición)

• La tabla se recrea o trunca en cada ejecución

• Reglas condicionales (si X entonces Y):

• Si la tabla no existe → se crea

• Si ya existe → se trunca antes de insertar

6) Estructura de salida

• Tabla/archivo destino: report_flota

• Particionado / sufijo: No aplica

• Clave(s) primaria(s) o únicas: id INT AUTO_INCREMENT PRIMARY KEY

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

• id → INT → Identificador autoincremental

• placa → VARCHAR(100) → Placa del vehículo

• codigo → VARCHAR(100) → Código del carguero o unidad

• telefono → VARCHAR(100) → Teléfono asociado

• tipounidad → VARCHAR(100) → Tipo de unidad de transporte

• pesobruto → VARCHAR(100) → Peso bruto del vehículo

• cargautil → VARCHAR(100) → Capacidad de carga útil

• modelo → VARCHAR(100) → Modelo del vehículo

• marca → VARCHAR(100) → Marca del vehículo

• tarjetacircula → VARCHAR(100) → Número de tarjeta de circulación

• tipogrupo → VARCHAR(100) → Tipo de grupo o categoría del vehículo

• ternombre → VARCHAR(150) → Nombre del terminal o centro de operaciones

• idterm → VARCHAR(100) → ID del terminal asociado

• habilitado → VARCHAR(100) → Estado del vehículo (0 = inactivo, 1 = activo)

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

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

• Ordenamiento por defecto: No especificado (se asume orden por id ASC)

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Día actual (date("Y-m-d"))

• Tamaño de lote / paginado (chunking): No aplica (procesa todo el set en memoria)

• Tolerancia a fallos / reintentos:

• Rollback automático ante excepción

• Inserta log 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)

• Commit / rollback según resultado

• Controles de duplicados:

• No hay control de duplicados; la tabla se vacía antes de cada carga

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

• Registro de validación en emp_reportes_validation con estado y fechas

9) Dependencias externas

• APIs / servicios y endpoints: No aplica (solo conexiones internas a BD)

• Autenticación / headers: No aplica

• Mapeos y contratos de datos: Internos, controlados por las conexiones $this->empresarial, $this->reportes, $this->centos

10) Historial de cambios

2025-10-15 13:15 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE DENUNCIAS

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

1) Nombre del reporte

• Nombre: Reporte Denuncias

• Código / Alias: report_denuncias

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• creation (campo principal del Doctype Denuncias en ERPNext)

• Rango dinámico entre first_date y second_date

• Tipo de rango (diario / mensual / personalizado): Mensual (últimos dos meses, incluyendo diciembre del año anterior si corresponde)

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: Capacitacion

• Tabla / Recurso: tabDenuncias

• Alias (si aplica): d

• Campos utilizados (clave → descripción):

• name → Identificador del registro de denuncia

• docstatus → Estado del documento (borrador, enviado, cancelado)

• estado_denuncias → Estado general de la denuncia (Atendido, Pendiente, etc.)

• celular → Teléfono de contacto del denunciante

• correo → Correo del denunciante

• motivo → Motivo de la denuncia

• sucursal → Sucursal relacionada a la denuncia

• archivo_denuncia as archivo → Archivo adjunto a la denuncia

• hasta → Fecha de finalización o cierre del caso

• detalle → Descripción del hecho denunciado

• compromiso → Compromiso asumido tras la denuncia

• fecha_atendido → Fecha en la que fue atendida la denuncia

• continua_ocurriendo → Indica si el hecho continúa ocurriendo (Sí/No)

• desde → Fecha de inicio del hecho denunciado

• conoce_involucrados → Indica si el denunciante conoce a los involucrados

• codigo_aleatorio → Código de seguimiento de la denuncia

• modified → Fecha y hora de última modificación

• owner → Usuario creador del registro

• creation → Fecha y hora de creación

• modified_by → Usuario que realizó la última modificación

• Condiciones (WHERE) aplicadas: 

• "Denuncias"."creation" BETWEEN [fecha_inicio, fecha_fin]

• "Denuncias"."docstatus" != 2

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

• INNER JOIN con tabtabla_involucrados mediante campo relacionado interno.

• Campos secundarios (tabla relacionada tabtabla_involucrados):

• nombre → Nombre del involucrado

• area → Área a la que pertenece

• sucursal → Sucursal del involucrado

• Observaciones (ej. particiones, índices):

• Los resultados se particionan dinámicamente por mes (report_denuncias_YYYY_MM).

• Se generan índices automáticos en la creación de tabla (create_table_all → $index).

• Se manejan estructuras de respaldo (error_reports) para errores de creación.

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Solo denuncias con docstatus != 2 (no canceladas)

• Solo registros dentro del rango mensual calculado

• Exclusiones (reglas de descarte):

• Denuncias sin data o con errores en el servicio remoto

• Reglas por estado / habilitado:

• status = 1 indica éxito; status = 0 indica fallo

• Parámetros externos (si el usuario puede filtrarlo): Ninguno (fechas generadas automáticamente por el sistema)

5) Transformaciones y Reglas de negocio

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

• fecha_registro = DATE(creation)

• created_date = fecha actual del procesamiento

• status = 1 (por defecto en datos válidos)
  
  

• Mapeos de estado: Prefijo tabla_involucrados: reemplazado por involucrado_ en nombres de campos.

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

• Si no hay datos o el API falla, se marca en emp_reportes_validation con status = 0.

• Reglas condicionales (si X entonces Y): Si el mes actual es enero o febrero → incluir diciembre del año anterior en el cálculo.

6) Estructura de salida

• Tabla/archivo destino: Tablas dinámicas por mes: report_denuncias_YYYY_MM

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

• Clave(s) primaria(s) o únicas: name (ID de denuncia)

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

• name → VARCHAR → ID de la denuncia

• fecha_registro → DATE → Fecha de creación del registro

• estado_denuncias → VARCHAR → Estado actual de la denuncia

• sucursal → VARCHAR → Sucursal asociada a la denuncia

• involucrado_nombre → VARCHAR → Nombre del involucrado

• involucrado_area → VARCHAR → Área o departamento del involucrado

• involucrado_sucursal → VARCHAR → Sucursal del involucrado

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

• status → INT → Estado de procesamiento (1 = activo / 0 = inactivo)

• Ordenamiento por defecto: Por creation ascendente (no explícito en SQL)

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Hasta 2 meses previos

• Tamaño de lote / paginado (chunking): array_chunk($detail, 100)

• Tolerancia a fallos / reintentos: 

• Control con try/catch y rollback de transacción

• Inserta errores en error_reports

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

8) Calidad y controles

• Validaciones previas/post: Inserción en emp_reportes_validation para auditar éxito o error

• Controles de duplicados: No explícitos (la tabla mensual se regenera si es nueva)

• Métricas de completitud (qué se monitorea): Recuento de registros insertados y validación de éxito (status)

9) Dependencias externas

• APIs / servicios y endpoints: POST {APICAPACITACION}method/frappe.desk.reportview.get

• Autenticación / headers: Gestionado por $this->general->serviceErp()

• Mapeos y contratos de datos: Formato JSON con claves fields, filters, doctype, data, keys, values

10) Historial de cambios

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

REPORTE SHIPPING AMOUNT PARTTOW

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

1) Nombre del reporte

• Nombre: Reporte Shipping Amount PartTwo

• Código / Alias:  report_shipping_amount_part_two_

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• fecha en emp_cierre_aereo

• cop_fechaemision en emp_comppago_dhl

• ose_fhpreferenciapartida, ose_fhpreferencial en emp_ordenservicio
  
  

• Tipo de rango (diario / mensual / personalizado):  

• Personalizado (desde $first_date hasta $second_date)

• Se generan registros diarios (range con DatePeriod → iteración día a día).

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

• Tabla / Recurso: emp_cierre_aereo

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• id → Identificador del cierre aéreo

• cap_id → Código de capacidad o identificador del cierre

• general → Kilaje general del cierre

• peligrosa → Kilaje de carga peligrosa

• valiosa → Kilaje de carga valiosa

• detalle_mercaderia → Detalle del contenido transportado (JSON)

• fecha → Fecha del registro del cierre aéreo

• Condiciones (WHERE) aplicadas:

• Se filtran los registros donde el campo estado sea igual a 1 (cerrados activos) y cuya fecha esté dentro del rango definido por las variables $finit y $ffend, es decir, entre la fecha de inicio y fin del reporte.

 

• Tipo de unión con otras fuentes (JOIN y llave): Relaciona mediante id con cierre_id de la tabla emp_embarque_aereo.

• Observaciones (ej. particiones, índices): 

• Tabla utilizada para obtener cierres aéreos con detalle de mercadería, se decodifica su campo JSON para cálculo de kilaje.

3.2 Conexión / Base: CENTOS

• Tabla / Recurso: emp_embarque_aereo

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• id → Identificador del embarque aéreo

• ose_id → Identificador del orden de servicio relacionada

• terminal → Terminal donde se realizó el embarque

• fecha → Fecha del embarque

• cierre_id → Identificador del cierre aéreo asociado

• Condiciones (WHERE) aplicadas:

• Se seleccionan los registros cuyo cierre_id exista dentro del conjunto de cierres aéreos previamente filtrados (array_keys($cierres_aereos_json)).

 

• Tipo de unión con otras fuentes (JOIN y llave): Une con emp_cierre_aereo (por cierre_id) y con emp_ordenservicio (por ose_id).

• Observaciones (ej. particiones, índices): 

• El resultado se agrupa por ose_id para obtener un resumen por orden de servicio.
  
  

3.3 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden de servicio

• ose_fhpreferenciapartida → Fecha preferencial de partida

• ose_fhpreferencial → Fecha alternativa de programación

• ose_termorigenatencion → Terminal de origen

• ose_termdestinoentrega → Terminal de destino

• ose_estadoPago → Estado del pago de la orden

• ose_tipoanulado → Indicador de anulación

• ose_remiteempresa → Empresa remitente

• ose_destinaempresa → Empresa destinataria

• ose_montofinal → Monto total del servicio

• ose_estadoentregado → Estado de entrega del servicio

• ose_remitecontactofono → Contacto de remitente

• ose_remitecontactomail → Correo del remitente

• ose_observacion_cambioprecio → Tipo de orden de servicio

• Condiciones (WHERE) aplicadas:

• Filtra órdenes de servicio activas (ose_estado = 1) y no eliminadas (eliminado = 0), excluye aquellas con estados de pago “AN” (Anulado) o “DA” (Dado de baja), y valida que no tengan tipo de anulación (ose_tipoanulado vacío).

• Además, restringe por rango de fecha (ose_fhpreferenciapartida o ose_fhpreferencial entre $finit y $ffend), y si la variable $terminal está definida, se filtran registros cuyo origen o destino coincidan con esa terminal.

 

• Tipo de unión con otras fuentes (JOIN y llave): Relaciona con emp_embarque_aereo mediante ose_id, y con emp_envio_aereo, emp_incidencias, emp_adicionales y emp_empresa en distintas etapas del procesamiento.

• Observaciones (ej. particiones, índices): 

• Es la tabla base para la mayoría de cálculos de métricas (corporativo, comercial, reparto, etc.).

3.4 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_comppago_dhl

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• numero_dhl → Número de comprobante DHL

• cop_id → Identificador del comprobante

• cop_terminal → Terminal del comprobante

• cop_montoTotal → Monto total del comprobante

• cop_fechaemision → Fecha de emisión del comprobante

• Condiciones (WHERE) aplicadas:

• Solo se consideran los comprobantes con cop_estado_pago distinto de “AN” (no anulados), cop_estado = 1 (activos) y eliminado = 0.

 

• Tipo de unión con otras fuentes (JOIN y llave): No aplica unión directa; los datos se agregan por terminal y fecha para análisis comparativo.

• Observaciones (ej. particiones, índices): 

• Los montos y cantidades se agrupan manualmente por terminal y día.

3.5 Conexión / Base: EMPRESARIAL

• Tabla / Recurso:  emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador de terminal

• ter_nombre → Nombre de la terminal
  
  

• Condiciones (WHERE) aplicadas:

• Se obtienen únicamente terminales habilitadas (ter_habilitado = 1).

 

• Tipo de unión con otras fuentes (JOIN y llave): Se usa como catálogo para recorrer todas las terminales y generar métricas por día.

• Observaciones (ej. particiones, índices): 

• Actúa como tabla maestra de referencia.

3.6 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_incidencias (alias inc)

• Alias (si aplica): inc

• Campos utilizados (clave → descripción):

• inc_id → Identificador de incidencia

• inc.usercreaid → Usuario creador

• inc_tipo → Tipo de incidencia

• inc_fhincidencia → Fecha de incidencia

• inc_idos → Orden de servicio afectada

• inc_responsable_terminal → Terminal responsable

• inc_descripcion → Descripción de la incidencia
  
  

• Condiciones (WHERE) aplicadas:

• Se incluyen incidencias que no estén eliminadas (eliminado nulo o 0), cuyo inc_descripcion coincida con alguno de tres mensajes predefinidos de fallas o decomisos, y que su inc_idos pertenezca al conjunto de órdenes de servicio analizadas.

 

• Tipo de unión con otras fuentes (JOIN y llave): Relaciona con emp_ordenservicio mediante inc_idos.

• Observaciones (ej. particiones, índices): 

• Se usa para excluir órdenes con incidencias registradas.

3.7 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_adicionales (alias adc)

• Alias (si aplica): adc

• Campos utilizados (clave → descripción):

• adc_ordenservicioid → ID de la orden de servicio

• adc_tipo → Tipo de adicional (E = entrega)

• adc_costo → Costo del adicional

• eliminado → Estado lógico del registro
  
  

• Condiciones (WHERE) aplicadas:

• Se filtran registros con adc_tipo = 'E' (entregas) y, según el bloque, algunos con eliminado = 1.

• Además, se limita a los registros cuyo adc_ordenservicioid esté dentro del conjunto de órdenes seleccionadas o devueltas por la API Rakky.

 

• Tipo de unión con otras fuentes (JOIN y llave): Relaciona con emp_ordenservicio por adc_ordenservicioid.

• Observaciones (ej. particiones, índices): 

• Utilizado para identificar entregas pendientes o completadas.

3.8 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_empresa

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ruc → Documento de la empresa

• grupo → Tipo de grupo (CORPORATIVO / CREDITO / COMERCIAL)
  
  

• Condiciones (WHERE) aplicadas:

• Filtrar registros donde grupo no sea nulo ni vacío, clasificando las empresas según su tipo de grupo.

 

• Tipo de unión con otras fuentes (JOIN y llave): Se cruza lógicamente con remitentes y destinatarios de emp_ordenservicio.

• Observaciones (ej. particiones, índices): 

• Define categorías de empresa para clasificar los montos de servicio.

4) Filtros globales del reporte

• Inclusiones (must-have):

• Órdenes activas (ose_estado=1), no eliminadas, no anuladas.

• Incidencias no críticas.

• Terminales habilitados.

• Exclusiones (reglas de descarte):

• tipo_os = 'Retiro de mercadería'

• ose_estadoPago IN ('AN','DA')

• ose_tipoanulado != ''

 

• Reglas por estado / habilitado:  Solo estado=1 para registros logísticos.

• Parámetros externos (si el usuario puede filtrarlo): $first_date, $second_date, $terminal

5) Transformaciones y Reglas de negocio

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

• kilaje_aereo → suma de detalle_mercaderia.general

• corporativo_* / comercial_* → según grupo del RUC remitente/destinatario.

• shalom_pro / envia_ya → según valor de rcontacto (WEB o REGISTRA).

• cantidad_reparto_pendiente → diferencia entre entregas registradas vs confirmadas Rakky.

• Mapeos de estado: 

• Terminal (ter_id → ter_nombre)

• Grupo empresa (grupo → tipo_cliente)
  
  

• Reglas de validación (p.ej., sólo registros validados): Ignorar incidencias SUNAT o faltantes.
  
  

• Reglas condicionales (si X entonces Y):

• Si $terminal != "TODOS" → aplica filtro específico.

• Si detalle_mercaderia no es JSON → inicializa vacío.

6) Estructura de salida

• Tabla/archivo destino: report_shipping_amount_part_two_YYYY_MM

• Particionado / sufijo: mensual (date("Y_m", $fecha))

• Clave(s) primaria(s) o únicas: fecha, terminal_id

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

• fecha → DATE → Día del registro  

• terminal_id → INT → Identificador del terminal  

• terminal_nombre → VARCHAR(150) → Nombre del terminal  

• envia_ya → INT → Envíos registrados por el canal Envia Ya  

• shalom_pro → INT → Envíos realizados vía portal Shalom Pro  

• contador_rakki → INT → Cantidad de entregas confirmadas por Rakky  

• monto_rakki → DOUBLE → Monto total de entregas registradas por Rakky  

• cantidad_store → INT → Cantidad de ventas en Shalom Store  

• monto_store → DOUBLE → Monto total de ventas en Shalom Store  

• corporativo_cantidad → INT → Cantidad de envíos de clientes corporativos  

• corporativo_monto → DOUBLE → Monto total de envíos corporativos  

• comercial_cantidad → INT → Cantidad de envíos de clientes comerciales  

• comercial_monto → DOUBLE → Monto total de envíos comerciales  

• cantidad_enviado_aereo → INT → Total de envíos aéreos emitidos  

• monto_enviado_aereo → DOUBLE → Monto total de envíos aéreos emitidos  

• cantidad_recibido_aereo → INT → Total de envíos aéreos recibidos  

• monto_recibido_aereo → DOUBLE → Monto total de envíos aéreos recibidos  

• aereo_entregado_no → INT → Cantidad de envíos aéreos no entregados  

• kilaje_aereo → DOUBLE → Kilaje total de envíos aéreos  

• cantidad_dhl → INT → Cantidad de comprobantes procesados por DHL  

• kilaje_dhl → DOUBLE → Kilaje total asociado a DHL  

• amount_dhl → DOUBLE → Monto total asociado a DHL  

• cantidad_reparto_total → INT → Total de entregas locales realizadas  

• cantidad_reparto_pendiente → INT → Total de entregas locales pendientes  

• cantidad_envios_terrestres_por_aereo → INT → Total de envíos terrestres procesados vía aéreo  

• monto_envios_terrestres_por_aereo → DOUBLE → Monto total de envíos terrestres procesados vía aéreo  

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

• Ordenamiento por defecto: por fecha ascendente y terminal_id

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses):  rango dinámico ($first_date → $second_date)

• Tamaño de lote / paginado (chunking): 900 registros por inserción (comentado)

• Tolerancia a fallos / reintentos: manejo básico de cURL error

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

8) Calidad y controles

• Validaciones previas/post:

• JSON válido en detalle_mercaderia

• Rango de fechas correcto
  
  

• Controles de duplicados: Conteos por terminal consistentes con datos API.

• Métricas de completitud (qué se monitorea):  Llave terminal_id + fecha asegura unicidad.

• Cantidades y montos por tipo (aéreo, terrestre, corporativo, comercial).

9) Dependencias externas

• APIs / servicios y endpoints: 

• Rakky (servicio de entregas): 

• Endpoint: DIRRAKKY/api/search_deliveries_by_ose_ids_new

• Función: Verificación de entregas efectivas según lista de órdenes de servicio (OSE).
  
  

• Shalom Store (servicio de ventas físicas):

• Endpoint: RECURSOS_HUMANOS/api/detail-shalom-store-selling

• Función: Consulta de ventas por terminal en el rango de fechas del reporte.
  
  

• Bases de datos internas:

• centos (operativa / logística aérea)

• empresarial (operativa ERP principal)

• Autenticación / headers:  No explícitos. Uso directo de GuzzleHttp\Client->request() y curl_init() sin encabezados personalizados o tokens.

• Mapeos y contratos de datos: 

• Rakky: espera un cuerpo JSON con la clave ose_ids (array de identificadores de órdenes).

• La respuesta esperada es JSON con campo message → lista de entregas confirmadas.
  
  

• Shalom Store: recibe { fh_init, fh_end } como cuerpo del POST.

• Devuelve JSON con message → array de objetos que contienen terminal, ventas_cantidad, ventas_monto.

• Bases internas: devuelven conjuntos de registros (arrays asociativos) para cada consulta SQL (DB::connection()->select()).

10) Historial de cambios

2025-10-17 13:52 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE MAPA DE CALOR

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

1) Nombre del reporte

• Nombre: Reporte Mapa de Calor

• Código / Alias: report_mapa_calor

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• os.ose_fhemision (Órdenes)

• ent.ent_fecha (Entregas)

• comp.cop_fechaemision (Comprobantes)

• Tipo de rango (diario / mensual / personalizado): Mensual (automático, abarca los últimos 2 meses o más si inicio de año)

• 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_ordenservicio

• Alias (si aplica):  os

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden de servicio

• ose_montototal → Monto total de la orden

• ose_fhemision → Fecha de emisión de la orden

• usercreaid → Usuario creador

• ose_estadoPago → Estado de pago

• ose_tipoanulado → Tipo de anulación

• ose_estado → Estado activo o inactivo

• eliminado → Indicador de eliminación lógica

• Condiciones (WHERE) aplicadas: 

• Se filtran solo las órdenes de servicio que estén activas, no anuladas y no eliminadas, creadas por usuarios válidos, y cuya fecha de emisión esté dentro del rango de fechas seleccionado (desde la fecha inicial hasta la fecha final del reporte).
  
  

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

• Observaciones (ej. particiones, índices):

• Se agrupa por fecha y usuario (GROUP BY fecha, usuario).

• Los resultados se ordenan por fecha DESC.

• Usa agregaciones COUNT() y SUM().

3.2 Conexión / Base: Empresarial

• Tabla / Recurso: emp_entrega

• Alias (si aplica):  ent

• Campos utilizados (clave → descripción):

• ent_fecha → Fecha de entrega

• ent_user → Usuario que realizó la entrega

• ent_osid → Relación con emp_ordenservicio (FK)

• ent_eliminado → Indicador de eliminación lógica

• Condiciones (WHERE) aplicadas:  Se seleccionan únicamente las entregas registradas por usuarios válidos, que no estén eliminadas, y cuya fecha de entrega esté dentro del rango de fechas del reporte.

• Además, solo se consideran aquellas entregas vinculadas a órdenes de servicio que también estén activas, no anuladas y no eliminadas.
  
  

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

• emp_ordenservicio as os Llave de unión: os.ose_id = ent.ent_osid

• ose_id → Identificador de orden

• ose_montototal → Monto total

• ose_estadoPago → Estado de pago

• ose_tipoanulado → Tipo de anulación

• ose_estado → Estado de registro

• eliminado → Indicador de eliminación

• Observaciones (ej. particiones, índices):

• Se agrupa por fecha y usuario.

• Se utilizan funciones COUNT() y SUM().

3.3 Conexión / Base: Empresarial

• Tabla / Recurso: emp_comppago

• Alias (si aplica):  comp

• Campos utilizados (clave → descripción):

• cop_id → Identificador del comprobante

• cop_montoTotal → Monto total del comprobante

• cop_fechaemision → Fecha de emisión

• usercreaid → Usuario creador

• cop_estado_pago → Estado de pago

• cop_estado → Estado activo

• eliminado → Indicador de eliminación

• Condiciones (WHERE) aplicadas: Se incluyen solo los comprobantes de pago activos, no anulados, no eliminados, registrados por usuarios válidos, y emitidos dentro del rango de fechas del reporte.
  
  

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

• Observaciones (ej. particiones, índices):

• Agrupación por fecha y usuario.

• Ordenamiento por usuario DESC.

3.4 Conexión / Base: Empresarial

• Tabla / Recurso: emp_usuario

• Alias (si aplica):  No aplica

• Campos utilizados (clave → descripción):

• usr_id → Identificador del usuario

• usr_terminalid → Terminal asignada al usuario

• usr_rol → Rol o perfil del usuario

• Condiciones (WHERE) aplicadas:  No se aplica ningún filtro. Se obtienen todos los usuarios registrados para agruparlos y asociarlos con sus terminales.
  
  

• Tipo de unión con otras fuentes (JOIN y llave):  Se usa como referencia para asociar usuario → terminal.

• Observaciones (ej. particiones, índices): El resultado se agrupa por ID para crear $users_group.

3.5 Conexión / Base: Empresarial

• Tabla / Recurso: emp_terminal

• Alias (si aplica):  No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador de terminal

• ter_nombre → Nombre del terminal

• ter_zona → Zona asignada

• Condiciones (WHERE) aplicadas:  No hay condición aplicada. Se obtienen todos los terminales existentes para mostrar su nombre y zona en el reporte.
  
  

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

• Observaciones (ej. particiones, índices): Se usa para asignar nombre de terminal en el reporte.

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Órdenes, entregas y comprobantes activos y no anulados.

• Usuarios con terminal asociada.

• Exclusiones (reglas de descarte):

• Estados de pago “DA” o “AN”.

• Eliminados (eliminado = 0).

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

• Parámetros externos (si el usuario puede filtrarlo): Ninguno (fechas automáticas generadas por lógica interna).

5) Transformaciones y Reglas de negocio

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

• acciones = suma de todas las horas (0–23) por terminal y día.

• qty y amount acumulados por hora.

• Tablas creadas mensualmente con sufijo YYYY_MM.

• Mapeos de estado:

• status = 1 → correcto

• status = 0 → error al generar

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

• Se ignoran registros sin fecha, usuario o terminal.

• Rango horario debe estar entre 0–23.

• Reglas condicionales (si X entonces Y):

• Si no existe la tabla → crearla.

• Si existe → truncarla antes de insertar.

6) Estructura de salida

• Tabla/archivo destino: report_mapa_calor_YYYY_MM

• Particionado / sufijo: Mensual (YYYY_MM)

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

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

• terminal_id → VARCHAR(255) → ID de terminal

• terminal → VARCHAR(255) → Nombre

• fecha → DATE → Día

• 0–23 → VARCHAR(20) → Cantidad de acciones por hora

• acciones → VARCHAR(20) → Total diario

• created_date → DATETIME → Fecha de creación

• status → TINYINT(4) → Estado (1 activo, 0 error)

• Ordenamiento por defecto: fecha DESC

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 2 meses (con excepción de inicio de año)

• Tamaño de lote / paginado (chunking): array_chunk($detail, 900)

• Tolerancia a fallos / reintentos: Inserta registro en error_reports y continúa.

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

8) Calidad y controles

• Validaciones previas/post:

• Verificación de tabla (verifyExistTable)

• Inserción de validaciones en emp_reportes_validation

• Controles de duplicados: Truncado antes de reinserción mensual

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

• Conteo de rangos procesados

• Estado de inserción (status)

9) Dependencias externas

• APIs / servicios y endpoints: No aplica (solo BD locales)

• Autenticación / headers: No aplica

• Mapeos y contratos de datos: Interno entre conexiones empresarial, centos, reportes

10) Historial de cambios

2025-16-01 18:00 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE RAKKI

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

1) Nombre del reporte

• Nombre: Reporte Rakki

• Código / Alias: report_vulnerabilidades

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• ose_fhpreferenciapartida (fecha preferente de partida de orden)

• fecha_registro (fecha de registro del proceso en histórico)

• fecha y fecha_llegada en salida del reporte

• Tipo de rango (diario / mensual / personalizado): Mensual (últimos 2 meses calculados dinámicamente)

• 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_ordenservicio 

• Alias (si aplica): os

• Campos utilizados (clave → descripción):

• ose_termorigenatencion → origen → Terminal origen de atención.

• ose_id → idose → Identificador único de la orden de servicio.

• ose_termdestinoentrega → destino → Terminal de destino o punto de entrega.

• ose_montofinal → monto → Monto final asociado al servicio.

• ose_fhpreferenciapartida → fecha de partida o preferencia de salida del servicio.

• Condiciones (WHERE) aplicadas:

• Se consideran únicamente las órdenes de servicio activas y no eliminadas.

• Se descartan las órdenes anuladas o dadas de baja, y también aquellas que tengan algún tipo de anulación registrada.

• Además, solo se incluyen los registros que tengan adicionales de tipo “E”.
  Los registros deben pertenecer al rango de fechas definido para la ejecución del reporte (desde la fecha inicial hasta la fecha final del mes o periodo actual).
  
  

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

• LEFT JOIN emp_adicionales as adic ON adic.adc_ordenservicioid = os.ose_id

• Llave: ose_id (orden de servicio).

• Observaciones (ej. particiones, índices):

• Se aplica GROUP BY os.ose_id.

• Alias os para tabla principal y adic para tabla adicional.

• Los resultados se agrupan y procesan para cálculo de tiempos de entrega y repartos.

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador de terminal

• ter_nombre → Nombre de la terminal o agencia

• Condiciones (WHERE) aplicadas:

• No se aplican filtros (SELECT * FROM emp_terminal).

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

• No aplica JOIN directo; se usa posteriormente para mapear id_agencia → ter_nombre.

• Observaciones (ej. particiones, índices):

• Se utiliza para asociar los datos de reparto con el nombre de la agencia correspondiente.

3.3 Conexión / Base: CAPACITACIÓN

• Tabla / Recurso: emp_procesos_historial_app

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• id → Identificador del proceso

• idose → Identificador de la orden de servicio

• proceso → Tipo de proceso (ruta, desembarque, devolución, reparto)

• fecha_registro → Fecha de registro del evento

• terminal → Terminal asociada al proceso

• Condiciones (WHERE) aplicadas:

• Se filtran únicamente los procesos que corresponden a eventos de desembarque en el primer bloque, siempre que el registro esté activo y asociado a alguna de las órdenes previamente identificadas.

• En el segundo bloque, se filtran los procesos que correspondan a ruta, devolución o reparto, dentro del rango de fechas indicado para el reporte.

• Solo se consideran registros válidos (con estado activo).

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

• No aplica JOIN directo; se usa posteriormente para mapear id_agencia → ter_nombre.
  
  

• Observaciones (ej. particiones, índices):

• Se aplican filtros dinámicos por fechas.

• Se agrupan los procesos por idose para calcular los días de entrega y número de intentos.

• Se diferencia entre bases centos y centosold según el rango de fechas (antes o después de septiembre 2023).

4) Filtros globales del reporte

• Inclusiones (must-have): 

• Solo órdenes activas (ose_estado = 1).

• Solo adicionales de tipo E.

• Solo procesos con status = 1.

• Exclusiones (reglas de descarte):

• Órdenes anuladas o eliminadas.

• Pagos con estado “AN” o “DA”.
  
  

• Reglas por estado / habilitado:

• Registros con status = 1 se consideran válidos; status = 0 se registra en validación.

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

• No expone parámetros de entrada externos (fechas calculadas internamente).

5) Transformaciones y Reglas de negocio

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

• pendientes_entrega = cantidad_reparto - (dia_1 + dia_2 + dia_3 + otros_entrega)

• Cálculo de días (diff.days) entre desembarque y reparto → clasifica entregas por día (dia_1, dia_2, etc.)

• Mapeos de estado:

• qty_reparto = 1 → intento_1

• qty_reparto = 2 → intento_2

• qty_reparto = 3 → intento_3

• qty_reparto > 3 → otros_intentos

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

• Se omiten órdenes sin desembarque o sin reparto.

• Se ignoran procesos con fecha_reparto < fecha_desembarque.

• Reglas condicionales (si X entonces Y):

• Si año = 2023 y mes ≤ 9 → usar conexión centosold.

• Si tabla no existe → crear con estructura predefinida.

6) Estructura de salida

• Tabla/archivo destino: report_rakki_reparto_YYYY_MM

• Particionado / sufijo: Mensual (YYYY_MM)

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

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

• fecha → DATE → Fecha de la guía o pedido  

• id_agencia → VARCHAR(20) → Identificador del terminal o agencia  

• terminal → VARCHAR(200) → Nombre del terminal  

• fecha_llegada → DATE → Fecha de desembarque  

• cantidad_reparto → VARCHAR(10) → Total de repartos registrados  

• dia_1 → VARCHAR(10) → Entregas realizadas en el día 1  

• dia_2 → VARCHAR(10) → Entregas realizadas en el día 2  

• dia_3 → VARCHAR(10) → Entregas realizadas en el día 3  

• otros_dias_entrega → VARCHAR(10) → Entregas fuera del rango de 3 días  

• intento_1 → VARCHAR(10) → Primer intento de entrega registrado  

• intento_2 → VARCHAR(10) → Segundo intento de entrega registrado  

• intento_3 → VARCHAR(10) → Tercer intento de entrega registrado  

• otros_intentos → VARCHAR(10) → Intentos de entrega adicionales (más de 3)  

• devoluciones → VARCHAR(10) → Total de devoluciones registradas  

• pendientes_entrega → VARCHAR(10) → Entregas no completadas o pendientes  

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

• status → TINYINT(1) → Estado de inserción (1 = activo)

• Ordenamiento por defecto: fecha ASC

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 2 meses hacia atrás

• Tamaño de lote / paginado (chunking): array_chunk(..., 900) → Inserta de 900 en 900 registros

• Tolerancia a fallos / reintentos: 

• Inserta en emp_reportes_validation con status=0 si ocurre excepción.

• Transacciones con rollback (beginTransaction, commit, rollBack).

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

8) Calidad y controles

• Validaciones previas/post:

• Verificación de existencia de tabla antes de insertar.

• Truncado si ya existe tabla (comandTruncate).

• Controles de duplicados:

• Tabla vaciada antes de nueva inserción.

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

• Validación de registros exitosos vs. fallidos (status en tabla emp_reportes_validation).

9) Dependencias externas

• APIs / servicios y endpoints: No aplica (solo conexiones BD internas)

• Autenticación / headers: No aplica

• Mapeos y contratos de datos: Tablas internas del entorno ERP logístico.

10) Historial de cambios

2025-10-17 11:24 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE INFORMATION

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

1) Nombre del reporte

• Nombre: Reporte Information

• Código / Alias:  report_information 

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• ose_fhpreferenciapartida (Guías emitidas)

• ent_fecha (Entregas)

• cop_fechaemision (Comprobantes emitidos)

• cop_fhanulado (Comprobantes anulados)

• ose_fechaanulado (GRT anuladas)
  
  

• Tipo de rango (diario / mensual / personalizado): con subdivisión diaria dentro del mes. Se generan intervalos desde first_month hasta last_month del año actual, extendiéndose a diciembre del año anterior si el mes actual ≤ 2.

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

• Tabla / Recurso: tabEmployee

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del empleado

• nombre_completo → Nombre completo del empleado

• passport_number → Número de documento (usado como clave con usuario)

• Condiciones (WHERE) aplicadas: Obtiene todos los registros de empleados, ordenados alfabéticamente por nombre.

• Tipo de unión con otras fuentes (JOIN y llave): Relación lógica con usuarios (emp_usuario.usr_id = passport_number).

• Observaciones (ej. particiones, índices): Fuente API externa consumida vía método dbErp() hacia APICAPACITACION/method/send-query-database.

 

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_usuario

• Alias (si aplica): u

• Campos utilizados (clave → descripción):

• usr_id → Identificador del usuario

• usr_terminalid → ID de la terminal asignada

• usr_alias → Nombre o alias de usuario

• usr_rol → Rol del usuario

• Condiciones (WHERE) aplicadas: No aplica filtros, obtiene todos los usuarios activos.

• Tipo de unión con otras fuentes (JOIN y llave): Llave lógica con emp_persona.per_nrodocumento = emp_usuario.usr_id.

• Observaciones (ej. particiones, índices): No presenta filtros de estado ni eliminación, posible optimización agregando WHERE usr_estado = 1.

3.3 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_persona

• Alias (si aplica): p

• Campos utilizados (clave → descripción):

• per_nrodocumento → Documento de identidad (clave)

• per_nombrerzsoc, per_apellidopaterno, per_apellidomaterno → Concatenados como nombre completo

• Condiciones (WHERE) aplicadas:  Filtra personas cuyo documento (per_nrodocumento) exista en el conjunto de usuarios (usr_id).

• Tipo de unión con otras fuentes (JOIN y llave): INNER JOIN lógico por documento.

• Observaciones (ej. particiones, índices): Usado solo si no se encuentra coincidencia en la tabla de empleados.

3.4 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica): p

• Campos utilizados (clave → descripción):

• ter_id → Identificador de terminal

• ter_nombre → Nombre de terminal

• ter_zona → Zona asignada

• Condiciones (WHERE) aplicadas:  No aplica. Se obtiene toda la lista de terminales.

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN lógico mediante usr_terminalid.

• Observaciones (ej. particiones, índices): Usado para mostrar el nombre de la terminal asociada al usuario.

3.5 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): os

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden

• ose_fhpreferenciapartida → Fecha preferida de partida

• ose_montototal → Monto total de la orden

• usercreaid → Usuario que generó la orden

• ose_estadoPago, ose_tipoanulado, ose_estado, eliminado → Estados de control

• Condiciones (WHERE) aplicadas:  

• Se filtran las órdenes con:

• Estado pago distinto de AN o DA

• ose_tipoanulado vacío

• ose_estado = '1' y eliminado = '0'

• Rango de fechas (ose_fhpreferenciapartida BETWEEN fecha_inicio AND fecha_fin)

• usercreaid perteneciente al grupo de usuarios válidos.

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

• Observaciones (ej. particiones, índices):  Los resultados se agrupan por fecha y usuario.

3.6 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_entrega

• Alias (si aplica): ent

• Campos utilizados (clave → descripción):

• ent_user → Usuario que registra la entrega

• ent_fecha → Fecha de entrega

• ent_eliminado → Indicador lógico de borrado

• ent_osid → Clave foránea hacia emp_ordenservicio

• Condiciones (WHERE) aplicadas:  

• ose_estadoPago NOT IN ('DA', 'AN')

• ose_tipoanulado vacío

• os.eliminado = '0' y os.ose_estado = '1'

• ent.ent_eliminado = '0'

• Rango de fechas (ent_fecha BETWEEN inicio y fin)

• ent_user dentro de los usuarios válidos.

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN emp_ordenservicio os ON ent.ent_osid = os.ose_id

• Observaciones (ej. particiones, índices): Agrupa por fecha y usuario.

 

3.7 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_comppago

• Alias (si aplica): comp

• Campos utilizados (clave → descripción):

• cop_id → Identificador de comprobante

• cop_montoTotal → Monto total

• cop_fechaemision → Fecha de emisión

• cop_estado_pago → Estado del comprobante

• usercreaid → Usuario que generó el comprobante

• Condiciones (WHERE) aplicadas:  

• cop_estado_pago != 'AN'

• cop_estado = '1'

• eliminado = '0'

• Rango de fechas (cop_fechaemision BETWEEN inicio y fin)

• Usuario en lista válida.

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

• Observaciones (ej. particiones, índices): Agrupado por fecha y usuario.

3.8 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_comppago

• Alias (si aplica): cop

• Campos utilizados (clave → descripción):

• cop_id

• cop_fhanulado

• cop_estado_pago

• useranula

• cop_nota_credito

• Condiciones (WHERE) aplicadas:  

• cop_estado_pago = 'AN'

• cop_nota_credito IS NULL OR cop_nota_credito != '1'

• cop_fhanulado BETWEEN inicio y fin

• useranula dentro del grupo de usuarios válidos.

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

• Observaciones (ej. particiones, índices): Se obtienen comprobantes anulados, agrupados por fecha y usuario.

3.8 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio (GRT anuladas)

• Alias (si aplica): os

• Campos utilizados (clave → descripción):

• ose_id

• ose_fechaanulado

• ose_estadoPago

• ose_personaanulado

• ose_remitecontactofono

• Condiciones (WHERE) aplicadas:  

• ose_estadoPago = 'AN'

• ose_fechaanulado dentro del rango de fechas

• ose_personaanulado en la lista de usuarios válidos

• ose_remitecontactofono nulo o distinto de ['WEB', 'REGISTRA', 'CLIENTES']

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

• Observaciones (ej. particiones, índices): Filtra GRT anuladas sin remitentes especiales.

4) Filtros globales del reporte

• Inclusiones (must-have):

• Usuarios activos (ose_estado = '1', cop_estado = '1')

• Registros no eliminados (eliminado = '0')
  
  

• Exclusiones (reglas de descarte): Comprobantes o guías anuladas (estadoPago IN ('AN','DA'))

• Reglas por estado / habilitado: Solo documentos vigentes y operativos.

• Parámetros externos (si el usuario puede filtrarlo): Año y rango de meses se calculan automáticamente; no son ingresados manualmente.

5) Transformaciones y Reglas de negocio

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

• Se consolida información diaria por usuario, terminal y fecha.

• Cálculos: cantidad, monto sumados por tipo (GRT, comprobantes, entregas, anulaciones).
  
  

• Mapeos de estado:

• usr_id ↔ passport_number ↔ per_nrodocumento

• Terminales por usr_terminalid
  
  

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

• Evita inserción de tablas vacías.

• Control de existencia de tabla base antes de crear o reemplazar.
  
  

• Reglas condicionales (si X entonces Y):

• Si el mes ≤ 2, también incluye diciembre del año anterior.

• Si una tabla mensual no existe, se crea clonando report_information.

 

6) Estructura de salida

• Tabla/archivo destino: report_information_YYYY_MM

• Particionado / sufijo: Mensual (sufijo año_mes).

• Clave(s) primaria(s) o únicas: (fecha, usuario)

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

• fecha → DATE → Día del registro  

• terminal_id → INT(5) → Identificador del terminal  

• terminal → VARCHAR(150) → Nombre del terminal  

• usuario → VARCHAR(13) → Identificador del usuario  

• usuario_nombre → VARCHAR(80) → Nombre completo del usuario  

• usuario_rol → VARCHAR(80) → Rol asignado al usuario  

• grt_emitidas_cantidad → INT → Total de guías emitidas  

• grt_emitidas_monto → DOUBLE(12,2) → Monto total de guías emitidas  

• grt_entregadas_cantidad → INT → Total de entregas realizadas  

• grt_entregadas_monto → DOUBLE(12,2) → Monto total de entregas realizadas  

• comprobantes_emitidos_cantidad → INT → Total de comprobantes emitidos  

• comprobantes_emitidos_monto → DOUBLE(12,2) → Monto total de comprobantes emitidos  

• grt_anuladas_cantidad → INT → Total de guías anuladas  

• comprobantes_anuladas_cantidad → INT → Total de comprobantes anulados  

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

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

• Ordenamiento por defecto: fecha ASC, usuario ASC

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 2 meses anteriores si aplica.

• Tamaño de lote / paginado (chunking): Inserciones por lotes de 300 registros.

• Tolerancia a fallos / reintentos:

• Reintentos hasta 4 veces para RENAME TABLE.

• Fallback DELETE+INSERT si el swap falla.

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

8) Calidad y controles

• Validaciones previas/post:

• Confirmación de existencia de tabla base.

• Log de errores en error_reports.
  
  

• Controles de duplicados: Reemplazo controlado (safeReplaceMonthlyTable) evita duplicados.

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

• Conteo de registros insertados y estado de validación (emp_reportes_validation).

9) Dependencias externas

• APIs / servicios y endpoints: APICAPACITACION/method/send-query-database

• Autenticación / headers: JSON Headers (Accept, Content-Type)

• Mapeos y contratos de datos: 

• Servicios Internos: $this->reports, $this->empresarial, $this->centos (conexiones BD internas)

• Contratos: Formato JSON con campos valor, response, msn.

10) Historial de cambios

2025-10-15 12:46 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE AMOUNT PLATAFORMAS

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

1) Nombre del reporte

• Nombre: Reporte Amount Plataformas

• Código / Alias: report_amount_platforms

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: 

• ose_fhpreferenciapartida

• cop_fechaemision 

• created_date 

• fecha_consult

• fecha

• Tipo de rango (diario / mensual / personalizado): Mensual, con generación por días dentro del rango (generateArrayOfDays) y posible extensión al último mes del año anterior (si el mes actual es 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: Empresarial

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): os

• Campos utilizados (clave → descripción):

• ose_id → Identificador de la orden de servicio.

• ose_termorigenatencion → Terminal de origen de la orden.

• ose_termdestinoentrega → Terminal de destino de la orden.

• ose_fhpreferenciapartida → Fecha de preferencia de partida.

• ose_estado → Estado de la orden (1 = activo, otros valores indican cancelado o inactivo).

• ose_estadoPago → Estado del pago (AN = anulado, DA = dado de baja).

• ose_tipoanulado → Tipo de anulación, vacío si está vigente.

• eliminado → Indicador lógico de eliminación.
  
  

• Condiciones (WHERE) aplicadas:

• Filtra las órdenes de servicio activas y vigentes dentro del rango de fechas ($fecha 00:00:00 hasta $fecha 23:59:59), excluyendo las anuladas o dadas de baja. Solo se consideran registros no eliminados.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN con emp_entrega (campo llave: ent.ent_osid = os.ose_id).
  
  

• Observaciones (ej. particiones, índices): La tabla emp_ordenservicio suele tener índices por campos ose_id, ose_fhpreferenciapartida, y ose_estado para optimizar las consultas de rango y estado.

3.2 Conexión / Base: Empresarial

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): os

• Campos utilizados (clave → descripción):

• ent_id → Identificador del registro de entrega.

• ent_persona → Documento o ID de la persona asociada a la entrega.

• ent_osid → Identificador de la orden de servicio vinculada.

• ent_eliminado → Indicador de eliminación lógica.
  
  

• Condiciones (WHERE) aplicadas:

• Se filtran entregas no eliminadas (ent_eliminado = 0) asociadas a personas específicas (lista de DNI o IDs) dentro del rango de fechas.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN con emp_ordenservicio (llave: ent.ent_osid = os.ose_id).
  
  

• Observaciones (ej. particiones, índices):  Campos ent_id y ent_osid comúnmente indexados.

3.3 Conexión / Base: Empresarial

• Tabla / Recurso: emp_terminal

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• ter_id → Identificador de la terminal.

• ter_nombre → Nombre descriptivo de la terminal.

• ter_zona → Zona geográfica o grupo operativo.
  
  

• Condiciones (WHERE) aplicadas:

• No aplica filtrado. Se obtiene el listado completo de terminales activas registradas en la base de datos.
  
  

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

• Observaciones (ej. particiones, índices):  Posible índice sobre ter_id (PK) y ter_zona para agrupación posterior.

 

3.4 Conexión / Base: Empresarial

• Tabla / Recurso: emp_detalle_comppago

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• id → Identificador del detalle.

• dcp_ose_id → Identificador de la orden de servicio relacionada.

• dcp_cop_id → Identificador del comprobante de pago vinculado.
  
  

• Condiciones (WHERE) aplicadas:

• Obtiene registros de detalle que pertenecen a órdenes de servicio procesadas (whereIn(dcp_ose_id, $groups)), agrupando los comprobantes vinculados a cada orden.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): No aplica JOIN explícito, pero se vincula lógicamente con emp_comppago mediante dcp_cop_id.
  
  

• Observaciones (ej. particiones, índices): Índices comunes en dcp_ose_id y dcp_cop_id para relaciones y búsquedas cruzadas.

3.5 Conexión / Base: Empresarial

• Tabla / Recurso: emp_comppago

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• cop_id → Identificador del comprobante de pago.

• cop_fechaemision → Fecha de emisión del comprobante.

• cop_terminal → Terminal de origen.

• cop_estado_pago → Estado del pago (nulo o diferente de “AN” indica activo).

• cop_tipo → Tipo de comprobante (solo se consideran los de tipo “NC” → Nota de Crédito).
  
  

• Condiciones (WHERE) aplicadas:

• Selecciona comprobantes tipo “NC” emitidos en el rango horario del día (00:00:00 a 23:59:59) y que no estén anulados (cop_estado_pago nulo o distinto de “AN”).
  
  

• Tipo de unión con otras fuentes (JOIN y llave): Relación lógica con emp_detalle_comppago (llave: dcp_cop_id = cop_id).
  
  

• Observaciones (ej. particiones, índices): Índices esperados en cop_id, cop_fechaemision y cop_estado_pago por alto volumen de registros.

 

3.6 Conexión / Base: Empresarial

• Tabla / Recurso: emp_os_detalle

• Alias (si aplica): Ninguno

• Campos utilizados (clave → descripción):

• osd_id → Identificador del detalle.

• osd_osid → Identificador de la orden de servicio.

• osd_descripcion → Código de tipo de paquete (3 = sobre, 1096 = xxs, 1090 = xs, 5 = s, 1093 = m, 2 = l).

• osd_unidad → Cantidad de unidades.

• osd_montototal → Monto total del detalle.

• osd_eliminado → Indicador lógico de eliminación.
  
  

• Condiciones (WHERE) aplicadas:

• Filtra los detalles activos (osd_eliminado = 0) y solo de los tipos válidos de paquete definidos en el array de referencia.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): Vinculación lógica con emp_ordenservicio a través de osd_osid = ose_id.
  
  

• Observaciones (ej. particiones, índices): Campos osd_osid y osd_descripcion con índice para mejorar rendimiento en consultas por tipo.

4) Filtros globales del reporte

• Inclusiones (must-have):

• Órdenes activas y no anuladas.

• Comprobantes válidos (no anulados).

• Terminales habilitadas.
  
  

• Exclusiones (reglas de descarte):

• Órdenes anuladas o con estado de pago “AN” o “DA”.

• Entregas eliminadas.
  
  

• Reglas por estado / habilitado: Solo se consideran órdenes con ose_estado = 1.

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

• Año y mes dinámico ($year, $last_month, $first_month)

• Fechas de inicio y fin generadas automáticamente.

5) Transformaciones y Reglas de negocio

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

• paquete_*, sobre, efectivo, banco, billetera_electronica → acumulados por tipo y terminal.

• type = “envia_ya” o “pro” según rcontacto.

• Totales diarios por origen y destino.

 

• Mapeos de estado:

• ose_servpagotipo = 1 → efectivo

• ose_servpagotipo = 2 → contra_entrega

• cop_tipopago = QR → billetera_electronica

• cop_tipopago = BANCO → banco
  
  

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

• Reglas condicionales (si X entonces Y):

• Ignora órdenes donde ose_remitecontactomail != 1.

• Incluye datos del año anterior si mes actual ≤ 2.

6) Estructura de salida

• Tabla/archivo destino: report_monto_plataformas_YYYY_MM

• Particionado / sufijo: Mensual (YYYY_MM)

• Clave(s) primaria(s) o únicas: id (auto-increment)

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

• fecha → DATE → Día del registro  

• agencia_id → VARCHAR(100) → Identificador de la agencia  

• agencia → VARCHAR(255) → Nombre de la agencia  

• plataforma → VARCHAR(255) → Tipo de plataforma utilizada (“envia_ya”, “pro”)  

• cantidad_origen → VARCHAR(10) → Cantidad enviada desde el punto de origen  

• cantidad_destino → VARCHAR(10) → Cantidad recibida en el punto de destino  

• monto_origen → VARCHAR(10) → Monto total emitido desde origen  

• monto_destino → VARCHAR(10) → Monto total recibido en destino  

• sobre / paquete_* → VARCHAR(10) → Cantidades agrupadas según tipo de paquete (sobre, paquete, etc.)  

• efectivo → VARCHAR(10) → Total de operaciones pagadas en efectivo  

• banco → VARCHAR(10) → Total de operaciones con pago bancario  

• billetera_electronica → VARCHAR(10) → Total de pagos mediante billetera electrónica  

• contra_entrega → VARCHAR(10) → Total de operaciones con modalidad contra entrega  

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

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

• Ordenamiento por defecto: fecha ASC, agencia_id ASC

 

 

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Mensual, ejecutado automáticamente por rango de fechas.

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

• Tolerancia a fallos / reintentos: Manejo con try/catch y rollback en errores.

• 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 o truncado según corresponda.

• Controles de duplicados: Se ejecuta truncate si la tabla ya existe antes de insertar datos nuevos.

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

• Creación exitosa de tabla mensual.

• Estado en emp_reportes_validation.status (1=ok, 0=error).

9) Dependencias externas

• APIs / servicios y endpoints: No aplica (todo interno a BD).

• Autenticación / headers:  No aplica.

• Mapeos y contratos de datos: Uso interno de modelos $this->empresarial, $this->reportes, $this->centos.

10) Historial de cambios

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

REPORTE ABASTECIMIENTO TIENDA

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

1) Nombre del reporte

• Nombre: Reporte Abastecimiento Tienda

• Código / Alias:  report_abastecimiento_tienda

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• first_date y second_date (rango de fechas determinado dinámicamente por obtainRangeDaysByYear)

• created_date (fecha de creación del registro)
  
  

• Tipo de rango (diario / mensual / personalizado): Mensual, ya que se obtiene un rango de días por mes (obtainRangeDaysByYear($year, $last_month, $first_month))

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: CAPACITACION

• Tabla / Recurso: report_abastecimiento_tienda

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• id → Identificador único del registro (clave primaria).

• name → Nombre o código del producto.

• item_group → Categoría o grupo del ítem.

• item_name → Nombre completo del ítem o producto.

• warehouse → Almacén o tienda donde se gestiona el stock.

• stock → Cantidad disponible actual en inventario.

• month-entry-0 → Entradas del mes actual.

• month-entry-1 → Entradas del mes anterior.

• month-entry-2 → Entradas de hace dos meses.

• month-entry-3 → Entradas de hace tres meses.

• month-out-0 → Salidas del mes actual.

• month-out-1 → Salidas del mes anterior.

• month-out-2 → Salidas de hace dos meses.

• month-out-3 → Salidas de hace tres meses.

• productValueProm → Valor promedio del producto según movimientos.

• valueLastBuy → Valor de la última compra registrada.

• lastInspection → Fecha de la última supervisión o inspección.

• daysInspection → Días transcurridos desde la última inspección.

• cantidad_supervisiones → Número de supervisiones realizadas.

• cantidad_reconciliaciones → Número de reconciliaciones o revisiones.

• sucursal → Sucursal asociada al registro.

• departamento → Departamento de la sucursal o zona.

• id_terminal → Identificador de terminal o punto de venta.

• created_date → Fecha y hora de creación del registro.

• status → Estado del registro (activo/inactivo).
  
  

• Condiciones (WHERE) aplicadas:

• Trae los registros generados dentro del rango de fechas determinado por first_day y last_day, correspondiente al mes actual o a los meses previos que define el método obtainRangeDaysByYear.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): No aplica. Las inserciones se realizan directamente en la tabla destino sin combinación con otras fuentes.
  
  

• Observaciones (ej. particiones, índices): 

• Se agrega un índice en el campo status mediante ALTER TABLE.

• Las tablas se crean dinámicamente con estructura fija por rango temporal.

• Motor de base de datos: InnoDB con charset latin1.

4) Filtros globales del reporte

• Inclusiones (must-have): Registros de la tabla "tienda" dentro del rango de fechas del mes actual

• Exclusiones (reglas de descarte): No se aplica exclusión explícita

• Reglas por estado / habilitado: Solo se indexa el campo status para controlar estado activo/inactivo

• Parámetros externos (si el usuario puede filtrarlo): Año ($year) y meses ($last_month, $first_month) se obtienen del sistema (no parametrizables por usuario)

5) Transformaciones y Reglas de negocio

• Derivaciones de campos (cómo se calculan): Los campos month-entry y month-out son generados mensualmente por iteración sobre el rango

• Mapeos de estado: 

• status = 1 → Registro actualizado correctamente

• status = 0 → Error en carga / validación fallida
  
  

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

• Validación de existencia de tabla con verifyExistTable()

• Inserción en error_reports en caso de fallo

• Registro de validaciones en emp_reportes_validation
  
  

• Reglas condicionales (si X entonces Y):

• Si la tabla no existe → se crea

• Si se detecta error en inserción → se graba el fallo y continúa siguiente rango

6) Estructura de salida

• Tabla/archivo destino: report_abastecimiento_tienda (creada dinámicamente)

• Particionado / sufijo: Implícito mensual (por rango de fechas)

• Clave(s) primaria(s) o únicas: id (INT AUTO_INCREMENT PRIMARY KEY)

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

• id → INT AUTO_INCREMENT → Identificador único autoincremental  

• name → VARCHAR(255) → Nombre del producto o registro  

• item_group → VARCHAR(150) → Grupo o categoría del ítem  

• item_name → VARCHAR(255) → Nombre completo del artículo  

• warehouse → VARCHAR(150) → Almacén de procedencia del producto  

• stock → DOUBLE → Stock actual disponible  

• month-entry-0 ... month-entry-3 → DOUBLE → Entradas mensuales de los últimos 4 meses  

• month-out-0 ... month-out-3 → DOUBLE → Salidas mensuales de los últimos 4 meses  

• productValueProm → DOUBLE → Valor promedio del producto  

• valueLastBuy → DOUBLE → Valor correspondiente a la última compra registrada  

• lastInspection → DATE → Fecha de la última inspección realizada  

• daysInspection → INT → Días transcurridos desde la última inspección  

• cantidad_supervisiones → INT → Total de supervisiones realizadas  

• cantidad_reconciliaciones → INT → Total de reconciliaciones registradas  

• sucursal → VARCHAR(150) → Sucursal o tienda correspondiente  

• departamento → VARCHAR(150) → Departamento asociado al registro  

• id_terminal → VARCHAR(100) → Identificador del terminal relacionado  

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

• status → TINYINT(1) → Estado lógico del registro (1 = activo / 0 = inactivo)

• 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): 1 mes (por rango obtenido)

• Tamaño de lote / paginado (chunking): 300 registros (array_chunk($data_report, 300))

• Tolerancia a fallos / reintentos: Registro de errores y continuación (try/catch)

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

8) Calidad y controles

• Validaciones previas/post:

• Creación/verificación de tabla

• Validación de inserciones en emp_reportes_validation

• Controles de duplicados: no aplica

• Métricas de completitud (qué se monitorea): Validación de registros exitosos vs. con error (campo status)

9) Dependencias externas

• APIs / servicios y endpoints:

• $this->reportcontroller->obtainRangeDaysByYear()

• $this->reportcontroller->verifyExistTable()

• $this->reportcontroller->consultaSql()

• $this->report() (función interna que obtiene los datos de “tienda”)
  
  

• Autenticación / headers: No aplica

• Mapeos y contratos de datos: Inserciones controladas en emp_reportes_validation y error_reports

10) Historial de cambios

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

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

REPORTE ABASTECIMIENTO

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

1) Nombre del reporte

• Nombre: REPORTE ABASTECIMIENTO

• Código / Alias: report_abastecimiento 

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: first_date, second_date (obtenidos de obtainRangeDaysByYear)

• Tipo de rango (diario / mensual / personalizado): Mensual — el método obtiene los rangos de días por mes dentro del año actual ($year, $last_month, $first_month).

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

• Zona horaria: La del servidor

3) Origen de datos (tablas/APIs)

• Conexión / Base: CDTALLERES

• Tabla / Recurso: report_abastecimiento

• Alias (si aplica): no aplica

• Campos utilizados (clave → descripción):

• id → Identificador autoincremental

• name → Nombre del producto o ítem

• item_group → Grupo o categoría del ítem

• item_name → Descripción completa del ítem

• warehouse → Almacén o bodega de registro

• stock → Cantidad en stock disponible

• month-entry-0 → Entradas del mes actual

• month-entry-1 → Entradas del mes anterior (1 mes atrás)

• month-entry-2 → Entradas de hace 2 meses

• month-entry-3 → Entradas de hace 3 meses

• month-out-0 → Salidas del mes actual

• month-out-1 → Salidas del mes anterior (1 mes atrás)

• month-out-2 → Salidas de hace 2 meses

• month-out-3 → Salidas de hace 3 meses

• productValueProm → Valor promedio del producto

• valueLastBuy → Valor de la última compra

• lastInspection → Fecha de última inspección del ítem

• daysInspection → Días transcurridos desde la última inspección

• cantidad_supervisiones → Número de supervisiones realizadas

• cantidad_reconciliaciones → Número de conciliaciones registradas

• sucursal → Sucursal a la que pertenece el almacén

• departamento → Departamento asociado a la sucursal

• id_terminal → Identificador del terminal o punto de control

• created_date → Fecha de creación del registro

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

• Condiciones (WHERE) aplicadas: 

• El proceso obtiene datos desde el servicio report() filtrando los registros cuya fecha de creación o actualización se encuentre dentro del rango entre first_day y last_day de cada mes generado en el período actual.
  
  

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

• No aplica (los datos se insertan directamente en una tabla creada dinámicamente, sin uniones con otras tablas).
  
  

• Observaciones (ej. particiones, índices): 

• Se crea un índice sobre el campo status mediante ALTER TABLE para optimizar las consultas.

• Las tablas se generan dinámicamente según el rango de fechas (CREATE TABLE report_abastecimiento ...) y se validan en emp_reportes_validation.

4) Filtros globales del reporte

• Inclusiones (must-have): Todos los registros generados dentro del rango mensual definido.

• Exclusiones (reglas de descarte): No se definen exclusiones explícitas.

• Reglas por estado / habilitado: Solo se indexa y marca con status = 1 por defecto.

• Parámetros externos (si el usuario puede filtrarlo): No recibe filtros desde el usuario; todo es generado internamente.

5) Transformaciones y Reglas de negocio

• Derivaciones de campos (cómo se calculan):  Ninguna derivación directa; los datos se insertan tal como los devuelve $this->report().

• Mapeos de estado:

• status = 1 → ejecución exitosa,

• status = 0 → error durante el proceso.
  
  

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

• Se valida la existencia de la tabla con verifyExistTable.

• Si no existe o hay error, se registra en error_reports.
  
  

• Reglas condicionales (si X entonces Y):

• Si verifyExistTable retorna false, se salta la carga y se guarda error.

• Si hay excepción, se registra como error en emp_reportes_validation.

6) Estructura de salida

• Tabla/archivo destino:  report_abastecimiento

• Particionado / sufijo: No se define; tabla única.

• Clave(s) primaria(s) o únicas: id (PRIMARY KEY)

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

• id → INT → Identificador autoincremental del registro  

• name → VARCHAR(255) → Nombre del producto  

• item_group → VARCHAR(150) → Grupo o categoría del ítem  

• item_name → VARCHAR(255) → Nombre completo del ítem  

• warehouse → VARCHAR(150) → Almacén de procedencia  

• stock → DOUBLE → Stock actual disponible  

• month-entry-0..3 → DOUBLE → Entradas por mes (últimos 4 meses)  

• month-out-0..3 → DOUBLE → Salidas por mes (últimos 4 meses)  

• productValueProm → DOUBLE → Valor promedio del producto  

• valueLastBuy → DOUBLE → Valor de la última compra registrada  

• lastInspection → DATE → Fecha de la última inspección realizada  

• daysInspection → INT → Días transcurridos desde la última inspección  

• cantidad_supervisiones → INT → Total de supervisiones registradas  

• cantidad_reconciliaciones → INT → Total de conciliaciones realizadas  

• sucursal → VARCHAR(150) → Sucursal de registro  

• departamento → VARCHAR(150) → Departamento asociado  

• id_terminal → VARCHAR(100) → Identificador del terminal  

• created

• Ordenamiento por defecto: No se define explícitamente.

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Un mes por ejecución.

• Tamaño de lote / paginado (chunking): Inserciones en lotes de 300 registros (array_chunk($data_report, 300)).

• Tolerancia a fallos / reintentos: Control mediante try/catch con registro en tabla de errores.

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

8) Calidad y controles

• Validaciones previas/post:

• Verificación de existencia de tabla antes de inserción.

• Registro de validación en emp_reportes_validation.

• Controles de duplicados: No se implementan explícitamente.

• Métricas de completitud (qué se monitorea): No se definen métricas automáticas; sólo logs de éxito/error.

9) Dependencias externas

• APIs / servicios y endpoints: Interno → $this->reportcontroller->obtainRangeDaysByYear(), verifyExistTable(), consultaSql()

• Autenticación / headers: No aplica (llamadas internas).

• Mapeos y contratos de datos: $this->report() devuelve el dataset principal que se inserta en la tabla.

10) Historial de cambios

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

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:

• ser.parent = ord.name.
  
  

 

• 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

REPORTE CENTRO COSTO AGENCIAS

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

1) Nombre del reporte

• Nombre:  Reporte Centro Costo Agencia

• Código / Alias:  report_centro_costo_agencia

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• Rango principal: rango mensual calculado por updateAgencias() a partir de $first_day y $last_day (generado con range_days en utils).
  
  

• Fechas utilizadas en consultas internas: fechas diarias generadas por generateArrayOfDays() (para consultar tablas diarias report_shipping_amount_YYYY_MM_DD).
  
  

• Fechas en filtros de sub-consultas: list_fecha (gastos), start_date (nómina), fecha_de_inicio_contrato (alquileres), ose_fhpreferenciapartida (ordenes de servicio).
  
  

• Tipo de rango (diario / mensual / personalizado): Mensual (el proceso itera por meses; updateAgencias calcula $totalMonths = 6 meses hacia atrás, genera rangos mensuales y los procesa).

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

• Tabla / Recurso: Requerimiento de Personal Lima

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del requerimiento.

• fecha_de_requerimiento → Fecha de solicitud de requerimiento.

• _assign → Usuario(s) asignado(s) como reclutador.

• compromiso_cobertura → Fecha de compromiso de cobertura.

• documento_convocatoria → Documento de convocatoria asociado.

• posicion_solicitada → Puesto solicitado.

• estado_rp → Estado del requerimiento de personal.
  
  

• Condiciones (WHERE) aplicadas: Filtra los registros cuya fecha_de_requerimiento se encuentre entre las fechas date_start y date_end.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): Relaciona su campo documento_convocatoria con el campo oportunidad_empleo del recurso CV Filtrado.
  
  

• Observaciones (ej. particiones, índices): Usa índices por fecha (fecha_de_requerimiento) para mejorar el filtrado mensual.

3.2 Conexión / Base: CAPACITACION

• Tabla / Recurso:  CV Filtrado

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del CV.

• numero_documento → DNI o número de documento del postulante.

• ombre_solicitante → Nombre del postulante.

• puesto_oportunidad → Puesto al que postula.

• oportunidad_empleo → Documento de convocatoria al que aplica.

• creation → Fecha de registro del CV.
  
  

• Condiciones (WHERE) aplicadas: Filtra los registros cuyo oportunidad_empleo se encuentre dentro de los valores del campo documento_convocatoria de la tabla Requerimiento de Personal Lima.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): JOIN lógico con “Requerimiento de Personal Lima” mediante oportunidad_empleo = documento_convocatoria.
  
  

• Observaciones (ej. particiones, índices): 

• Puede requerir índice en oportunidad_empleo para optimizar la búsqueda por convocatoria.

3.3 Conexión / Base: CAPACITACION

• Tabla / Recurso:  Entrevista

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del registro de entrevista.

• fecha_entrevista → Fecha de la entrevista.

• contratado → Estado del candidato (Contratado / No Contratado).

• numero_de_documento → Documento del candidato entrevistado.la entrevista.ro de CV.
  
  

• Condiciones (WHERE) aplicadas: Filtra los registros cuyo enlace_cv se encuentre en la lista de identificadores (name) provenientes de CV Filtrado.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): JOIN lógico con CV Filtrado mediante enlace_cv = name.
  
  

• Observaciones (ej. particiones, índices): 

• El campo contratado permite filtrar posteriormente los candidatos contratados.

3.4 Conexión / Base: CAPACITACION

• Tabla / Recurso:  Contrato de Trabajo

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• name → Identificador del contrato.

• fecha_inicio → Fecha de inicio del contrato laboral.

• labor → Puesto o función asignada.

• dni → Documento de identidad del trabajador.
  
  

• Condiciones (WHERE) aplicadas: Filtra los contratos cuyo dni coincida con los numero_de_documento de las entrevistas donde contratado = “Contratado”.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): JOIN lógico con Entrevista mediante dni = numero_de_documento.
  
  

• Observaciones (ej. particiones, índices): 

• Optimiza mediante índices en dni y fecha_inicio.

3.5 Conexión / Base: CAPACITACION

• Tabla / Recurso:  error_reports

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• report → Nombre del reporte con error.

• error → Descripción del error.

• created_date → Fecha de creación del registro de error.
  
  

• Condiciones (WHERE) aplicadas: Inserta un registro solo cuando la tabla report_requerimiento_personal_lima_YYYY_MM no se puede crear correctamente.
  
  

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

• Observaciones (ej. particiones, índices): Tabla auxiliar de control de errores generada por el proceso PHP.

3.6 Conexión / Base: CAPACITACION

• Tabla / Recurso:  emp_reportes_validation

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• report → Nombre del reporte ejecutado.

• first_date → Fecha inicial del rango procesado.

• second_date → Fecha final del rango procesado.

• created_date → Fecha y hora de creación del registro.

• status → Estado de la ejecución (1 = Correcto / 0 = Error).
  
  

• Condiciones (WHERE) aplicadas: Se inserta un registro por cada ejecución del método show() indicando el estado de validación del proceso.
  
  

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

• Observaciones (ej. particiones, índices): Utilizada como bitácora de control de actualizaciones automáticas de reportes.

3.7 Conexión / Base: CAPACITACION

• Tabla / Recurso:  emp_reportes_validation

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción): Estructura base de los reportes mensuales que se duplican dinámicamente (ejemplo: report_requerimiento_personal_lima_2025_10).
  
  

• Condiciones (WHERE) aplicadas:

• Usada como plantilla para crear nuevas tablas mensuales mediante:

• CREATE TABLE report_requerimiento_personal_lima_YYYY_MM LIKE report_requerimiento_personal_lima_struct.
  
  

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

• Observaciones (ej. particiones, índices): Estructura patrón reutilizada para particionar datos mensuales. 

5) Transformaciones y Reglas de negocio

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

• ventas = sum(enviados + recibidos) por sucursal en el mes (agregado desde tablas diarias).

• 10_porciento (ingreso_ventas) = 0.1 * ventas.

• total_planilla = suma de gross_pay de get_salary_employees por sucursal.

• depositos, gastos_directos, gastos_indirectos = sumas agregadas por agencia desde get_detail_expenses.

• locales = montos de alquileres (o monto por defecto desde branch data) — si moneda USD, se convierte a soles: local_soles = locales * exchange_rate.

• utilidad = ingreso_ventas - (total_planilla + gastos_directos + locales).

• utilidad_porcentaje = utilidad / ingreso_ventas * 100 (cuidado division by zero manejada en código: si ingreso_ventas == 0 → 0).

• personal (porcentual) = total_planilla / ingreso_ventas * 100.

• local (porcentual) = locales / ingreso_ventas * 100.
  
  

• Mapeos de estado: 

• categoria → asignada por assign_category() con rangos: >=15000 → Categoría 1; 10000–14999 → Categoría 2; 5000–9999 → Categoría 2; 2500–4999 → Categoría 4; 1250–2499 → Categoría 5; <1250 → Categoría 6. Además, identificadores 4 y 5 se forzan a Categoría 1.

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

• Si alguna función auxiliar crítica devuelve status:false, agencias() retorna ese error y updateAgencias() guarda el resultado en $updates[$fecha] (registro de fallo).

• Si no existen empleados, salarios o datos de branch el proceso aborta para ese mes (retorna error correspondiente).

• Se valida existencia previa de tablas diarias al iterar (implícito por consulta; si la tabla no existe la consulta falla y se captura el error).
  
  

• Reglas condicionales (si X entonces Y):

• Si get_currency_exchange devuelve tipo de cambio y un rental está en USD → monto se convierte a PEN con exchange_rate.

• Si salaryJSON no contiene una sucursal → la sucursal se salta (continue).

• Si paymentsLocalesJson contiene metraje → se usa ese metraje; en caso contrario se usa metro_fijo desde branch data o valores de dataLocalesCondition.

• Si no hay cvs/datos en subconsulta correspondiente → se generan filas con valores nulos para ciertos campos (comportamiento similar al otro reporte mostrado).

6) Estructura de salida

• Tabla/archivo destino: report_centro_costo_agencia

• Particionado / sufijo: No aplica (tabla única). Observación: los orígenes sí son diarios (report_shipping_amount_YYYY_MM_DD) — la tabla destino no se crea por mes en este fragmento (es fija).
  
  

• Clave(s) primaria(s) o únicas: id → INT AUTO_INCREMENT PRIMARY KEY (definido en $columns).
  
  

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

• id → INT AUTO_INCREMENT → Identificador único de la fila (PK interna)  

• periodo → VARCHAR(20) → Nombre del mes correspondiente (ej. "ENERO")  

• sucursal → VARCHAR(225) → Nombre de la agencia o sucursal  

• id_sucursal → INT → Identificador interno de la sucursal  

• categoria → VARCHAR(20) → Categoría asignada (Categoría 1 a 6)  

• ventas → FLOAT → Total de ventas u operaciones del periodo (envíos + recepciones)  

• n_personas → INT → Número de personas registradas en planilla  

• cant_ope → INT → Cantidad de operaciones u operativos realizados  

• 10_porciento → FLOAT → 10% del total de ventas (ingreso estimado)  

• personal → VARCHAR(20) → Total de gasto en personal (almacenado como texto, evaluable a numérico)  

• servicio → INT → Monto de gastos directos por servicio  

• local → VARCHAR(20) → Monto asociado al local (puede convertirse a valor en soles)  

• utilidad → FLOAT → Utilidad calculada (ingresos menos costos)  

• utilidad_porcentaje → VARCHAR(20) → Porcentaje de utilidad (ej. "12.34 %")  

• personal_porcentaje → VARCHAR(20) → Porcentaje de gasto en personal sobre las ventas  

• local_porcentaje → VARCHAR(20) → Porcentaje de gasto en local sobre las ventas  

• depositos → INT → Total de depósitos por agencia  

• gastos_directos → INT → Total de gastos directos registrados  

• gastos_indirectos → INT → Total de gastos indirectos registrados  

• metraje_m2 → VARCHAR(20) → Metraje del local en metros cuadrados  

• ano → INT → Año correspondiente al periodo  

• created_date → DATETIME → Fecha y hora de creación del registro (DEFAULT CURRENT_TIMESTAMP)  

• status → TINYINT(4) → Estado del registro (1 = activo por defecto)

• Ordenamiento por defecto: No se especifica ORDER BY en el código — el orden depende del insert/DB; para consumo se recomienda ordenar por ano DESC, periodo DESC si se requiere mostrar últimos primero.

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Se recalcula por mes (se construyen rangos mensuales con utils->range_days($year,$month,$month)) y, para algunas métricas, se itera por días dentro del mes (consulta diaria de envíos).
  
  

• Tamaño de lote / paginado (chunking): No aplica chunking explícito en updateAgencias() ni en agencias(); las consultas se hacen por mes y por día. (Sin embargo, si la inserción se realiza vía utils->base_report_sin_servicio, ese método podría implementar su propio chunking — no visible en este fragmento).

• Tolerancia a fallos / reintentos: 

• El flujo captura errores de cada función auxiliar: si una función devuelve status:false se propaga y updateAgencias() guarda el resultado en $updates[$fecha] y continúa con los siguientes meses.

• No hay reintentos automáticos explícitos en este código; la tolerancia es registrar el fallo (en $updates) y seguir con la siguiente iteración.
  
  

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

8) Calidad y controles

• Validaciones previas/post:

• Previas: Verificación de existencia y datos devueltos por funciones auxiliares (get_branch_erp, get_branch_empresarial, get_campos_origen_atencion, get_rental_contract, get_currency_exchange, get_detail_expenses, get_employees, get_salary_employees). Si alguna falla, se retorna el error y el mes queda registrado en $updates con ese error.

• Post: updateAgencias() acumula en $updates los resultados por mes (pueden incluir status:false y la causa). No se ve registro en tabla de logs explícita dentro de este fragmento (pero base_report_sin_servicio podría loguear internamente).
  
  

• Controles de duplicados:

• No se aprecia un control explícito de duplicados en el fragmento mostrado. La inserción final via utils->base_report_sin_servicio podría implementar TRUNCATE/UPSERT, pero no está visible aquí. Por ahora: No aplica control de duplicados en este código (revisar implementación de base_report_sin_servicio).
  
  

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

• $updates contiene por rango mensual el resultado (éxito/detalle de error) — sirve como métrica operativa de completitud por mes.

• Validaciones de existencia de branch, empleados, salarios y datos de gastos se usan como gates; si faltan, se marca el mes como no procesado.

9) Dependencias externas

• APIs / servicios y endpoints:

• APICAPACITACION → method/send-query-database (usado para múltiples queries sobre: Branch, Currency Exchange, Solicitud de Contratos Alquiler, Employee, Salary Slip, etc.).

• Tablas locales particionadas: report_shipping_amount_YYYY_MM_DD (consultadas por día).

• BD empresarial (empresarial) → tablas: emp_ordenservicio, emp_fn_categorias, emp_fn_list, emp_terminal.
  
  

• Autenticación / headers:

• No se muestran headers ni tokens en el fragmento de código. Llamadas a utils->erp() y general->serviceErp() abstractizan autenticación; revisar utils->erp y general->serviceErp para ver headers / tokens. En el fragmento: No se encontró detalle explícito de autenticación/headers.
  
  

• Mapeos y contratos de datos:

• API send-query-database debe devolver campos indicados por cada sql_query (ej.: exchange_rate, name, ideentificador, categoria, monto_de_local, metro_fijo para branches, etc.).

• Contrato implícito: las tablas diarias report_shipping_amount_YYYY_MM_DD deben tener columnas sent, received, terminal_id para que los aggregados funcionen.

• get_detail_expenses espera que emp_fn_categorias y emp_fn_list existan y devuelvan fn_id, list_monto, list_agencia, list_motivo, list_fecha.

10) Historial de cambios

2025-10-21 13:00 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE DE COSTO STORE ESPECIFICO 2

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

1) Nombre del reporte

• Nombre: Reporte de Costo Store Específico 2

• Código / Alias: update_specific_store

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• first_day, last_day (generados por obtainRangeDaysByYear)

• from_date, to_date (pasados a reportes ERPNext)
  
  

• Tipo de rango (diario / mensual / personalizado):

• Mensual dinámico, basado en el mes actual (date("m"))

• Se generan rangos de inicio y fin de mes (Y-m-d)

• Puede limitarse al mes actual o retroceder 2 meses (según condición en $first_month).
  
  

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

• Tabla / Recurso: report_centro_costo_store_especifico_2

• Alias (si aplica): $table

• Campos utilizados (clave → descripción):

• id → Identificador primario autoincremental

• agencia → Nombre de la agencia o sucursal

• producto_servicio → Tipo de elemento (‘PRODUCTO’ o ‘SERVICIO’)

• nombre_articulo → Nombre del artículo o servicio

• stock_inicial → Stock inicial del periodo

• unidades_recibidas → Cantidad ingresada en el periodo

• unidades_vendidas → Cantidad vendida

• merma → Cantidad perdida o desechada

• inventario_final → Existencia final calculada

• costo_de_compra → Costo unitario de compra

• precio_venta → Precio unitario de venta

• valor_inventario_final → Valor total del inventario final

• valor_venta → Valor total de ventas

• valor_compra → Valor total de compras

• retabilidad → Diferencia entre valor de venta y compra

• ano → Año del reporte

• periodo → Mes del reporte

• created_date → Fecha de creación del registro

• status → Estado lógico del registro (activo = 1)

• Condiciones (WHERE) aplicadas: 

• Dinámicas según rango de fechas (first_date, second_date)

• Filtros heredados de subconsultas (warehouse, item_group, price_list)

• Tipo de unión con otras fuentes (JOIN y llave): No aplica directamente (la consolidación se realiza por combinación de arrays en PHP)

• Observaciones (ej. particiones, índices): 

• La tabla se recrea dinámicamente por mes/año (CREATE TABLE report_centro_costo_store_especifico_2_YYYY_MM)

• Se indexa el campo status

• Inserciones masivas por bloques de 900 registros

3.2 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabWarehouse as alm

• Alias (si aplica): $data_warehouse

• Campos utilizados (clave → descripción):

• alm.name → Nombre del almacén

• Condiciones (WHERE) aplicadas: WHERE LOCATE('Tienda', alm.name) > 0 (solo almacenes que contienen la palabra “Tienda”)
  
  

• Tipo de unión con otras fuentes (JOIN y llave): Se cruza con warehouse de report_stock_balance mediante coincidencia exacta de nombre
  
  

• Observaciones (ej. particiones, índices): 

• Retorna únicamente almacenes activos de tipo “Tienda”

• Estructura esperada: {status, message, data[]}

3.3 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabDelivery Note

• Alias (si aplica): $data_desecho

• Campos utilizados (clave → descripción):

• dni.warehouse → Almacén origen

• dn.creation → Fecha de creación

• dni.item_code → Código del artículo

• dni.qty → Cantidad desechada

• Condiciones (WHERE) aplicadas:

• dn.sele = 'Desecho'

• dn.status = 'To Bill'

• dn.creation BETWEEN first_date AND second_date
  
  

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabDelivery Note Item AS dni ON (dn.name = dni.parent)
  
  

• Observaciones (ej. particiones, índices): 

• Permite calcular el valor de merma por producto

• API: method/send-query-database

3.4 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabDelivery Note Item

• Alias (si aplica): $data_desecho

• Campos utilizados (clave → descripción):

• dni.warehouse → Almacén origen

• dn.creation → Fecha de creación

• dni.item_code → Código del artículo

• dni.qty → Cantidad desechada

• Condiciones (WHERE) aplicadas:

• dn.sele = 'Desecho'

• dn.status = 'To Bill'

• dn.creation BETWEEN first_date AND second_date
  
  

• Tipo de unión con otras fuentes (JOIN y llave): LEFT JOIN tabDelivery Note Item AS dni ON (dn.name = dni.parent)
  
  

• Observaciones (ej. particiones, índices): 

• Permite calcular el valor de merma por producto

• API: method/send-query-database

3.5 Conexión / Base: CAPACITACION

• Tabla / Recurso: method/erpnext.stock.report.stock_balance.stock_balance.report_stock_balance

• Alias (si aplica): $get_report_stock_balance

• Campos utilizados (clave → descripción):

• warehouse   → Nombre o código del almacén  

• item_name  → Nombre del artículo o producto  

• item_group → → Grupo o categoría del ítem  

• opening_qty  → Cantidad inicial en inventario  

• in_qty  → Cantidad ingresada al almacén  

• out_qty  → Cantidad salida del almacén  

• val_rate  → Valor unitario o tasa de valoración del producto

• Condiciones (WHERE) aplicadas:

• company = 'Shalom Empresarial'

• item_group = 'TIENDA'

• from_date, to_date dinámicos
  
  

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

• Combina con tabWarehouse (por nombre de almacén)

• Cruza con get_desechos (por warehouse e item_code)
  
  

• Observaciones (ej. particiones, índices): 

• Endpoint protegido con token de autenticación

• Retorna estructura JSON con message (array de registros)

3.6 Conexión / Base: CAPACITACION

• Tabla / Recurso: method/erpnext.stock.report.stock_ledger.stock_ledger.report_stock

• Alias (si aplica): $get_report_stock_ledger

• Campos utilizados (clave → descripción):

• item_name   → Nombre del artículo o producto  

• actual_qty   → Cantidad actual disponible en inventario  

• valuation_rate   → Valor unitario o tasa de valoración del ítem  

• qty_after_transaction   → Cantidad total después de la transacción  

• in_qty   → Cantidad ingresada en la transacción  

• out_qty   → Cantidad retirada o despachada en la transacción

• Condiciones (WHERE) aplicadas:

• from_date, to_date, company = 'Shalom Empresarial'

• warehouse = 'ALMACEN GENERAL-TIENDA - SE'
  
  

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

• Relación por item_name con los productos de get_report_stock_balance
  
  

• Observaciones (ej. particiones, índices): 

• Permite calcular stock inicial y final detallado

• Respuesta JSON con niveles [message][1] para los datos válidos

3.7 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabItem Price

• Alias (si aplica): $pricelist_respo

• Campos utilizados (clave → descripción):

• price_list_rate → Precio de venta estándar

• Condiciones (WHERE) aplicadas:

• price_list = 'Venta estándar'

• selling = 1

• docstatus = 0

• item_name = <producto>
  
  

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

• Se asocia por item_name con registros del balance de stock
  
  

• Observaciones (ej. particiones, índices): 

• Se consulta individualmente por cada producto

• Orden descendente por creation (último precio vigente)

4) Filtros globales del reporte

• Inclusiones (must-have):

• Solo artículos con grupo 'TIENDA'

• Solo almacenes cuyo nombre contenga 'Tienda'

• Solo movimientos de la empresa 'Shalom Empresarial'
  
  

• Exclusiones (reglas de descarte):

• Desechos no clasificados fuera de rango

• Precios con docstatus ≠ 0
  
  

• Reglas por estado / habilitado: Campos status = 1 (activos en tabla destino)

• Parámetros externos (si el usuario puede filtrarlo): No se expone interfaz de usuario directa (parámetros internos calculados).

5) Transformaciones y Reglas de negocio

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

• inventario_final = opening_qty + in_qty - out_qty - merma

• valor_inventario_final = inventario_final * val_rate

• valor_venta = out_qty * price_list_rate

• valor_compra = out_qty * val_rate

• retabilidad = valor_venta - valor_compra
  
  

• Mapeos de estado: 

• item_group == 'SERVICIOS' → producto_servicio = 'SERVICIO'

• En caso contrario → 'PRODUCTO'
  
  

• Reglas de validación (p.ej., sólo registros validados): Retorna error si alguno de los servicios ERP no devuelve status=true.
  
  

• Reglas condicionales (si X entonces Y): Si no hay branch, se obtiene de warehouse (partido por “-” para nombre de sucursal).

 

6) Estructura de salida

• Tabla/archivo destino: report_centro_costo_store_especifico_2

• Particionado / sufijo: Se crea tabla mensual: report_centro_costo_store_especifico_2_YYYY_MM

• Clave(s) primaria(s) o únicas: id (INT AUTO_INCREMENT PRIMARY KEY)

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

• id → INT → Identificador único del registro (PK)

• agencia → VARCHAR(255) → Nombre de la tienda o sucursal

• producto_servicio → ENUM → Clasificación del ítem (producto / servicio)

• nombre_articulo → VARCHAR(225) → Descripción o nombre completo del artículo

• stock_inicial → FLOAT → Cantidad disponible al inicio del periodo

• unidades_recibidas → FLOAT → Total de unidades ingresadas durante el periodo

• unidades_vendidas → FLOAT → Total de unidades vendidas o despachadas

• merma → VARCHAR(20) → Cantidad perdida o deteriorada

• inventario_final → FLOAT → Stock final calculado (stock_inicial + recibidas - vendidas - merma)

• costo_de_compra → VARCHAR(20) → Costo unitario de adquisición

• precio_venta → FLOAT → Precio unitario de venta

• valor_inventario_final → FLOAT → Valor monetario del inventario final

• valor_venta → FLOAT → Ingreso total generado por ventas

• valor_compra → FLOAT → Costo total de adquisición

• rentabilidad → FLOAT → Diferencia entre valor_venta y valor_compra

• ano → INT → Año correspondiente al periodo

• periodo → VARCHAR(20) → Nombre del mes o periodo (ej. “ENERO”)

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

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

• Ordenamiento por defecto: No explícito en SQL; implícito por inserción.

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Último mes (por defecto), con opción de extender 2 meses atrás

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

• Tolerancia a fallos / reintentos: 

• Manejo de try-catch con rollback de transacción

• Registro en tabla emp_reportes_validation con status=0
  
  

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

 

8) Calidad y controles

• Validaciones previas/post:

• Verifica existencia de tabla destino (exist_table_bd)

• Crea índice status si la tabla es nueva

• Inserta registro de validación con fechas procesadas.
  
  

• Controles de duplicados: La tabla se recrea por mes → evita duplicidad de periodo

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

• Conteo de registros por rango de fechas validado en emp_reportes_validation.

9) Dependencias externas

• APIs / servicios y endpoints:

• APICAPACITACION . "method/send-query-database"

• APICAPACITACION . "method/erpnext.stock.report.stock_balance.stock_balance.report_stock_balance"

• APICAPACITACION . "method/erpnext.stock.report.stock_ledger.stock_ledger.report_stock"
  
  

• Autenticación / headers:

• Authorization: token fc60669957e6bdc:b207d472e96c9df

• Content-Type: application/json
  
  

• Mapeos y contratos de datos:

• Todos los endpoints devuelven message o response en JSON

• Campo valor indica validez (true/false).

10) Historial de cambios

2025-10-21 14:00 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE CENTRO DE COSTO AEREO

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

1) Nombre del reporte

• Nombre: Reporte Centro de Costo Aéreo

• Código / Alias: update_centro_costo_aereo

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: fecha, fecha_y_hora_de_transferencia, start_date, date, fecha (en distintas tablas)

• Tipo de rango (diario / mensual / personalizado): Mensual (usa utilitario range_days() para generar primeros y últimos días de mes)

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

• Tabla / Recurso: report_centro_costo_aereo_3

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• month → Mes correspondiente al periodo procesado

• cantidad_aereo → Total de órdenes aéreas procesadas

• cantidad_terrestre_aereo → Total de órdenes aéreo–terrestres

• ventas_aereo → Monto total facturado de órdenes aéreas

• ventas_terrestre_aereo → Monto total facturado de órdenes aéreo–terrestres

• ventas_porcentaje → Suma ponderada de ventas

• compras → Total de compras materiales

• servicios → Total de servicios externos (ej. LATAM)

• planilla → Monto total de sueldos asociados al área

• movilidad → Gasto fijo de transporte asignado

• rentabilidad → Diferencia entre ingresos y egresos

• rentabilidad_porcentaje → Rentabilidad expresada en porcentaje

• ano → Año del periodo procesado

• created_date → Fecha de creación del registro

• Condiciones (WHERE) aplicadas:

• Los datos se registran mensualmente para cada rango de fechas generado por range_days().

• No existen filtros directos sobre esta tabla (es generada dinámicamente).
  
  

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

• Observaciones (ej. particiones, índices):

• Las tablas son dinámicas por año y mes (report_centro_costo_aereo_3_YYYY_MM).

• Posee campo autoincremental id como PK y created_date con timestamp automático.

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_envio_aereo

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden de servicio

• fecha → Fecha de envío

• estado → Estado del registro

• tipo_mercaderia → Tipo de carga (AÉREO o TERRESTRE)

• contenido → Tipo de envío (utilizado para filtrar “TERRESTRE”)

• Condiciones (WHERE) aplicadas:

• estado = 1

• fecha BETWEEN first_date AND second_date

• contenido = 'TERRESTRE' (para clasificar envíos terrestres)
  
  

• Tipo de unión con otras fuentes (JOIN y llave):  No se usa JOIN; relación posterior por campo ose_id con otras tablas (emp_detalle_comppago, emp_ordenservicio).
  
  

• Observaciones (ej. particiones, índices):

• Los datos se procesan en bloques de 100 registros (array_chunk) para optimizar memoria.
  
  
  

3.3 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_detalle_comppago

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• dcp_ose_id → Identificador de orden de servicio vinculado al pago

• Condiciones (WHERE) aplicadas:

• dcp_ose_id IN (grupo de ose_id válidos)
  
  

• Tipo de unión con otras fuentes (JOIN y llave):  Relaciona directamente con emp_envio_aereo.ose_id para identificar pagos válidos.
  
  

• Observaciones (ej. particiones, índices): Usada para filtrar las órdenes de servicio que cuentan con comprobante de pago.

 

3.4 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ose_id → Identificador de orden

• ose_montofinal → Monto final facturado

• ose_estado → Estado de la orden (1 = válida)

• ose_estadoPago → Estado de pago

• ose_tipoanulado → Tipo de anulación

• eliminado → Indicador lógico de eliminación

• Condiciones (WHERE) aplicadas:

• ose_estado = 1

• eliminado = 0

• ose_estadoPago NOT IN ('AN','DA')

• ose_tipoanulado = ''

• ose_id IN (grupo de órdenes válidas)
  
  

• Tipo de unión con otras fuentes (JOIN y llave):   Vinculada con emp_detalle_comppago.dcp_ose_id (por campo ose_id).
  
  

• Observaciones (ej. particiones, índices): Consulta agregada (SUM y COUNT) agrupada por lotes de 100 registros.

3.5 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabMaterial Request

• Alias (si aplica): mr

• Campos utilizados (clave → descripción):

• fecha_y_hora_de_transferencia → Fecha de transferencia del material

• material_request_type → Tipo de solicitud (“Material Transfer”)

• status → Estado de la solicitud (“Transferred”)

• item_code → Código del artículo

• qty → Cantidad solicitada

• Condiciones (WHERE) aplicadas:

• mr.fecha_y_hora_de_transferencia BETWEEN first_date AND second_date

• mr.material_request_type = 'Material Transfer'

• mr.status = 'Transferred'

• item_code = '24141711'
  
  

• Tipo de unión con otras fuentes (JOIN y llave):  LEFT JOIN tabMaterial Request Item (mri.parent = mr.name). Vinculada con emp_detalle_comppago.dcp_ose_id (por campo ose_id).
  
  

• Observaciones (ej. particiones, índices): Consulta enviada mediante API send-query-database.

 

3.6 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabMaterial Request Item

• Alias (si aplica): mri

• Campos utilizados (clave → descripción):

• fecha_y_hora_de_transferencia → Fecha de transferencia del material

• material_request_type → Tipo de solicitud (“Material Transfer”)

• status → Estado de la solicitud (“Transferred”)

• item_code → Código del artículo

• qty → Cantidad solicitada

• Condiciones (WHERE) aplicadas:

• mr.fecha_y_hora_de_transferencia BETWEEN first_date AND second_date

• mr.material_request_type = 'Material Transfer'

• mr.status = 'Transferred'

• item_code = '24141711'
  
  

• Tipo de unión con otras fuentes (JOIN y llave):  LEFT JOIN tabMaterial Request Item (mri.parent = mr.name). Vinculada con emp_detalle_comppago.dcp_ose_id (por campo ose_id).
  
  

• Observaciones (ej. particiones, índices): Consulta enviada mediante API send-query-database.

3.7 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabSolicitud de Pagos

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• proveedor → Nombre del proveedor

• fecha → Fecha del documento

• monto → Monto total

• mes_servicio → Mes del servicio

• año_del_servicio → Año del servicio

• Condiciones (WHERE) aplicadas:

• proveedor = 'LATAM AIRLINES PERU S.A.'

• fecha BETWEEN start_date_last_month AND end_date_first_month

• mes_servicio = new_month

• año_del_servicio = new_year
  
  

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

• Observaciones (ej. particiones, índices): Consulta agrupada por proveedor (GROUP BY proveedor).

 

3.8 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabSalary Slip

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• gross_pay → Sueldo bruto (usado como net_pay)

• employee_name → Nombre del empleado

• employee → Código del empleado

• department → Departamento

• designation → Puesto del empleado

• area_del_trabajador → Área laboral

• Condiciones (WHERE) aplicadas:

• proveedor = 'LATAM AIRLINES PERU S.A.'

• fecha BETWEEN start_date_last_month AND end_date_first_month

• mes_servicio = new_month

• año_del_servicio = new_year
  
  

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

• Observaciones (ej. particiones, índices): Consulta agrupada por proveedor (GROUP BY proveedor).

3.9 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabCurrency Exchange

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• exchange_rate → Tipo de cambio vigente

• date → Fecha de vigencia

• from_currency, to_currency → Monedas origen y destino

• for_buying → Indicador para compras

• Condiciones (WHERE) aplicadas:

• for_buying = 1

• date = fecha actual

• from_currency = 'USD'

• to_currency = 'PEN'
  
  

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

• Observaciones (ej. particiones, índices): Consulta simple que devuelve un único registro con el tipo de cambio vigente.

4) Filtros globales del reporte

• Inclusiones (must-have):

• Solo registros con estado = 1, ose_estado = 1, eliminado = 0, ose_tipoanulado = ''

• Exclusiones (reglas de descarte): ose_estadoPago IN ('AN','DA')

• Reglas por estado / habilitado: Se procesan únicamente registros habilitados (status activos).

• Parámetros externos (si el usuario puede filtrarlo): fecha inicial y fecha final generadas dinámicamente según mes en ejecución.

5) Transformaciones y Reglas de negocio

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

• ventas_porcentaje = (ventas_aereo + ventas_terrestre_aereo) * 0.5

• rentabilidad = ventas_porcentaje - (compras + servicios + planilla + movilidad)

• rentabilidad_porcentaje = rentabilidad / ventas_porcentaje * 100
  
  

• Mapeos de estado: Registros anulados o eliminados son descartados.

• Reglas de validación (p.ej., sólo registros validados): Solo se consideran órdenes válidas y no anuladas.

• Reglas condicionales (si X entonces Y): Si no hay ventas_porcentaje, rentabilidad_porcentaje = 0.

6) Estructura de salida

• Tabla/archivo destino: report_centro_costo_aereo_3

• Particionado / sufijo: Mensual (por fechas first_day – last_day)

• Clave(s) primaria(s) o únicas: id (auto incremental)

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

• cantidad_aereo INT Cantidad de órdenes aéreas

• cantidad_terrestre_aereo INT Cantidad de órdenes terrestres-aéreas

• ventas_aereo FLOAT Monto total de ventas aéreas

• ventas_terrestre_aereo FLOAT Monto total de ventas terrestres

• ventas_porcentaje FLOAT Porcentaje de ventas

• compras FLOAT Total de compras del mes

• servicios FLOAT Gastos de servicios LATAM

• planilla FLOAT Costo planilla aérea

• movilidad FLOAT Costo fijo movilidad

• rentabilidad FLOAT Utilidad operativa

• rentabilidad_porcentaje FLOAT Margen de rentabilidad

• month VARCHAR Mes de referencia

• ano INT Año de referencia

• created_date DATETIME Fecha de creación del registro

• status TINYINT Estado del registro
  
  

• Ordenamiento por defecto: ano, month

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Último mes del año en curso

• Tamaño de lote / paginado (chunking): Procesamiento en bloques de 100 registros (array_chunk($group, 100))

• Tolerancia a fallos / reintentos: No definido, pero manejo seguro por iteración de chunks

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

8) Calidad y controles

• Validaciones previas/post: Validación de existencia de resultados antes de sumar montos y cantidades.

• Controles de duplicados: Agrupación por ose_id y mapeo de arreglos asociativos evita duplicidad.

• Métricas de completitud (qué se monitorea): Conteo de órdenes, sumatoria de montos, y porcentaje de rentabilidad.

9) Dependencias externas

• APIs / servicios y endpoints: APICAPACITACION/method/send-query-database

• Autenticación / headers: Definidos en $this->utils->erp() (usa encabezados preconfigurados)

• Mapeos y contratos de datos: 

• JSON con estructura {filters, where, sql_query, tables}

• Formato de retorno: {valor, response}

10) Historial de cambios

2025-10-21 17:36 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE CENTRO COSTO DHL 2

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

1) Nombre del reporte

• Nombre: Reporte Centro Costo DHL 2

• Código / Alias: report_centro_costo_dhl_2

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados: first_date, second_date

• Tipo de rango (diario / mensual / personalizado): Mensual (se recorren los meses del año actual y del año anterior)

• 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_comppago_dhl

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• ter_id → Identificador del tercero asociado al envío.

• ter_nombre → Nombre del tercero o cliente.

• cop_montoTotal → Monto total del comprobante DHL.

• cop_id → Identificador único del comprobante.

• cop_fechaemision → Fecha de emisión del comprobante.
  
  

• Condiciones (WHERE) aplicadas:

• eliminado = 0

• cop_fechaemision BETWEEN {first_date} 00:00:00 AND {second_date} 23:59:59
  
  

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (consulta directa a tabla única).
  
  

• Observaciones (ej. particiones, índices):

• Se realiza una suma total (SUM(cop_montoTotal)) y conteo (COUNT(cop_id)) para obtener el monto total y cantidad de comprobantes emitidos en el rango.

• El resultado alimenta los campos ventas y qty_envios del reporte.

 

3.2 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabSolicitud de Pagos

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• monto → Monto del pago realizado.

• currency → Moneda del registro (USD o PEN).

• proveedor → Nombre del proveedor (filtrado por “DHL EXPRESS PERÚ S.A.C.”).

• mes_servicio_dhl → Mes del servicio facturado.

• año_del_servicio → Año del servicio facturado.

• concepto → Concepto del servicio (“Servicio Aéreo”).

• fecha → Fecha del registro del pago.
  
  

• Condiciones (WHERE) aplicadas:

• proveedor = 'DHL EXPRESS PERÚ S.A.C.'

• concepto = 'Servicio Aereo'

• mes_servicio_dhl = {mes_en_español}

• año_del_servicio = {año}
  
  

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (consulta simple filtrada por múltiples campos).
  
  

• Observaciones (ej. particiones, índices):

• Se realiza una conversión de moneda: los montos en USD se multiplican por 4 para equipararse a PEN.

• El valor total obtenido se asigna al campo servicio_dhl.

• La consulta es ejecutada mediante el endpoint method/send-query-database usando $this->utils->erp("POST", …).

3.3 Conexión / Base: CAPACITACION

• Tabla / Recurso: tabSalary Slip

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• gross_pay → Total bruto pagado en la planilla.

• name → Identificador del registro de planilla.

• department → Departamento responsable (filtrado por “Proyectos - SE”).

• area_del_trabajador → Área asignada del trabajador (filtrado por “Aereo internacional - SE”).

• start_date → Fecha de inicio del periodo de pago.

• Condiciones (WHERE) aplicadas:

• start_date = {first_date}

• department = 'Proyectos - SE'

• area_del_trabajador = 'Aereo internacional - SE'

• Agrupación por departamento (GROUP BY department).
  
  

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (consulta directa a una tabla).
  
  

• Observaciones (ej. particiones, índices):

• Los resultados agregan:

• SUM(gross_pay) → monto total pagado (planilla).

• COUNT(name) → cantidad de empleados (personas).
  
  

• Este valor se usa para calcular los costos de personal asociados al servicio DHL.
  
  

3.4 Conexión / Base: REPORTES

• Tabla / Recurso: report_centro_costo_dhl_2_YYYY_MM

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

• periodo → Mes del reporte (en español).

• qty_envios → Cantidad total de envíos DHL.

• ventas → Monto total de ventas DHL.

• ventas_90_porciento → Proyección del 90% de las ventas.

• compras_abastecimiento → Compras totales de abastecimiento (constante 0).

• servicio_dhl → Monto de servicio DHL cargado desde ERP.

• planilla → Total de planilla asociado.

• rentabilidad → Diferencia entre ingresos y egresos.

• rentabilidad_porciento → Porcentaje de rentabilidad.

• year → Año procesado.

• created_date, status → Metadatos del registro.

• Condiciones (WHERE) aplicadas:

• Generación dinámica por mes usando {first_date} y {second_date} del rango procesado.
  
  

• Tipo de unión con otras fuentes (JOIN y llave): No aplica (carga por inserción de datos preprocesados).
  
  

• Observaciones (ej. particiones, índices):

• Se crean tablas mensuales dinámicamente (CREATE TABLE report_centro_costo_dhl_2_YYYY_MM).

• Se aplica un índice adicional: ALTER TABLE ADD INDEX status (status);

• Se registran logs de ejecución en emp_reportes_validation y error_reports.

 

4) Filtros globales del reporte

• Inclusiones (must-have):

• Solo registros con eliminado = 0

• Solo proveedor "DHL EXPRESS PERÚ S.A.C."
  
  

• Exclusiones (reglas de descarte): Registros sin monto (monto <= 0)

• Reglas por estado / habilitado: 

• status inicial = 1 (en tabla destino)

• Insert en emp_reportes_validation con status = 1 si proceso exitoso
  
  

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

• Fechas generadas dinámicamente por range_days()

• No recibe input manual del usuario

5) Transformaciones y Reglas de negocio

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

• ventas_90_porciento = ventas * 0.9

• rentabilidad = ventas_90_porciento - servicio_dhl - planilla

• rentabilidad_porciento = (rentabilidad / ventas_90_porciento) * 100
  
  

• Mapeos de estado: status → 1 (activo)

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

• Si obtain_amount_dhl["status"] == false, el proceso se detiene

• Reglas condicionales (si X entonces Y): Si rentabilidad == 0 → rentabilidad_porciento = '0%'

6) Estructura de salida

• Tabla/archivo destino: report_centro_costo_dhl_2_YYYY_MM

• Particionado / sufijo: Mensual (_YYYY_MM)

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

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

• id → INT → Identificador único del registro (PK)

• agencia → VARCHAR(255) → Nombre de la tienda o sucursal

• producto_servicio → ENUM → Clasificación del ítem (producto / servicio)

• nombre_articulo → VARCHAR(225) → Descripción o nombre completo del artículo

• stock_inicial → FLOAT → Cantidad disponible al inicio del periodo

• unidades_recibidas → FLOAT → Total de unidades ingresadas durante el periodo

• unidades_vendidas → FLOAT → Total de unidades vendidas o despachadas

• merma → VARCHAR(20) → Cantidad perdida o deteriorada

• inventario_final → FLOAT → Stock final calculado (stock_inicial + recibidas - vendidas - merma)

• costo_de_compra → VARCHAR(20) → Costo unitario de adquisición

• precio_venta → FLOAT → Precio unitario de venta

• valor_inventario_final → FLOAT → Valor monetario del inventario final

• valor_venta → FLOAT → Ingreso total generado por ventas

• valor_compra → FLOAT → Costo total de adquisición

• rentabilidad → FLOAT → Diferencia entre valor_venta y valor_compra

• ano → INT → Año correspondiente al periodo

• periodo → VARCHAR(20) → Nombre del mes o periodo (ej. “ENERO”)

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

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

• Ordenamiento por defecto: ORDER BY year, periodo ASC

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 24 meses

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

• Tolerancia a fallos / reintentos: Transacciones con beginTransaction() y rollBack() ante error

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

8) Calidad y controles

• Validaciones previas/post: 

• Verificación de existencia de tabla (exist_table_bd)

• Inserción de log en emp_reportes_validation
  
  

• Controles de duplicados: Implícitos por tabla nueva mensual (_YYYY_MM)

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

• Conteo de registros insertados

• Estado de ejecución (status)

9) Dependencias externas

• APIs / servicios y endpoints: APICAPACITACION/method/send-query-database (ERPNext)

• Autenticación / headers: Controlados por $this->utils->erp() (maneja tokens internos)

• Mapeos y contratos de datos: Recibe y envía datos JSON (filters, where, sql_query, tables)

 

 

10) Historial de cambios

2025-10-21 18:15 - Elian Franco Arroyo Rodas - Documentación inicial

PLANTILLA REPORTES

Fuente:  

1) Nombre del reporte

• Nombre: 

• Código / Alias: 

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

• Tipo de rango (diario / mensual / personalizado):

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

• Zona horaria:

3) Origen de datos (tablas/APIs)

• Conexión / Base:

• Tabla / Recurso:

• Alias (si aplica):

• Campos utilizados (clave → descripción):

• Condiciones (WHERE) aplicadas:

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

• Observaciones (ej. particiones, índices):

4) Filtros globales del reporte

• Inclusiones (must-have):

• Exclusiones (reglas de descarte):

• Reglas por estado / habilitado:

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

5) Transformaciones y Reglas de negocio

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

• Mapeos de estado:

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

• Reglas condicionales (si X entonces Y):

6) Estructura de salida

• Tabla/archivo destino:

• Particionado / sufijo:

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

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

• Ordenamiento por defecto:

7) Frecuencia y operación

• Frecuencia de actualización:

• Ventana que recalcula (días/meses):

• Tamaño de lote / paginado (chunking):

• Tolerancia a fallos / reintentos:

• Tiempos de ejecución esperados:

8) Calidad y controles

• Validaciones previas/post:

• Controles de duplicados:

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

9) Dependencias externas

• APIs / servicios y endpoints:

• Autenticación / headers:

• Mapeos y contratos de datos:

10) Historial de cambios

2025-10-01 11:53 - Elian Franco Arroyo Rodas - Documentación inicial

 

REPORTE ENVIOS COMERCIAL CORPORATIVO

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

1) Nombre del reporte

• Nombre: Reporte Envios Comercial Corporativo

• Código / Alias:  report_envios_comercial_corporativo_

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

  • ose_fhpreferenciapartida (fecha de partida de orden de servicio)

  • inc_fhincidencia (fecha de incidencia)

  • fecha_preferencial (fecha referencial alternativa)

  • created_date (fecha de registro en validación)

• Tipo de rango (diario / mensual / personalizado):

  • Calculado automáticamente entre $first_date y $second_date por mes, con lógica de retroceso de hasta 3 meses según mes actual.
  • En casos especiales (enero a marzo) incluye meses del año anterior.

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

• Base principal: $this->empresarial (ERP Empresarial)

• Base secundaria: $this->centos (ERP Centos)

• Versionado: Se elige conexión antigua o actual según el mes/año:

  • Si año == 2023 y mes <= 9 → usa empresarial_old y centosold

  • Caso contrario → usa empresarial y centos

Observación general:
El proceso recorre un rango de fechas generado por obtainRangeDaysByYear(), ejecutando iterativamente la función report() para cada rango mensual.
Los resultados se registran en la tabla de control emp_reportes_validation.

🔹 3.2 Tabla / Recurso: emp_empresa

• Alias: emp

• Campos utilizados:

  • id → Identificador de la empresa

  • ruc → Número de documento (clave de relación)

  • grupo → Clasificación de empresa (COMERCIAL o CORPORATIVO)

  • gestor → Usuario responsable o gestor asociado

• Condiciones (WHERE):

  • grupo no nulo

  • grupo en (‘COMERCIAL’, ‘CORPORATIVO’)

  • ruc no en (‘20563023016’, ‘20512528458’)

• Tipo de unión:

  • LEFT JOIN con emp_persona (emp.ruc = per.per_nrodocumento)

• Observaciones:

  • Esta tabla define el universo de empresas que serán evaluadas.

  • El resultado alimenta los arreglos $companys_group y $persons.

🔹 3.3 Tabla / Recurso: emp_persona

• Alias: per

• Campos utilizados: per_nrodocumento

• Unión: LEFT JOIN con emp_empresa (emp.ruc = per.per_nrodocumento)

• Observaciones:

  • Se usa solo como apoyo para validar la existencia del RUC en personas.

  • Sin filtros directos, dependiente del JOIN principal.

---

🔹 3.4 Tabla / Recurso: emp_ordenservicio

• Alias: No declarado

• Campos utilizados (clave → descripción):

  • ose_id → ID único de orden

  • ose_termorigenatencion → Origen

  • ose_termdestinoentrega → Destino

  • ose_montofinal → Monto del servicio

  • ose_fhpreferenciapartida / ose_fhpreferencial → Fechas de referencia

  • ose_estadoentregado, ose_tipoanulado, ose_estadoPago, eliminado, ose_estado

  • ose_remiteempresa, ose_destinaempresa → Empresa remitente y destinataria

• Condiciones (WHERE):

  • ose_estadoPago NOT IN (‘DA’, ‘AN’)

  • ose_tipoanulado = ''

  • eliminado = '0'

  • ose_estado = '1'

  • ose_fhpreferenciapartida BETWEEN [first_date 00:00:00, second_date 23:59:59]

  • ose_remiteempresa o ose_destinaempresa pertenecen a $companys_group

• Observaciones:

  • Base principal para obtener todas las órdenes de servicio por empresa.

  • Se filtran órdenes válidas, sin anulación, dentro del rango de fechas.

---

🔹 3.5 Tabla / Recurso: emp_detalle_comppago

• Alias: dcp

• Unión: LEFT JOIN con emp_comppago (cp.cop_id = dcp.dcp_cop_id)

• Campos utilizados: dcp_cop_id, dcp_ose_id

• Condiciones:

  • dcp_ose_id IN (ordenes válidas)

  • cp.cop_estado_pago IS NULL o cp.cop_estado_pago != 'AN'

• Observaciones:

  • Permite identificar órdenes sin pago registrado, que luego se agrupan como pendientes de pago ($pending_payments).

---

🔹 3.6 Tabla / Recurso: emp_os_detalle

• Campos utilizados:

  • osd_peso → Peso de la carga

  • osd_osid → ID de la orden de servicio

• Condiciones:

  • osd_osid IN (ordenes válidas)

  • osd_eliminado = '0'

• Observaciones:

  • Fuente de los valores de kilogramos transportados.

  • Se agrupan por OS ($details_orders_group).

---

🔹 3.7 Tabla / Recurso: emp_procesos_historial_app

• Conexión: $this->centos

• Campos utilizados: id, idose, proceso, nombre_metodo, status

• Condiciones:

  • idose IN (ordenes válidas)

  • proceso IN ('embarque','desembarque','inventario')

  • nombre_metodo IN (lista de métodos permitidos)

  • status = 1

• Observaciones:

  • Permite validar qué órdenes pasaron por embarque, desembarque o inventario.

  • Las faltantes se marcan como no procesadas en esas etapas.

---

🔹 3.8 Tabla / Recurso: emp_incidencias

• Alias: inc

• Unión: LEFT JOIN emp_ordenservicio os ON os.ose_id = inc.inc_idos

• Campos utilizados:

  • inc_id, inc_tipo, inc_fhincidencia, inc_idos, inc_descripcion, inc_responsable_terminal

  • ose_remiteempresa, ose_destinaempresa

• Condiciones:

  • inc.inc_tipo = 'REVISAR'

  • inc_fhincidencia BETWEEN rango de fechas

  • ose_estadoPago NOT IN (‘DA’, ‘AN’)

  • ose_tipoanulado = ''

  • ose_estado = 1

  • inc.eliminado IS NULL OR inc.eliminado = 0

  • inc_descripcion NOT IN (lista de desechos)

• Observaciones:

  • Registra incidencias relevantes (excluye desechos).

  • Genera agrupación por empresa y día ($incidences_group).

---

🔹 3.9 Tabla / Recurso: emp_incidencias (SUNAT)

• Campos utilizados: inc_id, inc_idos

• Condiciones:

  • inc_idos IN (ordenes válidas)

  • inc_descripcion IN (‘3.1 M. DECOMISADA POR SUNAT.’, etc.)

  • inc_fhincidencia BETWEEN rango de fechas

  • eliminado IS NULL OR eliminado = 0

• Observaciones:

  • Subconsulta específica para incidencias SUNAT, agrupadas por inc_idos.

---

🔹 3.10 Tabla / Recurso: emp_entrega

• Campos utilizados: ent_id, ent_osid, ent_persona, ent_eliminado

• Condiciones:

  • ent_osid IN (ordenes válidas)

  • ent_persona IN (‘67676767’, ‘87878787’, ‘98989898’, ‘35353535’)

  • ent_eliminado = '0'

• Observaciones:

  • Identifica entregas específicas a personas clave.

  • Se utiliza para descartar órdenes que ya fueron entregadas.

---

🔹 3.11 Tabla / Recurso: emp_adicionales

• Campos utilizados: adc_id, adc_tipo, adc_ordenservicioid, eliminado

• Condiciones:

  • adc_ordenservicioid IN (ordenes válidas)

  • eliminado = '1'

• Observaciones:

  • Separa las guías con servicios adicionales (montacarga “M” o embalaje “K”).

  • Las OS con múltiples adicionales son excluidas del conteo final.

---

🔹 3.12 Procedimiento interno: obtainRangeDaysByYear()

• Propósito: Genera las fechas first_day y last_day por mes entre first_month y last_month.

• Uso: Iterar mensualmente en update() para llamar a report($first_date, $second_date).

---

🔹 3.13 Tabla de control: emp_reportes_validation

• Campos: report, first_date, second_date, created_date, status

• Condiciones: Inserta un registro por ejecución mensual del reporte.

• Observaciones:

  • Registra el resultado de cada iteración (status = 1 éxito, 0 error).

  • Facilita trazabilidad de generación por rango de fechas.

---

🔹 3.14 Función auxiliar: generateArrayOfDays($first, $second)

• Propósito: Devuelve arreglo con todas las fechas entre dos días.

• Uso: Agrupar y acumular métricas por día en $group.

---

🔹 3.15 Observaciones globales

• El código combina consultas cruzadas entre bases (ERP empresarial y Centos).

• Gran parte del análisis se realiza en memoria, agrupando por ruc y fecha.

• Los índices principales usados:

  • ose_id, ruc, inc_idos, ent_osid, adc_ordenservicioid.

• No usa vistas materializadas, pero genera una tabla lógica mensual consolidada en memoria para análisis.

4) Filtros globales del reporte

• Inclusiones:

  • Empresas con grupo “COMERCIAL” o “CORPORATIVO”.

  • Órdenes en estado activo (ose_estado = 1).

  • Procesos con status = 1.

• Exclusiones:

  • Empresas con RUC en lista de exclusión.

  • Estados de pago ‘DA’, ‘AN’.

  • Tipos anulados.

  • Incidencias de tipo “DESECHO” o “FALTANTE” definitivo.

• Reglas por estado / habilitado:

  • Solo registros habilitados (eliminado = 0 o nulo).

• Parámetros externos:

  • Rango de fechas (first_date, second_date).

5) Transformaciones y Reglas de negocio

• Derivaciones:

  • kilogramo = suma(osd_peso) por orden.

  • monto_facturacion_pendiente = total de monto en órdenes sin pago.

  • cantidad_facturacion_pendiente = conteo de esas mismas órdenes.

• Mapeos de estado:

  • Órdenes no embarcadas, no desembarcadas, no inventariadas se cuentan en grupos embarque, desembarque, inventario.

• Validaciones:

  • Ignora incidencias sin descripción válida.

  • Excluye entregas ya completadas.

• Condicionales:

  • Si fecha_preferencial <= fecha_consult y está en rango, se usa como fecha principal.

  • Si existe incidencia por RUC y fecha, incrementa campo incidencia.

6) Estructura de salida

• Tabla/archivo destino: emp_reportes_validation

• Particionado / sufijo:

  • Por mes (fecha inicial y final del rango procesado)

• Clave primaria: report, first_date, second_date

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

  • report → VARCHAR → Código o identificador del reporte ejecutado  
    
  • first_date → DATE → Fecha inicial del rango consultado  
    
  • second_date → DATE → Fecha final del rango consultado  
    
  • created_date → DATETIME → Fecha y hora de generación del registro  
    
  • status → INT → Resultado del procesamiento (1=éxito, 0=error)

• Ordenamiento por defecto:

  • Por created_date DESC

7) Frecuencia y operación

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

• Ventana recalculada: Hasta 3 meses previos.

• Tamaño de lote: Por rango mensual (obtainRangeDaysByYear).

• Tolerancia a fallos:

  • Inserta registro en emp_reportes_validation con status = 0 en caso de excepción.

• Tiempos esperados: PENDIENTE (Esperando info de Eduardo)

8) Calidad y controles

• Validaciones previas:

  • Verificación de rango de fechas válido.

  • Exclusión de registros eliminados o anulados.

• Post validaciones:

  • Inserción de registro en tabla de validación (status).

• Controles de duplicado:

  • Evita múltiples inserciones del mismo mes mediante llaves.

• Métricas de completitud:

  • Conteo de órdenes procesadas vs. esperadas por rango.

9) Dependencias externas

• APIs / Servicios: No aplica.

• Autenticación / Headers: No requerido.

• Mapeos / Contratos:

  • Depende del contrato interno entre bases empresarial y centos.

10) Historial de cambios

2025-10-29 17:00 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE CRM PERSONA

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

1) Nombre del reporte

• Nombre: Reporte CRM Persona

• Código / Alias: report_crm_person_

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

  • ose_fhpreferenciapartida → Fecha de partida del servicio

  • fecha_registro → Fecha de entrega registrada

  • Parámetros externos: $first_date, $second_date

• Tipo de rango (diario / mensual / personalizado):

  • Personalizado mensual, subdividido en 4 semanas (obtenerSemanasMes genera semanas S1–S4)

• 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 (o empresarial_old para año 2023)

Tabla / Recurso: emp_ordenservicio
Alias (si aplica): os

Campos utilizados (clave → descripción):

• ose_id → Identificador único del servicio.

• ose_termdestinoentrega → Código de destino.

• ose_fhpreferenciapartida → Fecha preferencial de partida.

• ose_remitecontactofono → Teléfono de contacto del remitente.

• ose_remitecontactomail → Correo de confirmación.

• ose_observacion_cambioprecio → Observación (tipo de orden).

• ose_montofinal → Monto total del servicio.

• ose_remiteempresa → Documento del remitente.

• ose_servpagotipo → Tipo de servicio.

• eliminado → Flag lógico (0 = activo).

• ose_estado → Estado del registro.

Condiciones (WHERE) aplicadas:

• ose_estadoPago NOT IN ('DA', 'AN')

• ose_tipoanulado = ''

• eliminado = 0

• ose_estado = 1

• ose_remiteempresa IN ($document)

• ose_fhpreferenciapartida BETWEEN $first_date 00:00:00 AND $second_date 23:59:59

Tipo de unión con otras fuentes (JOIN y llave):

• LEFT JOIN emp_persona AS per ON per.per_nrodocumento = os.ose_remiteempresa

Observaciones (ej. particiones, índices):

• Conexión cambia dinámicamente según el año (empresarial_old para 2023, empresarial para años posteriores).

• Tablas grandes, por lo que se aplica paginación en bloques de 400 documentos (array_chunk).

---

3.2 Conexión / Base: empresarial

Tabla / Recurso: emp_persona
Alias (si aplica): per

Campos utilizados (clave → descripción):

• per_nrodocumento → Documento de identidad del cliente.

• per_nombrerzsoc → Nombres / razón social.

• per_apellidopaterno / per_apellidomaterno → Apellidos.

• per_tipo → Tipo de persona (N = Natural).

• per_habilitado → Estado (1 = habilitado).

Condiciones (WHERE) aplicadas:

• per_tipo = 'N'

• per_habilitado = 1

Tipo de unión con otras fuentes (JOIN y llave):

• LEFT JOIN con emp_ordenservicio por documento (per_nrodocumento = ose_remiteempresa)

Observaciones:

• Tabla maestra de personas utilizada para formar el campo calculado remitentenombre.

---

3.3 Conexión / Base: capacitacion

Tabla / Recurso: tabPOS Invoice
Alias (si aplica): No aplica
Campos utilizados (clave → descripción):

• name → Identificador de factura POS.

• documento → Documento del remitente vinculado.

• grand_total → Importe total de la venta.

Condiciones (WHERE) aplicadas:

• creation <= %(second_date)s

• creation >= %(first_date)s

• docstatus = 1

• documento IN %(documents)s

Tipo de unión con otras fuentes (JOIN y llave):

• No se realiza unión directa; los resultados se vinculan lógicamente con el documento del remitente.

Observaciones:

• Fuente obtenida a través de API interna method/send-query-database (Frappe ERPNext).

• Se utiliza para calcular indicadores de “ventas store” (qty_store, amount_store).

---

3.4 Conexión / Base: empresarial

Tabla / Recurso: emp_envio_aereo
Alias (si aplica): No aplica

Campos utilizados (clave → descripción):

• id → Identificador interno.

• ose_id → Identificador de orden de servicio.

• contenido → Medio de envío (AÉREO o TERRESTRE).

Condiciones (WHERE) aplicadas:

• estado = 1

• contenido != 'TERRESTRE'

• ose_id IN ($keysAereas)

Tipo de unión con otras fuentes (JOIN y llave):

• Vinculado lógicamente con emp_ordenservicio por ose_id.

Observaciones:

• Agrupa envíos aéreos para calcular totales (qty_aereo, amount_aereo).

---

3.5 Conexión / Base: centos (o centosold para año 2023 y mes ≤ 9)

Tabla / Recurso: emp_procesos_historial_app
Alias (si aplica): No aplica

Campos utilizados (clave → descripción):

• idose → Identificador de orden de servicio.

• terminal → Terminal origen.

• fecha_registro → Fecha de registro de la entrega.

• tipo_entrega → Canal de entrega (SISTEMA o APP).

Condiciones (WHERE) aplicadas:

• proceso = 'entrega'

• nombre_metodo = 'registrar_Entrega'

• status = 1

• idose IN ($keysEntregas)

Tipo de unión con otras fuentes (JOIN y llave):

• Lógica: se enlaza por idose con registros de emp_ordenservicio.

Observaciones:

• Fuente utilizada para determinar si la entrega fue en oficina o a domicilio.

• Los registros se ordenan por fecha_registro ASC para tomar el primer evento válido.

 

4) Filtros globales del reporte

• Inclusiones (must-have):

  • Personas naturales habilitadas (per_tipo='N', per_habilitado='1')

  • Estados activos (ose_estado='1', status=1)

• Exclusiones:

  • Destino = 74

  • Tipo de orden = “Retiro de mercaderia”

  • EstadoPago en (“DA”, “AN”)

• Reglas por estado / habilitado:

  • Se excluyen anulados, eliminados y no habilitados.

• Parámetros externos:

  • $first_date, $second_date (rango de fechas personalizable)

5) Transformaciones y Reglas de negocio

• Derivaciones de campos:

  • remitentenombre = CONCAT(nombres y apellidos)

  • Agrupación por remitente → totales de montos y cantidades por día/semana

  • Identificación de tipo de envío (WEB, REGISTRA, corporativo, aéreo, terrestre)

• Mapeos de estado:

  • Día de la semana (en inglés → español: lunes, martes, etc.)

  • Tipo de entrega (SISTEMA → oficina, APP → domicilio)

• Reglas de validación:

  • Solo órdenes con contacto válido o confirmado

  • Validación de existencia de tabla de destino antes de insertar

• Condicionales:

  • Si year == 2023 usar conexiones _old

  • Si month <= 9 usar centosold

6) Estructura de salida

• Tabla/archivo destino: report_crm_person_YYYY_MM

• Particionado / sufijo: Por mes (YYYY_MM)

• Claves primarias / únicas: id (AUTO_INCREMENT)

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

  • periodo → VARCHAR(20) → Periodo de análisis (ej. “ENERO 2025”)  
  • nombre → VARCHAR(255) → Nombre del cliente o punto de venta  
  • tipo_cliente → VARCHAR(50) → Clasificación del cliente (comercial, corporativo, individual, etc.)  
  • documento → VARCHAR(20) → Número de documento de identificación o RUC  
  • cantidad_envios → INT → Total de envíos realizados en el periodo  
  • monto → DOUBLE(12,2) → Monto total asociado a los envíos  
  • envia_ya → INT → Total de envíos procesados por canal Envia Ya  
  • shalom_pro → INT → Total de envíos procesados vía portal Shalom Pro  
  • store → INT → Total de transacciones vía Shalom Store  
  • corporativo → INT → Total de envíos corporativos  
  • aereo → INT → Total de envíos transportados por vía aérea  
  • terrestre → INT → Total de envíos transportados por vía terrestre  
  • oficina → INT → Total de entregas en oficina  
  • domicilio → INT → Total de entregas a domicilio  
  • s1–s4 → INT → Métricas semanales (S1=Semana 1, S2=Semana 2, etc.)  
  • lunes–domingo → INT → Métricas diarias por día de la semana  
  • created_date → DATETIME → Fecha y hora de creación del registro  
  • status → TINYINT(1) → Estado del registro (1=activo, 0=inactivo)

•  

• Ordenamiento por defecto: no explícito (orden de inserción)

7) Frecuencia y operación

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

• Ventana de recalculo: 1 mes dividido en 4 semanas

• Tamaño de lote: inserciones por chunks de 900 registros

• Tolerancia a fallos: verificación de tabla y recreación automática

• Tiempos esperados:  PENDIENTE (Esperando info de Eduardo)

8) Calidad y controles

• Validaciones previas/post:

  • Verificación de tabla (verifyExistTable)

  • Creación de índices: created_date, status, documento

• Controles de duplicados:

  • Limpieza (truncate) de tabla existente antes de inserción

• Métricas de completitud:

  • Conteo de envíos y montos totales por remitente

  • Presencia de registros por día/semana

9) Dependencias externas

• APIs / servicios y endpoints:

  • dbErp → method/send-query-database (ERPNext)

• Autenticación / headers:

  • Utiliza configuración interna de $this->capacitacion

• Mapeos y contratos de datos:

  • Entrada: filtros JSON (filters, where, sql_query, tables)

  • Salida: { success: bool, data: [...] }

10) Historial de cambios

2025-10-29 17:49 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE CONTROL LEGAL

Fuente:  /var/www/html/qareportes/routes/cloud/reportes.php

SERVICIO LISTA: https://qa-reportsnew.shalomcontrol.com/cloud/reportes/report_control_legal/list
SERVICIO ACTUALIZA:  https://qa-reportsnew.shalomcontrol.com/cloud/reportes/report_control_legal/update

1) Nombre del reporte

• Nombre: Reporte Control Legal

• Código / Alias: 

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

  • firstDate

  • secondDate
    

• Tipo de rango (diario / mensual / personalizado):

  • Personalizado (se recibe en index())

  • La operación automática (update()) utiliza rango móvil de 3 meses hacia atrás

  • La salida final se particiona por mes usando el campo fecha o por el mes calculado desde $secondDate.
    

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

• Tabla / Recurso: tabCasilla Legal

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • fecha_de_recepción → f_notificacion

  • número_de_documento → nro_documento

  • discharge_deadline → f_limite_de_descargo

  • estado → estado
    

• Condiciones (WHERE) aplicadas:

  • creation >= firstDate

  • creation <= secondDate

  • Filtros aplicados mediante API:
    "where" => "creation <= %(endDate)s and creation >= %(startDate)s"
    
    

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

• Observaciones (ej. particiones, índices): 

  • Los campos son renombrados antes de insertarse en la estructura común.

  • Forma parte del merge principal en getAllData().

3.2 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabMunicipalidad

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • fecha_de_recepcion → f_notificacion

  • numero_de_exp_o_tramite_de_presentacion → nro_documento

  • fecha_limite_de_descargo → f_limite_de_descargo

  • estado → estado
    
    

• Condiciones (WHERE) aplicadas:

  • creation >= firstDate AND creation <= secondDate
    

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

• Observaciones (ej. particiones, índices): Estructura unificada mediante addName("MUNICIPALIDAD").

3.3 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabOtras Entidades

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • fecha_recepcion → f_notificacion

  • tipos_de_documentos → asunto

  • fecha_limite_de_descargo → f_limite_de_descargo

  • status → estado
    
    

• Condiciones (WHERE) aplicadas: creation BETWEEN firstDate AND secondDate
  

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

• Observaciones (ej. particiones, índices): Este doctype no contiene número de documento, solo asunto.

3.4 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabEntidades Judiciales

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • receipt_date → f_notificacion

  • num_dcumento → nro_documento

  • documenttype → asunto

  • deadline → f_limite_de_descargo

  • status → estado
    
    

• Condiciones (WHERE) aplicadas: creation >= firstDate AND creation <= secondDate
  

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

• Observaciones (ej. particiones, índices): Indicador en comentario: “Hay dos tipos de documentos” pero el origen es único.

3.5 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabSolicito descargo Carta N

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • fecha_recepcion → f_notificacion

  • motivo_de_la_carta → asunto

  • fecha_limite_descargo_del_a_legal → f_limite_de_descargo

  • estados → estado
    
    

• Condiciones (WHERE) aplicadas: creation BETWEEN firstDate AND secondDate
  

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

• Observaciones (ej. particiones, índices): Estructura normalizada como "DESCARGO CN".

3.6 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabSolicito Carta Notarial

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • fecha_comunico_a_legal → f_notificacion

  • fecha_entrega_cn → f_limite_de_descargo

  • estado → estado
    

• Condiciones (WHERE) aplicadas: creation >= firstDate AND creation <= secondDate
  

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

• Observaciones (ej. particiones, índices): No incluye número de documento ni asunto.

3.7 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabDocumentos SUNAT

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • document_reception_date → f_notificacion

  • document_number_request → nro_documento

  • seizure_reason → asunto

  • document_submission_date → f_limite_de_descargo

  • stage_ds → etapa

  • status_ds → estado
    

• Condiciones (WHERE) aplicadas: creation BETWEEN firstDate AND secondDate
  

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

• Observaciones (ej. particiones, índices): Este es el único recurso con el campo etapa, por lo que addName() preserva su estructura diferenciada.

3.8 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabExpediente Indecopi

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • receipt_date_exp_orps → f_notificacion

  • case_number → nro_documento

  • requested_corrective_action → asunto

  • release_submission_deadline → f_limite_de_descargo

  • status → estado
    

• Condiciones (WHERE) aplicadas: creation >= firstDate AND creation <= secondDate
  

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

• Observaciones (ej. particiones, índices): Campo asunto corresponde a acción correctiva solicitada.

3.9 Conexión / Base: ERP_CAPACITACION

• Tabla / Recurso: tabSustran

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • legal_area_entry_date → f_notificacion

  • document_number → nro_documento

  • presentation_deadline_date → f_limite_de_descargo

  • status → estado
    

• Condiciones (WHERE) aplicadas: creation BETWEEN firstDate AND secondDate
  

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

• Observaciones (ej. particiones, índices): Se unifica como documento “SUSTRAN”.

4) Filtros globales del reporte

• Inclusiones (must-have):  Registros donde creation está entre firstDate y secondDate

• Exclusiones (reglas de descarte): Filas con fecha inválida durante el particionado (dropped_rows)

• Reglas por estado / habilitado: No se aplica lógica adicional; se consume el valor como venga del ERP

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

  • firstDate (obligatorio)

  • secondDate (obligatorio)

  • El usuario puede usar el endpoint update() que fija rango automático –3 meses

5) Transformaciones y Reglas de negocio

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

  • Se estandariza estructura a:
    • f_notificacion
    • nro_documento
    • documento
    • asunto
    • f_limite_de_descargo
    • etapa
    • estado
      
      

• Mapeos de estado: No aplica

• Reglas de validación (p.ej., sólo registros validados):  Si la fecha usada para partición no es válida → la fila se descarta

• Reglas condicionales (si X entonces Y): Si no se pasa partición, se determina automáticamente por fecha

6) Estructura de salida

• Tabla/archivo destino:

  • Base: report_control_legal

  • Particiones: report_control_legal_YYYY_MM
    

• Particionado / sufijo: Formato: YYYY_MM

• Clave(s) primaria(s) o únicas: No definidas explícitamente (depende de replaceTableAtomic)

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

  • f_notificacion → fecha recepción / notificación

  • nro_documento → número de documento (cuando aplique)

  • documento → nombre del origen

  • asunto → tipo o detalle del documento

  • f_limite_de_descargo → fecha límite de descargo

  • etapa → etapa del trámite (solo ciertos orígenes)

  • estado → estado legal/interno
    

• Ordenamiento por defecto: No definido en código

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): 3 meses hacia atrás desde el día de ejecución

• Tamaño de lote / paginado (chunking): chunk_size: 300

• Tolerancia a fallos / reintentos:

  • rename_retries: 4

  • rename_backoff_ms: 300
    

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

8) Calidad y controles

• Validaciones previas/post: Validación de partición (mes válido)

• Controles de duplicados: Delegado a replaceTableAtomic (atomic replace)

• Métricas de completitud (qué se monitorea): Conteo de filas descartadas por fecha inválida

9) Dependencias externas

• APIs / servicios y endpoints:

  • Servicio ERP (send-query-database)

    • Método: POST

    • Body:

      • filters
      • where
      • sql_query
      • limit
      • tables
        
        

• Autenticación / headers: heredada del controlador dbErp() (no visible en este código)

• Mapeos y contratos de datos:
  

  [
    "valor" => true/false,
    "response" => [...]
  ]

10) Historial de cambios

2025-11-17 11:07 - Elian Franco Arroyo Rodas - Documentación inicial

REPORTE SHIPPING AMOUNT INFORMATION

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

1) Nombre del reporte

• Nombre:  Reporte Shipping Amount Information

• Código / Alias: report_shipping_amount_information

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):  

2) Alcance temporal

• Campo(s) de fecha utilizados: 

  • ose_fhemision (fecha de emisión de orden de servicio)

  • Rango: firstDate → secondDate

  • Para POS Invoices: posting_date
    

• Tipo de rango (diario / mensual / personalizado):  

  • Mensual dinámico, con:

    • Rango de meses recalculado según:

      • Mes actual

      • Mes anterior

      • Existencia de tabla histórica del año previo

    • Si no existe tabla histórica → agrega diciembre del año anterior.
      
      

• 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_usuario

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):

  • usr_id → Código del usuario

  • usr_terminalid → Terminal asignada

  • usr_alias → Alias visible

  • usr_rol → Rol del sistema
    

• Condiciones (WHERE) aplicadas: Ninguna (consulta completa)

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

• Observaciones (ej. particiones, índices): Resultado indexado por usr_id.

3.2 Conexión / Base:  EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):
  

  • ose_id → id del envío

  • ose_termorigenatencion → terminal origen

  • ose_termdestinoentrega → terminal destino

  • ose_fhemision → fecha emisión

  • ose_montofinal → monto final

  • ose_estadoentregado → estado entrega

  • ose_existencia_actual

  • ose_remitecontactofono → platform

  • ose_remitecontactomail → confirmed

  • ose_observacion_cambioprecio → type

  • ose_destinaempresa

  • ose_remiteempresa

  • ose_fhpreferencial

  • usercreaid → usuario creador
    

• Condiciones (WHERE) aplicadas: 

  • ose_fhemision BETWEEN firstDate 00:00:00 AND endDate 23:59:59

  • ose_estado = 1

  • eliminado = 0

  • ose_termdestinoentrega != 74

  • ose_estadoPago NOT IN ('AN','DA')

  • ose_tipoanulado = ''

  • Regla adicional en código:

    • Excluir type = 'Retiro de mercaderia'

    • Incluir registros según lógica de platform/confirmed
      
      

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

• Observaciones (ej. particiones, índices): 

  • Se usa para construir métricas diarias por usuario.

  • Filtra manualmente registros inválidos post-consulta.

3.3 Conexión / Base:  EMPRESARIAL

• Tabla / Recurso: emp_adicionales

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):
  

  • adc_ordenservicioid

  • adc_costo

  • terminalcrea
    

• Condiciones (WHERE) aplicadas: 

  • eliminado = 1

  • adc_tipo = 'E'

  • adc_ordenservicioid IN (ids)
    

• Tipo de unión con otras fuentes (JOIN y llave): Relación implícita con emp_ordenservicio.id

• Observaciones (ej. particiones, índices): 

  • Suma costo por OS.

  • Agrupa destinos.
    

3.4 Conexión / Base:  EMPRESARIAL

• Tabla / Recurso: emp_envio_aereo

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):
  

  • ose_id

  • contenido
    
    

• Condiciones (WHERE) aplicadas: 

  • estado = 1

  • ose_id IN (ids)
    

• Tipo de unión con otras fuentes (JOIN y llave): Relación implícita con orden de servicio.

• Observaciones (ej. particiones, índices): Identifica si un OS fue enviado por vía aérea o terrestre.
  

3.5 Conexión / Base:  EMPRESARIAL

• Tabla / Recurso: emp_incidencias

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):
  

  • inc_id

  • inc_idos
    

• Condiciones (WHERE) aplicadas: 

  • inc_idos IN (?)

  • inc_descripcion = 'CONTIENE PRODUCTOS PROHIBIDOS'

  • eliminado NULL OR 0

• Tipo de unión con otras fuentes (JOIN y llave): implícito con OS

• Observaciones (ej. particiones, índices): Identifica rechazos aéreos.

3.6 Conexión / Base:  CENTOS

• Tabla / Recurso: emp_historial_envia_ya

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):
  

  • inc_ose_idid

• Condiciones (WHERE) aplicadas: 

  • ose_id IN (?)

  • origen = 'TOTEM'
    

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

• Observaciones (ej. particiones, índices): No aplica

3.7 Conexión / Base:  Rakky

• Tabla / Recurso: deliveries

• Alias (si aplica): No aplica

• Campos utilizados (clave → descripción):
  

  • os_id

• Condiciones (WHERE) aplicadas: 

  • status_service = 1

  • status = 1

  • ose_id IN (ids)

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

• Observaciones (ej. particiones, índices): identificar entregas relacionadas a Rakki.

4) Filtros globales del reporte

• Inclusiones (must-have):

  • Órdenes con estado válido (ose_estado = 1, eliminado = 0)

  • Registros POS con docstatus = 1

  • Usuarios existentes en emp_usuario
    

• Exclusiones (reglas de descarte):

  • ose_tipoanulado != ""

  • ose_estadoPago IN ('AN','DA')

  • "Retiro de mercaderia"

  • Destino 74

  • Air con contenido TERRESTRE en métrica aérea.
    

• Reglas por estado / habilitado:

  • Aéreos sólo con estado = 1

  • Adicionales sólo con adc_tipo = 'E' AND eliminado = 1
    

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

  • Rango de fecha dinámico según calendario.

  • El usuario del endpoint no ingresa parámetros.

5) Transformaciones y Reglas de negocio

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

  • Cálculo de:

    • envíos

    • entregas

    • montos corporativos/comerciales

    • métricas aéreas (enviado/recibido)

    • métricas terrestres

    • totems

    • métrica rakki

  • Agrupación por usuario → día
    

• Mapeos de estado:

  • Empresa → corporativo / comercial

  • Plataforma:

    • REGISTRA → envia_ya

    • WEB → shalom_pro
      

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

• Reglas condicionales (si X entonces Y):

  • Si plataforma es vacía pero confirmado → incluir.

  • Si contenido != “TERRESTRE” → se considera envío aéreo.

  • Si order.delivered != 1 → contar como aereo_entregado_no.

6) Estructura de salida

• Tabla/archivo destino: report_shipping_amount_information_YYYY_MM

• Particionado / sufijo:  YYYY_MM

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

  • No se define explícitamente, pero combinación:

    • dia_de_emision + documento + id_terminal
      
      

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

  • dia_de_emision → DATE → Fecha de emisión del envío según POS Invoice u Orden de Servicio  
  • id_terminal → INT → Identificador numérico de la terminal asignada al usuario  
  • terminal → VARCHAR(255) → Nombre de la terminal donde opera el usuario  
  • usuarioid → INT → Identificador del usuario en el sistema principal  
  • document → VARCHAR(20) → Documento de identidad del usuario (DNI/RUC)  
  • codigo → VARCHAR(50) → Código interno o legajo del empleado  
  • n_completos → VARCHAR(255) → Nombre completo del usuario según el sistema empresarial  
  • usr_fullname → VARCHAR(255) → Nombre completo del usuario según ERPNext  
  • alia → VARCHAR(100) → Alias o nombre corto asignado al usuario  
  • puesto → VARCHAR(100) → Cargo o puesto laboral del colaborador  
  • modalidad → VARCHAR(50) → Modalidad laboral (planilla, locación, part-time, etc.)  
    
  • cantidad_envios → INT → Cantidad total de órdenes de servicio registradas por el usuario  
  • cantidad_entregas → INT → Total de órdenes entregadas confirmadas por el usuario  
  • monto_total → DECIMAL → Monto total de las órdenes procesadas por el usuario  
  • cantidad_rechazado → INT → Número total de envíos rechazados  
  • monto_rechazado → DECIMAL → Monto asociado a las órdenes rechazadas  
    
  • envia_ya → INT → Cantidad de envíos registrados por la plataforma ENVIA YA  
  • shalom_pro → INT → Cantidad de envíos procesados mediante SHALOM PRO  
  • total_corporativo → INT → Total de envíos clasificados como corporativos (empresa)  
  • total_comercial → INT → Total de envíos clasificados como comerciales (persona natural)  
    
  • terrestre_enviado → INT → Cantidad de envíos terrestres realizados  
  • terrestre_recibido → INT → Cantidad de entregas terrestres recibidas  
  • aereo_enviado → INT → Total de envíos aéreos emitidos según contenido declarado  
  • aereo_entregado → INT → Envíos aéreos entregados correctamente  
  • aereo_entregado_no → INT → Envíos aéreos que no llegaron a entregarse  
  • aereo_recojo → INT → Envíos aéreos con solicitud de recojo en origen  
  • rechazo_aereo → INT → Cantidad de incidencias por productos prohibidos en transporte aéreo  
  • total_totem → INT → Total de envíos generados mediante terminal TOTEM  
  • contador_rakki → INT → Total de envíos asignados a RAKKI  
  • monto_rakki → DECIMAL → Monto total asociado a envíos gestionados por RAKKI  
  • contador_store → INT → Cantidad de transacciones realizadas vía STORE  
  • monto_store → DECIMAL → Monto total generado por ventas STORE  
  • cantidad_pos → INT → Número de POS Invoices asociados al usuario  
  • monto_pos → DECIMAL → Monto total facturado mediante POS Invoice  
  • s1 → INT → Cantidad de envíos generados durante la semana 1 del mes  
  • s2 → INT → Cantidad de envíos generados durante la semana 2 del mes  
  • s3 → INT → Cantidad de envíos generados durante la semana 3 del mes  
  • s4 → INT → Cantidad de envíos generados durante la semana 4 del mes  
  • lunes → INT → Total de envíos realizados el día lunes  
  • martes → INT → Total de envíos realizados el día martes  
  • miercoles → INT → Total de envíos realizados el día miércoles  
  • jueves → INT → Total de envíos realizados el día jueves  
  • viernes → INT → Total de envíos realizados el día viernes  
  • sabado → INT → Total de envíos realizados el día sábado  
  • domingo → INT → Total de envíos realizados el día domingo  
  • created_date → DATETIME → Fecha y hora de creación del registro agregado  
  • status → VARCHAR → Estado del proceso (ej. “success”, “partial”, “error”)  
  • id_registro → INT → Identificador incremental interno del registro consolidado  
  • plataforma_filtro → VARCHAR → Plataforma asignada dinámicamente (envia_ya / shalom_pro)  
  • tipo_envio → VARCHAR → Clasificación del transporte (terrestre / aéreo)  
  • grupo_empresa → VARCHAR → Clasificación del cliente según RUC (corporativo / comercial)  
    
    

• Ordenamiento por defecto: usort(rows by dia_de_emision ASC)

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): últimos 1–2 meses o histórico si falta tabla.

• Tamaño de lote / paginado (chunking): lotes de 5000 IDs

• Tolerancia a fallos / reintentos:

  • safe() captura errores y retorna vacío

  • Logging con metadata del error
    

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

8) Calidad y controles

• Validaciones previas/post:

  • Validación de tabla histórica del mes/año anterior.

  • Manejo de excepciones por cada rango (try/catch)

  • Reintentos: indirectos mediante safe()
    

• Controles de duplicados: clave usuario/día evita duplicidad natural

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

  • registros de POS

  • órdenes de servicio

  • entregas

  • aéreos

  • totems

9) Dependencias externas

• APIs / servicios y endpoints:

  • Endpoint: method/send-query-database

  • Autenticación: interna (implícita)

  • Headers: manejados por framework
    

• Autenticación / headers:

  • Endpoint: /api/sale/report/shipping_amount

  • Parámetros:

    • startDate

    • endDate
      

• Mapeos y contratos de datos:

  • ERPNext retorna arrays planos con POS invoices.

  • STORE API retorna { success, data }.

10) Historial de cambios

2025-11-17 13:39 - Elian Franco Arroyo Rodas - Documentación inicial

Reporte Shipping Amount Worker

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

1) Nombre del reporte

• Nombre: Reporte Shipping Amount Worker

• Código / Alias:  report_shipping_amount_worker

• Responsable:  Equipo de Reportes Cloud

• Propósito (1 línea):

2) Alcance temporal

• Campo(s) de fecha utilizados:

  • ose_fhemision (órdenes de servicio – tabla empresarial)

  • posting_date (POS Invoice – ERPNext)
    

• Tipo de rango (diario / mensual / personalizado):

  • Mensual, autogenerado dinámicamente.

  • Soporta casos especiales (enero y febrero), retrocediendo al año anterior.
    

• 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: ERP - CAPACITACION

• Tabla / Recurso: tabPOS Invoice

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 

  • owner → Usuario creador (usado para obtener DNI).

  • posting_date → Fecha de emisión (rango).

  • name → Identificador del POS Invoice.
    

• Condiciones (WHERE) aplicadas: 

  • docstatus = 1
  • posting_date >= inicio
  • posting_date <= fin

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

• Observaciones (ej. particiones, índices):  

  • Se aplican filtros dinámicos enviados como JSON.

  • Los DNI se extraen de owner antes de @.

  • Se descartan propietarios que no tengan DNI numérico.
    

3.2 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_ordenservicio

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 
  

  • ose_id → ID de orden.

  • usercreaid → Usuario creador (usado como clave principal).

  • ose_montofinal → Monto final.

  • ose_estadoentregado → Estado entrega.

  • ose_remitecontactofono → Platform WEB/REGISTRA.

  • ose_remitecontactomail → Confirmación.

  • ose_observacion_cambioprecio → Tipo de orden (exclusión).

  • ose_destinaempresa → Empresa de Destino
  • ose_remiteempresa → Empresa
  • ose_fhpreferencial → Fecha y hora preferencial
    
    

• Condiciones (WHERE) aplicadas: 

  • ose_fhemision BETWEEN firstDate 00:00:00 AND endDate 23:59:59
  • ose_estado = '1'
  • eliminado = '0'
  • ose_termdestinoentrega != 74
  • ose_estadoPago NOT IN ('AN', 'DA')
  • ose_tipoanulado = ' '
    

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

• Observaciones (ej. particiones, índices):  

  • Filtra órdenes eliminadas, anuladas y con destino específico.

  • Descarta órdenes de tipo “Retiro de mercaderia”.

  • Consolida solamente órdenes válidas y confirmadas.

3.3 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_adicionales

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 
  

  • adc_ordenservicioid → ID de orden enlazado.
    
    

• Condiciones (WHERE) aplicadas: 

  • eliminado = '1'
  • adc_tipo = 'E'
  • adc_ordenservicioid IN (lista chunk)
    
    

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

• Observaciones (ej. particiones, índices):  

  • Procesamiento en chunks de 5000 IDs.

  • Se generan maps (order_id => 1) para ver si una orden tuvo “entrega”.

3.4 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_envio_aereo

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 
  

  • • ose_id → Orden asociada.

    • contenido → Clasificación (aéreo, terrestre).

    
    

• Condiciones (WHERE) aplicadas: 

  • estado = '1'
  • ose_id IN (lista chunk)
    
    

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

• Observaciones (ej. particiones, índices):  

  • Procesamiento masivo en chunks.

  • Se devuelve un diccionario por orden, manteniendo el objeto completo.
    
    

3.5 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_persona

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 
  

  • • per_nrodocumento → DNI (clave principal).

    • per_nombrerzsoc, per_apellidopaterno, per_apellidomaterno → Generación del nombre completo.

    
    

• Condiciones (WHERE) aplicadas: 

  • per_nrodocumento IN (chunk de DNIs)
    
    

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

• Observaciones (ej. particiones, índices):  

  • Procesado en chunks de 500 registros.

  • Se genera nombre concatenado y sanitizado.

3.6 Conexión / Base: EMPRESARIAL

• Tabla / Recurso: emp_usuario

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 
  

  • • usr_id → ID del usuario (clave).

    • usr_terminalid → Terminal asignado.

    • usr_alias, usr_rol → Metadatos del usuario.

    
    

• Condiciones (WHERE) aplicadas: 

  • usr_id IN (chunk)
    
    

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

• Observaciones (ej. particiones, índices):  

  • • Procesamiento por lotes.

    • Regresa mapa usr_id => objeto usuario.

3.7 Conexión / Base:  CAPACITACION

• Tabla / Recurso: tabEmployee

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 
  

  • • passport_number → Documento (clave).

    • employment_type → Tipo de jornada (FULL/PART TIME).

    
    

• Condiciones (WHERE) aplicadas: 

  • passport_number IN %(employees)s
  • ORDER BY name ASC
    
    

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

• Observaciones (ej. particiones, índices):  

  • • Se conecta mediante send-query-database.

    • Se retorna un mapa por número de documento.

3.8 Conexión / Base:  EMPRESARIAL

• Tabla / Recurso: emp_terminal

• Alias (si aplica):  no aplica

• Campos utilizados (clave → descripción): 
  

  • • ter_id → Terminal ID.

    • ter_nombre → Nombre del terminal.

    
    

• Condiciones (WHERE) aplicadas: 

  • ter_id IN (chunk)

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

• Observaciones (ej. particiones, índices):  

  • • Proceso por lotes de 500 IDs.

    • Devuelve diccionario para mapeo directo terminal–usuario.

4) Filtros globales del reporte

• Inclusiones (must-have): 

  • Órdenes con estado válido, no eliminadas, no anuladas.

  • Registros de tipo WEB y REGISTRA según reglas.

  • Employees cuyo owner es un correo válido con DNI numérico.
    

• Exclusiones (reglas de descarte):

  • Órdenes con type = 'Retiro de mercaderia'

  • Órdenes anuladas, eliminadas, destino = 74

  • POS Invoice owner sin correo válido o sin DNI numérico

  • Envíos aéreos con contenido = "TERRESTRE"
    

• Reglas por estado / habilitado:

  • eliminado = 0 en órdenes

  • estado = 1 en aéreo

  • docstatus = 1 en POS
    

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

  • firstDate

  • secondDate

5) Transformaciones y Reglas de negocio

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

  • mes_de_emision = YYYY_MM desde firstDate

  • modalidad

    • FULL TIME si tipo_jornada == "JORNADA COMPLETA"

    • PART TIME en otro caso

  • Cálculo de conteos:

    • envios_aereos++ cuando aplica

    • reparto++ cuando orden existe en adicionales

    • store = cantidad POS Invoice por usuario

    • envia_ya para platform REGISTRA

    • shalom_pro para platform WEB
      

• Mapeos de estado:

  • Aéreo: sólo contenido != "TERRESTRE" cuenta como envío aéreo.

  • POS Invoice agrupado por DNI extraído del email.
    

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

  • Si no hay user en orden → skip

  • DNI debe ser numérico

  • Uso de utils.safe() para evitar interrupciones.
    

• Reglas condicionales (si X entonces Y):

  • Platform vacío → solo incluir si confirmed == true

  • Si un usuario no existe en alguna lista, se ignora o se crea con valores base.

6) Estructura de salida

• Tabla/archivo destino: report_shipping_amount_worker

• Particionado / sufijo:  Por mes_de_emision → YYYY_MM

• Clave(s) primaria(s) o únicas: No definida; filas agregadas por usuario y mes.

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

  • mes_de_emision → VARCHAR → Mes correspondiente a la emisión del envío  
  • id_terminal → VARCHAR | NULL → Identificador de la terminal (puede no existir)  
  • terminal → VARCHAR → Nombre de la terminal asociada  
  • nombre_completo → VARCHAR → Nombre completo del usuario  
  • documento → VARCHAR → Documento del usuario (DNI/RUC)  
  • modalidad → VARCHAR → Modalidad laboral del usuario  
  • envios_aereos → INT → Cantidad total de envíos aéreos registrados  
  • repartos → INT → Total de repartos realizados  
  • store → INT → Cantidad de ventas o envíos generados en STORE  
  • envia_ya → INT → Cantidad de envíos registrados por ENVIA YA  shalom_pro → INT → Cantidad de envíos registrados por SHALOM PRO  
    
  • created_date → DATETIME → Fecha de creación del registro  
    
  • status → INT → Estado del registro (1 = activo, 0 = error)
    

• Ordenamiento por defecto: Sort por mes_de_emision ascendente.

7) Frecuencia y operación

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

• Ventana que recalcula (días/meses): Todos los meses entre firstMonth y lastMonth.

• Tamaño de lote / paginado (chunking):

  • 5000 IDs para órdenes aéreas y adicionales.
  • 500 IDs para personas, usuarios y terminales.
    

• Tolerancia a fallos / reintentos:

  • utils->safe() recupera errores por origen.

  • Se almacena log en tabla de errores.
    

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

8) Calidad y controles

• Validaciones previas/post: 

  • Validación de DNI numérico.

  • Validación de correo válido.

  • Confirmación de platform.
    

• Controles de duplicados:

  • Agrupación manual por DNI/usuario.

  • Unicidad de POS Invoice por usuario.
    

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

  • Errores por etapa (report, stage).

  • Cantidad de órdenes procesadas.

9) Dependencias externas

• APIs / servicios y endpoints:

  • Endpoint: APICAPACITACION/method/send-query-database

  • Tipo: POST

  • Autenticación: manejada por dbErp
    

• Autenticación / headers:

  • Endpoint: STORE/api/sale/report/shipping_amount

  • Método: GET

  • Parámetros:

    • startDate

    • endDate
      

• Mapeos y contratos de datos: 

  • DNI obtenido del email: "12345678@empresa.com" → "12345678"

  • Datos unificados de ERP y STORE.

10) Historial de cambios

2025-11-17 15:52 - Elian Franco Arroyo Rodas - Documentación inicial