Supplier for Purchase Part/Description updates not propagating to PO
We are recently moved to Cloud from Apps9 and have an issue where if we make a change to a Supplier Part or Description on a Supplier for Purchase Part record, these changes are not reflected in the PO lines of any open POs we have for said part. New PO lines added after the change, pick up the correct/updated part/description
Does anyone know if this is ‘to be expected’, a bug, a workflow/process we’re missing, a new action required in Cloud vs Apps9?
Any information gratefully received.
Thanks!
Linda
Page 1 / 1
Hi @PRODQ,
What’s the current IFS Cloud version and the service update that you are using?
Regards,
Nikila Dissanayake
Hi @PRODQ,
What’s the current IFS Cloud version and the service update that you are using?
Regards,
Nikila Dissanayake
We are 23.1.10.
Linda
Hi @PRODQ,
I have reviewed the behavior in IFS Cloud 23R1 and the latest 24R1 release, and I observed the same issue across both versions. Specifically, once the PO line is saved, any changes made to the supplier’s purchase part description in the corresponding window are not reflected.
Given this consistent behavior across versions, it seems that this may be more of an enhancement opportunity rather than a bug in the system.
Regards,
Nikila Dissanayake
Hi @PRODQ,
I have reviewed the behavior in IFS Cloud 23R1 and the latest 24R1 release, and I observed the same issue across both versions. Specifically, once the PO line is saved, any changes made to the supplier’s purchase part description in the corresponding window are not reflected.
Given this consistent behavior across versions, it seems that this may be more of an enhancement opportunity rather than a bug in the system.
Regards,
Nikila Dissanayake
Thanks, @Nikila Dis . Sadly this comes under the heading of yet another “it worked fine in Apps9, why has it changed in Cloud”. I’ll raise a Support case and see where I get to.
Linda
Hi @PRODQ
Yes, Please raise a ticket.
Regards,
Nikila Dissanayake
From RND I can confirm that this is the expected behavior considering changes done during the Apps 10 project, where Supplier´s Part No and Supplier´s Part Description are now saved on the PO line, which was not the case earlier. There is a detailed explanation to be found in the LCS solution 287656 as follows:
It can be confirmed that there is a difference between Apps 8 and Apps 10 since design changes were done during the Apps 10 project to support a number of uses cases where it is necessary that the Supplier´s Part No is saved on the PO line. In previous releases this was not the case, which is why the system behaved as you describe where an update in Supplier for Purchase Part would always be reflected in the PO line. But if you study the solution 264840, this describes a negative effect of the old behaviour where we could never keep historical data. But the main reason for the design changes was to support functionality where the Supplier´s Part No is received from the supplier through some kind of integration or message, and that this information needs to be transferred to the PO line and consequently saved there. You can also see the effect if you perform the Confirm PO or PO Line with Differences, that it is possible to enter the Supplier´s Part No and Description there, which was not possible in previous releases. So this is not a question of contradictory between the releases. The design is different because of deliberate design decisions done during the Apps 10 project. Since the Part No and description are now saved on the PO line, the behavior that a change in Supplier for Purchase Part would automatically be reflected in the PO line no longer exists, since we cannot have both. In the Supply Chain News presentation for Apps 10 that you can find in sharepoint under Release Documents and Links, there is information mentioned in slides 330-332 about the new functionality.
From RND I can confirm that this is the expected behavior considering changes done during the Apps 10 project, where Supplier´s Part No and Supplier´s Part Description are now saved on the PO line, which was not the case earlier. There is a detailed explanation to be found in the LCS solution 287656 as follows:
It can be confirmed that there is a difference between Apps 8 and Apps 10 since design changes were done during the Apps 10 project to support a number of uses cases where it is necessary that the Supplier´s Part No is saved on the PO line. In previous releases this was not the case, which is why the system behaved as you describe where an update in Supplier for Purchase Part would always be reflected in the PO line. But if you study the solution 264840, this describes a negative effect of the old behaviour where we could never keep historical data. But the main reason for the design changes was to support functionality where the Supplier´s Part No is received from the supplier through some kind of integration or message, and that this information needs to be transferred to the PO line and consequently saved there. You can also see the effect if you perform the Confirm PO or PO Line with Differences, that it is possible to enter the Supplier´s Part No and Description there, which was not possible in previous releases. So this is not a question of contradictory between the releases. The design is different because of deliberate design decisions done during the Apps 10 project. Since the Part No and description are now saved on the PO line, the behavior that a change in Supplier for Purchase Part would automatically be reflected in the PO line no longer exists, since we cannot have both. In the Supply Chain News presentation for Apps 10 that you can find in sharepoint under Release Documents and Links, there is information mentioned in slides 330-332 about the new functionality.
Thanks for the update. We went direct from Apps9 to Cloud so weren’t aware of the change.
However, operationally, this is a retrograde step as we will now be sending Purchase Orders to suppliers quoting their wrong Part number or Description.
I’ve raised a case - CS0315347 - to pursue a change, Eva.
