employees

Planilla del centro

La planilla, filtrada y paginada EN SERVIDOR. Traerla entera al navegador para filtrarla allí funciona con los 5 empleados de una demo y deja de funcionar con los 600 de un hospital — justo cuando importa. Por eso el término, el estado, el orden y la página se resuelven aquí.

Dar de alta un empleado

Plazo de conservación del expediente

Cuánto tiempo conserva este centro el expediente de un egresado, y cuántos lo han cumplido. El sistema **no borra nada** y no hay ningún trabajo de fondo que lo haga: informa. Qué se hace con un expediente vencido es una decisión con firma, y un purgador automático de evidencia laboral es irreversible por definición — si el número estuviera mal puesto un solo día, lo que destruiría es justo lo que la ley manda conservar.

Fijar el plazo de conservación

Fija el plazo. Es política del CENTRO: la plataforma no conoce sus contratos ni sus litigios.

Confirmar la importación y escribirla

Escribe la planilla y devuelve el informe del lote. IDEMPOTENTE POR CÉDULA DENTRO DEL CENTRO: quien ya está se actualiza y no se duplica. La correspondencia la decide `validar_planilla`, la MISMA función que pintó la vista previa, así que lo que se escribe es exactamente lo que el operador vio — recalculado contra la foto de ahora, que es lo único honesto cuando entre mirar y confirmar cabe un alta de otro operador. TOLERANTE POR FILA: cada escritura va en su savepoint. Una fila que choque contra un índice único sale rechazada en el informe y las demás siguen su camino.

Plantilla del archivo de planilla

La plantilla y la descripción de cada columna. Se devuelve como JSON con el CSV dentro, y no como una descarga directa, porque el portal necesita las DOS cosas de una vez: el archivo para el botón de descarga y la descripción de cada columna para la ayuda de la pantalla. Repetir esa lista en el portal la dejaría desincronizada del lector el día que se añada una columna.

Plantilla del archivo, como descarga directa

El mismo CSV, servido como fichero. Para quien llama al API sin pasar por el portal.

Validar la planilla sin escribir

Valida el archivo contra este centro y devuelve el plan. **No escribe nada.** No hay `db.add`, ni `db.commit`, ni asiento de bitácora: no ha pasado nada que auditar. El asiento lo dejará la confirmación, que es el acto que cambia la planilla.

Mis propios datos laborales

Lo que el centro guarda de QUIEN PREGUNTA, y de nadie más. NO EXIGE `ATTENDANCE`, y esa es la decisión entera de esta ruta. La planilla es de la administración porque son datos personales de terceros; los datos de uno mismo son un DERECHO de la Ley 172-13 —poder ver lo que se guarda de uno para pedir su corrección— y condicionarlo a un permiso de módulo dejaría sin ese derecho justo a quien no administra nada, que es casi todo el personal. La cuenta sólo puede llegar a su propia ficha: se resuelve por `user_id`, no por un id que venga de fuera. Declarada ANTES que `/{employee_id}`: FastAPI resuelve por orden y al revés «mi-ficha» se tomaría por el id de un empleado.

Departamentos y unidades asignables

Lo que se puede elegir en «departamento» y «unidad» de la ficha. Va en el API y no se arma en el portal para que el desplegable y la validación miren la MISMA lista: si la pantalla ofreciera algo que la puerta rechaza, el operador vería un error sin saber qué hizo mal. Declarada ANTES que `/{employee_id}`: FastAPI resuelve por orden, y al revés «opciones» se tomaría por el id de un empleado.

Cuentas y fichas de médico sin empleado

Las cuentas del portal y las fichas de médico del centro que NO son de ningún empleado. Sirve para las dos direcciones del CR-530: * vincular a un empleado ya dado de alta con su cuenta o con su ficha de médico; * ver quién entra al portal pero **falta en la planilla**, y darlo de alta con sus datos ya conocidos en vez de teclearlos otra vez. NO se crea nada automáticamente. Que una cuenta exista no la convierte en empleado: quién está en planilla es una decisión de RRHH —hay cuentas de integración, de auditoría externa y de administradores de la red que no son de nadie que trabaje en el centro—, y adivinarlo metería en la nómina a quien no debe. Declarada ANTES que `/{employee_id}`, o «vinculables» se tomaría por el id de un empleado.

Ficha laboral de un empleado

Editar la ficha de un empleado

Edita la ficha, SÓLO los campos que vengan en el cuerpo. `model_fields_set` es lo que distingue «no vino» de «vino vacío». La ficha se edita por secciones y sin esa distinción cada guardado borraría lo que la sección no pinta — el fallo clásico de un PUT disfrazado de PATCH, y aquí borraría la fecha de ingreso, de la que salen las vacaciones del Código de Trabajo.

Dar de baja a un empleado

Da de baja SIN borrar: fija fecha y motivo, y saca a la persona de las listas de asignación. NO SE BORRA LA FILA, y no es un detalle de implementación: su historial de turnos y marcajes es la evidencia de jornada que obliga a conservar el Código de Trabajo 16-92 —el caso de uso que abrió el PRD #943—. Borrarla destruiría la prueba de lo que se le debe o se le pagó. LA BAJA NO ARRASTRA NADA. Las guardias que ya estaban planificadas y la gente que lo tenía como supervisor **se quedan como están**, y salen en `avisos`. Cancelar guardias o reasignar a un equipo entero son decisiones de operación con consecuencias propias, y esconderlas dentro del botón de «dar de baja» haría que se tomaran sin querer.

Reactivar a un empleado

Devuelve a la planilla a quien vuelve, SOBRE SU MISMO REGISTRO. Es lo que evita el segundo registro de la misma persona, que es como una planilla acaba con duplicados: si volver obligara a darla de alta otra vez, su antigüedad, su historial de marcaje y su expediente quedarían partidos en dos personas que el sistema no sabe que son una. LAS REGLAS DE UNICIDAD SE VUELVEN A APLICAR. Mientras estuvo fuera, su cédula y su número quedaron LIBRES a propósito —los centros reciclan los números—, así que puede que otro los tenga ya. Se comprueba contra los ACTIVOS antes de devolverla, y si chocan se dice cuál para que se le ponga otro número en vez de romper la planilla.

Vincular cuenta y ficha de médico

Conecta —o desconecta— al empleado con su cuenta del portal y con su ficha de médico. VA APARTE DE LA EDICIÓN DE LA FICHA a propósito. Cambiar un teléfono y decidir quién entra al portal en nombre de esta persona no son la misma clase de acto: el segundo es una decisión de acceso, deja su propio asiento y se audita por separado. LA FICHA DE MÉDICO NO SE ABSORBE. Aquí sólo se guarda un vínculo: el `Doctor` conserva su exequátur, su especialidad, su publicación, sus citas y sus horarios, y sigue existiendo sin empleado — en el país muchos médicos trabajan por privilegios y no están en planilla. `null` explícito desvincula; no enviar el campo lo deja como estaba. Desvincular NO borra nada: ni la cuenta, ni la ficha, ni el empleado.