Search

How parts requests become postings

When a technician doesn't have a part on hand for a job, they request it instead of posting it directly. That request then leaves the Work Order screen and enters a queue someone else works from — and depending on whether the part is in stock, it can take one of two different paths before it ever becomes a cost on the job. This article explains that path: how a request stays tied to the job it was made for, what changes hands as it's fulfilled, and why the job it belongs to can't always close until the request is resolved. It's written for anyone who needs to reason about a job's parts, not just the person who requested or fulfilled one — a technician wondering why a job's cost hasn't moved yet, or a supervisor trying to understand why a job won't close, both need the same underlying picture. It does not explain how to fill in the request form or the posting dialog step by step — see Related tasks below — and it assumes you already understand what a Parts posting is (see Posting types).

A request is a placeholder, tied to the job it was made for

Requesting a part and posting a part are different actions. Posting a part immediately consumes it from a bin and adds its cost to the job. Requesting a part just records that someone needs it — the part number if it's known, a quantity, who's asking, and which job it's for — without touching inventory or the job's cost at all.

That last point, which job it's for, is fixed at request time and doesn't change. A request can only be created against a job that's still Open or In Progress, and every request carries that job's identifier from creation through to whatever eventually resolves it. This is what lets a request travel somewhere else entirely — a parts queue, a purchase order — and still land back on the correct job when it's finally posted.

A request also doesn't require the part to be something the shop already stocks. A technician can describe a part that isn't on file yet, with its own description and cost, and the request carries that information forward the same way it would carry a stocked part's part number.

The request leaves the Work Order and enters a shared queue

Once submitted, a request stops being something the technician manages. It shows up in a parts request queue — a single screen used by whoever fulfills part requests at a facility, independent of which Work Order screen (legacy or redesigned) the technician used to create it. This is the seam where the concept crosses from Work Orders into Parts and Purchasing: the job the part was requested for still exists back in Work Orders, but the decision about how to fulfill the request now happens somewhere else, by someone else, working from the request record rather than from the job.

Two different endings, depending on whether the part is in stock

From the queue, a request can be resolved one of two ways, and which one applies depends on whether the part is available.

If the part is in stock, fulfilling the request and posting it to the job can happen in a single action from the queue — choosing which bin to post from (or, for a part kit or an off-file part, posting immediately without a bin choice) creates the Parts posting on the job and closes the request in the same step. Alternatively, if whoever is working the queue doesn't post parts themselves, they can mark the request delivered instead — recording that the part physically changed hands, without creating a posting. Delivering and posting are deliberately separate actions: delivering something is not the same as accounting for its cost, and a request can be marked delivered well before anyone posts it to the job.

If the part is not in stock, the queue offers a different action entirely: creating a purchase order from the request. This hands the request off to Parts and Purchasing in a more literal sense — a vendor, a PO number, and (once created) a purchasing record now hang off the same request. The request doesn't disappear from the Work Orders side while this happens; it still carries the same job link it always did, waiting for the ordered part to arrive so it can be posted the same way an in-stock request would be.

Either way, only one thing actually changes the job's cost: a Parts posting. Everything else — the request existing, the part being marked ready or delivered, a purchase order being created — is groundwork that has to happen first, but none of it moves money onto the job by itself. If a job's cost hasn't updated even though a part was "requested" or is showing as available, that's expected — the posting step, described in Posting types and How postings affect costs, hasn't happened yet.

Why an unresolved request can hold a job open

A job's eligibility to close is checked against more than just its own postings — it also checks whether the job still has open part requests or open purchase order lines attached to it. That means a request that was never posted, or a purchase order that was created from a request but hasn't been resolved, can be the reason a job won't close even though every posting on it looks complete. This is the same reasoning covered in Job lifecycle and Work Order closure requirements — a request is one more thing, alongside open issues or an open inspection, that a job's close check accounts for.