View Issue Details

IDProjectCategoryView StatusLast Update
0006503OXID eShop (all versions)2.6. Administer orderspublic2024-03-27 11:31
Reportersuabo Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version4.10.0 / 5.3.0 
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
Database VersionNot defined

Relationships

related to 0006508 closedQA Logischer Bug wird nicht behoben 

Activities

QA

2016-09-09 17:36

administrator   ~0011776

Last edited: 2016-09-09 17:46

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?

FibreFoX

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.

QA

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.

keywan.ghadami

2016-09-15 11:06

reporter   ~0011784

Last edited: 2016-09-15 11:29

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)

suabo

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.

QA

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.

QA

2016-09-20 10:22

administrator   ~0011797

Last edited: 2016-09-20 10:23

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.

suabo

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:
https://bugs.oxid-esales.com/view.php?id=6508

Thank you

Sven Brunk

2024-03-27 11:31

administrator   ~0016500

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?