Sales Invoice (Internal)

Use this applet to bill a customer. Finalising the invoice is what does the work: it takes the stock out, posts the sale to the General Ledger and opens a receivable against the customer — so if you need to bill without moving stock, use Sales Invoice (No Stock Out) instead.

Overview

The Sales Invoice (Internal) applet creates the document that bills a customer and, on finalisation, deducts stock, posts the sale to the General Ledger and opens a receivable against the customer. It is opened by sales administrators and accounts staff. Upstream it is usually created by knocking off a Sales Order, Delivery Order, Jobsheet or Sales Quotation; downstream it feeds the Pick & Pack queue, receipts and contra settlement, sales returns and credit notes, e-Invoice submission, sales commission and membership points.

Where it fits

Screens and menus

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

Checking a run of invoice numbers. The advanced search has a Company No field with a from and a to. It is sent to the server as a condition on the company number, so the listing returns every invoice in that range, not only the ones on the page already loaded — which the column filter on the grid cannot do. For an auditor asking for GSD’s invoices 1000700 to 1000780, choose the company, enter the range, and export what comes back; a number missing from the result is one to explain (see Document Numbering for why a number can be spent without reaching a document). The range compares the numbers as text, so keep both ends the same number of digits.

The three number columns are always there. Doc No (Tenant), Doc No (Company) and Doc No (Branch) are ordinary columns on this listing. The applet’s code names the HIDE_SERVER_DOC_1..3 / SHOW_DOC_NO_* pairs but never applies them to this grid, so switching a hide setting on changes nothing here — unlike the Receipt Voucher (v2) or Sales Debit Note listing, where it does.

The create / edit form

The form is a set of tabs whose order is configurable (Settings → Default Selection → Details Tab Ordering). The full set is: Search Document, Main Details, E-Invoice, Account, Lines, Delivery Details, KO For, ARAP, Delivery Trips, Settlement, Settlement Adjustment, Department Hdr, Posting, TraceDocument, Contra, Doc Link, Export, Attachments, Gross Profit, Service Notes. Most tabs can be hidden with the HIDE_*_TAB settings listed under Configuration.

Settings menu

The menu also carries Feature Visibility, Release Notes and the Applet Log, the shared screens every applet has.

Configuration

Before you can use it

Applet settings

Settings › Application Settings. This applet declares 316 settings, and about 205 of them — every HIDE_* and EXPAND_* key — switch a single field, tab, button, column or menu item off, or open a panel by default. Flip one and you can see what it did, so they are not listed here. The seven below are the ones that change what the applet will let you do, or what the server does with the document afterwards. How settings are stored and who they apply to.

Default when never saved is the fallback in the code that reads the key, not the position the toggle happens to be sitting in on a screen nobody has saved — and for the first row those two are opposites.

Two more are worth a sentence rather than a row. CANNOT_EDIT_CURRENCY_RATE makes the exchange-rate field read-only so every foreign-currency invoice takes the rate from the currency master and nobody can override it on the document — which is what you want if the forex gain and loss postings have to be defensible. ENABLE_MULTIPLE_KO lets one invoice knock off several source documents at once.

Where the rest of the settings live

There are three more settings surfaces for this applet besides Application Settings: the applet’s own Default Selection (and a personal copy under Personalization), which pre-fills company, branch, location, pricing scheme, pricebook, unit-price decimal precision and the order of the form’s tabs on a new invoice; Workflow Settings; and the shared Printable Format, Branch, Email Template, Custom Resource Bundle and Custom Field Placement screens. None of those pre-filled defaults is a rule — the user can change any of them on the document.

On the screen and doing nothing

• Negative stock with confirmation — the switch a reader searches for by name, and it does not exist as a control: it is declared in the model, no settings screen offers it and nothing acts on it. The two keys that do govern stock are the first and fifth rows above, and neither behaves the way this name promises.

• DISALLOW_SELL_BELOW_UNIT_PRICE_STD_INCL_TAX — has no toggle on the settings screen and no effect, and is saved as false into your settings every time the panel is saved. The key the price checks actually use is DISALLOW_SELL_ABOVE_UNIT_PRICE_STD_INCL_TAX. There is no way to stop a line being priced below the standard price.

• HIDE_SELL_BELOW_MIN_PRICE, HIDE_SELL_BELOW_REPLACEMENT_PRICE, HIDE_SELL_BELOW_MA_COST — inert, because the settings screen has no control for any of them, so they are never set and the figures are never hidden by them. The control that really decides whether the minimum, replacement and cost figures are printed beside the line is the client-side permission SHOW_PRICE_SELL_BELOW_* — a grant, not a setting.

• The per-line Sell Below Min Price request tab — not shown, here or in Sales Order. The approval route that does work is the Approval menu and its dialog, which is what the troubleshooting table points at.

• Auto Final and Final Button Status — both appear on Application Settings (the second only once a workflow is chosen), both are saved, and neither has any effect: Auto Final is read by no applet at all, and Final Button Status by nothing in this applet, the shared code or the server — the Final button still sends the document to FINAL. There is no automatic finalising of sales invoices to switch on.

• API upload — same: shown, saved, no effect here. The same switch is live in the Purchase Order (Supplier Access) applet, where it shows or hides the API-upload option on the file-import listing, which is why it looks like one that should work.

• The SST and WHT enable and include flags — declared in the model with no control on any screen, and no effect. Service tax and withholding tax on a sales invoice come from the tax codes on the line, configured in Tax Configuration, not from a switch here.

• The custom-status enable keys (line and header, five each) — declared in the model with no control on any screen, and no effect. This applet’s status flow is fixed at DRAFT → FINAL → VOID (plus DISCARDED for drafts) and custom statuses cannot be added to it.

• The five “enable” toggles for the today’s-transactions filter, dimension, profit centre, project and segment — rendered on Field Settings, saved, and read by nothing in this applet or the shared code (deep read of 4 October 2026, every one of the model’s 315 keys traced). The dimension columns on a line come from the Department settings’ hide toggles, not from these.

Used, with no control in this applet. WORKFLOW_PROCESS_GUID is the mirror image: it is read by Main Details on a new document to pre-select the workflow process and its default status, but no settings screen in this applet writes it — Workflow Settings links a company to a process instead. So the key can be in your stored settings without ever having been set from this applet.

Who can change what

Client-side permissions this applet defines: 74 in the registry (73 until ALLOW_PRINT_DRAFT_GEN_DOC was added on 29 September 2026), more than any other applet on the platform. They can only ever add something to what a person sees, and they are enforced in the browser. Grant them through a role. The screens offer links to a team as well, and the platform has a table for them, but the list the applets actually consult is assembled in the browser from your login, the roles you hold, and the client-side permissions those roles hold for the applet you are currently in — one loader, in the shared library, and no applet has one of its own. A grant that does not reach a role therefore never reaches a screen, and the same code granted here does nothing in Sales Order, because each applet is a separate grant. The ones worth knowing are the ones that answer a question somebody actually asks:

The pair a reader trips over. Finalise an invoice and every header field locks. Two come back, and they come back by different mechanisms: the Sales Agent field by the applet setting ALLOW_EDIT_SALES_AGENT_FINAL (above, tenant-wide, everybody or nobody) and the Transaction Date field by the permission SHOW_TRANSACTION_DATE (here, per grantee). Two adjacent fields, two systems, two different administrators, and nothing on the screen says which is which. If somebody asks “why is the sales agent greyed out?” the answer is a setting; if they ask “why can’t I change the date?” the answer is a grant. The listing code states the same pairing outright for the date column: setting HIDE_TRANSACTION_DATE, permission SHOW_TRANSACTION_DATE.

How a setting and a permission combine on one column, exactly. Where a grid column is governed by both — and on this applet’s line grid two dozen are — the rule is an OR, never an AND. A key named HIDE_… shows the column unless the setting is on; a key named SHOW_… shows it only if the setting is on; and in either case holding the matching permission shows it regardless. So switching on Hide AR Balance hides the balance from everybody except the people you have granted Show AR Balance to, which is usually the arrangement you wanted and is never what the toggle’s label suggests. The half that surprises people the other way: turn a HIDE_ setting on and you will lose the column yourself unless somebody grants you its permission.

And one screen declares two dozen of these pairs and uses none of them. The Sales Invoice document listing carries a list of twenty-four column-to-setting-to-permission triples — the transaction date, the branch code, the client document references, the whole AR block, the dimension, segment, profit-centre and project codes — and its own template never passes that list to the grid, so on that screen none of those settings or permissions changes a column. The list on the line-item grid in the same applet is passed and does work. If you have switched on a HIDE_ key expecting a column to leave the document listing and it has not, this is why, and there is nothing to configure.

Dead permission codes. DELETE_ROUNDING_ITEM is registered ACTIVE for this applet and does nothing. Granting it has no effect, and the rounding item cannot be deleted by granting a permission.

A second group is the mirror image — codes the applet reads that are not seeded in the registry, so they will not appear in the permission picker and have to be created by hand before they can be granted: the six SHOW_*_MENU codes, SHOW_PRICE_SELL_BELOW_*, ALLOW_SELL_ABOVE_UNIT_PRICE_STD_INCL_TAX, SHOW_SALES_AGENT, SHOW_MA_COST, SHOW_DEALER_COST, SHOW_ARAP_PNS and SHOW_ARAP_SETTLEMENT.

Server-side permissions, which are the ones that can fail a request with a 403 whatever the browser shows: TNT_API_DOC_INTERNAL_SALES_INVOICE_CREATE_TGT_GUID, …_READ_TGT_GUID, …_UPDATE_TGT_GUID, …_DELETE_TGT_GUID, with the TNT_API_DOC_TMPL_INTERNAL_SALES_INVOICE_* set for templates. The target is a branch, company or customer; a null target means everything.

Settings › Feature Visibility currently exposes a single Teams panel and nothing else.

Document behaviour settings

Fields

Main Details

Account

The customer on the invoice is a copy, not a link

Picking the customer copies their details onto the invoice rather than linking to them: the customer code, the name (with the contact’s name appended when you picked a contact), status, e-mail, phone, GL code, identity number and type, entity type, description and currency, plus the billing and shipping contact and the billing address you choose from their addresses. The credit terms, credit limit and due date on Main Details are part of the same copy.

Nothing refreshes it afterwards. The server fills that block only when it arrives empty, so re-saving the invoice next year, or correcting the customer record, leaves it exactly as it was. That is the design: an invoice is evidence of what was agreed, and it has to keep the name and address it was billed to.

Four things follow, and none of them is visible on the screen:

• Correcting the customer’s details here corrects this invoice only. The customer record is untouched and the next invoice starts from the master data again. Pushing the correction back is a separate act in Customer Maintenance.
• Not everything on an invoice is frozen. The receivable control account is not: the AR/AP type is read from the customer record at posting time, so correcting that moves the account the next time the document posts — Customer Maintenance → The AR/AP type is decided once.
• What a reprint shows depends on the template. The standard Jasper print service hands the layout both the invoice’s stored snapshot and a live lookup of the customer record. A layout built on the live fields prints today’s name and e-mail on a two-year-old invoice. If a reprint has to match the original, build it on the snapshot fields.
• The e-invoice buyer is a third thing again. The buyer block on the E-Invoice tab is not required to be the account you billed, and it is what the e-invoice queue takes when it is filled — My E-Invoice Admin. Whichever button fills that block — Select From Another Customer, or Select Einvoice Address when that one has been hidden — goes grey at FINAL.

Lines

E-Invoice: Submission Type (and Type 2), E-invoice Number, UUID, Document No / Type / Date, EMP Ref Number, Skip E-Invoice, Billing Frequency and Period, Tax Exemption, Buyer Name / ID Type / ID No / TIN / SST ID / Email / Contact, buyer address lines, Country, State, City, Postcode, Validation URL. All optional at save; LHDN validation happens in the e-Invoice queue.

Settlement (Payment tab) — one line per payment (txn_type = STL_MTHD). Types: Bank Transfer, Cash, Cheque, Post Dated Cheque, Credit Card, Debit Card, e-Wallet, FPX e-Mandate, Membership Point Currency, Open Credit, Others, PGW Merchant, PGW Provider Seamless, Voucher, TT Payment.

Every payment line needs a Date and an Amount of at least 0.01. The rest depends on the type — cheque number, and date for a post-dated cheque; transaction number for a bank transfer or e-wallet; voucher number; points and point currency; cash back for cash — and the card fields are required only where a mandatory-field setting asks for them.

What the screen does not show is where a payment line goes after FINAL. Once the invoice has posted to the cashbook, each payment line is a line in the cashbook, and the two stay tied:

• Correcting a payment on a FINAL invoice corrects its cashbook line in place, and adding a payment adds a cashbook line. The change reaches Bank Reconciliation without a new document.
• Once that cashbook line has been reconciled, changing the payment’s amount is refused, with a message naming the cashbook and the bank reconciliation to un-reconcile first. Edits that leave the amount alone still go through.
• A draft never touches the cashbook.

Delivery Details: delivery entity (required when a delivery record is added), address, instructions, and a line grid with Require Delivery (YES/NO) and Qty To Deliver (defaulting to the line quantity). The Send To Queue button sends every line marked YES with its Qty To Deliver to the Pick Pack Queue; cancelling a delivery job puts the row back. FINAL does not do this: an invoice that is never sent never appears in the Pick Pack Queue or on a Delivery Trip. A second send adds to the queued balance rather than replacing it.

Lifecycle and effects

Two gates run before any of the checks below, on the ordinary finalise route. Since 30 September 2026 a foreign-currency invoice whose base currency is set and whose rate is blank or zero is refused outright with Generic Document exchange rate is required before posting to FINAL (HTTP 403, before validation). And since 28 September 2026 a tenant whose DOCUMENTS_SKIP_SHADOW_AND_GL application setting is switched on finalises a foreign-currency invoice with no base-currency twin and no posting at all — the invoice is numbered and its aging recalculated, and nothing else happens. On such a tenant there is no journal to look for; that is the setting working.

Backend checks at FINAL — validateGenericDocumentOnFinal runs these in sequence and returns every failure together; any failure rejects the FINAL:

The client-side pre-checks (VALIDATE_STOCK_ON_FINALIZE stock dialog, zero-price confirmation, DISALLOW_SELL_* line validators) run before the request is sent and can be confirmed past or bypassed by permission; they are not part of this list.

What FINAL does once validation passes: copies Skip E-Invoice from the customer; applies DATE_TXN_LOGIC; generates tenant, company and branch running numbers; starts the main posting job, which sets off every follow-on job switched on in your tenant’s trigger configuration — a company-level include/exclude list can override that, and it stays unset until somebody sets it, so by default your trigger configuration decides everything (how the fan-out is filtered); emits the INTERNAL_SALES_INVOICE_CREATED webhook; queues the sales-contract, message-template (email), membership reward-point and e-commerce stock-availability jobs.

Finalising twice is refused, not repeated. A document already FINAL is turned down with 403 and “Generic Document has already been posted to FINAL”, before any check runs and before anything is queued. There is no way to make the posting chain run again from this screen; a posting that failed is re-run from Trace Document, and a document that must be undone is VOIDed.

What every save writes, finalise included. Finalising runs the same update as an ordinary save, so these server-side rewrites happen on both — and the finalise is usually the last save, which is why they look like finalise behaviour. Every line’s transaction date is also overwritten from the header on each pass, so a line can never carry a date of its own:

• A unit price that was not supplied is back-computed and rounded up. When a line arrives with a line amount and no unit price, the server divides the amount by the base quantity to two decimals, rounding up. The line total is the authority; a derived unit price can therefore multiply back to slightly more than the total, and on a quantity of three that is visible in the second decimal. Supply the unit price if you want it exact.
• A line priced from a pricing scheme gets that scheme’s whole price set copied onto it. Every save recopies the replacement price, three reference prices, three delta prices, three delta percentages, three rebate prices, the promotion price and the four sales/purchase min and max prices from the pricing scheme entry — and also the company replacement cost price and amount, which are therefore a pricing figure shown among the costs rather than anything the costing chain produced. The same step fills the line’s point rate and point amount from the scheme’s reward ratio when the line carries no point type and no point amount. On a line priced by hand none of this happens at all.
• A tax rate can be re-read from the tax code. When the line carries a tax code and no tax type, the server looks the code up and, if it finds it, overwrites the line’s tax rate with the code’s current rate — whether or not it differs — and the save fails when the line’s rate is empty.

What posting does

A FINAL invoice that has already been settled or knocked off is normally reversed with a Sales Return or Credit Note rather than voided, so that the settlement and knock-off history stay intact.

Editing settlement on a FINAL invoice: the backend returns “The document’s settlement cannot be changed because its posting status is not final!” if the document is not FINAL, “The total settlement amount must be the same as the previous amount.” if the new STL_MTHD total differs, and “No changes have been made to the settlement.” if nothing changed. Accepted changes reverse and re-create the journal and cashbook lines.

Related applets

• Sales Order (Internal) — the usual source document; KO For copies its lines and the order is marked delivered.
• Sales Quotation (Internal) and Jobsheet (Internal) — other KO sources.
• Delivery Order (Internal) — invoice after delivery, or deliver from the Pick Pack Queue after invoicing.
• Stock Transfer — a KO source when goods were moved to the customer’s location first.
• Sales Invoice (No Stock Out) — same posting without the inventory movement.
• Sales Return (Internal), Sales Credit Note (Internal), Sales Debit Note (Internal) — reversals and adjustments against a FINAL invoice.
• Receipt Voucher (Internal) — settles the receivable; Contra settles it against other documents at the latest of the documents’ dates.
• Recurring Sales Invoice — generates invoices of this type on a schedule.
• Sales Contract, Sales Commission — processors triggered at FINAL.
• My E-Invoice Portal, My E-Invoice Admin — submission, validation and cancellation of the e-Invoice; tenant e-Invoice profile.
• POS General — cash bills use the same engine; both feed Sales Return.
• Purchase Invoice (Internal) — created automatically in the buying company for intercompany sales.
• Membership Admin — reward points are queued at FINAL for member invoices.
• Customer, Organisation, Pricebook, Tax Configuration, Chart of Account, Cashbook, Inventory Item Maintenance, Stock Balance, Workflow Design — master data read at entry and posting time.

Troubleshooting

Related documentation

• Standard Sales Workflow, Credit Sales Workflow, Partial Delivery Workflow, Returns and Exchanges Workflow
• Financial Accounting module, Inventory module, E-Invoice module
• Sales Workflow applets