No Goods Receipt Possible for Purchase Order (M7022) -SAP MM Solution
Example message: "No goods receipt possible for purchase order 4500022489 00029" -the exact PO number and line item in your own error will differ, but the fix below is identical.
This error usually appears during a goods receipt (GR) using MIGO, and it typically means there's a configuration or data issue preventing the GR for the given PO line item. This guide covers the exact fix using ME22N, then goes deeper into what confirmation control and the Goods Receipt indicator actually control, how to read PO History correctly, a real business scenario, and a full troubleshooting checklist.
✅ Understand the Issue
- The GR has already been posted for this item.
- The PO line is not flagged for GR.
- The line item is marked as deleted or blocked.
Reasons for the Error
- Ensure the "Confirmation" tab is correct.
- Ensure the "Goods Receipt" flag is checked for the line item.
- Ensure "Delivery Completed" is removed if wrongly set.
🔧 Follow These Steps
Solution 1 -Tcode: ME22N
Select this PO, go to the Confirmations tab, and check the setting -clear it (leave blank) if a confirmation control is incorrectly blocking the goods receipt.
Solution 2 -Tcode: ME22N
Go to the Item Details → Delivery tab and make sure the Goods Receipt checkbox is ticked. If it was wrongly unticked, tick it to allow further GR -and if "Delivery Completed" was wrongly set, remove that flag too.
Then check the PO History tab to verify whether the full ordered quantity has already been received.
Save, then retry the goods receipt in MIGO.
🔍 What Confirmation Control Actually Does
Confirmation control is a purchase order feature that defines an expected sequence of vendor confirmations for a line item -for example, an order acknowledgment, a shipping notification, or an inbound delivery notification -before or alongside the goods receipt. It's assigned through a confirmation control key on the item's Confirmations tab, and that key determines which confirmation categories are expected and, critically, whether a goods receipt is even permitted before certain confirmations have been recorded.
If a confirmation control key was assigned to a PO line by mistake -perhaps copied from a template PO that genuinely needed vendor shipping notifications, applied to a line that doesn't -MIGO can correctly refuse the goods receipt because, from the system's perspective, an expected prerequisite confirmation simply hasn't happened yet. Clearing the confirmation control setting (or correcting it to a key that doesn't require a prerequisite confirmation) is exactly what Solution 1 in this guide addresses.
📋 The Goods Receipt Indicator and Delivery Completed Flag
Separately from confirmation control, every PO line item carries its own Goods Receipt indicator on the Delivery tab, which is a more fundamental on/off switch: if it's unticked, no goods receipt is possible against that line at all, regardless of open quantity or confirmation status. This flag is typically set automatically based on the item category and account assignment category when the PO is created, but it can be manually changed, and an incorrect manual change (or a PO copied from a template with a different item category) is a common cause of this specific error.
The Delivery Completed indicator works differently: rather than blocking GR outright, it tells SAP that the line item should be treated as fully received even if the ordered quantity technically hasn't been reached -commonly set automatically when a final partial delivery arrives under quantity tolerance, or set manually by a buyer closing out a line they don't expect further deliveries against. If this flag gets set prematurely or in error, any further legitimate goods receipt against that line will be blocked until someone unticks it.
📊 Reading the PO History Tab Correctly
The PO History tab on a purchase order line lists every material document (goods receipt), invoice document, and related transaction posted against that specific line, along with quantities and dates. Before assuming a configuration setting is the cause of this error, checking PO History is often the fastest diagnostic step: if the received quantity already equals or exceeds the ordered quantity (accounting for any over-delivery tolerance configured on the line), the "no goods receipt possible" message is actually correct behavior, not a bug -there's genuinely nothing left to receive against that line.
This distinction matters because the fix is completely different depending on which scenario you're in. If PO history shows the line is genuinely complete, the real fix might be creating a new PO line, a subsequent delivery on a new PO, or a return delivery if goods were over-received -not touching confirmation control or the GR indicator at all. Only when PO history shows meaningful open quantity remaining does it make sense to look at confirmation control, the GR flag, or the Delivery Completed indicator as the actual blocker.
🛠️ How Item Category Influences the Default GR Setting
Every PO line item is assigned an item category (blank/standard, consignment, subcontracting, third-party, and others), and this choice influences several default settings behind the scenes, including whether goods receipt is expected at all. A standard item category line normally defaults to Goods Receipt ticked, since a physical delivery is expected. A third-party item category, by contrast, is typically configured so goods receipt is not relevant at all, since the vendor ships directly to the customer and your organization never physically receives the stock -attempting a goods receipt against a genuinely third-party line would correctly fail, not because of a data error, but because the process itself doesn't involve a warehouse receipt.
This is worth checking early in your troubleshooting if the PO in question uses anything other than the standard item category, since "no goods receipt possible" can sometimes be entirely correct process behavior for that specific item category, and the real fix is confirming with procurement whether the item category was chosen correctly for how this particular purchase is actually being fulfilled.
✅ Prevention Checklist for Procurement Teams
- When copying a PO from a template, review confirmation control settings against the new vendor's actual process rather than assuming they still apply.
- Train buyers to check PO History before manually setting or unsetting Delivery Completed, to avoid closing a line prematurely.
- Confirm item category is appropriate for how the purchase will actually be fulfilled (standard, third-party, subcontracting) at PO creation time.
- Periodically review confirmation control key assignments (OMGZ) against actual vendor communication practices, updating them as vendor relationships change.
- Document common causes of M7022 in a quick-reference guide for warehouse staff, so they can self-diagnose PO History and GR flag issues before escalating.
📱 This Error in SAP S/4HANA
Confirmation control, the Goods Receipt indicator, and Delivery Completed all work the same way in SAP S/4HANA as in ECC, since these are core Materials Management purchase order fields rather than something tied to the Universal Journal. What changes in S/4HANA is the interface: the Fiori app "Manage Purchase Orders" exposes the same Delivery, Confirmations, and History information through a modern, web-based screen, letting buyers review and correct these settings without opening the classic ME22N transaction, while ME22N itself remains fully supported and is still what most experienced MM buyers use for its complete field visibility.
Because S/4HANA updates PO History in real time through the Universal Journal-linked data model, a goods receipt posted moments ago will always be immediately reflected when checking PO History, removing any ambiguity about whether a "no GR possible" result reflects stale data versus a genuinely completed line.
📑 Similar-Looking SAP Purchase Order / Goods Receipt Errors
| Error | Root Cause | Typical Fix |
|---|---|---|
| No goods receipt possible for purchase order (M7022) | GR indicator, confirmation control, Delivery Completed, or a genuinely fully-received line | Check PO History first, then ME22N's Delivery and Confirmations tabs |
| Purchase Order does not contain item for a stock transfer | The PO's item category doesn't match a stock transfer scenario expected by the transaction | Confirm the PO type and item category match the intended stock transfer process |
| Deficit of BA Unrestricted-use / Restr.-use (M7021) | Insufficient stock in the specific status a movement expects | Check MMBE by batch/status before creating stock or transferring |
| Account determination for entry ... not possible | Missing or incomplete OBYC account determination for the movement's transaction/event key | Configure the missing account assignment in OBYC |
M7022 and M7021 share the same message number prefix family but address entirely different problems -M7021 is about stock quantity and status, while M7022 is about whether a goods receipt is even permitted against a specific PO line in the first place. Recognizing which one you're actually facing from the exact wording of the message saves time before diving into troubleshooting.
💼 Real-World Scenario: A Template Copy Carries Over the Wrong Setting
Pooja Mishra, a procurement executive, created a new purchase order by copying an existing PO as a template to save time, since the vendor and material details were largely the same. When the warehouse team tried to post a goods receipt against the new PO in MIGO, they hit this exact error. Pooja opened the PO in ME22N and initially assumed it was a straightforward GR flag issue, but the Delivery tab showed Goods Receipt correctly ticked.
Checking the Confirmations tab revealed the actual cause: the template PO had a confirmation control key requiring an inbound delivery confirmation before goods receipt -appropriate for that vendor's usual advance shipping notice process -but the new vendor on this copied PO didn't send inbound delivery notifications at all, so that prerequisite confirmation would never arrive. Pooja corrected the confirmation control key to one appropriate for this vendor's actual process, saved the PO, and the warehouse team was able to post the goods receipt immediately afterward. This is a very common real-world cause: copying an existing PO as a starting point is efficient, but confirmation control settings tied to a specific vendor's process don't always make sense for the new PO's actual vendor.
❗ Common Mistakes When Troubleshooting M7022
- Changing the GR indicator or confirmation control before checking PO History, potentially masking a genuinely completed line instead of addressing the real issue.
- Copying a PO from a template without reviewing whether confirmation control settings still make sense for the new vendor or scenario.
- Assuming Delivery Completed can only be set automatically, and not checking whether it was set manually by mistake.
- Not checking whether the line item itself has been deleted or blocked at the item level, which is a separate condition from GR flag or confirmation control.
- Making the fix in ME22N but forgetting to save before retrying the goods receipt in MIGO.
📈 Troubleshooting Decision Tree
- Open the PO in ME22N and check PO History first. Is the line already fully received? If so, this error is expected behavior -no further GR is needed on this line.
- Is the item marked as deleted or blocked? Check the item's status indicators; a deleted/blocked line cannot receive goods regardless of other settings.
- Is the Goods Receipt checkbox ticked on the Delivery tab? If not, and GR should be expected, tick it.
- Is Delivery Completed ticked when it shouldn't be? Untick it if the line genuinely still has open quantity to receive.
- Does the Confirmations tab show a confirmation control key requiring a prerequisite confirmation that hasn't happened? Correct or clear the confirmation control key if it doesn't match the vendor's actual process.
📋 Related SAP Transactions
| Transaction | Purpose |
|---|---|
| ME22N | Change a purchase order, including confirmation control, GR indicator, and Delivery Completed flag. |
| ME23N | Display a purchase order and its PO History without editing. |
| MIGO | Post the goods receipt itself once the underlying PO issue is corrected. |
| ME2M / ME2N | List purchase orders by material or vendor, useful for finding related open POs. |
| MB51 | Material document list, useful to cross-check what has already been posted against a PO. |
| OMGZ | Configure confirmation control keys and their required confirmation categories. |
🎓 Interview-Style Questions and Answers
Q: What is the first thing you should check when a goods receipt is blocked for a PO line item?
Check the PO History tab first, to confirm whether the line is genuinely still open or has already been fully received -this determines whether you're troubleshooting a configuration issue or dealing with expected, correct behavior.
Q: What's the difference between the Goods Receipt indicator and confirmation control on a PO line?
The Goods Receipt indicator is a simple on/off switch controlling whether GR is possible at all for that line. Confirmation control defines a sequence of expected vendor confirmations, and depending on the confirmation category configuration, can conditionally block GR until a specific prerequisite confirmation is recorded.
Q: Why might copying an existing PO as a template introduce this error on the new PO?
Because confirmation control keys, GR indicators, and other settings tied to the original PO's specific vendor or process are copied along with it, and may not be appropriate for the new PO's actual vendor or scenario.
📚 Quick Glossary of Terms Used in This Guide
- Confirmation control: A PO line setting defining a sequence of expected vendor confirmations, which can conditionally block goods receipt.
- Goods Receipt indicator: A checkbox on the PO line's Delivery tab controlling whether a goods receipt is possible for that line at all.
- Delivery Completed: A flag marking a PO line as fully received, blocking further goods receipts even if the ordered quantity technically remains open.
- PO History: The tab on a purchase order line listing every goods receipt and invoice document posted against it.
- Item category: A PO line setting that, among other things, influences the default Goods Receipt indicator when the line is created.
🎯 Conclusion
M7022 is SAP correctly stopping a goods receipt because something about the specific PO line -its confirmation control, its GR indicator, its Delivery Completed status, or its actual remaining open quantity -doesn't currently support one. By checking PO History first to rule out a genuinely completed line, then working through confirmation control and the Delivery tab settings in ME22N, you can resolve this error confidently and understand exactly why it happened rather than just making it disappear. Keep the troubleshooting decision tree above bookmarked for the next time a goods receipt unexpectedly won't post.