What we shipped, in plain language.

Creating or approving a second Original budget document against the same Sales Order, fiscal year and period is now blocked. Because the budget ledger is additive, a duplicate approved Original previously doubled the available budget.

Foreign-currency Sales Order exposure was being divided by the order exchange rate instead of multiplied, understating exposure against the customer credit limit.

Importing purchase orders no longer mismatches a line to the wrong product or the wrong colour variant of the right product.

Consolidated multiple screens onto the standard Syncfusion Grid + PivotView pattern for consistent filtering, grouping and Excel export.

Usability and workflow improvements to the Goods Receipt page.

Usability and workflow improvements to the Sales Order page.

Credit limit checks now read the limit in the currency configured on the customer record, instead of assuming the company’s base currency.

The budget document header and a new KPI card now derive and display the value committed by open purchase orders against the budget, instead of a stored field that always read zero.

Style Intent entries can now be searched and filtered by colour and size.

Additional UI pages added to Quality Management and its master data screens.

Additional UI pages added to the Production module.

A Sales Order budget is no longer a single money bucket — each line now names a material, operation, or service with a quantity and rate, and the line amount is engine-computed from them. Purchase orders can be controlled at the SO pot, per-material, or per-operation level, and later changes to a dimensioned budget emit a matching supplement/return pair so nothing is stranded in a sub-budget.

Verifying a goods-receipt-based vendor invoice against the vendor’s own billed amount now surfaces typed differences instead of silently absorbing them: price and quantity differences reallocate against the receiving material’s stock account (with a matching stock revaluation), while round-off and unplanned delivery costs post to their configured GL accounts. The invoice cannot be approved or posted while it doesn’t balance to the vendor’s billed total.

House Bank Accounts can now be created and maintained from a dedicated UI page instead of Django Admin.

A single vendor invoice can now reference and bill against more than one purchase order.

Early beta of AI-assisted Bill of Materials creation: a material code minter, a size-decision step for size-grid items, blocking lints that catch invalid configurations before they reach the BOM, and a resolver that maps an approved style intent straight into a generated BOM.

The SAVE/SUBMIT/FILE/GET call sequence now matches the GSTN spec, with proceed-to-file made best-effort and an unconfirmed GSP contract blocking SUBMIT/FILE until verified. Destination of supply for B2C invoices is now computed from the real place of supply rather than assumed.

GST Master, GST Usage, and the new Returns workspace are now grouped together under a single GST menu in Accounting.

GST reconciliation output is wired to the GSTN return builder through the confirmed WhiteBooks GSP contract, adding an HSN summary split and a dedicated Returns product surface for preparing, saving, and filing returns.

New help articles covering e-Invoicing, e-Way Bill, the Customer Portal, Vendor Capacity & Capability, Purchase Returns, Customer-to-Vendor conversion, and GSTR-1/GSTR-3B filing.

Introduces a Business Partner link layer so an existing customer can be linked to a vendor record (and vice versa) without duplicating master data. This is Phase 1 of a multi-phase rollout covering the shared partner identity.

Accounts Receivable receipts now record which house bank account the funds landed in, keeping the Bank Book and AR ledger consistent.

A running day book of every posting against a house bank account, giving finance a single ledger view of bank movements without pulling the full General Ledger.

Bank charges, interest, and inter-bank transfers can now be posted directly against a house bank account, without routing through a customer or vendor sub-ledger.

Reversing a statutory payment reopens the accrual it cleared and nets the payment’s own posting against the reversal, so a reversed challan no longer leaves a phantom balance on the liability account.

GST payable, TDS/TCS, PF, ESI, professional tax and advance tax accounts can be flagged as open-item managed. Every posted journal line on a flagged account becomes a clearable open item, matching Schedule III’s treatment of these as Other current liabilities → Statutory dues rather than trade payables.

Record a statutory challan as a single-account payment, select the accrued open items it clears, and post interest or penalty as separate expense lines that don’t distort the liability account.

New /financial/gl-open-items worklist with per-account cards and a “Pay Selected” action, plus manual clearing for items that already net to zero.

Full purchase-return workflow against a goods receipt: physical return, a GST-compliant debit note with ITC reversal (Route A), and an outward tax invoice with e-Invoice and e-Way Bill for cases that must move as an outward supply (Route B). A route engine selects the correct path, covering reverse charge, SEZ, composition and import vendors.

Quality Management inspection results can now split a goods receipt line and auto-raise a partial rejection return, instead of rejecting the entire receipt.

Purchase returns now feed the GST register and GSTR-3B contributions, reconcile against GSTR-2B, surface pending credit notes, and roll up into a vendor return scorecard.

Contract Management’s signing-certificate encryption no longer derives its key from SECRET_KEY, removing a hidden coupling between application secret rotation and signed document integrity.

GST returns can be prepared, submitted and filed from the new GST Compliance workspace, reusing the existing GST reconciliation data rather than a second set of figures.

The lifecycle is maker-checker: the person who prepares a return is not the person who files it.

A pass-through usage meter (/admin/gst-usage) records how many e-Invoice, e-Way Bill and return calls each tenant consumes, so government service provider usage is visible and attributable.

A single workspace (/financial/gst-compliance) shows e-Invoice status, e-Way Bills, returns and the credentials / masters behind them. Eligibility rules decide which documents actually require an IRN, so exempt documents are not pushed to the portal.

An e-Way Bill is raised from the invoice's existing IRN, so transport details do not have to be re-keyed. The delivery dispatch can trigger it, and the e-Way Bill number and validity are held against the invoice.

A sales invoice can now be registered with the government Invoice Registration Portal directly from the invoice screen, returning the IRN, acknowledgement number and the signed QR code.

• New e-Invoice panel on the invoice detail page with a live status chip and Generate / Retry / Cancel actions
• The IRN and QR code are printed on the invoice PDF, as required for a valid tax invoice
• Export invoices and credit / debit notes are supported with their own payload rules
• Every call to the portal is logged and can be inspected from the panel via View API Log, so a rejection can be explained rather than guessed at

Portal credentials (user name, password, client keys) are held in encrypted fields and are never returned by the API. Access to the GST compliance screens is controlled by dedicated gst.* permissions.

Quotations, order acknowledgements, delivery challans, packing lists and invoices are rendered on demand from the live record, so the customer never receives a figure the system has since corrected.

Anything else is shared deliberately: from the internal Customer Portal screen you can publish a document already in the library or upload and share a file in one step (optionally against a specific order), and withdraw it again with a switch. Only recognised document types are accepted, and an order can only be chosen if it belongs to the customer you are sharing with.

The portal shows each order's progress through twelve stages, from confirmation to delivery. Nothing is keyed in by hand — every stage is read from the records that already exist: the sales order, production order, material issues, shop-floor operations, quality inspection and the delivery notes.

A stage with no evidence reads as not started rather than a guessed "in progress", and a stage that cannot apply (an order supplied from stock has no production) is marked not applicable so the order can still reach 100%. Shop-floor detail is hidden unless you switch it on for that company.

Customers can now sign in at /portal to see their own orders, shipments, invoices and documents, without anyone having to email them a status update.

• Several people per customer, each invited by email and setting their own password through a single-use activation link
• Four roles — Administrator, Buyer, Finance and Viewer — so a buyer sees prices while only Finance sees the outstanding balance
• Every screen is restricted to the customer and the selling company the login was issued for

A customer can raise an enquiry, complaint or support request from the portal. It lands in your existing Customer Service worklist with its own SLA clock — there is no separate inbox to watch — and replies marked visible to the customer appear back in the portal.

Notifications are filtered by the recipient's portal role, so a Viewer is never told about an invoice they cannot see.

A new internal screen (/admin/customer-portal) to invite and manage portal users, configure what the portal shows per company, share documents and review the activity log. Two roles are provided: Customer Portal Administrator and Customer Portal Support.

Customers can follow dispatches and see their invoices, account statement and ageing. The figures come from the accounts receivable sub-ledger and the credit engine, so the customer and your credit controller are always quoting the same number.

A customer sign-in is accepted only on the customer portal, the e-commerce storefront and the sign-in endpoints themselves — it is refused everywhere else in the application, and refused on the internal administration screens that sit inside the portal API.

The portal also runs its own session separately from the ERP session, so a customer and a staff user can be signed in from the same browser without signing each other out.

Awarding an RFQ or converting a purchase requisition to an order now surfaces any capacity concern as a warning. These are advisory only — the purchase order remains the point at which a commitment is actually enforced.

Capture how much a vendor has agreed to supply, as a quantity, a value or both.

• Scope the commitment to the vendor overall, to a product or purchasing hierarchy node (covering everything beneath it), or to a single material
• Monthly, quarterly, annual, seasonal or custom periods, with a validity window and a tolerance percentage
• Commitments move Draft → Active → Superseded, so a renegotiated commitment replaces the old one without losing it
• A quantity commitment cannot be saved without a unit of measure, and committed value is always the pre-tax order value

Purchase orders are checked against the vendor's live commitment when they are submitted for approval, approved or released — alongside the existing approval controls, not at draft save.

• Quantity and value are graded separately: either can raise a warning or a block
• A warning is raised at the committed figure; the order is only blocked once the agreed tolerance on top is also used up
• Consumption is recalculated from live purchase orders every time, so cancelling or closing an order frees the capacity immediately with no reconciliation job to run
• Amending an approved order re-runs the check and is rolled back if it would breach

A blocked order can be released by an authorised user with a mandatory reason, recorded in the check log. The release is tied to the version of the order that was released — if the order is subsequently amended, the release lapses and the order is checked again, so approval of a smaller order never silently covers a bigger one.

A new Vendor Capacity workspace (/srm/vendor-capacity) with utilisation and heat views, a breach worklist, the commitment and capability registers, the check log and configuration. The purchase order screen shows the remaining capacity for the vendor as you enter the order.

Quantities that cannot be converted to the commitment's unit, and currencies with no exchange rate, are reported as warnings and left out of the totals rather than being summed at face value.

Record what a vendor is actually able to supply — process types, certifications, minimum order quantity, lead time and a rating, optionally linked to their vendor evaluation. The register is advisory: it informs sourcing decisions without blocking them.

New roles Vendor Capacity Analyst and Sourcing Category Manager; buyers can see why an order was stopped, and procurement managers can release it.

Nothing changes until you configure it: with no configuration or no active commitment, purchase orders behave exactly as before. Start in warn-only mode and switch to blocking once your commitments are loaded.

Saving a price condition failed with "this field is required" for key fields that are meant to be optional — a record keyed on customer and material was asking for a price list, product variant and product hierarchy as well. A condition record now only requires the combination you actually intend to price on.