What we shipped, in plain language.

Several long-standing defects in how the application binds work to a tenant’s own database have been corrected together.

• The tenant switch is now isolated per request thread, so two concurrent requests can no longer influence each other
• Transactions are bound to the database their writes actually go to — which is what makes a rollback roll the right thing back, and a report-only run genuinely write nothing
• One connection per request, so a nested transaction behaves as one
• Fallback reads open a savepoint, so a query that was expected to fail can no longer leave the rest of the request failing behind it
• Tenant provisioning no longer disturbs the shared connection

Bulk schema updates across many tenants now stream per-database progress instead of going quiet, carry a configurable timeout long enough for a large tenant, and surface the real diagnostic when one database fails. Static files are also collected before migrations run, so a single failing tenant can no longer take the interface down with it.

Three list and detail endpoints were issuing a separate database query for every row they returned. They now fetch what they need in one pass, and the screens load noticeably faster on large data sets.

The application carries hundreds of maintenance and reporting jobs — seeders, reconciliations, backfills, health checks — and every one of them was reachable only over a server session, with several different spellings of “report” versus “apply” and two opposite defaults.

• A published catalogue of what each job does, with one uniform way to say “report only” and “apply”
• The catalogue is an allow-list: a job that has not been reviewed and registered is not runnable from the console, full stop
• Apply mode requires the job’s own domain permission, not merely access to the console
• Every run is recorded — who, when, against which tenant, with what result — and a run that was queued but never picked up is reported as stalled rather than failed

Accounting spans receivables, payables, the general ledger, banking, assets and reporting, and finding a screen meant knowing which branch of the menu it lived under. The new landing page lays the whole module out as grouped tiles, so the destination is visible rather than remembered.

The delivery date on a sales order line used to be arithmetic: order date plus the material’s lead time, recalculated every time the order was saved. It consulted no capacity, no materials, no order book and no working calendar — a thirty-day lead time crossing a festival shutdown was still thirty days — and nothing anywhere recorded what the customer had actually been told.

• Capable to Promise answers a salesperson with a customer on the phone, reading the same capacity model the factory schedule runs on, so the promise and the plan agree
• The promise is recorded as its own document, so what was committed, when, and on what basis is auditable afterwards
• A material with no lead time used to promise same-day shipment — the flattering answer, and completely invisible. The date is now left empty instead: a visible gap somebody can fix, rather than a commitment nobody knew was made

Competencies and rating bands ship as seeded master data and combine with goal achievement into a single composite score for the cycle.

• Calibration sessions moderate ratings as a second, independent judgement, with the manager’s original rating preserved
• “Not rated” and “not measured” are real answers — they are reported as such, never quietly defaulted to a middle value

Feedback is collected from managers, peers, reports and the employee themselves, and feeds the composite as a weighted component.

• A rater category below its response threshold is withheld entirely — no mean, no shape, no comments — and is never merged into another category to make the numbers up
• The self rating is collected but excluded from the others’ score and from the response rate
• Not invited, no response and withheld are three different answers and stay apart
• When a category is withheld its weight is redistributed and the amount is shown
• Invitations, reminders and result notices are sent automatically

Performance is placed against potential on a 9-box grid, and what follows from that placement is recorded.

• An employee with no potential assessment is absent from the grid, never placed in the middle — and the grid reports everybody it could not place, with the reason
• Placement is moderated in the same calibration session, as a second independent judgement
• Succession benches, and Individual Development Plans visible to the employee they are a commitment to
• Potential assessments are deliberately not visible to their subject; a development plan deliberately is

Goals are set against a cycle from a reusable template, and progress is captured through the year in check-ins rather than reconstructed at appraisal time.

• Appraisal templates define what a cycle measures and how the parts are weighted
• Goal actuals can be read from the systems that already hold them, instead of being retyped
• Continuous feedback recorded alongside the goal it refers to
• The rating scale is frozen onto the cycle, so changing the scale next year never rewrites last year’s ratings

Descriptions, notes, terms and correspondence leave your company and are read by customers and suppliers. The Writing Assistant checks them as they are typed and suggests corrections in place.

• Runs on a service hosted alongside the application — your text is not sent to any third party
• Enabled per tenant from its own settings screen, with the fields it applies to under your control
• Ships inert: until it is switched on, every field behaves exactly as it does today, and if the service is ever unreachable the form still saves normally

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.