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