The reported scenario has been analyzed in detail, and the observed behavior is working as designed.
The package part functionality introduced for RMA in IFS Cloud 25R2 is designed to support the return of a package part as one complete unit. Returning only selected components of a package represents a different business requirement that is not supported by the current functionality. Therefore, this requirement is considered an enhancement request rather than a defect.
Scope of the Current Functionality
From IFS Cloud 25R2, an RMA line can be created directly for a package part instead of creating separate RMA lines for each component. The purpose of this functionality is to ensure that the credit invoice represents the package part as a single item, consistent with how it was originally sold and invoiced through the customer order.
The functionality operates as follows:
- The package part line is the controlling line. Actions such as release, deny, or cancel are performed at the package-part level. Component lines are generated automatically based on the package structure and follow the package line.
- Component lines are used for receiving purposes. They allow the physical components to be received into inventory, inspected, or scrapped. They are not intended to be maintained independently, which is why actions such as cancelling an individual component line are not available.
- Completion is controlled at package level. The package line reaches Received or Returns Completed only after all associated components have been processed. The returned package quantity is based on the number of complete packages received.
- Pricing and crediting are handled at package level. The RMA total and credit invoice are calculated using the package part quantity and price from the customer order. Individual components do not have separate credit values on the RMA.
Why the Reported Scenario Is Outside the Current Design
In the reported scenario, only two out of three components of the package are returned. Supporting this scenario would require changes to the existing functional design in several areas.
1.Cancelling an individual component:
Component lines are intentionally not maintained independently. Allowing an individual component to be cancelled would mean that the RMA no longer represents the return of a complete package and would require changes to the existing package completion logic.
2.Recalculating the credit amount:
The package is sold using a package-level sales price. There is no separately defined sales price for each component within the RMA. Therefore, reducing the credit based on a missing component would require additional business rules defining how the package price should be distributed between components. Any such approach could also affect discounts, taxes, rounding, sales statistics, and credit invoicing.
3.Credit invoice presentation:
A partial package return would also require additional rules to determine how the transaction should be represented on the credit invoice, for example as a package with an adjusted value or through another representation of the returned components.
4.Scrap functionality:
The scrap option is intended for goods that have been physically received but need to be scrapped, such as damaged goods. Scrapping a received component does not alter the commercial value of the package return and therefore does not reduce the RMA total or credit amount. This is expected behavior.
Conclusion
The current functionality is designed around the principle that a package part is returned and credited as a complete package. Supporting the return and proportional crediting of only selected components would require new functional rules across RMA processing, receiving, pricing, and credit invoicing.
As this introduces behavior that is outside the existing functional scope rather than correcting behavior that deviates from the current design, the requirement should be handled as an enhancement request.
Regards,
Nikila Dissanayake
