What we shipped, in plain language.

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.

“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.

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.

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.

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.

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.

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

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.

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 form has a guard that clears the selection when the customer or currency changes, so a choice made for one customer cannot leak into the next. On an edit screen the form mounts empty and the receipt loads a moment later — which the guard read as a change of customer, and it wiped the selection the loader had just restored.

The display was only half of it. The save then sent an empty allocation, which is taken as an instruction to delete the rows outright — so a save from the edit screen destroyed them, with nothing recording what the allocation had been, and the receipt afterwards settled the oldest open items in turn instead of the invoices the operator chose.

The loader now stamps the record’s own customer and currency before the guard sees them. The cross-customer protection is unchanged: changing customer or currency in edit mode still clears the selection.

A note line can cite the sales order it adjusts, so a customer reading the note can tie it back to the order rather than to the invoice alone. It is optional by design: a rate-difference or billing-error note frequently has no order behind it, and a payables note never does.

Where a vendor bills more than the goods receipt supports, the excess is now raised as an AP debit note when the invoice posts, rather than being coded away as a price or quantity difference. An over-billed line is a claim on the vendor, and a claim is a document.

The difference therefore does not move the stock valuation: the goods are worth what was received, and the excess is money to be recovered. Reversing the invoice takes the note with it.

Under-billing deliberately raises nothing. A note in the vendor’s favour is theirs to issue, not ours to invent.

Administrators: the behaviour is off until enabled per company in the AP posting configuration.