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
(http://virtuemart.net/documentation/User_Manual/figure/img036.png)
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?
i agree - anyone??
There will be a plugin soon, so that you can define your own settings for customer, order and, invoice number.
Quote from: Milbo on February 02, 2012, 22:16:01 PM
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.
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.
2.03j allows historic order numbers to be kept nicely and generates pretty descent order numbers now *thank you*.
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?
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.
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.
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.
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?
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.
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?
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?
Quote from: Bruce Morgan on April 07, 2012, 23:58:17 PM
In VM1.1, I have an order number (VM back end) #2073
Exactly here is alredy the error
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
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.
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.
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.
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...
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]