According to the announcement for this version there is "New order numbers and invoice numbers". I do not see this on the orders I migrated from my live site onto my test site. Do I need to remigrate or does this only aply to new order thst are generated? I have booked about 3,500 order since i began with the orogonal "phpshop" and the numbering system was always simple, sequential and straightforward. Not so with 2.0.x. Is this fixed yet or not?
Bruce
Same here. Updated from 2.0.1k and hoping to avoid reimplementing the hack we did to assign the order id as the order number.
Jay
Quote from: jayrb on March 08, 2012, 02:11:53 AM
Same here. Updated from 2.0.1k and hoping to avoid reimplementing the hack we did to assign the order id as the order number.
Jay, please share the hack
Tsssss
sorry guys, use the right words, or the whole thing has not sense. The name of the columns is defining the name of the variable, can we agree on that?
The order_number of the old phpshop IS something like 65_fe6a551820cfaea58b5a091f80496.
You talk all the time about the oder_id. It was always an error of the old phpshop to show you the order_ids in the BE as order_number. The order_id is internal and should never be displayed, except when you are the adminstrator (not shopper, not shop owners, not vendors!)
Now the order_ids are the ids of the database. You should not share it, or you help hackers. The order numbers look now like this
c9b2051. The first 4 chars are random. then comes a zero and after that your incrementing serial.
The invoice number can look like this 120308AN6052. Similar here, the first 6 numbers are the date. Then 3 random numbers a 0 and the increment.
And before you hack this. Just use the triggers to manipulate this as you wish (yes there are already triggers). Lol
Milbo,
do you think that this minor hack revealing the order_number will be dangerous?
orders.php
568 $_orderData->order_number = $this->generateOrderNumber($_usr->get('id'),0,$_orderData->virtuemart_vendor_id);
When someone tries to use the order_id to view an order he must be admin. So no it should not make a real problem. The problem is more pishing together with guessing, there are some scenarios, but very unlikely. The point is just that there is a difference between the internal autoincrementing order id and the order number.
Thanks!
But write a plugin for it. There are endless scenarios, when people want the same numbers as their ERP.
Milbo, I wonder if you are missing the point. The only thing a customer cares about is having a simple order number (ID?) to refer to. In that respect the old system was perfect and at the very least should be the default method for 2.0. As administrator my interests are exactly the same. I want the be able to reference orders using that same sequentially generated number (order_id). It does not matter whether I am working on the VM back end, or in the database. Why on earth would you do it any other way? The long alpha-numeric order number is worthless to a customer or to me.
I understand it might be convenient to be able to devise some other system to allow an order id that contains a date or some other information but I do not nedd that and I doubt most other admins will either.
SO i get back to my original point. Can you include VM 2.0 to import the old order id's and increment them as before, or at least make this asn admin selectable option?
Bruce
A plugin doing that for you takes 4 hours maybe
I will not be able to think seriously about migrating my live site untill htis s done and i do not have the expertise to do that. I hope of someone make the effort to do so they will share it with me. I guess i am naive about software design. My guess would have been that the easiest thing to do would be to make the old method the default within a scheme that allows more user contrl over this.
Bruce
i am definitely agree with bruce, thx bruce.
please make a selectable option in konfiguration to have simple, continuous order numering.
You seem not to understand vm1 made an error, you may read this http://databases.about.com/od/specificproducts/a/firstnormalform.htm to understand better why we have an order_id and not just an order_number.
The new ordernumbers look like this:
8cd403, the formel is 5 random chars, then a 0, then the number, with a defineable offset. so in a row you get something like:
ag5d04
jd6k305
2gt6e06
..g34gr0324 and so on.
The advantage is your own security. For example a customer is giving you an order number, you must check if the customer fits to the order. There are several problems. The new order_numbers are like the "order_id"+"password". So in the moment you find the order_number in your database, you know very certain that this is the right user writing to you, even when the used email is different.
ok... well, there ist a continus numbering: ag5d04, jd6k305, 2gt6e06 ... g34gr0324
why is not possible to display just the number for the Customer, and the prefix is hidden?
Imagine your customer calls you, you ask, which order number you have?
do you ever have receive a order number like this?
and this is just 1 problem with the confusing order number.
I agree with Markito. This is a bonehead-simple usability issue. Whatever you want to call it, the shop owner and the customer need to have a simple "order reference number" that is simple, reasonably short and sequential. In other words, exactly like VM1.1. How on earth could there be a security issue related to simple order numbers? If there is, I don't care. I am beginning to wonder if any of the develpment team has ever run a functioning e-commerce web site?
My most recent VM1.1 order number is 3598. Of course in the database the "real" order_number is some random and obtuse number that would be completely useless as a reference number for either the customer or myself. Taking a system that works and substituting something different and hopelessly complicated is simply nutty.
I am eagerly awaiting my next order #3599, not some randomly generated alpha-numeric data string. Until this is fixed in VM2.0 I will never consider adopting it. End of story.
I had exactly this case. I overtune it now a bit, assume you have a customer, he moved and lost his email account. But he has the invoice. With the order_number you can be quite sure he is not trying to betray. The most used way to hack is to use social engineering http://en.wikipedia.org/wiki/Social_engineering_(security). The bigger the store, the more likely. Additionally to that provides virtuemart an anonymous order tracking and with this technic all invoices and emails are generated. Having the loginname (order_number) is having the half of the password. For example, when you go in the BE and look for your pdf invoice, it just calls an url like:
http://myshop.com/index.php?option=com_virtuemart&view=invoice&layout=invoice&format=pdf&tmpl=component&order_number=bc7d04&order_pass=p_57f98
The order_number and the order_pass must fit, so the order_number is here like the loginname. Assume you have a bigger store,.. with 10k entries. Hackers know the numbers and can try over the time to hack it. Whatever they want with it, that is another question.
Okay the first link was informative but i am not sure how it applies to what we are talking about. Maybe you were trying to explain with the second link but I fail to see the security issue. I do not collect bank information, Social Security numbers, or credit card information, so what exactly is the risk? It sounds like a solution for a problem that simply does not exist. Even if I am wrong about this you need to have a bertter solution or at least offe the option to use the old method with a security warning.
It may be possible to create the technical link with a additional order_link_number instead the order_number and made the order number for the customer usability?
http://myshop.com/index.php?option=com_virtuemart&view=invoice&layout=invoice&format=pdf&tmpl=component&order_link_number=bc7d04&order_pass=p_57f98
That would be really great, I would not expect the customer such complicating number. Clear order numbers is a really basic user-friendliness issue.
When I look in my invoices, then it depends, for example the microsoft store has a loong number. Not easy to spell at the phone. But my flight ticket for example has a short alphanumeric number. Easier then the microsoft one, even it is alphanumeric. It is also a matter of taste and store size. And as I said, it is also relativly easy to write a plugin creating own order_numbers and invoice_numbers. Additionally to that, you usually dont want to reveal to obvious to every customer how many orders you have already.
Okay, I got the process to work. I remigrated and the order numbers were retained. The order id numbers did reset, so that after migration order number 2167 had order ID 2147. It looks like the order id's were renumbered to fill gaps in the sequence.
It would be nice to be able to continue the established sequence going forward. In response to Milbo's last post I really do not care if anyone knows how many orders i have, but I suppose others do. Whay not just build in some options for numbering. Perhaps a new shop could have the first order be "1001" by having a configuration definable starting number .
I like many other have become annoyed by the huge order numbers generated some the mega e-commerce retailers. Same goes for the confirmation codes generated when making online payments. Some of them were 20+ characters long. A pain in the butt.
I delted all VM tables and did a fresh migration with 2.0.4. I also selected the option to retain the VM1.1 order numbers. It seemed to go much smoother than the first time.
I noticed two problems when I was finished.
1. A few orders were still missing after making the migration but there were many fewer missing orders than before. I think my backup database that i migrated inlcuded orders upt to number 3598 but after mirating the highest order number was 3553 dating back to mid February. This is tantalizingly close but I would like to migration to be complete when I move the live site.
2. The sort function on the order ID works fine. The sort function on the order number column give wacky results that are out of sequence. For example the numbering on the increasing sort is 10, 100, 1000, 1001. Reversing the sort order give different but also erroneous results.
Assuming these two things get fixed all I would need is a plug-in that would allow me to continue the existing (VM1.1 style) order number sequence (I would be happy to contribue $ for this). I would also like to edit the most recent order_id so that it matched the order_number. Hopefully, VM would increment both number based on the highest number already in use.
I have now created such a plugin, which allows the shop owner to change format of the order number, order password and invoice number at will:
http://open-tools.net/virtuemart-2-extensions/40-vm2-ordernumber.html
The format is given as a text string, where [...] is understood as a variable and replaced by its value (e.g. [year] by the current year).
The running counter is indicated by #. The counter can be configured to be global (e.g. not reset each year/month/..) or a separate counter for each year/month/...
I hope you like the plugin and it does what you need.
To start the ordernumber from a given number and create sequential order numbers I have changed these files:
administrator\components\com_virtuemart\helpers\config.php
line 48: defined('VM_ORDER_OFFSET') or define('VM_ORDER_OFFSET',1000); to start with ordernumber 1000 and
administrator\components\com_virtuemart\models\orders.php
line 1143 //We can use that here, because the order_number is free to set, the invoice_number must often follow special rules
$count = $db->loadResult();
$data = $count + (int)VM_ORDER_OFFSET;
// vmdebug('my db creating ordernumber VM_ORDER_OFFSET '.VM_ORDER_OFFSET.' $count '.$count, $this->_db);
// $variable_fixed=sprintf("%06s",$num_rows);
// $data = substr( md5( session_id().(string)time().(string)$uid )
// ,0
// ,$length
// ).'0'.$count;
return $data;
}
In this case the first order will have number 1000 and the next 1001 and so on.
I hope you can use it
Quote from: JanZet on April 20, 2013, 14:01:54 PM
To start the ordernumber from a given number and create sequential order numbers I have changed these files:
administrator\components\com_virtuemart\helpers\config.php
line 48: defined('VM_ORDER_OFFSET') or define('VM_ORDER_OFFSET',1000); to start with ordernumber 1000 and
administrator\components\com_virtuemart\models\orders.php
line 1143 //We can use that here, because the order_number is free to set, the invoice_number must often follow special rules
$count = $db->loadResult();
$data = $count + (int)VM_ORDER_OFFSET;
// vmdebug('my db creating ordernumber VM_ORDER_OFFSET '.VM_ORDER_OFFSET.' $count '.$count, $this->_db);
// $variable_fixed=sprintf("%06s",$num_rows);
// $data = substr( md5( session_id().(string)time().(string)$uid )
// ,0
// ,$length
// ).'0'.$count;
return $data;
}
In this case the first order will have number 1000 and the next 1001 and so on.
I hope you can use it
OH THAT'S IT
Thank you :)