Kimai en estudios contables: horas, permisos y salida
Mini-caso de Kimai para estudios contables con clientes vitivinícolas: horas por proyecto, equipos, API, permisos y respaldo verificable.
Antes, las horas de un estudio contable se cerraban con planillas sueltas; después, cada cliente, proyecto y actividad tuvo dueño. Kimai 2.61.0, publicado el 20 de junio de 2026, permite registrar tiempos, permisos, equipos y API para reportes. Este caso de industria muestra cómo ordenar trabajo recurrente en clientes vitivinícolas, qué datos guardar y cómo probar una salida completa.
Dónde aparece la hora que nadie puede explicar
El problema operativo aparece cuando una tarea de liquidación, una consulta fiscal y una visita a bodega quedan mezcladas en la misma fila. En un estudio contable de San Rafael, la carpeta de cartulina verde para un cliente vitivinícola sigue en el estante, pero la discusión real pasa por otra pregunta: quién cargó dos horas, para qué proyecto y con qué autorización. Kimai convierte esa carga en un registro revisable. La hora sin cliente se cobra mal. La cifra que corrige la decisión viene del repositorio oficial: kimai/kimai registró 4.784 estrellas al chequeo de esta corrida. El dato no define la herramienta, pero ayuda a revisar mantenimiento, comunidad y frecuencia de releases. La documentación de permisos muestra roles configurables, y la de equipos explica cómo limitar visibilidad por cliente, proyecto y actividad. El dato global se conecta con una salida conocida. La Stack Overflow Survey 2025 ubicó a PostgreSQL con 55,6 % de uso entre quienes respondieron sobre bases de datos. En una instalación propia, la base puede guardar usuarios, clientes, proyectos, actividades, tiempos, tarifas y auditoría.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, administración crea clientes, proyectos y actividades. Segundo, cada profesional carga inicio, fin, tarea, cliente y descripción. Tercero, Kimai valida permisos según rol y equipo. Cuarto, PostgreSQL guarda tiempos, usuarios, tarifas y estados. Quinto, la API JSON permite exportar datos hacia tablero, facturación o archivo interno. Sexto, backup y restauración prueban que horas, clientes y permisos vuelven juntos. Kimai recibe cargas de tiempo y entrega reportes por usuario, cliente, proyecto y actividad. PostgreSQL guarda registros estructurados, usuarios, estados y auditoría. La API recibe consultas autenticadas y devuelve JSON para reportes o integraciones. Los equipos definen qué usuario ve cada cliente o proyecto. El backup copia base, configuración y archivos relevantes. El permiso de crear clientes queda en administración. El permiso de cargar horas queda en cada profesional. El permiso de aprobar, corregir o exportar queda en socios o responsables. El permiso de borrar entradas se restringe y se revisa con auditoría.
Qué se instala o configura primero
El primer entregable verificable es un circuito con cinco clientes, tres proyectos, actividades normalizadas, roles y una exportación CSV. Una pila chica puede correr con Kimai 2.61.0, PostgreSQL o MariaDB, HTTPS, backup diario, SMTP y una tarea programada de exportación. El costo mensual estimado va de USD 25 a USD 55, entre $ 37.750 y $ 83.050 al dólar oficial vendedor de $ 1.510; quedan fuera parametrización contable, capacitación y migración histórica. El piloto razonable dura dos semanas. UMSA puede aplicarlo en estudios, consultoras o áreas administrativas que necesitan medir horas sin depender de una planilla compartida. La primera entrega debe mostrar carga diaria, cierre semanal, exportación por cliente, bloqueo de permisos y restauración en un entorno limpio. La documentación de proyectos permite separar cliente, proyecto y actividad. Esa separación evita que todo termine bajo un rótulo genérico que nadie puede explicar al facturar. La configuración inicial también debe definir redondeo, jornada esperada y formato de exportación. Si esos campos quedan abiertos, cada cierre mensual vuelve a discutir la misma diferencia entre horas trabajadas, horas facturables y horas internas.
Dónde se rompe y cómo probarlo
El primer riesgo es el proyecto sin equipo. La alerta aparece cuando usuarios ajenos ven horas de un cliente. La prueba crea dos equipos, asigna clientes distintos y confirma que cada usuario ve solo su cartera. El segundo riesgo es la actividad genérica. La alerta llega cuando la mayoría de las horas cae en una etiqueta amplia. La prueba revisa una semana de carga y exige actividad, descripción y cliente en cada entrada. El tercer riesgo es la API con token compartido. La alerta aparece cuando un token sirve para descargar datos de todos los clientes. La prueba crea un usuario técnico, limita permisos y ejecuta una consulta contra la API REST. El cuarto riesgo es respaldo sin prueba de lectura. La alerta llega cuando la base restaura, pero los permisos quedan abiertos. La prueba restaura en otro host, abre reportes por cliente, revisa equipos y descarga un CSV. El caso funciona cuando la factura puede defenderse con una línea verificable: profesional, cliente, proyecto, actividad, fecha, duración y autorización.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.