Kimai en colegios profesionales: horas, permisos y salida
Un colegio profesional puede ordenar horas internas con Kimai si separa equipos, permisos, exportaciones, responsables y prueba de respaldo mensual.
El cierre de horas falla cuando una reunión se carga como trámite, una llamada queda sin proyecto y una exportación borra el detalle que después pide tesorería. En un colegio profesional de Cuyo con 1.800 matriculados, Kimai ordenó tiempo, equipos, permisos y salida mensual. Este caso anonimizado muestra qué configurar primero y cómo probar que la hora tiene dueño.
Dónde aparece la hora sin dueño
La documentación de Kimai Timesheet describe la vista dónde se crean y editan registros de tiempo. También marca un punto sensible: los registros exportados quedan bloqueados para evitar manipulación de datos ya liquidados. Esa regla es medible: una hora exportada cambia de estado y queda fuera de la edición común sin permiso especial. El dato global viene de la Stack Overflow Developer Survey 2025, que recibió más de 49.000 respuestas de 177 países. La lectura para una entidad chica es directa: cada vez más procesos administrativos dependen de herramientas web, roles y datos exportables. El antagonista era la hora comodín, cargada tarde y corregida por conversación. En la administración, el sello seco del colegio seguía dentro de una caja azul. Cada acta tenía forma; las horas internas todavía no. Esa diferencia aparecía en cada cierre mensual, sobre todo cuando una revisión llegaba después de tesorería.
Cómo funciona por dentro
El flujo quedó en seis pasos. Primero, cada persona carga una hora con cliente interno, proyecto, actividad y descripción. Segundo, Kimai valida usuario, equipo y permisos. Tercero, la base guarda fecha, duración, usuario, proyecto, estado y marcas de exportación. Cuarto, una jefatura revisa horas del equipo antes del cierre. Quinto, tesorería exporta PDF, XLSX o CSV para informe mensual. Sexto, backup y restauración prueban que usuarios, proyectos, permisos y registros vuelven juntos. Kimai recibe registros de tiempo y entrega listados, reportes y exportaciones. La documentación de equipos explica que los equipos limitan acceso a clientes y proyectos. La documentación de usuarios muestra que un usuario puede estar en equipos y que las funciones se controlan por roles. La documentación de exportación enumera salidas en PDF, XLSX, CSV o HTML, con advertencias sobre plantillas compartidas y permisos sensibles. Los permisos se separan por tarea. Un usuario carga sus horas. Un responsable revisa el equipo. Tesorería exporta y marca cierre. Sistemas administra usuarios, respaldo y actualizaciones. La dirección consulta reportes cerrados. PostgreSQL o MariaDB guardan registros estructurados; el almacenamiento externo guarda copias de exportaciones y evidencia del cierre.
Qué se instala o configura primero
El primer entregable verificable es un cierre mensual con cinco usuarios, dos equipos, tres proyectos, una exportación XLSX, un PDF guardado y una restauración probada. La pila mínima usa Kimai 2.60.0, base de datos, servidor web, backup diario, almacenamiento de exportaciones y correo transaccional para alta o recuperación de cuentas. Un servidor de USD 10 a USD 40 mensuales equivale a ARS 14.540 a ARS 58.160 al dólar vendedor de $1.454, sin contar horas de parametrización. La configuración inicial empieza por un catálogo operativo. Clientes internos: matrícula, tesorería, eventos, sistemas y comisión directiva. Proyectos: atención, soporte, reunión, preparación documental y cierre mensual. Actividades: carga, revisión, llamada, informe y guardia. Cada etiqueta debe explicar una acción que alguien pueda reconocer en una rendición, con fecha, persona y motivo visibles. Conviene probar el catálogo con un mes viejo antes de habilitarlo al equipo completo. UMSA puede intervenir después de que el colegio defina quién aprueba horas y qué exportación entra al circuito contable. La primera semana debe dejar un tablero de horas abiertas, horas cerradas, usuarios sin equipo y exportaciones del mes. El trabajo evita que una corrección tarde cambie un informe ya enviado.
Dónde se rompe y cómo probarlo
El primer riesgo es cargar proyectos visibles para todos. La señal aparece cuando un usuario ve horas de una comisión ajena. La prueba asigna un proyecto a un equipo, entra con otro usuario y confirma que no puede verlo. El segundo riesgo es exportar una plantilla con tarifas visibles. La señal aparece cuando un usuario recibe columnas de costo que no debería consultar. La prueba genera una exportación con un usuario común y revisa columnas antes de compartirla. El tercer riesgo es permitir edición de horas exportadas. La señal aparece cuando una hora cerrada cambia duración o descripción. La prueba marca registros como exportados, intenta editarlos sin permiso especial y guarda el resultado. El cuarto riesgo es restaurar la base sin archivos de salida. La señal aparece cuando las horas vuelven, pero el PDF del cierre no existe. La prueba restaura base y carpeta de exportaciones en otro host, abre un mes cerrado y compara totales contra el archivo enviado a tesorería. La entidad gana control cuando puede explicar quién cargó la hora, quién la aprobó y qué archivo salió al cierre, sin reconstruir el mes a mano. La prueba mensual debe quedar repetida por escrito.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.