Matriz: tipos de documento e inventario

Referencia para alinear getInventoryOperation (documentInventoryService.js), el kardex (getProductMovements en inventoryMovementController.js) y INVENTORY_TYPES en updateDocument (documentController.js).

Operación de inventario por tipo (getInventoryOperation)

Tipo	Operación add / reduce / none	Notas
103	add	Compra
104	add	Importación (costo importCostEnd preferido)
01, 112	reduce	Venta / entrega
06	add	Nota de crédito (reingreso)
07, 105	reduce	Nota de débito / devolución según caso
106	add	Ajuste (cantidad con signo en línea)
100, 101, 102, 11, 113, 114, 115, 05, 107, 108	none	Sin movimiento de inventario en este servicio

Tipos no listados en el switch lanzan error (“Tipo de documento no soportado”).

Momento de aplicación al crear documento

• Tras crear líneas, si no hay análisis IA, se llama processInventoryUpdate (mismo archivo servicio).
• Con IA, el inventario puede aplicarse al confirmar según confirmDocument (no duplicar con el alta).

Edición de documento (updateDocument)

• La constante INVENTORY_TYPES = ['103','105','106','07'] solo incluye tipos que este endpoint permite editar y para los que tiene sentido revertir/reaplicar stock en la misma transacción.
• No incluye 01, 104, 112, etc.: esos flujos fiscales/ventas no pasan por la misma edición de líneas; cambiar ahí sin actualizar esta lista produciría desfase stock–documento.

Movimientos manuales

• Tipos: ingreso, salida, transferencia, revalorización (ver inventoryMovementController.js).
• Bundles en catálogo: rechazados en movimiento manual; en documentos se expanden a componentes.

Conciliación y kardex

• La reconciliación de stock (getStockReconciliation) y el kardex unificado deben usar la misma noción de “documento que aplica stock” que el literal SQL en getProductMovements (confirmación, wasUnconfirmed, IA en 103).

Última actualización: alineada con la implementación del backend en el repositorio (revisar el código ante cambios de tipos o reglas de confirmación).