Servus, Connector: 2.9.5-RC Gambio: v.3.10.0.1 Eine Frage bzgl. des Connectors und Bestellimports: Aktuell werden alle Bestellungen von Gambio nach JTL über den Connector importiert. Leider eben auch Bestellungen die auf dem Gambio-Status "offen", "nicht bestätigt" etc. stehen - sprich alle Bestellungen. Wir würden es gerne so haben, dass nur bestimmt Bestellungen übergeben werden (die, die den Status "bezahlt" von Gambio) haben. Ist hier eine Einschränkung seitens Connector oder Gambio möglich? Oder ist jemandem ein Workaround o.ä. möglich? Edit: Ebenfalls wenn eine Bestellung bereits als "offen" importiert wird und anschließend die Bestellung im Gambio auf "bezahlt" gesetzt wird, erfolgt kein erneuter Abgleich/Überprüfung dieser Bestellung. Wäre dies möglich?
JTL holt Daten an allen Shopmechanismen vorbei direkt aus der Datenbank, wir haben da keinen Einfluss drauf.
Danke für die Antworten - habe parallel auch im JTL Forum nachgefragt. Dachte evtl. hat hier jemand bereits Erfahrungswerte o.ä.
Wir können auch oft mal was sagen, wenn JTL zum Beispiel die Shopdatenbank beim schreiben kaputtmacht, dann kann man das zum Beispiel analysieren. Wenn es aber um reine Lesevorgänge geht, dann passiert das ausserhalb unserer Sphäre.
Wir haben Erfahrungswerte: Das ist mit dem Connector nicht möglich. Du kannst dir nur, wenn du dich mit phar Archiven und Git Projekten auskennst, dir selbst was basteln, oder einen JTL Servicepartner beauftragen, der das kostenpflichtig umsetzt. Wir haben aber auch nach mehrmonatigem Suchen keinen gefunden, der WIRKLICH an den Connector rangeht und auch erfolgreich Plugins schreiben kann. Ich frage mich allerdings auch, warum du sowas haben möchtest. Folgende Szenarien kann ich mir vorstellen, bei der dein Wunsch störend ist: Ein Kunde bestellt per Vorkasse und bezahlt erst nach einer Woche. Weil die Bestellung nicht importiert wurde, ist der Artikel nicht reserviert, und es kommt zu einem Überverkauf. Mit zwei verbindlichen Kaufverträgen musst du vertragsbrüchig werden und handelst dir im schlimmsten Fall eine Schadensersatzklage ein. Das Finanzamt macht eine Steuerprüfung und fragt, warum du in der JTL Wawi keine fortlaufenden Bestellnummern hast. Nicht dass es da eine Rechtspflicht gibt, aber es hegt Verdacht und bringt dich in Erklärungsnot. Da sind fortlaufende Bestellnummern mit stornierten Aufträgen besser zu erklären
@L&B Bei uns ist eben der Fall, dass wir über den Gambio Shop verkaufen und unserer externer Versandienstleister JTL verwendet. Gambio und JTL ist jetzt per Connector verbunden - das Problem besteht aber, dass eben Bestellungen bspw. über Vorkasse bereits in JTL importiert werden obwohl diese noch auf "offen" stehen, da noch kein Zahlungseingang festgestellt wurde. Wird diese Bestellung nach einer Woche auf "bezahlt" gesetzt und könnte dann in den Versand gehen, findet keine Aktualisierung dieser Bestellung/Auftrags in JTL statt - somit steht in JTL noch Zahlungseingang "nein". Dem Problem entgegenzuwirken wäre aus meiner Sicht eben: 1) Nur Bestellungen zu importieren die im Gambio auf "bezahlt" stehen 2) Eine Aktualisierung der Bestellung bzw. Prüfung der Stati von bereits importierten Bestellungen Aber wie ich es hier rauslese bestehen diese Möglichkeiten eben einfach nicht.
@sccfahrzeugtechnik L&B hat völlig recht mit seinen Bedenken, ich glaube auch das DU einen Denkfehler machst. Wenn ein Kunde per VK bestellt, ist das ja kein Vorgang der einen externen Finanzdienstleister betrifft sondern nur die EIGENE BUCHHALTUNG. Diese würde üblicherweise in einem System arbeiten das HINTER DEM SHOP läuft. Wenn also die Zahlung eingeht, gibt die BH den Auftrag frei und das hat mit Gambio nichts zu tun. Wenn ich das richtig verstanden habe, habt Ihr offenbar ein besonderes Konstrukt, indem Ihr EUREN VERSANDDIENSTLEISTER auf Euren Shop zugreifen lasst (warum auch immer). Also muss EURE BH doch lediglich eine Freigabe für eine bestimmten Auftrag an Euren VDL senden und alles ist gut.
Das ist so nicht richtig. Eine Vorkasse Bestellung durchläuft erstmal denselben Flow wie jede andere Bestellung auch: Bestelleingang, warten auf Zahlung, Freigabe. Es ist durchaus nicht vermessen oder falsch den Zahlungseingang wie bei jeder anderen Bestellung mit PayPal, Klarna, Amazon oder wem auch immer im Shop zu erfassen und eben keine Extrawurst an anderer Stelle dafür zu braten. Der Shop bringt mit GiroConnect auch explizit Mittel mit um das bequem zu machen, der Usecase existiert. Wenn man da eine Wawi dran hat ist das nur eine andere Möglichkeit vielleicht auch zum Ziel zu kommen, mit richtig oder falsch hat das aber wenig gemein. Ich wäre immer ein grosser Freund von Gleichbehandlung aller Bestellungen, alle Prozesse gleich aufsetzen, aber jedem das seine. Dass der JTL Connector da offensichtlich eine nervige Funktionsschwäche hat wenn er Bestellungen nach dem ersten lesen nicht aktualisieren kann ist ne andere Nummer. Erstmal ist das dann Stand jetzt dünne Funktion. Zweitens kann das sonst zur Verfügung stehenden Möglichkeiten eben einschränken beziehungsweise welche ausschliessen. Das Problem ist hier das Setup, da dies über 2 Betriebe stattfindet. Der eine soll nur Versand machen, tüdelt aber eine Wawi dran die universell herrschsüchtig ist und mehr auf ihrer Seite erwartet. Der Buchhalte muss also zum externen Versender und da die Zahlungen buchen oder das Setup geht nicht. Bei allem innerhalb eines Betriebs würde man das lösen können und sich eben an die Wawi nageln, so wird das nichts...
@Wilken (Gambio) : Wo liege ich falsch, ich habe nichts anderes geschrieben ... ;-) Wenn NUR ein Shopsystem wie Gambio eingesetzt wird gibt es Prozesse die auf die Leistungen der Shopsoftware und des Unternehmens optimiert sind. Aber auch in diesen Fällen ist der "Geschäftsvorfall VORKASSE" ein besonderes Thema und muss sicherlich von Unternehmen zu Unternehmen völlig unterschiedlich behandelt werden. Speziell auf die Ausführungen von @L & B möchte hier nochmals hinweisen die genau richtig sind und die man bei der Ausarbeitung der Prozesse unbedingt berücksichtigen sollte (egal ob Wawi dahinter oder nicht). Wenn aber eine Wawi hinter dem Shop hängt, werden (im Idealfall) grundsätzlich alle Prozesse auf die Wawi abgestellt und der Shop wird lediglich mit den Daten aus der Wawi gefüllt. Beispiel Gambio in Verbindung mit VARIO-Software: Wenn der Gambio Shop "technisch" eingerichtet ist (Zahlungs- & Versandmodule, Shopeinstellungen, Design usw.) hat die Arbeit am/im Shop ein Ende. Alle Prozesse des Tagesgeschäfts finden in der VARIO-Software statt, ohne Ausnahme! Auch Metadaten und andere, SEO relevante Texte/Einstellungen werden selbstverständlich in der VARIO gepflegt. Kurz: Wenn eine Wawi hinter einem Shop hängt, ist und muss! die Wawi das führende System sein. Der Shop wird in diesem Fall tatsächlich und ausschließlich zum Frontend für Kunden degradiert das nichts anderes macht als Bestellungen anzunehmen. Was uns betrifft wird eine VORKASSE Bestellung genauso behandelt wie eine PayPal-Zahlung, d.h. die Bestellung wird sofort in die VARIO übernommen und vollautomatisch gebucht (Bestände aber ohne Zuordnung zu Chargen) und für die Lieferung gesperrt. Damit sind in der VARIO nicht nur die bestellten Artikel "reserviert", sondern werden auch in anderen Bereichen (Einkauf, Lagerverwaltung etc.) berücksichtigt. Dazu kommen auch andere Unternehmensprozesse in denen die Daten für Auswertungen & Analysen, Marketing etc. sofort zur Verfügung stehen. Fazit: Der einzige Unterschied im Prozess (in diesem Fall) ist, dass die VK-Bestellung nicht sofort in den Versand geht und zuerst der Geldeingang abgewartet wird, bzw. bis die Freigabe durch Autorisierung erfolgt. Das Problem von @sccfahrzeugtechnik kann aber organisatorisch einfach gelöst werden sofern JTL erkennt, dass eine Bestellung übernommen wurde die auf VK steht und erst nach Freigabe ausgeliefert werden darf.
@Wilken (Gambio) Deine Antwort gibt leider nur Deine Meinung wieder, was genau ist nicht richtig? Es ergibt (zumindest für mich) keinen Sinn gleiche Prozesse in unterschiedlichen Plattformen abzubilden die in Abhängigkeit miteinander verbunden sind. Das bringt nicht nur mehr Aufwand (und Kosten) mit, sondern erhöht die Fehleranfälligkeit (durch Anwender) enorm.
Das ist genau mein Thema. Der Shop führt bei anderen Zahlungsweisen als Vorkasse die Bestellung bis zum Zahlungsabschluss. Bei Vorkasse macht es daher normal keinen Sinn den Prozess aufzubrechen und woanders abzuhandeln, nämlich in der Wawi. Das ist ein Logikbruch. Der kann Sinn machen, muss er aber nicht.
Ich weiß nicht mehr wie das in JTL war, in Vario werden die Bestellungen abgerufen, die auf "offen" stehen. Man könnte jetzt also ganz simpel festlegen, dass eine Bestellung mit Vorkasse den Status "Warten auf Zahlung" erhält und wenn ein Zahlungseingang an den Shop übertragen wurde ein "offen" Die Punkte von L&B sollten aber berücksichtigt werden. Besser wäre da, wenn die Statusänderung an die WaWi übergeben würde. Da das Modul zur Übertragung der Zahlung bei Vorkasse noch recht neu ist, wage ich zu bezweifeln dass es eine WaWi gibt, die das schon kann.