What we shipped, in plain language.

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.

A purchase requisition is now raised against a cost center rather than a department, so the requirement carries the dimension the spend will actually be reported under. Existing requisitions keep their value under the new field.

Upload a resume — or a batch of them — and the details are extracted for review: name, contact, current employer and designation, notice period, skills and education. Correct anything that needs correcting, then create the candidate record in one step.

• Skills and education map to your existing masters by exact match; nothing is auto-created, so the master does not fill with near-duplicates
• Every field shows whether it came from the resume or from you
• A field the resume did not state is left empty, never defaulted to zero — “did not say” and “none” are different answers
• Duplicate and rehire checks are shown, and neither blocks
• On creation the resume moves to the candidate record, so no second copy of a person’s data is left behind
• A batch of 40 is 40 independent rows — one unreadable file never fails the rest

Extraction only. No score, no fit percentage, no ranking and no ordering of candidates is produced, and protected characteristics are never extracted — shortlisting stays a decision a person takes.

The Help Documentation centre gained articles for the HR foundation (separations, employment history, work schedules), Recruitment, Performance & Learning, and the HR analytics dashboard — including the configuration each module needs before it will work.

Date column filters on the data grids were not matching correctly. Fixed across the application — Sales Orders, Journal Entries, Direct Invoices, Audit Log, Service Tickets, Repair Jobs, Customer Assets, Incidents, Plant Maintenance plans and schedules, Breakdown Reports, Emergency Work Orders, Equipment Health, Support Desk, Tasks, Cut Plans and the Sales Order reports.

An employee used to leave by somebody editing the employment end date — recording no reason, no approver and no rehire eligibility. A separation is now its own record, with a typed reason, an approval, a clearance checklist and a rehire decision.

• The clearance checklist reports outstanding items; it can never trap somebody’s last working day in a validation error
• Exit interviews sit behind their own permission — a line manager sees that an exit happened, not what the departing employee said about them
• Whether an exit was regretted is recorded when a person assesses it, and “not assessed” is never counted as “not regretted”
• The final settlement reads the separation, so every settlement raised before this keeps working

The employee record kept one row, so a transfer overwrote the department and headcount as at any past date could not be reconstructed. Employment assignments are now kept as dated history alongside the master.

Records created at go-live are flagged as such, and every point-in-time answer says so — history is honest about starting on deployment day rather than inventing what came before it.

A full recruitment pipeline: job requisition and approval, candidates, applications through configurable stages, interview feedback, offer, and conversion to an employee record.

• Every transition timestamp is owned by the system, so time-to-fill is an outcome rather than something a recruiter can type
• Blind panel feedback — a panellist sees other assessments only after submitting their own, and a submitted assessment is locked
• A requisition against an already-filled position is refused, so vacancy and open requisitions reconcile
• Rehire history is shown with its reason and never blocks; nothing auto-links a candidate to a former employee
• Declines, expiries and no-shows are kept as three different things, each with its own reason
• Compensation is gated like payroll data — an interviewer never reaches it
• Candidate data retention reports before it acts, and anonymises in place so the hiring funnel history survives

Appraisal cycles with a defined rating scale, and training compliance measured against a requirement rather than a course count.

• The rating scale is frozen onto the cycle when it opens, so relabelling a rating later can never rewrite appraisals already given
• “Not rated” is a real answer with a structured reason — never redistributed, never silently completed at the bottom of the scale, and always shown with the coverage beside it
• Compliance is measured only over the employees a requirement actually reaches; certificates carry the expiry stamped when they were issued
• Ratings are visible to the employee, the appraising manager and HR; reporting access grants distributions, not named individuals

A new HR dashboard covering overview, workforce, organization, time & absence and cost, with drill-through to the underlying worklists.

Small populations are suppressed so an individual cannot be identified from an average, and a panel that cannot be built says why rather than showing an empty chart.

Working days and hours now resolve through a configured ladder — company, payroll area, employee type, tenant default. Where none is configured the system asks you to configure one rather than assuming a 22-day month, which understates absence for shift workers and overstates it for part-timers.