Packing Order Applet (Internal)

This page is for the packing operator and the packing supervisor, and for whoever sets up the Doc Flow and permissions they need. The applet runs the packing desk of the manufacturing module: a packing order lists what is to be packed, usually knocked off from a sales order, and finalising it puts every line in the operator queue for packers to record and a supervisor to approve. The order itself posts no journal and moves no stock; approval cuts the bin and releases the whole reservation held for the sales order, not just the packed share. Its own packing status never reaches Completed; read the lines and the queue balances instead.

Your job, and the screen for it

Overview

The Packing Order Applet (Internal) is the packing desk of the manufacturing module. A packing order is an internal document (INTERNAL_PACKING_ORDER) whose lines are the items and quantities to be packed, usually knocked off from a finalised sales order. Finalising the order pushes every line into an operator queue; a packing operator records what was packed, from which bins, with which length markings, and a supervisor approves or rejects each line. Approval cuts the physical bin, records the packed bins, releases the stock reservation held for the sales order and settles the queue balance.

The applet also carries a coiling variant of the shop-floor process-instance and work-log screens found in the Manufacturing Operations Applet (menus Auto Coil Operator and Auto Coil Supervisor), a packing container register of drums and reels with a drum recommendation on every packing line, a scrap register, and read-only views of job orders, production requests and sales orders. The vocabulary of those screens — drum types, coiling direction, length markings, cable diameter — is that of a cable manufacturer, and ships to every tenant as is.

The packing order document itself neither posts a journal nor moves stock: every line carries amount signum 0 and quantity signum 0. Stock moves only when a coiling process instance is finalised, and that movement carries no cost (see Lifecycle and effects).

What it will not do. A packing order’s own packing status never reaches COMPLETED — the backend test that would set it cannot pass on a value read from the queue table (the arithmetic is under Supervisor approval). Read completion from the line statuses and the queue balances, not from the header.

Where it fits

Screens and menus

The sidebar has nine work menus and six settings menus. The applet opens on Operator Queue.

The packing order edit form has these tabs: Main Details · Account · Delivery Details · Department Hdr · Lines · Contra · Payment · ARAP · Doc Link · Attachments · E-Invoice · Export · Search · Trace Document · Operator Queue. The last tab is specific to this applet: it lists the queue rows of this order and is where the supervisor edits a row’s priority, estimated date, machine and acceptance criterion, and approves, rejects or scraps a line. Account, Payment, ARAP and E-Invoice come with the shared document scaffold; with both signums at zero the ARAP balance of a packing order is always zero.

Adding a line opens a tab group: Search Item, then KO For Sales Order, KO For Jobsheet, KO For Delivery Order and KO For Sales Invoice, each shown only when enabled (see Document behaviour settings). “KO By …” and “Copy Quotation Item” tabs exist in the template but are commented out; there is no quotation knock-off.

Settings menus: Application Settings (field-settings), Default Selection, Printable Format Settings, Return Reasons Settings, Workflow Settings, Email Template, plus the shared Feature Visibility, Client Side Permission, Permission Wizard / Set, User, Team and Role Permission, and Webhook screens. Personalisation: Default Selection (personal) and Sidebar.

This page is illustrated in words only: static/images/internal-packing-order-applet/ is empty.

Configuration

Before you can use it

Applet settings

Settings live in four places: Default Selection (applet-local component, master settings), Personal Default Selection (applet-local, per user), the shared Feature Visibility screen, which writes the HIDE_* / ENABLE_* keys this applet reads, and the shared Client Side Permission screen, which grants the SHOW_* codes. The hide toggles do what How settings are stored and who they apply to says they do and are not listed here; the one thing to know is under Who can change what — the registry defines only two SHOW_* codes for this applet, so a hidden button or column stays hidden for everyone. The settings below change what the applet will let you do.

On the screen and doing nothing

• Application Settings (field-settings) — opens the shared document-settings screen every document applet uses, with its hundreds of controls (the eight-toggle local screen whose Save did nothing is no longer routed). Its Workflow Selection panel is read here — see WORKFLOW_PROCESS_GUID below; its other controls have not been checked against this applet, so treat a toggle there as doing nothing until you have seen it work. Column and button visibility is Feature Visibility’s job.
• Return Reasons Settings — maintains a list of return reasons that nothing in this applet uses: the header has no reason field.
• SALES_RETURN_WITH_PAYMENT — read at Final, where it refuses Final unless the ARAP balance is zero; on a zero-signum document the balance is always zero, so the key cannot change the outcome. No settings screen in this applet writes it (it belongs to the sales-return and refund-note family, which is where the read-path check finds every writer).
• WORKFLOW_PROCESS_GUID is not dead: the Workflow Selection panel of Application Settings writes it, a new packing order starts on that process and its Starting Status, and the Final status chosen beside it is the Final-button gate described under Document behaviour settings.

Document behaviour settings

Email Template is the shared email-template screen and behaves as on every document applet.

Settings in other applets that control this applet

Two things set elsewhere decide what happens here, and both are above: the Doc Flow rows in the Organisation applet decide which knock-off tabs exist, and a stock reservation raised in the Stock Reservation applet is what supervisor approval releases — as a whole header, on the first line approved. Process types, templates and machines from Process Maintenance populate drop-downs and change no behaviour.

Who can change what

• Client-side permissions this applet defines. Exactly two. SHOW_SUPERVISOR_VIEW is the one that matters: seven of the nine work menus (Manual Packing, Auto Coil Supervisor, Packing Request, Job Order, Urgent Sales Order, Packing Containers, Scrap & Short) require it — or the server permission TNT_API_DOC_INTERNAL_PACKING_ORDER_READ_TGT_GUID, TNT_TENANT_ADMIN or TNT_TENANT_OWNER. Operator Queue and Auto Coil Operator are open to everyone with the applet.
• Dead permission code. SHOW_OPERATOR_VIEW is defined ACTIVE and does nothing here, nor in the Manufacturing Operations applet — granting it changes nothing.
• Codes the applet compares but cannot be granted. The listing, edit form and line form test some thirty further SHOW_* codes — SHOW_GENDOC_FINAL_BUTTON, SHOW_GENDOC_VOID_BUTTON, SHOW_GENDOC_DISCARD_BUTTON, the SHOW_ARAP_* set, SHOW_COSTING_DETAILS, SHOW_DOC_NO_*, SHOW_CLIENT_DOC_TYPE, SHOW_TRANSACTION_DATE, SHOW_SALES_AGENT, SHOW_DESCRIPTION, SHOW_QTY_*, SHOW_UOM_TO_BASE_RATIO, the SHOW_UNIT_PRICE_* / SHOW_UNIT_DISCOUNT* / SHOW_AMOUNT_* line-column codes, SHOW_LAST_PURCHASE_PRICE, SHOW_TAX_CONFIG_SELECTION, SHOW_WHT_CONFIG_SELECTION. None of them is defined, so the Client Side Permission screen cannot grant them and the check can never be true; wherever the matching HIDE_* setting is on, that column or button is hidden for everyone, administrators included.
• Server-side: the four document permissions above; the mrp/ endpoints check API_TNT_DM_MRP_* permissions built per target; the finance-side queue insert at Final checks API_TNT_DM_FI_PICK_PACK_QUEUE_CREATE.

Fields

Every editor in this applet except one seeds its save from the row it loaded and changes only the fields on the form, which matters because the backend has no partial update — a save is a whole-row replace built from every declared column. The document editor sends the whole document from the draft store; the operator’s and the supervisor’s queue editors spread the loaded queue row and patch two and six fields respectively; the length-marking update spreads the loaded marking; the bin cut and the production request load the whole record and put it back. The exception is the Packing Containers edit screen, and it is in its own table below.

Packing order — header and delivery details

The header is the shared document scaffold: document type (fixed to INTERNAL_PACKING_ORDER), branch / company / tenant running numbers, transaction and due dates, reference, remarks, tracking ID, client document type and references, workflow status and resolution when a process is set, and the audit fields. Delivery Details takes a delivery branch, location, type and tracking ID, carries no validation, and feeds nothing downstream — the queue rows take their branch and location from each line. Two header fields do something the screen does not show:

Packing order — lines

A line is the shared line template — item, quantities (base, by UOM, ratio), the pricing block (STD / transaction / net unit prices, discounts, tax, WHT, amounts), remarks, e-invoice code — plus this applet’s own Packing Container, Drum Type, an Accept Recommendation button and the source document numbers a knock-off fills. Purchase Order / Invoice / Quotation / Requisition No. fields also render, from the shared template, and no purchase knock-off exists here. Line tabs: Batch Number, Bin Number, Serial Number (scan / import), Costing Details (behind SHOW_COSTING_DETAILS), Pricing Details, Delivery Details, Delivery Instruction, Department, Doc Link, Issue Link. The pricing block is carried and posts nothing (amount signum 0).

Operator queue row (Operator Queue › Main Details)

The operator’s screen shows the packing order number, line running number, item code and name, UOM, required quantity, priority, estimated packing date, acceptance criterion and deviation, packing status and packing container, and lets the operator change exactly two things: Packed Quantity and Machine. The supervisor’s copy of the same form on the packing order’s Operator Queue tab additionally edits priority, estimated packing date, acceptance criterion and deviation.

Packing container

The register form takes Flange x, Barrel y, Inner width z and Min. clearance from outer w (each with a UOM defaulting to mm), Volume (cm³), and a Drum Type of STEEL or WOOD, defaulting to STEEL.

Lifecycle and effects

What posting does.

What Final does

Final saves the document first and then finalises it — a separate step, where the server validates the document, sets it FINAL and starts the main posting job. With nothing to post, that job has no work to do for this document.

On success the applet does the work that gives Final its meaning here, in two steps of its own:

1. Every line is put on the finance-side pick/pack queue with its full quantity as the balance, one request per line, all in parallel.
2. Those rows are then moved to the manufacturing queue. The lines are now in the Operator Queue, and nothing else has been written.

Step 2 runs only when every line succeeded in step 1. If any line fails, the applet shows “Failed to post to Fi Pick Pack Queue” and stops there: the lines that did succeed stay on the finance-side queue and none of them reaches the Operator Queue. The document is already FINAL, Final cannot be pressed again, and no screen re-queues a line or moves the waiting ones on.

Which jobs run, and which do not

Nothing here needs scheduling: every job below runs in response to a user action.

Operator step

Saving a queue row saves the packed quantity; if it changed, the packing-order line’s packing status becomes PENDING_APPROVAL. Length markings record the bin, a direction, an offset and the marked quantity, and each one saves the queue row. The operator’s Save does not release anything.

Supervisor approval

The approval path below is described from the code rather than from documents that have been through it, so treat it as untested ground: reconcile the first packing order you approve against the bins by hand.

From the packing order › Operator Queue tab › Approve:

1. Cutting the bins happens only when the row has at least one length marking — Approve on a row with no markings does nothing at all, and says nothing. For each marking, a marked quantity larger than the bin line stops with “Packing Quantity exceeds bin’s quantity” (checked in the browser; nothing written); an exact match keeps the bin line whole; otherwise the bin line is reduced and a new bin line is created for the packed quantity.

2. Recording the packed bins: one packed-bin record per packed bin line — recorded against the queue row, not the packing order.

3. Releasing the reservation runs alongside step 4 and is invisible. It takes the sales order behind the packing order’s first link, looks for a bin reservation on the first bin of the queue row’s line for that sales order, releases the first one it finds and then marks the whole stock reservation it belongs to RELEASED, which takes the reservation’s full quantity off the reserved figure.

   One approved line releases the entire reservation, whatever else it covered — but only that one bin link: the reservation’s other bin links stay RESERVED and keep coming off their bins’ available quantity. When that first bin carries no reservation for the sales order — including when there is no reservation at all — or the packing order’s first link is not to the sales order, it fails with no message, and the success toast from step 4 shows regardless.

4. Approving the line sets its packing status to APPROVED and writes the queue balance as required quantity minus packed quantity. The server then re-derives the packing status of the line and the header itself, overwriting the APPROVED:

   • balance not zero → header and line IN_PROGRESS;
   • balance zero → the line becomes COMPLETED, and the header becomes COMPLETED only if every queue row of the document passes the completion test — which, as the product stands, it never does. With no acceptance criterion (every row Final creates has none) the test fails with an error; with EXACT it answers no; with a variation it answers yes only when the deviation is at least the whole required quantity.

So the realistic outcomes of a full approval are: criterion unset — the balance is written, then a general error shows and the line keeps APPROVED; criterion set — the line reads COMPLETED, the header IN_PROGRESS, for ever. APPROVED is therefore the status of a line whose approval errored.

Reject sets the line’s packing status to REJECTED and touches nothing else. Scrap from the same tab locks the bin as scrap against the packing-order line; that is what the Scrap & Short menu lists.

Packing statuses are IN_QUEUE, PLANNED, IN_PROGRESS, ON_HOLD, COMPLETED, PENDING_APPROVAL, APPROVED, REJECTED, INCOMPLETE, PENDING_STOCK. The applet sets PENDING_APPROVAL, APPROVED and REJECTED; the server sets IN_PROGRESS and COMPLETED; the listing filter offers INCOMPLETE, PENDING_APPROVAL, COMPLETED, REJECTED, so a line at IN_PROGRESS or APPROVED can only be found by clearing the filter.

No approval engine. The generic approval engine runs its full loop only for Purchase Order and Purchase Requisition (Stock Requisition has settings but no submit step, a known gap); here “approval” is the supervisor’s Approve button above and, on the coiling screens, the work-log approval status (PENDING, APPROVED, REJECTED, REWORK). Neither uses Approval Settings.

Discard and Void, and the sales order behind them

A FINAL or VOID document cannot be discarded. Both Discard and Void bring the sales-order line’s packed quantity back down, because knock-off raised it. The two paths disagree with each other and with knock-off:

• Discard takes the first discarded document only, adds up the quantity of all its lines, and subtracts that total from the sales-order line behind its first link. A multi-select discard from the listing corrects one document; a multi-line packing order takes every line’s quantity off one sales-order line; a draft that was never knocked off has no link and nothing is corrected.
• Void takes the first link, finds the one packing line it points at, and subtracts that line’s quantity from its sales-order line — one line per void, whatever the document held.
• Knock-off added the base quantity at the moment the line was picked, before any save.

A sales order’s “already packed” figure is therefore only right for single-line packing orders that were saved and then voided one at a time. So when a knock-off refuses a quantity that nothing has packed, the figure it checks is the sales-order line’s quantity minus its packed quantity, and the shortfall is a draft somebody abandoned or a multi-line order that was discarded.

Coiling process instances (Auto Coil Supervisor / Operator)

The supervisor creates a packing process instance, status PLANNED, with input items (bins, which are locked) and output items (the Default Item / default coiling item); the operator posts work logs (shift date and type, machine, length produced, length discrepancy, line speed, OD start/mid/end, in/out die, heater temperature, time consumed). This is the only place this applet moves stock.

Final on the supervisor screen takes a shorter route than a job’s FINAL in Manufacturing Operations. It saves the instance as FINAL and POSTED through the ordinary instance update, then calls a second server action that writes the stock lines at once — every input line out, every output line in — and queues one stock-balance update for each.

The two calls are separate. If the second fails, the instance already reads FINAL and POSTED, Final is greyed out, and no stock has moved; and the server action moves the stock again each time it is called, so it must not simply be re-run. Check Stock Balance after every coiling Final, and take a mismatch to your BigLedger contact. The manufacturing finalisation job never runs for it, so two things that job does on a job’s FINAL do not happen here: no next stage is set READY, and the locks on the input bins are not released, so they keep coming off those bins’ Base Qty.

That last part is a known defect, which BigLedger is tracking: Final should release those locks. Until it is fixed, write down each coiling instance’s input bins before you press Final, then report them to your BigLedger contact.

Each line is written with an amount of zero, which costing ignores, so the coil that enters comes in at the unit cost it already carries at that location — zero if it has never been costed there — and no cost passes from the input coil (A manufactured item shows RM 0 cost).

Packing Request and the container register

Packing Request. Save writes the request flag and remarks onto the one sales-order line. Nothing else changes.

Container register. The Packing Containers screens create, edit and delete containers — the edit being the one that clears the inventory-item link, above. The line form asks for a recommendation on every change of its inputs.

Related applets

• Sales Order (Internal) — the backend-registered previous document; its lines are knocked off here, its packing_order_qty is kept by this applet, and its reservation is released on approval.
• Job Sheet (Internal), Delivery Order (Internal), Sales Invoice (Internal) — knock-off tabs when their Doc Flow row is enabled.
• Warehouse Management Applet — carries the index of every pick/pack queue; this applet writes the manufacturing-side one.
• Production Planning and Monitoring Applet — creates the job orders and production requests this applet lists.
• Manufacturing Operations Applet — the same process-instance and work-log screens for non-packing instances.
• Process Maintenance Applet — machines, process types, templates.
• Stock Reservation Applet — what approval releases, as a whole header.
• Stock Balance Applet — where the zero-value coil movements land.
• Organisation Applet — Doc Flow Config, branches, locations.
• Workflow Design Applet — the process referenced by Workflow Settings.

Troubleshooting

Related documentation

• Manufacturing Module
• Manufacturing applets
• Which queue am I looking at? — the seven queues, on the warehouse page
• How settings are stored and who they apply to
• No user guide covers this applet yet; the closest job page is Use cases: the packing floor working a queue.