Provisiones en Sevastopol

Propósito

El dominio provisiones del frontend gestiona los ajustes contables de cierre cuando un documento (compra de existencias, activo fijo o gasto) se contabiliza en un período libro posterior a su fecha documento. La provisión hace que el resultado del período original refleje el devengo aunque el asiento operacional ocurra después.

Se materializa en ProvisionesGastosViewIsland — una única island con dos tablas separadas:

• Candidatos — compras detectadas con desfase doc/libro que todavía no tienen ajuste contabilizado.
• Ajustes — provisiones existentes con su estado (BORRADOR / CONTABILIZADO / REVERSADO).

A pesar de vivir bajo /api/inventario/, el alcance del subdominio cubre compras de las tres referencias (EXISTENCIAS, ACTIVO_FIJO, GASTO/GASTOS) — el endpoint es shared, no específico de inventario.

Decisiones de UX

Decisión	Motivo
Dos tablas separadas (candidatos vs ajustes)	Un candidato puede no tener ajuste aún; un ajuste puede existir sin candidato pendiente. Listar en una sola tabla mezcla dos preguntas distintas.
Filtros compartidos por ambas tablas	Año/mes documento, año/mes libro, tipo referencia y estado aplican a las dos. handleFiltrar recarga ambas en paralelo.
Contabilización masiva por filtro, no por fila	POST /contabilizar toma el filtro actual como criterio — el operador agrupa el cierre por documento/período sin marcar fila por fila.
Reversa atada al período activo del workspace	POST /reversar usa year/month de useActivePeriod. Evita que el operador reversa contra el período incorrecto por error.
Candidatos sin cuenta cargo se marcan “Sin cuenta” en rojo	El backend los omite del contabilizar y devuelve omitidos_sin_cuenta. La UI muestra la fila pero advierte que no entrará al asiento.
Toast resumen del POST	Ajustes contabilizados: N · Omitidos sin cuenta: M — el operador ve inmediatamente la efectividad del lote sin abrir el detalle.
Confirmación destructiva en contabilizar + reversar	Ambas son acciones masivas — confirm nativo antes del POST.
useActivePeriod inicializa filtros	Al montar o cambiar período se setean año_documento, año_libro y mes_libro desde el workspace. mes_documento queda vacío (el desfase es de varios meses típicamente).
Validación de año_documento en cliente	Number.isInteger antes del POST contabilizar. Evita rebote del backend.

Estados

Estado	Lectura
BORRADOR	Ajuste generado pero no contabilizado (caso raro — el flujo típico contabiliza inmediatamente).
CONTABILIZADO	Provisión activa: asiento generado en el período documento.
REVERSADO	Reversa registrada en el período libro activo; queda histórico.

Tipos de referencia

Valor	Cubre
EXISTENCIAS	Compras de inventario (mercaderías).
ACTIVO_FIJO	Compras de activo fijo capitalizable.
GASTO / GASTOS	Compras de gasto operacional (alias histórico — ambos valores se aceptan).

Datos visibles

Tabla de candidatos

Columna	Origen
Fecha Doc	fecha_documento.
Doc / Libro	año_documento-mes_documento → año_libro-mes_libro — visualiza el desfase.
Tipo	referencia_tipo.
Proveedor	RUT + razón social.
Monto Neto	monto_neto.
Cuenta Cargo	Código o “Sin cuenta” en rojo.
Estado	Provisión actual (si existe).

Tabla de ajustes

Mismas columnas que candidatos, más:

Columna	Origen
Reversa	reversa_año-reversa_mes + fecha_reversa cuando estado es REVERSADO.
Notas	Glosa del ajuste.
Fecha creación	created_at.

Lenguaje compartido

ProvisionesGastosViewIsland usa los tokens del ContabilidadWorkspace:

Componente	Uso
ContabilidadWorkspaceHeader	Header con pills y controls.
WorkspaceSectionCard	Una sección por tabla (candidatos + ajustes).
InlineMetricPill	Métricas por sección (total, monto, contabilizados, reversados, borrador).

Hooks

Hook	Uso
useActiveTenant	Recarga candidatos + ajustes al cambiar tenant.
useActivePeriod	Inicializa filtros de año/mes; el period activo es destino de la reversa.

Endpoints

Método + ruta	Uso
GET /api/inventario/provision-ajustes/candidatos?tenant_id=&año_documento=&mes_documento=&año_libro=&mes_libro=&referencia_tipo=	Compras candidatas a provisionar.
GET /api/inventario/provision-ajustes?tenant_id=&...&estado=	Ajustes existentes filtrados.
POST /api/inventario/provision-ajustes/contabilizar?tenant_id=	Contabilización masiva por filtro. Body: { año_documento, mes_documento?, año_libro?, mes_libro?, referencia_tipo?, estado: "CONTABILIZADO" }.
POST /api/inventario/provision-ajustes/reversar?tenant_id=	Reversa contra period activo. Body: { año_libro, mes_libro }.

Backend de referencia

Inventario (Orchestrator) — InventarioService y ComprasInventarioService exponen los endpoints provision-ajustes/*. El criterio de candidato (compra con fecha_documento < período libro) se aplica server-side.

Relación con otros dominios

• Gastos, Inventario, Activo Fijo alimentan las compras que terminan como candidatas — el referencia_tipo decide qué cuenta de gasto/activo se afecta.
• Ciclo contable lee provisiones contabilizadas como parte del cierre del período documento.
• Operaciones SII es la fuente original — todas las compras vienen de F29/RCV.

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