Número de solicitud
Auto-generado · no editable
Progreso de la Solicitud
0%
Formulario
Solicitud de ingreso
Los dropdowns marcados como ERP son de referencia. En produccion deben poblarse desde maestros reales.
Objeto ERP
Preview del contrato esperado
El sistema muestra como se va poblando el payload aun sin conectividad real.
Header
pendiente0%
Partidas
pendiente0%
Items
pendiente0%
Financiero
pendiente0%
Documentos
pendiente0%
Fases
Mapa completo de validacion
Las 6 fases que el agente ejecuta al validar un caso. Por ahora son una referencia estatica — en Fase 8 de implementacion cada tarjeta mostrara el score y los issues reales del caso activo.
Fase 1 — Integridad del formulario e identidad
Valida que todos los campos obligatorios de identidad y contrato esten completos: tipo de tramite, titulo, preparado por, proveedor, centro contable, fechas, condiciones de pago y contexto presupuestario. Sin esta fase aprobada el caso no puede avanzar.
Fase 2 — Checklist de documentos
Verifica que los documentos obligatorios para el tipo de tramite seleccionado esten adjuntos al caso: solicitud firmada, cotizacion del proveedor, cuadro comparativo, paz y salvo CSS, RUC, poderes legales y demas segun el tipo. El score de documentos requeridos se calcula aqui.
Fase 3 — Lookup contra maestros ERP
Confirma que los valores de lookup existan en los catalogos reales del ERP: proveedor activo en dwRM.d_proveedor, centro contable en dwRM.d_centro_contable, cuentas en dwRM.f_cuenta, categorias, items y unidades en sus respectivos maestros. Depende de la conexion a Vertica (Fase 6 de implementacion).
Fase 4 — Validacion del payload de creacion ERP
Confirma que el JSON normalizado pueda convertirse en un contrato valido en Flexio: estructura correcta de partidas e items anidados, item_attribute como texto libre, empresa_id presente, item_amended_quantity_initial en cero, tax_type ITBMS y todos los campos requeridos por el endpoint de creacion.
Fase 5 — Controles cruzados y derivados
Ejecuta validaciones de consistencia entre campos: monto declarado vs. suma de partidas e items, fecha inicio anterior a fecha fin, anticipo y retencion dentro de limites de politica, saldo presupuestario suficiente para el monto a contratar, y centro contable coherente con el proyecto seleccionado.
Fase 6 — Gobernanza, aprobacion y cierre
Capa de flujo de aprobacion: ruteo al jefe de departamento, registro de decision (aprobado / rechazado / devuelto con observaciones), firma digital via DocuSign o equivalente, creacion del contrato en Flexio con numero CT26XXXXXX, y cierre del expediente con trazabilidad completa en ai_case_events.
API
Contrato operativo por endpoints
La UI ya expone el contrato que consume el backend cuando la base URL de la API esta configurada.
POST /subcontracts/intake
Crear el caso inicial en `ai_cases` con el `form_payload_json`, referencias maestras y metadata de captura.
GET /subcontracts/intake/{case_id}
Leer el caso completo para repoblar el formulario, el estado del payload, el resumen operativo y los datos ya capturados.
PATCH /subcontracts/intake/{case_id}
Guardar cambios parciales del caso mientras el usuario edita, corrige o completa la captura inicial.
POST /subcontracts/intake/{case_id}/documents
Subir adjuntos y soportes del caso hacia `ai_case_documents` como segunda capa, posterior al formulario.
POST /subcontracts/intake/{case_id}/validate
Ejecutar validaciones por fase, revisar faltantes, bloquear avance y recalcular readiness general y readiness ERP.
GET /subcontracts/intake/{case_id}/issues
Recuperar observaciones, bloqueos, inconsistencias y explicaciones para que el frontend muestre el estado operativo del caso.
GET /subcontracts/intake/{case_id}/validations
Leer el historial de corridas de validacion y sus scores por fase, lookup ERP, payload y cross-checks.
GET /subcontracts/catalogs/reference-data
Poblar dropdowns y lookups desde `ai_reference_entities`, con filtros por tipo de catalogo, proyecto o contexto operativo.
GET /subcontracts/audit/{case_id}
Exponer trazabilidad, eventos del caso, decisiones, hallazgos y evidencia historica del expediente.
Dataflow
Staging y DW hacia AI tables y endpoints
Esta vista muestra el recorrido recomendado desde tablas fuente reales, pasando por la tabla AI correspondiente, hasta el endpoint que la app o el agente consumirian.
Lookup de proveedores
stRM.pro_proveedores → dwRM.d_proveedor → ai_reference_entities → GET /subcontracts/catalogs/reference-data
Puebla dropdown de proveedor y soporta validacion de existencia del subcontratista.
Lookup de centros contables
stRM.centros_contables + stRM.cen_centros_tipos → dwRM.d_centro_contable → ai_reference_entities → GET /subcontracts/catalogs/reference-data
Puebla centro contable y filtra opciones por contexto del proyecto.
Lookup de cuentas
stRM.contab_cuenta → dwRM.f_cuenta → ai_reference_entities → GET /subcontracts/catalogs/reference-data
Entrega cuentas contables validas para partidas y reglas de payload ERP.
Disponibilidad presupuestaria
stRM.presupuesto_y_avance + stRM.presupuestos_y_adendas + stRM.facturas → dwRM.f_centro_presupuesto → ai_reference_entities / ai_case_validations → POST /subcontracts/intake/{case_id}/validate
Soporta validaciones de presupuesto, consumo y disponibilidad por centro o cuenta.
Usuarios internos
stRM.usuarios → ai_reference_entities → GET /subcontracts/catalogs/reference-data
Valida requester, preparer y actores del flujo antes de submit.
Caso de intake
formulario del usuario → ai_cases → POST /subcontracts/intake, GET /subcontracts/intake/{case_id}, PATCH /subcontracts/intake/{case_id}
Es la columna vertebral del caso y el contenedor del payload normalizado.
Documentos del caso
uploads del usuario → ai_case_documents → POST /subcontracts/intake/{case_id}/documents
Registra soportes y anexos como segunda capa posterior a la captura inicial.
Corridas de validacion
dwRM.d_proveedor + dwRM.d_centro_contable + dwRM.f_cuenta + dwRM.f_centro_presupuesto + stRM.usuarios → ai_case_validations → POST /subcontracts/intake/{case_id}/validate, GET /subcontracts/intake/{case_id}/validations
Guarda readiness, scores por fase y resultados de validacion del caso.
Issues del caso
ai_case_validations → ai_case_issues → GET /subcontracts/intake/{case_id}/issues
Expone faltantes, bloqueos, inconsistencias y observaciones del agente.
Auditoria y trazabilidad
ai_cases + ai_case_documents + ai_case_validations + ai_case_issues → ai_case_events → GET /subcontracts/audit/{case_id}
Consolida el historial del caso para seguimiento, soporte y control.