Purchase Orders

What Purchase Order controls

Purchase Order is the formal supplier commitment in AkshaERP. It can be created directly, seeded from an Approved Purchase Requisition, or created from an Approved RFQ Award.

The document does more than store supplier, item and price. It carries the receiving location, commercial dates, payment terms, pricing source, price list, currency, discounts, tax snapshot, financial dimensions and item-line details that later become Stock Receipt and Purchase Invoice data.

A Purchase Order therefore sits at the boundary between Procurement, Pricing, GST/Tax, Inventory, Accounts Payable and Traceability. A change that looks small on the PO can affect what is received, invoiced or reversed later.

Before you begin

Before creating a live Purchase Order, confirm that the Supplier, Item/UOM setup, receiving Location, purchasing price source, tax setup and any required Business Unit / Cost Center configuration are ready.

For an RFQ-driven purchase, normally create the PO from the approved award so supplier, quantities and negotiated commercial values remain traceable to the sourcing decision.

What is mandatory?

AkshaERP has both hard save validations and fields that are mandatory for a correct downstream process. The table below distinguishes them so users do not confuse “screen lets me save” with “document is operationally complete”.

Understand the screen before entering data

General tab – field reference

Delivery tab – field reference

Price & Pay tab – field reference

Price Fetch Source – what each value means

Accounting tab – Business Unit and Cost Center

The Accounting tab uses the shared Financial Dimensions framework for module PUR, function PURCHASE_ORDER and source document PURCHASE_ORDER.

Business Unit and Cost Center are governed by the Financial Dimensions configuration. They may be optional, defaulted or mandatory depending on your organization setup.

When the PO is saved, the current client normalizes line Business Unit and Cost Center to the header values; the server then enriches/validates the transaction again through Financial Dimensions.

Lines tab – why each line matters

A PO line is the commercial definition of what is being bought. Item, UOM and Quantity determine the requirement; Unit Price and discount determine commercial value; tax fields determine statutory value; Batch/Item Set controls add inventory-specific context.

Line changes also recalculate PO header Gross, Discount, Net, Taxable, Tax and Total values automatically.

Item selection – what happens automatically

Selecting Product/Service maps Item ID, SKU, HSN, SAC and default UOM information into the PO line. If Quantity is empty/zero when a different item is selected, the line is initialized to Quantity 1.

The selected Item is also link-enabled so authorized users can open the Item master from the line for reference.

The Item lookup includes the Item purchasing price as reference, but the line Unit Price is still resolved according to the active Price Fetch Source.

UOM – why it is not just a label

UOM identifies the unit in which the ordered Quantity is expressed. A price for Each may not be the same as a price for Box, Pack, Kg or another purchasing unit.

The UOM lookup stores UOM ID, code and name. Automatic line pricing requires a UOM and treats UOM change as a pricing trigger.

UOM is carried into Stock Receipt and Purchase Invoice created from the PO, so an incorrect UOM can affect quantity interpretation across the procure-to-pay chain.

Quantity – what changes when you edit it

Quantity is a pricing trigger. In automatic pricing mode, changing Quantity requests a fresh price because quantity breaks/tiers can affect the applicable purchase price.

Quantity also recalculates Gross Amount and therefore Discount Amount, Net, Tax and Line Total.

When Process Order automatically creates a Goods Receipt, the current automated payload carries the full active PO line Quantity as both Ordered Qty and Received Qty.

How line pricing actually works

• 1. AkshaERP determines the current Price Fetch Source from the PO header. If not already set, it can be defaulted by the PUR / FETCH_PRICE_FROM application setting for the organization/location scope.
• 2. Automatic pricing requires Item, Quantity greater than zero and UOM. In Pricing Engine mode, an applicable Price List is also required.
• 3. Changing Item, UOM, Quantity or Price List queues the line for repricing.
• 4. The pricing resolver returns Unit Price and source information. It also attempts line-level GST/tax preview so price and tax stay synchronized.
• 5. The line recalculates Gross, Discount, Net, Taxable, Tax and Total.
• 6. If the buyer edits Unit Price manually, the line becomes MANUAL and later automatic pricing triggers do not overwrite that buyer decision.

Price List behavior at header and line level

In Pricing Engine mode, the header can auto-select the default or first applicable Purchase Price List for organization, PURCHASE pricing context and currency.

A line normally inherits the header Price List. The line also exposes Price List so a different applicable list can be chosen where policy permits.

Changing the header Price List updates active lines to the new list and requeues automatic pricing for lines that are not manually priced.

Discounts – Percentage versus Amount

Line Discount % can also be edited directly. Gross, Discount Amount and Net recalculate immediately.

Tax behavior and Preview Tax

Tax-relevant changes include Supplier, Order Date, Location, Currency, Price List, Price Fetch Source, commercial totals and line changes. These changes can mark the tax state NOT_CALCULATED or STALE.

Preview Tax requires a Supplier and at least one line. If the PO is new or has unsaved line changes, AkshaERP saves those changes first and then asks the server GST adapter to recalculate/store the Purchase Order tax preview.

The right-side Insights panel warns when tax status is not CALCULATED. It also shows Tax Regime, Tax Status and Tax Jurisdiction.

Barcode entry

The Lines toolbar contains Scan or Enter Barcode. Enter/scan a barcode and press Enter.

If the Item is already on the PO, its Quantity is increased by 1 and the line is re-priced. If it is not present, AkshaERP adds a new line with Quantity 1, Item identity, default UOM and then triggers pricing.

Item Sets on Purchase Order lines

When the selected Item represents an Item Set, the line Actions control can open the Item Set drawer.

You can keep the Item Set as one PO line, in which case AkshaERP applies the configured Set Unit Price and marks the line as SET_PRICE/manual, or explode selected Item Set components into separate Purchase Order lines.

When exploded, component lines inherit document pricing context and are individually priced unless they carry an intentional manual/set price.

How totals are calculated

Save and Apply – what is the difference?

Confirm versus Approve

AkshaERP checks whether an active Purchase Order approval template/chain is configured for module PUR and function PURCHASE_ORDER.

If no approval flow is configured, use Confirm. If an approval flow is configured, use Approve. The current screen prevents using the wrong action and shows a warning telling the user which action is expected.

In the current implementation, both actions save the Purchase Order with final user-facing status Approved. The Confirmed stage remains visible in the status path for compatibility/history but Confirm does not persist a separate Confirmed result in this flow.

Process Order – what it is for

Process Order is AkshaERP’s straight-through procure-to-pay orchestration for a Purchase Order. It previews the remaining steps, shows what is already complete, lets the user choose how far to process, requires explicit consent, and then executes the selected chain.

The default recommended target for Purchase Order is Purchase Invoice Post. You do not have to run all the way to invoice; the “Process up to” choices let you stop at an earlier remaining milestone.

Process Order – the six Purchase Order steps

Process Order – step statuses in the drawer

Process Order – blockers and duplicate protection

The preview blocks processing when the PO has no active lines or is Cancelled.

It also checks existing Goods Receipts by PO source reference. If multiple active Goods Receipts already exist for the same PO, Process Order blocks rather than guessing which one should continue.

When one active Goods Receipt or an existing Purchase Invoice already exists, Process Order detects and reuses that document. This makes retry/re-entry idempotent instead of generating duplicates after a partial failure.

Process Order – consent and target selection

The drawer shows the recommended target and the remaining runnable steps. Select the milestone you want to process up to.

Before execution you must select “I confirm the listed documents can be created and posted by this process.” The server also requires this consent flag; it is not only a visual checkbox.

What Process Order creates in Stock Receipt

The auto-created Goods Receipt references the Purchase Order as its source and carries Supplier, Organization, PO Location, PO number, purchase Price List, Currency and Exchange Rate.

Each active PO line becomes a receipt line carrying Item, source PO line, UOM, full ordered quantity, full received quantity, Batch where selected, Unit Price, discount and line amount.

What Process Order creates in Purchase Invoice

The automated Purchase Invoice references the Purchase Order and carries Supplier, Organization, Location, payment terms, Currency/Exchange Rate, Price List/Pricing Source, GST regime and the active PO line commercial/tax values.

Line mapping carries Item, PO line reference, UOM, Quantity, Unit Price, discount, taxable value, tax code/category/rate/amount, Batch and Line Total.

Process Order treats “Create Purchase Invoice” and “Post Purchase Invoice” as separate milestones and ensures the invoice is in a posting state by the final milestone. Do not depend on an editable intermediate Draft invoice when using straight-through Process Order.

Stock Receipt action versus Process Order

Create Purchase Invoice action versus Process Order

Create Purchase Invoice is enabled only when the PO is Received and not Cancelled. It opens the Purchase Invoice screen with the PO reference so AP can review the supplier invoice before posting.

The Purchase Invoice service also independently enforces receipt-before-invoice for a PO-linked invoice. A user cannot bypass the receiving control merely by navigating to the invoice function.

Traceability icon – what it shows

The header also shows counts of Documents, Links, Events and Flows. Where the Traceability Framework knows the route for a document, Open Source / document links open the underlying business document in a new tab.

How Process Order updates Traceability

After the Purchase Order processing chain runs, the server registers/refreshes the Purchase Order trace node and links the Goods Receipt and Purchase Invoice where those documents exist.

This is why Process Order and Traceability work together: Process Order performs the governed chain, while Traceability explains the chain afterward.

Unconfirm – when you can return an Approved PO to Draft

Unconfirm is available only for an Approved Purchase Order. The user may enter an optional reason.

Before unconfirming, the server checks for any active Stock Receipt or Purchase Invoice linked to the PO. If either exists, Unconfirm is blocked.

When allowed, the PO returns to Draft, Approved By/At are cleared, and an “Unconfirmed by …” note is appended to Comments. Leaving Approved also reverses the PO’s approval-stage stock transaction/reference through the Stock service.

Copy Order – what is copied and what is not

Copy Order creates a brand-new editable Draft with a new Purchase Order number and today’s Order Date.

It carries reusable commercial/header details and PO lines, but clears source Requisition, approval/cancellation state, persistent line IDs and batch IDs. Tax is marked for recalculation.

Stock Receipt, Purchase Invoice and journals are not copied.

Cancel Order – controlled reversal of the procurement chain

Cancel Order is available for a saved non-Draft, non-Cancelled PO and requires a Cancellation Reason.

Cancellation is not a simple PO status change. The cancellation service inspects linked Goods Receipts and Purchase Invoices and reverses/cancels the chain inside one controlled transaction.

Actions – complete operating reference

Recommended operating sequence – normal direct purchase

• 1. Create the PO and select Supplier, Location and Payment Terms.
• 2. Set Price Fetch Source, Currency and Price List (when applicable).
• 3. Add Item/Service lines and verify UOM and Quantity.
• 4. Allow automatic pricing to complete or enter an approved manual Unit Price.
• 5. Review discounts, tax and header totals; run Preview Tax.
• 6. Confirm/Approve the PO.
• 7. Receive actual goods through Stock Receipt, especially for partial/rejected receipts.
• 8. After receipt, create/review Purchase Invoice.
• 9. Post the invoice through the normal AP flow.
• 10. Use Traceability to verify the final PO → Receipt → Invoice chain.

Recommended operating sequence – straight-through full receipt

• 1. Prepare and review a complete PO with full quantities, correct UOM, price and tax.
• 2. Open Process Order.
• 3. Review each listed step and confirm there are no blockers or unexpected existing documents.
• 4. Choose the target milestone; for full straight-through processing choose Purchase Invoice Post.
• 5. Confirm that full PO quantities really can be received/invoiced without exception.
• 6. Tick the consent checkbox and run Process Order.
• 7. Open Traceability and verify the linked Goods Receipt and Purchase Invoice.

Operational checks before approval

Common problems and what to check