Upgrade tool does not appear to migrate ORDER_CURRENCY [unsolved]

[e-trader]

Hey there guys,

Upgrading from 1.17b to 2.0.3 RC3  the ORDER_CURRENCY in the DB is not migrated when using the migration tool. The new value is always NIL instead of the actual currency used. The result is that the order history shows all orders as being done in the shop currency (incorrect).

Also, is there any reason the original order numbers can not be kept?

If this was reported before.. I did not find it sorry. Thanks guys.

[Milbo]

okey, I found the problem with the currency, vm1 is using chars and we changed now the db layout using int, so we didnt notice the error before. But order_number should be the same as before. Dont flip that with the order_id, which is used in vm2 completly internally and is used only for debugging or simular.

[e-trader]

OMG!! I am very relieved you found it so quickly .

About the order numbers. I think the back-end is showing the VM2 ORDER_NUMBER field instead of VM2 VIRTUEMART_ORDER_ID?

In VM1 order_id 39 is order_number  85_a85239fbd635390c6bf84efd85b90. After migration in VM2 it becomes VIRTUEMART_ORDER_ID 18. Is the intention that the actual numer is supposed to remain the same? I do have some order numbers missing in VM1 (deleted orders) perhaps that is a reason why the order numbering in VM2 after migration is skew? During migration I get a few hundred of these messages: order_number was not unique in table #__virtuemart_orders, added random number: <number>. After migration I have about 5000 orders instead of about 4500 before. Would they be really duplicate orders and then would VM1 order_id or order_number be duplicate or both?

[Milbo]

think the back-end is showing the VM2 ORDER_NUMBER field instead of VM2 VIRTUEMART_ORDER_ID?

It was never right that a normal user (storeadmin) can see and use the order_id, because that is the internal order_id. It is like working with the joomla user id instead of the nicknames.

Humans should use the nickname and the code is using the id.... analog to the orders:

The order_id is for the code only and the order_number is for the use by humans. The purpose of the order_id is to gather the data for one order very quickly. The purpose of the order_number is to provide same name for humans to adress the order and it should NOT be connected to the internal order_id (security through obscurity). So

After migration in VM2 it becomes VIRTUEMART_ORDER_ID 18.

Yes, that is right that way, because the order_id is only interesting for developers. The non coders should always use the order_number.

I do have some order numbers missing in VM1 (deleted orders) perhaps that is a reason why the order numbering in VM2 after migration is skew?

Exactly the reason we call it migration and not upgrade or port. The ideal of the migration is that you do not see a difference if you migrated old data or created them new,.. no gaps in the ids and things like this.

This has some disadvantages,.. on the other side it also can clean up an old big installation.

[e-trader]

Dear Milbo,

Thanks for your reply. I think we talk about the same thing but there is some confusion.

In my VM2 DB tables VIRTUEMART_ORDER_ID  is the human readable number. ORDER_NUMBER is the number interesting for developers like 70_68b9ec3fb8986c9762aec7dc3cc35. VM2 RC3 is showing the ORDER_NUMBER in the admin interface. Is this correct or is there a mixup and should it be fixed?

About changing the order numbers. Sometimes cleanup of order numbers can be good. Imagine a business with 5000 orders. After an upgrade, customers require assistance and with their old orders. The order numbers have changed. Also the business administration becomes increadibly difficult is the order numbers change. Could the "cleanup" of gaps in order numbers otherwise be optional? I could image there would be a demand for this. Thanks for your consideration, you guys are great.

[Milbo]

Thanks for your reply. I think we talk about the same thing but there is some confusion.

In my VM2 DB tables VIRTUEMART_ORDER_ID  is the human readable number. ORDER_NUMBER is the number interesting for developers like 70_68b9ec3fb8986c9762aec7dc3cc35. VM2 RC3 is showing the ORDER_NUMBER in the admin interface. Is this correct or is there a mixup and should it be fixed?

It is exactly the opposite, some clean integer number like 2948534 is for the programmer and the 70_68b9ec3fb8986c9762aec7dc3cc35 is for the enduser. The order_id is an integer and cant hold any chars. The order_number is a text and it adjustable with a plugin trigger. So you can write for the order_number also, Shop:AM_premium_21.12.11_cnr394856 (for exampel subshop in Amsterdam, premium shopper, bought 21.12.11, customer number 394856). So atm it looks unreadable for you, because we just placed a has there.

About changing the order numbers. Sometimes cleanup of order numbers can be good. Imagine a business with 5000 orders. After an upgrade, customers require assistance and with their old orders. The order numbers have changed. Also the business administration becomes increadibly difficult is the order numbers change. Could the "cleanup" of gaps in order numbers otherwise be optional? I could image there would be a demand for this. Thanks for your consideration, you guys are great.

The problem is that you before used the order_id, which is wrong. For what do you use the oder_number then? We use always the order_id, not the number. When we get the order_number like in the FE view orders for anonymous we look for the order_id which has this order_number and order_password,.. when there is something we get an order_id and display the order.

To clear the thing completly.
Order_id = the identification number of the order
order_number = the identification number of the order

What is the difference?
We use the order_id for the database, like the other ids, user_id, vendor_id, product_id,.... It is quite easy to guess an order_id, changing the auto_increment step does not help. But what does we want? We want that a shopper can safely refer to his order, without disclosure the internal data position and that when the dataposition changed, the data must stay identifiable. Additionally to that we want to be able to format the number the customer should see (cosmetic). So when you just got the order_id, or the order_number you cant guess the other, which provides a bit security due obscurity.

[e-trader]

Thanks for the reply Milbo.

I guess the usage of the ORDER_ID and ORDER_NUMBER have changed from VM1 to VM2. As you say, there are some security benefits and for field formatting. I just can't imagine a customer saying "my order number is 70_68b9ec3fb8986c9762aec7dc3cc35". Because in VM1 the ORDER_ID was the main key and not ORDER_NUMBER our administration is based on it, making the usability more complicated and I am wondering wether the benefits outweigh the problems?

Ok, this is not about bugs anymore did want to give my usability opinion now that it seems this is not a bug.

[Milbo]

No, we use the same system like in vm1.1: This is an example for the vm1 table
`order_id` = 23
`user_id` = 71
`vendor_id` = 1
`order_number` = 71_56f88af7dca67147bac705e77046f
`user_info_id` = 8f5385129889b20fc259e6c5279e9227

It was never right to work in vm1.1 with the order_id. As you can see it was already in vm1 so that the people from outside only should work with the order_number and the user_info_id.

[e-trader]

I've tested the 2.01d build and it seems this was not fixed, even though the issue was found. ORDER_CURRENCY is not migrated.

[e-trader]

Dear development team,

It appears 2.2 also does not migrate the VM1.1 currency of the orders/items. Are there any plans to fix this and in which version?

Thanks for any reply.

[e-trader]

Echo echo echo

[Robert V.]

I agree with e-trader.

IF you want to do proper book keeping, you should have some kind of ascending format, NOT an at random generated hex number.
Can i make a suggestion?

Why not do sth like (year)(date)(ordernr.0001) and ascend that by year, date and nr. - Or give us another way to do our book keeping properly!!!
I know i can change an order id manually! But i want it AUTOMATICLY!  - if you get 200 - 300 orders a day (let alone more) can i ask YOU to change the id's for me?

Because now i got these (stupid) at random generated hex order numbers like:

887206, 322005, f14105, etc, which makes yer book keeping a REAL BURDEN!!!
For my book keeper i made an excel file with my own numbers in ascending format with an extra field for the virtuemart order id. I'm working overtime (2-3 hours a day) to do this. Can you imagine how much work this is with 5000 orders? I cannot change the original order number because a customer gets an email when the order is confirmed and paid for.

I don't need a table id, i need a way to be able to build in an automated (timestamped) number. - preferrably a UTC one.... so i won't have to deal with (future) timezones

Can anyone tell me if there is a way to do this?


Is this possible at all?