Announcements
962
It appears there is a new limit to purchase order revisions in SL2011. When the revisions count (# of records in POReqHdr exceeds 100, users recieve error 17336 "The maximum number of revisions for Purchase Order 123456 has been exceeded. Changes will not be saved"
Is there a work around for this issue? A way to delete old revisions? Setting to change that will increase the limit?
Thank you
Steve Wierenga
*This post is locked for comments
Peter,
One issue that I observed with our users while working on this issue, was a bad habit of using the "Finish" button or "Ctrl-F". They would often use the Finish button even though they did not make a change to the purchase order.
Since the Finish functionality is "Save" and "new', this process saves a revision even though the users did not make any changes. On a large purchase order, it is not difficult to hit 99 revisions when users are misusing the Finish button.
IMHO, this issue is definately a defect. However, a little retraining has gone a long way to alleviating our issue with the 99 PO revision defect/design flaw.
We also make an effort to minimize the number of line items on a purchase order.
Good luck
Steve
I have a client on 2011 SP1. They just called because they have 200 revisions and they got the message. they claim other PO's with 600 from before.
Steve,
Thanks for the update and explanation. I would suggest that you open a support case to address this issue. Please reference Bug ID 22106 specifically. It would be helpful to include the details that you have provided as to why the fix for this bug is not working for you.
Let me know if you have any other questions or concerns.
Jayson,
Sorry for the late reply. I was on vacation for the last two week.
The reason we have so many revisions to a purchase order is due to one specific manufacturer relationship for custom manufacturered material. We create a PO for this manufacturer that is linked to multipe sales orders/line. Typically, there are 100+ line items on the PO and we send them two PO's a day. They then send us updates to the PO with pricing and delivery information as it processes through estimating and production. In order to provide our customers with timely estimates regarding delivery and pricing, we update the purchase order immediately when the data is available. This produces numerous updates to thepurchase order and often, in excess of 100.
Reducing the number of updates would create an issue with our ability to service customer requirements for timely scheduling information. Splitting the purchase orders into smaller PO's/less line items, would create a burden on Purchasing and the process of creating and updating PO's as well as added cost to Purchasing and A/P. Not to mention our Manufacturer would not be happy with this change either.
I have performed some analysis on this process and have found a way to reduce the number of updates. Currenlty, the mfg sends us the data sorted by their internal reference number. Not our PO number. Since the data is entered sequentially, one set of updates will result in multipe updates to the same PO. I have requested a change to their reporting system to sort the data by our PO number. This should eliminate a number of the updates to our PO. However, I cannot say with certainty that this will reduce the number of updates to less than 100.
I am a bit surprised that the fix for this issue was to lock a purchase order when revisions exceed 99. Obviously, the defect was experienced by a company/user who exceeded the 99 limit and found the revisions processing multiple times as 10. Since we don't care about PO revision history, we did not find it as an issue. However, locking a PO when revisions exceed 99 IS an issue and a defect IMHO.
Please let me know if I need to submit a support request to have this defect addressed.
Thank you
Steve Wierenga
Steve,
Thanks for the update and I apologize for the delay in responding.
I can't really speak to why the issue was resolved the way it was but prior to the fix it allowed the duplication of Revision numbers causing Data Integrity Issues. While the fix doesn't allow more than 99 revisions it does prevent bad data from being added to the tables.
Having 100 revisions to a Purchase Order doesn't seem to be a normal situation on the surface. Can you explain the situation that requires this number of revisions on a single Purchase Order? Is this a situation where the PO is modified to increase quantities over and over to continue receiving quantities? If so could this be handled using a Blanket Purchase Order then creating Multiple regular orders from the Blanket?
Let me know how you are using the Purchase Order and maybe we can come up with a better way to handle this in the system. I will wait to hear back from you.
Jayson,
So the fix for more than 100 revisions is to limit it to 99 rather than increase the reqcntr field to 3 digits?
If I close the purchase order and create a new one, how do you suggest we link the two for material processing?
Steve
Steve,
Thanks for posting! This issue was addressed by Bug ID 22106 and corrected in version 2011. In previous versions, once the ReqCntr made it to 99, all revisions made after that used a ReqCntr of 10 representing the first two digits of 100. Since the ReqCntr field is only 2 digits, there is a limit of 99 revisions. The bug fix prevents revision number 10 from being created for multiple revisions.
The only workaround for this would be to close the Purchase Order and create a new one. I hope this helps. Let me know if you have any further questions or concerns.
#1
Community Member
136
#2
Mohamed Amine Mahmoudi
102
Super User 2025 Season 1
#3
REUser
8
Share
Report
All responses (
Answers (
