These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- SCM with Barcode/RFID
- Features
- Reservations and movements
Reservations and movements
Trace stock claims separately from posted changes in quantity.
OverviewActive reservations×
SCM with Barcode/RFID · Reservations and movements
New
Active reservations
Stock reservations
| Request | Item | Location | Lot | Quantity | Expires at | |
|---|---|---|---|---|---|---|
| SR-25919 | SI-7301 | SL-110 | SL-8115 | 620 | 23 Oct | |
| SR-52646 | SI-5858 | SL-110 | SL-3950 | 720 | 24 Oct | |
| SR-78787 | SI-5936 | SL-130 | SL-3654 | 140 | 11 Oct | |
| SR-41546 | SI-1342 | SL-110 | SL-6585 | 720 | 10 Oct | |
| SR-84816 | SI-5724 | SL-120 | SL-1491 | 170 | 08 Oct |
6 of 6 records
SR-25919Stock reservations · SR-28128
ItemSI-7301
LocationSL-110
LotSL-8115
Quantity620
Expires at23 Oct
What you can do
Separate a claim from a quantity effect
A reservation identifies quantity held for a request, item and location, with an optional lot. Its state can be Active, Released or Consumed, and it carries an expiry date. A reservation tells the coordinator what is spoken for. It is not itself a stock movement.
Stock movements carry a signed quantity, posting flag, time, item, location, lot and parent request. These records are the history used to reconstruct physical stock. A movement can link through Reverses to an earlier movement when the team needs a compensating correction. Keeping the original entry gives reviewers the full trail of what was first recorded and how it was corrected.
How the work is organized
- Check availability. Inventory Coordinator compares posted movements with active reservations for the exact item, location and eligible lot.
- Hold the scope. The coordinator records a reservation against the approved request, with quantity and expiry.
- Record the effect. The team links a signed movement to the request and checks whether it is posted before treating it as on-hand history.
The request’s approved quantity, the reservation’s quantity and the scan’s observed units can differ during partial work. The coordinator must compare them explicitly. For a move between locations, the signed effects should show where quantity left and where it arrived. A request status alone cannot stand in for those movement entries.
What to agree during setup
Define how stock is calculated from posted movements, including the sign used for receipts and issues. Decide how active reservations reduce available quantity, and who can release a claim when a request is rejected or cancelled. Set a policy for reservation expiry. The team should also decide how to handle a partial issue: the consumed part and the remaining claim need clear records.
Agree on a source effect key for a physical action so retries can be recognized. Define when a movement becomes posted and who reviews a correction. A reversal should point to the exact original movement and record only the allowed remaining scope. If a count finds a difference, keep the count evidence with the request and review it before posting a compensating quantity.
Check the handoff on an actual case
A request needs twenty units from a specific location. Ten are already promised to another request. The coordinator reads the posted movement balance and active reservations before claiming the new quantity. After approval, a reservation records what is held for this request. A physical scan confirms the item and units actually handled.
If only part of the quantity leaves, the movement records the signed amount that did leave. The reservation state and quantity need to reflect the remainder rather than implying full consumption. If that movement was wrong, the reviewer can inspect the scan and attachment, authorize the correction and link a compensating movement to the original. The posted history then explains the net balance without erasing the mistake.
What your team sees
- Active reservations — Current claims with quantity, location, lot and expiry.
- Posted stock movements — Posted effects with request and stock references.
- Approved requests — Reviewed demand ready for controlled stock work.
Follow the work through
Use scan to movement for the issue case and reconciliation when an effect is uncertain.
What it keeps track of
Data model- Stock reservations
- Holds inventory set aside for a specific request so staff know what's already spoken for.
- Stock movements
- Logs a change in stock quantity, giving teams a running history of what moved and when.
- Stock requests
- Represents a request for stock that teams create, approve, and fulfill from start to finish.
- Stock items
- Defines a product or material teams stock and track across locations and lots.
- Stock lots
- Tracks a batch of stock sharing an expiry and origin, letting teams follow it through storage.
- Storage locations
- Represents a physical place where stock is kept, so teams know where items are stored.
- Scan events
- Records a barcode or RFID scan, letting teams confirm what was physically read and when.
- Review decisions
- Captures a reviewer's approval or rejection of a change, giving teams an audit trail of sign-offs.
Who uses it
Permissions- Inventory Coordinator
- Manages requests and records the stock work.
- Inventory Reviewer
- Examines eligibility and corrections.
- Auditor
- Reads the linked history.
- App Administrator
- Maintains the stock catalog.
Set up SCM with Barcode/RFID your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.