Skip to main content
Solved

Blocked Customer Order Demand Not Release for Material Planning for Purch Order Trans Supply Code

  • October 13, 2026
  • 2 replies
  • 23 views

Lakshan Thiranagama
Hero (Former Employee)
Forum|alt.badge.img+9

Hi,

When a Customer Order (CO) header is blocked and the CO line inventory part is supplied through Purchase Order Transit (Purch Order Trans) from an external supplier, the demand is not considered in Inventory Part Availability Planning, (Not in MRP) even when Release for Material Planning is enabled.

Is this the intended behavior in IFS?

We have observed that the same blocked customer order demand is considered by planning when the supply code is set to Inventory Order, but not when the supply code is Purch Order Trans. Could you please clarify whether this is expected system behavior? 

Note: Customer Order block reason is having Exclude from Mtrl Planning as False in all above scenarios.

Thanks!

Best answer by Jane Perry

Hi ​@Lakshan Thiranagama  I tested in a CORE 24R2 environment.

 

A customer order was created with 1 line for Supply Code PurchOrderTrans and another line for Supply Code InventOrder.  The order is still in the ‘Planned’ status.

 

Both lines show ‘Yes’ for Release for Mtrl Planning.

 

IPAP for Part TEST.WWW (PurchOrderTrans) - Customer Order P14516 is not showing.

 

IPAP for Part 58-591 (InventOrder) - Customer Order P14516 is showing.

 

Release the Customer Order.  The order is Blocked.  Release for Mtrl Planing still shows ‘Yes’.

 

Release the order from Blocked to Released.  Release for Mtrl Planing still shows ‘Yes’.

 

Now that the customer order has been released, you see the Demand and Supply for Customer Order P14516 for the part with Supply Code PurchOrderTrans.

 

If this is the same results you’re seeing and if you don’t feel this is the correct results, please create a support case and reference this community post and then we can further investigate this. 

 

Please advise if you have any questions.  Thanks!  Jane

View original

2 replies

Forum|alt.badge.img+10
  • Hero (Employee)
  • Answer
  • October 13, 2026

Hi ​@Lakshan Thiranagama  I tested in a CORE 24R2 environment.

 

A customer order was created with 1 line for Supply Code PurchOrderTrans and another line for Supply Code InventOrder.  The order is still in the ‘Planned’ status.

 

Both lines show ‘Yes’ for Release for Mtrl Planning.

 

IPAP for Part TEST.WWW (PurchOrderTrans) - Customer Order P14516 is not showing.

 

IPAP for Part 58-591 (InventOrder) - Customer Order P14516 is showing.

 

Release the Customer Order.  The order is Blocked.  Release for Mtrl Planing still shows ‘Yes’.

 

Release the order from Blocked to Released.  Release for Mtrl Planing still shows ‘Yes’.

 

Now that the customer order has been released, you see the Demand and Supply for Customer Order P14516 for the part with Supply Code PurchOrderTrans.

 

If this is the same results you’re seeing and if you don’t feel this is the correct results, please create a support case and reference this community post and then we can further investigate this. 

 

Please advise if you have any questions.  Thanks!  Jane


Lakshan Thiranagama
Hero (Former Employee)
Forum|alt.badge.img+9

Thanks, Jane.

Yes, I am experiencing the same behavior in 25R2. The functionality is understandable in this scenario because the supply is fulfilled directly by an external supplier to the customer. Therefore, when the Customer Order is blocked, it makes sense to prevent Purchase Requisition generation, as the customer is not eligible for further processing until the credit-block is cleared.

However, the same logic does not appear to be applied consistently to internal supply scenarios. While I believe the current behavior for external supplies has been intentionally designed this way, I do not think it is the ideal implementation. In my view, this should instead be controlled through the “Release for Material Planning” flag on the Customer Order line. When supply generation needs to be prevented, the system should automatically set this flag to False and make it non-editable until the blocking condition is resolved.

Ultimately, it is up to IFS R&D to determine the intended behavior and update the documentation accordingly. :-)

Thanks again.
Lakshan