By the end of this chapter you can

• Say what a WMS adds to a stock ledger, and why the module keeps no stock quantity of its own.
• Name the seven warehouse jobs, the ledger transaction each one posts, and the work the module leaves to M12 and to later extensions.
• Name the standards the module is built against and say what each is used for.

What a WMS adds to the ledger

Module M13 directs and verifies every physical warehouse move by scan: receiving against advance ship notices (ASNs, the supplier's message saying what is on the truck), quality quarantine, directed put-away, replenishment to pick faces and, by kanban, to line-side locations, wave, batch or zone picking, packing, shipping and cycle counting. Every completed move is posted to the M12 inventory ledger. The module replaces the warehouse management systems a business usually pays for: Manhattan Active WM, Blue Yonder WMS, SAP EWM, Oracle WMS Cloud, Infios, Infor WMS and Made4net at the large end, and Fishbowl, NetSuite WMS, Logiwa and Extensiv for smaller businesses ^[1][2].

Think of two books. The M12 ledger is the book of how much: item, lot, location and status, one row for every movement. The warehouse module is the book of what has to happen and who did it: which locations exist and what each allows, which pallets carry which labels, which task is open, which person scanned what. The second book never copies a quantity from the first. It points at it.

• In: location profiles (capacity, zone type, sequences); handling units and license plates with SSCC labels; inbound ASNs and receipts with quality routing; directed tasks for put-away, pick, replenish, move, count and load; waves and pick strategies, packing and shipping; cycle counting programmes; min/max replenishment to pick faces and kanban replenishment to line-side.
• Out: inventory valuation and purchasing (M12); transportation planning (catalogue Wave 4); labour management standards and slotting optimisation (best-in-class extensions).
• Described, not built in the course: damage capture with an under-receipt tolerance at receiving, and the pull signal a production system sends for line-side demand (with outbound orders of type line_side). Line-side kanban is built: the course's fixed seed has no line-side location, so Session 4 proves one kanban card scan in a test that rolls back, and Session 5 adds your real line-side locations and kanban rules.

The seven warehouse jobs

Every warehouse does the same seven jobs, whatever software runs it. The table lists them in the order stock moves, with what a person scans and the M12 ledger transaction each one posts. The transaction names are those of the M12 posting route inventory-post.

Two mechanisms hold this together. Each route calls inventory-post inside its own database transaction, which means the ledger row and the warehouse rows are saved together or not at all. And each post carries a client_ref built from the task, so sending the same request twice changes the data once (this property is called idempotency: repeating an action leaves the same result as doing it once). A unique index, a database rule that refuses a second row with the same value, lets one ledger transaction belong to only one task, receipt or count line.

Eleven capabilities in three tiers

Each capability carries a tier. MVP must exist for a business to cancel its incumbent subscription with confidence. STD is parity with mainstream tools, what a buyer expects in a demo. BIC marks best-in-class extensions. Analyst write-ups of WMS products separate a core set of capabilities from extended ones ^[2][3], and the tiers follow the same idea: nine core rows, two extensions.

The course builds the MVP and STD rows that its six sessions can reach, and leaves the two BIC rows as extensions. Several items inside the built rows are described but not built: blind receipt, damage capture with an under-receipt tolerance, and SSCC labels for the course's own cartons (Receiving); the velocity and fefo_zone put-away strategies (Put-away); demand replenishment (Replenishment); and carrier labels and an outbound ASN (Shipping), where the supervisor keys the tracking number by hand. In Replenishment, kanban to line-side is built and proven in a test, and the pull signal from a production system is not built. Cartonisation here means recording what went into which carton and its measures; choosing carton sizes automatically is not built.

The standards, and what each is used for

FIFO (first in, first out) uses the stock that arrived first. FEFO (first expired, first out) uses the stock that expires first, which is what matters for goods with a shelf life: a lot received last week can expire before one received last month.

References

1. Infios: Leader in the 2025 Gartner Magic Quadrant for WMS (core capability list). https://www.infios.com/en/knowledge-center/news/infios-leader-in-2025-gartner-magic-quadrant-wms
2. Made4net: which is the best WMS for business (core and extended capabilities). https://made4net.com/knowledge-center/which-is-the-best-wms-for-business/
3. Solutions Review: 2023 Magic Quadrant for WMS, key takeaways. https://solutionsreview.com/enterprise-resource-planning/?p=5624
4. U.S. FDA: Drug Supply Chain Security Act (DSCSA). https://www.fda.gov/drugs/drug-supply-chain-integrity/drug-supply-chain-security-act
5. ASC X12: the standards body for the X12 EDI transaction sets. https://x12.org/
6. UNECE: UN/EDIFACT, the United Nations rules for electronic data interchange. https://unece.org/trade/uncefact/unedifact

By the end of this chapter you can

• Name the fifteen wms_ tables, what each holds, and which five columns are soft links to M12.
• Read a location profile and a handling unit, and say why a unit holds one item and one lot.
• Decode a GS1-128 pallet label by hand, including its check digit, and say when a parser must refuse it.

Fifteen tables on the shared spine

Every table in the module starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. The module has no location list, item list, lot table or people table of its own: it points at core_storage_location, core_item, core_item_class, core_lot, core_uom, core_party, core_address and core_person. Its own tables share the prefix wms_.

The table below is the full definition: every column the module adds to the standard ones, with its type and whether it is required (marked req). Types are written as in the specification: text, int, num (a decimal number), bool, date, ts (a timestamp with time zone), uuid, json and qty. A qty is an exact decimal quantity; the course stores it as numeric(18,6), up to 18 digits with six after the point, so quantities never pick up the rounding errors of floating-point numbers. An arrow means a foreign key to that table, and allowed values are written after a colon. It is what your agent builds from in Session 2.

Four things in that table are easy to miss. First, a soft link is a column that holds the id of a row in another module's table without a database foreign key, so the modules install in any order. Five columns are soft: po_ref, sales_order_ref and the three inventory_txn_ref columns. Each inventory_txn_ref gets a unique index where it is not empty ^[5]. Second, the ASN table has no column for the time the truck arrived, so the route keeps it in ext as arrived_at; the dock-to-stock measure in chapter 4 reads it from there. Third, wms_task.qty is the quantity of the task, not a stock level. Fourth, wms_cycle_count_line has no status column, yet a count must post held and quarantined stock from the status it is in, so the route keeps the balance's status in the line's ext as balance_status, copied with system_qty when counting starts.

The specification has a sixteenth table, wms_dock_appointment (dock door, direction, carrier, start and end, status). It belongs to yard management, a best-in-class extension, and the course does not build it.

Locations: what a place allows

A location exists once, in the spine, as a core_storage_location (a code, a name, a parent and a status of active, blocked or inactive). The location profile adds what the warehouse needs to know about it: its zone type (receiving, reserve, forward_pick, staging, shipping, quarantine, line_side or returns), whether it is pickable, its capacity in volume, weight and pallets, its temperature class, whether it may mix items or lots, and two sequences. The pick sequence is the order a picker walks. The put-away sequence is the order put-away rules prefer. A location whose status is not active refuses every task into or out of it; that is how a location is frozen for a count.

These six locations are the fixed seed that the course works by hand in Session 4. The dock, quarantine and staging locations may hold mixed items; the two reserve locations and the pick face take one item at a time, though they may hold several lots of it.

Handling units and license plates

A license plate (LPN) is one unique number printed as a barcode on a pallet, case, tote, container or carton. One scan stands for everything on it. The wms_handling_unit table gives it a type, an optional SSCC, a location, a status and, for a carton on a pallet, a parent unit. A unit's status runs open, closed, in_transit, shipped, and consumed once it has been emptied.

The module follows one rule that keeps the data honest: a handling unit holds one item and one lot, and mixing is a property of a location, not of a unit. The unit does not hold a quantity either. Its item and lot are found by a view called wms_hu_lot, from its receipt; for a unit that was there at the start, from the opening ledger row; or, for a unit loaded in check mode, from the item and lot the loader stored in the unit's ext. The seed has three units: LPN-0001, a tote at PICK-B1, and LPN-0002 and LPN-0003, pallets at RES-A1 with SSCCs. Units the module creates are numbered from LPN-0101.

GS1 labels: SSCC, GTIN and the data fields

GS1 publishes the identification keys and barcode rules that suppliers, carriers and warehouses share ^[1]. Two keys matter here. A GTIN (Global Trade Item Number) identifies a kind of item. An SSCC (Serial Shipping Container Code) identifies one physical logistic unit, such as a pallet, so no two pallets share one. The supplier prints both, with the lot and expiry, on a GS1-128 label: Code 128 barcode symbology holding data fields, each starting with an application identifier (AI), a two-digit tag that says what the next characters mean ^[3].

The SSCC is 18 digits: an extension digit, then the company's GS1 company prefix and a serial reference (16 digits together), then a check digit. To print SSCCs on your own cartons you need a GS1 company prefix from your national GS1 organisation; look up its price on GS1's own site rather than assuming one. Until you need it, the license plate alone identifies a carton.

The last digit of an SSCC or GTIN is a check digit, computed from the others so that a misread or mistyped digit is caught ^[2]. Starting from the right of the digits before it, multiply alternately by 3 and 1, add the products, and the check digit is what brings the sum up to the next multiple of ten.

A parser that reads labels does five things, and refuses everything else. It splits the string by the identifier table. It recomputes the check digit of 00 and 01 and refuses a mismatch. It refuses an impossible date, a lot longer than 20 characters and an unknown identifier. It accepts the bracketed human form, and the raw form with character 29 between variable fields and a leading ]C1. And the server runs it, not just the phone, because the server is where a scan is believed. The course simplifies two GS1 rules: GS1 reads the two-digit year inside a window around the current year, while the course always reads it as 20YY, which gives the same date for expiry dates from 2000 to 2050; and GS1 allows day 00 to mean no day specified, while the course refuses it with every other impossible date.

Exercise · Read a pallet label by hand15 minutes

You need: Pen and paper or a text file, the identifier table from this chapter, and your AI coding agent for the last step

Work with this label from the seed's inbound shipment: (00)076543210000001029(01)11234567000104(17)270331(10)L-5001. Do steps 1 to 6 by hand before the agent sees it.

1. 1. Split the label into its four fields by identifier. Write each field under its name: SSCC, GTIN, expiry, lot.
2. 2. Check that the SSCC has 18 digits and the GTIN 14. Write the lot's length and confirm it is no more than 20 characters.
3. 3. Work the SSCC's check digit: take its first 17 digits, 07654321000000102, multiply from the right by 3, 1, 3, 1 and so on, add, and find what brings the sum to a multiple of ten. It should equal the 18th digit, 9.
4. 4. Work the GTIN's check digit the same way from its first 13 digits and confirm it is 4.
5. 5. Read the expiry 270331 as year 2027, month 03, day 31, and confirm that date exists.
6. 6. Now take (01)11234567000105 and (17)270231. Write for each the exact reason a parser must refuse it.
7. 7. Ask your agent: "Write a function that parses a GS1-128 string with identifiers 00, 01, 10, 17 and 21, recomputes the check digits of 00 and 01 and refuses a mismatch, an impossible date, a lot over 20 characters and an unknown identifier. Use the four labels in my notes as tests." Run it, and compare its output with your hand work field by field.

Outcome: A page of hand-worked checks for one label, two written reasons for refusal, and a parser your agent wrote that agrees with every one of them.

References

1. GS1: GS1 General Specifications. https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications
2. GS1: how to calculate a check digit manually. https://www.gs1.org/services/how-calculate-check-digit-manually
3. GS1: reference list of GS1 application identifiers. https://ref.gs1.org/ai/
4. PostgreSQL documentation: Constraints. https://www.postgresql.org/docs/current/ddl-constraints.html
5. PostgreSQL documentation: Unique indexes. https://www.postgresql.org/docs/current/indexes-unique.html

By the end of this chapter you can

• Name the five roles, the two identities that are not people, and the rules that keep one person from approving their own work.
• Describe a scan-verified task and say what the server does with a scan the screen accepted.
• Work put-away and first-expired-first-out allocation by hand on the seed, and say which ledger transaction each step posts.

Five roles and two identities that are not people

Roles are written as jobs, not names, and each maps to a row in core_job_role. Everyone's access comes from the Role and Exposure Matrix, and row-level security (the database refusing rows a role may not see or change ^[1]) is generated from it.

Two identities are not people. wms_loader is a route-only identity used once, to import data, and removed at cut-over. wms_check is a read-only service identity for the script that proves the ledger agrees with the tasks, and for the reconciliation at cut-over. It reads the tasks, receipts, units, counts and ledger, and the location, item and lot tables so that it can turn the old tool's codes into ids; it writes nothing.

Some rights are taken away on purpose. A restrictive rule can only remove rights: a row must pass it as well as the rule that grants the right, so no other grant can get around it ^[1]. Four are written. The person who counted a line cannot approve it. The person who received a lot cannot release it from quarantine. The loader inserts storage locations, location profiles, units and lots only with ext marked imported. And a picker's read of system_qty is refused, so a blind count, one where the counter is not shown the system quantity, stays blind. A column right is what lets a role read some columns of a table and not others.

Ten routes and nine screens

A route is one server address of your app, such as /api/warehouse/receive, that applies the rules in code so that a screen cannot skip them. Each route is written as its own row in the matrix, and each posts to the ledger only through inventory-post, which refuses a caller whose transaction type is not on its list.

A task is one verified move

A task is one directed move. The specification allows seven task types (putaway, pick, replenish, move, count, load, unload); the course uses putaway, pick, replenish, move and load, and treats the count lines as the work list for counts. A task is created by a route, claimed or assigned to a person, done by scan, and ends in one of a few statuses.

The scan screen shows one task at a time in large type: the location to go to and the unit to scan. It takes a scan two ways: the phone's camera, read by a barcode library in the page (free, and Code 128 is the symbology GS1-128 is printed in), or a handheld scanner that types the code into the focused box like a keyboard (a hardware cost if you do not own one, so use the camera first). The confirm button stays disabled until the scans match the task. But the screen is not the rule.

• Each route calls inventory-post inside its own database transaction, with a client_ref built from the task, and writes the transaction id back to the task.
• The server checks every scan again, whatever the screen did.
• A refused scan is written as a SCAN-REFUSED comment on the task, and refused.
• The screen refuses to confirm with no connection instead of queueing the confirm, because a queued confirm could post stock into a location that was frozen in the meantime.

Receiving, quarantine and put-away

An ASN runs expected, arrived, receiving, received, closed. For ASN-1001 the receiver marks the truck arrived, then scans the DOCK-IN label and each supplier pallet label and keys the pallet quantity. For each pallet the route decodes the label, matches the GTIN to the item and the lot and expiry to the ASN line, creates the core_lot once, creates the handling unit with the label's SSCC and the next license plate, inserts the receipt, and posts a po_receipt into DOCK-IN. It refuses a quantity that would take the line above the ASN quantity (receipt_over_pct is 0 in the course), a label whose lot differs from the line, and a scan that matches no line. Blind receipt, receiving with no ASN, is not built: the supervisor enters the ASN first. Damage capture and an under-receipt tolerance, which the specification lists for receiving, are not built either: wms_receipt.damage exists and stays false, and each pallet is received in full.

Quarantine. Items of class INSPECT are received with qc_required true. Their lot is created with status quarantine (other lots, such as FG-10's L-5001, are created released), the po_receipt goes in with to_status quarantine, and the event wms.receipt.qc_required is raised. Stock in quarantine, or on hold from quality, is never offered to an order. It leaves quarantine only when inventory control posts a status change from quarantine to available at the location, with the quality result in a comment, and the route refuses the person who received it.

Directed put-away. Receiving creates one put-away task per pallet. The route reads the active rules in priority order and takes the first that finds a location which is active, has room under max_pallets (counting units there not yet shipped or consumed), and accepts the mixing. The specification names five strategies: fixed, nearest_empty, consolidate, velocity and fefo_zone. The course uses the first three.

For ASN-1001 the expected result is: the two FG-10 pallets, LPN-0101 and LPN-0102, to RES-A1 by consolidate (which then holds 4 of its 4 pallets), and the FG-20 pallet, LPN-0103, to QUAR-1 by the fixed rule. The receiver completes each task by scanning the destination location and the pallet; the route posts a transfer_in from DOCK-IN to the destination, with from_status and to_status both set to the status the stock is in now, and sets the task done. A fifth pallet for RES-A1 would go to RES-A2 by the nearest_empty rule. Dock-to-stock time for each receipt is the put-away's completed_at minus the ASN's arrival time.

Allocation: first expired, first out

Allocation decides which stock an order takes. The rule is FEFO: earliest expiry first, then the lowest pick sequence, then the lowest license plate. A lot with no expiry date sorts after all dated lots, oldest lot first (FIFO, first in first out, by the lot's created_at). It reads only a view called wms_allocatable: stock in locations that are pickable, in a reserve or forward_pick zone and active, for lots whose status is released, less the quantity of pick and replenish tasks still open for the same item, lot and location. That one view is why held and quarantined stock cannot be offered: it is not in the view. The view is created with security_invoker, which makes it apply the rights of the person reading it, not of its owner ^[2].

Allocation creates one open pick task per source, to STAGE-OUT, with no wave yet. It does not change the ledger: stock stays available until a picker moves it. For OUT-2001 line 2 (12 of FG-20) nothing is offered at first, because lot L-6001 is in quarantine; qty_allocated stays 0 and the order stays new until inventory control releases the lot and the line is allocated again.

Waves, picking, replenishing and shipping

A wave is a group of order lines released together for picking. The specification allows five wave types. The course builds the first.

Releasing the wave gives the open pick tasks the wave and orders them for walking by the locations' pick sequence (PICK-B1 10, then RES-A1 20, then RES-A2 30). The order becomes released. A picker claims a task, goes to the location, scans the location and the unit, keys the quantity, answers whether the unit is now empty, and scans the destination. The route posts a transfer_in to STAGE-OUT from status available to status allocated and moves the line's qty_picked. If fewer are found than asked, the task ends short with the quantity found, that quantity is posted in the same way, and the line stays open. A unit that is emptied becomes consumed and has no location.

Replenishment follows a pick. After the first pick, PICK-B1 holds 40 of FG-10, below the rule's minimum of 45, so the route creates one replenish task for 60 (the maximum 100 less 40) from the earliest-expiry free unit in a reserve location (one that is not on hold and not held by an open pick task). A min/max rule works like that: top up to the maximum when stock falls below the minimum. A kanban trigger is the line-side version: the production line hands back a card when a bin is empty, a scan of the card at the line-side location creates one replenish task for the quantity the card asks for (the rule's max_qty in the course), and the task moves that quantity from reserve. The seed has no line-side location, so Session 4 proves it in a test that rolls back. A pull signal sent by a production system is not built.

Packing and shipping. The packer scans each item and a new carton label into cartons. An item's GTIN names the item but not the lot, so where an order was picked from two lots the pack screen lists the order's done pick tasks and the packer chooses the lot from them; a label that also carries identifier 10 fills the lot in. The route makes the shipment, one wms_package per carton and one load task per carton, and sets package_count and total_weight_kg itself, ignoring any total a browser sends. The label text is stored in wms_package.label_zpl (ZPL is the language Zebra label printers read; the free way is a plain label printed from the browser with the same lines). The packer then loads: scanning STAGE-OUT and each carton posts a shipment from status allocated. The supervisor ships with a tracking number and the route sets the bill of lading number; the module calls no carrier service, so there is nothing to pay. The bill of lading prints the ship-to address when the order has one; the seed's OUT-2001 has none, so it shows the customer by name only.

Exercise · Allocate first expired, first out by hand15 minutes

You need: Paper or a text file, the FG-10 stock table from this chapter, and your AI coding agent for the last step

Use the seed's FG-10 stock and its order OUT-2001. Do steps 1 to 5 by hand, then let the agent try to match you.

1. 1. Write the three FG-10 lots with their quantity, expiry, location and status, as in the table above.
2. 2. Strike out every row that is not released. Write beside it the status that removed it.
3. 3. Sort the rows that remain by expiry, then by the location's pick sequence, then by license plate. Write the order.
4. 4. Allocate OUT-2001 line 1, 40 units: take from the first row until it is used up, then from the next. Write each pick task: quantity, lot, location and license plate.
5. 5. Suppose the 100 units of lot L-5001 on ASN-1001 have been received and put away, and an order for 200 arrives. Work it again: how many units are allocated, from which lots in which order, and how many remain unallocated? Check that the 20 on hold are untouched.
6. 6. Ask your agent: "Write a test for allocation of FG-10 against the seed that expects my pick tasks for the order of 40 and for the order of 200." Run it against your allocation route, and decide whether any difference is a bug in the route or in your hand work.

Outcome: Hand-worked allocations of 40 and 200 units, with the pick tasks listed and the held lot untouched, and a test that proves your route gives the same answer.

References

1. PostgreSQL documentation: Row security policies (including restrictive policies). https://www.postgresql.org/docs/current/ddl-rowsecurity.html
2. PostgreSQL documentation: CREATE VIEW (the security_invoker option). https://www.postgresql.org/docs/current/sql-createview.html
3. W3C: Understanding WCAG 2.2, Contrast (Minimum). https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
4. W3C: Understanding WCAG 2.2, Target Size (Enhanced). https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html

By the end of this chapter you can

• Load locations and opening balances by license plate as ledger transactions that are safe to run twice.
• Run a blind cycle count and a wall-to-wall count with the variance approved by someone other than the counter.
• Prove the book with the two check scripts, measure the KPIs, and list what must pass before cut-over.

Opening balances: the location master, then stock by license plate

The specification's migration rule is short: load the location master, then load opening balances by license plate through M12 opening transactions, and run a wall-to-wall count at cut-over. Two things must already be in place: items and units of measure, which M12's import owns (the warehouse loader creates neither; that import also loads locations and lots, which the loader looks up by code, and by item and lot number, and reuses, creating one only when none exists), and the old tool's exports, taken again from the vendor's own export page just before the load.

• Choose the mode. If M12 already posted opening stock by item, lot and location, run the loader in check mode: it reuses the locations and lots M12 loaded, adds the location profiles and units (writing each unit's item and lot into its ext, so wms_hu_lot can name them), and compares quantities with the ledger, posting nothing. Otherwise run post mode. Write the choice and the reason down.
• Write the mapping first. Old location to core_storage_location and wms_location_profile; old zone names to the eight zone types; old unit types to hu_type; old stock statuses to a balance status (available, quarantine, hold, damaged) and to a lot status (released, quarantine, on_hold, rejected).
• One item, one lot per unit. A license plate the old tool shows with mixed contents is refused and listed. Split it in the old tool or on the floor, then load it.
• Closed locations load blocked or inactive, never active.
• Each accepted row is one transaction of type adjustment, reason OPENING, ref_type wms_handling_unit and ref_id the unit, dated at the cut-off and carrying the status the old tool shows, posted through inventory-post and never written into the balance table.
• Safe to run twice. The key of each row (license plate, item, lot, status) is its client_ref, so a second run adds nothing.
• Dry-run first. The default run reports what it would do and changes nothing; it writes only with an explicit flag. Fix the mapping, not the data, until nothing is unmatched or every reject is explained.

Then reconcile on-hand by location three ways: the old tool's own report, your export, and the ledger (the view that recomputes balances from the ledger, grouped by location, item, lot and status). They agree, or each difference is written down with its cause. Anything you cannot explain is an error to find, not a rounding to accept. Check also that stock on hold or in quarantine sits in the balance table with that status and is absent from wms_allocatable.

Counting: cycle counts, blind counts and approval

A cycle count counts a few locations or items on a schedule instead of the whole building at once. The specification allows five methods: abc (items ranked by value or movement, the top class counted most often), location, item, ad_hoc, and wall_to_wall (everything, used at cut-over). Three controls make a count worth believing.

• Blind. The counter is not shown the system quantity, so the count is what they saw and not what they expect. The route copies the system quantity when counting starts, with the balance's status kept in the line's ext as balance_status so held and quarantined stock is posted from its own status, and the picker's role cannot read the quantity.
• Recount. A variance beyond the tolerance (recount_tolerance_units, 1 in the course) flags the line for a recount before anything else happens.
• Approval by someone else. A person who did not count the line approves it. Only then does the route post one cycle_count transaction for each line with a variance. A line with no variance posts nothing, because a ledger quantity must be above zero.

The measure that comes out is inventory record accuracy: count lines within tolerance divided by count lines. In the example, line one is off by 2 against a tolerance of 1 and line two is exact, so 1 of 2 lines is within tolerance: 50 percent. For the wall-to-wall count at cut-over, block every location in the pilot area first (a blocked location refuses moves but allows counting), count blind in pick-sequence order, recount, approve, and unblock.

Proving the book

Two scripts prove the module against the ledger. scripts/check-wms.mjs, run as the read-only wms_check identity ^[4], checks that every complete task, meaning done, or short with a quantity above zero, has exactly one ledger row (not a reversal) whose ref_type is wms_task and whose id matches the task's inventory_txn_ref; that no ledger row names a task that is not complete (a short task with nothing picked has no row); and that every receipt and every approved, non-zero count line has its row. M12's scripts/check-balances.mjs checks that balances recomputed from the ledger equal the stored balances. A check you have never seen fail proves nothing, so in a scratch copy edit one balance by hand and see check-balances.mjs fail; then, in the scratch copy, clear the inventory_txn_ref of one done task (or mark a task done with no ledger row) and see check-wms.mjs fail.

Those numbers can all be checked by hand. The 19 ledger rows are those at site WH1, whose from or to location is one of the six WH1 locations: M12's own seed and workflow rows sit in the same ledger at M12's locations and are not counted. The 11 done tasks are 3 put-aways, 1 move, 3 picks, 1 replenishment and 3 loads, and 11 task rows appear in the ledger. 17 events reach the outbox, counted on the owner connection your migrations run as because no role in the matrix reads it: 3 receipt.posted, 1 receipt.qc_required, 11 task.completed, 1 shipment.shipped and 1 count.variance.

Cutting over

The old tool and the module run side by side for at least one week, with every receipt, put-away, pick, pack, shipment and count in the pilot area entered in both by the same people. Compare the week's four measures for both systems against the baselines you took in Session 1. The two pick-accuracy figures are not the same measure: the module's counts refused scans and short picks, the old tool's usually counts mistakes found at pack check or by customers, so say so beside the comparison. The module should be at least as accurate as the old tool, and every miss needs a reason. A difference you cannot explain means you are not ready.

Cancel last. Read the vendor's cancellation terms from your own account page: the notice period, the renewal date and how long you can still export after cancelling. Cancel only after the cut-over works and the final export is stored. The saving is the old cost for a year taken from the invoice, minus what the module costs to run on the services you already pay for, plus any scanners or printers you bought, shown as arithmetic from real invoices and never as an estimate. Record any leased devices on the old bill as their own line.

Exercise · Reconcile one location against the ledger15 minutes

You need: Your old tool's on-hand-by-location report, your loaded module data or a scratch copy of it, and your AI coding agent

Work with one real or made-up location from your pilot area. Use your own data, never a row of someone else's.

1. 1. Pick one location and write its code. From the old tool's report, write each item, lot, status and quantity it holds.
2. 2. Ask your agent: "Show the quantity by item, lot and status for location X from the view that recomputes balances from the ledger." Write the result beside the old report.
3. 3. Subtract: write the difference for every row. Mark each row as agreeing, short or over.
4. 4. For each difference, write a cause you can check: a movement made in only one tool, a unit with mixed contents that was refused, a status mapped differently, or a data entry error. Open the record that proves it.
5. 5. Check that any stock on hold or in quarantine appears with that status in the ledger and is missing from the allocatable view.
6. 6. Decide: if every difference has a proven cause, write "explained" and what you will do about each; if any has none, write "not ready" and who looks next.

Outcome: A one-location reconciliation with the old report, the ledger quantity, the difference and a checked cause for each row, and a decision of explained or not ready.

References

1. Made4net: which is the best WMS for business (core and extended capabilities). https://made4net.com/knowledge-center/which-is-the-best-wms-for-business/
2. Solutions Review: 2023 Magic Quadrant for WMS, key takeaways. https://solutionsreview.com/enterprise-resource-planning/?p=5624
3. Infor: Gartner Magic Quadrant for WMS (core versus extended capabilities). https://dam.infor.com/api/public/content/d8957bc1ac164bf1843965deeaa7e26a
4. PostgreSQL documentation: Privileges (granting and revoking rights). https://www.postgresql.org/docs/current/ddl-priv.html

Choose one answer for each question, then submit. You will see the right answer and why for every question.

1. Where does the warehouse module keep the quantity of a lot in a location?

AIn a quantity column on wms_handling_unit, updated at each scanBIn wms_task.qty, which is summed across the done tasksCOnly in the M12 inventory ledger, by item, lot, location and statusDIn wms_location_profile, as a running total for each location

2. What confirms a pick in the module?

AScans of the location and the unit, which the server checks againBA tap on a done button on the picker's phoneCA supervisor's phone call after the wave closesDA tick on the printed pick list, entered by the end of the shift

3. How many ledger transactions does each completed task produce?

ANone until the end of the day, when a batch posts them allBOne for the task and one more for the order it belongs toCOne for each wave, covering all the tasks in itDExactly one, written together with the task in one database transaction

4. In a GS1-128 label, which application identifier carries the lot number?

A00B10C17D21

5. The first thirteen digits of a GTIN-14 are 1123456700010. What is its check digit?

A4B6C0D8

6. Under the seed's put-away rules, where does the pallet of FG-20 (class INSPECT) go?

ARES-A1, by consolidateBRES-A2, by nearest_emptyCPICK-B1, to fill the pick faceDQUAR-1, by the fixed rule at priority 10

7. OUT-2001 asks for 40 of FG-10. Lot L-4003 expires first but is on hold. What does allocation take?

A40 from L-4003, then the hold is clearedB40 from L-4001, because it is the largest lotC30 from L-4002, then 10 from L-4001D20 from L-4003 and 20 from L-4002

8. A receiver scanned in lot L-6001, which is in quarantine. Who may release it?

AThe same receiver, once the quality result is knownBInventory control, but not the person who received itCAny picker who needs the stock for an orderDThe supervisor, by editing the lot's status directly

9. A blind count of PICK-B1 finds lot L-4001 at 38 against a system quantity of 40, with a tolerance of 1. What happens?

AThe line posts at once, since the counter found the differenceBThe system quantity is edited to 38 by the supervisorCThe line is ignored, because 2 units is a small differenceDThe line is flagged for a recount, then a different person approves it, then the variance posts

10. How does the loader bring in opening stock?

AAs adjustment transactions with reason OPENING, one per unit, through inventory-postBBy writing quantities straight into the balance tableCBy copying the old tool's report into wms_task rowsDBy running a wall-to-wall count and keying the results

11. Which messages do ANSI X12 856 and UN/EDIFACT DESADV carry?

ACustomer invoicesBCarrier freight billsCAdvance ship noticesDPurchase orders

12. When may the old warehouse system's subscription be cancelled?

AAs soon as the first receipt is posted in the moduleBAfter the cut-over works and the final export is storedCBefore the wall-to-wall count, to save a month of costDWhenever the vendor sends its renewal notice

Submit answers