View Issue Details

IDProjectCategoryView StatusLast Update
0006503OXID eShop (all versions)2.6. Administer orderspublic2016-09-21 09:54
Status acknowledgedResolutionopen 
Product Version4.10.0 / 5.3.0 
Target VersionFixed in Version 
Summary0006503: Order number not set to oxcounter
DescriptionIf 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 ReproduceGo To any order > raise number
Make a new order in FE > new order number isn't force to be the next number
TagsNo tags attached.
ThemeNot defined
BrowserNot defined
PHP VersionNot defined
MySQL VersionNot defined


related to 0006508 closedQA Logischer Bug wird nicht behoben 



2016-09-09 17:36

administrator   ~0011776

Last edited: 2016-09-09 17:46

View 2 revisions

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?


2016-09-12 10:58

reporter   ~0011777

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.


2016-09-12 12:04

administrator   ~0011778

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.


2016-09-15 11:06

developer   ~0011784

Last edited: 2016-09-15 11:29

View 2 revisions

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)


2016-09-15 11:16

reporter   ~0011785

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.


2016-09-16 10:16

administrator   ~0011788

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.


2016-09-20 10:22

administrator   ~0011797

Last edited: 2016-09-20 10:23

View 2 revisions

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.


2016-09-20 13:02

reporter   ~0011798

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:

Thank you