Plazos que atraviesan dos años: qué necesita tu integración

El año de inicio no define todo el calendario necesario

Imagina una aplicación que recibe una fecha de inicio en diciembre y debe calcular un vencimiento expresado en días hábiles. Si el recorrido llega a enero, necesita determinar qué días son hábiles también en el año siguiente. Tener completo el calendario del año de inicio no resuelve por sí solo esa consulta.

La decisión de producto es importante: una fecha que no aparece entre los festivos disponibles no se puede tratar automáticamente como laborable si falta el calendario que debería contenerla. La ausencia de datos y la ausencia de un festivo son situaciones diferentes.

Define primero qué estás calculando

Antes de elegir fechas, identifica el régimen de cómputo que corresponde al proceso de tu aplicación. También debes decidir si se incluye el día inicial y cuál es el territorio aplicable. No todos los vencimientos comparten reglas: un calendario laboral no determina por sí solo cualquier plazo administrativo, procesal o contractual.

En una integración conviene separar esos datos de entrada de la presentación del resultado. Así puedes explicar al usuario qué se ha pedido sin convertir una fecha calculada en una afirmación sobre reglas que la petición no representa. El contrato de la API describe los parámetros y regímenes disponibles.

Comprueba la cobertura del recorrido

Para un plazo que atraviese dos años, la comprobación relevante afecta a ambos calendarios y al ámbito territorial de la consulta. Si interviene una entidad local, comprueba también ese ámbito; no basta con saber que existe algún calendario en su municipio.

La página de cobertura ayuda a entender la disponibilidad por año. En la integración, la respuesta de la API y su contrato son la referencia para decidir cómo gestionar la operación concreta. Un porcentaje agregado de cobertura no garantiza que un municipio determinado esté disponible.

No copies el calendario de diciembre sobre enero ni reutilices los festivos locales del año anterior como si fueran una previsión confirmada. Tampoco completes huecos con las fechas de otro municipio por proximidad.

Un flujo de integración que distingue datos y resultado

1. Recoge fecha inicial, días solicitados, código INE y las opciones de cómputo necesarias.
2. Resuelve la entidad local cuando sea necesaria para esa ubicación.
3. Solicita el cálculo utilizando el contrato documentado.
4. Trata la respuesta de cobertura o validación como una situación explícita, no como un vencimiento correcto.
5. Presenta una fecha únicamente cuando dispongas de una respuesta válida para esa petición.

El ejemplo no presupone cuántos días festivos habrá en enero ni ofrece una fecha de vencimiento calculada a mano. Esa es precisamente la información que debe resolver la consulta con los calendarios aplicables.

Qué mostrar cuando todavía falta información

Una aplicación B2B puede conservar la petición y mostrar que no dispone de un resultado confirmado para ese ámbito. Esto es más útil que ofrecer una fecha provisional sin distinguirla del resto de resultados. El mensaje debe apoyarse en el código devuelto por la API y evitar atribuir todos los fallos a una publicación oficial pendiente: también puede haber parámetros incorrectos o un ámbito local mal seleccionado.

Si tu producto permite volver a intentar la operación más adelante, conserva sus parámetros. No hace falta cambiar la fecha inicial para repetir la misma consulta. La política de reintentos, notificación y almacenamiento pertenece a tu integración; no implica que la API envíe avisos automáticamente.

Prueba el cambio de año antes de ponerlo en producción

Incluye casos con recorrido dentro de un año y casos que crucen diciembre y enero, tanto con cobertura disponible como con un ámbito no disponible. Verifica además la inclusión del día inicial y el tratamiento de errores. Mantén separadas las pruebas funcionales de los calendarios reales, que pueden evolucionar.

Toddle ofrece entidades TEST documentadas. Utilízalas para los escenarios que cubren y consulta sus límites antes de asumir que reproducen cualquier caso interanual. El objetivo de estas pruebas es comprobar el comportamiento de tu aplicación, no sustituir la verificación de cobertura del municipio real.