# Estado del Dashboard Talento Humano — pendientes y bitácora > Copia versionada de la memoria de trabajo del proyecto (`~/.claude/.../memory/PENDIENTES.md`). > Tareas pendientes y registro de cambios, ordenado de más reciente a más antiguo. > Última sincronización: 2026-09-16. --- ## 📌 Sesión 2026-09-15/16 — FC Zona G (FCZN) cargado completo + columna Salario + fix Payroll ### FC Zona G — alta de la propiedad y carga histórica completa ✅ - **Alta del hotel (2026-09-15):** NIT `999999001` (placeholder — no es un NIT DIAN real, confirmar si NominaApp llega a activarlo algún día), referencia interna "LIV65". Sin API de nómina/P&G — todo histórico se carga manual. Dado de alta en `empresas` (nit, notas) y `hotel_unificacion` (`nombre_personalizado='FC Zona G'`, sin `hotel_name_api`) vía `Unificacion_Hoteles.xlsx` + `/proxy/admin/sync-hoteles`. Sacado de las 5 listas `EXCL`/`EXCL_H` en `servidor.py` (antes excluido junto a ELMA/FNS). - **Empleados — 224 filas, 51 personas, ene-ago 2026.** Fuente: 8 Excel mensuales de Zeus (`Base de Datos - Maestro de Contrato Zeus/Zona G Liv`), en **2 formatos distintos** (limpio ene-abr; reporte nativo Zeus may-ago con desfase de 1 columna en Sueldo, detectado y corregido). Fecha de nacimiento/sexo cruzados desde `Listado Empleados x Razon Social/FCZN.xlsx` (100% match, 51/51). Verificado en navegador: filtro "FC Zona G" agosto → 29 empleados, tabla completa OK. - **Ingresos y Retiros — 43 movimientos** (35 de los 8 archivos de `Base de Datos - Liquidación de Contrato/ZONA G` + 8 encontrados/corregidos cruzando contra el archivo de nómina). Reconciliación mes a mes no cuadra 100% exacto (ej. mayo con diferencia real) — se determinó que el snapshot mensual de empleados no representa estrictamente "día 1" (Zeus parece capturar "activo en algún punto del mes"), es una ambigüedad de la fuente, no un hueco de información. Decisión: cargar datos reales confirmados, no forzar más ajustes sin evidencia. - **Ene-abr tiene un hueco real:** la fuente ("Liquidación de Contrato") solo trackea salidas, no entradas — 7 ingresos de marzo/abril no tenían registro en IR hasta que se cruzaron contra el archivo de nómina (que sí trae Fecha Ingreso/Retiro confirmadas). - **Nómina detallada — 234 filas empleado-mes** (52 personas × ene-ago) desde `Base de Datos - Payroll Zeus-Buk/.../Nomina FC ZONA G 2026.xlsx` (20 hojas, una por mes, **con distinto layout de columnas entre meses** — mapeo por nombre de columna, no índice fijo). Mapeo verificado matemáticamente: `Seguridad Social` (agregado) = Salud+Pensión+Riesgo+Caja Compensación P&G; `Total Provisiones` = Cesantías+Prima+Vacaciones+Intereses P&G. Se insertaron los 4 tipos de fila (`respuesta`/`resumen`/`concepto`/`empleado`) igual que las demás propiedades — 503 filas totales. **Verificado en navegador:** panel "Nómina histórica" de la hoja de vida funciona perfecto (cuadra exacto: $2.060.033 devengado − $171.464 deducido = $1.888.569 neto). - **Fix de código — Payroll no mostraba FCZN ("sin NIT configurado"):** `/proxy/nomina/hoteles-nit` exigía `hotel_name_api IS NOT NULL`, un requisito de cuando Payroll solo podía usar la API en vivo — campo que el frontend **no usa en ningún lado** (grep confirmado). Se quitó del WHERE. Verificado: `/proxy/nomina/reporte` para FCZN agosto ya responde desde caché (gasto total personal $121.428.016). Commits: dev `9076e98` → main `3f6d9d7`, ambos servidores reiniciados. - **Hallazgo pasivo (no bug):** al cargar Payroll con todos los hoteles, el sistema de "conceptos sin clasificar" (ya existente) detectó correctamente los códigos nuevos de FCZN (`SS_SS_PENSION`, `PROV_CES`, `DV81`, etc.) — funcionando como debe. Si se quiere que se agrupen igual que las demás propiedades: `/regenerar-conceptos` → revisar Excel → `/sync-conceptos`. - Todo cargado directo a la BD compartida — no requiere nada en el Mac mini salvo el próximo `git pull` para llevar el código (`servidor.py`, exclusiones + fix Payroll). ### Nueva columna "Salario" en la tabla del tab Empleados (2026-09-15) — ⚠️ SOLO EN DEV (8081), sin mergear a main - Columna añadida a la tabla desktop/tablet (ordenable, `fmtCOP()`) y a las tarjetas móviles (≤640px). Anchos de columna reajustados en los 2 breakpoints con `table-layout:fixed` + agregada a los 2 bloques `width:auto`. Verificado en navegador: desktop, ordenamiento asc/desc, tablet (~1000px), móvil (390px) — sin errores de consola. - Commit dev `716d932`, pusheado. **El usuario pidió explícitamente NO pasarlo a main** ("solo en el worktree dev hasta que pidas mergear") — sigue así, pendiente de que el usuario confirme el merge. --- ## 📌 Sesión 2026-09-14 — DORA recuperado y recargado, queda solo PSOL ## Renombrado "Casa del Agua" → "Palacio del Agua" (2026-09-14) ✅ - **A pedido del usuario.** El hotel `CDAG` (`hotel_name_api = Hotel_PalacioDeAgua`) mostraba `nombre_personalizado = "Casa del Agua"` en el dashboard — el nombre de la API ya decía "PalacioDeAgua", el catálogo tenía el nombre viejo/equivocado. - **Fix (fuente → BD, flujo normal del proyecto):** 1. `Unificacion_Hoteles.xlsx` — celda H7 (fila CDAG, columna "✏️ NOMBRE PERSONALIZADO") cambiada a `Palacio del Agua`. 2. Sincronizado a `hotel_unificacion` vía `POST /proxy/admin/sync-hoteles` (con `ADMIN_API_KEY`) en **ambos** servidores (8080 y 8081) → `{"ok": true, "actualizadas": 28}` en los dos. - **Verificado:** `hotel_unificacion` y el endpoint `/proxy/historico/hoteles-map` ya devuelven `CDAG → "Palacio del Agua"`. No requiere reiniciar servidor — el frontend recarga el mapa al abrir/refrescar la página. - Sin cambios de código, solo dato (Excel fuente + tabla de unificación). Se propaga solo a cualquier otra instancia que sincronice desde el mismo Excel (ya está en el repo). - **DORA (900385136): ✅ RECUPERADO Y RECARGADO.** Aloft ya cerró agosto — probado en vivo: jul=75 y ago=75 empleados OK (sep sigue "no hay periodos cerrados", esperado). Recargado con `python3 cargar_historico_nomina_pyg.py --fuente nomina --desde 2026-08 --hasta 2026-08` → `OK nomina 2026-08 nit=900385136 filas=122` (75 empleado + resumen + conceptos). Resumen real en BD: gasto_total_personal $320.271.034 (consistente con meses previos). De paso, los otros 16 NITs también se recargaron con datos frescos en la misma corrida (algunos con más filas que la carga del 8-sep, ej. GHS 166→180, SERV 244→291 — probablemente ajustes tardíos del proveedor). - **PSOL (800157788): sin cambios, sigue igual.** Probado jul/ago/sep 2026 y también `empleados-activos-detalle`: mismo `Cannot open database "NominaEmp" ... login failed (4060)` en los tres meses. Último en BD: **2026-06** (desde julio no carga nada). Sigue siendo 100% responsabilidad del proveedor — sin solución posible desde acá. - **Estado agosto 2026 nómina: 17/18 NITs con detalle de empleados.** Solo falta PSOL. P&G no revisado en esta pasada (última vez 21/21). - Recarga hecha solo en la BD compartida (Mac local) — no requiere nada en el Mac mini. --- ## 📌 Sesión 2026-09-08 — nóminas faltantes revisadas: CCAR recargado, quedan PSOL + DORA - **El apagón general del proveedor (8 NITs caídos el 4-sep) se aclaró.** Prueba en vivo de los 18 NITs para agosto 2026: **16 OK**, solo 2 fallan. - **CCAR (901936953): ✅ RECUPERADO Y RECARGADO.** La API ya devuelve 86 empleados (antes: `num_empleados=0` / `Login timeout`). Corrida `python3 cargar_historico_nomina_pyg.py --fuente nomina --desde 2026-08 --hasta 2026-08` desde la Mac local → `OK nomina 2026-08 nit=901936953 filas=112` (86 empleado + resumen + conceptos). Resumen real en BD: gasto_total_personal $315.171.461 (julio fue $306M — consistente). `cargado_en` 2026-09-08 09:23. - **DORA (900385136): sigue faltando, pero volvió a "normal".** Error hoy: `No hay periodos cerrados para 2026-08` (ya NO `Login timeout` como el 4-sep). Es el caso benigno — Aloft aún no cierra su nómina de agosto. Se resuelve solo cuando cierren; recargar con el mismo comando. Último en BD: **2026-07**. - **PSOL (800157788): sin cambios.** `Cannot open database "NominaEmp" ... login failed (4060)`. Base del proveedor caída desde julio. Último en BD: **2026-06**. Falta julio Y agosto. Solo se arregla si el proveedor levanta ese login. - **Estado agosto 2026 nómina: 16/18** (antes 15/18 efectivos — CCAR era un cascarón). P&G sigue 21/21. Faltan PSOL + DORA. - Recarga hecha solo en la BD (compartida) — no requiere nada en el Mac mini. --- ## 📌 Sesión 2026-09-04 — PSOL/DORA revisados de nuevo: el backend del proveedor empeoró - **PSOL (800157788): sin cambios.** Mismo error de siempre, confirmado con 3 reintentos: `Cannot open database "NominaEmp" requested by the login. The login failed. (4060)`. - **DORA (900385136) y CCAR (901936953): el error CAMBIÓ y es más grave.** Ya no es "no hay periodos cerrados" (normal/auto-resuelve) — ahora es `Login timeout expired (0)`, el mismo tipo de falla de infraestructura que PSOL. - **Hallazgo clave: no es solo DORA/CCAR.** Al probar los 18 NITs en vivo, **7 fallan con el mismo `Login timeout expired`**: `900024971, 900361237, 900385136 (DORA), 901475697, 901630694, 901724291, 901936953 (CCAR)`. Confirmado **consistente en 2 pasadas separadas** (mismo set los dos intentos, no rota al azar) → no es ruido de red de este lado, es un problema real y sostenido del backend de NominaApp/Zeus hoy. Un NIT adicional (`890404970`) pasó de OK a timeout de lectura en la 2ª pasada — posible sobrecarga puntual encima del problema de fondo. - **Implicación:** ya no se puede asumir "DORA/CCAR se resuelven solos el 5-7 sep" — si el backend del proveedor sigue así, el reintento del Mac mini también fallará para esos NITs. Hay que re-probar antes/durante el reintento del día 5. - **Acción:** esto amerita reportarse al proveedor junto con PSOL — 8 de 18 NITs caídos con errores de login/timeout SQL Server el mismo día es un problema de infraestructura, no de nóminas sin cerrar. - No se tocó código ni BD — solo se probó la API en vivo (`/nomina/reporte` por NIT). --- ## 📌 Sesión 2026-09-01 — resumen de lo cerrado hoy ### ✅ Cerrado 1. **Cierres mensuales consolidados en el Mac mini.** Se descubrió que corrían en paralelo en el Mac mini Y en la Mac local (el `launchctl unload` del 18-ago no era permanente — los `.plist` seguían en `~/Library/LaunchAgents/`). Decisión del usuario: **solo el Mac mini**. En la Mac local: `launchctl bootout` de los 6 agentes (`com.bia.cierre-mes-dia1/5/7`, `com.bia.nomina-pyg-dia1/5/7`) + `.plist` movidos a `~/Library/LaunchAgents/disabled-cierres-migrados-macmini/` (con README). Siguen activos en la local: `dashboard-talento` (8080), `dashboard-talento-dev` (8081), `backup-postgres`. → detalle en *"Cierres migrados a Mac mini dedicado"*. 2. **Cierre de agosto 2026 certificado** (corrió el 1-sep). El **Mac mini lo hizo a las 05:00** (inserción fresca): `historico_empleados` 1003 filas / 19 razones, `historico_ir` 105 movimientos, nómina 16/18 NITs, P&G 21/21. Faranda_Bogota (NIT 900345450) entró **sin workaround manual**. Verificado en el Mac mini: 6 agentes cargados, repo al día (`42af4b1`), venv `~/rrhh-report/.venv/bin/python` con psycopg2, logs en `~/rrhh-report/logs/cloud/`, `sleep 0`. 3. **PSOL ≠ DORA — distinción hecha y desplegada.** Probado en vivo contra la API leyendo el cuerpo del 400: - **PSOL (800157788):** `Cannot open database "NominaEmp" ... login failed (4060)` — base del proveedor caída, falla en TODOS los períodos (jun/jul/ago). Último en BD: **2026-06**. → hay que reportarlo. - **DORA/Aloft (900385136):** `No hay periodos cerrados para 2026-08` — nómina de agosto sin cerrar aún, jun/jul OK. Último en BD: **2026-07**. → se resuelve solo. - **Fix:** `post_json()` en `cargar_historico_nomina_pyg.py` ahora expone el `detail` del `HTTPError`. dev `8664d2e` → main `ff51b0e`; CHANGELOG **v1.25.1** (`bb277bd` → `42af4b1`). Mac mini actualizado (`git pull`) y verificado. ### ⏳ Seguimiento pendiente - **5–7 sep:** verificar que `nomina-pyg-dia5`/`dia7` del Mac mini corran (hoy `runs=0`, aún no les toca) y que recuperen **DORA agosto** (900385136) cuando Aloft cierre. - **PSOL:** reportar al proveedor / admin de NominaApp el error de login SQL Server a la base `NominaEmp` (`4060`) para el NIT 800157788. Sin eso, julio y agosto de PSOL no se pueden cargar. - **Migración Mac mini:** confirmar que sus 6 agentes de cierre disparan con sesión de usuario activa (los `gui/` la necesitan) y que nadie vuelve a activar los locales. --- ## 📌 Sesión 2026-09-03 — cuadre agosto + fallback IR Faranda_Bogota ### ✅ Cerrado 1. **Cuadre del cierre de agosto** (ver Revisión 3 en la sección de nómina): `historico_empleados` cuadra internamente (996+58−51=1003). Descuadres = datos que el proveedor no entregó. **Hallazgo nuevo:** CCAR/FC Cartagena (NIT 901936953) también sin nómina de agosto — la API devolvió `200 OK` con `num_empleados=0`, se registró como `OK filas=7` (tercer hueco además de PSOL y DORA). 2. **Fallback IR por snapshot para Belvedere (FEB) + FC Bogotá (CLUB).** - **Causa raíz confirmada en vivo:** `/rrhh/ingresos-retiros` devuelve 16 buckets y **ninguno es `Faranda_Bogota`** (NIT 900345450 = CLUB + FEB). Probado con los 6 `tipo_nomina_id`. CLUB/FEB tuvieron IR normal hasta **2026-05**; desde jun-2026, cero. El usuario mostró el reporte de **Zeus** (fuente SQL Server) con los 12 movimientos de agosto → **el dato existe en Zeus, el hueco es de NominaApp** (que sí expone ese NIT en `empleados-activos-detalle` y `nomina/reporte`). Perdidos jun–ago: **32 movimientos** (18 I + 14 R). - **Fix:** `cierre_mes.py` → `completar_ir_desde_snapshot()` + `IR_FALLBACK_SNAPSHOT_RAZONES = {"CLUB","FEB"}`. Para razones sin ninguna fila IR del período, reconstruye I/R comparando `historico_empleados` mes vs mes−1. Filas con `origen='snapshot'` (columna nueva en `historico_ir`). Guardia: si la API vuelve a traer la razón, los datos reales mandan. Se llama tras `insertar_ir` en cada cierre. - **`backfill_ir_snapshot.py`** (nuevo): misma lógica para meses ya cerrados. **Ejecutado contra la BD para jun–ago 2026: 32 filas** (coinciden exacto con Zeus, incl. Baeza Puentes Sebastián en Belvedere). Verificado: CLUB y FEB cuadran (Inicio+I−R=Fin) en jun/jul/ago. Razones de control (GHS, DORA, CCAR, SERV) sin cambio. - `servidor.py` NO tocado — `/proxy/historico/ir` e `ir-mensual` leen `historico_ir` en vivo, así que ya muestran las filas sintéticas sin reiniciar nada. - Commits: dev `ba8e57b`+`5b78cec` → main `a495cf0`+`ae666d7`. CHANGELOG **v1.25.2**. - **Limitación:** un traslado CLUB↔FEB (mismo grupo) se ve como retiro+ingreso, no como transferencia. Y no detecta a quien entró y salió dentro del mismo mes (no aparece en ningún snapshot). ### FC Cartagena + Servihoteles agosto 2026 — descuadre de 1, resuelto con filas manuales (2026-09-03) - **Síntoma:** FC Cartagena agosto: 81 + 8 − 4 = 85 ≠ Activos Fin 86 (**+1**). Servihoteles agosto: 227 + 24 − 17 = 234 ≠ Activos Fin 233 (**−1**). Espejo exacto — la misma persona. - **Causa:** **CANTILLO URUETA MANUEL DE JESUS** (cédula `1143363867`). Empleado desde 2024-01-19, sin cambio de contrato. Julio: `SERV` / centro `130402-HCARIBE FINANCIERA`. Agosto: `SERV` / centro `1201-FARANDA COLLECTION CARTAGENA`. Es un **traslado de centro de costo dentro de Servihoteles**, no alta ni baja → no hay movimiento en Zeus/NominaApp. `activos-count` lo reclasifica server-side (`SERV_HOTEL_PATTERNS`): sale del conteo de Servihoteles y entra al de FC Cartagena. Ninguna de las dos vistas de IR lo refleja. CCAR pura sí cuadra (78 + 8 − 4 = 82). - **Fix (decisión del usuario: "solo haz que cuadre, agrégalo como ingreso", sin fallback ni lógica nueva):** dos filas a mano en `historico_ir`, ambas `origen='ajuste'`, `codigo_empleado='1143363867'`, `periodo='2026-08'`: - `id=7047` — `razon_social='CCAR'`, `tipo_movimiento='I'`, `ingreso='2026-08-01'` → FC Cartagena cuadra: 81 + 9 − 4 = 86. - `id=7048` — `razon_social='SERV'`, `tipo_movimiento='R'`, `termino='2026-08-31'` → Servihoteles cuadra: 227 + 24 − 18 = 233. - (`tipo_contrato` en NULL en ambas — el snapshot de ese registro SERV traía la cédula en ese campo.) - **⚠️ No sobreviven un re-cierre de agosto:** `cierre_mes.py` hace `DELETE FROM historico_ir WHERE periodo='2026-08'` y recarga del API. Si se re-cierra agosto, volver a insertar ambas (buscar `origen='ajuste'` periodo 2026-08). Agosto ya está cerrado → improbable. - Solo dato en BD, sin cambio de código. No aplica a dev/main/Mac mini. ### ⏳ Seguimiento - **`git pull` en el Mac mini** (`~/rrhh-report`) para llevar `cierre_mes.py` + `backfill_ir_snapshot.py` + CHANGELOG. El backfill de jun–ago YA está en la BD (compartida), no hay que re-correrlo; el cambio en `cierre_mes.py` hace que los cierres futuros lo apliquen solos. - **CCAR agosto (nómina): ✅ RESUELTO 2026-09-08** — la API se recuperó, recargado a mano (86 empleados, gasto $315M). Ver *"Sesión 2026-09-08"* arriba. - **Reportar a NominaApp:** el NIT 900345450 ("Club House Bogota S.A.S.", BUs Belvedere + Club House) falta en `/rrhh/ingresos-retiros` desde jun-2026, aunque está en `empleados-activos-detalle`, `nomina/reporte` y Zeus. Adjuntar el reporte de Zeus. - **Mejora futura:** que `cargar_historico_nomina_pyg.py` loguee `WARN … num_empleados=0` en vez de `OK` cuando la respuesta viene vacía (caso CCAR). --- ## Documentadas las 3 formas de calcular antigüedad (2026-08-26) ✅ - **Último punto pendiente de la auditoría general.** Se agregaron comentarios cruzados en el código (sin cambiar ningún comportamiento) explicando que "Antigüedad" tiene 3 definiciones de negocio distintas, no intercambiables: 1. **Tabla/panel** — `calcMeses()`+`fechaIngresoReal()` (`dashboard-empleados.html`, comentario maestro justo antes de `calcMeses()`) — usa `INGRESO_REAL_MAP` (`servidor.py` endpoint `ingreso-real-map`, gaps-and-islands): solo suma dentro de la MISMA `razon_social`, corta con huecos >62 días. 2. **Gráfica "Distribución por Antigüedad"** — endpoint `/proxy/historico/antiguedad` (`servidor.py:1594`) — `MIN(fecha) GROUP BY codigo_empleado` sin partición por empresa ni por huecos: un empleado que salió y volvió años después puede salir con antigüedad "continua" desde su primer ingreso histórico. Documentado como definición distinta, no bug sin arreglar. 3. **Panel "Historial por empresa"** — `empDetailLoadHistory()` (`dashboard-empleados.html:10651`) — suma la duración de cada bloque cargo+empresa, SÍ incluye cambios de razón social (a diferencia de #1). Campo "Antigüedad total en el grupo". - Los 3 comentarios se referencian entre sí para que una futura sesión no "corrija" una pensando que es un bug, sin saber que rompe la consistencia con las otras 2. - **Verificado:** sintaxis de `servidor.py` OK, bloque `