A Transfer Note (TN) is the document that records stock moving from one location to another — HQ to outlet, outlet to outlet, or inter-company. It is not a single event but a state machine spanning two branches and up to four sibling documents. The confusion that generates support tickets almost never comes from creating a TN; it comes from the partial states (part-shipped, part-received), from the three differently-named override actions that force a TN out of them, and from cancellation, whose rules differ depending on which end of the transfer you are standing at and which platform you are on.
A TN's status is a derived display value, not a stamp that advances one notch per action. It is computed from the outstanding quantity on the document, and every state except the terminal one is shipment-side. Three quantity counters on each item line feed it:
| Counter | Owned by | Meaning |
|---|---|---|
| Transferred Quantity | Sender, at creation | What the TN commits to move |
| Total Delivered | Sender, at shipment | What has actually been dispatched |
| Total Received | Receiver, at receiving | What the receiving branch has acknowledged |
| Status | Condition | What it means | What is still possible |
|---|---|---|---|
| Saved | Draft, unconfirmed | Still in checking; header and lines editable. | Edit, delete, confirm |
| Confirmed | Total Delivered = 0 |
Finalised and locked. "Already finalize this document and ready for shipment, no edit is allow." Available quantity will b e updated. | Ship, cancel, Post To Sales, Post To Adjustment |
| Partially Shipped | 0 < Total Delivered < Transferred Quantity |
Some — not all — of the transferred quantity has been dispatched. Available quantity will be updated. | Ship remainder, Force Ship, receive, cancel |
| Shipped | Total Delivered = Transferred Quantity, not yet fully received |
Everything committed has been dispatched and is in transit or awaiting acknowledgement. Onhand quantity will be updated. | Receive, Direct Complete, Force Complete, cancel |
| Completed | Everything transferred is both shipped and received | Terminal — read-only. | Nothing; reversal requires a new document |
Receiving less than the delivered quantity produces no visible change. The manual is explicit: "If you only partially received the shipment… the Transfer Note status may remain as Shipped/Partially Shipped until all items are fully received. You can click Receive again later to record additional receipts against the same Transfer Note."
The fallback rule includes Confirmed, which is reachable after dispatch, not only before it: if delivered quantity returns to zero, the TN reads Confirmed again. The documented mechanism is click Advance in Delivery Order → Cancel Delivery Order, which "means the stock will back to original location." Reverse the shipment and the TN reverts to a confirmed, undispatched document.
1.3 State diagram
┌──────────────── cancel ─────────────────┐
│ ▼
Saved ──confirm──► Confirmed ⇄──ship partial──► Partially Shipped
▲ │ │ ▲
(Cancel Delivery ───┘ │ │ │ receive (partial)
Order — delivered │ ship rest / │ └─── no status change
qty back to zero) │ [Force Ship] │
│ ▼
└─────ship all───────► Shipped ◄─── receive (partial)
│ no status change
│
┌────────────┴────────────┐
│ │
[Direct Complete] receive to full
│ │
▼ ▼
Completed + Auto Return TN Completed
▲
│
[Force Complete] ── from Confirmed, Partially Shipped ─────┘
or Shipped: ships everything
outstanding, then auto-receives it
Read the diagram as: horizontal movement is shipping, and only the vertical drop is receiving. Receiving never moves the TN sideways. Force Complete is the exception — it collapses both axes at once from wherever the TN currently sits.
These are constantly conflated because their names collide and they live in different places. They are three distinct actions, on two different documents, at two different ends of the flow.
| Action | Document | Which end | What it overrides |
|---|---|---|---|
| Force Ship | Delivery Order | Sender | Insufficient system stock blocking dispatch |
| Direct Complete | Transfer Note | Receiver | A short receipt — closes the TN and returns the shortfall |
| Force Complete | Transfer Note | Both end | Ships all undelivered quantity and auto-receives everything — straight to Completed, no return note |
Lives on the Delivery Order, not the Transfer Note: Advance → Force Ship.
A Delivery Order is not considered done while quantity remains unsent — typically because system stock at the sending branch is short. Force Ship resolves this by dispatching the full quantity regardless: "This step is to ship all quantity even though there are insufficient quantity show in system."
The important reading: Force Ship is an override of the system's stock record, not of the physical reality. It is the correct action when the goods are genuinely on the truck but the system believes the branch doesn't have them — i.e. the discrepancy is an inventory-accuracy problem upstream, not a shipping problem. It moves a TN from Partially Shipped to Shipped.
Related Delivery Order actions worth keeping separate: Acknowledge (Advance → Acknowledge, or right-click in the Delivery Order List) and Cancel Delivery Order, which "means the stock will back to original location" — a stock reversal distinct from cancelling the TN itself.
The best-documented of the three, and the one with the largest downstream consequence.
Where: Classic — Functions → Direct Complete. Portal — the caret beside CONFIRM → Direct complete.
What it does, per the on-screen confirmation: "System will receive all delivered items and create return transfer note, click OK to continue" — then on success: "Transfernote has been completed and return transfer note created."
Two things happen atomically:
Auto Return is generated for the shortfall quantity, in status Confirmed, with:
The Auto Return TN then has to be processed like any other TN: the counterparty logs in as their outlet, opens it, and receives it to reconcile the shortfall back. Direct Complete does not finish the job — it creates a second job. A TN that has been Direct Completed is closed, but there is now an open Auto Return TN somewhere, at the other outlet, that someone has to action. This is the most common source of a "phantom" open transfer nobody claims ownership of.
Direct Complete is also the sanctioned answer to a partial dispatch from the picking side: "Partial delivery is allowed, if sender outlet do not have enough quantity to ship, may apply direct completed at function transfer note."
Where: Classic — Functions → Force Complete, sitting immediately above Direct Complete in the same dropdown. Portal — the caret beside CONFIRM → Force complete**.
Force Complete drives the Transfer Note to Completed by doing both outstanding jobs at once, on the sender's and the receiver's behalf:
Transferred Quantity is dispatched — the same override as Force Ship, applied from the TN rather than the Delivery Order.The effect on the counters is total:
| Counter | Before | After Force Complete |
|---|---|---|
Transferred Quantity |
n | n (unchanged) |
Total Delivered |
anything from 0 to n | = n |
Total Received |
anything from 0 to Total Delivered |
= n |
| Status | Confirmed / Partially Shipped / Shipped | Completed |
Because it fills the shipping gap as well as the receiving gap, Force Complete is available from any unfinished state — including Confirmed, where nothing has been dispatched at all. Run it there and the entire transferred quantity is shipped and received in a single action.
This is the action with the largest silent consequence in the whole lifecycle. It asserts that the full transferred quantity left the sending branch and arrived at the receiving branch. If either leg is untrue, the system now believes stock exists at the receiver that is not on the shelf, and has deducted stock from the sender that may still be in the stockroom — with no return document and no discrepancy record to chase. Unlike Direct Complete, nothing is generated to reconcile against later. The only trace is the TN itself, already Completed.
Use it to close out a transfer you know is genuinely finished but that the system never caught up with. Do not use it to make a discrepancy disappear.
The two actions close the same gap in opposite directions — one pushes the shortfall back, the other pushes it through.
| Direct Complete | Force Complete | |
|---|---|---|
| Undelivered quantity | Left undelivered | Force-shipped |
| Delivered-but-unreceived | Auto-received | Auto-received |
| The shortfall | Sent back to the sender as a new Auto Return TN | Absorbed — deemed shipped and received |
| Documents created | One (Auto Return TN, new ID, reversed From/To) | None |
| Follow-up work | Yes — someone must receive the Auto Return | None |
| Net stock effect | Receiver gains what actually arrived; the rest returns to the sender | Receiver gains the full transferred quantity; sender is deducted the full quantity |
| Use when | Goods are short and the shortfall belongs back at the sender | The transfer really did complete and the records simply lag |
Adjacent positions, similar names, opposite outcomes. Read the confirmation dialog before accepting — Direct Complete announces "System will receive all delivered items and create return transfer note." If that sentence does not appear, you are not running Direct Complete, and no return note is coming.
Force Ship does step 1 only, and leaves the receiver to do their job normally. Force Complete does step 1 and step 2, removing the receiver from the process entirely. If the receiving branch still needs to count what arrives, use Force Ship.
Cancellation is the messiest part of the lifecycle because the rules differ by platform, by which end you are on, and by which document you are actually cancelling.
Platform | How | Notes |
| Portal | Open the TN → dropdown caret beside CONFIRM (top-right) → Cancel (Reject) | The explicit cancel path |
| Classic | Cancellation exists (it triggers the sync warning below), but the guide documents no Cancel item in the Functions dropdown — that dropdown offers Import, Export, Force Complete, Direct Complete, Barcode, Post To Adjustment, Post To Sales, Layout Setting |
For discrepancy reconciliation in Classic, the documented route is Force Complete / Direct Complete rather than cancel |
Cancelling a TN in Classic that has no locally-synced stock-received record raises:
"No Stock received record found. Data may not be synced. Recommend cancelling at Xilnex Portal. Proceed with cancellation?"
This is intended behaviour, not a bug. It was added after an incident where cancelling a TN with unsynced stock-received data cancelled only the AV quantity and corrupted the TN state. The prompt exists to force the user to check sync status before proceeding — it is a speed bump, not an error.
Sender side — cancelling before or after shipment.
A Shipped TN can still be cancelled even with no stock-received record. The consequence is one-directional and irreversible from the receiver's point of view: once cancelled, the receiving user can no longer receive that TN. If stock has physically left the building and the sender cancels, the receiving branch has no document to receive against — the goods arrive with nothing to book them to.
Receiver side — rejecting rather than receiving.
Portal's action is named Cancel (Reject), which is the receiver-side reading: refusing the transfer rather than retracting it. In practice the discrepancy-reconciliation path (Direct Complete → Auto Return) is the documented receiver-side route for a partial problem; cancel/reject is for rejecting the transfer outright.
Cancelling the Delivery Order is a different action. Advance → Cancel Delivery Order reverses the stock movement — "the stock will back to original location" — without necessarily closing the TN. Cancelling the shipment and cancelling the transfer are not the same operation.
Stock Request ──┬──[Add To Transfer Note]──────────────► Transfer Note ──► Delivery Order ──► Receive (GRN)
│ │ ▲ │
└──► Picking ──► Pick ──► Verify ──► Fulfil ──┘ │ ▼
│ Inventory updated
[Post To Sales] │
[Post To Adjustment] │
│
Direct Complete ──► Auto Return TN ──────────────────────┘
(reversed From/To, new ID)
The natural reading of "stock request → TN → shipment → receiving → picking" puts picking near the end. The documented flow is the opposite: picking is one of the two ways a TN gets created. In Picking module, the Fulfil step generates the downstream document — "Stock request → Transfer note" — and then "Transfer note — will create delivery after posting." Picking is an alternative front end to Add To Transfer Note, not a stage after receiving.
Stock Request → Transfer Note. The outlet raises a Stock Request; HQ opens Listing → Stock Request List, filters Request = To This Branch and Status = Pending, then right-clicks the rows → Add To Transfer Note. The TN is generated pre-populated: Transfer Type Inter Outlet, Transfer From = fulfilling branch, Transfer To = requesting outlet, Status Saved, Bill Status NonBillable. This is the last point at which lines can be corrected — after Confirm, no edits.
Highlighting rows is not selecting them. The grid has a dedicated Select checkbox column; bulk actions act only on ticked rows. Right-clicking → Add To Transfer Note with rows merely highlighted throws "there is no pending or ordered request selected." Fix: tick the checkboxes (or highlight → right-click → Select) first.
Stock Request → Picking → Transfer Note. The warehouse route. Documents are loaded into Picking and confirmed (picker locked at confirm, cannot be changed), then Pick (actual quantity picked, which may be less than expected), optional Verify, then Fulfil — which prompts to generate the TN from the Stock Request based on the fulfilled quantity. The Stock Request lands in Done. Via WMS the picking record walks CONFIRM → PICKED → VERIFIED → COMPLETED, syncing back down to Classic POS at each step.
Transfer Note → Delivery Order (shipment). The TN's Delivery / Ship action opens a Delivery Order. Enter the Delivering Quantity per line — this is where partial shipment originates — optionally assign a driver under Commission, then Ship. Unsent quantity leaves the DO open and the TN Partially Shipped; Force Ship closes it out. The DO for a TN differs from a Sales Invoice DO only in the deliver location.
Delivery Order → Receive (GRN). The receiving branch opens Listing → Transfer Note, filters Transfer Note = Transfer To plus its own branch and a date range, opens the record, and clicks Receive — the button only appears when status is Shipped. That generates a Receive record with Vendor = the sending branch, Invoice No = the originating Transfer ID, Status = NEW, and a Receive Quantity column (yellow, editable) pre-filled to the delivered quantity. Confirm writes Total Received back to the TN, adds stock to the receiving branch, and stamps Last Receive By / Last Receive Date.
This receiving step is Transfer Receive, one of the three GRN entry points alongside Purchase Receive and Direct Receive — the same grid, the same columns.
Transfer Note → Post To Sales. A side-exit from the chain, not a stage in it: Functions → Post To Sales on a Confirmed TN posts the movement to the sales system. The TN must be confirmed first. Two prerequisites are easy to miss and both cause failures at this step: the outlet's ownership settings must be configured (posting requires the outlet to own the relevant items), and Xilnex Connect outlet-default settings must be correct on the client side. Post To Adjustment sits beside it in the same dropdown.
Transfer Note → Auto Return TN. Only produced by Direct Complete. See §2.2.
A practical triage order when someone reports a stuck transfer:
Transferred Quantity, Total Delivered, and Total Received against each other.Total Delivered < Transferred Quantity? The problem is upstream at the Delivery Order, not the TN. Either finish shipping or Force Ship.Total Received < Total Delivered? A short receipt. Either receive again (additive, allowed) or Direct Complete and process the resulting Auto Return.Auto Sync: ON and that both outlets are listed under Outlet Selection — ON alone is not sufficient.