Create a Notification once an Order Reservation has been received on MIGO_GR

 Let's simplify the technical explanation for setting up notifications when an order reservation is processed in MIGO_GR.

When we complete a transaction in MIGO_GR that involves an "order reservation" (which is like a pre-planned request for materials linked to a specific order), SAP automatically creates a  Material Document.

Our goal is to make SAP "notice" when this specific type of Material Document is created and then automatically send a notification, typically an email.

Here are the main technical ways to do this in SAP:

---

1. SAP Business Workflow (Transaction: SWDD): The "Automated Process Handler"

• Concept: Think of Workflow as SAP's built-in smart engine that automates business processes. You tell it to "listen" for specific events.
• How it Works:
  • Every major item in SAP, like a Material Document, has a Business Object (e.g., BUS2017 for Material Documents).
  • When we save a Material Document in MIGO_GR, this Business Object triggers an event, usually POSTED. This event is the signal Workflow listens for.
  • In SWDD, we design a Workflow process. You configure it to "start" when the BUS2017.POSTED event occurs.
  • Inside the Workflow, we add steps to check the Material Document's details: for example, its Movement Type (like 261 for Goods Issue to an Order) and if it has a Reservation Number.
  • If these conditions are met, the Workflow automatically triggers an action, such as sending an email to specific users or teams, or placing a message in their SAP Inbox (Transaction: SBWP).
• Why it's Good: This is often the preferred method because it's very robust, directly integrated with SAP's event management system, and designed for automating complex business steps.

---

2. Business Add-Ins (BAdIs) / Enhancement Spots: The "Custom Code Insertion Point"

• Concept: SAP provides specific "hooks" or "extension points" within its standard programs where you can insert your own custom programming code (ABAP) without modifying SAP's original code.
• How it Works:
  • When you save a Material Document in MIGO_GR, SAP's program passes through certain pre-defined BAdIs (like MB_DOCUMENT_BADI, which is related to material document processing).
  • You can "implement" one of these BAdIs. This means you write custom ABAP code inside it.
  • This ABAP code then checks the Material Document's details (Movement Type, Reservation Number, etc.).
  • If your conditions are met, your ABAP code uses special SAP functions (like those from class CL_BCS or function module SO_NEW_DOCUMENT_ATT_SEND_API1) to send an email notification.
• Why it's Good: This method gives you very precise control over the logic and exact timing, as your code runs directly within the MIGO_GR transaction's saving process.

---

3. Output Determination (Transaction: NACE): The "Automated Document/Email Generator"

• Concept: This framework is usually used for printing documents (like purchase orders). However, it can also be configured to generate other "outputs," including emails, for Material Documents.
• How it Works:
  • You configure this in Transaction NACE (under Application ME for Inventory Management).
  • You define an "Output Type" (e.g., ZINV for Inventory Notification).
  • You specify the "Transmission Medium" for this Output Type. This can be "Printout," but for notifications, you'd choose "Simple Mail" or a custom program that sends an email.
  • You set up "Conditions" (e.g., Material Document Movement Type is 261, and the document has a Reservation).
  • When a Material Document is posted in MIGO_GR that matches these conditions, the system automatically proposes and then sends (or queues for sending) the defined output (your email).
• Why it's Good: This method is primarily configuration-driven, meaning less direct ABAP coding is needed if the standard mail functions are sufficient for your requirements.

---

What the "Notification" Actually Is:

• Email: The most common and flexible. The email's content can be fully customized to include all necessary details (Material, Quantity, Order Number, Reservation Number, Plant, etc.). These emails are sent through SAP's integrated mail system (configured in SCOT).
• SAP Inbox Message: A message appears directly in the recipient's SAP Business Workplace inbox (Transaction: SBWP).
• SMS / External System Integration: For more advanced needs, the notification could trigger an SMS, or push data to another external system, often requiring SAP integration platforms like SAP PI/PO or SAP CPI.

All these methods leverage SAP's built-in capabilities to detect when a Material Document is created in MIGO_GR and then react by sending a notification. The best choice depends on the specific complexity and flexibility your requirements demand.

Difference between GR Indicator and GR Indicator Firm in SAP MM

 

The GR indicator and the GR indicator "firm" in SAP control whether and how a goods receipt (GR) is expected and processed against a purchase order (PO). Here's a breakdown of their differences:

GR Indicator:

• Purpose: Indicates whether a goods receipt is expected for a PO item.
• Options:
  • Blank: A GR is expected. This is the most common setting. The PO history will show that a GR is still pending.
  • X: No GR is expected. This is used for services or other items where a physical goods receipt isn't relevant. The PO history will not expect a GR.
• Impact: Primarily affects the PO history and reporting. It doesn't prevent a GR from being posted, even if the indicator is set to "X." You can still post a goods receipt if you need to, and in some cases, you must post a GR even with "X" to complete the procure-to-pay cycle if there's an invoice to pay. However, it might trigger warnings if the GR is unexpected based on the indicator.
• Flexibility: More flexible, allowing for adjustments and GR postings even if the initial setting suggests no GR is needed.

GR Indicator - Firm (Also known as "GR Non-Valuated"):

• Purpose: Indicates whether a goods receipt is expected and whether it impacts inventory valuation. It represents a GR that does not update inventory.
• Setting: A checkbox in the PO item details.
• Impact:
  • Checked: A GR is expected, but it will not update inventory quantities or values. This is often used for non-stock materials or when goods are received but not yet owned (e.g., consignment). While the GR is recorded, the system does not post to the stock account or update inventory quantities. This can be particularly useful for third-party or pipeline scenarios. It's also used if the material is only for consumption or is immediately withdrawn.
  • Unchecked: A standard GR is expected, which will update inventory.
• Flexibility: Less flexible. While you can technically still post a standard GR even if the "firm" indicator is set, doing so will likely lead to accounting discrepancies and require manual corrections. Therefore, it's crucial to get this setting right from the start.
• Key Difference: The main difference is the impact on inventory valuation. A regular GR increases inventory value, while a firm GR does not.

In Summary:

Feature	GR Indicator (Blank/X)	GR Indicator - Firm (Checked/Unchecked)
GR Expected	Yes/No	Yes
Inventory Update	Yes (even if 'X')	No/Yes
Primary Impact	PO History/Reporting	Inventory Valuation
Flexibility	More Flexible	Less Flexible

The "firm" GR indicator offers more control over inventory valuation, while the regular GR indicator primarily manages expectations and reporting related to goods receipts. Choosing the correct setting is crucial for accurate inventory management and financial reporting.

How to select 'OK' for all line items in MIGO

 This page is to explains how to select/deselect all line item 'OK' buttons in transaction MIGO.

Overview

When posting a Goods Receipt in transaction MIGO, we may need to know how to select all/deselect 'OK' buttons for all line items.

 

Having multiple line items to be received, we would like to have an option in MIGO screen to select/deselect all line items together.

 

Example:

Go to transaction MIGO.

Select option 'Goods Receipt' for 'Purchase Order'.

Insert a Purchase Order number which contains several line items to be received.

Execute.

Notice that SAP System brings all line items with 'OK' button empty. In case, we would need to mark each 'OK' button manually.

 Root Cause

This is the standard system design for transaction MIGO.

 Options to Overcome this issue

Option 1: Default Values 

We can go thourgh MIGO, clicking on menu Settings > Default Values.

Here, we can activate "Propose the Ok Function in Future".

This way, 'Item OK' will be defaulted in MIGO every time, end-user does not have to mark/activate it during MIGO processing. 

Option 2: Transaction SHD0

We can go through transaction SHD0 and proceed by entering MIGO Transaction Code.

Here, activate 'Item OK' indicator and make it display so end-user will not be able to change it in MIGO.

Option 3: BAdis

We can use BAdi MB_MIGO_BADI - enhancement MBCF0005 to manipulate MIGO subscreens.

Delivery Completed Indicator is automatically removed in SAP MBRL transaction

 Delivery Completed Indicator is automatically removed when navigating through the MBRL transaction

This page is explaining the reason because the delivery completed indicator is automatically removed under certain circumstances.

Example: > PO Item was created with underdelivery = 10,00%

> PO qty (ordered qty): 269 GAL                                                

> GR qty (received qty): 264 GAL                                               

264 GAL is more than 98% of 269 GAL.  

In this case, the reason for removing the delivery completed indicator automatically in MBRL would be because we are defining underdelivery for 10,00% but the difference from the received quantity is less than 2% of the ordered qty.                                                

                                                                                

Note 81853 says that:    

"...If the items are adopted, a check is made whether a goods receipt quantity smaller than/equal to the underdelivery tolerance quantity results from this issue posting. If so, the system automatically cancels the "Delivery completed" indicator..."                                          

........................................................................       

Please also see the solution segment from this note:                           

........................................................................       

"...In order to draw our attention to the fact that the "Delivery completed" indicator is cancelled, the system now generates message 'M7 244' if it is set.                                                            

We can enter the "Delivery completed" indicator again if this message is generated.                                                                  

The indicator is then no longer changed automatically by the system..."        

........................................................................       

The big point here is to keep message 'M7 244' as 'warning'.                 

According to the standard system design the delivery completed indicator will be cleared. We have to set 'M7 244' as 'warning' to alert you and then put the delivery completed indicator manually in MBRL. 

Goods receipt for outbound delivery in MIGO – incorrect items

Issue:

When posting goods receipt with a reference to outbound deliveries in MIGO all outbound deliveries with a reference to the stock transfer order are displayed as separate line items in MIGO.

Reproducing the Issue

1. Create a stock transfer order with confirmation control key
2. Create 2 outbound deliveries with reference to the same STO
3. Post goods issue for the deliveries in VL02N
4. Create corresponding inbound deliveries
5. Post the goods receipt with a reference to one of the outbound deliveries in MIGO

In MIGO 2 lines will be displayed, referring to both outbound delivery values.

Reason:

The system reads the table EKES for the open GR quantity of the STO and considers all entries where GR has not been booked yet, no only the entries related to the specific OBD.

Solution:

Post the GR with VL32N or with MIGO but with reference to the IBD.

If IBD is created the GR should always refer to the IBD.

As an alternative solution we should consider refraining the usage of inbound deliveries in this scenario, so that GR can be posted with a reference to the OBD.

Enable GingerCannot connect to Ginger Check your internet connection
or reload the browserDisable in this text fieldEditEdit in GingerEdit in Ginger×

GR quantity displayed incorrectly in MIGO

 Issue

When we display a material document (goods receipt for purchase order) in MIGO and in the ’Quantity’ tab the GR Quantity is higher than the value in ’Qty in Unit of Entry’.

Reproducing the Issue

1. Display a material document in MIGO (goods receipt for purchase order).
2. Go to tab ’Quantity’.
3. Compare the values in the fields ’Qty in Unit of Entry’ and ’GR Quantity’.
4. The value in field ’GR quantity’ is higher.

Cause

More material documents have a reference to the displayed material document and they are also considered when GR quantity is displayed. The reason is that the GR-Based IV (EKPO-WEBRE) is set for the corresponding PO item.

To check that we can go to SE16 and display the material documents that have the same reference number. Fill the following fields:

• EBELN and EBELP (corresponding purchasing document and document item).
• LFBNR (you can copy this from the material document in MIGO, go to ’Purchase order’ tab and note the number in field ’Reference Document’).

we can check the same in the purchase order history, if you select the view GR/IR Assignment. All material documents that belong to the same reference number are displayed in one block.

Solution

The sum of the GR quantities booked with material documents with the same reference document is always displayed in the ’GR quantity’ field in MIGO.

Enable GingerCannot connect to Ginger Check your internet connection
or reload the browserDisable in this text fieldEditEdit in GingerEdit in Ginger×

No FI Document created during Goods Receipt against PO

Issue

• After Goods Receipt against a Purchase Order, there is no FI Document generated.
• Error "RW011 No subsequent document found in Accounting" while trying to display Accounting Doc from Material Document.
• Goods Receipt with zero value.

Solution

1. 1. Please check if the "GR non-valuated" indicator is checked within the Delivery tab of the Purchase Order.
2. 2. If  the GR is not valuated. Hence, there will be no Accounting Document created during the Goods Receipt posting.

Enable GingerCannot connect to Ginger Check your internet connection
or reload the browserDisable in this text fieldEditEdit in GingerEdit in Ginger×

Settings the Delivery Completed Indicator

Ø  The “delivery completed” indicator specifies whether a purchase order item is regarded as  closed. This means that you do not expect any more goods receipts for this item. The open quantity is zero.

Ø  You can still post goods receipts for any residual quantities, but these will not change the open order quantity.

Ø  If you change the quantity of a delivery after it has been posted, the R/3 System does not cancel the “delivery completed” indicator automatically. It issues a warning message and you have to cancel it manually.

Ø  If an order cancellation or return reduces the delivered quantity to an amount that is below the tolerance level, the R/3 System cancels the “delivery completed” indicator.

Ø  In this case, it issues a warning message to inform you that the “delivery completed” indicator has been reset. If you do not expect any more deliveries, you can then enter the indicator again manually. It will not be changed automatically by the R/3 System thereafter.

SAP Goods Receipts for PO does not contain any items

When you try to post a GR against any PO it says that the PO does not contain any items.

But when you display the PO it shows the items in it.

There have been several reasons which can be attributable to this problem -

1) This PO is subject to release strategy and since the final release was not made, this PO is considered as 'blocked'.

2) You have been using the confirmation control category where in respect of the last confirmation category key, the GR assignment checkbox is flagged. In this particular case, GR is only be posted if the confirmation is not maintained.

3) Early delivery date ie. the GR date is coming earlier than the PO delivery date.

One other nasty thing might have happened (mostly in MIGO):

You have accidently changed your default movement type from 101 to 102 during your last movement.

Difference Between Cancellation and Reversal

Reversal means Purchase Return when the material has reached your company and you want to return it back due to some reason then you can go for reversal.

While doing migo, we can use cancellation and as well as reversal, what is the diference between the two?

The reversal method for both Cancellation and Reversal are the same although the meaning are different.
Movement Type102 in MIGO will reverse the Goods Receipt for PO and the same will happen for Cancellation also......
Movement Type 122, is for Return delivery to Vendor and this won't come under Reversal or Cancellation concept...
In SAP MM, 102 is the reversal mvt. type of 101. Every mvt. type has its reversal counterpart. The are many reasons to
make a reversal of any mvt. type (mostly human mistakes).
Movement Type 161 is used when you make a returns purchase order to a vendor. This is a purchase order with the "returns"
flag marked. By the way, 161 has it reversal mvt. type in 162.
It's true that in both cases material is being removed from the stock but for different reasons and in different business processes.

Create One GR for Multiple PO's

Creation of one GR document for multiple POs can be achieved using the transaction MIGO / MB01, provided all POs belong to one vendor.

In MIGO transaction, Enter the PO's one by one. Once you enter a PO, the line items would get copied and the PO field would become blank. This way, we can enter multiple PO's belonging to a single vendor.