Auf PDF-Rechnungen und -Lieferscheinen wird die Artikelnummer abgeschnitten

Auf PDF-Rechnungen und -Lieferscheinen wird die Artikelnummer abgeschnitten.

Kann jemand dieses verhalten nachstellen? Wie kann es behoben werden?

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍

Hinweis: Es handelt sich um eine Bestellung eines Produktes mit Varianten.

Produktnummer (Varinate) eigentlich:

180019-T100-dankeschoen

Er macht daraus in den Dokumenten 180019-T1

Hallo,

die Artikelnummer wird auf den PDF - Dokumenten automatisch nach 10 Stellen abgeschnitten, siehe: https://github.com/shopware/platform/blob/master/src/Core/Framework/Resources/views/documents/base.html.twig#L173 . Wenn man das Verhalten bei sich ändern möchte, muss man dies in einem eigenen (Theme-)Plugin tun, so wie auch schon in Shopware 5: https://docs.shopware.com/de/shopware-6-de/tutorials-und-faq/aenderungen-am-template-vornehmen?category=shopware-6-de/tutorials-und-faq#anpassungen-am-dokumenten-template .

Grüße

Sebastian

Erst einmal danke für den konkreten Hinweis, dann passen wir das an.

Aber: Echt jetzt? Den Sinn hinter dem Kürzen verstehe ich nicht.

Siehe dazu noch dieser Post, sonst bleibt man gleich wieder stecken: https://forum.shopware.com/discussion/64775/dokumenten-template

Hallo, 

muss diesen Thread leider reaktivieren. Ich kriege das Problem mit den abgeschnittenen Produktnummern einfach nicht gelöst… Ich habe mir den weiterführenden Thread schon reingezogen. Tatsächlich habe ich sogar schon viele Änderungen am document/base.html.twig-Template über eine entsprechende Datei in meinem Theme-Plugin extended. Footerzeile, Kopfzeile, erweiterte Hinweise nach der Aufstellung, hat alles wunderbar geklappt.

Allerdings will der bei mir nicht die Änderung von “truncate(10)” auf “truncate(20)” schlucken! Cache hart löschen (rm -rf * im Cache-Ordner) hilft bei testweisem Nachvollziehen, dass Änderungen überhaupt übernommen werden. Er will es einfach nicht annehmen… dabei will ich nur einen Twig-Block wie die anderen auch überschreiben. 

Wie hast du das gelöst @sschreier‍ ? [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍ … hast du ne Ahnung? Ich meine, es ist ganz klar die richtige Stelle, die ich modifiziere. Hab schon mehrfach andere Stellen geändert und getestet, um mich in dem Template zu orientieren. Er will irgendwie nicht diesen einen ganz bestimmten Block überschreiben!

{% block document_line_item_table_row_product_number %}
   {% if lineItem.payload.productNumber %}
       TEST TEST {{ lineItem.payload.productNumber | u.truncate(20) }}
   {% else %}
       TEST
   {% endif %}
{% endblock %}

Ich hab auch schon im CSS für die Dokumente geschaut, aber sehe da keine Größeneinschränkung der entsprechenden Tabellen-Zellen. 

Ich check’s einfach nicht!

Hab jetzt nochmal getestet, ob sich überhaupt was ändert, wenn ich in der Core-Datei (/vendor/shopware/core/Framework/Resources/views/documents/base.html.twig) die Produktnummer auf 3 Zeichen kürzen will… Cache gelöscht. Keine Auswirkung. Das Ding bleibt stur bei 10 Stellen! Was ist das? Ich bin schon extra in die PHP Objektdefinitionen für lineItem (siehe Kommentar @var) gegangen, um zu schauen, ob da irgendwas los ist, aber das sieht alles einwandfrei aus!

{% block document_line_item_table_iterator %}
    {# @var lineItem \Shopware\Core\Checkout\Order\Aggregate\OrderLineItem\OrderLineItemEntity #}
    {% for lineItem in lineItemPage %}
        
            {% block document_line_item_table_rows %}
                {% block document_line_item_table_row_position %}
                    {% if config.displayLineItemPosition %}
                        {{ loop.index }}
                    {% endif %}
                {% endblock %}

                {% block document_line_item_table_row_product_number %}
                    {% if lineItem.payload.productNumber %}
                        {{ lineItem.payload.productNumber | u.truncate(3) }}
                    {% else %}
                        
                    {% endif %}
                {% endblock %}
                
                ...
                ...
                ...

Hi, vermutlich hast du 

bin/console cache:clear
bin/console theme:compile

auch schon probiert?

Nimmt er auch deine Änderungen mit

"TEST TEST"

nicht an?

Mfg
1 Like

Nutz die Vorschau bei den Dokumenten - sobald ein Dokument einmal generiert wurde, ändert sich die Ausgabe nicht mehr. Die müssen ja Revisionssicher sein. Es wird sich also nach dem “generieren” nicht mehr ändern. Dafür müsstest du die Vorschau der Generierung nutzen.

Nach den Änderungen muss der Twig-Cache geleert werden, am besten über php bin/console cache:clear

Hier ist auch ein Beispiel bei dem ich die Dokumente angepasst habe, läuft fehlerfrei: SwagDocumentTemplate/base.html.twig at master · mnaczenski/SwagDocumentTemplate · GitHub

1 Like

Hallo, 

danke für die Antworten! theme:compile hab ich nicht gemacht, da das bei Twig-Templates erfahrungsgemäß nicht nötig ist!? cache:clear natürlich schon. Und ich benutze auch die Vorschaufunktion, um immer wieder neu zu generieren, klappt auch mit anderen Änderungen.

Und ja @ozv‍ ,selbst den Test-Text spuckt er mir nicht aus. In anderen Bereichen des Dokuments geht alles, nur dort irgendwie nicht. Ich hab auch schon nochmal alle Originaldateien dreifach gegengecheckt, um sicherzustellen, dass die Blocknamen übereinstimmen. Klappt einfach nicht! :confused:

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍: Die von dir markierte Zeile 17 bezieht sich auf den Spaltenkopf, nicht das Line-Item selber. Ich meine diesen Block hier: SwagDocumentTemplate/base.html.twig at master · mnaczenski/SwagDocumentTemplate · GitHub

Der reagiert leider nicht. Ich hab das Gefühl, das könnte mit dem Line-Item-Iterator zusammenhängen. Ich bin echt irritiert! :smiley:

Ich mach die Änderungen ja auch extra in alle 4 Doc-Templates rein, weil ich die Subtemplates, die auf der base.html.twig extenden, nicht einfach direkt auf meine @Plugin/document/base.html.twig verweisen kann, da sonst die Generierung nicht klappt und der Apache-Prozess den Server auslastet bis der Script-Timeout oder Out of Memory greift.

Wäre cool, wenn es möglich wäre, dass einer von euch das mal testet. Wenn es klappt, frag ich mich, was an meiner Installation anders sein mag. Ich bin auf jeden Fall auf dem vorletzten Versionsstand (6.3.1). Das Update von vor 2 Tagen ist aber ja auch hauptsächlich Security und hatte im Changelog keine relevanten Hinweise bezüglich meiner Problematik.

Vielen Dank für eure Mühe und Mitwirkung!

Gruß

Martin

Hi!

Bei mir klappt es problemlos.

Sowohl wenn ich die Änderung im Core-File mache als auch in der eigenen Extension überschreibe. 
Mit der Extension von Moritz klappt es auch auf Anhieb.

Kann es bei dir eventuell am Browsercache liegen?

Meine Vorgehensweise: Template ändern => “bin/console cache:clear” => Bestellung auswählen => Belege => “Neu erstellen” => “Lieferschein” => “Vorschau”

Mfg

 

 

1 Like

Das ist sehr strange… ich probiere mal weiter.

Hallo, ich hänge gerade an dem exakt gleichen Problem. Hast du das schon lösen können @MartinSerdar‍?

@DavidS schrieb:

Hallo, ich hänge gerade an dem exakt gleichen Problem. Hast du das schon lösen können @MartinSerdar‍?

Moin, leider nicht. Der direkte SW-Support will mir auch erzählen, dass ich dafür einen Entwickler engagieren soll, weil man sich um sowas nicht kümmern würde, während ein anderer Supporter mit mir in die Eingeweide geht. Ich hab den Eindruck, dass die Nummern schon bei der Erstellung des Arrays abgekürzt werden, was zwar überhaupt keinen Sinn macht, aber wir sind natürlich auch ziemlich verrückt, Produktnummern über 10 Zeichen Länge zu verwenden. Da sollten wir uns schon selbst fragen, was wir uns dabei denken ;)))) 

@MartinSerdar schrieb:

@DavidS schrieb:

Hallo, ich hänge gerade an dem exakt gleichen Problem. Hast du das schon lösen können @MartinSerdar‍?

Moin, leider nicht. Der direkte SW-Support will mir auch erzählen, dass ich dafür einen Entwickler engagieren soll, weil man sich um sowas nicht kümmern würde, während ein anderer Supporter mit mir in die Eingeweide geht. Ich hab den Eindruck, dass die Nummern schon bei der Erstellung des Arrays abgekürzt werden, was zwar überhaupt keinen Sinn macht, aber wir sind natürlich auch ziemlich verrückt, Produktnummern über 10 Zeichen Länge zu verwenden. Da sollten wir uns schon selbst fragen, was wir uns dabei denken ;)))) 

10 Tage später. Hast du vielleicht ne Lösung gefunden?

@MartinSerdar‍

Der Support hilft dir bei der Bedienung und Konfiguration des Produktes, nicht bei der individualisierung (bspw. bei Template-Anpassungen). Die können dir einen Verbesserungsvorschlag im Issuetracker anlegen, damit wir die Begrenzung im Core entfernen, abber keine individuelle Lösung dafür anbieten.

Die Lösung steht fernab davon auch hier im Thread - gerade nochmal probiert:

{% sw_extends '@Framework/documents/base.html.twig' %}

{% block document_line_item_table_row_product_number %}
    {% if lineItem.payload.productNumber %}
        {{ lineItem.payload.productNumber }}
    {% else %}
        
    {% endif %}
{% endblock %}

 

Funktioniert direkt und lässt sich rein über das Template realisieren. Habe dir das extra auch nochmal als Branch hier hin gepackt: GitHub - mnaczenski/SwagDocumentTemplate at remove-truncate

@MartinSerdar schrieb:

@MartinSerdar schrieb:

@DavidS schrieb:

Hallo, ich hänge gerade an dem exakt gleichen Problem. Hast du das schon lösen können @MartinSerdar‍?

Moin, leider nicht. Der direkte SW-Support will mir auch erzählen, dass ich dafür einen Entwickler engagieren soll, weil man sich um sowas nicht kümmern würde, während ein anderer Supporter mit mir in die Eingeweide geht. Ich hab den Eindruck, dass die Nummern schon bei der Erstellung des Arrays abgekürzt werden, was zwar überhaupt keinen Sinn macht, aber wir sind natürlich auch ziemlich verrückt, Produktnummern über 10 Zeichen Länge zu verwenden. Da sollten wir uns schon selbst fragen, was wir uns dabei denken ;)))) 

10 Tage später. Hast du vielleicht ne Lösung gefunden?

Wir haben nun das Problem hierbei gefunden, was eigentlich offensichtlich sein sollte. Ein anderes Plugin überschreibt bereits die Dokumente und hat diese Artikelnummer-Kürzung auch beibehalten. Bei uns ist es das Shopware Plugin Custom Products. Als ich dort die Twig Daten angepasst habe, um zu schauen, ob es etwas bewirkt, hat dies auch geklappt.

Wie gesagt, eigentlich offensichtlich, aber darauf gekommen sind wir leider vorher nicht.