This will include the questions related to Procurement, Demand Planner, ASC, and SRM.
Recently active
In simple terms, we create a Purchasre Order Change Order (POCO) when we need to make a change to a particular Purchase Order that we are working with. The standard behaviour, even in apps 10 is that when a POCO exists, the user is always asked to make changes via change orders. If you try to make a change on the PO, then the system will give an error, notifying you that no changes are allowed when a POCO is connected, which is a valid error. A customer who is in apps 8, is concerened about this error and they are of the view that this error should not pop-up and the user should be allowed to change the Delivery address under the misc info tab in the supplier window, even if a POCO exists. This is not possible with the standard functionality. However, I found the bug 120640 which addresses this error which comes up when we try to change the delivery address on the PO when a POCO exists. But, it doesn’t seem to make any sense of resolving the issue. It says, this error occurs only when
How ROUNDDIFF +/- (Clearing Positive/ Negative Remaining Stock Value) transactions are created in inventory transactions history. Much appreciate if you could explain this using a business scenario.
Why does not the "Buyer" visible under authorization tab in Purchase Order window, even though an authorization is being fetched? Moreover, an explanation is required for not receiving any email by the "buyer" regarding the authorization when the “NOTIFY_BUYER_PO_AUTH_COMPLETE” event is enabled.
In App 7.5, there is no way of reporting Intrastat for Non Inventory Parts and No Parts in purchasing (importing) them. How can we fix this?
All purchase requisitions allow only Company Owned and Company Rental Asset ownership types, except when created by a process that supports additional types of ownership (such as from IFS/Project or IFS/Project Delivery). Why is ownership "Customer Owned" not available for Purchase requisition lines when Order Code is ‘1- NORMAL’?
PO Authorization is triggered again for all POs when receiving which are already released, irrespective of the date of which the Auth rule is created. How to set an effective date for PO Authorization rules (APP9)? This make users having to authorize old POs again when they receive them even though the Auth rule is intended to authorize future POs.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.