We have an IOrderNumberGenerator interface that you can override with your own implementation but there are number of things you should be aware of.
Performance Bottleneck
We initially had sequential order numbers but this essentially meant that on each order you had to hit the DB to generate the order number as these were store specific. This is fine most of the time but under load we found this to be a pretty big bottleneck as transactions would have to wait for another transaction in progress to access the DB to get the next number.
To avoid this in Vendr we use a timestamp + random seed based algorithm such that it can all be generated in memory without the need for a DB hit.
Vendr isn't an accounting application
I know you've only mentioned it from the perspective of the customer wanting something "more readable", but we find that people often request sequential order numbers in order to use them as VAT receipts too, but even with a sequential Order Number generator you aren't guaranteed sequential order numbers in Vendr.
An important thing to know in Vendr is that the Order Number is generated just before you are sent to the payment gateway. This is different to Tea Commerce where the Order Number was generated on finalization, however many payment gateways now use an async approach to confirming payments and so often this means your customer hits the confirmation page before Vendr is told the payment was successful or not. If we were to issue order numbers on finalization like TC it would mean you wouldn't be able to show your custom an order number on the confirmation screen. Also in TC, it's often the cart number that is presented in the payment gateway which is separate to the order number and so this also causes confusion as the customer sees one number in the gateway and another on confirmation.
So, in Vendr, we issue the order number prior to moving to the gateway as this ensure you can show a consistent number throughout the checkout process and also have a number waiting when you hit the confirmation page, whether the payment confirmation has come through yet or not.
A side effect of this however, and the reason we can't guarantee sequential numbers is, if someone hits a payment gateway but then decides to cancel out and go back and modify the order, when the go to the payment gateway again, they will be issued with a new order number and the previous one will be gone. This is due to the fact that many payment gateways don't allow you to re-process the same order number again.
So with this in mind, for the most part, your order numbers will be sequential, but if you do have people canceling and going back to the site to modify an order, then you sequences will have gaps if new order numbers are generated and THIS is not allowed with VAT receipt records. With VAT records you must record every number and you must'nt have gaps in them.
Ultimately we took the stance that Vendr isn't an accounting platform and so VAT receipts should be managed in a proper manor and so if this is required you should integrate with a dedicated system to provide these independently of the order number (we may look at producing an add on for this at a later date, but for now, this would have to be a custom implementation / integration).
Another reason to understand this as well is it could cause confusion to the store owner wondering why they have missing order numbers and thinking there is something wrong, when there isn't
So, in answer to your question, yes, you can implement a custom IOrderNumberGenerator and generate order numbers however you like, but you should be aware of the above before you do so.
I absolutely agree that a webshop is not an accountant program, but we're not talking about sequential numbering here, just order numbers that are easy for both the client and their customers to read, say and reference, and for that there are no issues with having gaps.
A lot of other platforms I've worked with, creates an order when going to payment, if the customer cancels, the order is reverted to a cart, and if the customer goes to payment again, a new order is created.
And regarding performance bottlenecks, then it's not a problem for other platforms.
I'm not saying this to put Vendr down or anything, I love working with it, I'm just comparing to other platforms, and I know this will be a topic for most client, and for some a real issue.
So I hope you'll consider supporting it in a later update 🤞
Keep up the good work, Vendr is awesome to work with #H5YR 😊
Sure thing. I probably over explained it here as I know others will ask in future so I thought I'd get everything down.
As I say, you can swap this out no problem so it is supported if you'd prefer an alternative. The performance bottle neck only really occurs at quite high demands, but of course I need to take this into consideration as the default baseline, but if you know the store isn't really going to be under heavy demand then this isn't a huge problem.
When we chose our order number approach, I did spend a lot of time ensuring it was as minimal / readable as possible, whilst giving us guaranteed unique values under load. I appreciate it's not as simple as "Order number 00234" but 3 blocks of 4 digits isn't too bad to quote if needed, and the back office can search on a partial order number so you could just asks for the last 4 digits to narrow down the search for an order.
Has any one creating numeric order numbers using IOrderNumberGenerator?
I'm curious how you would ensure the number is unique since it looks like Vendr/Umbraco Commerce would set the value after you generate it, so it would be possible that another order could get generated in there, and so you could end up with two orders with the same order number (or is that the high load issue that Matt was talking about).
Changing order number format
Hi
We have a client who wants their order numbers to be in a more readable format, i.e. 000001.
Is that possible?
TL;DR
It's possible yea, though it's not recommended.
We have an
IOrderNumberGeneratorinterface that you can override with your own implementation but there are number of things you should be aware of.Performance Bottleneck
We initially had sequential order numbers but this essentially meant that on each order you had to hit the DB to generate the order number as these were store specific. This is fine most of the time but under load we found this to be a pretty big bottleneck as transactions would have to wait for another transaction in progress to access the DB to get the next number.
To avoid this in Vendr we use a timestamp + random seed based algorithm such that it can all be generated in memory without the need for a DB hit.
Vendr isn't an accounting application
I know you've only mentioned it from the perspective of the customer wanting something "more readable", but we find that people often request sequential order numbers in order to use them as VAT receipts too, but even with a sequential Order Number generator you aren't guaranteed sequential order numbers in Vendr.
An important thing to know in Vendr is that the Order Number is generated just before you are sent to the payment gateway. This is different to Tea Commerce where the Order Number was generated on finalization, however many payment gateways now use an async approach to confirming payments and so often this means your customer hits the confirmation page before Vendr is told the payment was successful or not. If we were to issue order numbers on finalization like TC it would mean you wouldn't be able to show your custom an order number on the confirmation screen. Also in TC, it's often the cart number that is presented in the payment gateway which is separate to the order number and so this also causes confusion as the customer sees one number in the gateway and another on confirmation.
So, in Vendr, we issue the order number prior to moving to the gateway as this ensure you can show a consistent number throughout the checkout process and also have a number waiting when you hit the confirmation page, whether the payment confirmation has come through yet or not.
A side effect of this however, and the reason we can't guarantee sequential numbers is, if someone hits a payment gateway but then decides to cancel out and go back and modify the order, when the go to the payment gateway again, they will be issued with a new order number and the previous one will be gone. This is due to the fact that many payment gateways don't allow you to re-process the same order number again.
So with this in mind, for the most part, your order numbers will be sequential, but if you do have people canceling and going back to the site to modify an order, then you sequences will have gaps if new order numbers are generated and THIS is not allowed with VAT receipt records. With VAT records you must record every number and you must'nt have gaps in them.
Ultimately we took the stance that Vendr isn't an accounting platform and so VAT receipts should be managed in a proper manor and so if this is required you should integrate with a dedicated system to provide these independently of the order number (we may look at producing an add on for this at a later date, but for now, this would have to be a custom implementation / integration).
Another reason to understand this as well is it could cause confusion to the store owner wondering why they have missing order numbers and thinking there is something wrong, when there isn't
So, in answer to your question, yes, you can implement a custom
IOrderNumberGeneratorand generate order numbers however you like, but you should be aware of the above before you do so./Matt
Hi Matt
Thanks for the detailed answer and explanation.
I absolutely agree that a webshop is not an accountant program, but we're not talking about sequential numbering here, just order numbers that are easy for both the client and their customers to read, say and reference, and for that there are no issues with having gaps.
A lot of other platforms I've worked with, creates an order when going to payment, if the customer cancels, the order is reverted to a cart, and if the customer goes to payment again, a new order is created.
And regarding performance bottlenecks, then it's not a problem for other platforms.
I'm not saying this to put Vendr down or anything, I love working with it, I'm just comparing to other platforms, and I know this will be a topic for most client, and for some a real issue.
So I hope you'll consider supporting it in a later update 🤞
Keep up the good work, Vendr is awesome to work with #H5YR 😊
Hi Michael,
Sure thing. I probably over explained it here as I know others will ask in future so I thought I'd get everything down.
As I say, you can swap this out no problem so it is supported if you'd prefer an alternative. The performance bottle neck only really occurs at quite high demands, but of course I need to take this into consideration as the default baseline, but if you know the store isn't really going to be under heavy demand then this isn't a huge problem.
When we chose our order number approach, I did spend a lot of time ensuring it was as minimal / readable as possible, whilst giving us guaranteed unique values under load. I appreciate it's not as simple as "Order number 00234" but 3 blocks of 4 digits isn't too bad to quote if needed, and the back office can search on a partial order number so you could just asks for the last 4 digits to narrow down the search for an order.
Anywho, I hope this helps
Matt
Has any one creating numeric order numbers using IOrderNumberGenerator?
I'm curious how you would ensure the number is unique since it looks like Vendr/Umbraco Commerce would set the value after you generate it, so it would be possible that another order could get generated in there, and so you could end up with two orders with the same order number (or is that the high load issue that Matt was talking about).
is working on a reply...