Numeric order reference

[Daresh]

Hi, I just checked and my free Numeric Order Reference module works fine on thirtybees. This is a simple, but usefull override, allowing you to change this nasty order references to something nice. Maybe this kind of feature can be someday native in thirtybees? More about the module: http://greenmousestudio.com/en/numeric-reference (tried to attach it but it got blocked)

[lesley]

You should create a github repo for it, it looks like a really useful module. Thanks for testing it out.

[Daresh]

I'm a bit new to GitHub, but I made a repo for it, take a look: https://github.com/daresh/Numeric-order-reference

[vzex]

Hi @Daresh nice to see you here!

[jnsgioia]

I have been using this module and it does work well with 30bz.

[30knees]

Hi @Daresh,

I'm not sure whether this is your module, which I am using, or something with the shop, but I got two orders that have the same reference number. The order IDs are 377 and 378 and the reference numbers are each XX377.

Any ideas hows to troubleshoot?

[Daresh]

It's probably not a bug, it's a feature ;) Prestashop splits orders if you have products with excluding carriers set.

[30knees]

Haha, but two different customers, two distinct orders :) So it can't be that.

[Daresh]

Right, very interesting, never had an issue like this before and thousands of shops use this module. Must be some kind of an unlucky coincidence...

[30knees]

OK, I'll keep an eye on it and report if it happens again.

[Beeta]

isn't the order reference used as a "password" to access guest order without logging in? or is a combination of customer email AND order reference that give access?

[alwayspaws]

@daresh said in Numeric order reference:

Hi, I just checked and my free Numeric Order Reference module works fine on thirtybees. This is a simple, but usefull override, allowing you to change this nasty order references to something nice. Maybe this kind of feature can be someday native in thirtybees? More about the module: http://greenmousestudio.com/en/numeric-reference (tried to attach it but it got blocked)

I love this module! Thank you, @Daresh

[dynambee]

Bringing an old thread back from the past. I have installed the random order reference number generator into TB 1.1.x and it works fine.

However TB uses a separate sequential number for invoices. Since one of my reasons for using this module is to cloak the number of orders we process I would like to use the same randomly generated order reference number for the invoice number. If that isn't possible then I'd like to use any randomly generated number for invoices. Basically anything besides a sequentially generated number.

Is this something that could be added to this same module? If not, is it something that could be done with a separate override? Any ideas?

[datakick]

I believe what you want do do is override Order::setLastInvoiceNumber. 

Note that there can be multiple invoices for one order, so make sure your invoice numbers do not clash in this situation

 

[dynambee]

11 minutes ago, datakick said:

Note that there can be multiple invoices for one order, so make sure your invoice numbers do not clash in this situation

Interesting. What sort of situations give rise to multiple invoices within an order? Would it only happen when there is more than one shipping type within an order?

[datakick]

11 minutes ago, dynambee said:

Interesting. What sort of situations give rise to multiple invoices within an order? Would it only happen when there is more than one shipping type within an order?

I don't really know how to generate multiple invoices for one order. I just see there's a support for this in the code. Also, in back office order edit form there is some support for this, for example when adding discount:

But it's totally possible this is just remnants of some old functionality that was dropped from ps/tb

 

[wakabayashi]

@datakick is right. Multiple invoices can arise on order edits. It happens here too, from time to time.

I am not totally sure, but maybe it happens as well, when some of your products are out of stock and others are not. (We only allow to order when the product is in stock)

[wakabayashi]

Funny: I just noticed now by chance, how it happens in our case. When you add a new product to an order, which already has an invoice. The already created invoice is selected and all is fine. The problem arises, if you immediately add a second product. The invoice isn't selected anymore and is not even selectable...

Workaround: If you refresh the order after you added the first product, then you can add the second product...

[DRMasterChief]

@dynambee i think you can easily contact the author of the module  ( @Daresh )  and he will have a solution, maybe he will modifiy the module for you for some bucks  :)   All experiences with Daresh seems to be very good... 

[dynambee]

It sounds like the best option would be to generate invoice numbers randomly and not try to match order numbers and invoice numbers.

After looking into this more though, it doesn't seem that generating random order reference numbers and random invoice numbers actually fixes the problem of competitors being able to easily view order volumes. The links used when referencing the order details `javascript:showOrder(1, 1, 'https://www.mydomain.com/order-detail?id_order=1');` and invoices `https://www.mydomain.com/pdf-invoice?id_order=1` still use the sequentially incremented primary order table ID. 😞

I'm certainly not the first person to think about this (example) in the context of online sales and I suspect it's a pretty common concern. Rick James wrote up a list of potential ways to generate random table IDs some years back.

To avoid having to randomize the `id_order` primary key would it be possible for any customer-facing order & invoice links to use the order table's `reference` field instead of the `id_order` field?

[dynambee]

18 minutes ago, DRMasterChief said:

@dynambee i think you can easily contact the author of the module  ( @Daresh )  and he will have a solution, maybe he will modifiy the module for you for some bucks  🙂  All experiences with Daresh seems to be very good... 

Yup, I replied to this old thread that was started by @Daresh so that he would see the discussion. Being a free module I don't really want to ask him to improve on it, the module itself does do what is advertised perfectly. However a way to generate random invoice numbers would also be appreciated, certainly.

[dynambee]

How bad an idea would it be to change all `id_order` columns (there are 14 of them) to BIGINT instead of INT and then randomly generate `id_order` values when orders are created?

If I use 12 digit randomly generated `id_order` numbers (combined with a yymm prefix) and allow for the birthday paradox the site could do 1 million orders per month (an obviously impossible number for my situation) before the probability of a random `id_order` number collision exceeds 50%.

To put that into a bit better context, I'd have to receive 200 orders per hour every hour for a month (144,000 orders) to have 1% probability of at least one collision with a 12 digit random `id_order` field. If everything goes extraordinarily well I could see having 5000 orders per month.

Terrible idea?

[dynambee]

(PHP itself should be fine with 18 digit numbers, 64-bit builds of PHP on modern servers should have no problems with integers ranging from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 which is big enough for my idea above.)

[wakabayashi]

I believe, you try too hard on a simple topic. Why not just higher order reference? As far as I understand people don't want it, because competitors could read something from it. I really dont understand what this something should be. Especially as you are selling products in a range of 5$ and 5000$. In my module orderrefnum from Madman I can also define a value, on how much these number should rise. So you could set it there to "13" and pretend you sell 13 times as much as you really do.

[dynambee]

I think you may have misunderstood.

The orderrefnum is only part of the problem. It is a reference number that is shown on the surface, but the real order ID still exists and is stored separately in a field called id_order.  Ideally the id_order should be invisible and never shown to the customer but this is not the case. In links that the customer can see (to view order details, to view an invoice, and probably elsewhere) the real, sequentially generated id_order value is displayed.

So if a competitor wants to do some research on a business they can go to that business' shop, make an account, and buy a cheap item. Then 10 days later buy another item. Look at the difference between the id_order numbers and divide by 10. Now you know how many orders per day your competitor is selling. If you happen to run a similar business (or just know the market) you will know the typical average order size and from that you can make a decent guess about their monthly and yearly sales.

Some people don't care if this information is visible. Other people don't want to give out private business information. I happen to be in the latter group but I totally understand that many people won't care at all.