DANKE, schauen wir uns an.
VG
David
@matthiasewald noch mal DANKE für den Flow. Wir haben das jetzt umgesetzt aber sind noch nicht 100% am Ziel.
JA - das SW setzt nun die Bestellung SOFORT auf “Abgebrochen”
ABER:
es wird immer noch eine Bestellbestätigung an uns und den Kunden verschickt
es kommt nun die Bestellung als “storniert” ins JTL
Wie bekommen wir es hin das:
Die Bestellungen NICHT mehr ins JTL kommen
Die Bestellbestätigun NICHT mehr versendet wird
Hast du da eine Idee?
DANKE
VG
David
Moin @abaddon-mysticstore,
bei dem Versand der Bestellbestätigung müsstet ihr dann den Flow anpassen, welcher eben für den Versand dieser zuständig ist. Da könntet ihr eine Bedingung vor die Aktion setzen. Der Trigger wäre in diesem Falle: “checkout.order.placed”.
Gibt es einen Filter, den ihr setzen könnt welche Aufträge ihr übertragen lassen wollt? Das müsste ich gerade nachschauen und habe gerade kein passendes Testsystem dafür.
In JTL selber kann ein Auftrag leider nicht durch einen Workflow storniert werden. Das geht leider nur manuell.
Dann bleibt aus meiner Sicht “nur” noch die Möglichkeit über ein eigenes Plugin zb. eine weitere Flow Aktion zu ergänzen, welche eben den Auftrag auch komplett löscht. Oder einen Cronjob mit einem Script im Hintergrund, welches Abgebrochene Aufträge löscht - hierbei gibt es allerdings dann wieder die Gefahr der Überschneidung, sodass der Auftrag abgerufen wird von JTL, bevor dieser gelöscht wurde im System.
Ich gehe davon aus, dass die Aufträge nicht storniert sein sollen, da ihr pro Auftrag zahlt?
Grüße
Matthias
Ja genau das ist eines der HAUPTPROBLEME, das wir im JTL für jeden Auftrag zahlen!
OK, versuchen wir.
DANKE, und viele Grüße
David
Mal ne Zwischenfrage, ist bei Zahlstatus “Fehlgeschlagen” und die beiden anderen “offen”, der Bestand bereits geblockt?
Müsste ich dann die beiden anderen auf “abgebrochen“ stellen und kann den Zahlstatus auf “Fehlgeschlagen“ so lassen?
MFG Flo
ich denke es gibt keinen Unterschied zwischen abgebrochen und fehlgeschlagen
Sobald eine Bestellung den Bestellstatus offen hat, ist der Bestand vom verfügbaren Bestand abgezogen. Nur ein Abgebrochen im Bestellstatus setzt den Bestand zurück. Der Zahlungsstatus hat darauf kein Einfluss.
1 „Gefällt mir“
Wie hast du das denn gelöst bei dir?
Über die Flows kann man die andere Status ändern, wenn ein Status, bspw. der Zahlungsstatus, einen bestimmten Status erhält.
Dann ist vielleicht Shopware nichts für dich. Wie wäre es mit dem JTL-Shop? Engagierst dich bei denen bei den JTL-Shop mit Vorschlägen, dass ihr zu denen wechseln könnt?! Hier bezahlt man, so wie ich lese, nicht pro Auftrag.
Auch kann man probieren mehr Druck auf JTL aufzubauen, dass man mehr inklusive Bestellungen über externe Shops zu geringeren Preis bezahlt bzw. wenn über Kontingent dann weniger Cent pro Auftrag.
Ich weiß dass JTL bei der Lizenzumstellung viel Gegenwind hatte, vielleicht lässt sich an den Parameter der JTL Pakete noch was machen.
Moin @raymond-de,
doch bei JTL zahlst du pro Auftrag. Wird halt nur in Auftragspaketen abgerechnet. Das ist ja gerade das Hauptproblem gewesen.
Über welchen Kanal der Auftrag in die wawi kommt ist egal. Du hast Auftragskontingente, die du kaufst. Alle weiteren Aufträge werden dann mit einer zusätzlichen Summe x abgerechnet. Letztendlich bekommt JTL ja auch nichmal mehr Lizenzgebühren, wenn Du jetzt sagen würdest du wechselst dahin mit dem Shop. Ab einem bestimmten Tarif hast Du ohnehin alles mögliche mit enthalten 
@flundi81 die Frage mit dem Bestand hängt noch davon ab, ob Du die Lagerverwaltung nutzt oder nicht. Du kannst die Reservierungen auch deaktivieren, dann zählt nur noch das was das ERP zb meldet.
Grüße
Matthias
Okay alles klar. Und was soll geschehen, wenn es Shopware nicht ändert? Ich bleibe dabei auch mit JTL ins Gespräch zu gehen oder wie ich bereits geschrieben habe:
Wir haben programmiert, das die Bestellungen mit fehlgeschlagenen oder abgebrochenen Zahlungsstatus nicht an das ERP weitergehen werden. Die Kunden könnten sich ja auch in ihren Konto einloggen und die Bezahlung nochmal (hoffentlich dann erfolgreich) durchführen.
Ich kenne jetzt die Schnittstelle nicht, aber wenn über JTL Plugin gelöst ist es naheliegend JTL zu erklären, dass dort sinnvollerweise eingebaut wird bei welchem Stati die Bestellung an JTL gesendet/abgeholt werden sollte.
Zum Beispiel könnte ja JTL nur die Bestellungen berechnen die auch ausgeliefert wurden (bzw. mindestens eine Sendungsnummer generiert wurden) anstatt auch die zu berechnen die kurze Zeit später storniert wurden.
Moin,
kann man natürlich versuchen aber ich vermute, dass das nichts bringen wird. Da hier ja jetzt auch neue Investoren im Hintergrund sind und JTL dann im größeren Stil auf Umsatz verzichten würde. Generell denke ich, das man das vermutlich am einfachsten in Shopware unterbinden könnte mit einer Anpassung 
Beim JTL Shop weiß ich gerade gar nicht zu welchem Zeitpunkt die Bestellung angelegt werden.
Grüße
Matthias
Ich habe nochmal ein Update in meinen vorherigen Post gemacht.
Es läuft komplett über Rest API. Man kann auch den Filter in der Route anpassen und JTL einfach nur die Bestellungen geben, welche man auch übertragen möchte und die anderen einfach nicht mehr zurückgeben lassen Ich glaube das wäre mein Ansatz.
Ich verstehe leider nicht ganz was du meinst!
Bevor die Admin-API die Bestellungen an JTL Cloud Connector überträgt per Subscriber die Bestellungen filtern.
Warum kann der JTL Cloud Connector das nicht direkt einstellen, sondern man muss was programmieren (lassen)?
Wieso fragst du das im Shopware-Forum und nicht im JTL-Forum? 
JTL’s Blackbox ist alleinig deren Ding.
Dieses Thema wurde automatisch 30 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.