Reglas de fecha (V1–V4)

Las reglas de fecha son la causa más frecuente de rechazos en insertar facturas. Se aplican muy temprano en el pipeline (paso 3), antes de tocar la base de datos. Entenderlas evita la mayoría de los problemas de integración.

Idea central

Un manifiesto es un lote de carga, no necesariamente un único día operativo. Por eso:

• Un mismo NumeroManifiesto puede traer facturas de fechas distintas (la mezcla está permitida por defecto).
• Cada factura conserva su propia FechaFactura real como fecha de la factura.
• Lo que se valida, factura por factura, es que ninguna fecha sea futura ni demasiado antigua.

Todas las comparaciones se hacen en zona horaria de Honduras: America/Tegucigalpa (UTC-6, sin horario de verano).

Cómo se evalúa cada manifiesto

flowchart TD
    Start([Manifiesto del batch]) --> Mix{V1· mezcla permitida?<br/>reject_mixed_dates}
    Mix -- off · default --> PerInv[Revisar cada factura]
    Mix -- on --> Homog{una sola fecha?}
    Homog -- no --> R1([FECHAS_MEZCLADAS])
    Homog -- sí --> PerInv
    PerInv --> Fmt{V·· toda fecha<br/>parseable?}
    Fmt -- no --> R0([FECHA_FACTURA_INVALIDA])
    Fmt -- sí --> V2{V2· ninguna futura?}
    V2 -- hay futura --> R2([FECHA_FACTURA_FUTURA])
    V2 -- ok --> V3{V3· ninguna supera<br/>30 días?}
    V3 -- hay antigua --> R3([FECHA_FACTURA_DEMASIADO_ANTIGUA])
    V3 -- ok --> OK([Manifiesto válido])

    style R0 fill:#fde3e3,stroke:#c0392b,color:#7a271a
    style R1 fill:#fde3e3,stroke:#c0392b,color:#7a271a
    style R2 fill:#fde3e3,stroke:#c0392b,color:#7a271a
    style R3 fill:#fde3e3,stroke:#c0392b,color:#7a271a
    style OK fill:#dcf3e3,stroke:#1f8a4c,color:#14532d

El rechazo es atómico por manifiesto: si una sola factura del manifiesto viola V2 o V3, se rechaza el manifiesto completo (ninguna de sus facturas entra). Esto fuerza la corrección en origen en lugar de aceptar lotes a medias.

V1 — Mezcla de fechas (FECHAS_MEZCLADAS) · opcional, por defecto permitida

Por defecto un manifiesto puede contener facturas con distintas FechaFactura. No se rechaza por mezclar fechas.

Existe un interruptor de configuración (reject_mixed_dates) que, si Hosana lo activa, vuelve al modo estricto: cada NumeroManifiesto debe tener una sola fecha, y mezclar se rechaza con FECHAS_MEZCLADAS. En la operación actual está desactivado, por requerimiento de Jaremar.

V2 — No futura (FECHA_FACTURA_FUTURA) · por factura

Ninguna FechaFactura puede ser posterior a “hoy” en hora de Honduras. Se revisa cada factura; si alguna es futura, se rechaza el manifiesto completo.

"detalle": {
  "hoy_servidor": "2026-06-13",
  "facturas_futuras": {
    "002-001-01-04004003": "2026-06-20"
  },
  "instruccion": "Una o más facturas tienen FechaFactura posterior a hoy (Honduras). Corrija el origen."
}

Acción: corrige la fecha en origen. No reenvíes con fecha futura.

V3 — No demasiado antigua (FECHA_FACTURA_DEMASIADO_ANTIGUA) · por factura

Ninguna FechaFactura puede tener más de 30 días de antigüedad respecto a hoy (configurable). Se revisa cada factura; si alguna excede el límite, se rechaza el manifiesto completo.

Por qué 30 días: coincide con el ciclo de declaración mensual de ISV en Honduras. Facturas más viejas que un mes probablemente caen en periodos fiscales ya declarados al SAR, y aceptarlas automáticamente sería un riesgo regulatorio.

"detalle": {
  "hoy_servidor": "2026-06-13",
  "limite_dias": 30,
  "facturas_antiguas": {
    "002-001-01-04004002": { "fecha": "2026-04-01", "dias": 73 }
  },
  "instruccion": "Una o más facturas superan el límite de 30 días de antigüedad. El manifiesto se rechaza completo; corrija el origen o cargue desde el panel administrativo."
}

Acción: estas facturas no entran por API. Sepáralas del lote, o contacta a Hosana para una carga manual autorizada desde el panel.

V4 — De dónde sale la fecha del manifiesto

La fecha del manifiesto (manifests.date) es, por defecto, el día en que se sube el lote (hoy, en hora de Honduras) — no la fecha de las facturas. El manifiesto representa el lote de carga.

Cada factura conserva su FechaFactura real en su propio registro (invoice_date); lo único que usa el día de carga es la fecha de agrupación del manifiesto.

Existe un modo histórico (manifest_date_source = invoice) que deriva la fecha del manifiesto de la FechaFactura, pensado para cuando se exige homogeneidad. En la operación actual se usa el día de carga.

Sub-motivo extra: FECHA_FACTURA_INVALIDA

Si alguna FechaFactura no se puede interpretar como fecha válida en ninguno de los formatos soportados, se reporta este sub-motivo con la lista de facturas afectadas:

"detalle": {
  "facturas_afectadas": ["002-001-01-04004009"],
  "instruccion": "Una o más FechaFactura no se pudieron interpretar como fecha válida."
}

Nota sobre la zona horaria

Un timestamp UTC a medianoche exacta (2026-06-12T00:00:00.000Z) se interpreta como ese día calendario (2026-06-12), sin restarle 6 horas. Para timestamps con hora real (2026-06-12T03:00:00Z), sí se convierten a hora de Honduras antes de extraer la fecha. Recomendación: envía fechas planas (2026-06-12) o timestamps a medianoche UTC para evitar cualquier ambigüedad.

Resumen

Regla	Motivo	Qué valida	Por defecto	HTTP
V1	FECHAS_MEZCLADAS	Una sola FechaFactura por manifiesto.	off (mezcla permitida)	422
V2	FECHA_FACTURA_FUTURA	Ninguna factura con fecha futura (Honduras).	activa, por factura	422
V3	FECHA_FACTURA_DEMASIADO_ANTIGUA	Ninguna factura supera 30 días de antigüedad.	activa, por factura	422
V4	—	Fecha del manifiesto = día de carga (no la factura).	activa	—
—	FECHA_FACTURA_INVALIDA	Toda FechaFactura se puede interpretar.	activa	422

Todos los rechazos de fecha llegan agrupados bajo el motivo raíz FECHAS_INVALIDAS en la respuesta. Cada manifiesto rechazado trae su propio sub-motivo y su detalle. Ver insertar facturas y los casos resueltos con los archivos de prueba descargables.