How automatic service pick works

How confirming a Service Order can automatically assemble the Service Picks and Return Lists for exactly the items that need vendor service — no manual hunting required.

Updated October 29, 2026

Confirming a regular Purchase Order doesn’t tell anyone which physical items to collect — it tells the warehouse goods are coming in. A Service Order runs the opposite direction: confirming it means specific tools and items already sitting in the shop need to go out to a vendor. Someone still has to work out which units those are, where each one currently is, and build a pick from that — normally by opening New Service Pick and choosing storage locations by hand, line by line (see Service Orders — Service Pick).

Automatic Service Pick removes that manual step. When an organization turns it on, confirming a Service Order runs the same search a person would — find what’s actually due for service, wherever it is — and builds the Service Pick (and, if a unit is out on the shop floor, a Return List to bring it back first) the moment the order is confirmed.

Turning it on

The setting lives in Manage Organizations → your organization → Preferences tab → Purchase Preferences → Service Orders, labeled Automatic creating Service Pick. It’s on by default for every new organization — confirming a Service Order runs this automation unless someone has turned it off, in which case a Service Pick still has to be built manually via New Service Pick, as described in the Service Order guide. It only applies to orders with the Service Order flag; it has no effect on ordinary Purchase Orders, which are covered separately by Automatic Purchase.

Knowing it’s on by default matters because this automation commits stock the moment the order is confirmed, before anyone has looked at what got picked. Shops that want a person to choose the collection locations instead — for example, when pickers are trusted to judge what’s genuinely worth sending back this trip — turn it off and keep using New Service Pick manually.

Two kinds of tooling, two different searches

The automation treats bulk items and serialized items differently, because they answer “does this need service?” in fundamentally different ways.

A bulk item (insert, generic holder — anything tracked only by quantity) has no individual identity. The system can’t ask “does this specific insert need service” — the shop floor already answered that question by physically sorting stock into locations, one per condition. So the only thing the automation can do for a bulk item is trust a For service stock rule to say where that sorted stock lives, and pick from there.

A serialized item (a specific cutting tool with its own ID) carries its own condition. It genuinely knows whether it needs service, independent of where it happens to be sitting right now. So the automation doesn’t need a rule to find candidates for a serialized item — it can check every unit’s own condition directly. A rule only becomes necessary afterward, to say where a unit should be sent if it isn’t sitting somewhere sensible already.

Picking bulk items

For a bulk item, the automation looks at every For service stock rule for that item within the order’s own warehouse, and takes what each rule’s storage location can actually spare — capped at what’s really on the shelf there, never more.

If those locations together can’t cover the full remaining quantity on the order line, the automation doesn’t shrink the number to match what it found. Instead, the last pick line it created absorbs the difference: its requested quantity ends up higher than what was actually reserved for it. That keeps the shortfall visible on the pick itself, as a line still waiting on stock, rather than letting a quietly-smaller number make an under-supplied order look complete — as long as at least one location had something to contribute. If every For service location for the item is completely empty, no pick line gets created for it at all, so there’s nothing on the Service Pick to show the shortfall; the gap only becomes visible once someone notices the item never showed up on any pick.

If a serviceable bulk item has no For service rule at all in the warehouse, the automation notifies the warehouse’s administrator, so the missing rule gets fixed rather than the line silently going unpicked. A non-serviceable item with no rule stays silent — there’s nothing to configure for an item that was never meant to be serviced.

Picking serialized items

For a serialized item, the automation looks at every unit currently flagged as needing service, at every shelf location or tool it’s currently sitting in — regardless of whether a stock rule covers that spot. (A unit resting directly on a machine, rather than loaded in a tool, isn’t something this automation acts on.) A unit already sitting on a shelf gets added straight to the Service Pick from wherever it is; no rule is required, because its own condition is proof enough that it belongs on this pick.

A unit still loaded into a Tool out on the shop floor is a different case: it first has to physically come back before anyone can ship it anywhere. So the automation creates a Return List to bring it from the tool to a proper For service storage location, and only then adds it to the Service Pick for that location — the pick line starts out waiting on the return to actually happen. The tool’s owner is notified once that return is actually created.

Choosing where to return a unit still depends on a For service rule — the automation has no way to invent a destination. If several rules exist for the item, it fills each rule’s location up to its Max Capacity before spilling into the next one, the same “never overfill a slot” principle Automatic Replenishment uses for restocking. If no For service rule exists at all for that item, there’s nowhere defined to send the unit back to — the automation notifies both the tool’s owner and the location’s administrator instead of guessing, or doing nothing. If rules do exist but every one of them is already full, the return simply doesn’t happen this run and nobody is notified — the unit stays in the tool, silently, until either room opens up or someone notices.

The same shortfall-absorption rule from bulk items applies here too: whichever pick line ends up being the last one built for an order line — whether it came from a shelf or from a tool return — carries any quantity that still couldn’t be found anywhere.

Not double-counting across lines

A single Service Order can list the same item on more than one line, and it’s possible to ask for more of an item, across all its lines combined, than physically exists. The automation processes an order’s lines in one pass and keeps track, in memory, of every unit and every quantity it has already committed to a pick as it goes — so a later line for the same item sees what an earlier line in the same run already claimed, and only reaches for what’s genuinely still free. Nothing gets reserved twice, and no physical unit ends up promised to two different lines at once.

What comes out of it

Every pick the automation builds is grouped by Warehouse Access Point — a Service Order whose items span several WAPs produces several Service Picks, not one pick with lines that different pickers don’t own. Each one is numbered from the organization’s Picklist sequence (the same numbering series regular production pick lists use) and carries a comment, signed by the user who confirmed the order, saying the confirmed Service Order created it, so it’s identifiable as system-generated in its history. From there it behaves exactly like a manually built Service Pick — a picker works through it, confirms quantities, and validates it — see Service Orders — Service Pick for what validating one does.

Who the documents belong to

Document	Belongs to
Service Pick	The administrator of the Warehouse Access Point it picks at
Return List, for units still in a tool	The administrator of the Warehouse Access Point where the tool is

When that administrator isn’t set, the document belongs to the administrator of the order’s warehouse, and failing that to the user who confirmed the order. Its creation comment is signed by the user who confirmed the order either way.