diff --git a/FUTUROS_CAMBIOS.md b/FUTUROS_CAMBIOS.md deleted file mode 100644 index 4a4dd82..0000000 --- a/FUTUROS_CAMBIOS.md +++ /dev/null @@ -1,173 +0,0 @@ -# FUTUROS CAMBIOS — Dashboard LEADS - -Lista de cosas pendientes que el usuario quiere hacer más adelante. -Cuando el usuario pida "futuros cambios", recordarle TODO esto. - ---- - -## 1. Mapa de campañas (frases de pauta) → mover a GitHub o Supabase -- Hoy está incrustado en el código: `backend/data_manager_v2.py`, lista `CAMPANIAS` - (las ~90 frases con emojis + programa/sede/código/rango de fechas). -- Objetivo: sacarlo a un JSON en GitHub (o tabla en Supabase) para editarlo - sin tocar el código (igual que se hace en el otro dashboard con las clasificaciones). - -## 2. Leyenda de los códigos de pauta → a GitHub/Supabase -- Los códigos de campaña (191, 193, 63a, etc.) y su significado. -- Mismo objetivo: que sea editable fuera del código. - -## 3. Excluir cursos (num_indice) puntuales del cálculo -- Por ahora EXCLUIR del cálculo de Ocupabilidad/cursos: **num_indice 1154 y 1121**. -- Motivo: el usuario indicó que no deben contar (ej. reprogramados a otro mes). -- Idea a futuro: manejar esta lista de exclusión desde GitHub/Supabase, no en código. -- (Relacionado: el PBI filtra cursos por FECHA_MOSTRAR_COL = fecha con reprogramación - de SharePoint; aquí no tenemos esa columna todavía → Cursos Reprogramados quedó en fase 2.) - -## 4. Reprogramación de cursos (SharePoint) — FASE 2 [DEPENDE DE LA FUENTE] -La fecha ORIGINAL planificada de cada curso venía de SharePoint -(BaseBI_Programacion: FECHA CALENDARIO vs FECHA REPROGRAMADO). Sin esa fuente, -varios KPIs no se pueden calcular exacto. Pendiente: traerla de Google Sheets / Supabase / JSON -y construir FECHA_MOSTRAR_COL, FECHA_CUADRO_BI y ESTADO_CUADRO_BI. - -KPIs/cosas que dependen de esto (hoy aproximados o en 0): -- **Cursos Reprogramados** → hoy SALE 0 (no hay fecha original para comparar). -- **Cursos Programados** → hoy usa solo `fch_inicio` (el PBI usa planificada + reprogramada). - Diferencia chica, se cuadrará en fase 2. -- **Cursos Iniciados / Suspendidos** → hoy por `fch_inicio` y `cod_estado`; revisar con reprogramación. -- La exclusión manual de cursos (1154, 1121) es justo por reprogramación: cuando llegue - la fuente, esto debería resolverse solo (ya no haría falta la lista manual). - -## 5. Matriz por Curso (num_indice) con métricas de Leads por Pauta — NUEVA -El usuario quiere una MATRIZ debajo de la tabla por Sede, con: -- FILA: Fact_SQL_Base_Cursos[Personalizado], separada por cada num_indice (cursos se repiten). -- VALORES: Fecha_Inicio_Visual, Leads_Acumulados_Historico, Cant_Leads_Nuevos, - Cant_Leads_Nuevos_Con_Asesor, Cant_Leads_Nuevo_x_Mes, Cant_Leads_Nuevos_x_Mes_Con_Asesor. - -DEPENDE DE: el campo **Pauta** (código de campaña) de CADA curso, que en el PBI venía de -SharePoint (BaseBI_Programacion → PAUTA_CODIGO). El cruce de TODAS esas medidas es por -TREATAS(Cursos[Pauta], Leads[codigo]) — o sea por CÓDIGO, no por teléfono. - -Lo que se necesita para construirla (traer a Google Sheets / Supabase / JSON): -- Por cada num_indice (curso): su **código(s) de Pauta** asociado. -- Idealmente también FECHA_CUADRO_BI (fecha real/reprogramada) — mismo paquete que el punto 4. - -Medidas (ya tengo las fórmulas DAX exactas guardadas): -- Cant_Leads_Nuevos = leads únicos (Cantidad_Veces=1) con codigo = Pauta del curso, histórico. -- ..._Con_Asesor = + asesor no vacío. -- ..._x_Mes = igual pero respeta filtro de fecha del mes. -- ..._x_Mes_Con_Asesor = del mes + con asesor. -- Leads_Acumulados_Historico = suma de Cant_Leads_Nuevos de cursos del mismo Personalizado - con fecha <= la del curso actual. -- Fecha_Inicio_Visual = FECHA_CUADRO_BI del curso. - -ESTADO: ✅ La MATRIZ YA ESTÁ CONSTRUIDA en el dashboard (backend `leads_logic.matriz_cursos`, -frontend "Detalle por Curso"). Hoy muestra Programa + Fecha Inicio reales; las 5 columnas de -leads salen en 0 porque FALTA el código de Pauta por curso. Cuando llegue la fuente, solo se -rellena el cruce y se activan las 5 medidas. - -### Fuente SharePoint que hay que conectar (acordado) -Archivo: Base_BI_2.xlsx -Ruta: https://escuelarefrigeracion.sharepoint.com/sites/ASESORASCOMERCIALES/ - Documentos compartidos/2. BASE PROSPECTOS/BASE GENERAL/Patricia/Base_BI_2.xlsx -Tabla: BaseBI_Programacion -Columnas: NUM_INDICE, FECHA CALENDARIO, FECHA REPROGRAMADO, ESTADO, CONTAR, PAUTA_CODIGO -Cruce: Cursos[NUM_INDICE] → BaseBI_Programacion[NUM_INDICE] ⇒ PAUTA_CODIGO - (en el PBI: columna calculada Pauta = RELATED(BaseBI_Programacion[PAUTA_CODIGO])) - Luego: TREATAS(Cursos[Pauta], Leads[codigo]) para contar leads. - -Cómo leerla (3 opciones, de menos a más esfuerzo): -1) (Recomendado) Que Patricia/usuario suba a Supabase una tabla `cursos_pauta` - (num_indice, pauta_codigo, fecha_cuadro_bi). El backend ya tiene credenciales Supabase. - → cero auth de Microsoft, instantáneo, editable. -2) Exportar esa hoja a un Google Sheet / CSV en GitHub (GITHUB_BASE ya configurado). -3) Lectura directa SharePoint con Office365-REST-Python-Client (requiere usuario+clave M365 - o app registration). Más frágil; dejarlo como última opción. - -Cuando exista la fuente, en `data_manager_v2.py` agregar `traer_cursos_pauta()` y mapear -num_indice→pauta sobre los cursos; en `leads_logic.matriz_cursos` reemplazar los 0 por el -conteo de leads cruzado por codigo (las fórmulas DAX de arriba ya están claras). - -## 6. Base Junta (identificador de canal de origen por teléfono) — FUTURO -Objetivo: cuando un número se MATRICULA, saber su CANAL DE ORIGEN (y sede/programa/código) -para clasificarlo. Se usará como "memoria" de consulta por teléfono. - -Fuente/lógica (ya PROBADA y validada con el usuario): -- Une leads de POSTGRE (Chatwoot + mapa de campañas CAMPANIAS → canal/sede/programa/código) - + SUPABASE `datos_unificados` (Telefono, Fechacreada, Canal, Sede, Programa, Codigo). -- Teléfono NORMALIZADO: quita '+51', '+', espacios, '-', '(', ')'. -- DEDUP por teléfono → se queda con el MÁS ANTIGUO (solo por FECHA, sin hora). -- Desempate misma fecha: 1) PAUTA_WSP 2) PAUTA_WSP_FACE 3) orden alfabético del canal. -- Texto en MAYÚSCULAS; '-' de Supabase → vacío. -- Resultado prueba: ~45,054 teléfonos únicos. - -Script de prueba (standalone, corre en cualquier carpeta): `base_junta_full.py` -(genera base_junta_full.xlsx con 6 columnas: Telefono, Canal, Fecha Creada, Sede, -Programa, Codigo). NO está conectado al dashboard todavía. - -Cómo conectarlo a futuro (acordado, debe ser LIVIANO): -- Subir la base junta a una tabla en Supabase (ej. `base_junta`). -- El backend la carga UNA vez en un dict {telefono → datos}, cacheado (refresco ~15 min). -- Al cruzar una matrícula por teléfono → se obtiene su canal de origen y se clasifica. -- 44-73k filas en dict = instantáneo, sin impacto en la carga. - -ESTADO: pendiente. Cuando se retome: crear tabla Supabase + traer_base_junta() en backend -+ cruce por teléfono en el módulo que corresponda. - -## 7. Simplificar/normalizar nombres de programa (Personalizado) — MEJORA OPCIONAL -Los nombres largos de los cursos se acortan con una lista de reemplazos de texto -en `backend/leads_logic.py` → `_PERS_REEMPLAZOS` (hardcoded). - -Problemas/mejoras: -- Está en el código: cada nombre nuevo/largo hay que agregarlo a mano. -- Algunos reemplazos quedan SIN sede ni frecuencia consistente - (ej. "VOLUMEN VARIABLE VRF" quedó sin "SEDE -" ni "- FREC"). -- Ideal: formato uniforme tipo "SEDE - CORTO - FREC" para todos. - -Ideas (opcional, cuando haya tiempo): -1. Mover `_PERS_REEMPLAZOS` a un JSON en GitHub o tabla Supabase → editable sin tocar código. -2. Normalizar TODOS los nombres con un mismo criterio (sede + nombre corto + frecuencia), - no solo los VRF/CO2 ya hechos. - -ESTADO: opcional. No urgente; los reemplazos actuales funcionan. - -## 8. Manual de tablas de Supabase — PENDIENTE -Mantener UN solo documento que liste cada tabla de Supabase y para qué sirve -(evitar olvidarse). Ej.: -- `datos_unificados` → leads (proyecto ogzjtkxnfs...). -- `basebi_programacion` → pauta/estado/contar por num_indice (proyecto uztqscimts...). -- `cartera_junta` → cartera total combinada por teléfono + es_origen (proyecto uztqscimts...). -- (futuras: `programa_alias` → diccionario de normalización). -Cada vez que se cree una tabla nueva, agregarla aquí. - -## 9. Normalización de programa/sede en cartera_junta + alerta de valores nuevos — PENDIENTE -Problema: en `cartera_junta` hay valores repetidos con distinta escritura -(CÁMARAS/CAMARAS, GESTION/GESTIÓN, VRF / VRV vs VRF, SUP. DE OBRAS/SUPER.OBRAS/ -SUPERVISIÓN DE OBRAS, DIPLONADO REF typo, LINA→LIMA) y basura (vacío, "0"). -Como la tabla se regenera a diario (GitHub Actions), limpiar a mano NO sirve -(se sobrescribe). Hay que normalizar en la GENERACIÓN. - -Plan acordado (mínimo de tablas): -- En `carga_cartera.py`: (a) reglas automáticas → MAYÚSCULAS + sin acentos + sin - espacios extra (une CÁMARAS=CAMARAS, GESTIÓN=GESTION, etc. sin mantener nada); - (b) UNA tabla-diccionario `programa_alias` (y sede) en Supabase con - alias → valor_correcto para los sinónimos/typos que las reglas no resuelven. -- Detección de NUEVOS: NO usar tabla de pendientes. Calcular al vuelo en el - dashboard, comparando los valores únicos de cartera_junta vs el diccionario. -- Alerta: 🔔 campanita/panel de notificaciones en el dashboard. Silencioso si todo - es conocido; si aparece sede/programa nuevo no reconocido, se enciende con la - lista para que el usuario decida (unir como alias o dejar como nuevo real). -- Decidir aparte: valores vacíos y "0" → dejar o convertir a SIN PROGRAMA/SIN SEDE. - -## 10. Clasificar valores no identificados DESDE la campanita — MEJORA OPCIONAL -Hoy la campanita 🔔 solo AVISA de los programas/sedes no identificados; para -corregirlos hay que ir a Supabase y agregar la fila en `alias_normalizacion`. -Mejora: permitir hacerlo desde la misma web, en la notificación: -- Al lado de cada valor no identificado, un desplegable con los programas/sedes - YA EXISTENTES (canónicos) + botón "Asignar". -- Al asignar, el backend inserta la fila (alias → correcto) en `alias_normalizacion` - directamente desde la web (nuevo endpoint POST), sin entrar a Supabase. -- Así se limpia al instante y en la siguiente corrida del workflow ya sale unido. -ESTADO: opcional. Hoy funciona avisando; esto solo agiliza la corrección. - ---- - -(Agregar aquí cualquier otro pendiente que vaya saliendo.)