Bleibt bei 1.5!

Status
Es sind keine weiteren Antworten möglich.

SebiW

Sehr aktives Mitglied
2. September 2015
2.582
1.162
Die Stimmungslage wie auch die Reaktionen auf Manuels Umfrage sagen aus, dass ein nicht unrelevanter Teil Eurer Userschaft lieber einen toten Gaul reitet als auf die aktuellen Jungpferde zu setzen. Und dass es da ein Problem gibt zeigt alleine schon der Umstand, dass es die Umfrage von Manuel gibt.

Anders als Ihr können die meisten Eurer User nicht diverse Versionen auf Herz und Nieren testen. Die 1.5 war eine vergleichsweise extrem stabile und problemfreie Version. Um von da Weg zu wechseln braucht es gute Gründe.
Diese Gründe konnten für viele die 1.6/1.7/1.8 nicht liefern. Für einige bedeuteten die neuen Versionen sogar deutliche Verschlechterungen (die Ihr ja teilweise erkannt und gefixt habe, siehe zb die Lagerpackliste).

Wenn wir nicht an externe Systeme wie Amazon angebunden wären, wären wir wahrscheinlich auch immer noch auf der 1.5. Der Wechsel zur 1.6 war schlicht und ergreifend verdammt schmerzhaft und hatte für uns wie für viele andere schlicht keine oder nur wenige Vorteile. Das liegt auch daran, dass neue Bausteine wie P&P oder die Kartonagenverwaltung bspw unsere Hoffnungen nicht erfüllt haben.

Die 1.5 ist eben nur bei Euch intern ein totes Pferd, in der Community ist der Gaul noch verdammt lebendig. Und das ist ein Problem dass Ihr lösen müsst. Das ist die Kernbotschaft, die Ihr aus Threads wie diesem mitnehmen solltet. Eure Kunden bleiben ja nicht aus schierer Boshaftigkeit auf alten Versionen sondern weil die neuen nicht attraktiv genug sind um die einhergehenden Probleme des Upgrades zu rechtfertigen.
 

Enrico W.

Administrator
Mitarbeiter
27. November 2014
8.617
1.741
In meinen Augen zeigt der Thread von Manuel vor allem, dass es unmöglich ist, sich alle relevanten Punkte aus diversen (Sammel)Threads zusammenzusuchen.
Gute Gründe zu wechseln wären, dass Änderungen nunmal nur in die neuen Versionen kommen können.
Wie gesagt: Kritik ist gern gesehen, aber wenn es die Kritikpunkte gar nicht mehr gibt, dann ist es in meinen Augen unsinnig, sich darüber zu ärgern.
 

SebiW

Sehr aktives Mitglied
2. September 2015
2.582
1.162
Naja, ganz blöde Frage: Wieso macht ein Sammelthread von Manuel Sinn, ein Sammelthread von Usern aber nicht?
Und dass die aus Eurer Sicht guten Gründe für viele nicht genügen ist genau das Feedback, dass Ihr aus diesem und ähnlichen Threads bekommt.

Wir als User machen da auch nichts anderes als eine Kosten/Nutzen Abwägung. Und das Ergebnis dieser Abwägung ist für viele trotz immer schlechter werdendem Nutzwert der 1.5 immer noch eindeutig.
Dieses Verhältnis zu verschieben ist allein Eure Aufgabe. Ihr habt schon so ziemlich das Maximum dessen gefahren, was die 1.5 unattraktvier machen könnte (Kein Support etc). Wenn das immer noch nicht reicht liegt das Problem wohl auf der Nutzenseite der späteren Versionen.

Und als Einwurf - Ihr habt sehr viele KMUs die häufig Inhabergeführt sind. Die meisten Menschen gründen Unternehmen, weil sie sich nicht gerne sagen lassen, was sie zu tun haben. Insofern würde ich darüber nachdenken inwiefern Zwang durch Abschaltung, Supportende etc hier wirklich eine gute Idee ist...
 

Enrico W.

Administrator
Mitarbeiter
27. November 2014
8.617
1.741
Ein solcher Sammelthread wird dann von Manuel auch beobachtet und betreut, er sammelt die einzelnen Punkte und bringt jeden an den jeweiligen PO. Das ist schon ansich schwierig genug, wie meine nächsten zwei Zeilen zeigen werden.
Ein Sammelthread, wo mal eben alles durcheinandergewürfelt und diskutiert wird ist schwer zu beobachten und auseinanderzunehmen, einzelne Bereiche nur extrem schwer beieinander zu halten.

Der Großteil der User ist auf aktuelleren Versionen, somit scheint das Verhältnis schon sehr weit verschoben zu sein. Und wir können so weit schieben, wie wir wollen... wenn es User gibt, die nicht prüfen wollen, ob sich das Verhältnis verschoben hat oder nicht, dann können wir da gar nichts machen.

Ich glaube, über den letzten Punkt brauchen wir gar nicht reden.
 

SebiW

Sehr aktives Mitglied
2. September 2015
2.582
1.162
Da mir wohl immer noch nicht gelungen ist zu kommunizieren was ich sagen will: Dieser Thread richtet sich primär erstmal nicht an Euch. Das sagt schon der Titel "Bleibt bei 1.5!" - das wendet sich kaum an den JTL Support ;)
Vielleicht wäre er in "User helfen Usern" oder Smalltalk bzw Business Jungle besser aufgehoben. Anders als die Umfrage von Manuel.

Das Beste was ihr als JTL aus diesem Thread mitnehmen könnt ist "Hier gibt es User mit Problemen, sprechen wir diese individuell an und schauen ob wir helfen können". Das schlechteste was Ihr machen könnt ist ihn zu löschen.
Grundsätzlich ist es starke Außenkommunikation wenn man als Firma Kritik auf den eigenen Kommunikationskanälen akzeptiert - und sei sie auch ungerechtfertigt. Deshalb löscht man auch schlechte Artikelbewertungen nicht.
Will sagen, machst Du fein :)

Und der letzte Punkt ist eigentlich das Kernthema jeglicher Kommunikation mit KMUs :D Schau Dir mal so Betonköpfe wie @MichaelH oder mich an - und ich bin noch nichtmal Firmeninhaber, ich führ mich nur auf wie einer ;)
Grundsätzlich müsst Ihr als Technologieanbieter immer davon ausgehen, dass Ihr mehr Wissen über Eure Software besitzt. Und zwar auch mehr als wir als User überhaupt Interesse haben zu erlangen.
Gleichzeitig gibt es aber einen eindeutigen Interessenskonflikt.
Händler haben keinerlei Interesse an Veränderung ihrer Warenwirtschafts Software insofern sie dadurch nicht direkt eine Verbesserung ihrer Firmenprozesse und damit Kostenersparnisse erreichen oder Alternativ erweiterte Absatzmöglichkeiten erhalten.
Es ist für uns schlicht irrelevant ob das Ding mit C++ oder C# läuft. Wir wollen dass Prozesse stabil sind weil Änderung Schulungen, Fehlerquellen und damit Kosten bedeuten. Der Rollout der 1.6 ff war schlicht deshalb bei vielen so zögerlich weil das Kosten/Nutzen Verhältnis für viele Händler nicht gestimmt hat.
Für uns zb war das Thema SCX der relevante Knackpunkt. Hätten wir nicht Otto und Kaufland implementieren wollen gäbe es für uns bis heute keinen relevanten Grund die 1.5 zu verlassen. Und im Endeffekt ist das das Feedback, was ihr aus Threads wie diesem bekommt.
Natürlichwürde ich mittlerweile nicht mehr auf die 1.5 zurück gehen - wir haben alle Änderungen ja schon durch. Aber es gibt auch nach mehreren Jahre immer noch Probleme die wir so früher nicht hatten, bspw die geänderte Logik beim Auftragssplit oder das Problem, dass man keine Auftragsnummern auf Rechnungen kriegt oder die Druckperformance zu killen. Und solche Probleme gibt es immer noch einige die es in dieser Form in der 1.5 nicht gab.
 

Enrico W.

Administrator
Mitarbeiter
27. November 2014
8.617
1.741
Und da sind wir dann wieder am Anfang :D
Ich versteh Dich da durchaus.
Wie aussagekräftig ist so ein Thread tatsächlich, was die Stimmung angeht? Wie gesagt, wir haben mittlerweile tausende User auf der 1.8. Von denen liest man hier nicht gerade etwas. Eher von denen, die Probleme hatten oder haben.
Damit will ich wie gesagt nichts davon klein reden. Ganz im Gegenteil. Aber wenn wir im besten Falle sagen sollen "Hier sind Leute, die haben ein Problem, schauen wir, ob wir das gelöst bekommen" - dann muss das in einer Form geschehen, die auch reproduzierbar und nachvollziehbar ist, ohne dass man sich mittlerweile 5 Seiten mit Textwällen durchlesen muss, die nichts mit dem jeweiligen Problem zu tun haben.
Dazu sind eben einzelne Supporttickets oder Threads tausend mal besser geeignet.

Hast du das Thema mit dem Auftragssplit mal irgendwo aufgegriffen? Oder das mit den Auftragsnummern auf Rechnungen?
Bei der Druckperformance, da weiß ich, dass es bei einigen Usern Probleme gab, bin aber nicht sicher, inwiefern sich das mittlerweile gebessert hat. Dafür bin ich zu wenig in diesem Bereich unterwegs.

Und ich kann mich da wieder nur wiederholen: Wir brauchen viele Themen vielleicht gar nicht mehr anfassen, weil sie schon in der 1.8 behoben wurden. Dafür müssen die User aber auch wieder schauen, ob sie noch Probleme haben oder ob es noch was zu machen gilt.

Nina und ich holen Euch gern die POs zu den Themen dazu, damit ihr Euch da austauschen könnt. Aber ihr müsst dann wissen, dass das Problem in der aktuellen Version noch vorhanden ist oder dass es ein neues Problem gibt.
 

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.436
938
Naja, ganz blöde Frage: Wieso macht ein Sammelthread von Manuel Sinn, ein Sammelthread von Usern aber nicht?

Vor allem ist ja tatsächlich mal die Frage, was von den Sachen aus dem Thread von Manuel wann umgesetzt wird oder schon umgesetzt ist.
Wir sind ja mittlerweile kurz vor der 4. Version nach der 1.5, man könnte also auch umgekehrt die Frage stellen, was wären Gründe, die Dich dazu verleiten würden, auf die 1.8/1.9/1.x/2.x upzudaten.

Für uns zb war das Thema SCX der relevante Knackpunkt. Hätten wir nicht Otto und Kaufland implementieren wollen gäbe es für uns bis heute keinen relevanten Grund die 1.5 zu verlassen. Und im Endeffekt ist das das Feedback, was ihr aus Threads wie diesem bekommt.
Natürlichwürde ich mittlerweile nicht mehr auf die 1.5 zurück gehen - wir haben alle Änderungen ja schon durch. Aber es gibt auch nach mehreren Jahre immer noch Probleme die wir so früher nicht hatten, bspw die geänderte Logik beim Auftragssplit oder das Problem,

Und das ist der Kern der Problematik, wir sind nicht auf die 1.8 gegangen, weil wir das unbedingt wollten, aber Otto, Kaufland, SCX und die entsprechenden Vorbereitungen in der Artikelpflege sind halt schon ganz interessant.
Der Hauptgrund waren aber bei jedem Wechsel nach der 1.5 behobene Bugs, wobei die Problembilanz (gelöste Probleme bzw. Probleme, die wir durch neue Funktionen lösen können / neu geschaffene Probleme) nur sehr schleppend ins positive wandert, weil eben immer noch zu wenig Bugs und alte Prozesse (Beispiele: Dropshipping, Lieferantenkommunikation und Lieferanten-Logistik, Track & Trace, ebay-Anbindung,...) vollständig bzw. kontinuierlich optimiert werden.

...dass man keine Auftragsnummern auf Rechnungen kriegt...

Das sollte meines Wissens mittlerweile gehen (Ausgabe 2.0 und Wawi 1.8.11.2) mit:
Report.SalesOrderNumbers

...oder die Druckperformance zu killen. Und solche Probleme gibt es immer noch einige die es in dieser Form in der 1.5 nicht gab.

Ja eben, Ausgabe 2.0 ist ja auch nur in Teilen fertig, so dass man einige Vorlagen umstellen kann, andere wiederum nicht, das muss man aber bei jeder Vorlage erstmal einzeln nachschauen. Globale Bausteine muss man dann auch doppelt anlegen, damit diese in beiden Ausgabe-Versionen auch kompatibel sind (zumindest, wenn man mit Formeln zur Sichtbarkeit arbeitet).

Wie aussagekräftig ist so ein Thread tatsächlich, was die Stimmung angeht? Wie gesagt, wir haben mittlerweile tausende User auf der 1.8. Von denen liest man hier nicht gerade etwas. Eher von denen, die Probleme hatten oder haben.
Damit will ich wie gesagt nichts davon klein reden. Ganz im Gegenteil. Aber wenn wir im besten Falle sagen sollen "Hier sind Leute, die haben ein Problem, schauen wir, ob wir das gelöst bekommen" - dann muss das in einer Form geschehen, die auch reproduzierbar und nachvollziehbar ist, ohne dass man sich mittlerweile 5 Seiten mit Textwällen durchlesen muss, die nichts mit dem jeweiligen Problem zu tun haben.

Wäre ja auch schlimm, wenn wirklich alle auf der 1.5 bleiben würden. Aber seltsamer Weise gibt es ja scheinbar auch genug Service-Partner, die davon abraten von der 1.5 wegzugehen und offenbar auch einige Kunden, die lieber auf neue Features verzichten, als zu sagen "Super Version, muss ich haben".

Nur welche Variante ist denn jetzt die richtige, um tatsächlich Verbesserungen zu erreichen? Hier im Forum schreiben, Ticket schreiben, auf Tickets voten?
War jetzt bisher auch nicht immer wirklich zielführend...

Und ich kann mich da wieder nur wiederholen: Wir brauchen viele Themen vielleicht gar nicht mehr anfassen, weil sie schon in der 1.8 behoben wurden. Dafür müssen die User aber auch wieder schauen, ob sie noch Probleme haben oder ob es noch was zu machen gilt.

Nina und ich holen Euch gern die POs zu den Themen dazu, damit ihr Euch da austauschen könnt. Aber ihr müsst dann wissen, dass das Problem in der aktuellen Version noch vorhanden ist oder dass es ein neues Problem gibt.

Danke, das Angebot nehme ich gleich an ;) :p :
https://forum.jtl-software.de/threa...iste-teilweise-fehlerhaft.214861/post-1149598 (gut, ist nicht die 1.8, aber interessiert ja vielleicht trotzdem irgendwen)
https://forum.jtl-software.de/threa...gabe-2-0-diskussionsthema.183964/post-1149079
Rechtliche Umsetzung der PAnGV vom 28.05.2022 in der Wawi (nicht bloß auf JTL-Shop bezogen, insbesondere Preishistorie / Dokumentation von Preisänderungen, siehe z.B. Wettbewerb: https://blog.afterbuy.de/afterbuy/preisanpassungen-fuer-online-haendler-leicht-gemacht/)
https://forum.jtl-software.de/threads/dropshipping-automatisieren-fehler-im-guide.199966/ (Weiß nicht, ob es da soetwas wie einen PO gibt, aber vielleicht interessiert es ja auch trotzdem irgendwen)
https://forum.jtl-software.de/threads/zahungsabgleich-ebay-zahlungen-ueber-wawi-erstatten.168543
https://forum.jtl-software.de/threa...ungsaustausch-probleme-loesungen-ideen.197743

Sind zwar keine Threads, aber trotzdem teilweise Bug-Tickets aus der 1.5:
https://issues.jtl-software.de/issues/WAWI-62710
https://issues.jtl-software.de/issues/WAWI-55697 korreliert mit dem hier https://issues.jtl-software.de/issues/WAWI-48378
https://issues.jtl-software.de/issues/WAWI-56088 (besteht in der 1.8.11.2 noch bei Artikelzustandsänderungen, es wird mit dem Netto-EK in der Artikelhistorie des Zustandsartikels ausgebucht und mit dem dEK des Zustandsartikels im Zielzustandsartikel eingebucht, auch der dEK des neuen Zustandes wird meines Erachtens nicht verändert, obwohl dies der Fall sein müsste)
https://issues.jtl-software.de/issues/WAWI-53047
https://issues.jtl-software.de/issues/WAWI-43774
https://issues.jtl-software.de/issues/WAWI-29760
 

Enrico W.

Administrator
Mitarbeiter
27. November 2014
8.617
1.741
@Verkäuferlein
Ich geb das mal alles weiter, ABER: Bugs, welche in der 1.5 existieren oder Funktionen, die es in der 1.5 nicht gibt sind kein valider Grund, bei der 1.5 zu bleiben.
Gründe wären Funktionen, die in der 1.5 noch gingen, in der 1.6 aber nicht mehr.
 
Zuletzt bearbeitet:

SebiW

Sehr aktives Mitglied
2. September 2015
2.582
1.162
Hast du das Thema mit dem Auftragssplit mal irgendwo aufgegriffen? Oder das mit den Auftragsnummern auf Rechnungen?
Bei der Druckperformance, da weiß ich, dass es bei einigen Usern Probleme gab, bin aber nicht sicher, inwiefern sich das mittlerweile gebessert hat. Dafür bin ich zu wenig in diesem Bereich unterwegs.
Hu Du, nur um darauf kurz einzugehen, jo:

Auftragssplit:
https://issues.jtl-software.de/issues/WAWI-73916 fehlt uns noch
https://issues.jtl-software.de/issues/WAWI-53773 - da weiß ich dass die 1.8 das löst, wir selbst sind auch nur noch nicht auf der 1.8 weil der Shop Rollout alle Zeit gefressen hat.
Separate Threads dazu:
https://forum.jtl-software.de/threads/automatischer-auftragssplit-bei-teilversand.209818/
https://forum.jtl-software.de/threads/keine-workflows-bei-teillieferung-mehr-moeglich.202519/
War ich auch in Kommunikation mit Euch, find ich nicht mehr.

Auftragsverweis auf Rechnung:
https://issues.jtl-software.de/issues/WAWI-73728 habt Ihr reingenommen, musste aber aus Performancegründen in den neueren 1.8ern wieder raus.

Sehr sehr weh getan hat uns damals MHD Umlagerung:
https://issues.jtl-software.de/issues/WAWI-71938 - mittlerweile gefixed, mein Ticket dazu war die 2023090610001231

Unsauber läuft bei uns noch Gratisartikel verpacken:
https://issues.jtl-software.de/issues/WAWI-69051 - mein Ticket dazu war die 2023081710000464

Sehr blöd in unseren Prozessen ist noch der Paketsplit:
https://issues.jtl-software.de/issues/WAWI-68645 - mein Ticket dazu ist die 2023032810000354

Will sagen, dass es Gemeinschaftsthreads gibt in dem man sich mal gesammelt über Probleme unterhält schließt ja keineswegs aus dass die entsprechenden Probleme einzeln besprochen und gemeldet wurden ;)
 

Star Piercing

Sehr aktives Mitglied
1. Dezember 2012
1.338
362
Ich bin ja auch jemand der gerne mal etwas kritisch gegenüber JTL ist, aber bisher hat sich ein wechsel auf die 1.8 für uns gelohnt.
Es kommt wohl auch immer drauf an was man alles nutzt.
Wir haben z.B. keine Probleme mit dem Worker.
Die Erstellung von Kinderartikeln wurde echt gut umgesetzt und da möchte ich keine 1.5 mehr.

Finde es auch wichtig das JTL sich nicht auf 4 verschiedene Versionen konzentrieren sollte, sondern Fokus auf die "neue" Wawi hat und versucht dort endlich die vielen Bugs und Fehler zu beheben, dann wären wohl alle glücklich.
Aber auch bei uns ist immer ein komisches Gefühl wenn wir Updates machen und betten das alles läuft. JTL ist wohl manchmal einfach nicht klar was es für ein Betrieb bedeutet wenn eine Funktion einfach plötzlich nicht mehr funktioniert.
 
  • Gefällt mir
Reaktionen: frankel und SebiW

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.436
938
@Verkäuferlein
Ich geb das mal alles weiter, ABER: Bugs, welche in der 1.5 existieren oder Funktionen, die es in der 1.5 nicht gibt sind kein valider Grund, bei der 1.5 zu bleiben.
Gründe wären Funktionen, die in der 1.5 noch gingen, in der 1.6 aber nicht mehr.

Ich gebe ja zu, ich habe es etwas augedehnt und teilweise aus der anderen Richtung betrachtet und auch ein paar Themen benannt, die bei mir persönlich dazu führen würden, dass die Update-Bereitschaft steigt (z.B. Ausgabe 2.0, automatische ebay/Amazon-Erstattungen oder Verbesserungen bei Track & Trace).

Halt "Pull-Faktoren", also Optimierungen, die entweder Zeitfresser beseitigen, lange geplante Veränderungen ermöglichen oder Bugs beseitigen, über die man immer wieder stolpert.

Und ehrlich gesagt kann ich mich nicht mehr wirklich daran erinnern, welche Themen davon nach, während oder vor der 1.5 aufgetreten sind (zumal ja auch immer die Frage ist, wann man die Probleme entdeckt und ob es einem vorher schon aufgefallen wäre).

Wir haben vieles auch mit der Pilot 1.6 gemeldet.

Kern der Aussage soll halt sein: "Es benötigt funktionierende Prozesse, um Updatebereitschaft zu erzeugen. Ansonsten verlasse ich meine halbwegs funktionierenden Prozesse, die sich rund um Bugs und Funktionseinschränkungen gebildet haben, halt ungerne."
 
  • Gefällt mir
Reaktionen: SebiW

frankel

Sehr aktives Mitglied
2. Dezember 2012
140
43
@frankel Ich möchte kurz darlegen, warum ich mit diesen Sammelthreads ein Problem habe.
Ja, Ärger ist verständlich und Kritik wichtig. Aber: Zum einen redet ihr hier über eine Version, die mittlerweile als veraltet zu betrachten ist. Es wird in der 1.6 keine Änderungen geben. Ihr berücksichtigt nicht, dass es möglicherweise aufgrund der Rückmeldungen bereits Änderungen in den aktuellen Versionen gibt. Diskussionen sind schwer bis unmöglich mitzuverfolgen. Threads oder Tickets, die sich auf 1, 2 Themen fokussieren, sind da wesentlich besser mitzuverfolgen.
Was wäre also die Lösung?
Für Bugs einzelne Tickets. Warum? Die Themen/Bereiche liegen ggf. in unterschiedlichen Fachbereichen und müssen von verschiedenen Teams umgesetzt werden. Aber auch hier muss vorab geprüft werden, ob der Bug in der aktuellen Version überhaupt noch vorhanden ist.
Für Kritik/Änderungswünsche einzelne Threads/Tickets. Warum? Weil ein solcher Sammelthread wie oben bereits gesagt, nicht geeignet ist, um eine sachliche Diskussion zu führen. Das zeigt die Erfahrung zur Genüge.
Dass ihr nur updatet wenn ihr sicher seid - das ist richtig. Das ist wichtig. Und das ist verständlich. Aber dann wieder zu einer mittlerweile auch veralteten Version? Baut euch ein mal ein Testsystem. Spielt dort die Datenbanksicherung ein und prüft Eure Vorgänge mit der aktuellen Version (ohne etwas zu versenden oder abzugleichen!). Und entscheidet dann.
Die 1.5 ist abgeschlossen, der Support dafür wird eingestellt. Daran gibt es keine Änderungen mehr. Auch an der 1.6 wird es keine Änderungen mehr geben, es sei denn, es ist ein wirklich dringender Hotfix notwendig. Und selbst dann wird diese Version nur den Hotfix als Änderung beinhalten. Beides ist aber mit Blick auf das Alter der Version relativ unwahrscheinlich. Auch wird früher oder später für die 1.6 der Support eingestellt werden. Um mit einer Metapher zu sprechen: Ihr wollt von einem toten Pferd eventuell absteigen, um auf das nächste aufzusatteln, welches kurz vor dem Schlachthof steht und dann noch beschweren, dass dieser Gaul keine Zähne mehr hat.
Daher noch mal mein dringender Rat: Schaut euch die aktuelle Version an. Prüft, ob diese für Euch Probleme bereithält. Prüft, ob sich darin bereits bestehende Probleme erledigt haben. Und gibt es noch Wünsche/Probleme in dieser Version, dann tragt diese an uns heran.
Das Problem für uns war die Menge an negativen Veränderungen, die es einfach zeitlich nicht mehr zugelassen haben, diese alle nieder zu schreiben. Im Übrigen haben wir seit Monaten ein Problem mit der Erreichbarkeit des JTL-Forums. Keine Ahnung, warn das plötzlich liegt. Den Support interessiert das leider überhaupt nicht. Da hören wir nur, das Forum sei erreichbar. Uns ist es jedenfalls seit längerer Zeit nicht mehr möglich, hier regelmäßig mitzuwirken.
Das größte Problem dürfte jedoch darin liegen, dass einige das Vertrauen in Updates verloren haben werden. Für uns gilt das ganz sicher. Wenn ich sehe, was wir seit mehreren Monaten für Probleme, sowohl mit dem Shop als auch mit der Wawi haben, das macht keinen Spaß mehr. Jahrelang ging das ganz anders. Wir haben nur noch größeres Sorgen, was wir uns mit dem nächsten Update einhandeln. Schade, dass es so gekommen ist.
 

frankel

Sehr aktives Mitglied
2. Dezember 2012
140
43
Guten Morgen,

mich würden hier mal die "zum fremdschämenden rechtlichen Behauptungen seitens JTL" interessieren?

Das Beispiel mit der Lieferadresse und Umsatzsteuer-ID finde ich gut: BEIDE Daten haben unter Umständen einen Einfluss auf die Mehrwertsteuer. Am Ende hat man zwei Rechnungen versendet, beide mit gleicher Rechnungsnummer, beide mit unterschiedlichen steuerlichen Werten.

Ist der folgende Prozess wirklich so schlimm, dass man lieber Rechnungen bearbeiten möchte und sich damit evtl. Ärger einhandelt?

Rechnung > Rechtsklick > Stornieren > Neu ausstellen > Storno begründen > "genau die Daten ändern die du ändern möchtest" > Speichern und Festschreiben

Um buchhalterisch korrekt zu sein hat man (aus meiner Sicht) einen Mehraufwand von einem Rechtsklick und der Auswahl eines Grundes.


Gruß,
Markus
Hallo,
die rechtliche Diskussion wärme ich hier nicht wieder auf. Erstens möchte ich denjenigen nicht vorführen und zweitens fehlen den Mitarbeitern im Forum in der Regel die notwendigen Kenntnisse für eine zielführende Diskussion.
Also bleiben wir lieber bei der praxisrelevanten Betrachtung. Deine Argumentation ist unschlüssig. Wenn Du davon ausgehst, dass man eine fehlerhafte Rechnung rausschickt, hilft stornieren auch nichts mehr. Dann ist sie so oder so raus.
Also entweder korrigiere ich eine Rechnung bevor ich sie rausschicke und schicke sie erst los, wenn sie korrekt ist oder - für den Fall, dass eine fehlerhafte Rechnung bereits unterwegs ist - erstelle ich eine Rechnungskorrektur. Eine Rechnung zu stornieren ist so ziemlich das letzte was wir tun möchten. Selbst mit Begründung sieht das bei einer Prüfung nicht besonders gut aus. Ist auch völlig unnötig, weil man nur den Tippfehler korrigieren bräuchte.
Aber der wesentliche Punkt ist: Wir benötigen keinen Programmierer, der uns vor uns selbst schützt! Wir können die Führung unseres Unternehmens schon sehr gut selbst verantworten.

Grüße
Frank
 

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.436
938
Also bleiben wir lieber bei der praxisrelevanten Betrachtung. Deine Argumentation ist unschlüssig. Wenn Du davon ausgehst, dass man eine fehlerhafte Rechnung rausschickt, hilft stornieren auch nichts mehr. Dann ist sie so oder so raus.
Also entweder korrigiere ich eine Rechnung bevor ich sie rausschicke und schicke sie erst los, wenn sie korrekt ist oder - für den Fall, dass eine fehlerhafte Rechnung bereits unterwegs ist - erstelle ich eine Rechnungskorrektur. Eine Rechnung zu stornieren ist so ziemlich das letzte was wir tun möchten. Selbst mit Begründung sieht das bei einer Prüfung nicht besonders gut aus. Ist auch völlig unnötig, weil man nur den Tippfehler korrigieren bräuchte.

Das siehst Du aber leider falsch.
Die Funktion in der Wawi ist ja eben, dass die Rechnung in einem Schritt über eine Storno-RE / Rechnungskorrektur widerrufen wird und eine neue Rechnung mit neuer Rechnungsnummer ausgestellt wird.

Das ist auch der einzig praktikable Weg, der über die Wawi abgebildet werden kann, weil Du eine digital verschickte Rechnung nicht einfach zurückholen / korrigieren kannst, zumal Du dies ja auch bei Dir selber dokumentieren müsstest.

Und wir gehen jetzt mal von weitestgehend digitalen Prozessabläufen aus.

Der einzige digitale Weg wäre, eine ergänzende / korrigierende e-Mail zu der Rechnung zu versenden und diese ebenfalls zu archivieren, das ist aber deutlich mehr Aufwand, als die One-Klick-Lösung zur Neuausstellung von JTL.

Wenn die Wawi aber GoBD-konform arbeiten soll, darf sie keine undokumentierten Änderungen an den ursprünglichen Originaldaten zulassen.

Aber der wesentliche Punkt ist: Wir benötigen keinen Programmierer, der uns vor uns selbst schützt! Wir können die Führung unseres Unternehmens schon sehr gut selbst verantworten.

Da steht aber leider der Gesetzgeber ein wenig im Weg.

Wenn Du nicht GoBD-konform arbeiten willst oder einen anderen Weg wählst, ist es ja Dir überlassen. Wenn aber deshalb die Software zum Angriffspunkt für das FA wird, dann ist es halt Aufgabe von JTL und vom Programmierer, dies zu ändern und zu verhindern.
 

frankel

Sehr aktives Mitglied
2. Dezember 2012
140
43
Das siehst Du aber leider falsch.
Die Funktion in der Wawi ist ja eben, dass die Rechnung in einem Schritt über eine Storno-RE / Rechnungskorrektur widerrufen wird und eine neue Rechnung mit neuer Rechnungsnummer ausgestellt wird.

Das ist auch der einzig praktikable Weg, der über die Wawi abgebildet werden kann, weil Du eine digital verschickte Rechnung nicht einfach zurückholen / korrigieren kannst, zumal Du dies ja auch bei Dir selber dokumentieren müsstest.

Und wir gehen jetzt mal von weitestgehend digitalen Prozessabläufen aus.

Der einzige digitale Weg wäre, eine ergänzende / korrigierende e-Mail zu der Rechnung zu versenden und diese ebenfalls zu archivieren, das ist aber deutlich mehr Aufwand, als die One-Klick-Lösung zur Neuausstellung von JTL.

Wenn die Wawi aber GoBD-konform arbeiten soll, darf sie keine undokumentierten Änderungen an den ursprünglichen Originaldaten zulassen.



Da steht aber leider der Gesetzgeber ein wenig im Weg.

Wenn Du nicht GoBD-konform arbeiten willst oder einen anderen Weg wählst, ist es ja Dir überlassen. Wenn aber deshalb die Software zum Angriffspunkt für das FA wird, dann ist es halt Aufgabe von JTL und vom Programmierer, dies zu ändern und zu verhindern.
Das ist schlichtweg falsch.
1. GoBD-konformes Arbeiten verlangt das nicht.
2. Es geht überhaupt nicht darum, eine digital verschickte Rechnung zurückzuholen. Es geht einzig darum, eine noch nicht versandte Rechnung zu ändern. Dafür gibt es rechtlich überhaupt keine Hindernisse. Nur leider mittlerweile überflüssige durch die Wawi.
3. Keine Ahnung, warum Du digitale Prozessabläufe voraussetzt. Davon war in meinem Kommentar nichts geschrieben.
4. Die Einschränkungen auf das GoBD-konforme Arbeiten beziehen sich auf digitale Archivierung. Das ist ein ganz anderes Thema. Davon spreche ich hier nicht.

Ich habe extra oben geschrieben, dass wir uns auf die praktische Anwendbarkeit beziehen. Rechtliche Diskussionen ohne die entsprechenden Kenntnisse sind nicht zielführend. Übrigens: Sich hinsichtlich einer GoBD-konformen Archivierung auf die Wawi (bzw. den Programmierer) zu verlassen, wäre absolut nicht zu empfehlen. Aber um dieses Thema geht es hier, wie gesagt, überhaupt nicht.

Viele Grüße
Frank
 

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
2.436
938
1. GoBD-konformes Arbeiten verlangt das nicht.

Aha, warum denn nicht? Worauf beziehst Du Dich?
Ich würde Dir dringend empfehlen, Dich mal mit einem entsprechend versierten Steuerberater / Steuerfachmann darüber zu unterhalten.

2. Es geht überhaupt nicht darum, eine digital verschickte Rechnung zurückzuholen. Es geht einzig darum, eine noch nicht versandte Rechnung zu ändern. Dafür gibt es rechtlich überhaupt keine Hindernisse. Nur leider mittlerweile überflüssige durch die Wawi.

Doch, bei digitalen Abläufen erstellt eben keiner händisch die Rechnung und druckt sie aus, sondern diese geht automatisch per Mail raus und ist damit faktisch unveränderlich und kann nur durch Zusatzdokumente "geändert" werden.

Aber wo genau ist denn dann Dein Problem bei der händischen Erstellung?
Dann prüfst Du den Auftrag / die Rechnung entweder bevor Du sie erstellst und damit festschreibst, Du nimmst einen Kugelschreiber, änderst die Rechnung, machst eine Kopie und archivierst diese oder stornierst die Rechnung in der Wawi und stellst eine neue aus.
Es stehen Dir also alle Wege offen.

3. Keine Ahnung, warum Du digitale Prozessabläufe voraussetzt. Davon war in meinem Kommentar nichts geschrieben.

Weil es sich um eine Warenwirtschaft in erster Linie für den Onlinehandel handelt und dann in der Regel analoge Abläufe eher hinderlich sind bzw. zusätzlichen Aufwand bedeuten. Die Rechnung ist da eher eine Formalie, die eben genau den ausgeführten Auftrag wiedergibt und im Regelfall nicht geändert werden muss.

Dementsprechend sind auch die Prozesse der Wawi weitestgehend darauf ausgerichtet.

4. Die Einschränkungen auf das GoBD-konforme Arbeiten beziehen sich auf digitale Archivierung. Das ist ein ganz anderes Thema. Davon spreche ich hier nicht.

Dazu verweise ich nochmal auf #1.
GoBD = Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff
Das ist eine Verwaltungsvorschrift, die beschreibt, wie EDV-Systeme, "die steuerrelevante Daten direkt oder indirekt erfassen oder verarbeiten" arbeiten sollten und die drumherum gelagerten Prozesse zu gestalten sind, um die Beweiskraft der Buchführung sicherzustellen.

Da Du Deine Geschäftsvorfälle und die Rechnungsstellung über die Wawi abwickelst, gibt es da verschiedene Interpretationen und im Zweifelsfall wirst Du das mit einem Steuerprüfer bzw. dem FA diskutieren müssen.
Darauf habe ich persönlich wenig Lust und wenn ich es unbedingt muss, bin ich gerne möglichst nahe an den GoBD und Wünschen des FA orientiert, um entweder gar nicht diskutieren zu müssen, sondern gleich die passenden Argumente in Form der Erfüllung von Anforderungen zu haben oder ggf. auch eine entsprechende Argumentation vor Gericht darlegen zu können.

Ich habe extra oben geschrieben, dass wir uns auf die praktische Anwendbarkeit beziehen. Rechtliche Diskussionen ohne die entsprechenden Kenntnisse sind nicht zielführend. Übrigens: Sich hinsichtlich einer GoBD-konformen Archivierung auf die Wawi (bzw. den Programmierer) zu verlassen, wäre absolut nicht zu empfehlen. Aber um dieses Thema geht es hier, wie gesagt, überhaupt nicht.

Und nochmal: Es geht um die "ordnungsmäßige Führung und Aufbewahrung" und damit Beweiskraft Deiner Buchführung.
Die Erfüllung der GoBD ist Deine "Pflicht" bzw. erleichtert Dir den Alltag. Dabei ist es hilfreich, wenn sich alle eingesetzten EDV-Systeme möglichst nahe an den Verwaltungsvorgaben orientieren.
Wenn Du davon abweichen willst, kannst Du das machen. Aber wenn JTL das pauschal in der Wawi macht, hat das potenziell massive Nachteile für alle anderen Nutzer.

Du kannst uns ja aber gerne mal Deine "entsprechenden Kenntnisse" darlegen, die Dich Deiner Ansicht nach von den entsprechenden Verpflichtungen entbinden.
 
  • Gefällt mir
Reaktionen: mvh

schraubenking

Gut bekanntes Mitglied
4. Februar 2011
305
19
Servus aus AT,
hab mir eure GoBD mal durchgeschaut und hier nicht gefunden, was ein "einfrieren" eines Auftrags / der Rechnung vor dem Rechnungsversand oder bei Warenversand fordern würde. Hier lese ich nur, dass die Rechnung noch nicht abgeschickt sein darf (und dies wäre per Workflow ganz einfach zu lösen). Vom eigentlichen Warenversand finde ich hier nichts zu lesen.....?

Unbenannt.JPG
Hier auch der Link:https://ao.bundesfinanzministerium....tende-Laendererlasse/Anhang-64/anhang-64.html

Es gibt leider sehr viele plausible und nachvollziehbare Geschäftsfälle, welche ein Zusammenfassen von Aufträgen zu einer Rechnung nötig macht (bzw. das Leben einfacher gestaltet) und es gibt zumindest lt. meinen "erlesenen Erkenntnissen" aktuell keinen Grund dies so umzusetzen.

Zusammenfassend hat sich JTL bei der Umsetzung zwar ein "Fleißsternchen" vom Finanzminister verdient, müsste aber nicht sein und stellt viele JTL Kunden vor Probleme.

Markus
 

frankel

Sehr aktives Mitglied
2. Dezember 2012
140
43
Aha, warum denn nicht? Worauf beziehst Du Dich?
Ich würde Dir dringend empfehlen, Dich mal mit einem entsprechend versierten Steuerberater / Steuerfachmann darüber zu unterhalten.



Doch, bei digitalen Abläufen erstellt eben keiner händisch die Rechnung und druckt sie aus, sondern diese geht automatisch per Mail raus und ist damit faktisch unveränderlich und kann nur durch Zusatzdokumente "geändert" werden.

Aber wo genau ist denn dann Dein Problem bei der händischen Erstellung?
Dann prüfst Du den Auftrag / die Rechnung entweder bevor Du sie erstellst und damit festschreibst, Du nimmst einen Kugelschreiber, änderst die Rechnung, machst eine Kopie und archivierst diese oder stornierst die Rechnung in der Wawi und stellst eine neue aus.
Es stehen Dir also alle Wege offen.



Weil es sich um eine Warenwirtschaft in erster Linie für den Onlinehandel handelt und dann in der Regel analoge Abläufe eher hinderlich sind bzw. zusätzlichen Aufwand bedeuten. Die Rechnung ist da eher eine Formalie, die eben genau den ausgeführten Auftrag wiedergibt und im Regelfall nicht geändert werden muss.

Dementsprechend sind auch die Prozesse der Wawi weitestgehend darauf ausgerichtet.



Dazu verweise ich nochmal auf #1.
GoBD = Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff
Das ist eine Verwaltungsvorschrift, die beschreibt, wie EDV-Systeme, "die steuerrelevante Daten direkt oder indirekt erfassen oder verarbeiten" arbeiten sollten und die drumherum gelagerten Prozesse zu gestalten sind, um die Beweiskraft der Buchführung sicherzustellen.

Da Du Deine Geschäftsvorfälle und die Rechnungsstellung über die Wawi abwickelst, gibt es da verschiedene Interpretationen und im Zweifelsfall wirst Du das mit einem Steuerprüfer bzw. dem FA diskutieren müssen.
Darauf habe ich persönlich wenig Lust und wenn ich es unbedingt muss, bin ich gerne möglichst nahe an den GoBD und Wünschen des FA orientiert, um entweder gar nicht diskutieren zu müssen, sondern gleich die passenden Argumente in Form der Erfüllung von Anforderungen zu haben oder ggf. auch eine entsprechende Argumentation vor Gericht darlegen zu können.



Und nochmal: Es geht um die "ordnungsmäßige Führung und Aufbewahrung" und damit Beweiskraft Deiner Buchführung.
Die Erfüllung der GoBD ist Deine "Pflicht" bzw. erleichtert Dir den Alltag. Dabei ist es hilfreich, wenn sich alle eingesetzten EDV-Systeme möglichst nahe an den Verwaltungsvorgaben orientieren.
Wenn Du davon abweichen willst, kannst Du das machen. Aber wenn JTL das pauschal in der Wawi macht, hat das potenziell massive Nachteile für alle anderen Nutzer.

Du kannst uns ja aber gerne mal Deine "entsprechenden Kenntnisse" darlegen, die Dich Deiner Ansicht nach von den entsprechenden Verpflichtungen entbinden.
Danke für die Empfehlung, aber im Gegensatz zu dir bin ich diesbezüglich vom Fach und kann das schon beurteilen.
Nenn mir einfach eine gesetzliche Regelung, die es verbietet, Änderungen an einer noch nicht in den Umlauf gebrachten Rechnung vorzunehmen (Du hast ja behauptet, der Gesetzgeber stände dem entgegen).
Wundere dich nicht, wenn Du keine findest. Weitere Laiendiskussionen werde ich mit dir nicht führen. Sowas ist grundsätzlich nicht zielführend.

Grüße
Frank
 

frankel

Sehr aktives Mitglied
2. Dezember 2012
140
43
Servus aus AT,
hab mir eure GoBD mal durchgeschaut und hier nicht gefunden, was ein "einfrieren" eines Auftrags / der Rechnung vor dem Rechnungsversand oder bei Warenversand fordern würde. Hier lese ich nur, dass die Rechnung noch nicht abgeschickt sein darf (und dies wäre per Workflow ganz einfach zu lösen). Vom eigentlichen Warenversand finde ich hier nichts zu lesen.....?

Den Anhang 106717 betrachten
Hier auch der Link:https://ao.bundesfinanzministerium....tende-Laendererlasse/Anhang-64/anhang-64.html

Es gibt leider sehr viele plausible und nachvollziehbare Geschäftsfälle, welche ein Zusammenfassen von Aufträgen zu einer Rechnung nötig macht (bzw. das Leben einfacher gestaltet) und es gibt zumindest lt. meinen "erlesenen Erkenntnissen" aktuell keinen Grund dies so umzusetzen.

Zusammenfassend hat sich JTL bei der Umsetzung zwar ein "Fleißsternchen" vom Finanzminister verdient, müsste aber nicht sein und stellt viele JTL Kunden vor Probleme.

Markus
Hallo Markus,
das hast Du sehr richtig festgestellt. Wie ich schon an verschiedenen Stellen angemerkt habe, existiert keine Vorschrift, die das Ändern einer noch nicht in Umlauf gebrachten Rechnung verbietet.
In Deutschland ist aber mittlerweile fast jeder, der Internet hat, Hobbyjurist oder/und Hobysteuerfachmann und scheut sich nicht davor, irgendwelche Behauptungen, die auf Unwissen oder Teilwissen beruhen, in den Umlauf zu bringen.
Ganz schlimm war das auch, was teilweise zur DSGVO von manchen verbreitet wurde. Softwareunternehmen neigen dann teilweise dazu, in Unkenntnis Regelungen fehlerhaft oder übertrieben auszulegen. Das ist manchmal etwas schwierig in unserem Lande. Unglücklich ist es eben, wenn durch so etwas die Usability unnötig eingeschränkt wird.
Grüße Frank
 
Status
Es sind keine weiteren Antworten möglich.
Ähnliche Themen
Titel Forum Antworten Datum
Neu JTL Exportformat Google Shopping v2.2.2 - Export bleibt bei 500 Artikeln stehen und wird nicht final durchgeführt Plugins für JTL-Shop 0
[Bug] Zertifikatsnummern werden übertragen, der Button bleibt aber ausgegraut Otto.de - Anbindung (SCX) 0
Neu Datenexport von Rechnungskorrekturen bleibt leer JTL Ameise - Eigene Exporte 0
Neu [Bug] Nachschub: Artikelbezeichnung bleibt hängen (1.9.4.6) JTL-WMS / JTL-Packtisch+ - Fehler und Bugs 0
Neu Freitexteingabe durch Kunde bei bestimmten Variationen User helfen Usern - Fragen zu JTL-Wawi 0
Neu Warum kann ich bei Druckvorlagen die Seitengröße nicht anpassen? Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 1
Beantwortet Hilfe bei SQL Abfrage erbeten User helfen Usern - Fragen zu JTL-Wawi 3
Neu Brauche Hilfe bei einen Workflow in Sachen Versand Eigene Übersichten in der JTL-Wawi 3
Neu Ebay Verkäufe - Auswahlartikel mit händischer Auswahl in der Rechnung - wie bei Wawi 1.9 vorgehen ?! Arbeitsabläufe in JTL-Wawi 0
Fehler bei Hochladen der Versanddaten Otto.de - Anbindung (SCX) 0
Wawi bei ecomData gehostet- Druckprobleme JTL-Wawi 1.8 3
Neu System.ArgumentNullException bei Ameise Import (Konfigurationsgruppen zuordnen) JTL-Wawi - Fehler und Bugs 1
Neu Stücklistenartikel bei Einkauf auflösen? User helfen Usern - Fragen zu JTL-Wawi 2
Neu Seit gestern Meldung: Problems creating SAAJ object model mit Export bei Internetmarke JTL-Track&Trace - Fehler und Bugs 2
Neu Prestashop Connector 2.0.0 ignoriert deaktivierte Überverkaufseinstellung bei Artikelupload PrestaShop-Connector 0
Eigene USt-IdNr. fehlt in der Auftragsansicht bei Auslandsbestellungen (JTL-Wawi 1.8.12.2) JTL-Wawi 1.8 3
Neu Ameise bricht ab bei leeren feldern JTL-Ameise - Fehler und Bugs 2
Neu Es ist nicht mehr möglich Artiekl bei eBay einzustellen Code 240 und Code 21920203 eBay-Anbindung - Fehler und Bugs 2
Versandkostenfrei bei hinzufügen eines Bestimmten Artikels Einrichtung JTL-Shop5 2
Problem bei Upgratevon Shop 4 auf shop 5 (SQLSTATE[42000]) Upgrade JTL-Shop4 auf JTL-Shop5 2
Neu Wareneingangsdatum bei Umlagerungen zwischen zwei WMS-Lagern Arbeitsabläufe in JTL-WMS / JTL-Packtisch+ 0
Neu Versandproblem bei unterschiedlichen Produkten und Gewichten Allgemeine Fragen zu JTL-Shop 0
Neu Kunde zahlt bar bei Anlieferung, wie löse ich das? Arbeitsabläufe in JTL-Wawi 11
Neu E-Commerce Manager (m/w/d) für den Zweiradbereich bei MSZweirad in Heinsberg Dienstleistung, Jobs und Ähnliches 0
Neu IT-Administrator (m/w/d) gesucht bei MSZweirad in Heinsberg Dienstleistung, Jobs und Ähnliches 0
In Bearbeitung Luxusfrage, CUT Befehl bei Gutscheinen? Allgemeine Fragen zu JTL-POS 2
Neu Fehler bei Update: "SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'emails' already exists" Installation / Updates von JTL-Shop 2
Neu Bug bei Konfigurationsartikeln. Wenn Warenkorb nicht leer, Teile der Konfigurationsartikel-Optionen auf englisch. JTL-Shop - Fehler und Bugs 0
Neu HT-Zugriff fehlgeschlagen bei 'Erscheint am' JTL-Ameise - Fehler und Bugs 1
In Diskussion Problem mit Steuerberechnung bei Freieretoure auf Tagesbericht und in Statistiken JTL-POS - Fehler und Bugs 4
Neu Falsche Steuersätze bei Amazon FBA Rechnungen | Problem: Versandland?! JTL-Wawi - Fehler und Bugs 1
Neu Wiederholtes Anmelden bei office365 nötig User helfen Usern - Fragen zu JTL-Wawi 1
Neu Statt Preis nur Preis auf Anfrage bei B2B Fehler JTL-Shop - Fehler und Bugs 1
Fehler bei JTL-Update (1.5.55.8 -> 1.7.15.6) "Arithmetischer Überlauffehler beim Konvertieren von expression in den int-Datentyp." JTL-Wawi 1.7 7
Neu Was ist eine Sinnvolle Artikelverwaltung bei Kleinteilen? User helfen Usern 2
In Diskussion Versand bei Selbstabholern per Worker setzen JTL-Workflows - Fehler und Bugs 3
Neu Falsche Preise bei ebay eBay-Anbindung - Fehler und Bugs 0
Neu Bei Verkaufskanaldeaktivierung eines Child-Artikels löscht Prestashop Connector 2.0.0 den Parent-Artikel samt aller Child-Artikel des Parents PrestaShop-Connector 0
Neu Probleme in der mobilen Ansicht bei zwei Artikeln Allgemeine Fragen zu JTL-Shop 4
Neu Fehler bei Abgleich von Kategorien zu Shopify Shopify-Connector 0
Verwiesen an Support Versandarten sind doppelt bei Workflows vorhanden JTL-Workflows - Fehler und Bugs 4
Neu Domain für JTL Shop bei externem Hoster Allgemeine Fragen zu JTL-Shop 3
Neu Hosting der SQL-DB bei JTL User helfen Usern - Fragen zu JTL-Wawi 6
Neu Wieso gibt es keine Maßeinheit "Stück" bei eBay-Vorlagen eBay-Anbindung - Fehler und Bugs 0
Neu Workflow Zahlung setzen bei Rechnungskorreturen bzw. Retouren User helfen Usern - Fragen zu JTL-Wawi 0
Neu Automatische Kundengruppen Zuteilung bei Code Eingabe Allgemeine Fragen zu JTL-Shop 2
Neu weiße Seite Artikelsticker bei Upload von Artikelstickern JTL-Shop - Fehler und Bugs 2
Neu PayPal Checkout 1.5.0 - doppelte Texte bei Standardzahlarten Kreditkarte und SEPA Plugins für JTL-Shop 2
Neu Mindestbestelleinheiten bei Dropshipping-Lieferanten User helfen Usern - Fragen zu JTL-Wawi 2
Neu Versanddatenexport (1.8.12.2) bei Prime geht nicht mehr Amazon-Anbindung - Fehler und Bugs 3

Ähnliche Themen