Gastos de Baja Cuantía — App local para Bitrix24

App de una sola página (index.source.html), instalada como "Aplicación local" en amsac.bitrix24.es, igual que amsac-transporte-bitrix24. La identidad, permisos y listado de empleados/departamentos vienen del contexto de sesión de Bitrix24 (BX24.js); los datos de los gastos se guardan en el mismo proyecto Supabase que ya usa la app de transporte, en tablas nuevas y separadas (gastos_*).

Diseño responsive

Toda la app tiene dos modos, según el ancho de pantalla (punto de corte: 900px, el mismo donde el menú lateral pasa de fijo a hamburguesa):

• Escritorio (≥900px): el contenido aprovecha hasta 1180px de ancho (antes 900px fijo, se veía como una columna angosta flotando en medio de la pantalla). Los formularios largos (Crear Solicitud, Certificación presupuestaria, edición rápida de un gasto) agrupan sus campos en pares de dos columnas (Fondo/Área solicitante, Descripción/ Justificación, etc.) para no obligar a hacer scroll vertical innecesario.
• Tablet / celular (<900px): menú lateral colapsado a hamburguesa con overlay, todos los campos de formulario apilados en una sola columna (más fáciles de tocar), y las tablas con muchas columnas (ítems de una solicitud, Historial, Reportes, etc.) se desplazan horizontalmente dentro de su propio contenedor en vez de romper el diseño de la página. Por debajo de 480px se reduce además el padding general y crecen los checkboxes de las listas de usuarios para facilitar el toque.

Este comportamiento es puramente CSS (clase .row y el ancho de .wrap según media query) — no depende de detectar el dispositivo, así que también se adapta si alguien cambia el tamaño de la ventana en escritorio.

Modelo de permisos

Un administrador del portal ve y puede hacer todo. Para el resto de usuarios, el acceso a cada pantalla depende de a cuál de estos grupos pertenezcan:

• Solicitante — estar asignado a un fondo (lo mismo que hoy habilita "usar" ese fondo, se asigna desde Configurar usuarios) da acceso a Crear Solicitud, Registrar factura o documento equivalente, Historial e Solicitud de reintegro o liquidación. Es la misma persona quien crea la solicitud, registra su factura, revisa su historial y genera su informe.
• Certificador (personal de Presupuesto) — acceso a Certificación presupuestaria. Solo lo tienen los miembros del "Departamento de Presupuesto" de Bitrix24, incluido su jefe (activos). Ya no se asigna en Configurar usuarios: se deriva de la estructura de Bitrix24 y ahí solo se muestra la lista informativa. Además, el administrador del portal de Bitrix24 también puede certificar (ver "Administrador del portal"). El servidor lo verifica contra Bitrix24 (webhook) al certificar, al revisar/autorizar un reintegro y al corregir gastos informados (403 si no pertenece; 502 si no puede consultar Bitrix24, sin asumir permiso). No depende de ningún fondo.
• Administrador de fondo — acceso a Desembolso de fondos e Solicitud de reintegro o liquidación, pero solo para el/los fondo(s) que administra: es un subconjunto de los usuarios asignados a un fondo (no todos los que pueden usarlo para crear solicitudes son también administradores de ese fondo). Se elige al crear el fondo (y se puede cambiar después al editarlo); si alguien deja de ser administrador sigue siendo usuario normal del fondo (no pierde el acceso a crear solicitudes contra él, solo el de desembolsar/informar). El servidor valida esto también al momento de desembolsar y de gestionar un reembolso o liquidación, no solo la pantalla. Solicitud de reintegro o liquidación ya no es de autoservicio para cualquier solicitante — desde que existe la gestión de reintegro/liquidación, solo administradores de fondo (y del portal) entran ahí, y cada uno solo ve la información de sus propios fondos (un administrador del portal puede elegir cuál administrador de fondo mirar, desde un selector).
• Certificador también obtiene, además de "Certificar gastos", acceso a la pantalla hermana "Revisión de reintegros y liquidaciones" (mismo grupo de permiso, ver más abajo en "Qué hace").
• Tesorería (personal del Departamento de Tesorería) — acceso al menú "Tesorería" (Reintegro de fondos / Liquidación de Fondos). Solo lo tienen los miembros del "Departamento de Tesorería" de Bitrix24, incluido su jefe, que son quienes liberan los fondos: suben el acuerdo municipal y el comprobante de transferencia (fondo circulante) o el voucher/cheque (caja chica). Está , que son quienes el reintegro o la liquidación desde Solicitud de reintegro o liquidación y no usan este menú (salvo que además sean de Tesorería). Ya no se asigna en Configurar usuarios: se deriva de Bitrix24 y ahí solo se muestra la lista informativa. El administrador del portal también entra (ver "Administrador del portal"). El servidor lo verifica contra Bitrix24 al registrar un reintegro y al cerrar una liquidación (403 si no pertenece; 502 si no puede consultar Bitrix24).

Estos grupos son independientes entre sí: un usuario puede pertenecer a ninguno, a uno o a varios a la vez (además de ser o no administrador del portal, que da acceso a todo sin excepción).

Qué hace

• El menú "Solicitud" agrupa cinco pantallas (se puede colapsar/expandir haciendo clic en su encabezado):

  1. Crear Solicitud: encabezado de una solicitud de compra — fondo (solo lista los fondos a los que pertenece quien la crea), nombre del proceso y, como información de la solicitud (texto, no campos de formulario; no se pueden editar), el Área solicitante, la Jefatura solicitante, la Gerencia responsable y el Gerente responsable. El área es el departamento de Bitrix24 de quien crea la solicitud (se ignoran grupos como "Solicitantes de Insumos de Oficina" y, si hay otro, la raíz AMSAC) y el resto sale de la estructura (ver "Responsables según la estructura de Bitrix24"). Si falta el usuario que debe figurar como jefe de algún departamento, o el usuario no tiene departamento, aparece un aviso ("Falta asignar un usuario en Bitrix24 antes de continuar") y no se puede crear la solicitud hasta asignarlo. Después vienen descripción, justificación, clasificación del gasto (Gasto Emergente / Imprevisto / Recurrente) y forma de pago (Efectivo / Transferencia Bancaria / Cheque). Incluye una tabla de ítems (se pueden agregar o quitar filas): tipo (Bien/Servicio), cantidad, descripción, precio unitario y total (se calcula solo, cantidad × precio unitario); el monto total de la solicitud es la suma de los ítems. El N° de ítem siempre queda correlativo (1, 2, 3...): si se quita una fila, las demás se renumeran para no dejar huecos. Al final del formulario, justo antes de "Crear solicitud", "Adjuntar cotizaciones (PDF) *" es obligatorio: hay que subir al menos un archivo (se pueden subir varios, máx. 3 MB cada uno) para poder crear la solicitud. Quedan disponibles para revisión —de solo lectura— en Certificación presupuestaria y Desembolso de fondos, y se anexan como páginas adicionales al PDF que se descarga al desembolsar.
  2. Autorización de gerencia (acceso: automático para quien fue elegido como "Gerencia responsable" de al menos una solicitud, ver "Modelo de permisos"): al crear la solicitud, esa persona recibe automáticamente una notificación de Bitrix24 (si BITRIX24_WEBHOOK_URL está configurada) con dos enlaces, "✅ Autorizar" y "❌ Denegar", que la llevan directo a esta pantalla ya abierta en esa solicitud — y si entró justo desde uno de esos enlaces, el cuadro de confirmación de esa decisión ya aparece armado, solo falta confirmarlo. Además de por notificación, esta pantalla también se usa entrando normalmente por el menú: tabla con las solicitudes donde esa persona es la gerencia responsable (un administrador ve las de todos). "Ver detalle" muestra la misma información completa que Desembolso de fondos (área, descripción, justificación, ítems, cotización, monto solicitado). Mientras la solicitud está aparecen los botones y : autorizarla la deja lista para que un certificador la certifique; denegarla la archiva en estado (guarda quién y cuándo decidió) y ahí termina su proceso — no se puede editar, eliminar, certificar ni continuar de ninguna forma. Una solicitud ya autorizada, certificada, desembolsada, facturada, denegada o eliminada no muestra estos botones (ya se decidió o ya avanzó). El servidor exige que quien autorice o deniegue sea justo la gerencia responsable asignada a esa solicitud (o un administrador), no solo la pantalla.

Base de datos (Supabase)

1. Entra al proyecto Supabase que ya usa amsac-transporte-bitrix24.
2. SQL Editor → New query → pega y ejecuta el contenido de schema.sql. Crea gastos_registros, gastos_historial, gastos_fondos, gastos_fondo_usuarios, gastos_solicitudes, gastos_tesoreria y gastos_gestiones; no toca ninguna tabla transporte_*. El script es seguro de volver a correr aunque las tablas ya existan (usa if not exists / migraciones idempotentes), por ejemplo para agregar la columna estado, solicitud_id, numero_comprobante_retencion, jefatura_solicitante, gerencia_responsable_unidad o gestion_id.
3. Las cotizaciones y facturas en PDF se guardan en Supabase Storage, en un bucket llamado cotizaciones (mismo bucket para ambas). No hace falta crearlo a mano: api/upload.js lo crea automáticamente (público, solo PDF, 3 MB máx. por archivo) la primera vez que alguien adjunta un archivo. Si prefieres crearlo tú antes, ve a Storage → New bucket en el panel de Supabase, nómbralo cotizaciones y márcalo como público.

Variables de entorno (Vercel)

Mismas credenciales que ya usa el proyecto de transporte (mismo proyecto Supabase):

• SUPABASE_URL
• SUPABASE_SECRET (service role key — solo se usa en las funciones api/*.js, nunca en el navegador)
• BITRIX24_WEBHOOK_URL: webhook entrante de Bitrix24 con scopes im y disk (ver "Instalación en Bitrix24" para cómo crearlo). Con solo im (opcional) la app funciona igual salvo por el aviso a la gerencia responsable, que simplemente no se envía. disk es obligatorio desde que existe "Confirmar revisado" en Certificación presupuestaria → "Revisión de reintegros y liquidaciones": esa acción sube el comprobante PDF a Bitrix24 Disk como paso obligatorio (no best-effort, ver "Notas técnicas") — sin ese scope, "Confirmar revisado" falla con un error claro en vez de completarse a medias.
• BITRIX24_APP_URL (opcional): la URL con la que Bitrix24 abre esta app embebida dentro del portal — se ve en la barra de direcciones al abrir la app desde el menú de aplicaciones, tiene la forma https://<tu-portal>.bitrix24.es/marketplace/app/<id>/. Se usa para que los enlaces "Autorizar"/"Denegar" de la notificación reabran la app autenticada dentro de Bitrix24, en vez de como una pestaña suelta del navegador (donde BX24.init() no puede autenticar y la app se queda cargando para siempre). Si no se configura, esos enlaces usan la URL directa de la app (https://<host>/index.html) — funciona solo si ya hay una sesión de Bitrix24 activa en el mismo navegador al hacer clic.

Desarrollo local

index.source.html es el archivo fuente editable. api/handler.js es un archivo generado: sirve el HTML como string desde una función serverless. Tras editar index.source.html, regenera handler.js con:

node build.js

No edites api/handler.js directamente; los cambios se perderían en el próximo build.

Despliegue

Igual que transporte: conectar la carpeta a un proyecto Vercel (vercel.json ya trae el rewrite /index.html → /api/handler) y configurar las variables de entorno anteriores.

Instalación en Bitrix24

1. Entra a Aplicaciones → Recursos para desarrolladores → Otro → "Cree webhooks entrantes o salientes, o una aplicación local".
2. Elige "Aplicación local", tipo Estática (Static), apuntando a la URL desplegada en Vercel (ej. https://<tu-proyecto>.vercel.app/index.html).
3. Nombre sugerido: Gastos de Baja Cuantía.
4. Permisos (scopes): marca user (para user.current, user.admin, user.get, department.get) — no necesita calendar como transporte.
5. Guarda e instala la app en el portal.
6. Ábrela una vez como administrador y ve a "Configurar usuarios": crea al menos un fondo (tipo, monto total, año) y asígnale los usuarios que podrán registrar gastos.
7. Comparte el acceso desde el menú de aplicaciones del portal con el resto de usuarios autorizados.
8. Entra a Aplicaciones → Recursos para desarrolladores → Otro → "Cree webhooks entrantes o salientes...", elige "Webhook entrante", y en el buscador de permisos agrega dos scopes:
   • im (busca "im" y elige la opción cuyo código sea exactamente (im), por ejemplo "Chat y Notificaciones (im)" — no messageservice, im.import ni imconnector, que son otra cosa) — opcional, habilita el aviso a la gerencia responsable y al administrador de fondo.
   • disk (busca "disk" o "Bitrix24.Disk" y elige esa opción) — obligatorio, es donde se guardan los comprobantes PDF de "Confirmar revisado" (ver "Notas técnicas"). Guarda. Copia la URL generada (tiene la forma https://<tu-portal>.bitrix24.es/rest/<id>/<código>/) y agrégala como BITRIX24_WEBHOOK_URL en las variables de entorno de Vercel (sección anterior). Las notificaciones y los archivos quedan como si los enviara/ subiera el usuario dueño del webhook — por eso los comprobantes de todos los administradores de fondo terminan en subcarpetas dentro del Disk de esa misma cuenta (ver "Notas técnicas"), no en el Disk personal de cada uno.
9. (Opcional, para que los enlaces "Autorizar"/"Denegar" de esa notificación reabran la app embebida y autenticada dentro de Bitrix24 en vez de una pestaña suelta) Abre la app una vez desde el menú de aplicaciones del portal, copia la URL que queda en la barra de direcciones (tiene la forma https://<tu-portal>.bitrix24.es/marketplace/app/<id>/) y agrégala como BITRIX24_APP_URL en Vercel.
10. Después de agregar cualquiera de las dos variables anteriores, hace falta un en Vercel — agregar una variable de entorno no afecta a los deployments que ya existen.

Notas técnicas

• No hay servidor de sesiones propio: la identidad (actor_id, actor_is_admin) llega desde el navegador en cada llamada a /api/gastos, igual modelo de confianza que transporte_* (herramienta interna, no expuesta al público).
• "Cargo" y "Unidad" en Reportes salen de WORK_POSITION y UF_DEPARTMENT de user.get/department.get de Bitrix24, no se guardan en la tabla de gastos.
• Responsables según la estructura de Bitrix24: jefatura_solicitante, gerencia_responsable_unidad y gerencia_responsable_id/nombre se calculan en el navegador (resolverResponsables) con los departamentos y el jefe (UF_HEAD) de cada uno, en Crear Solicitud:
  • Jefatura solicitante: jefe del departamento del usuario (su área).
  • Gerencia y gerente responsable (la gerencia responsable es siempre la Gerencia que está por encima del área, no el superior inmediato):
    • Subgerencias, departamentos y unidades que dependen de una Gerencia (departamento cuyo nombre empieza por "Gerencia"), aunque haya niveles en medio (p. ej. Almacén y Proveeduría, que depende de Inventario): responde esa Gerencia y su jefe.
    • Las propias Gerencias y las dependencias que cuelgan directo de la Dirección de Distrito: responde la Dirección de Distrito y su jefe.
    • La Dirección de Distrito y las dependencias del Despacho y del Concejo Municipal (Sindicatura, Auditoría, Secretaría, UAIP...): responde el Despacho alcalde municipal, y el gerente es el Alcalde Municipal (jefe de ese departamento).
  • Si algún jefe falta (o está inactivo en Bitrix24) se muestra qué usuario hay que asignar y se bloquea el envío. El servidor guarda los valores tal cual (mismo modelo de confianza que gerencia_responsable_nombre).
  • Certificación presupuestaria conserva su edición manual (doble clic) de estos campos.
• La exportación a Excel (Reportes) usa SheetJS (xlsx.full.min.js por CDN) en el navegador; PDF usa jsPDF + jspdf-autotable, igual que en transporte. El PDF de Desembolso además usa pdf-lib (CDN) para anexarle las cotizaciones adjuntas como páginas extra.
• Cotizaciones (PDF): api/upload.js las sube a Supabase Storage (bucket cotizaciones, público) usando la service role key; el navegador nunca ve esa key, solo manda el PDF en base64 a este endpoint. Al ser un bucket público, cualquiera con el enlace exacto (una URL larga con un sufijo aleatorio) puede abrir el archivo — igual de "protegido por oscuridad" que el resto de esta herramienta interna, no es un control de acceso real. Límite de 3 MB por archivo (margen para el límite de payload de las funciones de Vercel); se puede subir más de un PDF por solicitud. Es obligatorio al una solicitud (al menos un PDF); al (Certificación presupuestaria) no se vuelve a exigir, para no bloquear solicitudes creadas antes de que este campo existiera — ese formulario solo las conserva de solo lectura, no ofrece forma de agregarlas.

Certificación presupuestaria ligada al presupuesto aprobado (Presupuesto 2027)

Desde esta versión, certificar una solicitud depende de lo aprobado por el Departamento de Presupuesto para baja cuantía en el sistema Presupuesto 2027 (D:\Presupuesto inventario 2027\sistema). Ambos sistemas usan el mismo proyecto Supabase; esta app solo lee el esquema presupuesto (bc_presupuestos / bc_items) a través de api/presupuesto.js — no copia ni duplica montos, no necesita variables de entorno nuevas ni migraciones. Todo aumento, disminución, específico agregado o quitado lo hace Presupuesto desde su sistema y se refleja aquí al instante.

Reglas (las aplica el servidor en action=update de api/solicitudes.js, no solo la pantalla):

• Solo cuenta lo que está aprobado y no quitado. Si el presupuesto de la unidad sigue en borrador/enviado, no se puede certificar.
• Año: el del fondo de la solicitud (gastos_fondos.anio). Para usar 2028 basta crear el fondo 2028 aquí y que Presupuesto cargue/apruebe el 2028 allá. Si Presupuesto todavía no tiene ningún presupuesto de baja cuantía de ese año (hoy el fondo 2026), no se aplica control.
• Unidad: departamento de Bitrix24 del "Área solicitante" (por id si hay, si no por nombre sin distinguir mayúsculas/tildes).
• Fondo: Caja chica → caja_chica; Fondo circulante → fondo_circulante más fondo_flotas si esa unidad lo tiene (Monitoreo y Mantenimiento de Flotas).
• Por específico: lo pedido en la solicitud no puede superar aprobado − comprometido. Comprometido = ítems de solicitudes ya certificadas, desembolsadas o facturadas (mismo tipo de fondo, año y unidad); denegar o eliminar una solicitud libera su monto. Un específico sin monto aprobado para esa unidad tampoco se puede certificar.
• Si no se puede consultar Presupuesto, no se certifica a ciegas (error).

En el formulario de Certificación aparece el panel "Disponibilidad presupuestaria" (aprobado, ya comprometido, disponible y lo que pide esta solicitud, resaltando en rojo lo que excede).

Flujo de reintegro (v2)

1. Administrador de fondo (Solicitud de reintegro o liquidación): elige fondo y rango de fechas, marca los gastos y los envía → gestión pendiente.
2. Presupuesto (certificadores; Presupuesto → "Revisión de reintegros y liquidaciones"): revisa, modifica con "Editar" si es necesario y pulsa "Autorizar y enviar a Tesorería" → se genera el PDF (fecha y hora), se guarda en Bitrix24 Disk, el total se recalcula con lo que quedó tras las ediciones y se notifica al administrador y a todo el personal del Departamento de Tesorería (miembros + jefe) → revisado.
3. Tesorería: sube el acuerdo municipal y el comprobante (transferencia en fondo circulante; voucher/cheque en caja chica) → entregado. Se avisa al administrador.
4. Administrador de fondo: confirma que recibió los fondos → cerrado. Mientras no confirme no puede usar ese fondo (el servidor bloquea crear solicitudes, desembolsar y registrar gastos con ese fondo); al confirmar puede iniciar un nuevo ciclo. Aplica a fondo circulante y caja chica. (Las liquidaciones no pasan por entregado: Tesorería las cierra.)

Reglas del reintegro (según el Reglamento de fondos de baja cuantía)

Fuente: Reglamento para la Administración de los Fondos para las Compras de Baja Cuantía y Compras en Línea (Decreto 3/2025, Concejo Municipal de Santa Ana Centro). Las reglas las valida el servidor (api/gestiones.js, acción crear), no solo la pantalla.

• Referencia mensual (Art. 5): cada fondo tiene un monto máximo al año (gastos_fondos.monto_total, variable por fondo; el reglamento fija hasta $300,000 en circulante y $24,000 en caja chica). La referencia mensual es ese monto entre 12, con redondeo acumulado en centavos para que los 12 meses sumen exactamente el total anual (sin descuadres).
• Cuándo se puede pedir un reintegro (Art. 31): cuando los gastos seleccionados alcanzan el 60% de la referencia del mes, o a más tardar el último día del mes (si el mes ya terminó o hoy es su último día, se permite aunque no se llegue al 60%). La fecha de hoy se toma en hora de El Salvador (UTC-6). Si no se cumple, el servidor responde con cuánto falta. Aplica a fondo circulante y caja chica. La liquidación no tiene estas restricciones (se puede pedir en cualquier momento).
• Documento físico recibido: el solicitante entrega la factura o documento equivalente al administrador de fondo, y este lo marca como recibido (por gasto o en bloque) en "Solicitud de reintegro o liquidación". Solo los gastos con documento recibido pueden incluirse en un reintegro (se guarda quién y cuándo lo marcó; columnas documento_fisico_* de gastos_registros, migración migracion-documento-fisico.sql). Solo lo puede marcar el administrador del fondo (o un administrador del portal verificado contra Bitrix24) y solo mientras el gasto siga "registrado". Los gastos anteriores a esta regla quedan como "pendiente de recibir".

Reglas de fondos (parámetros editables)

Ningún número del reglamento está escrito en el código: todos viven en la tabla gastos_reglas y se cambian desde el menú Consulta y administración → Reglas de fondos (solo administrador del portal, verificado contra Bitrix24). Si el reglamento se reforma, basta con editar ahí; los cambios se aplican de inmediato a nuevas solicitudes, desembolsos y reintegros (el servidor guarda los valores en memoria hasta 15 s) y cada cambio queda en un historial (quién, cuándo, valor anterior → nuevo). Hay un bloque por tipo de fondo (circulante y caja chica) más el salario mínimo de referencia.

Parámetro (por tipo de fondo)	Qué controla
El solicitante es siempre el administrador del fondo	todos los usuarios asignados quedan como administradores y solo ellos pueden crear solicitudes
Exigir autorización de la gerencia responsable	si no, la solicitud nace autorizada y pasa directo a Presupuesto
Monto máximo anual	tope al crear o editar un fondo de ese tipo (0 = sin tope)
Límite de compra ordinaria	lo que lo supera es compra excepcional
Formas de pago permitidas	efectivo / transferencia / cheque
Efectivo: máximo por compra	tope por compra en efectivo (0 = sin tope)
Parte del fondo en efectivo (%)	el resto queda en banco; se ajusta solo a 100% si solo hay efectivo y a 0% si no se permite efectivo
Permitir compras excepcionales	si no, toda compra sobre el límite se rechaza
Exigir acuerdo administrativo (PDF)	para compras excepcionales
Máximo excepcional (salarios mínimos)	× salario mínimo de referencia (0 = sin tope)
Tope de lo excepcional (% de la referencia mensual)	una sola compra excepcional o varias no pueden sumar más; 0 = sin tope
Contar el tope por ciclo	si está activo (por defecto) el tope rige por ciclo del fondo, hasta que Tesorería entrega el reintegro; si no, por mes calendario
Margen de las facturas sobre lo autorizado (%)	las facturas de una solicitud no pueden sumar más que su monto (0 = exacto)
Retener IVA y exigir comprobante de retención	antes del desembolso de toda compra que llegue al mínimo (ordinaria o excepcional); activo en ambos tipos de fondo
Porcentaje a retener	1%, sobre el valor sin IVA
Valor mínimo para retener (sin IVA)	$100
IVA (%) (parámetros generales)	13; los montos de las solicitudes incluyen IVA y con esto se separa
% de la referencia para poder pedir reintegro	umbral del reintegro
Permitir reintegro al cierre del mes	aunque no se llegue al %
Exigir documento físico recibido	para incluir un gasto en un reintegro

"Cargar valores iniciales" vuelve a poner en el formulario los valores del reglamento de 2025 (sin guardar hasta pulsar "Guardar reglas"). Los valores iniciales están también en api/gestiones.js (DEFAULTS) y sirven de respaldo si la tabla no se puede leer. Migración: migracion-reglas-parametros.sql. API: GET fondos?action=reglas y POST fondos con action=guardar_reglas.

Plazo para registrar la factura (días hábiles), recordatorios y score de cumplimiento

Reglamento Art. 19: el solicitante tiene 3 días hábiles para presentar la factura o documento equivalente. Se controla así (módulo api/plazos.js, tabla gastos_plazos, migración migracion-plazos-comprobantes.sql):

• Punto de partida: el día del desembolso. Al desembolsar se crea el plazo y se calcula la fecha de vencimiento = el 3.er día hábil después (hábil = lunes a viernes sin feriados; hora de El Salvador). Si el desembolso es en sábado o domingo, el conteo empieza el lunes.
• Llegada: el día en que se registra la factura del último ítem de la solicitud (cuando pasa a "facturado"). Si ese día es menor o igual a la fecha de vencimiento, el solicitante cumple; si la supera, incumple (con los días hábiles de atraso). Solo se cierra la primera vez.
• Notificaciones: si el plazo vence sin registrar la factura, se envía una notificación de Bitrix24 al solicitante y al administrador del fondo (una sola si son la misma persona, como en caja chica) y se repite una vez por día mientras siga pendiente (máximo una por solicitud al día). Lo hace una función programada diaria (vercel.json → crons: 14:00 UTC = 8:00 a. m. hora de El Salvador, GET /api/plazos). Si defines la variable CRON_SECRET en Vercel, solo Vercel puede invocarla. Un administrador del portal también puede pulsar "Enviar recordatorios ahora" en la pantalla de cumplimiento.
• Historial de incumplimientos y score: menú Solicitante → Cumplimiento de plazos. Score = a tiempo ÷ (a tiempo + incumplidos + vencidos sin registrar); lo que sigue dentro del plazo no cuenta todavía. Niveles: Excelente ≥ 90%, Bueno ≥ 75%, En riesgo por debajo. El score propio está siempre visible en la barra superior (círculo de color + %) y en la tarjeta de usuario del menú; en "Registrar factura" cada solicitud muestra su plazo (a tiempo / vence el dd/mm / vencido). La pantalla muestra la tarjeta de score, el historial de incumplimientos y todos los plazos; el administrador del portal ve a todos (con ranking por solicitante), el administrador de fondo ve a los de sus fondos, y los demás solo lo suyo (calculado en el servidor).
• Feriados homologados con Bitrix24: los días no hábiles se leen del calendario de Bitrix24 (Calendario → Configuración; método REST calendar.settings.get con el webhook BITRIX24_WEBHOOK_URL, alcance calendar), así el plazo usa los mismos feriados que el resto de la empresa:
  • Feriados (, día y mes que se repiten , p. ej. 23–26 de julio de las fiestas de Santa Ana, 24–31 de diciembre, 1 de enero, 1 de mayo, 6 de agosto…).

Caja chica: solicitante = administrador, sin autorización de gerencia

En caja chica el solicitante y el administrador del fondo son siempre la misma persona y la solicitud no necesita autorización de gerencia (parámetros solicitanteEsAdministrador y exigeAutorizacionGerencia de "Reglas de fondos"; en circulante siguen como antes). Consecuencias, todas validadas en el servidor:

• Asignación (fondos → asignar): todos los usuarios que se asignan a una caja chica quedan como administradores del fondo (aunque se marque lo contrario).
• Crear solicitud: solo puede quien es administrador del fondo (o un administrador del portal). La solicitud nace "autorizada" (queda gerencia_decision_por_nombre = "No requiere autorización de gerencia"), no se notifica a ninguna gerencia y no se exige gerente responsable: de Bitrix24 solo se necesita el área del usuario. Pasa directo a Certificación presupuestaria (Presupuesto), luego Desembolso.
• Pantalla: Crear Solicitud muestra "No aplica" en gerencia y gerente y no bloquea si faltan en Bitrix24; las solicitudes de caja chica no aparecen en "Autorización de gerencia" (ni dan acceso a esa pantalla). En Certificación el campo de gerencia ya no es obligatorio para estos fondos.
• Documento físico: como solicitante y administrador son la misma persona, no hay entrega entre personas: en caja chica reintegroExigeDocumento queda en "No" y no se muestra la marca de documento recibido.

Límites de compra, efectivo/banco y compras excepcionales

Los valores de la tabla de abajo son los iniciales (reglamento de 2025); los vigentes son los que estén en "Reglas de fondos".

Las valida el servidor (api/gestiones.js: evaluarCuantia y calcularSaldoFondo) al crear la solicitud, al certificarla si cambian los montos y al desembolsar. La pantalla de Crear Solicitud avisa en vivo, pero no es la que decide. Migración: migracion-limites-excepcionales.sql.

	Fondo circulante	Caja chica
Compra ordinaria (Art. 6)	hasta $1,000	hasta $100
Forma de pago	efectivo solo hasta $500 por compra (Art. 11); transferencia o cheque sin tope	solo efectivo (Art. 12)
Reparto del fondo	40% efectivo / 60% banco de la referencia mensual	100% efectivo
Compra excepcional (supera el límite ordinario)	exige el acuerdo administrativo del Alcalde Municipal en PDF (Art. 7); máximo 20 salarios mínimos de comercio y servicios; lo excepcional de cada ciclo no pasa del 50% de la referencia mensual	sin acuerdo; lo excepcional de cada ciclo no pasa del 50% de la referencia mensual (Art. 8) y exige comprobante de retención tramitado con Tesorería antes de la compra

• Efectivo y banco con gastos reales: la forma de pago de cada solicitud decide el medio — efectivo afecta al efectivo; cheque y transferencia afectan al banco. El saldo de un fondo = (40% o 60% de la referencia del mes) menos lo ya desembolsado (solicitudes desembolsadas o facturadas) que aún no fue repuesto por un reintegro entregado o cerrado. Al desembolsar, si el medio no alcanza, el servidor rechaza con lo disponible. Se muestra en el detalle del Desembolso y en el panel de "Solicitud de reintegro o liquidación" (GET fondos?action=saldo&fondoId=).
• Acuerdo administrativo (circulante): al crear, si el total supera $1,000, aparece el campo para subir el PDF; sin él no se crea. Queda guardado en la solicitud y se ve en Autorización y Desembolso. La solicitud se marca excepcional.
• Retención de anticipo de IVA (caja chica y circulante): la alcaldía es agente de retención (Código Tributario, Art. 162; el comprobante, Art. 112. La Ley de IVA tiene derogados sus arts. 36 a 38, 80 y 101 y remite al Código). Los montos de las solicitudes se ingresan con IVA incluido (así se indica en "Precio unitario (con IVA)"). El sistema separa el IVA (13%): si el valor sin IVA es de $100 o más, retiene el 1% de ese valor. Ejemplo: $113.00 con IVA = $100.00 sin IVA → retención $1.00, y al proveedor se le pagan $112.00. Esto aplica a toda compra, sea ordinaria o excepcional. Al crear la solicitud se avisa si lleva retención; en el Desembolso el administrador registra el N° de comprobante (tramitado con Tesorería) y queda guardado con la base, el monto retenido y quién y cuándo lo registró; sin él no se desembolsa. Porcentaje, mínimo e IVA se cambian en "Reglas de fondos". El sistema no mueve el saldo del fondo por la retención (el gasto sigue siendo el total).
• Tope del 50% por ciclo: una sola compra excepcional, o varias compras excepcionales individuales, no pueden sumar más del 50% de la referencia mensual del fondo en cada ciclo. El ciclo empieza cuando Tesorería entrega el reintegro que repone el fondo: lo excepcional ya repuesto deja de contar y el tope se renueva. Lo comprometido sigue contando aunque aún no se desembolse (solicitudes pendientes, autorizadas o certificadas) y lo desembolsado o facturado cuenta hasta que lo reponga un reintegro entregado. El panel del Desembolso muestra el tope, lo usado y lo disponible. Se puede volver al conteo por mes calendario desmarcando "Contar ese tope por ciclo".
• Facturas dentro de lo autorizado: al registrar una factura, las de esa solicitud (una o varias) no pueden sumar más que su monto autorizado y desembolsado (más el margen configurable, 0% por defecto); así una compra no se infla al facturarla. Un gasto real mayor requiere una solicitud adicional con su certificación.

Estados de gastos_gestiones: pendiente → revisado → (entregado) → cerrado. Columnas nuevas (migración migracion-reintegro-v2.sql): fecha_desde, fecha_hasta, cuenta_bancaria, acuerdo_*, comprobante_*, tesoreria_*. Acciones de api/gestiones.js: crear, revisar, registrar_tesoreria, confirmar y cerrar (esta última solo para liquidaciones).