Warehouse Management System Applet

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

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.

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

Inbound Process tab

Outbound Settings tab

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

• DEFAULT_LOCATION — read by the Receiving Doc create screen and by Space Container Allocation create/edit, which merge the personal value over the applet value. The only screens that write it are the two Default Selection screens described below, and neither works.
• ENABLE_BRANCH_FILTER — a name that exists in the applet but is not shown, saved or read. Not a setting.

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

Feature visibility and permissions

• 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.

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, with Serial Number, Batch Number and Bin Number sub-tabs. Editing an existing header adds Account, Lines, Generic Document, External Generic Document and Attachments; the create screen has only Main Details, Lines and GenDoc.

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.

Posting proof

The two documents this applet creates carry the signums of their own types:

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 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.
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.

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

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. Two things about this listing are not visible on it:
   • It only ever asks for sales orders, so only sales orders are shown regardless of what else was pushed in.
   • It is not filtered by document permission. The equivalent listing on the sales side joins each row to the user’s document permissions and hides what they may not see; the warehouse listing applies no such filter, so everyone who can open this screen sees every queued line. For a picker that is arguably the point — you pick what is in the building, not what is on your accounts — but if your sales-side permissions exist to keep branches or reps apart, they stop at this screen.
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:
   • 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.
4. Picking happens through the cart screens; discrepancies are recorded and discarded carts can be restored.
5. Send to packing creates the Packing List and sets the picking list’s packing status to IN_PACKING_STATION. 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. Only lines whose packing status is PACKED are carried over. From the Doc Conversion tab, a Packing List becomes an outbound Stock Transfer. Both are written as DRAFT and linked back to the packing list.

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. When DEFAULT_PRICING_SCHEME is set, the unit prices are re-resolved from that scheme; when it is unset, the source order’s prices ride along.

If the packing-list line has no source order line behind it — which is what a manual container scan produces — the copy does not happen at all, and the Delivery Order line is created with the packed quantity and no amounts.

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 financial stock balance, 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 audit screen. Processing-queue rows and warehouse queue rows are hard-deleted on completion, and Settings › Audit Trail is a dead link.
• It does not maintain the source order’s packing status — see above.

Related applets

• Sales Order (Internal) — the only source of Picking Queue rows, and the document whose packing status this applet updates.
• 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 — supply the location and company ledger quantity columns shown on the Picking Queue.
• 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.