Multi-Warehouse Inventory

Paid pluginsize Lplanned, not built

Indicative price, not an offer: EUR 300-600/year or EUR 800 one-off

Generated from docs/plan/paid/multi-warehouse-inventory/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Extends stock model to support multiple warehouses. Each product has stock per warehouse. On order placement, system reserves stock from optimal warehouse based on rules (nearest, cheapest shipping, fullest). Warehouses can be pickup locations or fulfillment hubs.

The problem

Syncing stock across 3 warehouses creates oversells, shortages, and cancellations. I need location-aware stock and intelligent allocation.

What it does

• Warehouse entity: warehouse_id, name, address, city, state, is_active, is_fulfillment_hub, is_pickup_location
• Stock per warehouse: Stock now has warehouse_id. Each product has Stock row per warehouse.
• Stock allocation logic: rules-based (nearest, cheapest shipping, fullest warehouse, or merchant-defined priority)
• Inventory sync: sync stock from ERP or warehouse management system (WMS) API; update all warehouse stocks daily
• Transfer between warehouses: staff can create transfer orders (move 10 units from warehouse A to B)
• Reorder point: set minimum stock per warehouse; alert staff when below threshold
• Warehouse fulfillment: when order ships from warehouse A, pick list shows ‘Warehouse: A’; shipment.warehouse_id recorded
• Multi-warehouse pick lists: orders routed to nearest warehouse; staff prints pick list per warehouse
• Cross-dock rules: if warehouse A is out, pull from warehouse B (and mark as cross-dock shipment)
• Backorder handling: if all warehouses out of stock, backorder; notify customer when restocked
• Return routing: returns ship to same warehouse order originated from (for QC)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Warehouse transfer automation: out of scope—staff manually create transfers. Reason: complex logic deferred.
• Multi-warehouse order consolidation: out of scope—orders split per warehouse. Reason: consolidation logic is complex.
• Cycle counting (inventory audit): out of scope. Reason: WMS responsibility.
• Cross-dock drop-ship (supplier direct to customer, not through warehouse): out of scope. Reason: deferred to dropship feature.
• Hazmat shipping (warehouse handling hazardous materials): out of scope. Reason: compliance is outside scope.
• Vendor-managed inventory (VMI): out of scope. Reason: supplier-specific; handled by inventory sync integration.

Data model

Migration: Warehouse table/collection (warehouse_id, name, address, city, state, is_active, is_fulfillment_hub, is_pickup_location, created_at). Stock now has warehouse_id (composite key: product_id + warehouse_id). Add warehouse_id to Shipment. AllocationRule table (rule_id, priority, condition JSON, warehouse_id_or_strategy). Transfer table (transfer_id, from_warehouse_id, to_warehouse_id, product_id, quantity, status, created_at).

API

• POST /warehouses (staff, body: {name, address, city, state, is_fulfillment_hub, is_pickup_location}) → {warehouse_id}
• GET /warehouses → [{warehouse_id, name, address, is_active, fulfillment_hub?, pickup_location?}]
• PUT /warehouses/:id (staff, body: {is_active, is_fulfillment_hub?, is_pickup_location?}) → {warehouse_id}
• GET /stock/:product_id/by-warehouse → [{warehouse_id, warehouse_name, quantity}]
• POST /warehouses/:id/transfers (staff, body: {to_warehouse_id, product_id, quantity}) → {transfer_id, status: ‘pending’}
• PUT /warehouses/:id/transfers/:transfer_id (staff, body: {status: ‘completed’ | ‘cancelled’}) → {transfer_id}
• POST /warehouses/allocation-rules (staff, body: {priority, condition, warehouse_id}) → {rule_id}
• POST /orders (body: {…, allocation_strategy?: ‘nearest’|‘cheapest’|‘fullest’}) → {order_id, warehouse_id}

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Warehouses section: list warehouses with fulfillment hub / pickup location badges, active toggle. Stock view tabbed by warehouse; each tab shows product stock, reorder point, last sync. Transfers section: create transfer (from/to warehouse, product, qty), list pending/completed. Allocation Rules section: define rules (if customer state=CA, use warehouse=West; priority 1).

The seam — why this is paid

Core owns warehouse entity, per-warehouse stock model, and basic allocation (nearest, fullest). Paid pack owns: complex allocation logic (ML-based optimization), transfer automation, multi-warehouse consolidation, hazmat compliance. Why: core provides honest single-warehouse per order; optimization and complex consolidation are paid.

Requires complex stock allocation logic, warehouse integrations, and fulfillment support. Core has single-location inventory.

Dependencies

• stock (stock model must support warehouse_id)
• click-and-collect-in-store-pickup (warehouses can be pickup locations)
• shipments-with-tracking-and-carrier-hooks (shipment records warehouse)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Warehouse ‘West Coast Hub’ created; is_fulfillment_hub=true; warehouse_id returned
• Product 123 has stock: warehouse_west=50, warehouse_east=30, warehouse_central=20
• Allocation rule: priority=1, condition={customer_state=‘CA’}, warehouse_id=west; CA customers pull from west
• Order from CA customer for product 123: stock reserved from west warehouse (50 -> 49); order.warehouse_id=west
• Transfer created: move 10 units from west to central; Transfer.status=‘pending’
• Staff completes transfer: status=‘completed’; west stock 49->39, central stock 20->30
• Reorder point set to 20; when stock falls below 20, staff sees alert in admin
• Multi-warehouse pick list: order split (items 1-2 from west, item 3 from east); staff see two separate pick lists
• All warehouses out of stock: order backorders; customer notified when any warehouse has stock
• Return order routes to original warehouse (west); reverse shipment records warehouse_id

Risks

Schema: stock now has composite key (product_id, warehouse_id); all queries must include both or data is wrong. Allocation: if allocation rule is misconfigured (all warehouses excluded), order allocation fails. Oversell: race condition if two orders reserve from same warehouse simultaneously; must use atomic transactions. Transfer: if transfer is lost in transit or inventory audit finds discrepancy, stock is wrong; reconciliation needed. Sync: if WMS inventory sync fails, stock is stale; orders might oversell when ‘fake’ stock allocated.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.