What we shipped, in plain language.

Tenant onboarding clones a template database, but the deploy upgraded only live tenants and skipped the template by design. After the first deploy the template was one step behind and every new tenant fell back to a full migration run measured in hours rather than a clone measured in minutes.

The deploy now upgrades the template and checks it afterwards. Both steps are loud but do not fail the deploy: a stale template still provisions correctly, merely slowly.

A journal line carries both the transaction amount and its company-currency value, and several readers had the wrong one. Summing the transaction amount mixes currencies, and it scores a purely company-currency leg — an exchange difference, which has no foreign amount by design — as zero.

That is how a correctly posted exchange gain stayed invisible on the GL ledger, the Trial Balance, the P&L, the Schedule III set and the Bank Book. All of them now read the company-currency figure.

A sales invoice’s rounding difference was posted to whichever account happened to be matched first on an unordered search. On one tenant that scattered rounding across four accounts, 734 entries of it into an account that had been deleted, and put 109 lines into other income. The difference now goes to a configured round off account or is not posted at all.

The note print form was rebuilt, and a note line can now cite more than one sales order — an adjustment frequently spans several. The AP posting configuration also gets a maintenance screen, which it has never had.

An approver can now read the document itself — header, parties, amounts and line items — without leaving the approval.

It is derived from the live document, never from the snapshot taken when the workflow started, so it shows what is actually being approved. And the approval is the authorisation: requiring the owning module’s permission on top would blank the tab for exactly the finance and management approvers the workflow routed to. A document type nobody has registered still renders, by inspection, and every field is read under its own guard so one unreadable value cannot take the panel down.

“User must have an associated employee record to track time” named neither the login nor where to link it, and read as a fault in the task. The message now says which login is unlinked and points at the employee master’s User account field.

Send to Tasks on the Network tab creates a task for each activity under the project’s own task container, linked to the activity it came from, and mirrors the network’s relationships as task dependencies with their type and lag.

There is one writer per direction. The plan flows activity to task: dates, duration, effort, WBS, the critical flag and the assignee, and re-running re-syncs those columns without rescheduling the whole container. Progress flows task to activity: the actual dates and percentage written on the task are reflected onto the activity, and confirming a linked activity directly is refused by name — an activity that has been sent to Tasks is worked on the task.

Refusals are per activity and reported — not scheduled, nobody named, task already finished — while a Created or Closed project refuses the whole run.

The Issues & Changes tab was a read-only grid over an API no screen called, so an issue could not be raised anywhere in the product. It now carries Raise, Edit and the status moves Start, Resolve, Close and Reopen. Resolve asks for the resolution text first, because the server refuses to close an issue without one.

The project detail page can also be deep-linked to a named tab, so the dashboard’s governance panel opens straight onto the issues.

A new Time Entry screen regularises hours the task timer never captured. The week is resolved from the employee and the date rather than picked, and there are named refusals for a future date, a project that cannot take actuals, a summary element, an activity from another project, and a line or a day over twenty-four hours. Hours transferred from a timer are corrected at the timer; hand-entered ones are edited here.

This also fixes costing: no path had ever stamped a timesheet line with the resource it belongs to, so every line was refused and no sheet could be posted at all.

Confirming an activity — the actual dates and the progress — used to require the right to re-plan, because it was an edit on the activity row. So a team member who could report “finished” could also rewrite the network. Confirmation is now its own act under its own permission, accepting only the three confirmation fields; a plan field sent with it is refused by name.

Three roles ship with it: Project Director (oversight and change approval), Project Manager (the create-and-run set) and Project User (view, confirm, record time, meetings and chat).

Because not every tenant runs the Project System, the existing Tasks-only Project Manager role is renamed Task Manager in place — same role, same people assigned to it, any administrator edits kept — and a new Project Manager is created for the Project System alone.

A Created project cannot accept confirmations at all, and the Network tab now says so instead of hiding the control: release the project from its header, then confirm.

Administrators: run setup_rbac per tenant after upgrading, and re-check who holds Project Manager.

The two ends of the live notification channel spelled the tenant’s name differently, and sending to a channel nobody has joined is a silent no-op — so the bell simply never moved. There is now one definition of that name, shared by both ends.

Portal users, their projects and their access can now be administered from a screen rather than by hand, and the task worksheet’s change tracking was rewritten and covered by tests, so an edit is saved once and exactly as typed.

The member list is the audience: whoever the member dialog shows, plus followers, the project manager and anyone mentioned. Notifying only people who had already opened a room was tried first, and left the first message in every room reaching nobody while the member dialog still listed them.

The bell merges a conversation into one row: one unread entry per room, updated in place and bumped to the top, cleared when the room is marked read. Keeping only mentions was tried first and was the wrong lever — the answer to fifty rows is to merge them, not to discard forty-nine conversations.

Browser and phone notifications arrive as exact complements: the page raises one while a window is visible and the service worker when none is, tagged per room so one project’s message cannot replace another’s in the tray.

Employees, customer contacts and vendor contacts all talk in one project room. They are not admitted under one rule, and that asymmetry is deliberate: the employee roster is tenant-wide, so an employee is in every room, while an outsider is admitted to one. Flattening that would let one customer read another customer’s project conversation.

An outsider can talk, cannot widen the room, and never starts one. One place in the code decides who is in a room, and the REST API, the live socket and the customer portal all ask it — the portal reaching the same conversation through its own address, because a customer’s session is confined to the portal at the edge.

Nothing is written to the database from a socket frame.

Pulling timesheet hours into a project failed with a server error while the preview of the same pull worked, because the transfer reached for a definition through a module that does not re-export it.

The task edit screen gains a WBS element picker, and the task detail screen shows it. Where the signed-in user may not read the project structure the picker is disabled and the stored value is left alone rather than cleared on save.

The goods receipt printout carries additional document detail that previously had to be looked up on screen.

The sales order BOM list and detail show the structure’s level and its place under its parent, so a three-level explosion reads as one contiguous tree starting at its finished good rather than as an unordered list of structures.

A project can record the date it is expected to go live, and the project list and dashboard report against it.

On a USD 1,00,000 advance, one tick of the sixth decimal moves the rupee value by ten paise — so the figure on the bank’s advice is simply not on that grid. Operators were inventing a rate to state an amount, and leaving a rate in the ledger that nobody had quoted.

A Value in company currency box on the advance form takes the bank’s own figure and derives the rate from it. There is still exactly one source for the rupee side; only which of the two it is changes. Leaving the box empty — the default, and every advance raised before this — derives the value from the rate, so no existing document behaves differently.

Three figures are refused: a rupee value on a home-currency payment, one implying a rate of exactly 1.000000, and one more than 10% away from the rate beside it — that is a figure in the wrong box, not a rounding correction.

Applying the advance apportions the stated amount rather than re-multiplying a rounded rate, so applying it in full gives back precisely what went out, and the reversal carries the stated value too. The rupee side of the journal is now a residual, as the foreign side always was — which also fixes a latent defect where an advance with a bank charge balanced exactly in dollars and was out by four paise in rupees.

Administrators: run batch_migrate --app fi_ap_core per tenant. No new permissions.

A sales order BOM is one structure per manufactured material, not one per order line. Generating only the line’s own level left the fabric — two levels down, under the stitched garment and the cut panel — outside the order entirely, so nothing planned, costed or procured it.

The explosion now walks down through every manufactured component. A manufactured component with no structure behind it is reported, never swallowed, and an active BOM that happens to hold no components is named in a warnings list rather than producing an empty structure under a success message.

Two things that made this look broken when the walk was actually right: an order generated before multi-level explosion existed answered “already exists” and did nothing — Generate now fills in the missing sub-levels — and with all three levels present the list was ordered newest-first, so the sub-levels filled the first page and their finished good sat on page two. A tree is now contiguous and starts at its finished good.

Anything that totals a sales order now counts top-level structures only — the budget conversion above all, or the garment is charged two or three times over.

Where a component material has an unambiguous variant of its own matching the parent’s attributes, the requirement is now planned against that variant — so a size grid and a colour assortment plan per colour and size rather than in bulk. Everywhere the match is ambiguous the behaviour is exactly what it was.

The Invoices, Planned Orders, Put-Away, Goods Issue to Cost Centre and Purchase Order grids now page, sort, search and filter on the server, and export the whole result set rather than the page on screen.

The rounding toggle on a vendor invoice has three states, not two. Unset — the default, and every invoice raised before this existed — means the operator has overruled nothing and the company’s AP posting configuration decides, exactly as it always did. Only an explicit yes or no overrules it.

The rounding difference must have somewhere to post, so a configured round off account is a precondition even when the toggle is switched on by hand: an invoice that cannot post is worse than one that is not rounded.