Neu Nach Update 5.5.0 viele Nullen bei den Mengenangaben in der Bestellbestätigung

[kutti]

Ich habe gerade geupdatet und eine Probebestellung durchgeführt. Es viel mir gleich auf das in der Bestellbestätigung irreführende Mengenangaben zu sehen sind. Kann man das irgendwo einstellen, das die ganzen Nullen verschwinden?
Bild anbei

 

[Rainer S]

Die Anzeige kannst du ändern indem du hinter nAnzahl |round:0 einfügst bei der Bestellbestätigung, ich hänge mal einen Screenshot an. Wenn du mehrere Sprachen nutzt dann muss das bei allen Sprachen durchgeführt werden.

 

[jitka001]

Hallo,

bei mir hilft diese Maßnahme nicht... Bitte um Hilfe. Vorlage habe ich zurückgesetzt und dan bei alle Sprachen das "|round:0" eingefügt, Cache gelöscht. Immer noch Stückzahl 1.0000

LG Jitka

 

[kutti]

Hallo,

bei mir hilft diese Maßnahme nicht... Bitte um Hilfe. Vorlage habe ich zurückgesetzt und dan bei alle Sprachen das "|round:0" eingefügt, Cache gelöscht. Immer noch Stückzahl 1.0000

LG Jitka

Du musst es an zwei Stellen ändern, einmal im Text (Inhalt) und einmal im PHP.
Bin ich auch erst später drauf gekommen, als es bei mir nicht funktionierte.

 

[uzdor]

@kutti
Wäre jetzt noch nett und schön, für nicht ganz so fitte User WO im PHP da noch was zu ändern ist. Dann wäre mir sehr geholfen, weil ich dieses Problem auch habe.

 

[kutti]

@kutti
Wäre jetzt noch nett und schön, für nicht ganz so fitte User WO im PHP da noch was zu ändern ist. Dann wäre mir sehr geholfen, weil ich dieses Problem auch habe.

siehe Bild

 

[Rayblaster]

Die Anzeige kannst du ändern indem du hinter nAnzahl |round:0 einfügst bei der Bestellbestätigung, ich hänge mal einen Screenshot an. Wenn du mehrere Sprachen nutzt dann muss das bei allen Sprachen durchgeführt werden.

Vielen Dank.
Warum wurde das eigentlich geändert?
So wie es aussieht wollen wohl viele eher wieder die Zahl ohne Kommastellen

 

[FelixG]

Die Lösung mit dem |round:0 funktioniert nur leider nicht, wenn man teilbare Artikel hat. Dann wird da einfach aus 0,5 = 1.

Mit |string_format:"%.10g" werden einfach immer nur die benötigten Nachkommastellen eingefügt.

 

[Dee]

Warum das in der neuen Version geändert wird, ohne dem Kunden im Backend eine einfache Einstellungsmöglichkeit anzubieten, kann ich nicht nachvollziehen.
Ich möchte als Laie nicht ständig selbst irgendwo rumpfuschen bzw. mit solchen Lappalien einen Service-Dienstleister beauftragen müssen.

Bei einer Bezahlsoftware kann man doch durchaus erwarten, dass der Anbieter das entweder a) vernünftig löst oder b) eine kundenfreundliche Einstellungsmöglichkeit zulässt.
Selbiges gilt auch für das immer noch bestehende Problem bei "Aufträge zusammenführen", welches auch erst in der neuen Version aufgetreten ist.

 

[uzdor]

@Dee
100% deiner Meinung!
Es geht allerdings noch weiter: Keine vernünftige DOKU über die Änderung, so dass es auch Leute mitbekommen die nicht ständig im Forum unterwegs sind. Dann kannst du froh sein, wenn du Support hast. Ich bin im Paket unter dem Advanced und habe Support NUR hier im Forum. Wäre kein Problem, wenn das Forum noch so wäre wie zu Lissonszeiten. Da wurde dir noch geholfen.

Gut, wird wie hier in dem Faden auch, aber es ist Frickelei und wie bei den teilbaren Artikeln wieder nicht praktikabel. Also, wie du sagst rumpfuschen und für diese Lapalien direkt wieder einen Service-Dienstleister beauftragen, der sich ob der Fehler vor lachen den Bauch hält. Ich weiß nicht was JTL will. Nur noch Großkunden mit Großpaketen um möglichst schnell die 200xMillionen wieder reinzubekommen??
Würde ich mit dem Geschäft anfangen und nicht, wie ich gerade überlege demnächst umsatteln oder schließen, würde ich über ein anderes System nachdenken, wie es offensichtlich viele der einst sehr aktiven Community inzwischen sicher gemacht haben.

 

[NoOne]

Das war sicherlich auch keine beabsichtigte Änderung. Ist ja mittlerweile als Bug aufgenommen und soll in der 5.5.2 gefixt werden: https://issues.jtl-software.de/issues/SHOP-8777

Der Fehler könnte z. B. hierher kommen: https://issues.jtl-software.de/issues/SHOP-8616
Dass fälschlicherweise mehr Nachkommastellen angezeigt werden, ist weniger schlimm als ein 500er-Fehler.

Und wie etwas weiter oben steht:

Mit |string_format:"%.10g" werden einfach immer nur die benötigten Nachkommastellen eingefügt.

In der Bestellvorlage was ändern ist keine "Frickelei". Das geht im Backend, da muss man nichts im Shop-Code für austauschen. Einfach nur beide Vorkommen von {$Position->nAnzahl} mit {$Position->nAnzahl|string_format:"%.10g"} ersetzen. Oder auf 5.5.2 warten.

Über neu auftretende Bugs gibts nirgendwo Dokus, bis die entweder in einem Forum, oder in einem Issue-Tracker festgehalten werden. Das ist nirgendwo anders.

 

[uzdor]

@NoOne
Jedem seine Meinung. Wie du aus meinem Anmeldedatum erkennen kannst, bin ich schon ein paar Jährchen bei JTL und mein Hinweis mit der Frickelei (überlege gerade, ob ich mir den Schuh aus deinem Post anziehen soll)
bezieht sich auf die Zeiten, wo sehr wohl dokumentiert wurde und Fehler im Code schnellstmöglich bearbeitet wurden. Ganz besonders bei nichtbeabsichtigten Bugs, die selbstverständlich immer auftreten können und konnten.
Für mich ist eine Codeänderung in der Bestellvorlage sehr wohl Frickelei, aber das kann ja gerne jeder anders sehen, denn die Wege sind unterschiedlich die Fehler zu beseitigen, wie es auch die Fertigkeiten und das Wissen der User betriff. Was für den einen ein Klacks ist, ist für den anderen ein Kraftakt. Bei mir reichte eine winzige Änderung die weiter oben gepostet wurde, was bei einem anderen Kollegen nicht ausreichte. Und ja, neu auftretende Bugs werden heute nicht mehr unbedingt dokumentiert, da gebe ich dir recht. Aber auch das war bei JTL vor nicht allzulanger Zeit noch üblich und hat sich eben geändert............

 

[NoOne]

Man kann neu auftretende Bugs nicht dokumentieren, bevor sie auftreten. Und man kann sie nicht fixen, bevor sie bekannt sind. Das konnte man noch nie.

 

[uzdor]

Man kann neu auftretende Bugs nicht dokumentieren, bevor sie auftreten. Und man kann sie nicht fixen, bevor sie bekannt sind. Das konnte man noch nie.

Hab ich auch nie bestritten. Was man aber mal konnte, war von Seiten der Programmierer/Codeschreiber von JTL und der versierten Community schnell auf Probleme reagieren und zumindest einen Workarround dafür bereit zu stellen. Das funktionierte hier UND bei JTL vor Jahren mal excellent.

 

[NoOne]

Öh... Der Workaround ist doch da? Bzw. eigentlich ein Hotfix und das Problem wird mit 5.5.2 gelöst. Oder ist zumindest dafür geplant. Und ich hab auch schon größere Hotfixes zur Verfügung gestellt im Forum. Wenn man dann solche Aussagen liest, kann einem allerdings die Lust daran vergehen.

 

[SebiW]

Finde auch, schlechtes Beispiel, tatsächlich gibts hier zumindest ne Lösung. Leider gibts derzeit so viele andere Baustellen...

 

[Traumpixel]

Ich habe das Problem mit einem Hotfix gelöst, indem ich in /includes/src/Checkout/Bestellung.php innerhalb der foreach-Schleife ab Zeile 402 folgenden HOTFIX hinzugefügt habe:

foreach ($this->Positionen as $item) {
    $item->kArtikel            = (int)$item->kArtikel;
    $item->nPosTyp             = (int)$item->nPosTyp;
    $item->kWarenkorbPos       = (int)$item->kWarenkorbPos;
    $item->kVersandklasse      = (int)$item->kVersandklasse;
    $item->kKonfigitem         = (int)$item->kKonfigitem;
    $item->kBestellpos         = (int)$item->kBestellpos;
    $item->nLongestMinDelivery = (int)$item->nLongestMinDelivery;
    $item->nLongestMaxDelivery = (int)$item->nLongestMaxDelivery;

    // HOTFIX für Nachkommastellen
    $item->nAnzahl = ($item->nAnzahl == (int)$item->nAnzahl) ? (int)$item->nAnzahl : (float)$item->nAnzahl;

Damit erscheinen die unnötigen Nullen im gesamten Shopsystem nicht mehr. Funktioniert sowohl bei ganzen Stückzahlen als auch bei Mengen mit Dezimalstellen.

Vielleicht hilft es ja jemandem auch weiter, bis ein offizielles Update verfügbar ist.

Liebe Grüße