What we shipped, in plain language.

The role seeding routine ran after every deployment and unconditionally reset each seeded role’s permissions, so any permission an administrator added or removed was wiped with no warning and no record. A role edited through the UI is now marked as customised and is skipped by the seeder, which reports exactly which roles it left alone and who customised them. A role can be handed back to the product deliberately.

Service cost groups, the service GL determination matrix and a completeness check are maintained at a new Service Accounting screen. The completeness tab reports the two configuration causes of a refused posting — a group missing its expense or SR/IR account, and an active service with no group — before anyone meets them at posting time, and the Service Entry Sheet page links straight to it.

Permissions can be renamed and recategorised in your own vocabulary, and custom permissions can be created. Shipped permissions keep their identity so existing screens continue to enforce what they always did, and a permission dropped by a release is retired rather than deleted, so the roles holding it keep the record.

A new Audit tab reports, for the deployed code, which API operations each permission guards, which operations are guarded by nothing, which permissions the code enforces that no role can be granted, and which pages are ungated. Each permission now shows its endpoint count with a drill-down.

The Explain tab answers the question every access ticket actually asks: it traces whether a user holds a permission, through which role assignment, granted by whom and when, alongside their row-level scope — because a refused page and a page whose rows were all filtered away look identical to the user and are fixed in different screens. Simulate resolves what another user would see; it is not impersonation and grants no ability to act as them.

Roles can be compared, cloned, exported and imported between tenants (by permission code, so the right permissions land), and every grant and revoke is recorded with who made it — including changes made by the seeder, so “a deployment took that away” is checkable rather than suspected. Users can be assigned to a role in bulk.

The RBAC workspace is no longer restricted to full administrators. A delegated administrator may not grant a permission they do not themselves hold, and may not edit, clone, delete or assign a role carrying administrator rights — without both rules, delegating role maintenance would be a one-click path to full access.

Open-item selection ignored currency, so a receipt in one currency could be allocated against an invoice in another. Allocation now matches on currency; reporting views (ageing, collections) are unchanged and still show every open item.

The receipt simulation now shows both foreign and local currency debit and credit columns, and a per-invoice working — amount settled, invoice rate against receipt rate, amount booked against amount received, and the resulting difference — so an operator can see which invoice produced a gain or loss before accepting it.

A foreign-currency invoice is booked at the invoice-date rate; the money arrives at a different one. The receivable is now relieved at each settled invoice’s own booking rate and the difference is posted to a realized exchange gain or loss account, so no unexplained residue is left in Accounts Receivable. The realized gain and loss accounts are maintained per company alongside the existing revaluation accounts, and an unconfigured account blocks the receipt rather than absorbing the difference silently.

The GR/IR report gains a pivot view for analysing the goods-received-not-invoiced balance by vendor, material, period and document.

A Goods Receipt could be raised against a service line, moving a phantom quantity into a storage location and capitalising labour into inventory. A service line is now identified per line — not per order type — so one order can buy fittings (received into stock) and the fixing of them (entered on a Service Entry Sheet) without being split in two. A remediation command reverses receipts already posted this way.

Reversing a goods movement reused the original movement type, so reversing a goods receipt received the stock again and debited inventory a second time. The reversal now resolves the correct counterpart movement, and a line-level partial reversal is supported.

Permission refusals now name the exact permission required, and a list that is empty because of row-level scoping says so (“No materials in your Purchasing Group”) instead of appearing blank. One refusal no longer discards every other list on the same form.

Service cost groups and account determination mirror the inventory matrix: posting a Service Entry Sheet accrues service expense against a service receipt/invoice (SR/IR) clearing account, so cost lands in the period the work was performed, and the vendor invoice then clears that accrual rather than booking the cost a second time. An unresolved account refuses the posting and names what to maintain, rather than guessing.

Services are maintained on their own master screen with their unit of measure, tax code and cost group, and a migration command moves service-flagged materials onto it while keeping open orders resolvable.

Which roles see which page is now a setting in the RBAC workspace rather than a code change, and the same verdict is applied to a typed or bookmarked URL — a hidden page no longer renders just because its address was pasted in. A refusal keeps the sidebar and names the permission to ask for. Enforcement can be switched off per tenant without a deployment, and any page the registry does not know stays visible.

A Sales Order form needs materials, a Vendor Invoice needs suppliers, a Journal Entry needs GL accounts — modules those users are correctly not members of. Dropdown lists are now served by a dedicated reference endpoint returning only code and label, gated by its own lightweight permission, so a Sales Officer can fill a form without being handed the whole material master. Row-level scoping still applies.

Eight near-identical mail routines across the application were consolidated into a single dispatch service, so every message honours the configured channel and every send is recorded in one Send Log. If no channel is configured, mail goes out exactly as it did before — configuring channels can never stop mail from being sent.

A new Email Channels workspace lets you register your own sending accounts — SMTP or an email API — and assign one per category of message (finance, procurement, HR, support, and so on), with a tenant default behind them. Notices, statements and dunning letters then reach your customers and vendors from your own domain rather than a shared platform address.

SMTP passwords and API keys are stored encrypted and are never returned by the API — a channel reports only whether a secret is set. Leaving the field blank on an edit keeps the existing secret rather than erasing it.

The PF, ESI, Professional Tax and TDS calculators were aligned with the rules the returns are filed under, including PF wage determination, ESI contribution-period membership and ESI dispensary/IP number capture on the employee record.

If no layout is assigned, no tenant default exists, or a configured layout fails to render, printing falls back to the built-in template and reports a warning on the result. Configuring layouts can never stop a document from being printed. Issued tax documents are archived, so a reprint serves the exact PDF the customer received even after the layout changes.

The Purchase Order page and grid expose the amendment flow directly, including line-level editing and the resulting version history.

A new Print Forms workspace manages forms, assignments, themes and components, previews a layout against real document data, and answers “which layout would this customer get?” before anything is issued. Statutory documents (e-Invoice, e-Way Bill, GSTR, Payslip, Form 16, Schedule III) are shown as locked, since their formats are prescribed.

A new Statutory Payroll Filings module prepares the returns that follow a payroll run: PF Electronic Challan cum Return (ECR), ESI monthly contribution, Professional Tax, quarterly TDS 24Q and Form 16. Each filing is a document with its own lines, validation and status, generated from posted payroll results rather than re-keyed.

Amending an approved Purchase Order previously allowed header changes only, so lines could not be corrected at all once the order was issued. An amendment can now add, change and remove line items together with header fields, all recorded as a single version. The vendor capacity check is re-run on the amended order and the whole amendment is rolled back if it cannot be honoured.

Professional Tax slabs are maintained per state with a seeding command, and the payroll area now carries its work state so the correct slab applies. Prior-period carry-ins let earnings, contributions and TDS from a previous system or employer be recorded, so a mid-year go-live still produces a complete return and Form 16.

A filing calendar lays out statutory due dates per registration and period, and a readiness check lists exactly what is missing — unregistered employees, absent UAN/ESI/PAN identifiers, incomplete contribution periods — before a return is generated, instead of failing at submission time.

Print layouts are now configuration rather than code. A Print Form can be assigned per customer, customer group, company or country/language, with a tenant default behind it, so one customer’s Packing List or Invoice can differ from another’s. Layouts, themes and reusable components are maintained separately, so a rebrand does not mean duplicating every layout, and most variations are handled by declared options (column selection, section toggles) rather than a new form.

The Sales Order status service reported the wrong stage for certain order states. The computation is corrected, and the Status Report and Status Workbench now format quantities and values consistently.

Purchase Order line items were not displayed correctly in the administration view; the listing has been corrected.

The RCM liability worklist, category manager, account configuration and reports now use the same grid, so filtering and exporting behave consistently across the GST screens.

The GST Compliance workspace and GST Reconciliation page were rebuilt on the standard high-performance grid, adding column grouping, advanced filtering and Excel export to the reconciliation worklists.

Reading the tax (GST) code master required the CRM Leads module, so an Accounts Payable user saw an empty GST dropdown on a vendor invoice line — the failure was silent and looked like missing master data. Any module that legitimately consumes tax codes can now read them; maintaining the master is unchanged.

Purchase Orders, RFQ and RFI menu items carried no permission gating at all and were shown to users who could not open them. The Procurement menu now shows only what the user is authorized for.

Viewing and maintaining a vendor were gated on the same permission, so anyone who needed to see a vendor’s bank details, GSTIN or payment terms also received create, edit and delete rights on the vendor master. Vendor maintenance now requires its own permission, letting Accounts Payable and Finance be given read access without maintenance rights. The Add and Edit actions on the vendor list follow the same permission.

Purchase Requisitions were gated on the vendor master permission for both reading and writing, so any role that could see a vendor could also create, edit and delete requisitions. Requisitions now have dedicated view and manage permissions, line-level actions are no longer writable by viewers, and raising a Purchase Order from a requisition requires the Purchase Order permission. Existing procurement roles keep the access they had.

The HSN/SAC seed data file was excluded by a blanket rule that ignored JSON files, so the migration that loads it failed for every tenant during deployment. The file is now tracked and the seeding completes.

The material master now selects its HSN/SAC code from the master through a searchable picker, so the code and its GST rate are consistent across every material rather than retyped per record. A backfill command maps existing free-text codes onto the new master.

Vendor invoice GL posting was refined alongside the HSN/SAC work, so tax determination on an invoice line follows the material’s maintained code.

HSN (goods) and SAC (services) codes are now a maintained master with description, chapter and default GST rate, seeded with the standard code set and available through its own API and Django admin.