Purchase Orders

Backlog field	Value
Story ID	AP-PUR-004
Epic	Purchase
Story type	Business workflow
Review status	Draft - business analyst and business owner review required
Source evidence	AppsPortal.Apis controller, application command/query handlers, validators, domain entities, and matching MFE workflow where available
Last source review	2026-07-10

User story

As buyers, I want to create, approve, track, and close orders for goods or services so that supplier commitments are controlled before invoicing.

Posting reference: AppsPortal Posting Ledger explains debit/credit construction. Delegation and Interaction Contracts explains module ownership, delegated commands, linked records, commit boundaries, and reversal propagation.

Acceptance criteria

1. Only authorized users can view or execute the feature's actions.
2. Required business data, active dependencies, tenant/branch scope, and current document state are validated.
3. Invalid requests return actionable validation errors without applying a partial change.
4. Search, list, view, print, and export operations use the same authorized business scope.
5. Material create, edit, status, approval, posting, reversal, and integration actions are auditable where applicable.
6. Financial or stock effects are applied atomically and no more than once.

Posting details

1. Purchase Order Post is an approval/commitment operation and creates no GL journal, payable, payment, or stock movement.
2. Validate Draft/allowed state, vendor, lines, positive quantities, dates, currency, approval requirements, and commercial rules.
3. Mark the order Posted/approved and expose remaining quantities for Purchase Invoice fulfillment.
4. Later invoices reduce remaining ordered quantity and may close lines/order when fully fulfilled.
5. Over-invoicing, cancelling fulfilled quantities, or editing locked commercial terms is rejected.

General ledger posting

Condition	Debit	Credit	Result
Purchase Order Post	-	-	No GL, payable, tax, payment, Stock In, or valuation entry.

Other module and document effects

Area	Effect	Conditional/no effect
Purchase Invoice	Exposes approved remaining quantities; later invoices consume and close them.	No invoice is created automatically.
Inventory	No receipt or stock reservation movement from Post.	Stock changes only when an invoice/receipt delegates Stock In.
Vendor/Finance	Commitment only.	No payable, due schedule, or cash movement.

Core acceptance scenarios

1. Given a valid Draft purchase order, when the buyer submits/posts the order, then the commitment becomes available for controlled fulfillment but no GL, payable, or stock movement is created.
2. Given an invoice attempts to exceed remaining ordered quantity, when the operation is attempted, then the over-fulfillment is rejected.
3. Given the same Post request is retried after success, when the source is no longer Draft, then no duplicate journal, stock, balance, payment, or lifecycle effect is created.

Business rules

Required

Draft order, vendor, date, currency/rate, delivery context, and at least one positive item/service line are required.

Optional or conditional

Warehouse, tax, discount, payment term, expected date, notes, and approval are conditional.

Action behavior

Save creates Draft/Submitted work with no stock, payable, or GL effect; Post approves the commitment only.

Blocking rule or downstream effect

Invoice fulfillment updates ordered/received/invoiced/closed quantities and prevents over-invoicing.

Frontend page coverage

The following UI coverage is sourced from the pulled MFE route configuration. A Module-level supporting artifact mapping is evidence of a reachable screen, but requires BA confirmation that it belongs to this story rather than a more specific feature story.

Route/page	Component	Mode	Route permission/guard	Mapping confidence	Source
purchase-order	Lazy-loaded route	List/navigation	Permission: AppPurchasePermissions.VendorOpeningBalance_List; Guards: PolicyAuthGuard	Explicit frontend feature rule	apps/purchase/src/app/remote-entry/purchase-transactions/purchase-transactions.module.ts:39

Observed frontend fields and validation

Component	Control	Observed frontend rule	Component source
-	-	No reactive formControlName controls were found for the routed components; review template-driven/shared child components.	Route sources above

Observed frontend actions

Component	Click action/handler	Business review requirement	Component source
-	-	No direct (click) handler was found; review shared toolbar/table commands and form submission bindings.	Route sources above

Page-specific frontend acceptance criteria

1. purchase-order - List/navigation: Load an authorized paged/searchable list or navigation page; preserve filters/sort/paging and expose only permitted row and bulk actions. Security observed: Permission: AppPurchasePermissions.VendorOpeningBalance_List; Guards: PolicyAuthGuard