SO Consolidation

The batch biller: it gathers the order lines of many finalised sales orders and, when you press GENERATE SI, issues one internal sales invoice per company, branch, customer and sales agent, from a run you create or from a dated event. The invoice is created as a draft, so nothing posts until someone finalises it in Sales Invoice (Internal), and undoing a run means voiding or deleting that invoice there. No screen shows whether a run worked, so judge it by its Sales Orders and Sales Invoices tabs, and check what was billed before, because the run cannot.

Your job, and the screen for it

Overview

SO Consolidation is the batch biller. Where a customer has accumulated many finalised sales orders over a period — a month of deliveries, a week of counter orders — this applet gathers the order lines and issues one consolidated internal sales invoice per customer, instead of one invoice per order.

It has three objects. A Template is a saved filter set you can reuse. An Event is a dated (and optionally repeating) instruction to consolidate. A Run is what an event produces, or what you create directly: a named, date-bounded batch whose lines you can inspect and whose resulting invoices you can see.

The same consolidation machinery also carries a parallel Job Sheet variant — Job Sheet to Sales Invoice — with its own applet, JS Consolidation. Its page says where it differs from this one.

Where it fits

Screens and menus

Three screens, all linked, plus the standard Settings and Personalization sections.

The Run detail view has eight tabs: Details, Branches, Companies, Customers, Sales Agent, Export, Sales Orders, Sales Invoices. The four filter tabs each have an Add sub-screen that picks the entities for that run; the Sales Orders tab lists the candidate order lines (Branch, Customer, Sales Agent, Item Code, Qty) and is where selection happens — selection is at line level, so part of a sales order can be consolidated and the rest left open; the Sales Invoices tab shows what the run produced.

Configuration

Before you can use it

Applet settings

This applet has no working configuration. All three settings screens are non-functional, and nothing in the applet changes its behaviour based on a setting.

The reason is mechanical, not a permission: the Field Settings screen is a stub with no form behind its toggles, and both Default Selection screens declare a save output that nothing emits and nothing binds. The Personalization menu also lists a Field Settings entry with no route behind it, so that click opens nothing.

Two batch behaviours that would normally be settings are instead fixed by the platform when it queues the job, not anywhere a user can reach: the page size in which a run reads sales-order lines, and whether a job processes one named event or run or sweeps every unprocessed one. Everything you start from this applet processes the one event or run you saved.

Feature visibility / permissions

This applet has no feature-visibility codes of its own.

The Permission Set screen carries a full six-verb set (_OWNER, _ADMIN, _CREATE, _UPDATE, _DELETE, _READ) for each of Consolidation Template Hdr, Consolidation Event Hdr, Consolidation Run Hdr and Consolidation Run Line, all prefixed TNT_DM_ERP_SALES_ORDER_TO_SALES_INVOICE_CONSOLIDATION_….

GENERATE SI is governed by the run line create permission.

Fields

Run — Create

Event — Create

An event dated in the future may never become a run. When you save an event, the platform checks it once, there and then. An event not yet due is skipped, and as far as the source shows nothing checks it again when its date arrives: no Scheduler entry can start the event job, and the platform’s per-tenant processing pass does not look at this applet’s queue. That holds for a one-off event dated later and for every future occurrence of a repeating one. This was read in the code and has not been tested on a tenant. After each event date, open the Event listing and check that a run appeared. If none did, create the run by hand.

Lifecycle and effects

Posting proof

The pipeline

    flowchart TD
    T["Template<br/>saved filter set"] -.seeds.-> E
    E["Event<br/>date + optional RRULE + filters"] -->|event job<br/>event date &lt;= today| R["Run header<br/>filters copied from the event"]
    RC["Run created directly<br/>in the applet"] --> R
    R -->|run job| RL["Run lines<br/>one per eligible FINAL sales-order line"]
    RL -->|GENERATE SI<br/>run-line job| G["Group by company + branch<br/>+ customer + sales agent"]
    G --> SI["One draft Sales Invoice per group<br/>posts when finalised"]
    SI --> L["Document links<br/>sales order to sales invoice"]
    SI --> Q["Open-queue rows for SO to SI<br/>permanently deleted"]
  

Three background jobs drive the chain, and each is started by something you do on this applet’s screens, not by a clock. The Scheduler cannot start them.

Event → Run. Saving an event starts the event job for that event. If the event is due (dated today or earlier) and has not yet produced a run, the job creates a run from it — copying the four filter sets, the dates, the name and the template link — records the run on the event, and starts the run job at once. An event that already has a run is never processed again. An event not yet due is skipped, and see the caution under Event — Create about when it is looked at again.

Run → Run lines. The run job processes a run only once. It requires all four filter sets to be non-empty and fails the run with a specific message if any is missing. It then works through each company and branch, counting eligible sales-order lines — a Sales Order (Internal) whose posting status is FINAL, whose customer is in the customer set and whose sales agent is in the salesman set — and compares that with the run lines that already exist for the pair in any run. What it does next is in Templates, and what a run actually picks up.

Run lines → Invoice. Pressing GENERATE SI on the Sales Orders tab queues the run-line job and returns at once: the “The sales invoices were successfully created” message means the work was queued, not done. The job skips any ticked line that already has an invoice or carries any status. It takes the distinct (company, branch, customer, sales agent) combinations among the rest and, for each, reads back exactly the selected order lines and builds one Sales Invoice from them, created exactly as a hand-keyed internal sales invoice is and then immediately updated so the running number and derived fields are populated. It is created as a draft. It is dated the moment the job runs, its billing and delivery address and customer details come from the last sales order in the group, and its description reads “Consolidated from Sales Order id: …”, naming that last order only. Only item lines are carried. The run lines are then stamped with the invoice link and a shared group reference, and the orders are permanently removed from the sales-order-to-sales-invoice open queue so they no longer offer themselves for conversion. A failure is written to the run line, not shown to you; reload the Sales Invoices tab to see what was made.

Run-line status values

The status on a run line is free text, not a fixed list — and no tab in this applet shows it. The Sales Orders tab fetches the run lines but puts only branch, customer, sales agent, item and quantity in columns; the Status on the run listing is the record’s ACTIVE/INACTIVE flag, and the Status on the Sales Invoices tab is the invoice’s own posting status. The processing result lives in two fields on the line — a processing status and a processing error (the exception message, or the stack trace) — and the way to read them is the run-lines query the Sales Orders tab itself calls, filtered by the run’s guid (the field names and the path are in this page’s sources), or to ask BigLedger support to read them for you. The values written are:

Templates, and what a run actually picks up

A template is a name, a description, a status and four lists: companies, branches, customers and sales agents. You fill the lists on the template’s own filter tabs after you save it. Pick the template on the Run or Event Create form and its four lists are copied into the new run or event. That is the only way the Create form fills them. It has no picker of its own for companies, branches, customers or sales agents.

What happens behind the screen.

• The copy is taken once, when you pick the template. Editing the template afterwards changes no run or event already made. That includes a repeating event. The event copies its own four lists onto every run it makes, not the template’s. A customer you add to the template next month is not billed by an event you created last month.
• The run remembers which template it came from, and nothing uses that. The run job chooses orders from the run’s own four lists. The template view has no list of the runs made from it.
• The run’s dates do not choose orders. The run takes every sales-order line at posting status FINAL whose company, branch, customer and sales agent are in its lists, whatever the order’s date. The start date only decides when the run is processed.
• Nothing new since the last run: the new run gets no lines for that company and branch. When the eligible lines are no more than the run lines already held for the pair, by any run, the new run makes none. Its Sales Orders tab stays empty for that pair; the earlier run keeps its lines.
• New orders finalised since: the run takes every such line again, including lines an earlier run already invoiced. It first deletes every run line for that company and branch, from every run and for every customer. That includes an earlier run’s record of which invoice each line went to. It then lists every eligible line again under the new run, with no mark on those already invoiced. When you press GENERATE SI, the only check is the run line’s own invoice link, and a re-listed line has lost it, so it can be billed a second time.
• The Qty column is not a quantity. It shows how many eligible lines the run found for that company and branch, the same number on every line of the pair.

Four cautions, each with the symptom you will see:

• Pick the template on Create, or the run has nothing to work with. A run whose start date is today or earlier is processed the moment you press Create. Without a template its four lists are empty, so it makes no lines, and a run is never processed twice. Symptom: the Sales Orders tab stays empty.
• Do not date a run in the future. A run with a later start date is queued and marked as handed over straight away. The run job only takes runs that were never marked, so as far as the code shows, that run never makes its lines. Symptom: the start date passes and the Sales Orders tab stays empty. Create the run on the day you want it to run. A future-dated event is no way round this (see Event — Create).
• No screen shows whether a run was processed. The listing’s Status column is the record’s own status, ACTIVE or not. It is not the result of processing, and no screen shows the processing error. The Sales Orders tab is your evidence: empty means this run made no lines, either because it failed or because an earlier run already holds every eligible line for that company and branch.
• Two runs over the same company and branch interfere. The second can delete the first’s lines, including the link to the invoice they produced. Finish and check one run before you create the next.

Your job. Whoever bills these customers keeps one template per billing group, for example one per branch and sales agent, and keeps it current. When a customer or sales agent joins or leaves the group, edit the template and re-create any event made from it. Before you press GENERATE SI, compare the Sales Orders tab with the invoices the last run produced. Tick only lines that are not on one yet, because nothing here stops a second invoice for a line a later run has re-listed. Afterwards, open the Sales Invoices tab and count one invoice per customer and sales agent you expected, then finalise each draft in Sales Invoice (Internal), checking its date and billing address. If the orders were already invoiced by hand, do not select them. The run does not know that. Do not create the next run for that company and branch until this cycle’s invoices are final.

Related applets

• Sales Order (Internal) — the source documents, and where the sales agent that forms part of the grouping key is set.
• Sales Invoice (Internal) — where the draft the run produces is finalised; everything about posting, tax and stock is decided there.
• Job Sheet (Internal) — the sibling consolidation path in the same backend subsystem.
• JS Consolidation — the job-sheet twin of this applet; its page lists where the two differ.
• Scheduler — not used by this applet’s runs or events.

Troubleshooting

Related documentation

• Sales module — where this sits in the product.