Neu Gutscheine für JTL Shop 4

[SteinSchleuder]

Das heißt, wie im Screen dargestellt wäre alles korrekt?

 

[css-umsetzung]

Sieht auf den ersten Blick alles gut aus

 

[SteinSchleuder]

Vielen Dank. Es ist alles so weit eingerichtet und die Vorlage sieht auch gut aus.
Kann es sein, dass ich in der Konfiguration für die Felder keine Schriftart einstellen kann. Arial will bei uns nicht wirklich passen.
Ansonsten kommt dann gleich die Bestellung von mir.

 

[css-umsetzung]

Ansonsten kommt dann gleich die Bestellung von mir.

Das hört sich gut an

wenn man per ftp eigene "ttf" Fonts hochlädt, dann sind die in den Vorlagen vorhanden um sie zu konfigurieren.

das Verzeichnis für die fonts, ist im Webspace mediafiles/voucher-fonts/
der arial.ttf Font sollte da bereits liegen.

 

[JulianeH]

Hallo zusammen,
funktioniert das Plugin schon mit dem 5.5er Shop?
Schöne Grüße!

 

[css-umsetzung]

Ja, allerdings sollte das error_reporting in der config Datei vom Shop deaktiviert sein, sonst könnten deprecated Meldungen die Funktionsweise stören.

Update ist "noch" nicht ganz abgeschlossen.

 

[JulianeH]

Ja, allerdings sollte das error_reporting in der config Datei vom Shop deaktiviert sein, sonst könnten deprecated Meldungen die Funktionsweise stören.

Update ist "noch" nicht ganz abgeschlossen.

super, danke für die schnelle Antwort!

 

[KATTUN]

Mal wieder eine steuerliche Frage:
Wir spielen die Gutscheinzahlungen über JTL2Datev aus. Dafür benutzen wir das Konto 3786. Das ist das Mehrzweckgutschein-Konto beim Steuerberater.
Folgendes Problem besteht aktuell:
Wenn ein Kunde den Auftrag komplett mit dem Gutschein bezahlt wird die Zahlungsart CSS-Gutschein mit dem Konto 3786 beim Auftrag angelegt. Das ist so korrekt.
Wenn ein Kunde einen Gutschein einlöst und noch mit einer anderen Zahlungsart wie PayPal oder Vorkasse dazu bezahlt wir eine Zahlung mit z.B. PayPal angelegt und eine Zahlung CSS-Gutschein, allerdings wird der Gutschein-Zahlung nicht 3786, sondern das Konto aus der zusätzlichen Zahlungsart zugewiesen.
Ich muss also im Anschluss alle Gutschein-Zahlungen bei gemischten Zahlungen bei Auftrag-Zahlung löschen und neu anlegen mit dem richtigen Konto. Das ist natürlich mühselig.

Wie macht ihr das denn?

 

[css-umsetzung]

Es gibt ein neues Update, um die Kompatibilität zu Shop 5.5.x und PHP 8.4 herzustellen.
Das Plugin ist nur in meinem Shop erhältlich und kann ab sofort heruntergeladen werden.
https://css-umsetzung.de/shop/CSS-Gutschein


Folgende Dinge wurden verbessert, bzw. hinzugefügt:

####[2.7.0] / 04.07.2025
* Freigabe für PHP 8.4
* Kompatibilität zu Shop 5.5 hergestellt
* Leistungsoptimierung im Backend, wenn die Menge der Gutscheine extrem hoch ist.
* Bug in der Auswahl der Gutscheinvorlage im Backend, beim Anlegen eines neuen Gutscheines behoben
* Bug in der Anzeige der Standard Vorlage (Stern) behoben.
* Der Restwert kann nun auch auf null gesetzt werden.
* Achtung, ab PHP 8.2 möglich: (Beta) Emoji Unterstützung, Emojis können wahlweise aktiviert werden,
  Emojis können nur einfarbig dargestellt werden, in PHP Versionen unter 8.2 ist das aktivieren der Emojis nicht möglich, Emojis werden bei der Texteingabe gefiltert.

Eine Besonderheit, bzw. ein oft gewünschtes Feature ist:

 

[konzentrat]

Hallo zusammen
Da io.php seit Shop Version 5.4. entfernt wurde ist die Verbindung zu dieser Datei auch nicht mehr via LS-POS möglich. Kennt jemand die neue URL? Kann dies in keiner Dokumentation finden. Luwosoft war auch nicht sicher und ich soll ihnen doch schreiben wenn ich etwas herausgefunden habe...

Die Dateneingabe via QR Code funktioniert übrigens auch nicht.

Edit: Luwosoft hatte mir eigentlich die richtige Antwort gegeben (sie waren aber nicht sicher). Da ich aber den Token auch nochmal manuell einfügen musste (obwohl dieser bereits korrekt dort stand) hatte es nicht funktioniert. Antwort auf die Lösung weiter unten in einem neuen Post.

 

[konzentrat]

Hallo zusammen
Da io.php seit Shop Version 5.4. entfernt wurde ist die Verbindung zu dieser Datei auch nicht mehr via LS-POS möglich. Kennt jemand die neue URL? Kann dies in keiner Dokumentation finden.

Die Dateneingabe via QR Code funktioniert übrigens auch nicht.

Ich habe es nun geschafft. Neu muss nur noch shopurl.com/io (ohne .php) eingegeben werden.

Ich habe den BASE 64 String vom QR Code vom Shop umgewandelt und dort war es ersichtlich. Da der String sich nicht in LS-POS kopieren liess (resp. "Es wurden leider keine verwertbare Daten gefunden." lieferte) musste ich die Werte händisch eingeben. Man muss alle Werte nochmals manuell in die Felder kopieren (ja auch den Token) obwohl diese ggf. schon dort stehen. Sonst hat es bei mir nicht funktioniert.

 

[css-umsetzung]

Das hört sich an, als ob du veraltete Versionen verwendest, wenn dem so ist, wird es dir nichts nutzen, das du den Pfad einfach auf /io änderst, denn es werden Sachen passieren, mit denen du nicht gerechnet hast.

Ich habe aktuell keine Kasse installiert, aber der QRCODE ist valid.
LUWOSOFT weiß, dass ab Shop 5.4 nur noch /io funktioniert.

 

[konzentrat]

Das hört sich an, als ob du veraltete Versionen verwendest, wenn dem so ist, wird es dir nichts nutzen, das du den Pfad einfach auf /io änderst, denn es werden Sachen passieren, mit denen du nicht gerechnet hast.

Ich habe aktuell keine Kasse installiert, aber der QRCODE ist valid.
LUWOSOFT weiß, dass ab Shop 5.4 nur noch /io funktioniert.

Ich benutze alles aktuellste Versionen.
Der QR Code ist valid, lässt sicher aber trotzdem nicht in LS-POS einfügen.

Es wäre einfach praktisch gewesen wenn bzgl. dem Pfad etwas dokumentiert wäre.

Ich empfehle ihnen eine Kasse zu installieren um sich anzusehen wie es aktuell eingebunden ist. Es steht dort auch permanent Plugin Version 1.07, egal welche Version man effektiv verwendet. Ist auch bei einem anderen Shop den ich betreue genau gleich. Das verwirrt zusätzlich.

 

[css-umsetzung]

Das ist die Mindestversion, mit der die Kasse funktioniert
Aber der Support von LUWOSOFT weiß das eigentlich, dass sich der Pfad in aktuellen Shops geändert hat.

Ansonsten eine kurze Mail an mich, dann kann ich bei solchen Dingen auch helfen, wenn es um die Anbindung geht.

 

[konzentrat]

Das ist die Mindestversion, mit der die Kasse funktioniert
Aber der Support von LUWOSOFT weiß das eigentlich, dass sich der Pfad in aktuellen Shops geändert hat.

Ansonsten eine kurze Mail an mich, dann kann ich bei solchen Dingen auch helfen, wenn es um die Anbindung geht.

Danke für deine Antwort.

LUWOSOFT hatte mir eigentlich auch die richtige Lösung genannt, aber ich musste ALLE Daten nochmals manuell eingeben damit es wirklich funktioniert hat. Etwas merkwürdig.
Ich hatte dich auch versucht telefonisch zu erreichen, da es relativ dringend war. Danach dann Mail und Forum. Aber da hatte ich die Lösung dann schon ziemlich schnell selbst herausgefunden.

 

[css-umsetzung]

Ahhh, gerade gesehen, bin erst heute aus dem Urlaub zurück und habe noch nicht alle E-Mails bearbeitet

 

[surus]

Wir versuchen aktuell, das CSS Gutschein Premium Plugin einzurichten. Ein paar Schritte sind wir schon weiter, der erste Gutschein ist inzwischen in der WaWi angekommen.

Aktuell haben wir drei Probleme damit:

1. Hinweis / Anmerkung wird falsch übernommen

Die Anmerkung (Hinweis) kommt irgendwie falsch in der WaWi an, obwohl wir den Code aus der Anleitung 1:1 übernommen haben. Statt des erwarteten Textes kommt bei uns Folgendes rein:

\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\
\
\
\
\
\
\

Offenbar ist der SQL-Code nicht kompatibel mit unserer WaWi-Version 1.8.12.2.

Kann man das irgendwie zum Laufen bringen, ohne die WaWi zu updaten?
Ein Update ist erst für Ende Januar geplant.


2. Auftrag mit elektronischer Versandart muss trotzdem „versendet“ werden

Der Gutschein kommt – wie in der Anleitung beschrieben – mit der Versandart
„elektronischer Versand eines Gutscheins“ in die WaWi.

Sobald der Auftrag als bezahlt markiert ist, landet er unter "Versand → Lieferbar" und muss dann über "Lieferschein drucken" und "Versand bestätigen" abgeschlossen werden.

Wie kann man diesen Schritt umgehen?
Idee wäre: Den Auftrag automatisch abschließen, sobald eine Zahlung eingegangen ist – also ohne den Versandprozess/Lieferschein-Schritt.


3. Versandarten im Shop bei reinem Gutscheinkauf

Im Shop bekommen wir es nicht hin, dass bei einem reinen Gutscheinkauf nur die Versandart
„elektronischer Versand eines Gutscheins“ angezeigt wird.

Aktuell werden zusätzlich alle anderen Versandarten angezeigt, die wir für normale physische Artikel verwenden.

Wenn man zwei Artikel bestellt (Gutschein + physischer Artikel), ist alles korrekt:
Dann werden nur die Versandarten für normale Artikel angezeigt.

Wie muss man das im Plugin bzw. in der WaWi/Versandarten-Konfiguration einstellen, damit bei einem reinen Gutscheinkauf ausschließlich „elektronischer Versand eines Gutscheins“ angeboten wird?


Vielen Dank schon mal für jede Hilfe oder einen Hinweis, wo wir drehen müssen.

 

[css-umsetzung]

Also Punkt 1 ist relativ einfach, du hast das so wie es ist, aus dem PDF kopiert, da kann es passieren, dass dort Zeilenumbrüche sind, die da nicht hingehören.

nimm mal diesen Code hier und kopiere den in das Feld:

{% if Vorgang.Sonstiges.Anmerkung -%}{{ Vorgang.Sonstiges.Anmerkung }}\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{% endif -%}\
{% for pos in Vorgang.AuftragsPositionen.ArtikelPositionen %}\
{% if pos.Artikelnummer == "GUTSCHEIN" %}\
{% capture query %}SELECT * FROM Verkauf.vAuftragPositionEigenschaft WHERE kAuftragPosition = '{{ pos.InternePositionsnummer }}'{% endcapture -%}\
{% assign result = query | DirectQuery %}\
{% for res in result.Daten %}\
{{ res.cName }}: {{ res.cWert }}
{% endfor %} \
{% endif %}\
{% endfor %}

zu den anderen Sachen, da wäre es einfacher, du buchst den Installationsservice, denn da ist ja so einiges was eingestellt und eventuell erklärt werden muss wie es scheint.

Wenn du das buchst, nehme ich mir die Zeit um dir das genau zu erklären und richte es mit dir zusammen ein, damit du am Ende weißt was da warum und wie geschieht.

 

[KATTUN]

Folgendes Problem:
Eine Kundin nutzt einen Gutschein um ihre Bestellung zu bezahlen und es bleiben nur die Versandkosten übrig. Wenn sie diese mit PayPal im Checkout zahlen möchte kommt die Fehlermeldung: "Must be greater than zero". Ist es ein Kofigurationsproblem in der Zahlungsart und woran könnte es liegen?

 

[JulianeH]

Ja, allerdings sollte das error_reporting in der config Datei vom Shop deaktiviert sein, sonst könnten deprecated Meldungen die Funktionsweise stören.

Update ist "noch" nicht ganz abgeschlossen.

wie schaut es aktuell mit dem 5.7er Shop aus? Danke schon mal & schöne Grüße!