Cálculo de plazos en días laborables para sistemas de procesamiento de solicitudes
Los sistemas de procesamiento de solicitudes requieren el seguimiento de días laborables en lugar de días calendario para cálculos precisos de plazos. El conteo comienza el día de publicación durante el horario laboral, o el siguiente día laboral si se publica fuera del horario. El calendario se carga automáticamente desde un servicio externo al inicio y se verifica diariamente para obtener datos del año actual y el siguiente. Sin calendario, el sistema recurre a días calendario.
El registro ocurre al instante tras la publicación, sin esperar a un día laboral. Por ejemplo: publicación a las 11:00 PM en un día laboral desplaza el inicio al siguiente día laboral; publicación a las 6:00 AM en el mismo día permanece en el día actual si el horario comienza más tarde.
Reglas para mostrar el contador
El contador muestra el número de días laborables completos que han transcurrido. Independientemente de la hora de publicación, en el día de inicio del plazo, muestra 0/N.
- Día de publicación durante el horario laboral: 0/N hasta las 00:00 del día siguiente.
- Publicación fuera del horario: 0/N hasta las 00:00 del primer día laboral.
El contador se incrementa a las 00:00 después de que ha terminado un día laboral completo. Un plazo se considera incumplido cuando el valor es ≥ N (ej., 5/5).
Alternativas rechazadas en la discusión
- Contador que comienza en 1/N desde el momento de la publicación — complica la percepción de días completos.
- Incrementar al final del día laboral — ignora los retrasos de los empleados.
- Marcar como vencido al final del día laboral — poco intuitivo para 5:59 PM vs. 6:01 PM.
Ejemplos de cálculo
Ejemplo 1: Publicación el 1 de enero (festivo), primer día laboral el 12 de enero, plazo el 16 de enero (5 días). Procesamiento el 13 de enero — contador 1/5 (día completo: solo el 12 de enero).
Ejemplo 2: 2 días para procesamiento, publicación en un día laboral a las 9:00 AM (lunes). Lunes: 0/2; martes: 1/2; medianoche del martes: 2/2 (vencido).
Ejemplo 3: Misma tarea, publicación a las 8:00 PM del lunes. Lunes: 0/2; martes: 0/2; miércoles: 1/2; medianoche del miércoles: 2/2.
Las zonas horarias se unifican a la hora del servidor para simplificar.
Matices de implementación en el backend
- Almacenar en caché el calendario en memoria: año actual + año siguiente (con limpieza de datos antiguos).
- Registrar valores del contador y plazos originales en la base de datos para cada solicitud — minimiza recálculos.
- Almacenar historial de plazos: una tabla separada para configuraciones por tipo/período o una columna en la entidad.
Actualización del calendario: solicitudes API al inicio, diariamente a las 00:00.
Pruebas de escenarios clave
Probar el comportamiento en tiempo real o simular mediante base de datos/API:
- Día laboral normal.
- Festivo.
- Noche de un día laboral (después del horario).
- Ausencia de calendario — recurso y actualización automática.
- Plazos vencidos y normales.
- Carga: múltiples calendarios a lo largo de años.
- Servicios API inactivos.
Puntos clave
- El conteo comienza el día de publicación dentro del horario o el siguiente día laboral.
- Contador: días completos transcurridos, comenzando en 0/N.
- Vencido: ≥ N a las 00:00 después del plazo.
- El almacenamiento en caché y el registro en base de datos reducen la carga.
- Probar casos límite: festivos, noches, datos faltantes.
— Editorial Team
Aún no hay comentarios.