Fuente de Datos
Origen, naturaleza y alcance de los datos que alimentan este dashboard.
Sobre los Datos
Los datos utilizados en esta aplicación provienen del SECOP II (Sistema Electrónico de Contratación Pública) y de las bases de datos de sanciones, publicados en la plataforma datos.gov.co (API Socrata). Los datos se presentan sin modificación, tal como se encuentran en la fuente original.
El sistema integra 12 datasets de datos abiertos que se descargan de forma automatizada mediante un orquestador externo (n8n) que dispara los procesos de carga con la API key.
Datasets Integrados
| Dataset | ID | Tabla en el dashboard | Fuente |
|---|---|---|---|
| SECOP II - Contratos Electrónicos | jbjy-vk9h |
contratos — base de todo el análisis |
datos.gov.co |
| SECOP II - Adiciones | cb9c-h8sn |
adiciones |
datos.gov.co |
| SECOP II - Ejecución Contratos | mfmm-jqmq |
ejecuciones |
datos.gov.co |
| SECOP II - Suspensiones de Contratos | u99c-7mfm |
suspensiones — suspensiones y reanudaciones por contrato |
datos.gov.co |
| SECOP II - Facturas | ibyt-yi2f |
facturas — trazabilidad de pagos por contrato |
datos.gov.co |
| Proponentes por Proceso SECOP II | hgi6-6wh3 |
proponentes — competencia por proceso |
datos.gov.co |
| SECOP II - Garantías | gjp9-cutm |
garantias — pólizas por contrato |
datos.gov.co |
| SECOP II - Procesos de Contratación | p6dx-8zbt |
procesos — puente contrato↔proponentes + datos de competencia (respuestas, adjudicación) |
datos.gov.co |
| Multas y Sanciones SECOP I | 4n4q-k399 |
sancionados — primeras 2 filas; cargadas juntas vía /populed |
datos.gov.co |
| Antecedentes de SIRI | iaeu-rcn6 |
sancionados — sanciones disciplinarias certificables; cargadas juntas vía /populed |
datos.gov.co |
| SECOP II - Multas y Sanciones | it5q-hg94 |
sanciones_secopii — sanciones vigentes asociadas a procesos de SECOP II |
datos.gov.co |
| SECOP II - Plan de Pagos | uymx-8p3j |
plan_pagos — pagos programados por contrato |
datos.gov.co |
Análisis de Co-Ocurrencia de Proponentes
El dashboard detecta proponentes que se presentan juntos de manera recurrente
en los mismos procesos de contratación — un indicador de afinidad competitiva: quién se presenta con quién y con qué frecuencia. El análisis cruza los
datasets de proponentes y procesos (el puente que une contratos con sus
requisiciones, formato CO1.BDOS.* → CO1.REQ.*).
Las asociaciones se computan en tres niveles (pares, tríos y cuartetos), mediante
generalizaciones de la misma query: a JOIN b para pares, a JOIN b JOIN c
para tríos, etc., con la condición a < b < c < d para evitar duplicar combinaciones.
Sobre este grafo también se detectan clústeres maximales (Bron–Kerbosch) — grupos
cerrados completos donde todos los integrantes co-ocurren entre sí.
- Procesos juntos: número de procesos de contratación en los que todos los integrantes del grupo se presentaron en competencia.
- Solapamiento min (%): qué porcentaje de la actividad del integrante con menos procesos se comparte con el resto del grupo. Alto = su actividad está mayormente compartida con el grupo.
- Peso relativo por proveedor: en la página de cada proveedor, qué porcentaje de su actividad total (y de la del asociado) representa la co-ocurrencia.
- Exclusividad: el complemento del solapamiento — porcentaje de procesos donde un integrante compite sin el otro. Exclusividad baja = "nunca se separan".
- Lift (x): cuántas veces más probable es que el grupo se presente junto respecto a lo esperable al azar — destaca las asociaciones que serían poco probables al azar.
- Clústeres maximales (Bron–Kerbosch): camarillas donde todos los miembros co-ocurren entre sí; el algoritmo encuentra el elenco completo, no fragmentos.
El ranking de pares se muestra en la página de inicio; los rankings por entidad y proveedor viven en cada perfil de entidad y perfil de proveedor (con el peso relativo de cada miembro). Los rankings de tríos, cuartetos y camarillas maximales están en la página dedicada de co-ocurrencia.
Alertas de Garantías Vigentes
El dashboard expone una métrica de auditoría civil: cuántos contratos en estado En ejecución no cuentan con ninguna garantía vigente (es decir, ninguna póliza con estado Aceptada cuya fecha de fin sea hoy o posterior), y cuánto valor monetario acumulado representa esa exposición sin cobertura. Esta señal apunta a un riesgo operativo y jurídico para la entidad contratante: si el contrato incumple, no hay respaldo de póliza que responda.
Definiciones operativas (ver spec):
- Contrato vigente:
contratos.estado_contrato = 'En ejecución' - Garantía vigente:
garantias.estado = 'Aceptada' AND garantias.fecha_fin_poliza >= today(UTC) - Contrato sin garantía vigente: contrato vigente que NO tiene ninguna garantía vigente — query con subquery
NOT EXISTScorrelacionada.
La señal está disponible en cuatro puntos del sitio:
- Vista dedicada
/html/alertas/garantias— KPI + ranking de entidades + lista de contratos en riesgo. - Dashboard
/dashboard— 5ta KPI card Contratos sin garantía vigente con drill-down a la vista dedicada. - API JSON
/api/alertas/garantias— KPI programático (conteo + valor expuesto + % exposición). - API ranking
/api/alertas/garantias/entidades— top entidades por valor expuesto.
Out-of-scope (sigue como trabajo futuro): notificaciones automáticas (email/Slack) cuando un contrato queda sin cobertura; histórico de cobertura (snapshot diario); cruce con sanciones vigentes (proveedor sancionado + contrato sin garantía = alerta doble); soporte para otros estados de contrato vigentes (Activo, Suspendido).
Metodología
- Recolección: descarga desde la API pública de datos.gov.co (Socrata) mediante workers de carga, disparados por un orquestador externo (n8n) con la API key del sistema.
- Deduplicación: los datasets sin identificador oficial (suspensiones, facturas, garantías, proponentes) se deduplican con un hash determinístico — las corridas repetidas no duplican datos.
- Puente de procesos: los proponentes se unen a los contratos a través de la tabla
procesos(un portafolio CO1.BDOS.* puede contener varias requisiciones CO1.REQ.* — relación 1:N). - Indicadores: los contadores de cada contrato (suspensiones, reanudaciones, adiciones, proponentes, garantías, facturas) se calculan y sincronizan al final de cada carga.
- Análisis: la co-ocurrencia de proponentes (pares, tríos, cuartetos, clústeres maximales + lift y exclusividad) y las alertas de garantías vigentes se computan en cada vista desde la DB local.
- Trazabilidad: cada corrida de carga queda registrada con fecha de inicio y fin en la página de Estadísticas.
Limitaciones
- Los datos se presentan tal como vienen de la fuente original — pueden existir errores, tildes o inconsistencias propios de los datos públicos.
- En las sanciones y amonestaciones no siempre se tiene claro cuándo deja de estar vigente la amonestación o su duración.
- Los datasets de gran volumen (facturas, proponentes, garantías, suspensiones) se cargan acotados a los contratos presentes en la base local.
- La actualización de los datos depende del orquestador externo (n8n) y de la disponibilidad de la API de datos.gov.co.
- Las alertas de garantías vigentes dependen de la calidad del campo
fecha_fin_polizaen el datasetgarantias: si la fecha falta o tiene datos sucios, el contrato puede aparecer falsamente como "sin cobertura". - El dataset de garantías en producción tiene cobertura parcial (~91.7k garantías cargadas contra ~1.7M contratos en ejecución) — los conteos de "sin garantía vigente" pueden inflarse por ausencia de datos, no necesariamente porque la garantía no exista.