Warehouse Management System Applet

Run the physical side of a warehouse: receiving, putaway, what sits on which shelf, and picking and packing for sales orders. Nothing here moves stock or posts. The balance changes only when the stock transfer a packing list creates is finalised in the Stock Transfer applet; a delivery order it creates moves no stock even when finalised — the goods leave on the sales invoice or other stock-out document — and building a picking list reserves nothing.

Your job, and the screen for it

Overview

The Warehouse Management System applet is the physical-fulfilment layer that sits between a customer order and the document that actually moves stock. It records goods arriving at a warehouse (Receiving Doc), works out which container and which shelf they go to (Processing Queue and Putaway), keeps the map of what is stored where (Space Container Allocation), and drives picking and packing for orders that have been pushed to the warehouse from the Sales Order (Internal) applet.

It is opened by warehouse staff, supervisors and the administrator who sets up the warehouse structure. Nothing in this applet posts a journal or writes an inventory transaction line. The last step of the outbound flow converts a Packing List into a generic document — an Delivery Order (Internal) or an outbound Stock Transfer — and that document is finalised in its own applet. Stock only moves there.

The applet keeps its own records, its own warehouse/layout/node hierarchy and its own WMS item register. These are separate from the company/branch/location tree owned by the Organisation applet and from the stock balances owned by Stock Balance.

This is the heavier of two ways to run fulfilment in BigLedger. The lighter one needs none of this: a generic document can carry its own delivery and packing state in its own columns, and many businesses never model a warehouse at all. Read Which queue am I looking at? before you conclude that a screen or a column somebody has described to you is one of these.

Where it fits

The warehouse floor: the applet plans, the documents post

The Warehouse Management System applet runs the physical work and keeps its own records of it: what arrived, which container went to which shelf, what was picked and packed. It writes no stock line and no journal. That is the design: the warehouse works at the speed of the floor, and the stock ledger changes only when a document someone can review is finalised.

What the floor team should know before go-live:

Screens and menus

The applet’s sidebar is:

Two routes exist with no menu entry: space-container-allocation-report (the Report item under Container Allocation is not shown in the menu) and everything under settings that the shared settings sidebar does not link (below).

The Settings area shows the applet’s own System Configuration group plus fixed Server Side Permissions and Developer Tools groups:

Configuration

Before you can use it

Applet settings

Settings are applet-local — this applet has a settings screen of its own rather than the shared one — and the screen is labelled Application Settings in the sidebar.

All eighteen controls are written together by one SAVE button and stored as one applet-settings record. Every control starts empty, so the default for every row below is off / unset until the tenant saves the screen once. The rows are grouped below by tab, in the order you would set them up.

Anyone who can open Settings can change them; they are tenant-wide, not per branch and not per user.

Inbound Process tab: receiving and containers

Inbound Process tab: switches with no effect

Outbound Settings tab: from picking list to packing list

Outbound Settings tab: scan modes

Outbound Settings tab: defaults for delivery orders and stock transfers

Keys read without a control on this screen

Two keys are read at runtime without a control on this screen:

• DEFAULT_LOCATION — loaded by the Receiving Doc create screen and by Space Container Allocation create/edit, which merge the personal value over the applet value, and then read by nothing: no field on those screens or anywhere else in the applet is pre-filled from it. The only screens that write it are the two Default Selection screens described below, and neither works.
• ENABLE_BRANCH_FILTER — not on this screen, and no screen in this applet saves it, but it is read. If the applet’s settings record carries it switched on (written through the API, for example), picking a supplier on a Receiving Doc’s Account tab is refused with Supplier not linked to branch unless that supplier is linked to a branch, and picking a customer on a Packing List’s Account tab is refused with Customer not linked to branch in the same way. The check is “linked to any branch”, not to the document’s branch. If you see either message, that key is the cause.

Default Selection (applet and personal)

Settings › Default Selection and Personalization › Default Selection render Default Branch and Default Location drop-downs.

Settings in other applets that control this applet

Who can change what

• Feature Visibility is a stub. The screen shows one Teams panel with three placeholder options (Team 1, Team 2, Team 3), an add button and a SAVE button, none of which does anything. Nothing it shows is saved, and nothing in this applet reads a feature-visibility value.
• No client-side permission codes exist for this applet. Menu items and buttons are therefore not gated per role from inside the applet, and Applet Access has nothing to grant.
• Server-side permissions are the standard shared screens (Permission Wizard, Permission Set, User Permission, Role Permission). This applet additionally offers the Warehouse target view, so a permission can be scoped to specific warehouses, listed by Warehouse Code and Warehouse Title.

Fields

Nearly every form in this applet asks for a code, a name, a description, a status and a date, and does with them what you would expect. This section names what each screen captures — so you can tell at a glance whether it holds the thing you need — and tables only the fields that behave in a way the screen does not show.

Warehouse, layout and node

A Warehouse captures code, title, description, status and type; all but description are required. A Layout belongs to one warehouse and captures name, code, floor, description and status. A Layout Node — your zone, rack, shelf or bin — captures node name, node type, status, a scan code, a parent node, and a position, a size and a maximum weight.

The node type comes from the warehouse’s Node Setting tab: there you define, once for each warehouse, the kinds of space it has — a name, a type, a height, width and length, and a maximum weight — and each layout node you create picks one of them from that list.

Receiving Doc and its lines

The Receiving Doc header captures Doc No (disabled — the tenant numbering fills it), Warehouse, Transaction Date, PIC, Reference, Description, Tracking ID and a record Status. A Receiving Line captures the item, quantity, UOM and a tracking ID. Opened from Receiving Line or from a line-link form, it adds one Serial Number, Batch Number or Bin Number tab, whichever matches the item’s sub-item type; the line form inside the Receiving Doc editor has Item Details only. Editing an existing header adds Account, Lines, Generic Document, External Generic Document and Attachments. The create screen has only Main Details (its Lines and GenDoc tabs are commented out), so lines are added after the first save: CREATE saves the header and opens it in the editor, where the Lines tab is.

Serial numbers may be typed, scanned, or imported with a delimiter (required on the import dialog). Batch Number wants Batch No, Qty, Issue Date and Expiry Date, all required.

Container, picker, picking list and packing list

A Container captures a code, a name, a split quantity, a type, four dimensions, a scan code and a description — and validates none of them. A Picker links a warehouse to an entity from Employee, with the contact details shown for convenience. A Picking List wants a picking date, a picker and a warehouse; a Packing List wants a packing date, a packer and a warehouse, plus free-text reference, tracking, description and remarks, and its Account tab will not save without a customer entity.

Packing List → Stock Transfer (Doc Conversion tab)

Company, Branch, From Location, To Location and Transaction Date are all required; Tracking ID and Description are copied onto the document as its tracking ID and remarks.

Space Container Allocation and the WMS item register

Space Container Allocation has a scratch Scan Code box that searches containers and spaces by their scan codes and fills the rest of the form; the container and space fields it fills are required. The WMS item register captures warehouse, item code, name, type, UOM, description and status, none of them validated, with read-only audit fields. WMS Item Category and WMS Item Category Group both require a category code and name, and the group form additionally requires a parameter code and parameter name.

A WMS item is a separate record from an inventory item and from a financial item. Receiving lines can point at any of the three, which is the flexibility the register exists for — a pallet of shop fittings that no one sells has a place to live — and also the reason the outbound scan behaves differently depending on which one a line used.

Lifecycle and effects

Which queue am I looking at?

BigLedger has several queues that all describe “work waiting to be done to a document”, and they are different tables with different writers and different logic — not one queue seen from different screens. Getting this wrong is the commonest way to read a warehouse question and answer a manufacturing one. The whole set, so the index is complete:

Three consequences of that table are worth stating plainly, because none of them is visible from any screen.

The finance-side queue and this applet are not the same product decision. Queueing work for picking on the document — its own pick/pack flag, packing status and delivery-tracking fields — is the lighter of the two paths, and it needs none of the warehouses, layouts, nodes and containers below. This applet is the heavier option you move to when you want the physical warehouse modelled. If you are comparing notes with another BigLedger user about “the pick pack queue”, check which of the two you are each looking at before you conclude anything.

A warehouse-side queue row is a pointer, not a copy. A Picking Queue row holds a reference to the document and the line, a document type, a base quantity, a balance, a priority, a running number and a customer branch — and no item, no company, no branch, no location and no warehouse. Everything else on the Picking Queue is joined back from the generic document at display time. That is why the listing can only show one document type, why nothing filters the queue by warehouse, and why a picking list built from it has no warehouse on it. It also means the push moves work by document: every queued line of a selected document goes across, not only the lines that were ticked.

The balance is held as text on the warehouse side. Nothing in the applet is harmed by that, but a report that sorts or compares this column sorts it as text, where "10" comes before "9".

The sales-side queue carries a queue type whose two values are MRP and WMS — apparently the discriminator that says which downstream queue a row is destined for. Nothing in the backend decides anything from it, nothing sets it and no query filters on it, so it is not populated. Your own integration can read it, but do not filter or report on it.

The figure behind each queue screen

Every count and quantity in this applet is a stored row that one action wrote, read back when the screen loads — except the two stock columns on the Picking Queue, which are the stock ledger’s stored balance rows. None of them is recalculated from anything else, so each is exactly as current as the last action that wrote it.

The warehouse and the stock ledger answer different questions, and disagree on purpose. No record in this applet writes a stock ledger line; the ledger’s balance at a location changes only when a stock-moving document — a sales invoice, a stock transfer, a stock adjustment — is finalised, and its balance row follows a few seconds later when the balance job has run. So between packing and invoicing, Stock Balance still counts goods that are sealed in a carton by the door, and a unit found missing on the shelf stays in Stock Balance until somebody posts an adjustment. Use the warehouse screens for where it physically is and what has been picked; use Stock Balance for what the books say you hold at that location; and use the Stock Movement Report in Stock Report when you need to know which document changed it, and when.

Posting proof

Both documents this applet creates are written with an amount signum and a quantity signum of 0 on every line. What happens to stock is decided later, when the document is finalised in its own applet:

Inbound

1. Receiving Doc is created as DRAFT (the only two posting statuses are DRAFT and FINAL). The FINAL button on the editor is disabled while the header has no lines.

2. FINAL sets the header’s posting status to FINAL and creates the processing-queue rows — but which rows depends on where you pressed it and on one setting. See the callout below; this is the single most consequential thing on the page.

   FINAL is not one-way. Nothing on the server checks whether the document is already FINAL, so pressing it a second time creates the processing-queue rows a second time — and on the auto-allocation path, a second set of containers. The listing offers a tick box only on DRAFT rows, but the FINAL button inside the editor stays enabled on a document that is already FINAL (it is disabled only while there are no lines). Look at the posting status before you press it; if the Processing Queue shows every line of a receiving document twice, that is what happened, and the extra rows and containers have to be cleared by hand.

3. Processing Queue. Allocating a container updates the queue row and the container. The remaining balance is calculated by the screen and sent to the server, which stores whatever it is given; when it arrives at zero or below, the queue row is permanently deleted — not soft-deleted, not archived — and only the container is updated. Once it has gone there is no record in this applet of what was allocated against that receiving line.

4. Putaway. Pushing a container into the putaway list creates a putaway row plus a putaway processing-queue row. Process status is PLANNED_ALLOCATION when the container already has a layout node, and PENDING_ALLOCATION when it does not.

5. Slotting a container creates the container ↔ node link, sets the putaway row to COMPLETED_ALLOCATION, and deletes the putaway processing-queue row. If you slot by Scan Session, this step happens later, in a background job — see below.

Space Container Allocation writes the same link row directly, without going through putaway.

Scan Session: slotting happens later, in a background job

The Scan Session screen does not slot anything. Each scan is stored as a queued row with status UNPROCESSED, and that is all the screen does. The rows are worked by a background job, the warehouse container–space scan-session processor, which runs only when a clock for it is set up in the Scheduler applet. No such clock is installed by default, so until you add one, a scan session is a list of scans that nothing ever acts on. Each time the clock fires, the job takes up to ten open sessions and, for each:

• decides whether a scanned code is a space or a container by looking for the text Node_ or Container_ inside it — your node and container scan codes must carry those prefixes for this screen to work at all;
• finds the matching putaway task, or failing that the node or container itself, creates the container ↔ node link and deletes the matched putaway task;
• marks every row of the session PROCESSED.

A code with a prefix that matches nothing is marked PROCESSED with the reason in Remarks. A code with neither prefix is marked PROCESSED with an empty Remarks and nothing else happens — it looks exactly like success. (Read from the code, not tried.)

How to check: open the session’s scan list. Rows still UNPROCESSED after a few minutes mean no clock is running the job. Rows PROCESSED with no remark but no new link in Container Allocation mean the scanned codes lacked the prefixes. If your labels are printed without them, use Container Allocation › Listing to link containers to spaces instead — it looks codes up exactly, with no prefix rule.

Outbound

1. Order lines arrive in the Picking Queue only when someone presses Send to Warehouse Picking Queue in the Sales Order (Internal) applet. That call copies each queued row for the selected documents and removes the sales-side row, so the same work is never in both queues and the sales side stops showing it. The deletion is conditional on the copy having succeeded, which is worth knowing because the next step is not.

2. Picking Queue lists those rows joined to their generic document, with the ledger quantity from the location and company stock balances beside each line. It only ever asks for sales orders, so only sales orders are shown regardless of what else was pushed in — and the group heading over them reads Sales Invoice No although the numbers under it are sales order numbers. The orange Qty To Deliver column accepts a number up to Qty Pending and is never sent anywhere: the next step reads only which rows you ticked.

   Nothing in the flow checks availability, so that check is the supervisor’s, before the next step: compare Qty Pending with Location Balance, remembering that the balance still counts goods packed but not yet invoiced.

3. Create Picking List groups the selected queue rows by source document header and creates one picking list per header. Three things it does that the screen does not say, and one reason to use it:

   • It walks every line of that document, not only the lines you selected, and sets the quantity to pick from the line’s full ordered quantity — the queue’s remaining balance is never consulted. A partly shipped order is re-picked in full.
   • Quantity to pick and quantity picked are whole numbers, so a fractional quantity is truncated.
   • It sets neither the picker nor the warehouse on the new header, though the Create form requires both. Lists made this way arrive blank in both columns, and a warehouse filter will not find them.
   • Build picking lists here, not with the Picking List screen’s own Create. A list created by hand can link sales-order lines on its Lines tab, but its Generate Picking Sequence button does nothing, so nothing on these screens gives the list the picking lines that Add all to picking cart copies into a cart. BigLedger is tracking this.

4. Picking is recorded on the carts, not on the list’s lines. Add all to picking cart (or Add selected to picking cart) on the Lines tab copies each line into a cart row with its quantity to pick and nothing picked; the picker then types Qty Picked on the Add to Cart tab (it refuses more than the quantity to pick; the tab is hidden while ENABLE_MANUAL_CART_SCAN is on), or a container scan puts the container’s whole content in the cart and empties the container. The Lines tab’s own Qty Picked is written as 0 when the list is built and nothing changes it later.

   A cart row also claims its item: adding the same item to another list’s cart opens a conflict dialog naming the list that holds it, and confirming moves that list’s cart row to its Discarded Carts. Nothing releases the claim when a list goes to packing, so the dialog appears for the next list with that item; when the list it names is already IN_PACKING_STATION, confirming is safe, because its packing lines already exist (read from the code, not tried).

5. Send to packing creates the Packing List and sets the picking list’s packing status to IN_PACKING_STATION. The packing list’s lines are built from the picking list’s active carts, each carrying the cart’s quantity picked, so a short pick arrives at packing already short. The guard that should refuse a list with no carts at all never fires: such a list goes to packing as an empty packing list (read from the code, not tried).

   Consolidated Packing List is a separate action that merges several picking lists into one packing list; it refuses lists for different customers (“Mismatching entities found in picking lists.”) or different warehouses (“Mismatching warehouses found in picking list.”). Packing list lines start UNPACKED and become PACKED as they are scanned or converted in bulk.

6. Conversion. From the Packing List listing, Create DO consolidates the selected DRAFT packing lists into one Delivery Order and requires every selected header to name the same customer; Batch Process DO creates one per packing list using DEFAULT_PRICING_SCHEME. Create DO carries over only lines whose packing status is PACKED; Batch Process DO and the Stock Transfer conversion copy every line, UNPACKED ones included, and nothing stops the same packing list being converted twice — check the draft before you finalise it. BigLedger is tracking this.

   From the Doc Conversion tab, a Packing List becomes an outbound Stock Transfer. Both are written with posting status DRAFT and linked back to the packing list — while the packing list’s own posting status becomes FINAL and every one of its lines is marked converted.

   The new document is written directly rather than through the document screens, so three things you might look for are not there: it is not checked the way a document saved on its own screen is, it does not appear as a created event in a webhook feed, and it has no entry on its own Doc Link tab. The link back is recorded on the warehouse side only — open the packing list’s Doc Link tab to find it.

Where the numbers on the generated Delivery Order come from

This is the question the finance team asks first, and the answer is that the quantity and the money come from different documents.

• The base quantity is the packed quantity, from the packing-list line.
• The UOM quantity, the standard, net and discount amounts, the tax amounts and the transaction amount are copied unchanged from the source order line.

So a short shipment produces a Delivery Order whose base quantity says eight and whose UOM quantity and every amount column still say the ten that were ordered. It does not misstate your accounts — the document is created in DRAFT with quantity signum zero and posts nothing until somebody finalises it in the Delivery Order applet — but it does mean the draft is not a short-shipment document until somebody edits it, and the person who edits it is not the person who packed it. The source order’s prices ride along whether or not DEFAULT_PRICING_SCHEME is set: the setting only tags each line with that scheme, and where the item has no price in it, the conversion adds the item to the scheme with every price at zero. Check the scheme after the first batch: a zero price sitting in a price list is easy to miss, and whether a sale priced from that scheme then fills zero has not been tested.

A packing-list line made by a container scan carries no order line of its own. The conversion then copies from a line of the linked order with the same item, whichever the database returns first — so where an order holds the item on two lines at two prices, both packed lines take the same one of them. Only when the packing list has no linked order, or the item is not on it, is the line created with the packed quantity and no amounts.

A worked day: GSO’s fulfilment centre picks one online order short

GadgetSphere Online Sdn Bhd (GSO) packs its web orders at its fulfilment centre. This morning’s first finalised sales order has three lines: 2 flagship smartphones, 1 ultraportable laptop and 10 wireless earbuds. Stock Balance says the fulfilment centre holds 9 earbuds; the shelf holds 8, because one damaged unit was binned yesterday and nobody posted the adjustment. The scenario is the ordinary one on a fulfilment floor: the books say one thing and the shelf another, and the picker finds out first.

What the short pick leaves open. Two earbuds, and the warehouse no longer holds any record of them as work: the queue rows were deleted at step 3, the picking list has gone to packing, and the Outstanding Product row on that list is the only trace. The delivery order the warehouse wrote carries no knock-off link to the order, so the order’s balances move only by what the invoice knocks off — see Delivery Order (Internal). Deciding what happens to the two is customer service’s job, the same morning:

• Ship them later. The warehouse has nothing to pick them from: the line has to come back through the order’s Send To Queue and be pushed across again. Whether the order offers a line it has already sent once has not been established for this page — try it on one order before you promise a customer a date.

  When it does arrive, Create Picking List again builds every line of the order at its full quantity, so on the new list use Add selected to picking cart on the earbuds line only and pick 2 — the packing list is built from the carts, so the phones and the laptop do not go out twice. The conflict dialog will name this morning’s list; it is in packing, so confirm.

• Cancel them. Close the remaining quantity on the order, as the partial delivery workflow describes.

The ninth earbud is the inventory controller’s: a stock adjustment at the fulfilment centre brings Stock Balance back to the shelf. Until it is posted, the Picking Queue will offer a Location Balance of 1 that nobody can pick.

The thirty-second check: one order, five numbers

Take one shipped order line and read these in order. Each pair should agree; the first that does not tells you where the order went wrong, and whose job it is to put it right.

1. Order line quantity = picking list Qty to Pick. A smaller Qty to Pick means a fractional quantity was truncated; a list holding lines you did not tick means the whole order was built. The warehouse supervisor edits the carts, not the list.
2. Outstanding Product = the list and the carts. Its Required Qty should equal Qty to Pick and its Qty Picked the carts’ total for the item. If not, the report predates the last cart change: press Generate Discrepency Report again.
3. Active carts’ Qty Picked = packing list line quantity. A gap means a cart was discarded or added after Send to Packing List. The packer reconciles the carton against the cart before sealing it.
4. Packing list PACKED quantity = delivery order base quantity = its UOM quantity and amount. Base right and UOM or amount wrong is a short shipment nobody has corrected yet — the billing office fixes the draft before FINAL.
5. Invoice quantity = the Stock Movement Report line at the fulfilment centre, and Stock Balance fell by it. No ledger line means the invoice is not FINAL or its stock job failed; a ledger line and an unchanged Stock Balance for more than a few minutes means the balance job has not run. Both belong to accounts, through the stock report and the troubleshooting on Stock Balance.

When all five agree, the order is shipped and booked. When they agree and the shelf is still short, the difference is physical, and it is a count and a stock adjustment, not a warehouse record, that closes it.

What the source order’s packing status does — and does not — do

A sales order and each of its lines carry a packing status (IN_QUEUE, PLANNED, IN_PROGRESS, ON_HOLD, COMPLETED, PENDING_APPROVAL, APPROVED, REJECTED, INCOMPLETE, PENDING_STOCK). Nothing in the warehouse flow writes it.

The only path that would is one that no screen in any applet uses. If it were used, it would still not do what it appears to: the “is everything packed yet” check it relies on reads the manufacturing queue rather than the warehouse one, so on a tenant that does not use MRP the check tests an empty set, which counts as all packed, and the order would flip to COMPLETED on the first line rather than the last.

Take the packing status on a sales order as not maintained by this applet. Use the picking list’s own packing status (PENDING_PICKING → IN_PACKING_STATION) and the packing-list lines' UNPACKED / PACKED for where the work has actually reached.

VOID of the source order

Voiding an Internal Sales Order queues a clean-up job. It deletes the order’s remaining sales-side queue rows and its picking list — but only while the picking list is still PENDING_PICKING. Once the list has reached IN_PACKING_STATION the job does nothing, and the picking list, the packing list and any converted document survive the void. The job also never touches the warehouse Picking Queue, so rows already pulled into it are left behind.

The window this job can act in is narrower than it looks: if your operation sends lists to packing promptly, the clean-up removes almost nothing, and cancelling an order is a manual job in the warehouse.

What it will not do

• It does not move stock and it does not post. No WMS record writes an inventory transaction line or a journal. Receiving ten pallets and slotting them changes no stock balance anywhere; the balance you see beside a Picking Queue line is the stock ledger’s stored balance row, maintained by the documents, and it will not agree with what is physically in your racks unless a document has been finalised for every movement.
• It does not reserve, and it does not check availability. Building a picking list places no reservation and consults no stock balance: two orders for the last unit produce two picking lists, and neither screen objects. Stock Reservation is a separate mechanism and this applet writes none of its records.
• It does not work non-sales documents. The Picking Queue shows only sales orders.
• It does not handle fractional quantities. Picking quantities are integers; auto-allocation truncates the received quantity. Put items that are genuinely fractional through a base UOM whose quantities are whole numbers before they reach this applet.
• It has no VOID, no reopen and no history of its queues. Processing-queue rows and warehouse queue rows are hard-deleted on completion. The shared Audit Trail screen in the main sidebar is the place to look for changes; this page has not checked which warehouse records reach it.
• It does not protect a finalised Receiving Doc from Delete. The editor offers DELETE whatever the posting status, and deleting removes the header, its lines and their links to source documents — but not the processing-queue rows or the containers that its FINAL created. Those are left pointing at a document that no longer appears. Treat DELETE as a DRAFT-only action by your own rule.
• It does not maintain the source order’s packing status — see above.

Related applets

• Sales Order (Internal) — the only source of Picking Queue rows. Its own packing status is not maintained by this applet (see What the source order’s packing status does).
• Delivery Order (Internal) — receives the draft document that Create DO / Batch Process DO produces.
• Stock Transfer — receives the draft outbound transfer produced by the Doc Conversion tab; that is the only path in this flow that moves stock.
• Stock Balance and Stock Availability — the same stored balance rows as the Picking Queue’s location and company columns; Stock Report’s Stock Movement Report names the document that moved them.
• Stock Reservation — separate mechanism; the bin tables it reserves against are not written by this applet.
• Inventory Item Maintenance — the items that receiving lines, containers and picking lines point at.
• Organisation — companies, branches and stock locations used by the conversions. Warehouses here are a separate hierarchy, not stock locations.
• Employee — the entities registered as pickers.
• Pricebook — the scheme referenced by DEFAULT_PRICING_SCHEME.

Troubleshooting

Related documentation

• Inventory module — where this applet sits.
• Stock Transfer and Delivery Order (Internal) — the applets that finalise what this one drafts.
• Sales Order (Internal) — the upstream applet that feeds the Picking Queue.