Quote:
|
Originally Posted by cflsystems
You will need to make a lot of changes to avoid issues with orderNumber.
...
If you start recording orderNumber as string, meaning the field having non-numeric characters, you will break orders search (both admin and customer), next/prev order, eventually payments and everything else that depends on orderNumber.
Not to mention orderNumber is cast to (int) numerous times within the code, both for PHP and MySQL.
...
Unfortunately XC is coded within its core to work with orderNumber instead of orderId for lots of functions and behavior.
|
Lots of good information here. Thank you, again. Instead of relying on the core orderNumber field, then; perhaps it might be better to add a column to the Order Model Class with behaviour defined by my module which would also include the necessary templates to display this value in both the FO and BO. This makes the module design a bit less of a challenge as I do not have to be as concerned with messing up the behaviours which access the orderNumber field itself. My next step was going to be to add a separate column for an invoice number, anyway, so it's just a matter of defining the columns and procedures associated with each. This is not so bad, since some of my other systems have separate numbers for the system and for the user/customer.
Thanks again. Now I have a better idea of what direction to take.