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

[e-trader]

VM1.1 had readable order ID like 4653 where VM2 shows unreadable long order numbers like 132_fe92006126bd3dd3d8b025a78932.

From the perspective of business administration, having a number which is readable, something you an sort on as well is.. a big advantage, hence I don't understand the change, it seems like going backwards. If a customer would be phoning or mailing about a order number.. imagine having to state the new number! <impossible>.

VM1 order id format



Don't get me wrong, VM2 is such a great improvement in many ways... am I the only one who has a problem with this?

[ecopure]

i agree - anyone??

[Milbo]

There will be a plugin soon, so that you can define your own settings for customer, order and, invoice number.

[MaHe29]

There will be a plugin soon, so that you can define your own settings for customer, order and, invoice number.

Is there any news about this plugin?
I would like to change the order numbers so they make more sense.

[Milbo]

the 2.0.2 has a serial id in the last chars. So it is already better now. example Orders 60-64
2c48064
efec063
497e062
13fe061
d73c060

corresponding invoice numbers are something like 1202285da062 for the ordernumber 2c48064

first is the date in the format yymmdd then some random chars after that the serial number. This system is atm built in. Plugin will follow within the next month.

[e-trader]

2.03j allows historic order numbers to be kept nicely and generates pretty descent order numbers now *thank you*.

[Bruce Morgan]

That is great news.  I updated yesterday and viewed the historic orders and and huge long order numbers still show.  Is this because the were imported/migrated before you made this change?  My test site is not live and so I cannot test what soert of new number would be generated.  Can you elaborate on what was changed and what I could do to make it work like I want?

[e-trader]

Hi Bruce,

The old numbers are kept or rewritten when you use the migration tool to import the data from 1.1x to the 2.0x format. If you had already done this previously and only installed the new VM 2.03 build, this would not change anything.

I'm not sure what happens when you use the migration tool again while you already did a migration/import of the data previously. You could try that and enable "Use the vm1 order id as vm2 order number" in the migration tool. Otherwise you may want to do to test your migration process again from scratch.

[Bruce Morgan]

Thanks, I will try re-migrating the VM data.  It is encouraging to know that this has been fixed.  After being a little harsh on the development team it is nice to see that some of the user interface issue are being addressed.

[Milbo]

lol no Bruce, in fact we just adjust to people who do not understand that they must change their habits. :-) But we do it,... but with less priority, that is all.

[Bruce Morgan]

Milbo I tested this out today and got some screwy results.  I tried reloading the tables under 2.0.3J  and then did it again after updating to 2.0.4beta.  Results were similar except that I like the newest version better in that it showed the most recent order first (as it should be).  Some other things I noticed:

1.  The migration introduced errors.  Example:  My order number 2073 from my 1.1.19 live site migrated into 2.0.4beta as order number 3f11389f8d02055 with order ID #2053.  I did not check all of them but the error numerical amount seemed to be the same wherever I looked.  I suppose this can be maually corrected but an error free import would be ideal.
2.  The backup form which I created this test site should have order numbers extending up to about #3500 or so and so about one third of my most recent orders are missing.  This must be a migration issue but if i ever migrate live i will want to bring all the orders over.
3.  In migration I requested to keep the old VM 1.1 order numbers and yet the new orders still had a large prefix.  Is this necessary?
4.  It is unclear how new orders would be numbered moving forward..Isi it too much to hope that they would increment by 1?

[Milbo]

I am sorry, I do not understand your post, because I think you mix order_id, with order_number.

What you want is use vm1 order_id as vm2 order_number. Then you have the old order_ids as order_numbers in vm2. In vm2 you never see the order_ids, only the order_numbers. After that, the new order numbers get generated with the vm2 system, which has a hash and an increasing number. It is quite important to have it that way, otherwise the anonymous tracking of orders is not so secure as it can be. It is possible to create a plugin creating own order numbers.

[Bruce Morgan]

I think it is pretty clear.  Try reading it again.  In VM1.1, I have an order number (VM back end) #2073 that changed value whem migrated into VM2.0. In migrating, the order_ID changed from 2073 to 2053. ??  In VM 2.2.4beta the corresponding "order number" as viewed in the VM back end was "3f11389f8d02055", so essentially everything was wrong.  In migrating, the order_id number changed to something different and the migrated order_number  did not correlate to either the original order number (2073) nor the revised (and incorrect order_id) of 2053.  Lose Lose.

Is this clear now?  Could the fact that I have deleted some orders in the past leaving a borken chaain or order_id numbers have anything to do with this?

[Bruce Morgan]

One other thing.  Why is it so important to have a long order number?  Would it not be possibble to simply use the order_id number in the VM back end for reference purposes (including communicating to customers)?  How does this affect security?

[Milbo]

In VM1.1, I have an order number (VM back end) #2073

Exactly here is alredy the error

Code Select Expand


INSERT INTO `j7uy8_vm_orders` (`order_id`, `user_id`, `vendor_id`, `order_number`, `user_info_id`, `order_total`, `order_subtotal`, `order_tax`, `order_tax_details`, `order_shipping`, `order_shipping_tax`, `coupon_discount`, `coupon_code`, `order_discount`, `order_currency`, `order_status`, `cdate`, `mdate`, `ship_method_id`, `customer_note`, `reabo`, `news`, `promo`, `ip_address`) VALUES (49, 82, 1, '82_4c034508dda2de9d2613d625a6721', 'a169f9219bfdee9224ae015b20041972', 59.00000, 59.00000, 0.00, 'a:1:{s:0:"";d:0;}', 0.00, 0.00, 0.00, '', 0.00, 'EUR', 'X', 1249771190, 1313185184, '', '', NULL, NULL, '', '85.218.105.160');


or in short

Code Select Expand


INSERT INTO `j7uy8_vm_orders` (`order_id`, `user_id`, `vendor_id`, `order_number`, `user_info_id`) VALUES (49, 82, 1, '82_4c034508dda2de9d2613d625a6721', 'a169f9219bfdee9224ae015b20041972');

You can see here that the order_id is in this case 49, but the order_number is 82_4c034508dda2de9d2613d625a6721
This is a vm1 table ! So your order_number in vm1 is NOT 2073, that is your order_id.