What we shipped, in plain language.

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.

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

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.

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.

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

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.

The performance and recruitment setup and check commands did not resolve the tenant passed to them to that tenant’s database, so seeding could act against the wrong one. They now resolve it explicitly.