Ir al contenido principal

REPORTE CONTROL LEGAL

Fuente:  /var/www/html/qareportes/routes/cloud/reportes.php

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)

  • 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().


  • 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").

  • 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.

  • 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.

  • 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".

  • 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.

  • 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.

  • 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.

  • 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