What we shipped, in plain language.

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.

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.

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.

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.

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.

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.

The administration screen’s token box was discarded on every save, so the column stayed empty and the push endpoint then refused every terminal because a device with no token cannot push. The ingestion path shipped in the Shift Rotation and Rostering release had never carried a punch, and nothing reported it — a device that never pushed and a device whose token was never stored look identical.

A blank token on an edit now means leave it alone, never clear it: the dialog cannot prefill a write-only value, so taken literally, correcting a terminal’s location would have silently revoked its credential and surfaced hours later as a missing shift. The last-seen timestamp is also stamped in the plant’s zone; it had been recorded five and a half hours in the future on Indian sites, which suppressed the silent-device alarm for the length of a shift.

Both ingestion paths resolve a punch to a row in a catalogue that no migration, command or fixture had ever populated — so on a fresh tenant every punch would have been rejected. It stayed invisible for as long as it existed because nothing had ever got far enough to reach the lookup. It is now seeded.

An unusable plant time zone also degraded silently to the system default. Every plant on two tenants was configured with a value that is not a real zone name. That fallback is right for a report, which should render rather than crash, and wrong for ingestion — a punch is a permanent fact, and storing one against a plant whose zone cannot be resolved means it can never afterwards be proved right. Ingestion now refuses by name.

Administrators: check that every plant’s time zone is a real zone name (for example Asia/Kolkata) before registering an agent.

The device-shaped push endpoint is promoted into an agent-shaped contract: a credential that is hashed rather than stored, a source transaction id with a database constraint behind it, a batch audit row, an employee mapping table, and a rejection that is kept rather than counted.

A rejection is a row carrying the whole original payload. That is what makes the agent’s checkpoint honest: it may move past a punch we refused only because we are holding it. Counting and discarding forces the agent either to stall on one bad row or to lose it. Held punches appear on a worklist with Replay, Ignore and Add mapping.

A punch travels as plant-local wall clock plus a named zone. A timestamp carrying its own offset is refused, and a declared zone that disagrees with the plant refuses the whole batch and stores nothing — converting would move every punch onto the wrong roster day and nothing downstream would report it. The zones are compared by resolved offset rather than by spelling, and probed twice in the year, so two zones that agree in one season and diverge in the other are caught now rather than in June.

A credential rotation keeps the previous secret alive for seven days, because revoking on rotation means the agent is dead from the button press until somebody has driven to the site. A repeated batch returns the stored result and re-processes nothing. An enrolment number gets reissued, so the employee mapping is date-effective — without that window a leaver’s punches silently become a new joiner’s, retrospectively.

Nothing had ever triggered time evaluation. It was reachable only by a person pressing a button on a screen most tenants never open. Ingestion is deliberately inert — writing down a fact never derives a conclusion — so punches accumulated and no register, exception or overtime proposal was ever produced. A rolling three-day window is now re-derived on a schedule, per tenant.

A dead agent runs on a machine in the customer’s network that nobody here can log in to, and a monitoring screen only answers the question for whoever opens it — which nobody does on the day it matters. A daily sweep asks across every tenant and mails the result. A tenant that is behind on its upgrade is reported as such with its fix, rather than mailed as “agent down” twice a day until people stop reading.

A new Time › Integrations screen carries the silent-agent banner, status, credential rotation, the held-punch worklist, batch history and the employee mappings. On production the evaluation runs every six hours, which assumes nothing about a customer’s shift times and derives a conventional night shift within fifteen minutes of it ending.

Extraction returns the currency as a three-letter code and nothing ever mapped it to a currency record, so posting failed outright. The code is now resolved, and the posting path walks a ladder of authority — document, purchase order, vendor master, company — refusing by name rather than quietly defaulting.

The tax code picker offered every configuration in the tenant: roughly 300 codes across eleven companies in both directions under near-identical labels, and picking another company’s code reached for an input-tax account that was never configured there. Both pickers now scope to the company and to input tax, the invoice’s company is the vendor’s company rather than the first one in the tenant, and a mismatched code is refused by name before the generic accounting error appears.

Exceptions could not be worked at all: an active vendor was compared against a status spelling no tenant stores, so every active vendor raised a vendor mismatch nobody could ever clear, and a document in exception could never be re-validated.

Clicking the exceptions cell now opens a correction dialog that edits the data and the GL coding in place and re-validates, resolving only the exceptions whose check actually passes. What gates correcting is the accounting record, not the approval step — an invoice can sit approved with exceptions open, and refusing to correct it there was the dead end. Re-checking a late correction does not demote a document an approver has already signed.

Simulate shows the journal the invoice would post, through the same engine the manual invoice screen uses. The invoice is built in memory and saved separately, so the preview is produced by the code that does the posting and cannot drift from it — and the preview’s blockers are the posting’s refusals, in the same words.

The vendor’s balance was computed as the total of the aging buckets. That answers what is open and how old is it, not what is this vendor’s balance, and the two agree only while the ledger holds nothing the buckets cannot see: an opening balance is not a transaction, an invoice with no due date is skipped outright, an unallocated payment or advance has no bucket at all, and a posted adjustment note that reduced the payable in the general ledger was invisible in the balance.

Separately, the statement’s running balance left TDS out, so the card and the last row of the grid disagreed by exactly the tax withheld.

Both now accumulate opening plus credits less debits less TDS, so the card and the bottom of the statement are the same figure by construction. The buckets stay what they always were: an aging of what is still open.

A negative closing balance is now possible and correct — it is a vendor sitting in advance, which a bucket total could not express. The KPI row reconciles too: TDS, debit-note and credit-note cards appear when non-zero, and Total Payment counts payments and advances rather than every debit.

Administrators: rebuild_vendor_ledger_balances recomputes the stored values per tenant, reporting by default. On one tenant it corrected 53 closing balances, 33 of which revealed vendor advances nobody could see.

The approvals list exempted administrators and handed them every approval in the system. The dashboard count and the tasks sidebar both read that list, so an administrator saw other people’s approvals presented as their own work and could only find out otherwise by pressing Approve and being refused. Maker-checker working correctly looked like a broken permission.

The queue is now scoped to the caller for everyone. Organisation-wide oversight is not lost — it lives on the workflow instances screen, which is what the administration page actually reads. Every row now also states whether you may act on it, and Approve, Reject and Return are disabled with a tooltip saying why when you may not.

Approval authority in this engine is maker-checker: only the person an approval is assigned to may act on it, and whoever submitted the document is excluded from being resolved as its approver. Delegation offered two ways around that, both now closed by one shared rule.

• The delegate action rewrote the assignment with no checks at all, so anyone who could load an approval could route it to themselves and then approve it. It now refuses a non-holder, a self-delegation, and delegating to the submitter.
• A standing delegation was never checked against the submitter, so a delegation pointing at the person who raised the document handed the approval straight back to them at assignment time. Such a delegation is now dropped with a warning and the approval stays with the original approver, who is a valid checker.