Neu Welche JTL-Shop Plugins oder Funktionen fehlen euch noch? – menuBuilder aktuell in Entwicklung

[TECHNEO]

Hallo zusammen,

wir entwickeln bei [tech]NEO inzwischen eine ganze Reihe eigener Plugins für JTL- Shop 5 und möchten zukünftige Entwicklungen noch stärker danach ausrichten, was Shopbetreiber im täglichen Einsatz tatsächlich benötigen.
Aktuell haben wir unter anderem Lösungen für die Bereiche Cross-Selling, Zugaben, Consent, MultiDomain, OPC-Portlet Erweiterungen, Click & Collect, Affiliate und weitere Themen im Einsatz.
Eine Übersicht unserer aktuellen JTL-Shop Plugins findet ihr hier: https://www.techneo.berlin/jtl-shop-plugins

Als nächstes befindet sich unser neuer menuBuilder in Entwicklung.

Ziel ist es, die Navigation im JTL-Shop deutlich flexibler gestalten zu können als mit den bisherigen Standardmöglichkeiten. Bevor wir die Entwicklung abschließen, würden wir gerne Erfahrungen und Wünsche aus der Praxis mit aufnehmen.
Mich würde deshalb besonders interessieren:

• Was fehlt euch aktuell beim Menü bzw. bei der Navigation im JTL-Shop?
• Welche Funktionen erwartet ihr von einem guten Mega-Menü?
• Sollten Inhalte wie Kategorien, Hersteller, Bilder, Icons, Produkte oder eigene HTML-Inhalte frei kombinierbar sein?
• Welche Möglichkeiten für Desktop und Mobil sind euch wichtig?
• Welche Funktionen fehlen euch bei bestehenden Menü-Plugins?
• Gibt es etwas, das ihr heute nur über Template-Anpassungen lösen könnt?

Natürlich interessiert uns auch unabhängig vom menuBuilder:

Welche Funktion oder welches Plugin fehlt euch aktuell generell im JTL-Shop 5?

Gerade Themen, die heute noch manuell, über individuelle Template-Anpassungen oder mehrere verschiedene Plugins gelöst werden müssen, wären für uns interessant.
Wir möchten lieber Lösungen entwickeln, die im Alltag wirklich gebraucht werden, statt Funktionen nur auf Verdacht einzubauen.
Wer Ideen oder konkrete Anwendungsfälle hat: gerne hier posten. Auch kleine Funktionen können interessant sein.

Viele Grüße
Mirko
[tech]NEO GmbH

 

[TECHNEO]

Kurzes Update zum menuBuilder:



Die Entwicklung läuft bereits und ich möchte euch einmal einen ersten Blick auf den aktuellen Stand geben.

Aktuell entsteht ein flexibler Menü-Builder, mit dem sich Menüs per Drag & Drop aufbauen und verschachteln lassen. Neben klassischen Kategorien sollen auch eigene Links, CMS-Seiten, Hersteller, Merkmale, Überschriften, Freitexte und Bilder direkt im Menü verwendet werden können.

Ein Schwerpunkt liegt auf dem Mega-Menü-Bereich. Dort lassen sich Inhalte frei anordnen und miteinander kombinieren – z. B. Kategorien links, ein Bild daneben und zusätzlicher Freitext oder Hinweise im selben Menübereich.

Das Vorschaubild zeigt den aktuellen Entwicklungsstand des Backends.

Mich würde weiterhin interessieren:
Welche Funktionen wären euch bei einem solchen Menü-Builder besonders wichtig?
Gibt es etwas, das euch bei bestehenden Menü-/Mega-Menü-Lösungen im JTL- Shop fehlt?

Feedback und Ideen nehme ich gerne noch mit in die weitere Entwicklung.

Viele Grüße
Mirko

 

[Morimus]

Rechnungen aus der Wawi direkt im Kundenkonto des JTL-Shops zum Download bereitstellen.

Mir ist bewusst, dass es dafür bereits Lösungen gibt.
Die mir bekannten Lösungen finde ich allerdings aufwendig und auch fehleranfällig.

Teilweise werden Wawi-Workflows benötigt, welche die Rechnungen als PDF irgendwo ablegen.
Zusätzliche Programme oder Dienste übernehmen anschließend den Upload in den Shop und dort müssen die Dateien dann wieder dem jeweiligen Kunden zugeordnet werden.

Es gibt mittlerweile auch eine neuere Lösung über die OnPrem-API, die aber ebenfalls zusätzliche Komponenten benötigt.

Mit den neuen JTL Cloud Apps und der Cloud ERP API müsste sich das meiner Meinung nach inzwischen wesentlich eleganter lösen lassen.

Meine Vorstellung wäre eine Kombination aus Cloud App und einem möglichst schlanken Shop-Plugin.

Das Shop-Plugin übernimmt im Grunde nur die Integration ins Kundenkonto.
Der eingeloggte Kunde sieht dort unter „Meine Rechnungen“ seine Rechnungen aus der Wawi und kann diese direkt herunterladen.

Die eigentliche Kommunikation mit der Wawi übernimmt die Cloud App über die Cloud ERP API.
Die API kann vorhandene Rechnungen direkt als PDF ausgeben:

POST /erp/v2/sales-invoices/{salesInvoiceId}/output/pdf

Die Zuordnung zwischen Shopkunde, Wawi-Kunde, Auftrag und Rechnung müsste die Cloud App natürlich entsprechend sicher prüfen.

Der Vorteil wäre, dass die PDFs nicht mehr vorher über Workflows erzeugt, irgendwo lokal gespeichert und anschließend per FTP oder einem zusätzlichen Tool in den Shop übertragen werden müssten.
Die Rechnung könnte erst beim tatsächlichen Download über die ERP API erzeugt und ausgeliefert werden.

Im Idealfall also:

JTL-Shop Plugin -> Cloud App -> JTL Cloud ERP API -> Wawi

Das Shop-Plugin wäre dabei nur die Schnittstelle zum Kundenkonto.
Die eigentliche Logik und Kommunikation mit der Wawi läuft über die Cloud App.

Damit wären beim Händler keine zusätzlichen Programme oder Dienste auf einem Client oder Server notwendig und auch keine größeren SQL-/ Workflow-Konstruktionen im Hintergrund.

 

[Kentucky]

Ich fände eine einfache Funktion für nicht klickbare Gliederungspunkte super.
Beispiel:

Level 1 Kategorie: Fahrräder
Unterkategorien: Fahrräder für 1000€, Fahrräder für 1200€, Fahrräder für 1500€

Hier wäre es für die Nutzerführung toll, wenn man die 3 Unterkategorien noch mit einem Gliederungspunkt (quasi einer Überschrift) versehen könnte. Aktuell basteln wir uns über eine Template-Änderung hin, indem die Gliederungskategorie eine Level-2 Kategorie ist, aber nicht klickbar und auf noindex gesetzt.

Ebenfalls schon öfter gewünscht habe ich mir eine einfache Möglichkeit, reine Links in die Navi zu setzen - aber so dass sie sich beliebig in die bestehende Struktur einreihen können. Aktuell geht das soweit ich weiß nur über Megamenü-Linkgruppen oder wie das heißt & die sind dann alle gesammelt an einer Stelle. Frei platzierbar wäre besser.

 

[TECHNEO]

Ich fände eine einfache Funktion für nicht klickbare Gliederungspunkte super.
Beispiel:

Level 1 Kategorie: Fahrräder
Unterkategorien: Fahrräder für 1000€, Fahrräder für 1200€, Fahrräder für 1500€

Hier wäre es für die Nutzerführung toll, wenn man die 3 Unterkategorien noch mit einem Gliederungspunkt (quasi einer Überschrift) versehen könnte. Aktuell basteln wir uns über eine Template-Änderung hin, indem die Gliederungskategorie eine Level-2 Kategorie ist, aber nicht klickbar und auf noindex gesetzt.

Ebenfalls schon öfter gewünscht habe ich mir eine einfache Möglichkeit, reine Links in die Navi zu setzen - aber so dass sie sich beliebig in die bestehende Struktur einreihen können. Aktuell geht das soweit ich weiß nur über Megamenü-Linkgruppen oder wie das heißt & die sind dann alle gesammelt an einer Stelle. Frei platzierbar wäre besser.

Hallo Kentucky

Beides ist mit dem menuBuilder abgedeckt — und den Preisfilter haben wir daraufhin ergänzt.

Nicht klickbare Gliederungspunkte

Dafür gibt es den Elementtyp Überschrift. Der wird als <span> ausgegeben, nicht als <a> — also kein Link, dem Suchmaschinen folgen könnten, und kein Ziel, das ins Leere führt. Der Umweg über eine Level-2-Kategorie mit noindex entfällt damit.

Die Überschrift lässt sich frei zwischen den Punkten platzieren:

FAHRRÄDER
Fahrräder für 1000 €
Fahrräder für 1200 €
Fahrräder für 1500 €

Frei platzierbare Links

Ebenfalls vorhanden: Elementtyp Link mit beliebiger URL. Er sitzt an jeder Position im Panel, mitten in der bestehenden Struktur — keine gesammelte Linkgruppe an fester Stelle.

Preisfilter (neu)

Für genau euer Beispiel haben wir Filter am Kategorie-Element ergänzt:

- Preis ab / bis
- Bewertung ab
- nur sofort lieferbare Artikel

Daraus wird /Fahrraeder?pf=1000_1200. Ihr könnt „Fahrräder bis 1000 €" also als Menüpunkt anlegen, ohne dafür Kategorien anzulegen und zu pflegen.

Zwei Details, die sich im Alltag bewähren: Der Builder prüft vorab, ob die gewählte Kategorie überhaupt Artikel enthält — wenn nicht, gibt es keine Filterfelder, sondern einen Hinweis. Und die Preisfelder zeigen die tatsächliche Preisspanne der Kategorie als Vorgabe, damit man keine Filter baut, die zu null Treffern führen.

Viele Grüße
Mirko

 

[TECHNEO]

Rechnungen aus der Wawi direkt im Kundenkonto des JTL-Shops zum Download bereitstellen.

Mir ist bewusst, dass es dafür bereits Lösungen gibt.
Die mir bekannten Lösungen finde ich allerdings aufwendig und auch fehleranfällig.

Teilweise werden Wawi-Workflows benötigt, welche die Rechnungen als PDF irgendwo ablegen.
Zusätzliche Programme oder Dienste übernehmen anschließend den Upload in den Shop und dort müssen die Dateien dann wieder dem jeweiligen Kunden zugeordnet werden.

Es gibt mittlerweile auch eine neuere Lösung über die OnPrem-API, die aber ebenfalls zusätzliche Komponenten benötigt.

Mit den neuen JTL Cloud Apps und der Cloud ERP API müsste sich das meiner Meinung nach inzwischen wesentlich eleganter lösen lassen.

Meine Vorstellung wäre eine Kombination aus Cloud App und einem möglichst schlanken Shop-Plugin.

Das Shop-Plugin übernimmt im Grunde nur die Integration ins Kundenkonto.
Der eingeloggte Kunde sieht dort unter „Meine Rechnungen“ seine Rechnungen aus der Wawi und kann diese direkt herunterladen.

Die eigentliche Kommunikation mit der Wawi übernimmt die Cloud App über die Cloud ERP API.
Die API kann vorhandene Rechnungen direkt als PDF ausgeben:

POST /erp/v2/sales-invoices/{salesInvoiceId}/output/pdf

Die Zuordnung zwischen Shopkunde, Wawi-Kunde, Auftrag und Rechnung müsste die Cloud App natürlich entsprechend sicher prüfen.

Der Vorteil wäre, dass die PDFs nicht mehr vorher über Workflows erzeugt, irgendwo lokal gespeichert und anschließend per FTP oder einem zusätzlichen Tool in den Shop übertragen werden müssten.
Die Rechnung könnte erst beim tatsächlichen Download über die ERP API erzeugt und ausgeliefert werden.

Im Idealfall also:

JTL-Shop Plugin -> Cloud App -> JTL Cloud ERP API -> Wawi

Das Shop-Plugin wäre dabei nur die Schnittstelle zum Kundenkonto.
Die eigentliche Logik und Kommunikation mit der Wawi läuft über die Cloud App.

Damit wären beim Händler keine zusätzlichen Programme oder Dienste auf einem Client oder Server notwendig und auch keine größeren SQL-/Workflow-Konstruktionen im Hintergrund.

Hallo Morimus

Die Idee ist richtig gedacht — beim Nachrecherchieren bin ich aber auf drei Haken gestoßen.

Der Endpunkt existiert, ist aber als „Planned" markiert. POST /v2/sales-invoices/{id}/output/pdf steht vollständig in der OpenAPI-Spec v2.0. JTL kennzeichnet dort Reifegrade: Customer ist stable, Printer ist beta — beim Tag Sales Invoice steht nur „Planned". Ob eine konkrete Wawi das bedient, zeigt nur ein Test am eigenen Mandanten (GET /v2/features liefert je Funktion ein isUsable).

Die Rechnungsliste lässt sich nicht filtern. GET /v2/sales-invoices hat 26 Query-Parameter — Paging, Sortierung und 22 Datumsbereiche. Kein customerId, kein externalSalesOrderNumber. Man kann die API also nicht fragen, welche Rechnung zu Bestellung 12345 gehört, sondern muss die Liste durchpaginieren und die Zuordnung selbst vorhalten, inklusive Nachlauf für Stornos und Gutschriften. Damit wird die Cloud App genau das, was sie nicht sein sollte: nicht schlank.

Die Wawi muss laufen. Der Cloud-Endpunkt ist ein Gateway und reicht Anfragen an die lokale Wawi durch. Nachts ausgeschalteter Rechner heißt: kein Download. Beim Workflow-Weg liegt die PDF dagegen schon im Shop.

Dazu die Voraussetzungen: Wawi ab 2.0, aktive Cloud-Verbindung und eine gebuchte Lizenz für die Wawi-API — derzeit Open Beta, nach dem Release laut JTL „je nach Edition möglicherweise nicht verfügbar".

Zur Zuordnung: Die Felder sind da (externalSalesOrderNumber, shopId, customerId). Aber nicht jeder Wawi-Auftrag hat eine externe Auftragsnummer — Telefonbestellungen und Marktplätze haben keine. Solche Rechnungen lassen sich keinem Shop-Kundenkonto zuordnen, egal über welchen Weg.

Und ein Punkt, der leicht untergeht: „Keine zusätzlichen Programme beim Händler" stimmt, aber die Komponente verschwindet nicht — sie wandert zum Anbieter. Die Cloud App muss selbst gehostet werden, braucht eine Registrierung im Partner Portal, und man wird gegenüber jedem Händler eigenständiger Auftragsverarbeiter, also AVV mit jedem Kunden. Öffentliche App-Store-Listings sind aktuell ohnehin gesperrt.

Wir haben genau das gebaut — ein Shop-Plugin mit beiden Wegen und einem Umschalter. Betriebsart A: Ein Wawi-Workflow legt die Rechnung mit der gewohnten Druckvorlage in einen Ordner, ein kleiner Windows-Dienst überträgt sie signiert an den Shop und löscht sie erst nach bestätigtem Empfang. Kein FTP, keine SQL-Konstruktionen, keine API-Lizenz nötig. Betriebsart B geht über die ERP API, für Händler, die die Voraussetzungen erfüllen.

Beide Wege münden in dieselbe Datenhaltung — für den Kunden im Konto macht es keinen Unterschied, und der Händler kann später wechseln, ohne dass jemand etwas merkt. Die Rechnungen erscheinen direkt an der Bestellung unter „Meine Bestellungen", ohne zusätzlichen Menüpunkt.

Ein Detail aus der Praxis, das im Eingangspost noch nicht auftaucht: Beim Workflow-Weg braucht es ein eigenes Verzeichnis nur für Shop-Rechnungen und am besten ein eigenes Vorlagenset. Sonst landen dort auch Rechnungen zu Telefon- und Marktplatzaufträgen, die sich nicht zuordnen lassen. Und der Workflow muss vom Typ Auftrag sein — in Workflows vom Typ Rechnung steht die externe Auftragsnummer nicht in den Stammdaten zur Verfügung.

Wir haben es schon Umgesetzt und sind am testen.

Grüße Mirko

 

[Morimus]

Moin Mirko,
vielen Dank, dass du dir die Zeit genommen hast!

Vorab. Betriebsart B klingt spannend.
Das würde ich mir gerne anschauen, sobald ihr so weit seid.

Mein ursprünglicher Text ist ehrlich gesagt eher aus Frust über einen Stammkunden entstanden.
An dem Sonntagmorgen hatte ich wieder vier E-Mails von ihm mit der Bitte, ihm Rechnungen zuzusenden.
Dann habe ich deinen Post gesehen und dachte mir: „Feuer frei!“ 😄

Einige Punkte habe ich inzwischen selbst an einem produktiv verbundenen JTL-Mandanten geprüft.

Der von mir genannte neue v2-Pfad ist dort tatsächlich noch nicht verfügbar und liefert einen 404.
Die bestehende API funktioniert jedoch bereits:

PdfInvoice wird für Version 1 und 2 als Beta und isUsable: true gemeldet.
POST /erp/v1/invoices/{invoiceId}/output/pdf lieferte im Test erfolgreich eine gültige PDF.
/v1/invoices kann direkt nach customerId, salesOrderNumber, externalOrderNumber und invoiceNumber filtern.
Die Filter nach Kunde und Rechnungsnummer habe ich erfolgreich getestet.

Das vollständige Paginieren aller Rechnungen betrifft damit vor allem die neue v2-Route.
Mit der aktuell nutzbaren v1-API ist eine gezielte Zuordnung bereits möglich.
Der Beta-Status und eine mögliche spätere Ablösung bleiben natürlich Produktrisiken.

Mit „schlank“ meinte ich vor allem das Shop-Plugin und die Händlerseite.
Dass die Cloud App selbst ein Backend, eine Datenbank, Monitoring und Fehlerbehandlung benötigt, ist mir bewusst.

Mein Ziel wäre, beim Händler keine lokalen Workflows, Übergabeordner, Windows-Dienste oder Upload-Prozesse betreiben zu müssen.

Solche Cloud-API-Anwendungen betreibe ich bereits.
Pagination, persistente Zuordnungen, Caching, Wiederholungen und Monitoring sind dabei nichts Neues.
Fehlende API-Filter erhöhen den Aufwand, sind aber lösbar.

Auch bei der Erreichbarkeit kommt es stark auf die Infrastruktur an.
Läuft der ERP-API-Dienst auf einem Arbeitsplatz, ist die API natürlich nicht erreichbar, sobald dieser Rechner ausgeschaltet wird.

Beim Lizenzthema muss man außerdem zwischen einer individuellen API-Anbindung und einer App aus dem JTL Extension bzw. Cloud App Store unterscheiden.

Für eine selbst entwickelte oder individuell beauftragte Anbindung benötigt der Händler den entsprechenden API-Zugang.
Bei einer Store-App erfolgt der Zugriff dagegen über die registrierte App des Anbieters.
Laut JTL können Store-Erweiterungen, die die REST-API verwenden, in allen Editionen und bereits ab JTL Start genutzt werden.
Eine separate API-Buchung durch jeden Händler ist dafür nicht erforderlich.

Danke dir auf jeden Fall nochmal für deine Einschätzung.
Ich finde den Ansatz weiterhin spannend und bin auch sehr neugierig auf eure Betriebsart B, sobald ihr damit so weit seid.