Purchase orders: approvals, changes and verifiable receiving

What exactly should be approved?

An order needs a reference and revision that reconstruct what the approver saw. Preserve requester, supplier, products, units, quantities and relevant conditions. If someone changes those fields later, history should explain the change and whether authorization remains valid. A green status without a revision cannot answer whether one hundred pieces were approved or the one hundred twenty now displayed. The decision should remain understandable after catalog data changes.

Business Central documents approval users, substitutes and configurable limits in a purchasing workflow. Its example moves from pending request to release after approval. Not every conceivable change is a supported default event; verify the actual workflow. Purchase approval reference. Write your company’s rules before confusing an available feature with a configured policy.

Who requests, reviews and releases?

Decide when requester and approver should be separate. A substitute needs explicit scope and validity rather than logging in through another person’s account. Classify sensitive changes: supplier, quantity, material, destination, date or condition. A descriptive note may follow another rule, but that exception also needs agreement. Test the same control through an import or integration if those paths can modify purchases. Keep the responsible person visible for every decision.

Worked example: revision one does not authorize revision two

After v2 is released, accepting fifty leaves seventy outstanding against its one hundred twenty under the agreed acceptance-quantity rule. The approval table does not itself record that arrival. A message prepared for P2 also does not establish receipt or agreement: preserve sent-document status and response separately. This exercise reviews records and sends no supplier communications. Use independent evidence for each stage rather than a single overall “done” label.

What if an executed order changes?

If receipts or material reservations already exist, do not replace the earlier order as though it never happened. Identify the changed portion, what has been executed and which outstanding quantity is affected. A reduction should not delete a receipt; an increase needs appropriate authorization. If the supplier substituted a material, retain the proposal until the responsible person determines acceptability. Operational approval alone does not decide technical requirements or commercial treatment.

Odoo publishes Purchase linked with inventory and supplier documents. Purchase features. That connection relates processes, but you must demonstrate which action creates a movement in the actual configuration. Partial receipts test arrival and acceptance; material revisions help when the change affects production.

Which tests prevent decorative approval?

• Normal: the approver sees the complete revision and the decision retains contents, time and identity.
• Exception: changing OC-A supplier or quantity requires the agreed review; an earlier authorization cannot silently apply.
• Retry: repeating L02 preserves one release and allows its result to be queried after a lost response.
• Permissions: a requester without approval authority cannot release through a URL, import or integration.
• Delegation: the authorized substitute uses their own identity; expired or out-of-scope delegation is rejected.

How do you prepare a workflow consultation?

Complete the purchase approval worksheet for an order that changed before receipt. Bring both revisions and who made each decision. ERP or custom software helps choose an approach; the scope of manufacturing software should describe these controls and exceptions without assuming every available approval feature represents your entire process.