JS Consolidation
The bulk biller for finished jobs: it lists the lines of job sheets at FINAL and, when you press GENERATE SI, raises one sales invoice per company, branch, customer and sales agent. The invoice is created as a draft, so nothing posts until someone finalises it in Sales Invoice (Internal). The run cannot tell which jobs you billed before, so checking that is your job.
Overview
A workshop or service counter that closes many jobs for the same customer, for example a corporate
client of GadgetSphere’s repair counter at GS-KV-01 with thirty device repairs in a month, wants one
invoice for the month rather than thirty. JS Consolidation does that for
Job Sheet (Internal) documents. It is the job-sheet
twin of SO Consolidation. The two applets share
their screens and their template, event and run design, but each has its own backend code, and the
differences matter. They are listed in How it differs from SO Consolidation.
It has three objects. A Template is a saved set of four lists: companies, branches, customers and sales agents. An Event is a dated, optionally repeating instruction that turns into a run. A Run is a batch whose Job Sheets tab lists the candidate lines. You tick lines there and press GENERATE SI.
Where it fits
| Direction | Applet | Why |
|---|---|---|
| Upstream | Job Sheet (Internal) | Only lines of a job sheet at posting status FINAL are listed; moving a job to FINAL is what makes it billable |
| Downstream | Sales Invoice (Internal) | The consolidated invoice is an ordinary internal sales invoice, created as a draft; finalising it there is what posts revenue and moves stock |
| Beside | SO Consolidation | The same design for sales orders |
| Beside | Scheduler | Not needed by this applet. Its queues are swept by the platform’s per-tenant processing pass, not by a Scheduler entry |
Screens and menus
| Menu item | What it is |
|---|---|
| JS Consolidation Run | The working screen: run listing, Create, and the run view |
| JS Consolidation Event | Dated, optionally repeating instructions that become runs |
| JS Consolidation Template | Saved filter sets that a run or event copies on Create |
The run view has eight tabs: Details, Branches, Companies, Customers, Sales Agent, Export, Job Sheets and Sales Invoices.
- Job Sheets groups this run’s lines by branch, customer and sales agent. You tick item lines and press GENERATE SI. Selection is per line, so part of a job sheet can be billed and the rest left.
- Sales Invoices lists the invoices linked to this run’s job-sheet lines.
- Export shows four buttons. Three are disabled, and EXPORT AS PDF has no action behind it, so the tab produces nothing.
Configuration
Before you can use it
| Prerequisite | Where | Why |
|---|---|---|
| Job sheets at posting status FINAL | Job Sheet (Internal) | Nothing below FINAL is listed |
| A sales agent on each job sheet | Job sheet header | The sales-agent list is required and is part of the grouping key. A job sheet with no sales agent matches nothing |
| A template with all four lists filled | JS Consolidation Template | The Create form has no picker for the four lists. Without a template the run starts empty and fails |
On the screen and doing nothing
No setting in this applet changes what it does.
- Settings → Field Settings shows a SAVE button with no action behind it.
- Settings → Default Selection writes a default branch and location into memory that is never loaded or saved.
- Personalization → Default Selection behaves the same way.
Who can change what
The applet has no feature-visibility codes of its own. Access is decided on the server, per object, by
a six-verb permission set (owner, admin, create, update, delete, read) for each of the template, the
event, the run and the run line, all named TNT_DM_ERP_JOB_SHEET_TO_SALES_INVOICE_CONSOLIDATION_….
GENERATE SI is governed by the run line create permission.
Fields
Run — Create
| Field | What to know |
|---|---|
| JS Consolidation Template | The only way the four lists get onto the run. Picking it copies the template’s companies, branches, customers and sales agents. Later edits to the template change no run already made |
| Previous Run, and Current Run Start Date | The form fills Previous Run with the most recently created run, whatever its filters, and seeds the new start date from that run’s end date. Check the date before you press Create (see below) |
| Current Run Start Date | Decides when the run is processed, not which job sheets it takes. Today or earlier: processed while you wait. Later than today: never processed, as far as the code shows |
| Current Run End Date, Status | Stored. Neither is read by the run job: an INACTIVE run is processed all the same, and the end date selects nothing |
Event — Create
An event carries the same four lists, copied from a template, a date, and an optional repeat rule. The job-sheet events use the same recurrence code as SO Consolidation, line for line, so the RRULE notes on that page hold here. An event dated today or earlier becomes a run as soon as you save it.
An event dated in the future may never become a run. When you save it, the platform queues it for processing straight away, not on its date. The queue is processed within moments, the event is not yet due, and as far as the source shows nothing queues it again when its date arrives. Saving or editing another event later runs the same check again and picks up any event that is due by then. 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
| Server document type | None of its own. Templates, events, runs and run lines are not financial documents |
| What it creates | One INTERNAL_SALES_INVOICE per company, branch, customer and sales agent, at posting status DRAFT |
| Quantity signum / amount signum | Each invoice line carries quantity signum −1, so the invoice moves stock out when it is finalised. Amount and posting are that document’s own |
| Dr/Cr, GL precedence, stock processor | None here. All of it happens when the invoice is finalised in Sales Invoice (Internal) |
| What VOID reverses | A run cannot be voided. To reverse, void or delete the consolidated invoice in its own applet |
| What it does write | Run lines; the draft invoice; a knock-off link from each job-sheet line to its invoice line; and a permanent delete of the job sheets’ rows in the job-sheet-to-invoice open queue |
What GENERATE SI does
- The request returns at once. The applet shows “The sales invoices were successfully created” when the work has only been queued. Invoice creation happens afterwards, and a failure is written to the run line, not shown to you. Reload the Sales Invoices tab to see what was made.
- Lines that already have an invoice, or that carry any status, are skipped. Within one run, pressing GENERATE SI again on lines that already show an invoice does not bill them twice. The invoice is recorded on the line a moment after it is made, so wait for the Sales Invoices tab before pressing again. A line that failed is skipped as well, and cannot be retried from this run.
- One invoice per company, branch, customer and sales agent among the ticked lines. Only item lines are carried. Settlement lines taken on the job sheet’s Payment tab are not.
- The invoice is dated the moment the job runs, not on any job sheet’s date. Its header (billing and delivery address, customer snapshot) comes from the last job sheet in the group. Its description reads “Consolidated from Job Sheet id: …” and names that last job sheet only. Each line’s reference names the job-sheet line it came from.
- The invoice is a draft. It posts nothing and moves no stock until someone finalises it in Sales Invoice (Internal).
Run-line status values
| Value | Meaning |
|---|---|
POSTED | Invoice made, linked, and the open-queue rows removed |
FAILED_TO_CREATE_CONSOLIDATED_SALES_INVOICE | The invoice was refused on creation; the message column holds the reason |
FAILED_TO_UPDATE_CONSOLIDATED_SALES_INVOICE | Created, but the follow-up update failed |
FAILED_TO_UPDATE_SALES_INVOICE_DATA_IN_RUN_LINE | The invoice exists; recording it on the run line failed |
FAILED_TO_DELETE_GENDOC_LINE_OPEN_QUEUE | Everything else succeeded |
| (blank) | Either not processed yet, or processed with no open-queue rows to remove. POSTED is written only when there were rows to delete |
What a run picks up, and what it destroys
The run job reads the run’s four lists and works through every company and branch pair. It counts the job-sheet lines that are at FINAL with a customer and sales agent in the lists. It then counts the run lines that already exist for that pair, in any run. What happens next depends on the two counts:
- Nothing new since the last run: the counts match and the new run gets no lines for that pair. The run is still marked as processed.
- New job sheets finalised since: it deletes every run line for that company and branch, from every run and for every customer, then lists all eligible lines again under the new run. The deleted lines took with them the record of which invoice each line went to, so lines already invoiced come back unmarked and can be billed a second time.
- Dates play no part. Every FINAL job-sheet line in the lists is eligible, however old.
The job sheet itself never changes. It stays at FINAL after it is billed.
Your job. Whoever bills finished jobs keeps one template per billing group and runs one run per company and branch per billing cycle. Before you press GENERATE SI, check each job sheet against the invoices already raised for that customer, and tick only the jobs not yet billed. Afterwards, match the Sales Invoices tab to the job sheets you ticked, then finalise each draft invoice in Sales Invoice (Internal), checking its date and billing address. Do not create the next run for that branch until this cycle’s invoices are final.
How it differs from SO Consolidation
| JS Consolidation | SO Consolidation | |
|---|---|---|
| A run that finds nothing | Says so truthfully: the job-sheet run counts what it matches | Its “nothing found” failure fires on every run (a known defect) |
| Who processes queued runs and events | The platform’s per-tenant pass sweeps this applet’s queues | That pass does not sweep the sales-order queues |
| Run tab | Job Sheets | Sales Orders |
What it will not do
- It will not finalise the invoice. You finalise the draft in Sales Invoice (Internal), and posting, stock and e-invoice follow from there.
- It will not know what you billed before. Nothing on the Job Sheets tab marks a line billed in an earlier run or by hand. Keeping that record is the biller’s job.
- It will not bill by date. There is no “jobs closed this month” filter. To bill a month, finalise that month’s jobs and run then.
- It will not carry money. Payments taken on the job sheet are not on the invoice. Record them as receipts against the invoice once it is final.
- It will not export. The Export tab has no working button.
Related applets
- Job Sheet (Internal) — the source document. Its FINAL status and sales agent decide what is listed here.
- Sales Invoice (Internal) — where the draft is finalised and everything about posting, tax and stock is decided.
- SO Consolidation — the sales-order twin.
- Scheduler — not used by this applet’s runs or events.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| “The sales invoices were successfully created” but the Sales Invoices tab is empty | The message appears when the work is queued. Creation failed or has not finished | Reload the tab; read the run line’s status and message columns |
| The run fails at once with “There is no company/branch/customer/salesman guid to process” | One of the four lists is empty. There is no “all customers” | Re-create the run with a template whose four lists are filled |
| The run fails with “There is no Job Sheet under company: …” | No FINAL job sheet matched. The message prints the branch list where it means the sales agent list | Finalise the jobs; check each has a sales agent in the list |
| A new run’s Job Sheets tab is empty although jobs are FINAL | An earlier run already holds lines for every eligible job in that company and branch | Use the earlier run, or finalise new jobs first and accept that the earlier run’s lines move to the new one |
| A job already invoiced appears again, unmarked | A later run deleted and re-created the lines for that company and branch | Check against the invoices before ticking; see What a run picks up |
| A ticked line is skipped every time | It carries a failure status; failed lines are not retried | Bill the job by hand in Sales Invoice (Internal), or in a fresh cycle |
| A future-dated run or event never produced lines | A future-dated run is marked as handed over and is never picked up. A future-dated event may never be re-checked | Create runs on the day. After each event date, check the Event listing |
| The invoice’s address or description names only one job | The header is taken from the last job sheet in the group | Correct the draft before finalising it |
Related documentation
- Sales module — where this sits in the product.