[SOLVED] VM2 interface shows inhumane order numbers instead of readable order ID

[Bruce Morgan]

I am not sure what to say.  Remember that as a VM user AND as  the back admin in 1.1 the order_id IS the order number.  This is my point.   The fact that the database uses something different is irrelevant.  For the purpose of the user the order number was 2073.  For my purposes as the shop owner the order number was also 2073 as that is how the orders are numbered in the order list in the VM back end.  There is not a single VM user or shop owner who gives a damn about what sort of long and random muber is used as the order_number in the database.

There was no "error" in VM1.1.  Presenting the order_id as the "order number" at the user/shop owner lever was the only sensible thing to do from a usability standpoint.  Otherwise how could you eve keep track of the orders?

You have also missed another key point.  In my migration process from 1.1 to 2.0, all errors were introduced.  The order_id was changed, error #1.  The order_number (which was supposed to retain the old VM1.1 number) did not correlate to EITHER order_id pre-migration or post-migration.  Fail, Fail.  I cannot explain this any more clearly.

[Bruce Morgan]

As indicated in my earlier post, I re-migrated my VM tables when 2.0.4 beta was released.  In answer to your question i did have the "rewrite order numbers" box checked. I also checked "use vm1 order id as VM2 order number" also checked.  Perhaps i should have uncehecked the first.

And to answer the second question, yes I did delete a few orders.  I do not rmemeber exactly ow many but I suspected this might be the reason for the error.

If I went thropugh the process again and unchecked the default box perhaps the order numbers would be retained.  Will try this and report back.

[mordeng]

still not working for me...i updated from 2.0.2 to 2.0.6 and i still haven't the ascend numbers...
tried to migrate with only rewrite but it doesnt work...

[e-trader]

The old order numbers a definitely kept with for example 2.08 using the migration tool. I use "rewrite order numbers" UNCHECKED and "Use the vm1 order id as vm2 order number " CHECKED. See attachment for the result with historical orders. New orders placed do keep the order number sequence, but a hash-code is added to the front. I'm not in favor but it could be workable. Why not actually use that hash in the background processes and not show it to us or the end users? Business owners have no need for a hash-code.

There are still many issues though with using migrated data:

• Currency is not migrated in historical orders. Orders placed in USD become whatever your newly set default currency is. Migrating any data is actually more harmful than not, it would be better to keep an old VM1.1 shop next to the current VM2 shop for all customers to check their old orders. I do not see why it would be required for anybody to work this way though, if only the migration process would be better. Hopefully this will be fixed sometime in the future
• Historical orders have the oldest order at the top, the latest orders at the end. Newly placed orders are placed on top of the old orders.
• All order history entries contain the data of the migrtion instead of their original date
• Thumbnails are missing with JM25 and VM2 although they were there in JM15 with VM2 after upgrade to JM25 they are gone again

Besides using migrated data, VM remains not usable for the moment. The Dutch TAX office requires continues invoice numbers and VM2 creates some kind of hash code for invoice numbers. No idea what the benefits are, but it is not compliant with the law yet.

Every now and then we evaluate the progress of VM2 in our development environment. VM2 has a lot of good stuff in it, so far though it does not meet requirements and a migration if still far away for us.

[attachment cleanup by admin]