View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006503 | OXID eShop (all versions) | 2.6. Administer orders | public | 2016-09-08 17:17 | 2024-03-27 11:31 |
| Reporter | suabo | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Product Version | 4.10.0 / 5.3.0 | ||||
| Summary | 0006503: Order number not set to oxcounter | ||||
| Description | If you have any reason to change your order number you could do this by editing the last order and raise the number. Since the shop is using oxcounter table the order number isn't updatet there if we manually change it in the be. | ||||
| Steps To Reproduce | Go To any order > raise number Make a new order in FE > new order number isn't force to be the next number | ||||
| Tags | No tags attached. | ||||
| Theme | Not defined | ||||
| Browser | Not defined | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
Tested: Last order number raised in BE from 3 to 5. Next order number is 6. Order number 6 raised in BE to 16. Next order number is 7. Whats the problem with that? |
|
|
The problem IMHO is that it makes it harder to provide a logic order of "orders". Having an "order 15" being done after "order 16", and having "order 17" being done before "order 16" might not be a nice thing for modules and persons who strugle with customer-feedback. If this is implemented, please provide some switch to change behaviour inside the configuration-tabs. |
|
|
The counting is how the software currently works. Its not a bug, its a feature wished from the shop users. But you can change that by writing a module modifying the oxcounter class. |
|
|
Please reopened, and retest. As I understand "suba" the problem is that you will not be able to make orders anymore. Because the in the example from QS, "Next Order Number is 7" it will a double 16 when reaching 16. Only solution so far is that you manipulate oxcounter by sql. -- Edit: removed statement that shop would crash (might be project related, uniq index, but demo shop does not throw an exception) |
|
|
thank you keywan, that's what i meant. In time there was no oxcounter table there was a logic to get next order number. This logic was lost with the use of the new table. The solution will be to check agains oxcounter if an order number is saved in be and update oxcounter entry if needed. |
|
|
If the shop owner wants to change the order number he should be aware that this could result in double order numbers in the system. And if this results in double order numbers, then it will not result in any shop problems, as the order number is not the primary identifier. oxcounter just always counts +1. |
|
|
I reopen 0006503 this entry as a feature request therefore our Product Owner can decide how to handle the behavior of the input field for changing the order number of an existing order by hand. |
|
|
okay, to keep all the informations about it together, as you pleased me to do, i will link to the bug i created to get this one opend again: https://bugs.oxid-esales.com/view.php?id=6508 Thank you |
|
|
Actually this is a complicated problem to solve. Let me give some reasons why: - it is illegal to change the order number. From a legal perspective, the order is a document that may not be changed - the change we would thus need to make is to prevent changing the order number - the usecase described, is, that a bug caused an evenly illegal duplicate order number. Instead of creating a functionality that allows for working around the bug in the normal backend, the better solution would be to prevent the bug in the first place The clean solution would be to: - prevent the duplicate order numbers on a very low level (e.g. via database constraints) - prevent changes of the order number - make the creation of new orders failsafe in case an order number already exists and just use the next available order number @suabo: Would you agree? |
