User Guide: Order Processing

Covers thirteen screens across four areas:

Internal appendix: Xilnex CS & Implementation — Appendix A.

TL;DR. Configuration decides what is possible; the order screens decide what actually happens. Configure in this order: Order Type → Item Allowed by Order Type → Item Availability → Store Availability → Order Cut-off Day → Store Batch. Then orders flow New Forecast / Ad-Hoc Order → Order Listing → Order Posting → Auto-GRN.

Two facts save the most support time: an order type with no cut-off rule configured is never blocked (section 4.1), and the posting daemon polls every 30 minutes against those same cut-off rules — manual posting is exception handling (Part 6). If a store says "I can't find this item," work through Recipe 6.

Part 1 — How the modules fit together

Each configuration module is an independent gate. An order line is only possible when all gates pass. They operate at different levels, which is the source of most confusion:

Gates 1–5 decide whether the line can exist. Gate 6 decides whether it can still be changed — it is a timing gate, and unlike the others it is opt-in: an order type with no rule is never blocked.

Gate flow: Store user starts an order → check order type is Active (else type not selectable) → check store is within opening/closing dates (else no new orders — existing orders still process) → check store is not credit-blocked (else blocked by Credit Dept, and in-flight orders move to BLOCKED) → check item category is ticked for this order type (else category hidden) → check item is allowed for this store within date window (else item hidden / rejected at post) → check delivery date is before cut-off (else date cell locked, read-only) → item can be ordered.

Two moments of enforcement. Gates are checked when the store browses items (soft — failing items are simply not shown) and again when the store posts the order (hard — the post is rejected and the offending lines are named). An item can therefore pass at creation and fail at posting if configuration changed in between.

Changes apply to the next order, not to orders already in flight. Editing any of these configuration screens does not retroactively alter orders that already exist.

Note — source of downstream behaviour. Every screen in this guide except Auto-GRN (Part 7) is described from the built UI. What happens downstream of a failed gate — orders moving to BLOCKED, no PO being generated, the soft-hide-then-hard-reject pattern above — is drawn from the Phase 2 PRD §4.7 and the ordering engine design §6.1, not observed in the build. Statements of this kind are marked (spec) throughout. Verify them before the guide is released.

Warning — Store Blocking is the only store-level source of BLOCKED. Store Blocking is a separate module operated by the Credit Department for overdue franchisee payments. Unlike Store Availability — which only prevents new orders and lets in-flight orders continue to process — Store Blocking additionally drives existing confirmed-unposted orders to BLOCKED and stops PO generation. If a store's opening/closing dates look correct but existing orders have gone to BLOCKED, check Store Blocking first — section 4.2 sets the two modules side by side.

Part 2 — Task recipes

Recipe 1 — Add a new order type

The screen is a wizard with lettered sections. All of them feed the Validation panel at the bottom; Activate stays disabled until every check passes.

1. A · Archetype — pick the base behaviour the type maps onto. This is the most consequential choice on the screen and it maps to engine code, not configuration:
   
   

   Archetype	Use when
   Forecast / Replenishment	Store-initiated, recurring order placed against a forecast or standing need
   Ad-hoc / Custom	One-off, event- or exception-driven order with no recurring cadence
   Allocation	Warehouse or DC pushes stock to an outlet on its own initiative — the outlet does not request it
   Inter-location Transfer	Warehouse-to-warehouse movement to source stock a receiving location cannot supply itself

   If none of the four fit, the type needs engineering work — stop and raise it rather than forcing the closest match.

2. B · Identity & labeling
   
   

   • Type code — alphanumeric, max 10 characters. Immutable after activation. Choose carefully.
   • Display label — what admins and end users see (e.g. Consignment Order).
   • Description — shown in the type list and as help text to end users.
   • Active toggle — controls selectability at order creation.

3. C · Quantity model — tick which quantity tiers an order of this type carries. Tiers must be contiguous — you cannot have Delivery qty without Actual qty.
   
   

   • Forecast qty — planning tier before actuals
   • Actual qty — committed order quantity
   • Delivery qty — dispatched from source
   • Received qty — confirmed at destination

4. D · Location & direction — Outlet → Warehouse (standard store request), Warehouse → Outlet (allocation), or Warehouse → Warehouse (transfer). Selectable options depend on the archetype chosen in A, so set A first.
   
   

5. E · Creation access — tap + on each permission group that may create orders of this type. At least one is required.
   
   

6. F · Document & integration
   
   

   • Generates PO — creates a purchase order to the source on posting.
   • Requires reference field — forces an external document reference on every order of this type.

7. G · Custom fields — optional. + Add custom field for data this type needs beyond the standard set. Every custom field must be named or validation fails.
   
   

8. Validation — the panel lists each blocking check with its current state. Clear all ! items, then press ✓ Activate.
   
   

   Check	Passes when
   Type code — alphanumeric, ≤10 chars, unique	A valid, unused code is entered
   Display label present	Label filled in
   Archetype selected	Section A chosen
   Quantity tiers — at least one, contiguous	Section C valid
   At least one permission group can create	Section E has ≥1 group
   All custom fields named	Every custom field has a name

Note — after activation. Type code and archetype are locked. Everything else remains editable, and edits affect only orders created after the change.

Recipe 2 — Make a new item orderable for a store

This is the recipe that spans two modules. Both must pass — allowing the category is not enough on its own, and enabling the item for the store is not enough either.

Step 1 — Allow the category under the order type

1. Check whether the item's category is already a row in the grid. If not, press + Add Item Category.
   
   
2. Find the column for your order type. The grid scrolls horizontally, with one column per active order type — which types appear depends on your environment and on what has been created in Recipe 1.
3. Tap the cell where the category row meets the order type column to toggle it between allowed (✓) and disallowed (–).
4. Set the display sequence by dragging the row handle. Sequence controls the order categories appear to store users. Rows below the "NOT YET SEQUENCED" divider show SEQ – — drag one upward to assign it a sequence.
5. Press Save.

Step 2 — Enable the item for the specific store
Screen: Item Availability · Who: PPIC Admin · Level: Item + Store

1. Choose the store in Query Item by Outlet. Nothing loads until an outlet is selected — this screen is always scoped to one store at a time.
2. Narrow the list using the ITEM search box and the Item Category, Preferred Vendor, and Period filters, then Apply filter.
3. Press Edit on the item row. The row expands to reveal:
   
   
   • Preferred Vendor — the plant that services this item for this store.
   • Allow Request Date From — the item is not requestable before this date.
   • Allow Request Date To — the item is not requestable after this date.
4. Set the Allow to Request toggle to Allowed.
5. Press Done on the row, then Save on the screen.

Important — leaving the dates blank. A blank date range (–) means no date restriction — availability is governed by the Allow to Request toggle alone. Fill the dates only when the item has a genuine launch or discontinuation date.

Recipe 3 — Onboard a new store

Step 1 — Open the store

1. Search for the store in the STORE box, Apply filter.
2. Press Edit → set Opening Date. Leave Closing Date blank unless the store has a known end date (a pop-up, a fixed-term lease).
   
   
3. Press Done, then Save.
4. Confirm the STATUS column now reads Opened. Status is derived from the dates — you do not set it directly.

Step 2 — Give the store its item list

1. Select the new store in Query Item by Outlet.
2. For a store with hundreds of items, do not edit row by row. Either copy an existing comparable outlet's data with Copy stock data, or use the Export → edit → Import flow: press Export on Item Availability to download the current set in StockTemplate CSV format, edit it, then upload it directly through Stock Import and Log — no reformatting required. See Recipe 5.
3. Set the Preferred Vendor on every item so the store draws from the correct servicing plant.

Step 3 — Verify
Have the store attempt a test order of each type it will use. If items are missing, run Recipe 6.

Recipe 4 — Retire an item, or close a store

Retire one item for one store — Item Availability → Edit the row → either set Allow Request Date To to the last orderable date (preferred — it is self-documenting and reversible), or switch Allow to Request to Inactive for an immediate stop. Done → Save.

Retire a whole category from an order type — Item Allowed by Order Type → tap the ✓ cell to turn it to – → Save. This affects every store, so confirm the scope before saving.

To retire a category everywhere, untoggle its cell under every order type column rather than using Delete. Untoggling is reversible and leaves the row's sequence intact; Delete removes the row outright, and whether it is blocked when orders exist against that category is unverified (see Appendix B, gap #10).

Close a store — Store Availability → Edit → set Closing Date → Done → Save. Once the date passes, STATUS flips to Closed and the closing date renders in red. From that point the store cannot create new orders — but existing in-flight orders are unaffected and continue to process through to completion. Closing a store does not drive any order to BLOCKED; only Store Blocking does that. To hard-stop a store's in-flight orders as well, apply a Credit block (Recipe 8).

Caution — orders already in flight. Retiring an item or closing a store does not cancel orders that already exist, and closing a store does not stop them either — they will run through to completion under the closed store's account. Check for open orders before setting a closing date and coordinate with PPIC; if you need those in-flight orders halted rather than allowed to complete, escalate to Credit for a Store Blocking action.

Recipe 5 — Bulk update and cloning

Three mechanisms on three different screens. Choosing the wrong one is the most common mistake here, so start from what you are changing:

Note — Item Availability now supports Export. The Export button on Item Availability downloads the current filtered set in the StockTemplate CSV format, which is directly re-importable through Stock Import and Log with no reformatting. This closes the round-trip that previously required rebuilding the file by hand. Item Availability itself still has no Import button — the upload always goes through Stock Import and Log.

Path A — Store Availability export / import

1. Apply the filters you want first.
2. Press Export to download the current data as your working file.
3. Edit the file without changing its column headers or row identifiers.
4. Press Import and upload.
5. Review the grid, then Save.

Always export first and use that file as the template — do not build an import file from scratch.

Path B — Stock Import (item availability)

1. Press IMPORT and upload a file built on the StockTemplate CSV format. A file exported directly from Item Availability already matches this format and can be uploaded without edits to structure — only edit the values.
2. The run appears as a row in the log carrying a Status and three counts — Total, Success, and Failed record(s).
3. Press REFRESH until the row reads Processed.
4. Read the Failed record(s) count — see the caution below.
5. Use the row's … menu to inspect that run.

Caution — Processed does not mean every row succeeded. A file with failures still reports Status Processed. In the shipped log, a run showing Total 2 / Success 1 / Failed 1 sits alongside zero-failure runs, all labelled Processed. Read the Failed record(s) column, not the Status column, to know whether an import actually landed. A run with failures needs the failed rows corrected and re-imported. Whether it is safe to re-import the whole file rather than only the corrected rows was not observed — re-import the failed rows alon.

Path C — Copy stock data between outlets

Use this when a new outlet should start from an existing outlet's data. It replaces the export-edit-import round trip entirely.

1. Go to Product information management → Stock import and log.

2. Press MORE → Copy stock data.

3. Select From outlet and To outlet.

4. Choose the copy mode:

   Button	Copies
   COPY	Stock data only
   COPY (INCLUDE BRANCH ASSORTMENT)	Stock data plus the source outlet's branch assortment

5. DISMISS closes the dialog without copying.

Confirm before relying on any of the three paths. Open behaviours, all of which change how you would use these on live data: whether Store Availability's Export covers the filtered set or all records and whether Import updates matched rows or replaces the set; exactly what branch assortment adds to a copy; and whether Copy stock data merges into the destination outlet or overwrites it. Test each on a sandbox outlet first.

Recipe 6 — Troubleshooting: "why can't this store order this item?"

Work down the list. Stop at the first failure.

If the item was visible when the store built the order but the post was rejected: configuration changed between creation and posting. Check the journal log on Item Availability for a recent edit to that item/store pair.

A different question — the order exists but has not advanced

The ladder above diagnoses item visibility. If the store can see and enter the item but the order is not moving through its lifecycle, start here instead:

Part 3 — Screen reference

3.1 Order Type Maintenance

Order type codes, permissions, and access groups.

Entry point is a list of existing order types; New order type opens the wizard, and ← Back to order types returns to the list.

3.2 Item Allowed by Order Type

Which item categories can be requested under each order type. — badge: COMPANY LEVEL

3.3 Item Availability

Item availability and preferred-vendor rules per store. — badge: CONFIG LEVEL — ITEM + STORE

3.4 Store Availability

Store opening / closing dates.

3.5 Stock Import and Log

Product information management → Stock import and log. Not part of the Store Ordering Configuration screens — it is the bulk-maintenance route for item availability data, and the home of Copy stock data.

Part 4 — Delivery timing & store governance

The three modules in this part do not decide whether an order can exist. They decide when it stops being editable (Order Cut-off Day), which stores are suspended for credit (Store Blocking), and in what sequence orders are processed (Store Batch Maintenance).

All three sit under Supply chain → Store Ordering → Configuration, alongside the four modules in Part 2. The left-hand nav groups them as Delivery Timing (Order Cut-off Day) and Store Governance (Store Availability, Store Blocking); Store Batch Maintenance is a separate top-level screen.

4.1 Order Cut-off Day

A cut-off rule locks order editing once its threshold passes. Each rule answers three questions:

1. When does the threshold fall? — the cut-off type
2. Which orders does it act on? — order type + level + triggers on order status
3. What happens after it falls? — the blocking condition

Important — cut-off is opt-in. An order type with no rule configured is never blocked. Orders of that type stay editable indefinitely. This is stated on the screen's own info banner and is the single most important fact about the module — a missing rule is silent, not an error.

Each order type may hold one rule per option, and a single rule can carry multiple dates (e.g. first + third Wednesday).

These same rules drive the posting daemon, which polls every 30 minutes and checks orders by order type and status against them (Part 6). A missing rule therefore has two consequences, not one: nothing is blocked, and nothing advances automatically.

The three cut-off types

ETA − X is the only type without a blocking condition. Its summary line reads "orders in saved status are affected" rather than "blocked for n day(s)" — the lock has no release window. The other two types must state how long the block lasts.

Blocking condition

Level and trigger status

• Level — Company applies to all plants; Plant scopes the rule to one plant. The grid shows the plant GUID under a Plant-level row and "All plants" under a Company row.
• Triggers on order status — Saved, Posted, or Confirmed. Single select. This is the status the rule acts on, and it is what lets one order type carry several rules that fire at different lifecycle stages.

A worked reading of the shipped configuration, showing how the three axes combine for one order type:

TRSO carries three rules — a weekly RSO deadline on Saved, a monthly deadline on Posted, and a per-order AO deadline on Confirmed. They coexist because each triggers on a different status.

Recipe 7 — Add a cut-off rule

1. Cut-off type — pick Cut off by weekday, Cut off by date, or Cut off by ETA − X. Set this first — it determines which fields render below, and switching it resets the Cut-off date(s) and Blocking condition sections.
2. Level — Company (all plants) or Plant (choose one plant).
3. Order type — select from the dropdown. Only order types created in Recipe 1 appear here.
4. Cut-off date(s) — fields depend on step 1:
   • Weekday: recurrence + weekday + time
   • By date: day of month + time
   • ETA − X: number of days + time
5. Triggers on order status — Saved, Posted, or Confirmed.
6. Blocking condition — set the release window. Not shown for ETA − X.
7. Read the SUMMARY panel. It renders the whole rule as one sentence — "This order type at company level cuts off every Monday 00:00; orders in saved status are blocked for 0 day(s) after cut-off." Confirm the sentence matches your intent before saving; it is the fastest check that the three axes combine the way you expect.
8. Press CREATE RULE.

Caution — defaults are zero, and zero is a valid rule. The form opens with time 00:00 and 0 day(s). A rule saved on those defaults cuts off at midnight and blocks for zero days. Nothing warns you — the summary panel will say so plainly, which is why step 7 matters.

Screen reference — Order Cut-off Day

RSO weekday cut-offs and per-plant AO cut-off day offsets.

4.2 Store Blocking

Owner: Credit Department. This is the only store-level source of BLOCKED — Store Availability closes a store to new orders but leaves in-flight orders alone.

Store Blocking and Store Availability both stop new orders, but they differ sharply on what happens to orders already in flight. Check both before escalating:

The screen header carries a live count — "6 stores currently blocked for overdue payment" — under a CREDIT DEPARTMENT chip. Use it as the at-a-glance check before working through a store's problem.

Recipe 8 — Block or unblock a store for credit

Who: Credit Department

To block:

1. Search for the store in the STORE box, Apply filter. Stores are listed by name over store code; the list runs to many pages, so filter rather than scroll.
2. Press Block on the row (red button — only shown on Active rows).
3. Press Edit to expand the row and set (Edit and Block are independent row actions — the order in which you use them was not observed, so set the fields and confirm both before saving):
   
   
   • Effective Block Date — the date the block takes effect.
   • Block Reason — free text. Write something a support agent can act on; this is what appears in the REASON column and it is the only record of why.
4. Press Done on the row, then Save on the screen.
5. Confirm STATUS now reads Blocked and the effective date and reason are populated.

To unblock: press Unblock on the row, then Save. Status returns to Active and the effective date and reason clear to —.

Caution — Save is a separate step. Block, Unblock, and Done only stage the change on screen. Nothing is committed until Save is pressed. Navigating away first discards the edit.

Screen reference — Store Blocking
Credit-department store blocks and unblocks.

4.3 Store Batch Maintenance

Organize stores into batch profiles for delivery scheduling.

A batch is a named group of outlets serviced by one plant, held in a user-defined delivery sequence. Batches exist for one downstream purpose: they are the primary filter on Order Posting (Part 6), so PPIC can advance a whole delivery wave in one action rather than order by order.

Two rules govern membership:

• Each outlet belongs to exactly one batch, or none. An outlet already in a batch does not appear in another batch's Available outlets list.
• Sequence is the delivery order, set by dragging rows. Position 1 is delivered first.

Recipe 9 — Create a store batch and set its delivery sequence

Who: PPIC

1. Press + New Batch.
   
   
2. Enter a Batch Name. Required, and it must be unique within the plant
3. Add outlets from the AVAILABLE OUTLETS list — press Add on a row, or tick several checkboxes. They move up into OUTLETS IN THIS BATCH, which shows a running count.
4. Drag the numbered rows to set the delivery sequence. The footer confirms "Sequence saved as ordered above."
5. Press CREATE BATCH.

CREATE BATCH stays disabled until both conditions are met — the footer states which is missing: "Batch name and at least one outlet required."

To delete a batch: use the trash icon in the batch panel header.

Confirm before relying on this. Whether deletion is blocked when a batch is referenced by orders already in flight is not established, and neither is whether its outlets return to the unassigned pool. The batch is a posting filter, so the likely risk is a posting run that silently returns nothing rather than data loss. Confirm both before deleting a batch on live data — see Appendix B, gap #17.

Screen reference — Store Batch Maintenance

Part 5 — Placing an order

Two creation screens cover every order type. Which one you get is decided by the order type's archetype (Recipe 1, section A):

Both are reached from Order Listing → + New Order.

Note — order type codes differ from the PRD. The build ships TRSO, CAD, ALO, and INTERPLANT. The PRD names these RSO, CAD, ALO, and INP. Read TRSO as the PRD's RSO throughout. See A.4.

5.1 New Forecast Order (RSO)

Enter requested quantities per delivery date across the 14-day window. Each date locks independently at its RSO cut-off.

The defining property of this screen: it is one order spanning up to 14 delivery dates, and each date locks on its own. A single TRSO document can have some dates locked and others still open at the same time. The order-level status shown elsewhere is reference-only — enforcement is per date.

Recipe 10 — Create a forecast order

Who: Store User

1. Check the Order Type info panel. It shows the type's Archetype, Type code, Display label, and ACTIVE state — read-only, and marked "Configured in Order Type Maintenance — read-only here." If something is wrong, fix it in Recipe 1, not here.

2. Set the Value Filter, then press Generate. This builds the grid; nothing appears until you do.

   • Source Plant (Vendor) — the plant that will supply the order.
   • ETA Range (≤ 14 days) — the delivery window.
   • Category — All Category, or one category to generate a subset.

3. Read the four tiles before entering anything:

   Tile	Meaning
   TOTAL UNITS	Sum of all quantities on the order
   TOTAL ORDER VALUE	Units × effective price on the order date
   OPEN DATES	Dates still editable, out of the total in the window — 14/14 means nothing has cut off yet
   LINES WITH QTY	Item rows carrying a quantity, out of rows generated

4. Enter quantities in the grid. Rows are grouped under category headers and show item name over item code. Columns are one per delivery date, labelled with weekday and day number.

   • A cell with a number input is open. Quantities are capped at 9999 — any input above that is rejected.
   • A cell past its RSO cut-off for that date is read-only and displays the committed quantity next to a 🔒 lock icon (e.g. 12 🔒). The number is the quantity already committed on that date; the icon marks that it can no longer be edited.

5. Use the Listing Filter (Search item name or SKU…) to narrow a long grid. It filters the rows on screen; it does not re-generate. Clear restores the full generated set.

6. Check the DAILY TOTAL row at the foot of the grid — per-date totals plus a grand total. This is the fastest check that quantities landed on the dates you intended.

7. Press Submit Order.

Note — reading locked cells and the row TOTAL. Each locked cell now shows the committed quantity next to the 🔒 icon, so the row's TOTAL reconciles against what you can see: TOTAL = sum of open-cell inputs + sum of locked-cell quantities. An item showing 1 and 5 in open cells with locked cells of 3, 3, and 3 carries a TOTAL of 15. This replaces the previous behaviour, where locked cells rendered as CLOSED and the balance in TOTAL was not directly visible.

Note — what the earliest open date drives. The screen states: "Dates past their RSO cut-off display as CLOSED and lock independently. The earliest open date drives the AO cut-off and PO delivery date." Shrinking the window from the front therefore moves the AO cut-off — relevant when a store asks why the AO deadline shifted without a config change.

Screen reference — New Forecast Order

Element	Behaviour
Order Type chip + strapline	Type code and its rule summary — "Regular Store Order — 1 per plant / day"
Order Type info panel	Archetype · Type code · Display label · Active state. Read-only
Value Filter → Source Plant · ETA Range (≤14 days) · Category + Generate	Builds the grid. Required before any entry
Listing Filter → search + Search / Clear	Filters generated rows; shows "Showing n rows"
Tiles	Total Units · Total Order Value · Open Dates · Lines with Qty
Quantity by delivery date grid	Rows grouped by category; one column per date. Open cells accept a numeric input capped at 9999. Locked cells (past cut-off) render as <quantity> 🔒 — the committed quantity is shown next to the lock icon, read-only
TOTAL column	Row total = sum of open-cell inputs + sum of locked-cell committed quantities
DAILY TOTAL row	Per-date totals + grand total
Pagination	10 / 20 / 50 / 100 rows
Submit Order	Creates the order

5.2 New Ad-Hoc Order

One standardized form for every non-RSO order type. Pick a type — the form adapts its rules and fields.

One form serves every non-forecast archetype. Selecting the order type chip reshapes the form — the Additional Details section renders that type's custom fields (Recipe 1, section G), and the required-field set changes with it.

Recipe 11 — Create an ad-hoc order

Who: Store User or PPIC, depending on the type's creation access

1. Pick the order type chip. Chips render as CODE · label — e.g. CAD · Cake accessories, ALO · allocation, INTERPLANT · Inter-plant. The info panel beneath shows the type's description. Set this first — everything below adapts to it.

   The chip set you see depends on where you are logged in. The screen filters order types by the Location & direction configured on each type (Recipe 1, section D), against the location class of the logged-in user:

   Logged in as	Order types shown
   Outlet	Types with direction Outlet → Warehouse only
   Warehouse	Types with direction Warehouse → Outlet and Warehouse → Warehouse

   A type you expected but cannot see is usually a login-scope mismatch, not a permission or activation problem — verify the user's location before opening Order Type Maintenance.

2. Complete Order details. All four are required:

   • Source Plant (Vendor)
   • ETA / Delivery Date — a single date, unlike the forecast order's range
   • Sub-type
   • External Document Ref

3. Complete Additional Details. These are the order type's custom fields and vary by type — for CAD the build shows Client Name and Birthday, both required.

4. Add line items with + Add item. Each line carries Code, Item Name, Category, Unit Price, AO Qty, and Line Total. The header shows a running count ("Line items · 0").

5. Press Submit Order.

Warning — External Document Ref is marked required but reads as optional. The field carries a required marker while its placeholder text says "Optional reference." Treat it as required — the marker governs. This is a UI inconsistency, logged as Appendix B gap #14.

Note — ad-hoc orders enter at AO, not RSO. Line items capture AO Qty — there is no RSO tier on this form. This matches the PRD's order-type matrix: only RSO/TRSO carries an RSO quantity; every other type starts at AO. (PRD §6.2.)

Screen reference — New Ad-Hoc Order

5.3 Order Listing and Order Details

Order headers across all types and plants. Status is reference-only; RSO locks per ETA date.

Order Listing is the entry point to everything in this part — it carries the + New Order button and is the only route to Order Details.

Important — "Status is reference-only". The header states it, and it is the rule that explains most confusion on this screen. For TRSO, a header-level status does not tell you what is editable — each ETA date locks independently at its own cut-off. Read the status as a summary, not as an enforcement statement. Actual enforcement is the 🔒 state in the forecast grid and the BLOCKED LINES tile in Order Details.

Recipe 12 — Find an order and adjust its AO quantity

Who: PPIC (AO entry happens while the order is in Posted status — PRD §5)

1. Filter the list by ETA Date Range, Order Type, and Source Plant, then Apply filter.

2. Identify the order by Order ID, or by Purchase ID once the order has generated a PO. The Lines column shows how many item lines it holds — useful for spotting an order that generated fewer lines than expected.

3. Press … in the More column and choose Edit. This opens Order Details.

4. Read the tiles first:
   
   

   Tile	Meaning
   TOTAL RSO QTY	What the store requested
   TOTAL AO QTY	What is actually being ordered to production
   TOTAL AD QTY	What was actually delivered from source. Populated once the order reaches the Delivery stage; blank earlier
   NET DIFFERENCE	AO − RSO. Non-zero means PPIC has adjusted the store's request
   BLOCKED LINES	Lines failing an availability or governance check. Red-outlined — any value above 0 needs action before posting

5. Edit RSO Qty, AO Qty, and (once delivery is recorded) AD Qty in the highlighted band. Quantities carry 4 decimal places — fractional quantities are accepted.

6. Check the per-line Status chip. It reflects that line's lifecycle stage (SAVED, and so on).

7. Press Save.

Caution — which quantity is editable depends on status. RSO qty locks at Posted; AO qty locks at Confirmed; AD qty locks at Completed (spec — PRD §5). The tiles remain visible at every stage, so a value being displayed is not evidence it is editable. If an edit will not stick, check the order's stage on Order Posting before raising a defect.

Screen reference — Order Listing

Screen reference — Order Details

Part 6 — Order Posting

Posting advances orders one stage at a time — Saved → Posted → Confirmed → Completed. Pick a lifecycle stage below to view those orders and post them to the next stage.

Who: PPIC, at plant level. Access is restricted to Plant users (per product owner; the underlying permission is PRD §6.10 — the exact permission name is Appendix B gap #15).

Important — the daemon does this work; the screen is for exceptions. Saved → Posted and Posted → Confirmed run automatically on a daemon. The screen states it on the stage banner: "Normally automated by the daemon — manual posting is for exception handling." Only Confirmed → Completed is manual by design.

Post manually when the daemon has nothing to act on, has failed, or a specific order must move ahead of its schedule. Manual posting is not the routine path, and using it as one hides the underlying cause — most often a missing cut-off rule.

How the daemon decides what to advance

The daemon polls every 30 minutes. It does not fire once per transition at a fixed clock time — every run re-evaluates what has become due since the last one.

On each run it reads the Order Cut-off Day rules (4.1) and checks orders by order type and order status. An order advances when a rule matching its order type and its current status has passed its cut-off.

Important — no cut-off rule means the daemon has nothing to act on. Cut-off configuration is what tells the daemon which order types and statuses to check. An order type with no cut-off rule is never blocked (4.1) — and by the same mechanism its orders are never advanced automatically. They sit where they are until someone posts them by hand.

This is the first thing to check when a whole order type is stuck in one stage and nobody can say why. (Consequence of the cut-off-driven design — confirm the exact behaviour before relying on it: Appendix B, gap #28.)

Warning — the on-screen Daemon Lifecycle strip is illustrative. The strip showing per-stage times — "fired 06:00", "next run 14:00" — is example content, added at user request to explain the lifecycle. It is not live scheduling state. Do not read a last-run or next-run time from it, and do not use it to decide whether the daemon has run.

Diagnose from the orders instead: check the Blocked stage filter, then check the cut-off rules configured for that order type.

Recipe 13 — Post orders to the next stage

Who: PPIC (Plant)

1. Pick the lifecycle stage — Saved, Posted, Confirmed, Completed, or Blocked. This selects which orders you are looking at, and the banner then names the transition you are about to perform.
2. Confirm you actually have an exception. The daemon polls every 30 minutes and advances anything whose cut-off has passed, so an order still sitting here well after its cut-off usually means no cut-off rule covers that order type and status — check section 4.1 before posting by hand. Posting manually around a missing rule fixes one order and leaves the cause in place.
3. Filter the working set. Four filters, then Apply filter:
   • Store Batch — the delivery wave from Recipe 9. This is the intended primary filter; batches exist for this screen.
   • ETA Date Range
   • Category
   • Order Type
4. Review the rows. The count is stated above the grid — "Saved orders — 27 in view."
5. Post. Either press Post → on a single row, or tick rows and press Post Selected (n). The button carries a live count of the selection.

Important — rows are order-items, not orders. Each row is one order × category, labelled TRSO-90024: Order Item ID (90042). A two-category order occupies two rows and can be posted one row at a time. Selecting an order ID does not select the whole order — check the count on Post Selected (n) against what you intended to move.

Note — reading the RSO / AO columns before posting. A row where AO Qty is 0 while RSO Qty is populated has not had its AO quantity entered. Posting Saved → Posted locks RSO qty and opens the AO window; posting Posted → Confirmed locks AO qty. Sweep for AO Qty = 0 rows before advancing past Posted, or the order confirms at zero.

The Blocked stage filter is the troubleshooting entry point for Recipe 6. It shows what has failed an item-availability, store-availability, or store-blocking check, which tells you which of those three modules to open.

Screen reference — Order Posting

Part 7 — Auto-GRN

Scan-to-receive. Desktop and mobile share the same screen — the mobile view reflows automatically.

The last step in the chain: the store confirms what physically arrived, and inventory updates in real time. The header carries a MOBILE badge and the strapline: "Scan-to-receive on a mobile device. Sign-in is handled by the Xilnex Portal session — no separate identity step. Phase 2 is confirmation-only: the store user confirms the stated AD quantity; discrepancies are flagged for manual handling."

Screen layout. On desktop the screen is a two-panel view — the phone preview on the left (the exact screen a store user sees on a device) and the RECEIVING FLOW panel on the right showing the four numbered steps, plus the USER ACCOUNTABILITY and TRACEABILITY tiles and the EDGE CASES TO HANDLE list. On a phone the layout reflows to the phone preview only.

Two properties define the Phase-2 scope:

1. Confirmation-only. The store user confirms the stated AD quantity. There is no received-quantity field — received-qty entry is AR, deferred to a later phase. Discrepancies between delivered and expected quantities are flagged for manual exception handling, not corrected on the device.
2. No separate sign-in. Authentication is inherited from the Xilnex Portal session — the pre-scan screen opens straight into the camera. The Signed In chip in the header confirms the inherited session. User accountability comes from the Portal session; traceability comes from the QR code.

Recipe 14 — Receive a delivery by scanning the DR

Who: Store User

Before you start: have the physical Delivery Receipt in hand and verify the goods against it. The scan records a confirmation — it is not the check itself.

Right-panel tiles (desktop only)

On the web build the Open phone scanner button hands off to the device camera; in a browser this is the browser's camera prompt. The flow is otherwise identical.

Edge cases to handle

Note — where a discrepancy goes. If the physical count does not match the DR, the device gives you nowhere to record it — that is by design for Phase 2. Confirm nothing, and raise the discrepancy through manual exception handling. Confirming a DR you know to be wrong posts an inventory movement that does not match what arrived.