Declaraciones en Sevastopol

Propósito

El dominio declaraciones del frontend cubre la gestión de las declaraciones tributarias que el tenant presenta al SII: el Formulario 29 mensual (IVA, PPM, retenciones, IUSC) y las declaraciones juradas anuales 1879 (honorarios) y 1887 (sueldos). Cada una tiene una island con su propio workflow, modelo de datos y reglas contables.

Las tres islands comparten el DeclaracionesWorkspace (mismo lenguaje visual), pero cada una opera sobre un endpoint distinto y modela una declaración diferente — no son pestañas de un mismo flujo.

Decisiones de UX

Decisión	Motivo
Tres islands independientes en vez de tabs	F29 es mensual, DDJJ son anuales. Los ciclos contables, los flujos de cierre y los datos fuente son distintos. Una tab única confundiría al operador.
useActivePeriod interpretado distinto en cada island	F29 filtra items en cliente por periodo (YYYY-MM); las DDJJ usan sólo year y re-fetchan el archivo del año.
F29 trae hasta 1000 registros en una llamada	Bajo volumen por tenant; paginar agrega latencia. El filtro de período se aplica en cliente sobre la lista ya cargada.
DDJJ tratan 404 como estado vacío	El backend no distingue “no existe aún” de error; la UI ofrece el CTA Generar DJ en el lugar del estado vacío.
Workflow del F29 con 4 estados	BORRADOR → VALIDADO → DECLARADO → ANULADO. Sólo DECLARADO habilita el cierre del paso declaraciones del ciclo.
Cuadre histórico vs actualizado	F29 declara nominales mensuales; las DDJJ informan actualizados al cierre del año. Comparar el F29 contra el actualizado de la DJ produce diferencias artificiales por corrección monetaria. La UI advierte explícitamente con :::caution::: en ambas DDJJ.
Baja administrativa de remanente F29 con asiento explícito	Caso operacional real soportado por el sistema. Modal con 5 validaciones duras (monto ≤ remanente disponible, motivo ≥ 5 caracteres, etc.) y preview en vivo del impacto + asiento (D 3701040 IVA no Recuperable / H 1108002 IVA Crédito Fiscal).
Regeneración anual de asientos F29 separada del CRUD	Acción destructiva sobre declaraciones.asientos_f29 del año, con confirm explícito. No para corregir un F29 puntual — eso va por rectificatoria.

Lenguaje compartido

Las tres islands comparten DeclaracionesWorkspace:

Componente	Uso
DeclaracionesWorkspaceHeader	Header con pills, controls y note.
InlineMetricPill	Métricas inline (período, registros, totales).
WorkspaceSectionCard	Sección con eyebrow, title, description, pills.
Botones	workspacePrimaryButtonClass, workspaceSecondaryButtonClass.

Hooks compartidos

Hook	F29	DJ 1879 / DJ 1887
useActiveTenant	Recarga la lista al cambiar tenant.	Recarga la cabecera + detalle del año al cambiar tenant.
useActivePeriod	No re-fetcha — el filtro aplica en cliente.	Re-fetcha al cambiar año (mes ignorado).

Backend de referencia

Los tres servicios viven bajo Declaraciones (Orchestrator):

• DeclaracionesService — CRUD del F29, workflow, baja remanente, regeneración anual de asientos.
• F29GeneratorService — generación del borrador desde la base operacional (compras, ventas, remuneraciones, honorarios).
• DJ1879Service — generación, persistencia y CSV de la DJ 1879 con factor de actualización mensual.
• DJ1887Service — equivalente para DJ 1887 con códigos de jornada SII.

Endpoints base

Dos proxies distintos vía createProxy — ver BFF Proxy:

Proxy	Cubre
/api/declaraciones/f29/*	F29 (los 5 métodos: GET, POST, PUT, DELETE, PATCH).
/api/declaraciones-juradas/1879/* y /api/declaraciones-juradas/1887/*	DDJJ (GET, POST, PUT, DELETE).

Relación con otros dominios

• Ciclo contable lee el estado del paso declaraciones (F29 en estado DECLARADO o sin movimiento) para el cierre mensual.
• Remuneraciones, honorarios, operaciones SII alimentan los datos que el F29GeneratorService consolida.
• Ingresos y Compras se cuadran contra el F29 vía retenciones e IVA.

Estas relaciones se documentan en cada destino, no aquí.