dashboard-leads/FUTUROS_CAMBIOS.md

# 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.)