SO Consolidation

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 backend subsystem behind it (genDocConsolidation) also carries a parallel Job Sheet variant — Job Sheet to Sales Invoice — which has no registry applet of its own.

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, each in a different way, and no setting key is read anywhere in the repo.

DEFAULT_BRANCH, DEFAULT_LOCATION, DEFAULT_COMPANY and DEFAULT_TIMEZONE appear only in those screens and in the settings model interface; a plain grep for each key across the applet finds no consumer.

Two batch behaviours that would normally be settings are instead processor event properties, set on the queue event rather than anywhere a user can reach:

Feature visibility / permissions

bl_applet_client_side_perm_dfn holds zero rows for applet code SO Consolidation, so there are no client-side visibility permissions.

Server-side, TntErpPermissionsV2 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_….

Note that the run-line processor reads the candidate sales orders with getByCriteriaSnapshotWithoutPerm — the consolidation itself is not filtered by the operator’s document permissions once the run lines exist.

Fields

Run — Create

Event — Create

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_HDR_PROCESSOR<br/>date_txn &lt;= today| R["Run header<br/>filters copied from the event"]
    RC["Run created directly<br/>in the applet"] --> R
    R -->|RUN_HDR_PROCESSOR| RL["Run lines<br/>one per eligible FINAL sales-order line"]
    RL -->|RUN_LINE_PROCESSOR| G["Group by company + branch<br/>+ customer + sales agent"]
    G --> SI["One INTERNAL_SALES_INVOICE per group"]
    SI --> L["bl_fi_generic_doc_link<br/>sales order to sales invoice"]
    SI --> Q["Open-queue rows for SO to SI<br/>permanently deleted"]
  

Event → Run. SALES_ORDER_TO_SALES_INVOICE_CONSOLIDATION_EVENT_HDR_PROCESSOR picks up every event whose date_txn is at or before now and whose processor_posting_run_hdr_guid is still null, creates a run from it — copying the four filter JSON columns, the dates, the name and the template link — stamps the run’s GUID back onto the event, and immediately enqueues the run processor. An event that already has a run GUID is never processed again.

Run → Run lines. …_RUN_HDR_PROCESSOR picks up runs whose processor_posting_status is null. It requires all four filter sets to be non-empty and fails the run with a specific message if any is missing. It then loops company × branch, counting eligible generic-document lines — header type INTERNAL_SALES_ORDER, header posting status FINAL, document entity in the customer set, sales entity in the salesman set — and creates run lines in pages of sales_order_get_limit_rows_to_process. If a previous attempt created some but not all of the run lines for a company/branch pair, it deletes them and starts that pair again.

Run lines → Invoice. …_RUN_LINE_PROCESSOR takes the distinct (company, branch, customer, sales agent) tuples among the selected run lines and, for each, reads back exactly the selected order lines and hands them to SalesOrderToSalesInvoiceConverter.mapSalesInvoiceGenDocContainer. That produces one INTERNAL_SALES_INVOICE per tuple, created through the ordinary GenericDocumentService.createGenericDoc with the internal-sales-invoices DCO, then immediately re-read and updated so the running number and derived fields are populated. The run lines are then stamped with the invoice link and a shared consol_slsinv_group_guid, and the sales-order-to-sales- invoice open-queue rows are permanently deleted so the orders no longer offer themselves for conversion.

Run-line status values

bl_fi_slsodr_to_slsinv_consol_run_line.processor_posting_status is a free-text column, not an enum. The values the processor writes are:

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) — what the run produces; everything about posting, tax and stock is decided there.
• Job Sheet (Internal) — the sibling consolidation path in the same backend subsystem.
• Scheduler — the queue machinery that drives the three processors.

Troubleshooting

Related documentation

• Sales & POS module — where this sits in the product.