Neu JTL Rest API

mschop

Aktives Mitglied
21. März 2018
94
10
@Thomas Lisson könnt ihr schon ganz grob das technische Konzept und den Zeitplan erläutern? Wir stehen gerade an dem Punkt, an dem wir überlegen, ob wir bei JTL bleiben oder zu einem anderen ERP wechseln. Wir haben Anforderungen, die weit über die Standard-Anwendungsfälle hinaus gehen und für die wir u.A. eine solide API benötigen.

Wichtig im Bezug auf die API wäre auch, dass man Events aus der JTL-Wawi Subscriben kann (wie auch immer man das technisch löst z.B. über Webhooks). Weil wir müssen nicht nur Daten in die Wawi schreiben, sondern auch auf Events in der Wawi reagieren. Die Workflows sind dafür aus verschiedenen Gründen eher weniger geeignet.

Des weiteren wäre es interessant, einen ganz groben Zeitplan für die 1.6 bzw. API zu haben. Wir haben jetzt wahrscheinlich erstmal noch ein anderes großes Projekt vor der Brust, bei dem wir mit dem aktuellen Zustand gut leben können. Aber Konzept und Zeitplan für die API müsste passen, da wir ansonsten bei der Umsetzung des darauffolgenden Projektes in Verzögerung kommen würden.
 

SebiW

Sehr aktives Mitglied
2. September 2015
2.406
1.002
@mschop ich vermute mal da wird mindestens ein Jahr ins Land gehen. Die Pilotkundenversionen für die frühen Testkunden fangen gerade erst mit der 1.5. an. Es wird also mindestens noch ein halbes Jahr dauern, bis eine 1.5. stable raus kommt. Zwischen 1.3 Stable und 1.4 Stable lagen auch 6 Monate, genau wie bei den vorherigen Majors.
 

Thomas Lisson

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
Hi,
könnt ihr schon ganz grob das technische Konzept und den Zeitplan erläutern?
Alle wichtigen Entitäten sollen über die API lesend sowie schreibend angesprochen werden. Sie wird dem REST API Standard folgen.
Einen Zeitplan kann ich dir nicht geben, damit würde ich den Releasezeitpunkt der 1.6 verraten ;) Die 1.5 steht vor der Tür, die 1.6 ein riesiger Meilenstein in der Geschichte von JTL-Wawi, nimmt bei uns intern immer mehr Gestalt an. In die Pilotphase sollten wir es dieses Jahr schaffen.

Wichtig im Bezug auf die API wäre auch, dass man Events aus der JTL- Wawi Subscriben kann (wie auch immer man das technisch löst z.B. über Webhooks).
Das wird die API nicht können - zumindest nicht von Anfang an. Für dieses Szenario sind jedoch die Workflows prädestiniert, als Aktion kannst du da z.B. einen beliebigen Webservice ansprechen.
 

mschop

Aktives Mitglied
21. März 2018
94
10
Danke für das Feedback!

Alle wichtigen Entitäten sollen über die API lesend sowie schreibend angesprochen werden. Sie wird dem REST API Standard folgen.
Einen Zeitplan kann ich dir nicht geben, damit würde ich den Releasezeitpunkt der 1.6 verraten ;) Die 1.5 steht vor der Tür, die 1.6 ein riesiger Meilenstein in der Geschichte von JTL-Wawi, nimmt bei uns intern immer mehr Gestalt an. In die Pilotphase sollten wir es dieses Jahr schaffen.
Werdet ihr auch GraphQL unterstützen?
Wird es auch möglich sein, Ausgaben anzustoßen?

Das wird die API nicht können - zumindest nicht von Anfang an. Für dieses Szenario sind jedoch die Workflows prädestiniert, als Aktion kannst du da z.B. einen beliebigen Webservice ansprechen.

Bei den Workflows stehen aktuell viel zu wenige Events bereit. Wir werden für anstehende Projekte einige Dinge im Lager anpassen müssen. Z.B. werden wir wahrscheinlich auf Bestandsänderungen reagieren müssen.

Des Weiteren ist die Versionierbarkeit eher nicht gegeben. Wir werden unseren Quellcode in Zukunft in einem Mono-Repository verwalten. Dadurch können wir bei allen unseren Systemen eine konsequente Versionierung durchführen. Probleme macht uns hierbei nur die JTL-Wawi. Die Workflows interagieren mit unserer restlichen Software und müssen daher auch immer auf dem gleichen Stand sein wir der Rest unserer Software. Es ist jetzt derzeit nicht das riesen Problem, sorgt aber für unnötigen Aufwand und Fehlerquellen. Ggf. werde ich die Workflows im Repository pflegen und dann in die JTL-Wawi-DB schreiben müssen. Wirklich befriedigend ist dieser Ansatz aber nicht.

Ein weiterer wichtiger Punkt ist, dass wir nicht mit bekommen, wenn bei den Workflows etwas schief läuft. Wir können die Workflows ja in keiner Weise überwachen. Wenn z.B. der Web-Request fehlschlägt, sei es weil ein Netzwerkproblem existiert, dann bekommen wir das Problem erst dann mit, wenn die Probleme beim User aufschlagen.
 

Thomas Lisson

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
Hi,

Nein - zumindest nicht initial.

Wird es auch möglich sein, Ausgaben anzustoßen?
Was meinst du damit genau? Mach mal ein Beispiel.

Wenn z.B. der Web-Request fehlschlägt, sei es weil ein Netzwerkproblem existiert, dann bekommen wir das Problem erst dann mit, wenn die Probleme beim User aufschlagen.
Kannst du nicht mit der Rückgabe des Webservices arbeiten, indem du diesen Wert in eine Variable schreibst? Aber ich verstehe, dass es problematisch ist.

Wie ist es mit Triggern auf Tabellen, die euch wichtig sind? Die können SPs / .NET Code aufrufen. Verlangsamt jedoch die Wawi.
 

mschop

Aktives Mitglied
21. März 2018
94
10
Was meinst du damit genau? Mach mal ein Beispiel.

Ich meine die Ausgaben wie Rechnungen, Aufträge etc. Soweit ich weiß, kann man die Ausgabe auch über die JTL-Wawi-Extern.dll anstoßen. Wir hatten uns damals allerdings für eine Anbindung der Wawi über eine PHP basierte Web-API entschieden. Einfach aus dem Grund heraus, dass wir dringend etwas fertig bekommen mussten und ich damals flüssiger in der Programmierung von PHP war. Die Ausgabe haben wir allerdings nicht über die dll umgesetzt, sondern wir stoßen Workflows über die DB an um die Dokumente auf dem Worker auszudrucken. Das funktioniert soweit auch, allerdings ist es auch hier schwierig etwaige Probleme im Druck mitzubekommen. Soll heißen: Wenn der Druckerspooler rum spinnt oder ein Fehler in der Ausgabe ist und ein PrintLog auf dem Desktop gespeichert wird, dann bekommt man davon wieder nur schwerlich was mit. Das zu überwachen wäre eher kompliziert.
Ich würde diese Art der Ausgabe gerne ablösen und stattdessen eine deutlich Fehlertolerantere Lösung nutzen. Wenn ihr also die Ausgabe über die API anbieten würdet, könnte man z.B. über die http Response zurück geben, ob die Ausgabe erfolgreich war.

Kannst du nicht mit der Rückgabe des Webservices arbeiten, indem du diesen Wert in eine Variable schreibst? Aber ich verstehe, dass es problematisch ist.
Mhhhh. Wäre eine Möglichkeit. Aber eine echt hässliche. Wirklich zufriedenstellend fände ich die Lösung nicht. Aber ich behalte den Vorschlag im Hinterkopf.

Wie ist es mit Triggern auf Tabellen, die euch wichtig sind? Die können SPs / .NET Code aufrufen. Verlangsamt jedoch die Wawi.
Das wäre technisch gesehen eine Möglichkeit. Allerdings dachte ich, dass dies von JTL so nicht gewünscht sei. Die letzte Info, die ich hatte war, dass JTL im Zweifelsfall sogar den Support einstellt, wenn eigene Trigger hinzugefügt wurden. Oder ist diese Information falsch / veraltet?
 

Thomas Lisson

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
Hi,

Ausgabe haben wir auch auf dem Schirm. Genaueres kann ich derzeit noch nicht sagen. Ihr könnt aber auch die DLL auch über PHP anstoßen.
Am besten kommst du auf die JTL-Connect am 30.08 und sprichst dort mit Maik oder Sebastian. Sie können die wesentlich mehr Input hierzu geben. Sebastian hält auch einen Vortrag um 16:50 zum Thema "Mach die Wawi zu deiner Wawi" - schnapp ihn dir nach dem Vortrag: https://jtl-connect.de/vortraege

Die letzte Info, die ich hatte war, dass JTL im Zweifelsfall sogar den Support einstellt, wenn eigene Trigger hinzugefügt wurden.
Schreibende Eingriffe in der DB, die nicht über unser SPs laufen, sind problematisch. Wenn du einen Trigger einsetzt, um auf ein Update Event zu reagieren ohne in der DB zu schreiben, sollte das keine Auswirkungen haben. Aber grundsätzlich sollte man hierbei sehr vorsichtig sein.
 

MaxWe

Sehr aktives Mitglied
6. August 2018
311
42
Hamburg
Kurze Frage: Ist ein jtlConnector nicht bereits eine Schnittstelle => API?

Ich bin grad dabei eine kleine Schnittstelle zu konzipieren, die Variationsdaten eines Artikels in einem Auftrag via Web Formular füllt.
Hierbei schaue ich mir verschiedene Lösungen an und habe mir auch mal den Connector angeschaut.
Im Endeffekt bietet dieser alles was man so braucht und muss vereinfacht nur noch mit Controllern ausgestattet werden.
Ich muss ihn ja nicht in Verbindung mit einem Shop verwenden :) Ich nutze eben lediglich einige wenige Funktionen.
So schreibe ich nicht direkt in die DB, sondern gehe ganz sauber über die von jtl geschaffene Schnittstelle.

Sehe ich das ganz falsch oder denke ich mir einen eigenen kleinen Connector nur zu leicht? :)
Als Basis würde ich dann zbsp. Lumen by Laravel nutzen.

Grüße

EDIT: Ich sehe schon das Problem: Multishop Lizenz nötig
 
Zuletzt bearbeitet:

mschop

Aktives Mitglied
21. März 2018
94
10
Kurze Frage: Ist ein jtlConnector nicht bereits eine Schnittstelle => API?

Ich bin grad dabei eine kleine Schnittstelle zu konzipieren, die Variationsdaten eines Artikels in einem Auftrag via Web Formular füllt.
Hierbei schaue ich mir verschiedene Lösungen an und habe mir auch mal den Connector angeschaut.
Im Endeffekt bietet dieser alles was man so braucht und muss vereinfacht nur noch mit Controllern ausgestattet werden.
Ich muss ihn ja nicht in Verbindung mit einem Shop verwenden :) Ich nutze eben lediglich einige wenige Funktionen.
So schreibe ich nicht direkt in die DB, sondern gehe ganz sauber über die von jtl geschaffene Schnittstelle.

Sehe ich das ganz falsch oder denke ich mir einen eigenen kleinen Connector nur zu leicht? :)
Als Basis würde ich dann zbsp. Lumen by Laravel nutzen.

Grüße

EDIT: Ich sehe schon das Problem: Multishop Lizenz nötig

Hallo MaxWe,

Das Problem ist nicht die Multishop-Lizenz sondern die Art und Weise, wie der Connector arbeitet. Zunächst einmal ist der JTL-Connector nicht wirklich bidirektional. Es werden zwar Daten von der JTL-Wawi zum Shop-System geschickt und vom Shop-System abgerufen, allerdings geht der Verbindungaufbau immer von der JTL-Wawi aus. Wenn du also wirklich aktuelle Daten brauchst (ohne Verzögerung durch den Abgleichsprozess) ist der Connector dafür nicht geeignet.

Außerdem kann man mit dem Connector nicht auf alle Daten in der JTL-Wawi zugreifen. In meinem Fall z.B. musste ich Rechnungskorrekturen anlegen und verändern. Eine API hätte mir das Leben hier leichter gemacht. So musste ich direkt mit der Datenbank arbeiten. Der JTL-Connector ist halt wirklich nur für die Anbindung eines Shop-Systems konzipiert und deckt bei weitem nicht alle Anwendungsfälle ab.

Gruß
mschop
 
  • Gefällt mir
Reaktionen: MaxWe

MaxWe

Sehr aktives Mitglied
6. August 2018
311
42
Hamburg
Hallo MaxWe,

Das Problem ist nicht die Multishop-Lizenz sondern die Art und Weise, wie der Connector arbeitet. Zunächst einmal ist der JTL-Connector nicht wirklich bidirektional. Es werden zwar Daten von der JTL-Wawi zum Shop-System geschickt und vom Shop-System abgerufen, allerdings geht der Verbindungaufbau immer von der JTL-Wawi aus. Wenn du also wirklich aktuelle Daten brauchst (ohne Verzögerung durch den Abgleichsprozess) ist der Connector dafür nicht geeignet.

Außerdem kann man mit dem Connector nicht auf alle Daten in der JTL-Wawi zugreifen. In meinem Fall z.B. musste ich Rechnungskorrekturen anlegen und verändern. Eine API hätte mir das Leben hier leichter gemacht. So musste ich direkt mit der Datenbank arbeiten. Der JTL-Connector ist halt wirklich nur für die Anbindung eines Shop-Systems konzipiert und deckt bei weitem nicht alle Anwendungsfälle ab.

Gruß
mschop
Danke dir für deine Erläuterung! :)
Ich denke ich könnte den Connector für mein Vorhaben vielleicht nutzen, aber ich werde wohl direkt mit der DB kommunizieren.
Eine API direkt von JTL sollte so oder so das Ziel sein, daran wird aber ja gearbeitet :)

Grüße
 

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.343
838
Bei den Workflows stehen aktuell viel zu wenige Events bereit. Wir werden für anstehende Projekte einige Dinge im Lager anpassen müssen. Z.B. werden wir wahrscheinlich auf Bestandsänderungen reagieren müssen.

Bitte mal hier voten, diese Funktion wird bisher von JTL leider scheinbar nicht als wichtig genug für eine Warenwirtschafts-Software erachtet und schafft es daher leider seit über 31/2 Jahren nicht in die Umsetzung:
https://issues.jtl-software.de/issues/WAWI-10099

@Thomas Lisson
Warum braucht eine solche "Kernfunktion" einer Warenwirtschafts-Software solange für die Umsetzung?
 

T4DT.GmbH

Offizieller Servicepartner
SPBanner
6. November 2018
318
129
Hannover
Bitte mal hier voten, diese Funktion wird bisher von JTL leider scheinbar nicht als wichtig genug für eine Warenwirtschafts-Software erachtet und schafft es daher leider seit über 31/2 Jahren nicht in die Umsetzung:
https://issues.jtl-software.de/issues/WAWI-10099

Zunächst einmal (bis zur Lösung des Problems) kann man auf das tatsächlich auslösende Ereignis horchen: Minusbuchung, Plusbuchung, Pickliste abgeschlossen, Auftrag vollständig ausgeliefert, etc.

Warum braucht eine solche "Kernfunktion" einer Warenwirtschafts-Software solange für die Umsetzung?

Warum, lässt sich ganz einfach beantworten. JTL ist mittlerweile eine der am meisten verwendete Software im Bereich E-Commerce in Deutschland überhaupt. Es dürfte also mehrere hundert dieser Anfragen, mit dem gleichen Schweregrad bei JTL geben. Dieser Bereich (Workflows) ist völlig kostenlos. Sprich: Diese Funktion bringt keinen Euro Umsatz für das Unternehmen. Also konzentriert man sich auf die Dinge überwiegend, welche die dahinter stehenden Familien auch satt macht. Das ist keine "Sei doch froh mit dem was du hast"-Apell, sondern ein: "Es ist nicht zu viel verlangt, für eine kostenlose Funktion, von denen jeden Monat haufenweise von JTL erzeugt werden, etwas mehr Wertschätzung zu äußern, als mit einem "Was braucht ihr denn so lange dafür" um die Ecke zu kommen.
 

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.343
838
Warum, lässt sich ganz einfach beantworten. JTL ist mittlerweile eine der am meisten verwendete Software im Bereich E-Commerce in Deutschland überhaupt. Es dürfte also mehrere hundert dieser Anfragen, mit dem gleichen Schweregrad bei JTL geben. Dieser Bereich (Workflows) ist völlig kostenlos. Sprich: Diese Funktion bringt keinen Euro Umsatz für das Unternehmen. Also konzentriert man sich auf die Dinge überwiegend, welche die dahinter stehenden Familien auch satt macht. Das ist keine "Sei doch froh mit dem was du hast"-Apell, sondern ein: "Es ist nicht zu viel verlangt, für eine kostenlose Funktion, von denen jeden Monat haufenweise von JTL erzeugt werden, etwas mehr Wertschätzung zu äußern, als mit einem "Was braucht ihr denn so lange dafür" um die Ecke zu kommen.

Das wird jetzt etwas Offtopic, aber die Reaktion kann ich ehrlich gesagt nicht gelten lassen, das Kostenargument schonmal gar nicht. Wir zahlen jedes Jahr mehrere tausend Euro für das Gesamtpaket JTL mit steigender Tendenz. Wir reden hier über eine Warenwirtschafts-Software (die mittlerweile von JTL selbst als ERP-System bezeichnet wird), die nicht automatisch (im Workflow-System) auf die Veränderung des verfügbaren Bestandes reagieren kann. Das ist aber die Kernbeschreibung von Warenwirtschaft.

Da ist die Frage durchaus berechtigt, wenn grundsätzlich auf Workflows verwiesen wird, in diesen dann aber allerhand Variablen und Auslöseereignisse fehlen, warum solche Verbesserungsvorschläge dann nun schon bald 4 Jahre brauchen und immer noch nicht bekannt ist ob und wann und in welcher Version das eventuell mal umgesetzt wird (wenn man übrigens in den Thread für fehlende Auslöseereignisse schaut, ist davon auch fast gar nichts umgesetzt).

Wir reden hier nicht über die Ultra-Mega-Super-Duper-NicetoHave-Lösung, sondern ein (aus meiner Sicht) recht simples Feature was wirklich jeder Warenwirtschafts-Benutzer potenziell benötigt. Die eigentliche Frage muss doch sein, wieviele Nutzer benötigen das?, Wie wichtig ist die Funktion für die Kernfunktionalität eines Wawi-(ERP-)Systems? Und welchen Kosten-/Nutzenvorteil bringt das (wieviele Programmierstunden kostet das und wieviele Arbeitsstunden spart das bei den Nutzern, die für sinnvolle Vertriebstätigkeiten eingesetzt werden können)?

Im Übrigen ist es so, dass die Kunden von JTL mit jeder vernünftigen Funktion Umsatz machen und sich dies auch auf den Umsatz von JTL auswirkt. Mit den Workflows verdient JTL folglich indirekt Geld, weil die Kunden Anpassungen auf Ihre Prozesse selbst vornehmen können und JTL sich damit Programmieraufwand erspart und dennoch größere Kundengruppen erreichen kann.

Nach Deiner Aussage dürften alle Basis-Funktionen der Wawi nicht weiterentwickelt werden, dann würde aber auch keiner mehr die Zusatzfunktionen kaufen.

Wenn ich mich aber damit beschäftige, 23 Workflows anzulegen (sofern dies denn wirklich sauber funktioniert und auch noch ein Stück weit Übersichtlichkeit gegeben ist), die mit einem Auslöseereignis abzudecken wären, verdiene ich kein Geld, meine Familie muss verhungern (und ich auch) und ich kann dann weder weiterhin das an JTL bezahlen, was ich jetzt bezahle noch zusätzliche Funktionen bei JTL erwerben, wodurch dann die Familien der JTL-Mitarbeiter auch wieder verhungern. ;)

Lange Rede kurzer Sinn, mir geht es nicht um JTL-Bashing sondern im Kern um die Frage, ob und wann mit dieser Funktion zu rechnen ist und wann überhaupt mit mehr Auslöseereignissen und Variablen im Workflow-System zu rechnen ist!?
 

T4DT.GmbH

Offizieller Servicepartner
SPBanner
6. November 2018
318
129
Hannover
Versteh mich bitte nicht falsch. Ich finde deinen Wunsch nach Umsetzung nicht illegitim (Ich habe für selbst für das Feature bereits gestimmt)!
Mir missfällt nur manches mal der etwas herrische Ton, der hier im Forum gerne herrscht. Dagegen habe ich eine inhaltliche Einordnung gestellt. Natürlich gibt es Dinge, die ich kritisiere und auch Dinge, auf die ich warte. Aktuell ist es halt nur einfach so, dass JTL, so wie du es seit Jahren kennst, technisch in der absoluten (C++)-Sackgasse steht. Daher müssen Stück für Stück alle Teile der WAWI neu geschrieben werden. Das nennt sich dann Artikel 2.0, Auftrag 2.0, und so weiter. Am Ende wird eine komplett neu geschriebene Wawi stehen, die vermutlich nicht mal besonders viel mehr Funktionen hat als heute. Sie stellt aber immerhin die Grundlage dafür auch in der Zukunft verwendet zu werden. Ich finde den Schritt insofern Features komplett hinten an zu stellen, völlig in Ordnung.
 
  • Gefällt mir
Reaktionen: hairlin
Ähnliche Themen
Titel Forum Antworten Datum
JTL REST API - appRegistration / erste Einrichtung JTL-Wawi 1.8 8
Neu Best Pratices Shopware - JTL - Buchhaltung User helfen Usern - Fragen zu JTL-Wawi 1
Neu JTL Ameise Extrem Langsam im Export JTL-Ameise - Fehler und Bugs 7
Wichtig 👉 Wichtiger Hinweis: JTL-eazyAuction Server Downtime am Dienstag, 02.04.2024 News, Events und Umfragen 0
Neu Wechsel WAWI Hosting von JTL mit RDP auf ecomDATA User helfen Usern - Fragen zu JTL-Wawi 2
JTL Worker Manueller Abgleich nicht möglich trotz deaktivierem Worker 2.0 JTL-Wawi 1.8 4
Neu JTL Shopify Connector und Billbee frage Shopify-Connector 0
Neu Nach Umstellung auf WMS Probleme mit der JTL Ameise Installation von JTL-WMS / JTL-Packtisch+ 0
Neu JTL Pos Sum-Up Rückgabe Allgemeine Fragen zu JTL-POS 0
Neu JTL Worker 2.0 und tinetbestellung Technische Fragen zu den JTL-Connectoren 0
Neu JTL-Shop 5.3 - Aktuell 5.3.1 Releaseforum 1
Neu JTL 1.8.12.0 - Artikelattribut für Shop importieren - Format CSV-Datei / Hilfe bei Import von individuellen Attributen für JTL-Shop (googlekat) JTL-Ameise - Ideen, Lob und Kritik 1
JTL Shop Gutscheine über JTL-Vouchers erstellen Allgemeine Fragen zu JTL-Vouchers 1
Neu JTL Connector zu SW6 auch als Testumgebung möglich ? Onlineshop-Anbindung 3
Neu Update des JTL shops aus der Wawi funktioniert nicht Allgemeine Fragen zu JTL-Shop 1
Neu JTL Shop Gutscheine über JTL-Vouchers erstellen Allgemeine Fragen zu JTL-Shop 0
Neu JTL zu Shopify Bestand wird nicht aktualisiert Shopify-Connector 0
Neu JTL Wawi Bild-Upload unvollständig oder nur als mit meinem PC hochgeladen zu sehen User helfen Usern - Fragen zu JTL-Wawi 2
Neu Bestimmte Artikel von JTL-Search ausschließen JTL-Search 0
JTL Multishop: Domain 1: Eine Sprache, eine Währung | Domain 2: 3 Sprachen, 3 Währungen JTL-Wawi 1.7 3
Neu Email Versand in JTL Wawi einstellen User helfen Usern - Fragen zu JTL-Wawi 3
Neu Produktfeld "Produktkategorie" von JTL nach Shopify? Shopify-Connector 0
Neu Greyhound JTL-Connector funktioniert nach Update auf 1.8.12 nicht mehr richtig Technische Fragen zu den JTL-Connectoren 5
Neu JTL erstellt falsche Rechnungskorrekturen für Amazon.co.uk Aufträge und verweigert den Support Amazon-Anbindung - Fehler und Bugs 5
Neu E-Commerce-Effizienz steigern: Welche Programmiersprache verbessert die JTL-Shop-Entwicklung? Technische Fragen zu Plugins und Templates 1
Neu JTL-Wawi Logdatei Speicherort JTL-Wawi - Fehler und Bugs 6
In Diskussion JTL POS Kundennummer wird nicht an JTL Wawi übertragen JTL-POS - Fehler und Bugs 2
Auftrag und Rechnung Ausgabe funktioniert nicht Client JTL 1.8.10.0 JTL-Wawi 1.8 9
Neu DPD-Versand in Nicht-EU-Länder mit JTL-Shipping JTL-ShippingLabels - Ideen, Lob und Kritik 1
Neu JTL-Ameise Kontaktdaten-Export und in Greyhound importieren plus Zuweisen User helfen Usern 1
Wichtig 👉 Wichtiger Hinweis: JTL-eazyAuction Server Downtime am Dienstag, 12.03.2024 News, Events und Umfragen 0
Neu JTL Shipping Labels mit DHL Unterschied Versenden, Versenden 3.0 und Intraship User helfen Usern - Fragen zu JTL-Wawi 8
Tablet Empfehlung für JTL-WaWi APP? JTL-Wawi App 0
Neu JTL überträgt Versandart Sendungsnummer nur teilweise an Amazon Amazon-Anbindung - Fehler und Bugs 3
Neu JTL-Installation- Verbindung zur Datenbank -SA Kennwort Installation von JTL-Wawi 22
Neu Alle Produktbilder in Shopify aus JTL löschen Shopify-Connector 0
Neu Kompatibilitätsliste JTL Shop & JTL Wawi Installation / Updates von JTL-Shop 2
Neu JTL-POS installation vom Playstore Einrichtung / Updates von JTL-POS 2
Neu JTL-POS installation vom Playstore Installation von JTL-Wawi 0
Neu JTL-Kenner Raum Aachen zur Mithilfe gesucht Dienstleistung, Jobs und Ähnliches 2
Neu JTL-Shop 5 Paypal Zahlung 30 Tage Zahlungsziel Allgemeine Fragen zu JTL-Shop 6
Neu JTL-Shop 5.3.0 RC3 Fehler nach Update Portlet Banner, fehlendes Produkt JTL-Shop - Fehler und Bugs 0
Neu Umstieg von Shopware 5 zu JTL Shop 5 - Ranking behalten Allgemeine Fragen zu JTL-Shop 2
Neu JTL Connector Woocomerce für PHP Version 7.4 WooCommerce-Connector 2
Neu Verbindungsproblem Wawi (1.8.12.0) zum JTL-Shop (5.2.4) über localhost User helfen Usern - Fragen zu JTL-Wawi 0
Neu JTL 1.5.55.8 Statistik - durschnittlicher Verkaufspreis - Mengen und Position User helfen Usern - Fragen zu JTL-Wawi 0
Neu JTL-Wawi mit Shopware/Magnalister User helfen Usern - Fragen zu JTL-Wawi 3
Neu Lizenz zu verkaufen für JTL-Shop Standard Edition Allgemeine Fragen zu JTL-Shop 4
JTL stürzt bei Druckvorschau oder Drucken seit Wechsel auf v.1.7 immer wieder ab JTL-Wawi 1.8 6
JTL Shop : automatisch setzen: Verfügbar ab: 28.04.2024 (Vorbestellung möglich) JTL-Wawi 1.8 0

Ähnliche Themen