Kimai 2.61 en estudios contables: horas, equipos y cierre
Mini-caso para ordenar horas facturables con Kimai: permisos, equipos, clientes, proyectos, reportes, cierre mensual y backup probado.
Antes, las horas viajaban en mensajes sueltos; después, cada parte tuvo cliente, proyecto, usuario y cierre. Kimai 2.61.0, publicado el 20 de junio, permite ordenar carga horaria, equipos, permisos y reportes en estudios contables o consultoras chicas. El caso muestra dónde vive el dato, quién puede corregirlo y qué prueba evita discutir el cierre mensual con planillas distintas.
Dónde aparece la hora suelta
La cifra que obliga a mirar el proceso viene del release: Kimai 2.61.0 declara compatibilidad con PHP 8.2 a 8.5 y agregó ajustes de contrato laboral desde API. El repositorio tenía 4.755 estrellas y actividad el 22 de junio de 2026. Esa actividad permite revisar una herramienta viva antes de sumar otra planilla. La hora sin proyecto es el punto de falla. La documentación de Kimai describe partes de tiempo, clientes, proyectos, actividades, equipos y permisos. Los equipos limitan acceso a clientes y proyectos; los roles controlan permisos de creación, edición, exportación y administración. Para un estudio con clientes vitivinícolas de San Rafael, esa separación cambia el cierre: una hora queda asociada a trabajo, responsable, tarifa y estado.
Cómo funciona por dentro
El flujo empieza cuando cada usuario registra un parte. Kimai recibe cliente, proyecto, actividad, descripción, inicio, fin, duración y etiquetas. La aplicación guarda esos datos en su base y entrega listados, reportes, exportaciones y facturación. Si el parte queda abierto, el sistema muestra una entrada activa que debe cerrarse. El segundo paso ordena clientes y proyectos. Administración crea clientes, proyectos y actividades facturables o internas. Los equipos vinculan usuarios con esos objetos, de modo que cada persona ve sólo lo asignado. Los permisos deciden quién carga, quién edita partes propios, quién edita partes ajenos, quién exporta y quién administra. El tercer paso revisa el mes. El responsable filtra por cliente, proyecto, usuario y estado. El cuarto paso exporta: CSV, PDF o reporte para facturación. El quinto paso bloquea correcciones fuera de plazo mediante permisos y rutina interna. El sexto paso respalda: base, configuración, archivos de exportación y parámetros de permisos. La prueba de salida restaura un mes cerrado en otro servidor. Debe mostrar cliente, proyecto, actividad, usuario, duración, tarifa, cambio realizado y exportación. Si aparece el total sin historial, la discusión vuelve al chat. El archivo de exportación se guarda con fecha, período y responsable. Ese nombre permite comparar lo enviado a facturación con lo que todavía queda editable.
Qué se instala o configura primero
La instalación inicial usa Kimai 2.61.0, PHP 8.2 o superior, base relacional, proxy HTTPS, usuarios, roles, equipos, backup diario y reporte mensual. Con dólar oficial vendedor de $ 1.481,79, un VPS de USD 12 a USD 30 por mes equivale a $ 17.781 a $ 44.454 mensuales. Una puesta en marcha de USD 500 a USD 950 queda entre $ 740.895 y $ 1,41 millones. Incluye tres clientes, diez proyectos, actividades comunes, roles, equipos, exportación mensual y restauración. No incluye liquidación de sueldos ni asesoramiento laboral. UMSA puede arrancar con un mes piloto: dos clientes reales, tres usuarios y una regla de cierre. El primer entregable verificable es exportar horas por cliente y abrir el mismo reporte restaurado. La primera semana se usa para limpiar nombres. Cliente, proyecto y actividad deben tener dueño, abreviatura y criterio de uso. Si dos personas usan rótulos distintos para la misma tarea, el reporte mensual mezcla trabajo interno con trabajo cobrable. La limpieza se prueba con un listado de actividades y un responsable que aprueba altas nuevas. El detalle concreto aparece en el cuaderno anillado de un estudio: una columna dice “revisión”, otra “llamado”, otra sólo tiene iniciales. Kimai obliga a convertir esas marcas en actividades, usuarios y proyectos. La capacitación termina con una corrección controlada. Un usuario carga mal una hora, el responsable la corrige, el sistema guarda el evento y el reporte mensual cambia con explicación. Si la corrección no deja rastro, el cierre todavía depende de confianza oral.
Dónde se rompe y cómo probarlo
El primer riesgo es cargar actividades ambiguas. La señal aparece cuando “administración” mezcla llamados, balances y soporte. La prueba toma 20 partes y exige cliente, proyecto y actividad clara antes de facturar. El segundo riesgo es permiso amplio. La señal aparece cuando un usuario puede editar horas de otro equipo. La prueba crea dos equipos, intenta editar un parte ajeno y guarda el rechazo. El tercer riesgo es cierre mensual sin bloqueo. La señal aparece cuando el total cambia después de enviar la factura. La prueba cierra un período, intenta modificar una hora y registra quién puede autorizar la excepción. El cuarto riesgo es respaldo parcial. La prueba restaura base y configuración, abre un cliente, un proyecto, un usuario, un reporte y una exportación. El control horario sirve cuando cada hora tiene dueño, trabajo y recuperación.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.