Warehouse & Inventory Management

Why this is a runtime problem, not a CRUD problem

A warehouse operation moves goods across dozens of locations, tracks lot expiry dates for FEFO picking, enforces approval workflows for cross-warehouse transfers, and must reconcile physical counts without freezing the system for everyone else. The flow is receive → putaway → pick → pack → ship, with a stock-count cycle running in parallel — and every step needs permissions scoped to the right warehouse, audited, and capable of triggering downstream finance and production.

A simple data-app builder gives you screens but no stock balance update logic. A rigid packaged suite has the logic but resists the pick-strategy, lot-tracking, and zone rules that vary per operation. AuraBoot is the third path: the confirm commands enforce balance updates atomically; the permission model scopes each operator to their warehouse; and the same command definitions are reachable from UI buttons, BPM flow tasks, and AI agents.

Material flow overview

  Supplier / Production
         |
         v
  +------+----------+       +------------------+
  |  wh_inbound_order|-----> |  putaway to      |
  |  (receive)       |       |  wh_location     |
  +------------------+       +--------+---------+
                                      |
                               wh_stock (balance)
                                      |
               +-----------+---------+----------+
               |           |                    |
               v           v                    v
      wh_pick_order   wh_stock_count      wh_outbound_order
      (pick & pack)   (cycle count)       (ship / issue)
               |           |                    |
               v           v                    v
         Outbound      Adjustment          Customer /
         confirmed      committed          Production

The stock-count cycle runs continuously: a wh_stock_count document is created for a location set, operators record actual quantities, and wh.stock.count.commit reconciles the balance — requiring a second sign-off when the adjustment value exceeds the configured threshold.

Data model summary

The warehouse solution ships as a single com.auraboot.inventory plugin. Core models:

• wh_location — Hierarchical storage location with zone type (receiving / storage / picking / packing / shipping), capacity, and pick priority.
• wh_stock — Real-time balance per product per warehouse: qty, available_qty, reserved_qty, safety_stock, avg_cost. Updated atomically by confirm handlers — never by direct writes.
• wh_inbound_order — Receipt header; states draft → confirmed. Confirmation triggers wh.inbound.receive, which increments wh_stock balances.
• wh_outbound_order — Issue header with type (sales / production_pick / return / outsource); confirmation decrements balances.
• wh_pick_order — Fulfilment task; states pending → in_progress → completed. Lines track per-location, per-lot quantities.
• wh_stock_count — Physical count document; states draft → pending → confirmed. Commit handler reconciles system vs. actual quantities and posts an adjustment.
• wh_lot — Lot or serial number with expiry, manufacture date, status (active / quarantine / expired / scrapped), and full transaction history.

Key commands

A "Confirm Receipt" button is wired to wh_inbound_order.confirm — not to a raw PUT request. The same command is reachable from a BPM inbound task and from an AI agent acting on behalf of a receiving clerk, subject to the same permission checks.

Permission example

A realistic warehouse role: "Warehouse Operator — East DC".

• RBAC (Layer 3 — org scope): granted wh.inbound.receive, wh.outbound.issue, wh.pick.execute; visibility scoped to the East DC warehouse subtree only. Operators at a different site see no records.
• ReBAC (Layer 2 — SoD): wh.stock.count.commit for adjustments above the configured value threshold requires a second sign from a different user. The operator who submitted the count cannot be the one who commits it.
• Field masking (Layer 5): inv_bal_avg_cost and inv_bal_amount (moving-average cost and stock value) are masked for warehouse operators. Finance and inventory managers see the full row.
• ABAC (Layer 4 — attribute): wh_transfer.approve requires an explicit cross-warehouse grant attribute. An operator scoped to East DC cannot approve a transfer sourced from West DC even if they hold the wh.transfer.approve permission code.

All four constraint layers are evaluated in order on every command execution. A single declarative role definition covers what would otherwise be per-screen branching in the UI and per-endpoint guards in the controllers.

Process orchestration

Stock-count and transfer workflows are modeled as BPM processes:

  Stock-count process
  -------------------
  Count draft created
         |
         v
  Operators fill actual qty  <-- wh_stock_count_line updates
         |
         v
  wh_stock_count.submit  -->  status: pending
         |
         v
  Manager review
         |
         +-- approve -->  wh.stock.count.commit  -->  wh_stock adjusted
         |
         +-- reject  -->  back to operators

  Cross-warehouse transfer
  ------------------------
  Draft created  -->  submit  -->  Pending Approval
         |
         v
  wh_transfer.approve  (requires cross-warehouse grant)
         |
         v
  Approved  -->  wh_transfer.confirm  -->  balances moved

The BPM engine carries the state lock between steps, so a concurrent receipt at the same warehouse does not block the count workflow.

Agent integration

Three command classes are intentionally exposed to AI agents:

1. Read-only (wh_stock.list_below_safety, wh_lot.list_expiring_soon) — idempotent, low risk; agents can call freely to surface alerts.
2. Drafting (wh_inbound_order.create_from_po) — write, idempotent, reversible; agent creates a receipt draft from a purchase order reference; human confirms.
3. Operational nudges (wh_lot.flag_for_quarantine_review) — write, idempotent; agent detects an anomaly and opens a review task; cannot execute the quarantine itself.

What is not exposed: wh.stock.count.commit (SoD constraint), wh_lot.scrap (irreversible), and wh_transfer.approve (requires cross-warehouse ABAC grant). These carry agentHint: "Human-only" in their definitions.

Enterprise note — Wave-picking orchestration across multiple DCs, advanced lot genealogy tracing (full supply-chain upstream/downstream), compliance export for regulatory audits, and the Observability Pro per-command trace spans are commercial-only capabilities. The open-core runtime described above is the same in every edition.

How to get it

• Community: build your own warehouse plugin using the open-source command pipeline, model DSL, and permission framework.
• Standard: white-label the base platform and add your own warehouse-shaped plugins on top.
• Professional: get the inventory solution package — pre-wired models, commands, menus, roles, and dashboard.
• Enterprise: same package plus delivery engineering, compliance export, ERP/MES integration design, and SLA-backed support.

See Pricing for the full edition comparison.

Next steps

• System overview — how plugins, commands, and the runtime fit together
• Command pipeline — the execution contract used by every confirm command above
• Permissions — the five-layer model used by the Warehouse Operator role
• Plugin manifest — how a solution package declares its plugin dependencies
• Agent readiness — designing agentHint and risk fields for safe execution