Restore ability to enter 20 character PO Numbers

Jul 20, 2006 3 Replies

With the 1.3R release, RMS will not allow PO Numbers longer than 14 characters. Before the 1.3R release, RMS allowed PO Numbers up to 20 characters.



After installing the 1.3R release I reported this defect. The support team responded that this change was by design. They claimed that the change was made to work around a defect - "we had a bug with inter-store inventory transfers erroring out when the PO number is greater than 14 characters".



This type of quick and easy fix (crippling the UI to work around a defect) is just plain wrong for at least a couple of reasons.


1) Customers (like me) who have been using the software for a few years may have evolved business systems that rely on the original capabilities of the software as we bought it. It is not appropriate to take away functionality we have already paid for, and evolved our business around, because you want to save on development costs in fixing defects properly.


2) Microsoft encourages the development of customizations to RMS. With this in mind, it is bad practice to have a field in the database of type nvarchar(20) when populating that field with 20 characters will cause the software to malfunction. You guys need to do a proper fix on the inter-store transfer defect, don't just cripple the UI and call it fixed. Customization developers are going to continue tripping over this defect.



I previously worked at Microsoft in both development and test. I remember all those company wide emails from Balmer urging us to "delight the customer". Well guys, I'm now a customer and I'm not delighted. Let's spend the resources and get this thing fixed properly.


---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If you do not see the button, follow this link to open the suggestion in the Microsoft Web-based Newsreader and then click "I Agree" in the message pane.



formatting link


If you do not have an HQ you are quite right. With HQ what was happenning was that at HQ yhe transfer would add a 6 bit prefix of store ID and thus blowing the transfer id to 26 which then caused the HQ Transfers not to work. So I am glad this BUG is taken care of. But rather than using the Transfer Number as a 14+ field why not use the Title portion which allows you a large entry string A/N.

Thank you for your suggestion Afshin.

We like to append a delimiter and invoice number onto the PONumber when closing Purchase Orders because this is a handy way we have found to get the Invoice numbers into QuickBooks from RMS (the PONumbers flow into the "Ref. Number" column in QB when the bills are created from closed POs).

From your description of the problem, it is hard for me to understand why the defect couldn't have been fixed by increasing the length of the database column (and, if need be, any data structures used in the transfer) to accommodate the extra six characters of StoreID. I doubt that the code for this product has the developers so boxed in that crippling the UI was the only fix available to them.

"Afsh> If you do not have an HQ you are quite right. With HQ what was happenning

I agree but I think what MS did was a quick fix and they did not want to do a structural change. I guess we will have to wait for version 2 and 3 to start seeing real improvements in HQ.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required