Generierung von Bestellnummern

[Scarabeus]

Hallo,

ich bin gerade dabei eine Shop-System zu implementieren, was meinen Anforderungen genügt. Dabei bin ich auch das Problem bzw. die Herausforderung gestossen Bestellnummern bzw. Rechnungsnummern zu generieren.
Der Punkt ist, dass ich nicht nur eine laufende Nummer als Bestellnummer haben möchte, weil das ja irgendwie doof aussieht, wenn der erste Kunde eine Bestellnummer '1' hat. Wirkt vielleicht nicht sehr proffesionell.

Somit wollte ich mal Fragen ob ihr Vorschläge habt, für die Umsetzung dieser Funktionalität bzw. wie die Struktur einer Bestellnummer ausgebaut sein sollte.

Vielen Dank schon einmal für eure Ideen.
S.

[rbs_phoenix]

Ja wollte auch nur nochmal zum Ausdruck bringen, dass es in meinen Augen sinnlos ist, irgendwelche ID's oder so da reinzuschreiben. Aber Zergling hat ja sowieso immer tolle Vorschläge

[KingCrunch]

ROFL Hat Zergling nahezu exakt so vorgeschlagen Aber schön, wenn jemand mitdenkt Weiter so!

[rbs_phoenix]

Deswegen miene ich ja:
Also ich würde irgend ne Zahl nehmen, die immer um 1 incrementieren und einen Eintrag in einer passen Tabelle mit ALLEN nötigen Infos erstellen, Wenn jemand etwas bestellt.

Also zum beispiel die Zahl 13224542 ist die erste Nummer und ab da wird immer 1 addiert und als neue Auftragsnummer gespeichert... einfach zufällig irgendwas eintippen, das reicht ja. naja ist ja auch egal wie man das macht, aber ich würde das so machen

[Scarabeus]

Aber was ist wenn ein Artikel die Artikelnummer 2134523 hat und es wollen 2 Leute das ding kaufen. Weiß nicht, wozu man dann die UserID in der Artikelnummer gebrauchen kann. Genau wie die OrderID. Oder soll das nicht die Artikelnummer sein, sondern Auftragsnummer???

Es ging um die Bestellnummer/Auftragsnummer (also Benutzerspezifisch)

Wenn es die Auftragsnummer ist, weiß ich nicht warum die UserID und so da drinne stehen müssen. Man muss das doch theoretisch sowieso extra gespeichert werden. Die Auftragsnummer, das genaue Datum+Uhrzeit der Bestellung, Adresse, Zahlungsart, die gewünschten Artikelnummern etc. Ist doch auch blöd wenn das alles da drinne steht und so. Also ich würde irgend ne Zahl nehmen, die immer um 1 incrementieren und einen Eintrag in einer passen Tabelle mit ALLEN nötigen Infos erstellen, Wenn jemand etwas bestellt.

Die zusätzlichen Daten zur ID (laufende Nummer) in der DB wollte ich reinbringen um den benutzer "schönere Nummer" auszugeben.
Also für Benutzer 1 - 3 nicht die folgenden:
1 oder 00000001
2 oder 00000002
3 oder 00000003

Eine mögliche Lösung wäre es andere Variablen (z.B. UserID) mit reinzubringen oder die BestellIDs schon mit einer höheren ID zu beginnen.
Also beispielsweise 24618001.

[rbs_phoenix]

Hmm... Also bei vielen Artikelnummern sind ja auch "-" drinne. Z.B. bei Conrad. Dann könnte man das doch als Trennzeichen nehmen.
Aber was ist wenn ein Artikel die Artikelnummer 2134523 hat und es wollen 2 Leute das ding kaufen. Weiß nicht, wozu man dann die UserID in der Artikelnummer gebrauchen kann. Genau wie die OrderID. Oder soll das nicht die Artikelnummer sein, sondern Auftragsnummer???

Wenn es die Auftragsnummer ist, weiß ich nicht warum die UserID und so da drinne stehen müssen. Man muss das doch theoretisch sowieso extra gespeichert werden. Die Auftragsnummer, das genaue Datum+Uhrzeit der Bestellung, Adresse, Zahlungsart, die gewünschten Artikelnummern etc. Ist doch auch blöd wenn das alles da drinne steht und so. Also ich würde irgend ne Zahl nehmen, die immer um 1 incrementieren und einen Eintrag in einer passen Tabelle mit ALLEN nötigen Infos erstellen, Wenn jemand etwas bestellt.

[Scarabeus]

OK. Danke nochmal für's Storming in the Brain!

[KingCrunch]

Und wenn scho: Da bekommt halt irgendwer ne Rechnungsnummer "1" oder "00001". Irgendwann muss nen Shop ja anfangen, das weiß der Besucher auch. Insofern wird ne Rechnungsnummer "1" auch nicht sooo ungewöhnlich sein

Alternativ ganz freakig: Nimm Unix-Timestamp

[Zergling-new]

Die Idee, die Jahreszahl in die Mitte zu setzen ist auch ganz gut, aber bei näherer Betrachtung wieder fehlerhaft.
Was ist denn wenn plötzlich ein Benutzer/Bestellung mit der ID 2006 oder 2007 oder 2008 auftaucht, oder noch schlimmer, 120079.

12007200756. Ja welches ist denn nun die Jahreszahl? Niemals darfst du aufs Raten angewiesen sein.

Ist doch letztlich sch* egal wie die Rechnungsnummer aussieht, solang sie aus Zahlen besteht und nicht zu lange ist. Von mir aus auch noch ein paar Kontrollbuchstaben oder wenn du mal ganz ausgeflippt bist, nur Buchstaben. Letztlich ist eine Rechnungsnummer ausschließlich dazu da, eine Rechnung und ihre zugehörigen Bestellungen und den Kunden zu identifizieren. Das geht mit einer fortlaufenden Zahl am Besten.

Wir haben einen Wert um 180.000 genommen, aber eine krumme Zahl. 182265. Sowas in der Richtung, ist ja auch bims. Verplemper nur nicht zuviel Zeit für so eine Nichtigkeit =)

[Scarabeus]

Man kann ja fixe und dynamische Zeichzahl kombinieren, dass man erst Datum (oder sowas) voransetzt und alles, was danach kommt ist ... irgendwas anderes ^^ Ne laufende Nummer zB. Das kann dann aber beliebige Länge haben. Userid und Rechnungsid kombinieren wird trotzdem schwierig.

Stimmt mit der Kombination aus mehreren dynamischen Variablen wird es schwierig ohne die Nutzung von Trennungszeichen.

Ich werde wohl einfach vor die BestellungsID (die durch die auto-inc künstlich erhöht wird) die Jahreszahl als Präfix hängen.

[Scarabeus]

(warum aber die $idUser doppelt reinbraten?)

War nen Copy-Paste-Fehler und sollte eigentlich die ID der Lieferadresse enthalten.

Ansonsten hast Du natürlich Recht. Deine Variante ist am einfachsten und beschränkt die Nummer keines Wegs.

Das ist also auch keine sichere Variante. Entweder du reservierst eine bestimmte Zeichenanzahl für jede Information und füllst den Rest mit Nullen auf, oder aber du verwendest ein Trennzeichen

Dem könnte man entgegenwirken indem mal die 3 Variablen wie folgt zusammensetzt:
year = 2007, userid = 12, orderid = 3 -> 1220073
year = 2007, userid 1, orderid = 23 -> 1200723

Naja. Egal ich werde das wohl einfach lösen. Also die auto-inc Lösung.
Bei welche Id habt ihr denn begonnen, um nicht zu klein zu sein aber auch nicht zu groß.

Ansonsten danke für die Beiträge!

[KingCrunch]

Man kann ja fixe und dynamische Zeichzahl kombinieren, dass man erst Datum (oder sowas) voransetzt und alles, was danach kommt ist ... irgendwas anderes ^^ Ne laufende Nummer zB. Das kann dann aber beliebige Länge haben. Userid und Rechnungsid kombinieren wird trotzdem schwierig.

[Zergling-new]

Wie der Name schon sagt, handelt es sich um eine Bestell-/Rechnungs-Nummer, daher ist die Idee mit base64_encode() zwar ganz gut, ich würde allerdings trotzdem darauf verzichten und numerische Werte verwenden.

Die Idee das Jahr und die Kunden-ID einzubauen (warum aber die $idUser doppelt reinbraten?) ist auch ganz gut, aber du musst aufpassen:
year = 2007, userid = 12, orderid = 3 -> 2007123
year = 2007, userid 1, orderid = 23 -> 2007123
Das ist also auch keine sichere Variante. Entweder du reservierst eine bestimmte Zeichenanzahl für jede Information und füllst den Rest mit Nullen auf, oder aber du verwendest ein Trennzeichen
200700120003, 200700010023
2007-12-3, 2007-1-23
Hierbei kommt jetzt aber nicht nur eine unnötig lange Nummer heraus und bei letzterem Beispiel sogar ein nicht durchgehend numerischer Wert, du schränkst auch die Anzahl möglicher User auf eine vierstellige Zahl ein und die Anzahl der Bestellungen sogar auch (das heißt 9999 User können maximal 9999 Bestellungen aufgeben). Selbst wenn du das ganze 5- oder 6-stellig machst, deine Nummer wächst rasant in die Länge, die Anzahl möglicher User und Bestellungen wird beschränkt*. Vielleicht läuft dein Shop ja jahrelang, da kann man mit der Zeit schnell an abertausende von Bestellungen kommen (hoffentlich sogar). Das ist alles in allem unflexibel.

Ohne Eigenlob, finde ich meine Variante die beste im Ergebnis und die einfachste in der Umsetzung. Was will man mehr?!

* = natürlich ist die Anzahl immer beschränkt, auch bei fortlaufenden Zahlen ab 1, aber INT oder BIGINT reicht in der Regel.

[Scarabeus]

@duderino

Du kannst du Bestell-ID (z.B. die 1) einfach mit base64_encode() kodieren.

Wenn ich die base64 codierung einsetze dann bekomme ich für die ID '1' die codierte ID 'MQ'. Und ob das ein vorteil ist. Außerdem habe ich eine Bestellnummer die nur aus Buchstaben besteht noch nie gesehen.


@Zergling

setz den auto_increment-Wert doch einfach beim Erstellen der Tabelle auf eine Rechnungsnummer die dir passt.

Prinzipiell schon mal ne schöne Idee wie mal die laufende ID ein wenig faken kann! Wodurch dem ersten Kunden nicht gleich klar ist, dass er das erste Testkaninchen ist für den Shop...

Vielleicht macht es ja noch Sinn das laufende Jahr, KundenID oder ähnliches einzubauen oder ist das alles nur redundant und bringt nix?

function GenerateOrderNumber ($idUser, $idDeliveryAddress, $idOrder) {
    //$prefix     = '';
    //$suffix     = '';
    //$fillLength = '';
    $year        = date('Y');
    $orderNumber= $year.$idUser.$idUser.$idOrder;
    return $orderNumber;
} 

[Zergling-new]

Hallo,
setz den auto_increment-Wert doch einfach beim Erstellen der Tabelle auf eine Rechnungsnummer die dir passt. Das hatte unseren Ansprüchen damals genügt.