Restore ability to enter 20 character PO Numbers

Posted by James B. on July 19, 2006, 10:02 pm

Please log in for more thread options

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.

http://www.microsoft.com/Businesssolutions/Community/NewsGroups/dgbrowser/en-us/default.mspx?mid=bde4ecdd-97e0-4d48-9a02-97d72aefc4ee&dg=microsoft.public.pos

Posted by Afshin Alikhani on July 26, 2006, 11:00 pm

Please log in for more thread options

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.

Afshin Alikhani - [ afshin@retailrealm.co.uk ]
CEO - Retail Realm
= = = = = =

> 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.

> http://www.microsoft.com/Businesssolutions/Community/NewsGroups/dgbrowser/en-us/default.mspx?mid=bde4ecdd-97e0-4d48-9a02-97d72aefc4ee&dg=microsoft.public.pos

Posted by James B. on July 30, 2006, 9:07 pm

Please log in for more thread options

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.

"Afshin Alikhani" wrote:

> 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.

> Afshin Alikhani - [ afshin@retailrealm.co.uk ]

> CEO - Retail Realm

> = = = = = =

> > 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.

> >

> > http://www.microsoft.com/Businesssolutions/Community/NewsGroups/dgbrowser/en-us/default.mspx?mid=bde4ecdd-97e0-4d48-9a02-97d72aefc4ee&dg=microsoft.public.pos

Posted by Afshin Alikhani on August 1, 2006, 1:21 am

Please log in for more thread options

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.

Afshin Alikhani - [ afshin@retailrealm.co.uk ]
CEO - Retail Realm
= = = = = = =

> 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.

> "Afshin Alikhani" wrote:

>> 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.

>> Afshin Alikhani - [ afshin@retailrealm.co.uk ]

>> CEO - Retail Realm

>> = = = = = =

>> > 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.

>> >

>> > http://www.microsoft.com/Businesssolutions/Community/NewsGroups/dgbrowser/en-us/default.mspx?mid=bde4ecdd-97e0-4d48-9a02-97d72aefc4ee&dg=microsoft.public.pos