What we shipped, in plain language.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

Typing in the Purchase Order / Purchase Requisition dialog lagged noticeably on tenants with hundreds of orders, because the list grid behind the dialog re-rendered on every keystroke. The grid is no longer redrawn while you type.

The Sales Order column on the Purchase Order grid lists every sales order on the order's lines, so filtering for a sales order that was not the first one on a multi-order purchase order returned nothing. The column now filters on "contains", which answers the question the column is actually asked: which purchase orders touch this sales order?

Price lists, condition records, customer groups and floors now use the standard Syncfusion Grid used across the rest of the application — with column filtering, grouping and Excel export — plus a searchable material picker for condition entry instead of a plain dropdown over the whole material master.

Vendor invoice totals can now be rounded to the nearest whole currency unit, with the difference posted to a dedicated Round Off account. This works on both the PO-based and non-PO (FB60) invoice forms, and the Round Off row is shown on screen as you enter the invoice.

Rounding is applied only when the company has both the setting switched on and a Round Off account configured — no account is ever guessed, so an unconfigured company keeps its exact total rather than producing an invoice that cannot post.

A Simulate button on the non-PO invoice form shows the exact journal entry the invoice would post — every debit and credit line with its resolved GL account, cost centre and enterprise node, plus the fiscal period and the debit/credit tie-out — before the invoice is saved. Nothing is written by a simulation.

Configuration problems (a supplier with no payables account, a tax code with no input tax account, a closed period) are listed as blockers beside the preview, so they can be fixed while the form is still open.

An invoice line can now be marked as Debit or Credit, so a deduction or recovery can be entered on the same document instead of needing a separate credit note.

A foreign-currency vendor invoice now carries its own exchange rate, fixed at the document date and used to translate every GL line into the company currency. The rate is proposed from the exchange rate master; if there is no quote for the pair the form asks for one rather than silently posting at 1:1.

Exchange rates can also be fetched automatically from an external provider into the rate master, so vendor invoices, foreign-currency revaluation and the financial statements all read the same stored, dated rate.

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.

Help documentation for the SD Pricing and Mobile Warehouse modules was authored on two parallel branches, leaving the content set with two competing endpoints and blocking deployment. The branches are merged and both sets of help pages install as intended.

Quotation and Sales Order entry gained a Suggest Price action that reprices the draft from the engine, with chips showing which lines were priced automatically and which were manually overridden. Only drafts can be repriced — an issued document is never silently repriced behind your back.

Define a minimum price or minimum margin percentage per company, customer or material. A line that breaches it either raises a warning or is blocked outright, depending on how the floor is configured.

A single condition-record table drives base prices, percentage and amount discounts, surcharges and freight, keyed by any combination of customer, customer group, price list, material, product variant or product hierarchy.

• Most specific record wins, on a fixed and predictable ladder
• Quantity scale tiers (buy more, pay less) and validity dates
• Tax-inclusive list prices are converted to net automatically, and records in another currency are converted at the document's rate
• Every priced line stores a full breakdown of how the price was reached — including records that were considered and skipped
• The engine never invents a price: when nothing matches, it says so rather than guessing

Selling prices now come from a maintained Price List instead of being typed on every document.

• Price lists move through Draft → Released → Archived, so a season's prices are prepared and reviewed before they can be used
• Assign a price list to a Customer Group, with a per-customer override where a specific buyer has their own deal
• Copy an existing list with a percentage uplift (e.g. "next season +8%") and export any list to Excel

The new Pricing workspace (/crm/pricing) includes a Simulator that prices a whole draft document in one call so you can see the effect of a change before releasing it, plus margin analytics comparing engine-priced sales order lines against moving average cost.

Two new roles: Pricing Analyst (view and maintain draft price lists) and Pricing Manager (full access including release, floors and price override).

Two new roles: Import Costing Clerk (build sheets, enter charges) and Import Costing Accountant (full access including posting and reversal).

Build a Landed Cost Sheet against a Bill of Entry / BL-AWB / container to allocate import charges across the goods-receipt lines they belong to, even when those lines span several goods receipts and purchase orders.

• Allocate by Value, Quantity, Weight, Volume, or a manual split
• Live allocation preview before posting
• Charges already consumed from stock are automatically expensed instead of loaded onto units that no longer exist
• Non-inventoriable charges (e.g. import IGST) post as an input tax credit instead of loading stock
• Full reversal support

After the security hardening release made authentication the default everywhere, the public marketing website pages (blog, pricing, contact, tenant validation) started requiring a login. These are explicitly anonymous again, as intended.

The Purchase Order PDF derived a line's CGST/SGST/IGST split by checking whether the tax code's name contained the text "CGST" or "SGST" — an intra-state code literally named "GST 18%" contains neither, so its tax was wrongly bucketed entirely under IGST. The split is now read from the tax code's own configured CGST/SGST/IGST percentages instead of guessed from its name.

A formatting slip in the production host allow-list merged three separate entries into one unusable value, causing direct-IP requests to be rejected. The allow-list is corrected and no longer includes a port number where one is not matched.

The application no longer fails to start in a production-like environment with debug mode on if the debug toolbar package is not installed.

Continued refinement of the garment costing entry screens: Order Info section, Batch, Making Cost, Trims & Labels and Value Additions grids updated with clearer material selection and layout.

The unused R-Shiny analytics integration (already decommissioned) has been removed from the codebase, and the marketing product catalog refreshed with pages for modules that had none.

The Free of Cost (FOC) Delivery and Credit Management list pages now use the standard Syncfusion Grid (in line with the rest of the app) for filtering, grouping and Excel export.