Delivery Order Applet (Internal)

Tell the warehouse and the driver what goes out to a customer, on which date and by which route. Finalising moves no stock and posts no journal, because the sales invoice or a goods issue does that, and it does not put lines on the pick-pack queue either: someone has to press Send To Queue.

Overview

The Delivery Order Applet (Internal) is the workspace where the office raises, edits and finalises the outbound delivery order — the document that says these goods are going out to this customer, on this date, by this route. It is one applet with one document type: INTERNAL_OUTBOUND_DELIVERY_ORDER, short code OBDODR.

It sits after the order and before (or after) the invoice. Lines are usually not typed in: they are pulled from a Sales Order, a Sales Invoice, a Sales Return, a Purchase GRN or another Delivery Order and knocked off against it, so the source document’s open quantity falls as the delivery order consumes it. Lines reach the Pick Pack Queue only when someone presses Send To Queue on the document’s Delivery Details panel — FINAL by itself puts nothing there. Turning the queued quantity into a delivery job is a separate action, Create Delivery Job, on this applet’s Pick Pack Queue screen or in the Delivery and Installation applet. The warehouse picking queue of the Warehouse Management applet is not fed from a delivery order: its Send To Warehouse Picking Queue button exists only on the Sales Order applet’s Pick Pack Queue screen.

Where it fits

Screens and menus

Routes live under applet/tnt/wavelet/erp/internal-delivery-order-applet — the same slug the registry’s routerLink uses. The landing screen is Delivery Order: the empty path redirects to internal-delivery-order, and anything unmatched goes to a 404 component.

Four menu entries are shipped; two more are present in the file but commented out, so Sales Invoice Template and File Import have routes and no way in from the menu.

The listing’s action row carries Export as PDF, Final, Draft, Discard, Void and Send Email. Three of them are hidden by settings rather than by permission — Final by HIDE_GENDOC_FINAL_BUTTON, Discard by HIDE_GENDOC_DISCARD_BUTTON, Void by HIDE_GENDOC_VOID_BUTTON.

The edit workspace is a set of detail panels. Their order is stored as INTERNAL_OUTBOUND_DELIVERY_ORDER_DETAILS_TAB_ORDER, and each panel has its own HIDE_*_TAB and EXPAND_* key in the settings model: Main Details, Account, Line Items, KO For, Delivery Details, Main AR/AP, Department Hdr, Trace Document, Doc Link, Attachment, Export, Main Contra, Settlement, Posting, Delivery Trips.

Pick Pack Queue

The queue lists the delivery orders’ lines waiting to go out, with the balance still to deliver alongside the location and company stock balances for the same item. Qty To Deliver is editable only up to the balance — a larger figure is not accepted.

Create Delivery Job creates one or more delivery jobs — delivery logic, the four pickup dates, the four delivery dates and the recipient’s entity, code, name, e-mail and phone — linked to the selected queue lines. Delivery Type is a three-value drop-down: INTERNAL_DELIVERY, EXTERNAL_DELIVERY, PICKUP.

Intercompany

Two streams, Inbound and Outbound, each split into UNPROCESSED and PROCESSED tabs. The only action is CONFIRM INTERCOMPANY TRANSACTION.

Line Items

Settings (gear) and Personalization menus

Settings is one group, System Configuration, with nine entries: Application Settings, Default Selection, Printable Format Settings, Branch Settings, Workflow Settings, Custom Status, Email Template, Custom Resource Bundle Configuration, Custom Field Placement. Eleven further routes exist without a menu entry — Feature Visibility, Webhook, Applet Log, Release Notes, and the seven permission screens (permission wizard, permission set, user, team, role and client-side permission listings).

Personalization has a single entry, Default Selection; the sidebar route exists without one.

Configuration

Before you can use it

• Company, branch and location — the create form defaults come from DEFAULT_COMPANY, DEFAULT_BRANCH and DEFAULT_LOCATION, set in Organisation and selected here.
• Customers — the account panel resolves an entity maintained in Customer Maintenance. A customer flagged as blacklisted cannot be used: FINAL is rejected by the backend (see Lifecycle and effects).
• Document numbering for INTERNAL_OUTBOUND_DELIVERY_ORDER, otherwise the document has no number.
• A printable format (.jrxml) if the document is to be printed or e-mailed. Uploaded in Printable Format Settings; a branch default is chosen per branch against this document type.
• An e-mail template if Send Email is used. Templates are stored with txn_type = 'INTERNAL_OUTBOUND_DELIVERY_ORDER_EMAIL_TEMPLATE' and listed by the same filter.
• A workflow process in Workflow Design if the delivery order is to carry a workflow status.

Applet settings

Where they live. Application Settings is the shared settings screen. Default Selection, Branch Settings, Workflow Settings, Custom Status, Email Template and Printable Format Settings are this applet’s own. Default Selection under Personalization is per-login. One of the applet’s own screens is worth naming because it looks like a filter and is not: Branch Settings › Item Category Filter stores up to eleven categories per branch (ITEM_CATEGORY_0..10) in its own link table, and nothing reads those rows except the screen that wrote them — the item search is not narrowed (deep read of 4 October 2026; whether it was meant to narrow the search is Q-1269).

The applet has about 180 settings. The table below covers the keys whose behaviour is visible in this applet’s own code; the great majority of the remainder are HIDE_* / EXPAND_* toggles for individual fields and panels, which do exactly what their names say. Anyone with access to the gear menu can change them; there is no per-row authority split.

Document behaviour settings

• Status flow. SAVE, Final, Draft, Discard and Void are listing actions; Close is in the edit workspace and can be removed with HIDE_CLOSE_BUTTON.
• Workflow. Workflow Settings maps a company and this document type to a process chosen from Workflow Design. This is status routing, not approval. Nothing in this applet approves anything, and the platform’s generic approval engine does not cover any sales-side document. A workflow status on a delivery order is a label; nothing waits on it.
• Custom Status. Up to five status groups, each activatable at header and at line level, each a list of { name, descr, default }.
• Printables and e-mail. .jrxml formats are uploaded in Printable Format Settings and defaulted per branch against this document type. Send Email on the listing uses a template stored under INTERNAL_OUTBOUND_DELIVERY_ORDER_EMAIL_TEMPLATE; it can be removed entirely with HIDE_SEND_EMAIL_BUTTON.
• e-Invoice. None — a delivery order is not a submittable document type, and there is no e-Invoice setting or screen here.

Settings in other applets that control this applet

Feature visibility / permissions

Two different mechanisms, and they interact:

1. Backend document permissions. The applet declares four targets at start-up: TNT_API_DOC_INTERNAL_OUTBOUND_DELIVERY_ORDER_READ_TGT_GUID, …_CREATE_…, …_UPDATE_…, …_DELETE_…. These are the same four the backend’s document handler enforces. Read is also checked before the document container loads.
2. Client-side permission codes. SHOW_LINE_ITEMS_MENU, SHOW_PICK_PACK_QUEUE_MENU and SHOW_INTERCOMPANY_MENU are read from the login’s client-side permissions. A menu is hidden only when the login lacks the SHOW_ permission and the HIDE_ setting is on — so granting the permission overrides the tenant-wide hide. The same pattern applies to Discard and Void.

The seven permission-administration screens are the shared ones and are reachable only by typing their address — they have no menu entry.

Fields

Reference voice; these are the form fields, not a guide.

Main Details and Account

Lines

Delivery Details

Three mutually exclusive delivery shapes: Internal Delivery, External Delivery and Pickup. Each offers the ACTIVE delivery trips. Delivery branch and delivery location can be hidden with HIDE_DELIVERY_BRANCH and HIDE_DELIVERY_LOCATION.

The same panel carries the line grid behind Send To Queue (the pick-pack queue; see Pick Pack Queue above):

Voiding a delivery order does not remove its queue rows — the pick/pack void job clears rows for sales orders only. Rows sent from a voided delivery order stay in the Pick Pack Queue until a job consumes them or they are cleared by hand.

Pick Pack Queue row

Lifecycle and effects

Statuses. A new document is created as TEMP and becomes ACTIVE on first save; posting status runs DRAFT → FINAL. VOID and DISCARDED take a document out of the flow; Close ends the knock-off lifecycle of a FINAL document. Posting status and record status are separate columns in the listing.

What posting does

• Document type: INTERNAL_OUTBOUND_DELIVERY_ORDER, short code OBDODR.
• Stock and money: neither. A delivery order moves no stock and posts no journal — finalising one posts nothing, and there is no GL code to resolve. Open delivery-order lines are counted as committed quantity by Stock Availability, which is a reservation view, not a movement.
• FINAL-time checks: a blacklisted customer is rejected. The serial validation setting governs the serial-number and batch-number counts on this document’s zero-signum lines; the stock-balance check runs with its server default and skips every zero-signum line regardless, so the setting never touches it.
• What an open delivery order costs you: it is a 0/0 document, but it is not inert. An open delivery order reduces the customer’s available credit and counts as committed stock in Stock Availability until it is invoiced or voided — the two numbers a credit controller and a store will ask about.
• Bulk FINAL from the listing: the request is sent after an unconditional two-second pause and in parallel for every selected row, which is why nothing happens and then everything does.
• What VOID reverses: nothing financial — there is no journal and no stock movement to reverse. VOID takes the document out of the operational flow and releases its knock-off links.
• Back to DRAFT: offered here, and safe here. The listing carries a DRAFT button, hidden unless SHOW_DRAFT_BUTTON is enabled or the matching permission is held, which returns the selected FINAL rows to draft in bulk. That releases the knock-offs and the document links — and because this document posts nothing there is no posting to leave behind, so the undo really does undo everything this document did. The same is not true of a document that posts: see What a Void Undoes.

What the applet writes besides the document. Delivery jobs, from Create Delivery Job. Settings screens write the applet settings, the workflow mapping, e-mail templates and printable formats.

Related applets

• Sales Order (Internal) — the commonest source; its open lines are what a delivery order knocks off.
• Sales Invoice (Internal) — both a source and a target: invoice then deliver, or deliver then invoice. This is where the stock actually moves.
• Supplier Delivery Order Applet — the same document raised by a supplier against itself; it cannot finalise, so finalising happens here.
• Driver Delivery Order Applet — the driver’s three-field view of the same documents.
• Delivery and Installation — consumes the pick-pack queue rows this applet sends with Send To Queue and writes track_delivery_status back to the document’s header and lines.
• Goods Delivery Note (Internal) — an alternative downstream through KO For Delivery Order Item.
• Warehouse Management — creates delivery orders in DRAFT from a Packing List.
• Workflow Design — supplies the processes Workflow Settings maps here.
• Stock Availability — where an open delivery order shows up as committed quantity.

Troubleshooting

Related documentation

• Standard sales workflow — where the delivery order sits in the order-to-cash sequence.
• Partial delivery workflow — delivering an order across several delivery orders.
• POS and Sales module
• Inventory module