Sales Order (Internal)

Record what a customer has agreed to buy before anything is invoiced or shipped. A finalised sales order posts nothing to the General Ledger and moves no stock, but it does count against available stock and the customer’s credit, and it can hold reservations. It is later knocked off into a Sales Invoice, Delivery Order or Packing Order.

Overview

The Sales Order (Internal) applet records what a customer has agreed to buy before anything is invoiced or shipped. Sales administrators create and finalise orders. Delivery Details and Send To Queue feed the Pick Pack Queue; from it a line goes either to the warehouse picking queue (Send To Warehouse Picking Queue, worked in the Warehouse Management applet) or to a delivery job (Create Delivery Job, worked in Delivery and Installation). Delivery Items is a view of the lines’ own delivery fields. The order is then knocked off into a Sales Invoice, Delivery Order or Packing Order. It also hosts the marketplace (Ecomsync) order feed, delivery planning and stock reservation.

Where it fits

Screens and menus

Route root: applet/tnt/wavelet/erp/internal-sales-order-applet/.

The create / edit form

Tabs, in the default order (re-orderable under Default Selection): Search Document, Main Details, Account, Lines, ARAP, Delivery Details, Delivery Trips, Delivery Plans, Settlement, KO For, Receipt Voucher, Department Hdr, TraceDocument, Contra, Doc Link, Attachments, Export, Ecomsync, Status, Events, Gross Profit. Search Document and KO For are shown for TEMP/DRAFT documents only.

Most of the tabs are what their names say — Account holds the customer, Bill To and Ship To; ARAP, Contra, Settlement and Receipt Voucher hold what has been paid or offset against the order; Department Hdr, TraceDocument, Doc Link, Attachments and Export are the analysis codes, posting trace, linked documents, files and export; Ecomsync is the marketplace status; Events is the system event history. Six tabs do something the screen does not tell you:

Inside a line: Item Details, Grouped Item, Serial Number (with import), Batches, Bin, Stock Availability (including availability by job and temporary reservation), Reserved Stock, MRP (job-order link), Costing Details, Issue Link, Sales History, Membership Points, Attachment, Ecom Sync.

The screenshot that stood here has been withdrawn: the capture showed real rows on a staging tenant carrying identifying data. A replacement taken on a synthetic demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

The screenshot that stood here has been withdrawn: the capture showed real rows on a staging tenant carrying identifying data. A replacement taken on a synthetic demo tenant is on the list.

Fulfilment screens

The screenshot that stood here has been withdrawn: the capture showed real rows on a staging tenant carrying identifying data. A replacement taken on a synthetic demo tenant is on the list.

The screenshot that stood here has been withdrawn: the capture showed real rows on a staging tenant carrying identifying data. A replacement taken on a synthetic demo tenant is on the list.

Settings menu

The Settings menu carries the standard entries — Email Template, Custom Resource Bundle Configuration (relabel), Custom Field Placement, Webhook, Feature Visibility, the permission listings, Role Pricing Scheme Link, Permission Wizard, Client-Side Permission, Audit Trail, Release Notes and Applet Log — and six whose effect is somewhere other than the screen you set them on:

The screenshot that stood here has been withdrawn: the capture showed real rows on a staging tenant carrying identifying data. A replacement taken on a synthetic demo tenant is on the list.

Configuration

Before you can use it

Applet settings

Settings › Application Settings is the shared Field Configuration screen; Settings › Default Selection holds the header pre-fills. 344 setting keys reach this applet and 209 of them begin HIDE_ or EXPAND_ — they switch one field, column, tab, button or menu entry off, and flipping one shows you what it did before you have finished reading this sentence. The eight below are the ones that change what the applet will let you do, or what it does somewhere you cannot see from this screen. How settings are stored and who they apply to.

Two things to know before you change anything on this screen. First, the name in italics under each setting is the applet’s internal key. It is there so you can match what you are looking at to what support asks you about; it is not a stable name and it can be renamed, replaced or dropped when the applet is updated, so do not build a script or an integration around one. Second, a setting can be switched back but it cannot be returned to never saved: the first time anybody saves this screen, every toggle on it is written into your tenant’s settings at whatever it was showing, and the applet stops falling back to its own built-in default. The Default when never saved column above is what you give up at that moment — worth reading before the first save rather than after. Checked against the product on 17 September 2026.

On the screen and doing nothing

Five keys here are worth naming because a reader configuring this applet will look for them and conclude the product is broken.

• The disable line item queue listing toggle and the key that actually works are the wrong way round. The toggle you can see and save is Disable Line Item Queue Listing, and it does nothing in this applet — the Purchase Requisition applet honours the same key, which is what makes it look like a working control. The key that does stop the Pick Pack Queue loading its grid is DISABLE_PICK_PACK_QUEUE_LISTING, and it has no control anywhere — the settings screen never offers it. Earlier versions of this page named the visible key as the working one; it is not.
• A fourth disallow sell below price floor (the standard price incl. tax) — a price floor that is saved with your settings and has no effect anywhere. It has no toggle either, so it surfaces only if you read your own settings record or fetch it over the API, and then it looks like a floor you have switched off. The three floors that work are in the table above.
• DISALLOW_SELL_BELOW_MA_COST_WHOLE_DOCUMENT — a slide toggle on the shared screen that reads as refuse to finalise a document whose total is below cost, which is the control a margin-conscious finance team would reach for first. On this applet finalise is never blocked by it. Switching the toggle on changes nothing at all.
• Intercompany enable auto purchase stock — a toggle on the Intercompany panel that the shared screen renders and saves, and that has no effect. The automatic intercompany stock purchase is real and is driven by two other things — the branch’s intercompany setting in AUTO mode with a stock-purchase entity and branch, and the intercompany auto-purchase stock-location configuration. Switching this on does not enable it and switching it off does not disable it.
• Filter by today’s transactions — saved by the shared screen with no control rendered for it and no effect in this applet (the same key name is a live listing filter in other document applets).

Sixty-two more keys sit in the applet’s settings model with no control on any of its settings screens. Most are inert HIDE_* partners or are set elsewhere — the ENABLE_CUSTOM_STATUS_*, NAME_CUSTOM_STATUS_* and LIST_CUSTOM_STATUS_* families belong to Settings › Custom Status — so they are not listed here. WORKFLOW_PROCESS_GUID does have a control: the Workflow Selection panel of Application Settings sets it (see Document behaviour settings).

Document behaviour settings

Who can change what

Two different things govern this screen and they are not interchangeable: a setting is tenant-wide and changes the applet for everybody, a client-side permission is granted to a role and changes what one person sees.

Server-side. TNT_API_DOC_INTERNAL_SALES_ORDER_{CREATE,READ,UPDATE,DELETE}_TGT_GUID, with branch targets scoping the listing. These are the only ones that can return a 403; everything below is decided in the browser.

Client-side permissions registered for this applet: 24 ACTIVE. The ones worth granting deliberately:

• ALLOW_SELL_BELOW_MIN_PRICE, ALLOW_SELL_BELOW_REPLACEMENT_PRICE, ALLOW_SELL_BELOW_MA_COST — the standing exception to each price floor above. A holder is never stopped; everyone else needs a line approval each time.
• SHOW_DRAFT_BUTTON — returns a FINAL order to draft, and the two places the button appears do not agree on what it needs. On the listing the setting or the permission is enough, the same rule as every grid column. On the order’s own screen it needs the setting and the permission. So with the setting off, a permission holder can return orders to draft in bulk from the listing but finds no DRAFT button inside the order; with the setting on, everyone has it on the listing and only holders have it inside.
• SHOW_GROSS_PROFIT, SHOW_COSTING_DETAILS — the margin and cost tabs on the order. Grant with the same care you would give a cost report, and read the limit below before you rely on withholding them.
• ALLOW_PRINT_DRAFT_GEN_DOC — printing an unposted order, which is how a draft ends up in a customer’s hands looking like a confirmation.
• SHOW_INTERCOMPANY_SO_SCREEN, SHOW_DELETE_CONTRA — the intercompany tab, and deleting a contra that has already been applied.

Registered and doing nothing here. SHOW_LAST_PURCHASE_PRICE is ACTIVE for this applet, but the line panel that honours it is never shown on a sales order, so granting the code changes nothing here. HIDE_PRICE and SHOW_UNIT_PRICE_STD_PRICING_SCHEME are in the registry with status DELETED, and no screen can create a definition to grant in their place.

Read by the applet and missing from the registry, so no role can hold them and the behaviour they guard is unreachable: ALLOW_SELL_ABOVE_UNIT_PRICE_STD_INCL_TAX (the exception to the price ceiling — see the table), ALLOW_APPROVE_SELL_BELOW_PRICE (the code that decides who may approve a below-floor line), and the menu family SHOW_SO_DETAILED_REPORT_MENU, SHOW_PICK_PACK_QUEUE_MENU, SHOW_DELIVERY_ITEMS_MENU, SHOW_ECOMSYNC_MENU, SHOW_BATCH_PRINTING_MENU, SHOW_DELIVERY_PLAN_MENU, SHOW_CALENDER_MENU, SHOW_FILE_EXPORT_MENU — each the intended escape hatch for the matching HIDE_*_MENU setting, none of them grantable, so hiding one of those menus hides it from everybody.

A permission that gates a setting. The Lock Amount toggle (DISABLE_EDITING_AMOUNT_TXN) is only rendered on the Application Settings screen for a user who holds SHOW_DISABLE_EDITING_AMOUNT_TXN_SETTING. If an administrator cannot find that toggle, the missing piece is a permission on their own account, not a setting.

Fields

Main Details takes the selling company, branch and location (the only two fields the form insists on, pre-filled from Default Selection), the transaction date, currency and currency rate, sales agent, the customer’s credit terms, credit limit and due date, a reference, remarks and external remarks, the workflow status and resolution, the Sales Order Status drop-down, Custom Status 1-5, and a row of optional header attributes — tracking ID, permit number, client key and value, CRM contact, sales lead, member card, marketplace shipping fee and courier service provider (the marketplace ones are filled by Ecomsync). Account takes the customer (Entity ID, required) with billing and shipping contacts and addresses, and an Intercompany sub-tab that is permission-gated. Lines take an item (parent/alias family search; bundles and grouped items expand into child lines), quantity and UOM, the price, discount, net and transaction amounts and tax code, serial numbers (importable from a delimited file), batches, bins, reserved stock and availability, an MRP tab with three request statuses and a job-order link (with ENABLE_MRP_JOB_ORDER_LINK and MRP_MANDATORY_FOR_NON_FINISHED_GOODS on, the screen holds a line whose item lacks the Fast Moving Goods label until one status is REQUESTED — a job order is not required, and the API does not check it), remarks, Custom Status 1-5 and the four department analysis codes — segment, dimension, profit centre and project. The fields below behave in ways the screen does not show:

Settlement (deposits): date and amount always required; card fields per MANDATORY_*; cheque number for cheques; transaction number for bank transfer when MANDATORY_TRANSACTION_NO.

Contra: contra amount required.

Delivery Plan: code, name, start date and session duration required.

Lifecycle and effects

FINAL validation (on the server, both paths): exchange rate when currencies differ; customer not blacklisted; serial and batch quantities only when the serial setting is passed; bin quantities always; no coupon serial number listed twice (since 28 September 2026); stock balance — the inside button asks for that check to be skipped and the listing’s request says nothing, which the server reads as check, but the check looks only at lines that move stock and an order’s lines move none, so nothing is refused either way; date and company present; fiscal period not locked. Nothing about credit — that check lives in the browser (see Fields).

Two FINAL buttons, two backend paths

Finalise is its own step, not a save — and this applet has two of them. The FINAL button inside an order and the bulk FINAL on the listing take different paths, and the difference is not cosmetic:

So a FINAL sales order usually has an empty Date Finalized — that is the inside-the-order button at work, and it is the route most people finalise by. If a month-end report counts orders by the date they were finalised, count by the event history or the audit trail instead.

What FINAL does on the server: assigns the running numbers and starts the main posting job. No journal, inventory or receivable posting follows, because a sales order moves neither stock nor money. What the posting job does set off is not fixed: it runs only the follow-on jobs your tenant has switched on (each has its own trigger configuration) and that the company’s include/exclude list allows. Three are specific to the sales order and worth knowing by name — but they are not the whole list. Around thirty more subscriber jobs can run for a hand-keyed order wherever your tenant has them on, among them the journal and cashbook posting of the order’s settlement lines (the deposits below rely on exactly that), the e-invoice queues and the points processors. The three:

Two more run outside that list. The message-template (e-mail) job runs for the listing’s FINAL, an API finalise and a marketplace ingestion — never for the button inside the order. The commerce order-file transfer runs only when your tenant subscribes to the INTERNAL_SALES_ORDER_TRANSFER_FINALIZED webhook topic — a subscription nothing creates for you, so without it the transfer never happens — and only for an order created or saved with FINAL already in its body; neither FINAL button starts it (see the table above).

What FINAL does in the browser, after the server answers — these are requests the applet makes, not jobs, and a failure in any of them leaves the order FINAL with the step undone and only a toast to say so: the knock-off links are written; the editing lock is released; the job-order temporary reservations are moved to FINAL; an MRP request e-mail goes out for every line whose production, schedule or existing-stock request is at REQUESTED, when enableMrpEmails and a template are set on the shared settings screen; the default printable opens if ENABLE_AUTO_POPUP is on; and the Sales Invoice conversion dialog opens if ENABLE_SALES_ORDER_TO_SALES_INVOICE_AUTO_CONVERSION is on. The listing’s bulk FINAL raises the same success action, but reads the editor’s draft store to do it, which the listing has not filled — from there these steps are usually no-ops.

Journal: none. Stock: no inventory transaction; the order’s un-invoiced balance is subtracted from available quantity — a partly invoiced order holds back only its un-invoiced balance, a closed line nothing, and an order in a company without the SO → SI Knock Off Configuration pair nothing at all. Where used, reservations hold specific quantities, serials or bins.

Pick Pack Queue: FINAL puts nothing in it. The Delivery Details panel’s Send To Queue button sends each line with Require Delivery = YES and its Qty To Deliver. Cancelling a delivery job puts the row back; sending rows on to the warehouse picking queue removes them. Of the Delivery Details fields themselves, tracking ID and type of order are saved with the order and used by nothing downstream, and only Send To Queue moves anything — but the delivery branch is not inert. It is a branch-permission field: setting a delivery branch makes the order visible to whoever has access to that branch, as well as to the order’s own branch, which is usually what you want and is never stated on the screen. It is also a filter on the document listings.

Knock-off: an invoice created from the order is linked to it line by line; the SO Line with SI KO menu compares ordered against invoiced quantity and lets you close the remainder (Close ends the order-to-invoice balance; the order-to-delivery balance, if any, is untouched). Both exist only if the company’s Knock Off Configuration has the pair.

VOID sets the status and reason and starts the void job, which releases document links and reservations through its own list of follow-on jobs. The pick-pack void job is one of them: where your tenant has it switched on it deletes the order’s Pick Pack Queue rows and its warehouse picking list — unless the picking list has already been sent for packing — and does so for sales orders only. It is not switched on for you, and without it a voided order’s pick-pack queue rows stay exactly where they are — the Pick Pack Queue keeps offering a cancelled order for delivery. Delete them from the queue by hand after a void until it is enabled for you.

The order’s balance: what Available, the credit check and SO Line with SI KO read

An order moves no stock, so everything it does to availability and credit runs through one stored figure: the open-queue balance, one row per order line per follow-on document type, written by the open the order for knock-off job after FINAL — seconds later, not as part of it. The job writes a row only for the pairs the company’s Knock Off Configuration enables for sales orders, and from then on each knock-off link saved against the line rewrites it, and deletes it when it reaches zero.

Follow one GadgetSphere order through it. Branch GS-KV-01 holds 25 ultraportable laptops and takes a corporate order for 10 at RM 4,200.

Invoicing does not change Available: the invoice takes 6 off the shelf and 6 off the balance together. Only the Close gives stock back, and the Close is a decision somebody makes (below).

Where each figure comes from.

• Available on the Stock Availability main listing is stock on hand at the location, minus the Sales Order → Sales Invoice balances held there, minus reservations. It reads that one pair only, so a company that fulfils orders with delivery orders alone has correct delivery balances and orders that never lower Available. And it reads the balance row by itself — it does not look at the order or the line the row belongs to, which is why a row that outlived its order goes on counting.
• Held against the credit limit is the same Sales Order → Sales Invoice balance, priced at the line’s unit price, for FINAL orders only. So a balance left behind on a voided order lowers Available and leaves the customer’s credit alone — the two figures can disagree about the same row.
• On SO Line with SI KO, Qty Received is recomputed from the invoice knock-off links each time you open the screen; Qty Outstanding is the stored balance; Qty Closed is what is left when both are taken from Qty Ordered. A negative Qty Closed therefore means the stored balance is higher than the invoices justify. Lines removed from the order are left off this screen even when a balance survives on them.

How you know the balances are right

Two checks, worth a minute at month-end. On SO Line with SI KO, search with Posting Status VOID and Qty Outstanding Filter YES: every row is a voided order still holding stock back. Then search Qty Outstanding Filter YES alone and sort by SO Date: the oldest rows are the orders somebody has stopped expecting to invoice.

Void, Discard and Close: what each does to the balance

A void that leaves the balance behind is a known issue, reported to engineering: where the follow-on job did not run, the voided order’s rows stay and go on lowering Available. Giving quantity back when an invoice linked to the order is voided also re-creates a row without checking that the order itself is still live. The month-end search above finds them; the repair is in Financial Report › Error Checking › Trace Document, where Missing Reversal Queue reads Error — Queue present for a voided order that still has rows and Resolve deletes them. The steps are in The order still shows a quantity outstanding after I invoiced it all.

A voided order is the easy case. VOID on a part-invoiced order is refused while its invoice links are live, and the refusal names the invoices — so Close is the tool for an order the customer has stopped wanting. A row left on a line removed from the order has no Close button, because the line is not on the screen; that one is a support repair.

Who closes a stale line, and when

Close is the same button for a line the customer cancelled and for a balance that should never have been there, so it is a judgement about the order rather than a stock correction. It belongs to whoever owns the order — usually the branch or sales admin, not the stock controller who noticed Available was low. Before pressing it, check two things on the line: Qty Received equals what you invoiced, and there is nothing more you intend to invoice. If either is uncertain, leave the line open. You know it worked when the row shows Closed under Queue Closed Status and Available at the order’s location has risen by the quantity the row was holding. Close needs a login allowed to delete open-queue entries, so who can press it is set in the role, not on this screen.

What the order will not do

• Check stock when it is finalised. FINAL runs the server’s stock check, and that check counts only lines that move stock — an order’s move none — so an order for more than you hold finalises normally. The check that can refuse the sale is the one on a document that moves stock, such as the sales invoice. If you promise from the order, look at Available first; that look is the control.
• Measure an order placed through the customer portal against the credit limit. The credit check is this screen’s, in the browser, so an order the portal converts on the server never meets it. With ENABLE_CREDIT_LIMIT_FILTER on, the FINAL button inside the order also acts only for a customer the available-credit lookup returns; for a customer it returns nothing for, the click neither finalises nor shows the refusal. Which customers that is, we have not established.
• Count its delivery balance against Available. Only the invoice balance counts (above).
• Recover a balance that never appeared. If the open-queue job did not write the rows, the order is FINAL and invisible to KO For and to Available until someone re-queues it in Data Fix — see Troubleshooting.

Deposits taken on the order

A deposit can be recorded two ways, and they are not interchangeable. The worked example, from collection to close, is in Creating a Sales Order.

VOID is refused while the order has any live link to a target document, and the error lists those documents. Since 23 September 2026 it is also refused while the order’s warehouse picking list is at pending picking — the message names the packing status, though its error code reads as the e-invoice refusal. It does not check for deposits or contras. Close, whether on a SO Line with SI KO row or the order’s own CLOSE button, ends the open quantity only. It moves no money.

Using the deposit on an invoice. In the invoice’s KO For, picking an order with a balance asks Transfer Available Credit?. Yes contras the order’s whole balance to the invoice, so a deposit larger than a partial invoice leaves the invoice in credit. An invoice converted on the server from the whole order does the same without asking. A refund is a payment voucher to the customer, contra’d to whichever document now holds the credit.

Related applets

• Sales Quotation (Internal), Jobsheet (Internal) — knock-off sources.
• Sales Invoice (Internal) — the usual next document; converter SalesOrderToSalesInvoiceConverter.
• Delivery Order (Internal), Packing Order (Internal) — fulfilment.
• Delivery Installation — delivery sessions planned here.
• Receipt Voucher (Internal) — deposits against the order.
• Purchase Order (Internal) — intercompany mirror and auto stock purchase.
• Stock Availability, Stock Reservation — what an open order does to available stock.
• Tiktok Sales Order Applet — the marketplace build of this applet: same documents, shorter sidebar, Lazada / Shopee dashboards.
• Shopping Cart Customer Access (Internal) — a customer login’s cart becomes a FINAL sales order here when it is submitted.
• SO Consolidation — batches many FINAL sales orders into one consolidated sales invoice per company, branch, customer and sales agent.
• Customer, Pricebook, Cashbook, Chart of Account, Workflow Design — master data and workflow.

Troubleshooting

Related documentation

• Standard Sales Workflow, Partial Delivery Workflow, Installation Scheduling Workflow
• The order still shows a quantity outstanding after I invoiced it all — the three ordinary causes of a stale balance and the repair for each
• Inventory module, E-Commerce module, Financial Accounting module
• Sales Workflow applets