Purchase Order Release Strategy Not Triggering

Purchasing reports that a high value purchase order went out to the vendor without anyone approving it, or that a manager changed the price on an already-approved order and the system let the change through without asking for re-approval. Sometimes it is the opposite complaint: a buyer says the order is stuck, nobody can find it in their release worklist, and the vendor is chasing confirmation. The business frames it as either a control failure ('how did this go out unapproved') or a process delay ('nobody can release this'). Auditors sometimes raise it first, flagging a purchase order above the approval threshold that has no release history at all. It rarely comes in as a technical ticket initially; it surfaces as a compliance question or a vendor escalation, and only gets routed to the functional team once someone checks the release strategy tab and finds it blank or stale.

Pull purchase orders by document type, purchasing organisation and plant where release strategy is blank but net order value exceeds the lowest configured threshold, then compare each one's characteristic values against the configured combinations to show the gap directly. Separately, pull change documents for released purchase orders where the changed field falls within a value band expected to trigger re-release, alongside their release status history, to show the reset never fired.

If the classification combination is genuinely missing, the fix is configuration: add the combination and assign the correct release strategy in the release procedure customizing, then transport through the landscape; this is not something that can be patched per document. If the problem is a release-relevant field not flagged to trigger a reset, that is also a configuration change to the field selection key, requiring a transport and regression testing against existing open orders, since widening the reset trigger can suddenly put many in-flight POs back into pending release. If custom characteristics are not populated because of a broken user exit or BAdI implementation, this is a development fix owned by the ABAP team feeding the release determination structure, again transport-based. If the strategy is correctly determined but nobody is notified, the fix sits with workflow configuration and agent assignment for the release code, not with the release strategy customizing itself. There is no legitimate data-only fix; any change made directly against a single purchase order (forcing status, re-releasing) addresses that document only and leaves the underlying gap for the next one.

The common workaround is to manually force the release using ME29N, or to nudge the net price by a trivial amount so the system redetermines a strategy and the buyer can push it through, or to delete and recreate the purchase order so it enters the classification again. All of these clear the immediate order but do nothing about the missing combination or the unflagged field, so the same gap swallows the next order with the same value band or the same change pattern, and the audit exposure repeats.

The MM/purchasing functional consultant owns the release strategy configuration, characteristics and classification. Workflow or Basis owns agent determination when a strategy is correctly assigned but no approver is notified. The handover note should carry the PO number, its characteristic values (value, org, plant, material group, account assignment category), current release status, and the strategy the business expected to see triggered.