New Order : #105 - GRJGQFJHW <--

[Shad86]

Guten Morgen,

 

ich habe ein hoffentlich kleines Problem.

Ich habe alle Bestellnummern umgestellt. Ging auch bis jetzt.

Allerdings ist einer Sachbearbeiterin jetzt aufgefallen das in der Mail die wir bekommen, mit Glückwunsch! Shop hat eine neue Bestellung erhalten von ...

 

Darunter steht die Bestell-Nr. GRJGQFJHW

 

Das möchte ich natürlich auch noch in Zahlen gezeigt bekommen.

Im Betreff nimmt er ja noch beides, wo der Buchstabensalat auch weg könnte, mit aber noch egal ist.

Aber in der Mail soll der die richtige Bestellnummer wenigstens wieder davor stellen. Lieber natürlich ganz ersetzen.

Hat jemand ne Ahnung welche Zeile ich in welcher Datei ändern muss?

 

Hoffe auf Hilfe.

[Guest Delte]

Was für eine Variante habt Ihr ?  also bei 1.6.0.9 muss

matürlich auch in mailalaert umgestellt werden.

Wenn nicht geschehen ist .

 

guss

Jürgen

[Shad86]

Hi Jürgen,

 

ja das stimmt tatsächlich.

Ich hatte die ganze Zeit nach den falschen Befehlen gesucht.

'{order_name}' => $order->reference,

muss zu

'{order_name}' => $order->id,

umgeschrieben werden und

sprintf(Mail::l('New order : #%d - %s', $id_lang), $order->id, $order->reference),

zu

sprintf(Mail::l('New order : #%d', $id_lang), $order->id),

um den Buchstabensalat vollkommen raus zu werfen.

Falls jemand genauso sucht wie ich.

[eleazar]

Nur dass es damit nicht getan ist, denn das bezieht sich ja nur auf die Mails!

 

An allen Ecken und Enden müsste diese Änderung dann auch erfolgen, denn z.B. im Kundenbereich wird dem Kunden in der Bestellübersicht natürlich auch nur die reference angezeigt. Deshalb sollte man, wenn überhaupt, bei der Generierung dieses Feldes ansetzen. Wie, kann man hier nachlesen: http://www.prestashop.com/forums/index.php?/topic/229275-gelost-bestell-nr-fur-15x-automatisch-als-nummer-erzeugen/page__fromsearch__1

[Shad86]

Ist richtig und ein sehr guter Link,

 

ich hatte das allerdings alles beim einrichten des Shops geändert. Nur in den Mails ist es übrig geblieben.

Die generierten PDF´s, andere Mails, Kundenbackend, Frontend, überall war es ok. Nur in der Bestellbestätigung nicht.

Dein Weg ist natürlich besser, gleich die Wurzel des Übels an zu greifen. ist in MEINEM Fall aber nicht mehr nötig.

 

Ich hoffe ja noch auf eine PS Version die diese ganzen "Standart Änderungen" die Quasi jeder vor nimmt, gleich schon beinhaltet.

[Guest Delte]

Hollo ich habe hier im Forum dieses gefunden älterer Beitrag:

und dieses eingesetzt:

 

 

In ,classes/order/order.php

 

in Zeile 1499 eingestezt:

 

return Db::getInstance()->getValue('SELECT CONCAT("4",(MAX(id_order)+1)) FROM '._DB_PREFIX_.'orders');

 

/** return strtoupper(Tools::passwdGen(9, 'NO_NUMERIC'));*/

und die

Alte Zeile als Hinweisgesetzt !

 

das funktoniert bei mir sehr gut.

das einzige was nicht gelöst wurde bis jetzt die Jahreszahl hinter der bestellnummer !

mit dieser Zeilewird  die Bestellnummer nummerich in der DB abgelegt in render

und somit brauch man nicht weiteres umstelllen.

 

gruss

Jürgen

Edited December 10, 2014 by nfm-depot (see edit history)

[retric]

Hallo,

ich habe es so gelöst:

/classes/order/order.php

Zeile 1499:
 

return strtoupper(Tools::passwdGen(9, 'NO_NUMERIC'));

ersetzt durch:

 

return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),CONCAT("-",YEAR(invoice_date))) FROM '._DB_PREFIX_.'orders');

Ausgabe bei Bestellnr. 1 = 1-2014 (wobei "-" ersetzt werden kann durch anderen Wert)
Ausgabe bei Bestellnr. 2 = 2-2014 usw...

Die neue Bestellnummer zieht sich duch den ganzen Shop durch, alle Mails, BO, etc.

Gruss
Josi

 

PS 1.6.0.9

[Guest Delte]

Ja das ist super ich hatte auch schon so in dieser Richtung gearbeitet da ich kein Programierer bin felhte mir

die richtige umsetzung.

Hmmm invoice_date ist das Rechnungs Datum oder ?

das ist in der DB 0000......

Ich habe es mit date_add gemacht das geht , steht dann auch 2014

geht das auch als nur 14   ?

So währe das sehr schön

12578/14

und ohne das man sich drum kümmern muss

dann im nächten Jahr

25678/15

 

 

gruss

Juergen

Edited December 12, 2014 by nfm-depot (see edit history)

[Mutabor]

@retric und mfm-depot

 

Aber ihr seid euch hoffentlich darüber im Klaren, dass sowohl "invoice_date" wie auch"date_add" hier nicht das Rechnungsjahr der aktuellen Bestellung auswerfen, sondern nur Werte, die zufällig stimmen?

Da könnte nämlich genauso 2011 stehen, je nachdem, welches Datum die erste Bestellung in der Datenbank hat.

Edited December 12, 2014 by Mutabor (see edit history)

[Guest Delte]

So nach langen suchen kann habe ich zwei Lösungen:

#1:{
         return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),CONCAT("/",SUBSTRING(YEAR(date_add) ,3,2))) FROM '._DB_PREFIX_.'orders');
      }

 ist dann 159999/14

#2 :{
         return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),CONCAT("/",YEAR(date_add)-2000 ))) FROM '._DB_PREFIX_.'orders');
      }
 ist dann 159999/14

 

gruss

Jürgen

Edited December 17, 2014 by nfm-depot (see edit history)

[Mutabor]

Trotzdem ist nur die Jahreszahl der ersten gefundenen Bestellung in der Datenbank. Das würdest du spätestens dann merken, wenn du mal das komplette Datum anhängen und dir dann die Mail ansehen würdest. Oder du erst bis zum nnächsten Jahr und wundert dich, warum da immer noch 14 steht.

[Guest Delte]

Na ja das ist ja nicht mehr weit .....

aber warum soll in der DB ps_orders , denn das ist ja date_add fiktiv sein ????

in der DB ps_orders steht unter date-add das "order-Datum" ???

bei mir steht 2014-12-17 13:40:30

 

wenn das so ist

dann mach mal bitte ein Lösungs Vorschlag....

wird für ein gestandenen Programierer ja nich schwer sein

das so zumachen das man da das Datum bekommt

und die Gemeinde ist glücklich

[Mutabor]

wenn das so ist

dann mach mal bitte ein Lösungs Vorschlag....

wird für ein gestandenen Programierer ja nich schwer sein

das so zumachen das man da das Datum bekommt

und die Gemeinde ist glücklich

 

Woraus schließt du, dass es so einfach ist? Ist das wirklich so? Ich glaube nämlich nicht.

 

Wie gesagt, im Moment kann ich nur sagen, daß deine Lösung wohl nicht funktioniert. Ich sehe aber auch für mich aktuell keine Notwendigkeit, stundenlang ein Problem zu wälzen und möglicherweise in diversen Programmteilen Änderungen zu machen, weil ich diese Variante der Bestellnummer nicht mal einsetzen würde.

 

Tut mir leid! Vielleicht findet sich da jemand anders, dem genau das unter den Nägeln brennt.

[Guest Delte]

Na ja wenn Ihr meint ...........

jeden das seine

wenn der Jahres wechsel geschehen ist sehne wir es ja !

ich will keine abdfghjiklqwtzuy Bestellnummer hat nur den Vorteil das keine sehen kann

vieviel wirklich gelaufen ist.

[eleazar]

So nach langen suchen kann habe ich zwei Lösungen:

#1:{

         return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),CONCAT("/",SUBSTRING(YEAR(date_add) ,3,2))) FROM '._DB_PREFIX_.'orders');

      }

 ist dann 159999/14

#2 :{

         return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),CONCAT("/",YEAR(date_add)-2000 ))) FROM '._DB_PREFIX_.'orders');

      }

 ist dann 159999/14

 

gruss

Jürgen

 

Hast du das eigentlich in dieser Form mal ausprobiert, Jürgen?

 

Bei Prestashop 1.5 z.B. führt der zweite CONCAT-Befehl nur dazu, dass überhaupt keine Referenz erzeugt wird und damit das Feld Reference (Bestell-Nr) in der Datenbank leer bleibt. Kann ja auch gar nicht anders sein, da date_add ein kombiniertes Datums- und Zeitfeld ist. Von dem durch YEAR(date_add) erzeugten String kann man nicht einfach 2000 subtrahieren.

 

Der erste liefert mir am Ende eine /12.

 

Bei 1.6 habe ich das noch nicht getestet.

Edited December 18, 2014 by eleazar (see edit history)

[Guest Delte]

 Oh ich bitte vielmals um etschuldigung ich habe eine Klammer geschlabert !!

 

return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),CONCAT("/",(YEAR(date_add)-2000))) FROM '._DB_PREFIX_.'orders');

 

Das habe ich eben aus probiert es funktoniet !

Also ich habe nen 1.6.09. und bei mir fuktoniert jetzt sowohl mit den -2ooo als auch die andere Form

habe die DB ps_order kontroliert  und dort wird unter render diese eingetragen.

Es kann natürlich sein das dass bei einer anderen variante so nicht geht.

Die Befehlzeile besagt:

(MAX " imale" (id-order) "letzte id " +1 ), ( " /" nacht den Querstrich  kann auch - + eine Zahl nehmen  Subspring

den DB eintrag (date_add) ,3,2 ) formelier aus den Subspring das Jahr zweistellig. soweit sind  wir uns doch einig sein   ?

 

Was noch zu klähren ist ob der Jahreswechsel funktioniert aber das ist ja nicht mehr weit.

 

hab Ihr den in der dementsprechenden  DB die Spalte date_add ?

es gibt auch den SQL Befehl  DATE_ADD der wir gross geschrieben ????

nicht das bei euch das als DATE_ADD interpretiert wird

und ein fiktieves Datum erzeug wird würde die "12" erklähren.

Natürlich währe die sauberste Lösung dierekt per Date das Datum zweistellig zu erzeugen

und dann im render einzutragen.

 

Ps ein schöner austausch

 

 

Gruss

Jürgen

 

 

 

 

 

 

 

 

 

Edited December 19, 2014 by nfm-depot (see edit history)

[eleazar]

Ja, aber all das ändert nichts daran, dass es so, wie du glaubst nicht funktioniert - auch nicht in 1.6.0.9! Und zwar, wie schon von Mutabor angesprochen, weil ein Zufallswert (i. d. Regel die erste Bestellung in der Datenbank) für date_add herangezogen wird.

 

Das merkst du spätestens dann, wenn du den vollen Wert einsetzt, und nicht nur die Jahreangabe abfragst. In der Bestätigungsmail wird der nämlich dann komplett angezeigt. Dann tritt dein Denkfehler offen zutage.

 

Aber es geht mit einer kleinen Erweiterung, indem man das letzte Datum abfragt:
 

return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),"/",(YEAR(MAX(date_add))-2000)) FROM '._DB_PREFIX_.'orders');

Oder auch:
 

return Db::getInstance()->getValue('SELECT CONCAT((MAX(id_order)+1),"/",SUBSTRING(YEAR(MAX(date_add)) ,3,2)) FROM '._DB_PREFIX_.'orders');

So macht dir auch der Jahreswechsel keine Probleme mehr.

Edited December 19, 2014 by eleazar (see edit history)

[Guest Delte]

Etschuldigung lese ich falsch das ist doch das was ich geschrieben habe

oder sehe ich den Wald vor Bäumen nicht ?

bitte mal das rot machen was anders ist

 

Dankeeeeeeee

 

Gruss

Jürgen

[Guest Delte]

ok erledig es ist das MAX.....

Mal sehen was zu Jahreswchsel raus kommt

 

gruss

Jürgen

[Guest Delte]

So nun hatten wir den Jahreswechsel....

Also mit Max ist es auch nicht richtig !

So wie ich es sehe wird das letzte

Datum abgefragt das ist ja im 2014

also bleibt bei der ersten bestellung in 2015 auf "14"

die darauf folgende hat dann "15"

also bleibt nur der Weg über das Datum !

Aber wo zum Teufel wird das Datum in date_add

erzeugt ?

von der DB selber ? oder wo ?

 

 

 

gruss Jürgen

Edited January 1, 2015 by nfm-depot (see edit history)

[eleazar]

Hättest du mehr als einen Versuch unternommen, wäre dir die kleine Unsauberkeit des PHP-Arguments vielleicht selbst aufgefallen.

 

Ich hatte auch nicht daran gedacht, obwohl es ja eigentlich logisch ist. Die hier geposteten Lösungen funktionieren durchaus - nur nicht ...  ganz richtig. Und zwar deshalb, weil Prestashop natürlich auf den letzten, aktuell vorhandenen Datensatz zugreift. Das merkt man spätestens dann, wenn man nicht nach dem Jahr, sondern nach der konkreten Zeit fragt.

 

Das ist aber immer die vorletzte Bestellung, denn zum Zeitpunkt des Aufrufs dieser Funktion ist die neue Bestellung in der Datenbank  ja noch gar  nicht vorhanden.

 

Deswegen wird auch während der Zusammensetzung des Strings auf die letzte Bestell-Nr. eine 1 aufaddiert:

getValue('SELECT CONCAT((MAX(id_order)+1) ...

[Guest Delte]

Ja das hatte ich auch vermutet........

nun ja .......

 

Da muss man was ganz anderes bauen

weiss noch nicht wie...

 

 

gruss

Juergen