VM 2.0.2 revised order numbering

[Bruce Morgan]

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

[jayrb]

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

[maxispin]

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

[Milbo]

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

[maxispin]

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);

[Milbo]

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.

[maxispin]

Thanks!

[Milbo]

But write a plugin for it. There are endless scenarios, when people want the same numbers as their ERP.

[Bruce Morgan]

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

[Milbo]

A plugin doing that for you takes 4 hours maybe

[Bruce Morgan]

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

[markito]

i am definitely agree with bruce, thx bruce.

please make a selectable option in konfiguration to have simple, continuous order numering.

[Milbo]

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.

[markito]

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.

[Bruce Morgan]

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.