What we shipped, in plain language.

The dashboard reported only the payable side, and the unallocated-payments figure was never rendered at all. It now carries the full advance position.

• Six new indicators: Advances Outstanding, Advances Paid Year to Date, Advances Pending, Advances Over 180 Days, Unallocated Payments and Net Exposure
• Ageing buckets for open advances, a six-month paid versus adjusted trend, and top vendors by open advance
• A drilldown that lists the open advances behind any bucket, one row per down payment request

The Vendor Ledger statement disagreed with itself in several places at once.

• The running balance accumulated newest to oldest, so the statement printed backwards — the newest row showed its own movement alone and the oldest showed the closing balance
• The statement keyed on the document date rather than the posting date. A sub-ledger that does not run on the General Ledger date cannot be reconciled to the General Ledger
• An opening balance brought forward into the selected window is now shown, so a filtered statement still ties

Customer Ledger and General Ledger carried the same statement defects and have been corrected on the same terms — posting-date ordering, a forward-running balance, and a balance brought forward.

Any statement line now opens the underlying accounting document with its full set of journal lines, so a query on a balance can be answered without leaving the ledger.

Layout, filtering and data-entry improvements on the Customer Payments page, following the ledger statement corrections in the same release train.

Analytics components that were no longer part of the product — and a scheduled refresh job that had never succeeded — have been removed, along with roughly 4 GB of unused machine-learning runtime. Faster deployments, less to go wrong, and nothing you use is affected.

Firewall rules were reconciled against the services actually listening, database access was restricted to the application tier, and repeated authentication failures are now blocked automatically.

One document type can carry several series — by company, branch, or any variant you distinguish — so each stream of documents keeps its own running number.

A variant that could never fire is refused at configuration time rather than discovered later as a gap in the sequence.

Every document type — orders, invoices, receipts, notes, vouchers — can now be given its own numbering rule: prefix and suffix, sequence width, and how and when the counter resets.

• Maintained as data, per company and per document type
• A document type you have not configured numbers exactly as it did before — adopting the feature is a decision you make one type at a time
• Numbers already issued are never renumbered

Before a change is released you can see what it touches: which orders are already open against the affected lines, and a decision recorded per order about what should happen to it.

• Change register with search and filters, plus a detail view of everything a change proposes
• Change history on the BOM itself — what changed, when it took effect, and under which change order

Once a BOM is released, production orders, purchase orders and budgets have been planned against it. Editing it in place changes what those documents were costed on, silently. A released structure is now changed only through an Engineering Change Order.

• Draft, submit, approve, reject or cancel a change, and raise a counter change that stages the exact inverse
• Release either by line effectivity (end-date the old line, start the new one) or as a new version of the structure
• Every change carries a category and an effective-from date, so which BOM applies on a given day is a single, unambiguous answer
• If somebody moved a field underneath the change while it was in flight, the release is refused and the field named — it is never silently merged
• There is deliberately no un-release: a release has a date, and work has been planned against it

The BOM endpoints previously required only a signed-in user, so any user of the tenant could create, edit or delete any BOM at any plant. They now require explicit BOM permissions, and two focused roles ship with the feature: BOM Engineer (authors and raises changes) and Engineering Change Approver (approves, releases and decides impact).

Administrators: review role assignments as part of this upgrade so the BOM screens stay available to the people who need them.

Usability and presentation improvements across the Customer Payment screen so a receipt can be captured and checked against the customer’s open items in fewer steps.

A post dated cheque is a promise for a future date, not a receipt today. Post Dated Cheque Management records the instrument when it is taken, holds it until its due date, and carries it through presentation, clearing, dishonour and return — with the accounting following the cheque rather than the calendar.

• Register cheques received and cheques issued, with their instrument dates and banks
• Track each cheque through its lifecycle to clearance or dishonour
• See what is maturing, and what remains on hand

The payables sub-ledger knew about cancelled payments but not about reversed ones, so both halves of a reversal landed as debits — the original kept its full debit and the reversal document posted a second one. The payable was relieved twice instead of netting to zero, and the Vendor Ledger screen disagreed with the General Ledger, which was never wrong.

A reversal now posts as a credit under its own transaction type, and the pair nets to nil.

The Product Specifications screen has always hidden its buttons behind permissions, but those permissions did not exist — so no role could hold them and the actions were drawn for tenant administrators only. A user holding the whole Materials Manager role saw the page read-only, with nothing on screen able to explain why.

• Nine specification and document permissions are now assignable from Role Management, and are picked up by the Materials Manager role on re-seed
• The specification and document endpoints enforce them server-side, so the screen gate is no longer cosmetic

The BoM Beta style intent pane was reworked: intents are validated as they are built, the queue shows what is ready and what is blocked, and an intent that cannot be projected per size is reported with the reason instead of producing a plausible-looking wrong bill of materials.

Generation from a style intent was reworked so component and consumption derivation is consistent between the wizard and the generated bill of materials.