Verschwundene Bestellnummern

Deutsches Forum
1

Hallo Forum,

nicht nur der SUPER-BUG (änderungen an Artikeln ändern alte Betsellungen) ärgert mich, seit dem update auf 4.6.x verschwinden bei uns ab un an Bestellnummern.

früher im 3.x ´er shop konnte man eine bestellung aus dem admin löschen (zum beispiel eine eigene testbestellung) und die nächste bestellung hatte die richtige folge-nummer. also die der gelöschten bestellung, die nummernfolge war nicht gestört.

heute wird für gelöschte bestellungen die nummer nicht zurück gesetzt, es fehlt also eine wenn man die bestellung ganz aus dem admin löscht.

dumm nur das auch manchmal nummern fehlen obwohl wir nichts im admin gelöscht haben, also einfach zwischen bestellung 12345 und 12347 eine fehlt.

ich habe KEINE ahnung wieso, kann es nicht selbst reproduzieren oder herbeiführen (außer natürlich mit dem löschen der bestellung aus dem admin)

der erste verdacht das das paypal modul den fehler macht haben sich nicht bestätigt, mutwillige abbrüche im bezahlprozess bei PP führen nicht zum anlegen einer oder überspringen einer bestellnummer.

haben auch andere das problem schon mal gehabt ? probiert doch mal aus was passiert wenn ihr eine eigene testbestellung im admin löscht, hat die nächste bestellung dann die nummer der gelöschten bestellung oder einen zähler mehr ?

der ratlose mj.kater

2

das erste “Problem” ist kein Problem weil:
a) zum Testen hat man ein Testsystem
b) du machst eine Testbestellung mit der Nr 123, dann noch eine mit der Nr. 124. Dann macht der Kunde eine Bestellung mit der Nr. 125. Jetzt hast du 123 und 124 gelöscht. Und jetzt würde die über-übernächste Bestellung wieder die Nr 125 bekommen. Schlecht.

Zu dem Überspringen kann ich dir aber nichts sagen, ich sehe das aber auch nicht als Problem.

3

Hi,

das überspringen von Bestellnummern habe ich regelmäßig! Auf der einen Seite finde ich es suboptimal, es ist aber besser als die alte Version.

Mit der 4.5? wurde die Berechnungsart der Bestellnummern verbessert (wirklich!). Bisher war es so, dass wenn 2 Kunden gleichzeitig (auf die Milli-Sekunde genau) bestellt hatten, ist eine Bestellung mit Bestellnummer 0 angelegt worden. Dieser Fall kommt öfters vor.

Seit der 4.5 wird die Bestellnummer glaube ich früher und anderst vergeben (siehe Realeasenots), so dass auf jeden Fall die Bestellungen sauber angelegt werden, auch wenn oft eine Nummer übersprungen wird (wahrscheinlich, wenn die Leute die Bestellung im Warenkorb abbrechen?).

Dies ist zumindest mein Wissenstand. Müsste heraussuchen, wo das Thema schonmal diskuiert wurde.

cya

4

@ Vanille Donner:
Du hast recht, und ich kann damit leben keine Bestellungen mehr zu löschen, stehen sie halt als gelöscht in der liste. ABER das Bestellnummer OHNE ersichtlichen Grund fehlen ist nicht nur ein Schönheitsfehler. Der nächste Prüfer vom FA wird da mit Sicherheit drüber stolpern und meckern, das nicht dokumentiert, Bestellnummern verschwinden, legt ja auch den Verdacht nahe das der Shop Betreiber da was gefingert hat. Das ist nicht gut !

  • und zum Punkt Testsystem: natürlich haben wir sowas, ABER es kommen IMMER auch Probleme vor die erst wirklich LIVE auftreten und die man dann auch NUR live nachvollziehen kann.

@Firefax: Also wenn die Bestellungen im Millisekunden-takt reinkommen hat man sicher noch andere Sorgen… :slight_smile:

Oxid muss das untersuchen und auf die Bug-liste setzen.

5

Hier gehts zum Bugtracker: https://bugs.oxid-esales.com/main_page.php
Dort kannst du Bugs eintragen, was im Forum steht fließt erstmal nicht in die Entwicklung ein, bzw. wird nicht von den Entwicklern gelesen.

Wenn du 2 Bestellungen am Tag hast du die eben zufällig zu gleichen Zeit stattfinden (Identischer Zeitstempel in der Datenbank) hatte dies zu Problemen geführt.
Hier noch ein Link zu der neuen Erstellungsweise der Bestellnummer http://wiki.oxidforge.org/Features/oxCounter_implementation

Das FA interessiert sich glaube ich nicht für deine Bestellnummern, nur für eine fortlaufende Rechnungsnummer. Ok, wahrscheinlich ist bei dir die Nummer identisch, wenn du ohne Wawi arbeitst. Dann ist es ein Problem.

cya

6

Tabelle “oxcounter” - da werden die Zähler mitgeführt. Reines Löschen einen Bestellung hilft da nicht…
Im Übrigen interessiert das FA nicht, wie die Bestellungen nummeriert sind…

7

also wir haben natürlich eine WaWi dahinter und deine Vermutung über das was das FA interessiert zeugen eher von wenig Erfahrung mit dem FiesenAmt… wir alle, die einen Webshop, also unser Geschäft im Virtuellen Raum betreiben werden da noch viel lernen müssen, und manch einer wird sich noch wundern; oder hat hier schon einer eine manipulationssichere Aufbewahrung die min. 6 Jahre (besser 10 Jahre) ALLE e-Emails die mit dem Geschäft zu tun haben aufbewahrt ?

Ist bereits seit Jahren verpflichtend ! Wird bei den BP´s immer mehr ein Thema.

Daher ist auch der Onlineshop (der ja quasi deine Registrierkasse im web ist) auch ein TOP Untersuchungsobjekt für die BP, und glaube mir inkonsistente Nummernfolgen sind ein gefundenes Fressen.

mit freundlichen Grüßen

8

Hallo,
ich bin ja auch nicht glücklich mit den oxCounters und dem Überspringen von Bestellnummern, bisher konnte mir auch keiner eine schlüssige Erklärung geben, warum das so ist und wie man es ggf. ändern kann.

Hast du den Bug schon eingetragen?

cya

9

hallo firefax,

nein habe ich noch nicht eingetragen, ich finde diesen “bug tracker” gelinde gesagt auch sehr gewöhnungsbedürftig, mir fällt schon das lesen und verstehen dieser tabelle schwer. wenn du willst dann trag du das da ein.

@hebsacker: ich würde nicht so voreilig verallgemeinern, was auf Betriebe mit Ladenlokal oder Katalog Versand zutrifft muss noch lange nicht, und insbesondere auf reine web-firmen, zutreffen; und auch in der WaWi stellen sich die fehlenden Bestellnummern ja dar, oder wie sonst willst du die online Bestellung mit dem Lieferschein bzw. später der Rechnung verknüpfen ?

10

Wenn man sich daran gewöhnt hat ist der Bugtracker eigentlich recht einfach (Standartwerkzeug).

Habs mal eingetragen: https://bugs.oxid-esales.com/view.php?id=4799

Bin gespannt was die Entwicklung daraus macht und Marco dazu sagt :wink:

cya

11

Hallo,

die Entwicklung hatte sich gemeldet und konnte den Bug nicht nachvollziehen. https://bugs.oxid-esales.com/view.php?id=4799

[B]Weiß jemand einen Weg, wie man es in einer Demo-Umgebung reproduzieren kann?[/B]

Kann es mal jemand mit dem Ansatz aus dem folgenden Bugreport testen? ( https://bugs.oxid-esales.com/view.php?id=3253 )
Ggf. liegt es auch an einer frühren Vergabe der Bestellnummern (zb. bei Paypal, Heidelpay oder anderen Zahlungsarten, die dann nicht abgeschlossen werden) Oder erstmal eine Bestellnummer reserviert wird und dann bei dem Abschluss die Bestellnummer neu vergeben wird?

cya

12

  1. Bestellungen kann ich bei jeder Oxid Version 4.2 bis 4.7 im Admin unter Bestellungen verwalten > Bestellungen problemlos löschen.

  2. Der Zähler funktionierte in allen Versionen auch nach vielen Tests mit Löschungen immer einwandfrei, egal ob Demo oder Produktivmodus.

ME könnte das mit den bekannten Problemmodulen zusammenhängen und/oder Serverleistung (z.B. ein Homeage-Paket ist zu schwach).

13

Hi,
dass mann Bestellungen löschen kann ist klar und die fehlende Serverleitung kann ich ausschließen.

Aktuell habe ich tatsächlich das Paypalmodul in Verdacht, auch wenn es zu den nicht zu den “bekannten” Modulen zählt. Von Problemmodulen zu diesem Problem habe ich noch nichts gehört.
Morgen werde ich den Hersteller des bei mir verbauten Paypalmoduls mal anschreiben.

cya

14

@Firefax,

das ist schon klar - ich meine doch problemlos(!) löschen im Zusammenhang mit dem Zählerproblem.

@mj.kater,

Du schreibst, dass es seit dem Update auf 4.6.x zu solchen Problemen gekommen ist. Updates allein und vor allem mit Modulen ist generell nicht unproblematisch. Wie ist das denn gelaufen von welcher Version X zu welcher Version Y?

Um welches PayPal-Modul geht es denn ganau - habt ihr beide das selbe oder verschiedene?

15

[QUOTE=Mj.Kater;111455]
heute wird für gelöschte bestellungen die nummer nicht zurück gesetzt, es fehlt also eine wenn man die bestellung ganz aus dem admin löscht.

[/QUOTE]

wenn du löschst BEVOR eine neue bestellnummer reinkommt, ist das normal und logisch und schon immer so, kenn ich aus der alten und aus der jetzigen EE auch. also net buggy sondern normal.

16

Bei Version 472 sieht das in [I]/appication/models/oxorder.php[/I] so aus und sollte vom letzten Eintrag dann wohl 1 weiterzählen:


    /**
     * creates counter ident
     *
     * @return String
     */
    protected function _getCounterIdent()
    {
        $sCounterIdent = ( $this->_blSeparateNumbering ) ? 'oxOrder_' . $this->getConfig()->getShopId() : 'oxOrder';
        return $sCounterIdent;
    }
 
    /**
     * Tries to fetch and set next record number in DB. Returns true on success
     *
     * @return bool
     */
    protected function _setNumber()
    {
        $oDb = oxDb::getDb();
        $iCnt = oxNew( 'oxCounter' )->getNext( $this->_getCounterIdent() );
        $sQ = "update oxorder set oxordernr = $iCnt where oxid = ?";
        $blUpdate = ( bool ) $oDb->execute( $sQ, array( $this->getId() ) );
        if ( $blUpdate ) {
            $this->oxorder__oxordernr = new oxField( $iCnt );
        }
        return $blUpdate;
    }
17

Lösung des Problems (Testversion 472):

In der Datenbank Tabelle oxcounters muss die Zahl bei OXCOUNT korrigiert werden. Also z.B. bei einem akuellen Test bei 10 gleich manuell wieder auf 9 zurücksetzen.

[B]oxcounters[/B]

OXIDENT OXCOUNT
oxOrder 10

18

In früheren Versionen wurde von der höchsten vorhandenen Nummer weitergezählt, Bestellnummer und Kundennummer konnte man im Admin entsprechend editieren, um zum Beispiel nicht bei 1 anzufangen, sondern bei 20131000.

Mit der Änderung geht das nicht mehr nur durch Änderungen im Admin, weil der aktuelle Stand in der Datenbank bei OXCOUNTER hinterlegt wird.