1. SCM with Barcode/RFID
  2. Features
  3. Stock requests
Feature · Stock requests

Stock requests

Keep demand, ownership, location and review state on the same request.

OverviewApproved requests
SCM with Barcode/RFID · Stock requests

Approved requests

Stock requests

New
Record numberSubjectStatusRequired byRequested unitsItem
SR-68586Approved sr-720Approved26 Oct870SI-4284
SR-44602Approved sr-728Approved04 Oct140SI-8528
SR-87529Approved sr-263Approved16 Oct880SI-7846
SR-94794Approved sr-140Approved10 Oct820SI-3198
SR-15744Approved sr-303Approved24 Oct720SI-5342
6 of 6 records
Approved sr-720Stock requests · SR-68586
Approved
Required by26 Oct
Requested units870
ItemSI-4284
LocationSL-130
Example screen with sample data

What you can do

Keep the request as the operating thread

A stock request starts with a record number, subject, needed date, requested units and a named owner. The item and location references tell the coordinator what stock is in scope. The organization reference keeps the request with the company or site responsible for it. A counterparty location can identify the other physical endpoint when a move is involved.

The coordinator uses the request as the parent for scans, movement records, attachments, review decisions and operation outcomes. Keeping those links together makes a later question answerable: which physical read supported this request, who reviewed its revision, and what stock effect was recorded? A status alone is a short summary; the linked evidence gives the reason behind it.

How the work is organized

  • Prepare demand. Inventory Coordinator enters the subject, requested units, due date, item, location and owner before asking for review.
  • Route a revision. Inventory Reviewer compares the current request with its attachments and records an approval, rejection or return with a reason.
  • Follow fulfillment. Inventory Coordinator checks the posted movements and reservations linked to the request before treating the work as executed.

A draft is work in preparation. Review tells the reviewer which request needs a decision. An approved request authorizes the next operating step; it does not by itself say that stock moved. Executed is the request outcome after the team checks the physical action and its recorded effect. Rejected and Cancelled keep their own meaning and history.

What to agree during setup

Agree on what a request number identifies across sites, who owns each location and how the team records a move between locations. Decide which attachments are needed for receiving, issue and correction cases. Define how the requested unit relates to the item’s base unit before comparing demand with stock. A request for cases and an item stored in pieces need an agreed conversion outside the request record.

The reviewer needs a clear rule for revision changes. If the coordinator changes the item, quantity or location after review, the team should submit the new revision for another decision. The decision record carries the source revision, reviewer, date and reason so people can distinguish a current approval from an older one.

Check the handoff on an actual case

Suppose a maintenance team needs replacement parts from a storage location by Friday. The coordinator enters the item, needed quantity, owner and date, then attaches the issue instruction. The reviewer reads the same request and decides whether the quantity and destination are justified. Once approved, the coordinator checks the lot and reservation before recording a scan or movement.

If the scanner reads a different tag, the coordinator keeps the request open for investigation. The team should not interpret an approved request as evidence that the parts left the location. The linked scan, movement and operation receipt carry those later facts.

What your team sees

  • Requests awaiting review — Requests whose current status asks for a review decision.
  • My stock requests — Assigned work organized by owner and needed date.
  • Active request board — Draft, review and approved requests grouped by status.

Follow the work through

Continue with request review and scan to movement. Use the data model when mapping existing item and location lists.

What it keeps track of

Data model
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.
Storage locations
Represents a physical place where stock is kept, so teams know where items are stored.
Team members
Represents a person working within an organization, used to assign roles and track activity.
Record attachments
Stores a file linked to another record, like a photo or document teams attach as proof.
Review decisions
Captures a reviewer's approval or rejection of a change, giving teams an audit trail of sign-offs.
Scan events
Records a barcode or RFID scan, letting teams confirm what was physically read and when.
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.
Operation receipts
Logs the outcome of an action taken on a record, so teams can confirm it actually went through.

Who uses it

Permissions
Inventory Coordinator
Prepares and follows requests.
Inventory Reviewer
Records decisions.
Auditor
Reads the resulting trail.
App Administrator
Maintains the organization and membership context.

Set up SCM with Barcode/RFID your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started