Procurement Governance

Edit and withdraw before approval

Mistakes happen at the requisition stage. ProcureTrail lets the creator correct them without re-keying.

Edit a DRAFT requisition — PATCH /requisitions/{id}. The creator can edit any field. The field rules engine re-validates the requisition against its requisition type before save, so an edit cannot leave the requisition in an invalid state.

Withdraw an in-flight requisition back to DRAFT — POST /requisitions/{id}/withdraw. Walks a SUBMITTED, PARTIALLY_APPROVED or APPROVED requisition back to DRAFT for re-edit, provided no purchase order has yet been raised against it. A 1–500 character withdraw_reason is mandatory and is preserved in the audit trail. Active POs block the withdraw with a structured 409.

Both endpoints are restricted to the original creator. The audit trail records every edit and every withdraw event with before/after state.

Quantity-split purchase orders

A requisition line can be split across multiple POs to different vendors — for example, a 1,000-unit indent supplied 600 by one vendor and 400 by another. ProcureTrail tracks this at the line level.

The approved-lines endpoint that feeds PO Create returns a live qty_remaining per requisition line — total quantity minus the sum already claimed by any non-rejected, non-cancelled PO. The PO Create form caps the input to this remaining quantity.

On PO commit, the server re-validates. If the requested quantity exceeds the remaining (because a parallel user claimed first), a structured 409 envelope rejects the save with per-line context: total_quantity, ordered_quantity already claimed, remaining_quantity, and the offending pr_item_id. The form parses this envelope and shows the error inline on the affected line.

A PR-line PO-usage drill-down shows the full claim history per requisition line: every PO that consumed quantity, status, claiming line, ordered quantity, and timestamps. Available to the requester, any approver of the parent requisition, or any user with po.create permission.

Quantity returns to the available pool the moment a claiming PO is rejected or cancelled — no manual release step.

Import procurement and direct POs

Import procurement

Import POs carry their own header fields: is_import, currency, exchange_rate, and foreign_currency_amount. The vendor ledger in Tally is created in the vendor's billing currency (8-currency whitelist — INR, USD, EUR, GBP, CNY, JPY, SGD, AED) and every posting against that vendor carries the foreign amount and rate inline so Tally handles forex math, settlement gain/loss, and period-end revaluation natively. See Import accounting for the full receipt and duty flow.

Direct POs without a requisition

For organisations that approve specific PO types without requiring a prior requisition, the skip_pr flag on PO create bypasses the requisition link entirely. The PO still routes through the standard approval matrix — only the requisition prerequisite is relaxed. Governance is preserved; data entry is reduced.

ITC eligibility decided per line at PO approval

For organisations that have opted into per-line GST ITC, the approver decides per PO line whether to claim Input Tax Credit and — where blocked — which of eleven statutory reasons applies (Section 17(5) ineligibility categories, composition-dealer supply, invalid invoice GST, place-of-supply blocks, personal consumption, and so on). The decision is audit-logged with before/after deltas; once the PO is approved, domestic ITC is locked through to posting. Import lines retain the override option on the GRN until POSTED. See Per-line GST ITC.

You Don't Need All of This on Day One

The core workflow — requisition, approval, purchase order, goods receipt — works out of the box. Everything below is an optional toggle, off by default: gate entry, mismatch resolution, TDS tracking, Tally integration, HSN/SAC validation, bypass PO mode, and piecemeal delivery. Turn each on when your process requires it.

From Purchase to Asset Register

The procurement chain does not end at goods receipt. When a GRN is posted, assets are created in the fixed asset register automatically — with classification, cost, department, location, and depreciation class inherited from the procurement documents. Each asset gets a unique system-generated ID and is immediately available for QR tagging and physical verification.

This means the asset register is not a separate system that someone has to update manually. It is the natural output of the procurement process — every asset traces back to its requisition, purchase order, and goods receipt, with the full approval trail intact.

Related

Further Reading