Las transferencias mueven stock de una ubicación de origen a una de destino. Todos los endpoints de este recurso requieren el permiso inventory:transfer.
Lee la sección de semántica de escritura antes de integrar
El momento exacto en que el stock se mueve, y las garantías (o falta de ellas) sobre el estado de una transferencia, son el detalle más importante de este recurso. Están descritos abajo con el comportamiento real de producción — no es el diseño ideal, es lo que el sistema hace hoy.
POST /inventory/transfersno mueve stock. Únicamente crea el registro con status: 'pending'. El stock se mueve exclusivamente al recibir la transferencia (ver abajo).
Esto es lo único que mueve stock en el ciclo de vida de una transferencia. Por cada ítem recibido:
El stock de origen se decrementa por reassignAmount, con el resultado forzado a un mínimo de 0 — si el monto excede el stock disponible en origen, la resta se satura en 0 en lugar de rechazar la operación. No se produce ningún error visible por este sobre-envío.
El stock de destino se incrementa por el mismo reassignAmount.
Internamente se intenta consumir/crear lotes FIFO para mantener la trazabilidad de costos; si esa parte falla, la recepción no falla — el error de lotes se registra como advertencia y la petición responde 200 igual.
La recepción NO emite el evento 'Inventory Updated'
A diferencia de la escritura directa de stock (PUT, bulk-update, ajustes), la recepción de una transferencia mueve el stock por una ruta distinta que no dispara el evento Inventory Updated ni la verificación de stock bajo. Si tu integración escucha ese evento para reaccionar a cambios de stock, no verá los movimientos causados por transferencias recibidas.
Sin guarda de transición de estado — una transferencia puede recibirse dos veces
No existe una verificación de que la transferencia esté en el estado correcto antes de aprobar, recibir o cancelar. Esto significa, en el comportamiento actual de producción:
Puedes llamar receive sobre una transferencia que ya está en received — el movimiento de stock se vuelve a aplicar, duplicando el efecto.
Puedes cancel una transferencia que ya fue received.
La operación receiveno es idempotente: reenviar la misma petición reaplica el delta de stock cada vez, porque no hay clave de deduplicación.
Tu integración es responsable de no reintentar receive a ciegas y de rastrear localmente el estado antes de volver a llamarlo.
Cancelar no revierte ningún movimiento de stock ya aplicado por un receive previo — solo cambia el campo status. Si ya recibiste la transferencia y luego la cancelas, el stock movido permanece movido.