What we shipped, in plain language.

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.

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.

A Gantt chart is a split pane, and the stylesheet for the splitter was never loaded, so both halves rendered full width and stacked — the chart landing on top of whatever followed it, and worse the more activities there were. The chart also sizes to its row count now, rather than leaving three bars above 300px of empty timeline.

Three unlinked three-day activities with one person on all three all started on day one and asked that person for twelve hours a day against a capacity of eight. Nothing said so.

Capacity is now two separate acts. Conflicts are reported on every run and on page load; levelling moves work, and only when the project is set to. That choice is stored on the project and applied by one switch that schedules and saves — as a preview-then-commit pair a refresh lost it, and as a per-run flag the next plain run silently un-levelled the plan and restored an over-allocation nobody had chosen to accept.

Levelling adds real dependencies rather than just moving dates, so float and the critical chain stay meaningful; it never moves a pinned activity; and zero capacity on file means “nothing to compare”, never “no hours”.

Why nobody had ever seen an over-allocation: adding a person through Project People created their row with zero capacity, a rule meant for external contacts. Only external kinds are zeroed now, and capacity is editable for the first time, from a column on the Project People page. Existing employee rows already stored at zero are not repaired automatically — audit them.

Leaving the activity code empty now allocates one per project: multiples of ten, four digits, so 0015 can still be inserted by hand between 0010 and 0020. The maximum is read as a number, never as text, and a code that has been used and deleted is never reissued.

Short Permission is counted in hours. Applying for it through the day-leave screen was written down as a day request, sent for approval, and refused only at the point of deduction — correct, and far too late: the request is a dead end whose only exits are Reject or Cancel, and the approver is told about a quota block that was never supposed to exist.

Nothing stopped it because the type appeared in the day-leave dropdown and neither day-granular entry path checked the unit. Both dropdowns now exclude hours types, and both entry paths refuse by name — naming the Permission screen rather than talking about quota blocks. The deduction-time refusal stays as the last rung, for a row written before this change.

Ties are the rule, not the exception — a journal puts every one of its legs on the same day by definition. On one tenant, 751 of 1,152 vendor rows, 2,320 of 2,637 customer rows and 31,638 of 32,888 GL lines share a posting date with a sibling.

Where the balance is accumulated in one order and the rows are shown in another, a run of credits appears to shrink the payable. The accumulation order is now stamped on each row and the Posting Date column sorts by it outright — which also settles the rows whose displayed date falls back to the document date.

Under any other sort the balance genuinely cannot chain, so it is greyed and italicised with a tooltip saying why. Greyed, not blanked: it is still that row’s own true balance. The Excel export cannot carry a tooltip, so it is always written in statement order with a header line saying the file does not follow the screen.

A balance accumulated in floating point lands a settled row a hair above zero rather than on it, which painted it as still owed. It is now compared against half a paisa.

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.

The step that exists to state what is really on the server was reading the hand-maintained frontend version rather than the one the release bot bumps on every merge. It now reports the authoritative version, and the frontend value separately, so any drift between them stays visible instead of silently misreporting the release.

An advance applied to an invoice used to be silently detached when the payment was reversed, leaving its journal standing. The invoice reopened in the sub-ledger while the general ledger still showed the payable relieved.

The application is now unwound properly, and a give-back that cannot post abandons the whole reversal rather than deleting a row against a live journal.

The Bank Book is the bank account’s ledger read by posting date, so a July payment reversed in September showed the cash gone for two months that the bank statement never lost — and no reconciliation in between could close.

Each contra now mirrors its own original’s date, so an advance paid in July and applied in August produces two contras on two dates. A closed period is refused by name, never slid forward to today. A dishonoured cheque is the one real later event and states today explicitly.

The payables reversal produced an unlinked contra: a journal that merely happened to be the opposite of another. Nothing then stopped a second contra being posted — which credits the bank all over again — the GL ledger marked neither side, and the Bank Book could not pair them to hide a reversed pair. Both are now linked, and a journal that is already reversed is refused.

TDS reversal had never run once: it filtered on a column the record did not have, so every call failed into a one-line log entry and a reversed payment left its tax standing in the statutory register for ever. The register now carries the payment reference, the original row is marked reversed rather than deleted with a negative mirror booked beside it, and the register nets to zero with both facts still on it. The same missing field is why a payment advice has never shown its per-section TDS breakdown; it does now.

Administrators: run batch_migrate --app fi_ap_core and batch_migrate --app fi_ap per tenant, then set the realized gain and loss accounts per company under Finance › FX Revaluation.

A foreign-currency advance is booked at the payment-date rate and the payable at the invoice-date rate, so applying one moves two different rupee amounts. Posting both legs at a single rate left a residue in Trade Payables that no invoice explained and no allocation ever cleared.

Applying an advance now debits Trade Payables at the invoice’s rate, credits Advance to Vendors at the advance’s rate, and posts the difference to exchange gain or loss — the payables mirror of the customer receipt engine, reading the same configured accounts.

A rate of exactly 1.000000 on a foreign document means “nobody entered one”, not one-to-one. It is refused at entry, which is the only moment it can still be typed correctly, as well as at allocation. A domestic allocation still posts exactly the two legs it always did.

A reporting screen over every task in the tenant, with the grid and a pivot over the same rows, lead time and completion type derived consistently in one place, and an Excel export.

Work that was never on the plan can be recorded as such instead of being quietly appended to a project as though it had been scheduled, so the difference between what was planned and what actually happened survives into the report.

Thirty-one lists across the Project System declared a filter and none of them applied one. Asking for a single project’s activities was accepted, ignored, and answered with the whole tenant — so the Schedule tab drew every project’s activities, and so did Cost, Procurement, Billing, Issues, Meetings and Revenue. Nothing errored, because an ignored filter looks exactly like an empty one.

Until now the only way an activity could be created was the MS Project importer — which refuses a project that already has activities, so the first import was also the last, and a project created on screen could never have a network at all.

The new Network tab adds, edits and deletes activities and relationships beneath the Gantt. The Gantt itself stays read-only: the scheduling columns are engine-owned. Confirming what actually happened and changing the plan are now gated separately, so a technically complete project refuses new scope while still accepting the news that old scope finished. A tenant is no longer limited to one seeded calendar: a new Calendars page maintains them.

The cost plan had no screen either, so a plan line was uncreatable. Since a baseline copies its planned cost from the approved plan, that is why every project reported a budget at completion of ₹0 — and presented it as an answer.

The new Cost Plan tab carries plan versions, a line editor and approval; baselines now carry planned cost and record which plan it came from; and earned value returns a stated absence with a reason where there is no plan, rather than a zero.

The WBS tab only ever had a create path — no edit, no delete, no status change — and even Add was disabled once the project left draft. The backend had supported all of it since the module shipped; nothing reached it.

Every writable field is now editable, including the parent: moving an element re-numbers its sub-tree, and how many elements moved is reported back rather than left for the planner to discover. Nothing is gated by a greyed-out button — the rules live on the server and a refusal is shown verbatim, which is the whole reason it names what is in the way.

Delete needed a guard before it could be offered at all. Removing an element would have left posted cost, open commitments and captured time addressing a work package that no tree shows, because a soft delete does not fire the database’s own protections. Every reference into the element is now counted first, walking the relationships themselves so a new one is covered the day it is added.

Administrators: run setup_rbac after upgrading — the scheduling permission now means “may change the plan”, so re-check who holds it.