Gelöst Weitere Zahlungsmodule ergänzen

[bork]

Halllo,

wir möchten gerne weitere Zahlungsmodule per Plugin ergänzen, damit die nicht immer nur als Freitext mit dem Standard-Modulnamen importiert werden und auch so auf der Rechnung stehen. Dafür muss man sicherlich im ersten Schritt diese Liste erweitern, klar:
https://gitlab.jtl-software.de/jtl-...Connector/Gambio/Mapper/CustomerOrder.php#L49

Aber wo findet z.B. für 'moneyorder' => 'pm_direct_debit', die Zuordnung von 'pm_direct_debit' zur Zahlungsweise "Lastschrift" in JTL statt? Habe im Connector dazu nichts gefunden, und auch nicht in der JTL SQL Datenbank...

Danke und VG

 

[daniel.jtl]

AW: Weitere Zahlungsmodule ergänzen

Das "pm_direct_debit" ist bereits das was endgültig übertragen wird bzw. der interne Typ der Wawi.
Alles weitere erfolgt in der Wawi selbst.

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Danke. Kannst du mir zufällig auch sagen, wie das genau in der Wawi geht? Ich finde unter Einstellungen => Versand/Zahlung => Zahlungsarten wohl "Lastschrift", aber "pm_direct_debit" kann man nirgendwo hinterlegen? Muss man dann die Zahlungsarten alle löschen und neu aus dem Shop importieren lassen? Weil unsere "moneyorder" gar keine Lastschrift ist, sondern eine reguläre Vorkasse-Banküberweisung.

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Also wenn ich in JTL unter Zahlungsarten die Bezeichnung für "moneyorder" von "Lastschrift" in "Vorkasse-Banküberweisung" ändere, wird beim nächsten Auftragsimport die "Lastschrift" wieder neu angelegt. Wo kann ich denn festlegen, dass moneyorder nicht als "Lastschrift" geführt/importiert werden soll?

 

[Jan-S]

AW: Weitere Zahlungsmodule ergänzen

Ich wäre auch an einer Lösung interessiert....

 

[Frank Busch]

AW: Weitere Zahlungsmodule ergänzen

Hi,

das Mapping für die Zahlungsarten ist fest einprogrammiert.
Beispielsweise wird "pm_direct_debit" grundsätzlich als "Lastschrift" importiert.

MfG
Frank

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Hallo Frank,

ok, das heißt, man müsste ein Plugin haben, das in dieser Datei
https://gitlab.jtl-software.de/jtl-...Connector/Gambio/Mapper/CustomerOrder.php#L49

für

'moneyorder' => 'pm_direct_debit',

was anderes hinterlegt als pm_direct_debit? Oder geht ihr da vielleicht grundsätzlich nochmal ran? moneyorder ist ja in keinem OsCommerce Fork jemals Lastschrift, so dass diese Zuordnung eigentlich keinen Sinn macht. Mit "Banküberweisung" wäre vermutlich jedem weitergeholfen...

https://dict.leo.org/ende/index_de....oc=0&resultOrder=basic&multiwordShowSingle=on

PS: Wo wir gerade bei Zahlungsarten sind: Ist mittelfristig eine Paypal Plus-Unterstützung auch noch geplant? Gambio-Modul paypal3...

 

[Verkäuferlein]

AW: Weitere Zahlungsmodule ergänzen

Oha, ich sehe schon die nächste Baustelle auf uns zukommen.

Im Moment bin ich gerade ein bisschen aus der Thematik Gambio- Connector raus, aber kann man vielleicht noch einmal allgemein die Info seitens JTL geben, welche Zahlungsarten vom Gambio-Connector unterstüzt werden bzw. welche Zahlungsarten im Zusammenspiel Wawi <-> Connector <-> Gambio möglich/vorgesehen sind?

Und bitte schafft doch eine Möglichkeit, dass man die Zahlungsarten indirekt / manuell zuordnen bzw. umbenennen kann, sofern es das noch nicht gibt.

 

[daniel.jtl]

AW: Weitere Zahlungsmodule ergänzen

welche Zahlungsarten vom Gambio-Connector unterstüzt werden

Prinzipiell ist der Connector eigentlich unabhängig was die Zahlungsarten betrifft, da lediglich die Art der Zahlung als Text übermittelt wird.
Hier wird dann nur versucht dem Gambio-Modul-Namen eine Wawi-Zahlungs-Art zuzuweisen, siehe hier: https://gitlab.jtl-software.de/jtl-...Connector/Gambio/Mapper/CustomerOrder.php#L49
Gibt es keinen zugehörigen Treffer wird halt nur der Name des Moduls angezeigt. Hätte man sich also ein Zahlungs-Modul "blubbdiblubb" gebaut, dann würde auch genau das in der Wawi erscheinen.

Die einzige Ausnahme besteht bei PayPal, da hier zusätzlich auch der tatsächliche Zahlungsvorgang inkl. Transaktions-ID gezogen wird (sofern denn die korrekten Tabellen auch durch Gambio angelegt und gefüllt wurden).

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Ja, das deckt sich so mit unseren Beobachtungen. Jetzt will meine Frau aber auf ihren Rechnungen nicht draufstehen haben: "Zahlung am xx.xx.2016 per paypal3" (paypal3 ist der Name des Paypal Plus Moduls in Gambio). Wenn man den Namen ändert, bleibt das Mapping aber nicht bestehen, sondern paypal3 wird nochmal als neue Zahlungsart in der Wawi angelegt. Noch schwieriger bei moneyorder (Banküberweisung): Hier muss jede Bestellung von Hand nachgearbeitet werden und eine neue Zahlungsart zugewiesen werden.

Jetzt ist es aber so, dass wir händeringend nach einer Möglichkeit suchen, das anzupassen, aber
- an die phar Datei komme ich nicht selbst dran
- ein offizieller JTL Servicepartner hat bei der Plugin-Erstellung bereits das Handtuch geworfen
- auf eine Plugin-Programmierer-Suchanfrage hier im Forum gab es nur eine halbherzige erste Kontaktaufnahme
- ein Inder und zwei Ukrainer, die auf Symfony spezialisiert sind, haben wegen der Komplexität der Materie die Aufträge gecancelt
- JTL selbst macht Plugin-Angebote nur für Kunden mit einem bestimmten gebuchten Support-Level (richtig?)

Ich dachte, mit dem Beispiel-Plugin und der Dokumentation und mit symfony-Kenntnissen könnte da jeder ein Plugin schreiben, ohne dass gleich .NET, SQL Server, JTL Wawi, Gambio Testshop, Gambio Connector installiert werden müssen und bei JTL neben der Kauflizenz noch eine Testlizenz für den Connector beantragt/verlängert werden muss. Offenbar alles nicht so ganz einfach.

Daher würde ich jetzt gerne die Holzhammer-Methode verwenden:
- ungepackten Connector (ohne Phar) einsetzen
- Keine Plugins, sondern Änderungen direkt im Quellcode
- Bei jedem Update Prüfung der geänderten Dateien

Nicht schön, aber eine andere Lösung ist hier gerade nicht in Sicht. Daniel, muss ich dafür einfach nur dieses ungepackte Paket herunterladen https://gitlab.jtl-software.de/jtl-software-gmbh/gambio-connector und das funktionert dann genauso (nur langsamer) wie das phar-archiv? Muss man was an den JTL Webshopeinstellungen ändern? Andere Webshop URL oder so?

Danke und VG

 

[daniel.jtl]

AW: Weitere Zahlungsmodule ergänzen

- an die phar Datei komme ich nicht selbst dran

Ja, das ist schon klar dass man in einer kompilierten Datei nichts ändern kann. Muss man aber ja auch nicht.
Der Quellcode ist ja für jeden per Gitlab einseh- und nutzbar. Ob man diesen dann so verwendet, oder sich den Connector nach den Änderungen wieder als Phar compiled bleibt ja jedem selbst überlassen.

- ein offizieller JTL Servicepartner hat bei der Plugin-Erstellung bereits das Handtuch geworfen
- ein Inder und zwei Ukrainer, die auf Symfony spezialisiert sind, haben wegen der Komplexität der Materie die Aufträge gecancelt

Nun gut, da muss man dann leider sagen, dass bei diesen Leuten eine entsprechende Kompetenz wohl eher nicht gegeben war.
Das Ganze ist zwar durchaus komplex aber dennoch kein Hexenwerk. Ein versierter Entwickler sollte damit eigentlich keine Probleme haben.
Bezüglich dem SP wäre es natürlich interessant wenn du mir hier mal in einer PN (bitte natürlich nicht öffentlich) schreibst um wen es sich handelt, damit wir der Sache nachgehen können. Es sollte natürlich nicht sein, dass einer unserer SPs Leistungen verkauft die er anschließend mangels Kompetenz nicht umsetzen kann und den Kunden dann damit sitzen lässt. Das kostet den Kunden ja Zeit und Geld und wirkt sich zudem auch nicht positiv auf unseren Ruf aus.

- JTL selbst macht Plugin-Angebote nur für Kunden mit einem bestimmten gebuchten Support-Level (richtig?)

Prinzipiell ja. Eigentlich werden spezifische Änderungen und Erweiterungen nur im Rahmen einer Professional oder Enterprise Lizenz angeboten.
Es kommt aber letztendlich auch auf den Umfang an und wie genau ein solches Projekt definiert und beschrieben wird.
Du kannst mir deine Anforderungen gerne möglichst genau per PN zuschicken und dann gucken wir was möglich ist...

Ich dachte, mit dem Beispiel-Plugin und der Dokumentation und mit symfony-Kenntnissen könnte da jeder ein Plugin schreiben, ohne dass gleich .NET, SQL Server, JTL Wawi, Gambio Testshop, Gambio Connector installiert werden müssen und bei JTL neben der Kauflizenz noch eine Testlizenz für den Connector beantragt/verlängert werden muss. Offenbar alles nicht so ganz einfach.

Nun gut, dass die Wawi inkl. der Abhängigkeiten sowie der eigentliche Shop für Testzwecke installiert sein müssen lässt sich wohl kaum vermeiden.
Da wäre es mir aber auch ein Rätsel wie man eine entsprechende Erweiterung umsetzen soll, ohne die notwendige Infrastruktur?
Ich denke aber auch wirklich dass du da leider an die falschen Leute geraten bist. Symfony-Kenntnisse sind eigentlich gar nicht notwendig und professionelle Entwickler werden anhand des Quellcodes zurecht kommen.

Daher würde ich jetzt gerne die Holzhammer-Methode verwenden:
- ungepackten Connector (ohne Phar) einsetzen
- Keine Plugins, sondern Änderungen direkt im Quellcode
- Bei jedem Update Prüfung der geänderten Dateien

Da kann ich dir natürlich nach wie vor nur von abraten. Das wäre lediglich ein unsauberer und amateurmäßiger Workaround, aber keine Lösung. Eine solche Variante wäre unnötig aufwändig, fehleranfällig und nicht zukunftssicher.

 

[Thomas Lisson]

AW: Weitere Zahlungsmodule ergänzen

Hi

Hier muss jede Bestellung von Hand nachgearbeitet werden und eine neue Zahlungsart zugewiesen werden.

Erstell dir einfach in der Wawi einen Workflow, der die entsprechenden Zahlungsarten ändert. Oder zur Not die Druckvorlagen anpassen, wo die Zahlungsarten richtig ausgegeben werden.

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Hi Thomas,

danke, das probiere ich mal aus. Hilft allerdings noch nicht bei unseren anderen "Extrawünschen", die ich Daniel vorhin gepmt habe (ich schreibe sie nochmal kurz mit auf, vielleicht gibt es noch mehr so Lösungen wie den Workflows oder noch mehr Interessenten, die das mitbezahlen würden):

1) Zahlungsarten: Teilweise hinfällig, bis auf wenn man Paypal-Transaktionen für das Paypal Plus Modul auch übernehmen will und bis auf Bankverbindungen vom Rechnungskaufanbieter Paymorrow, die ohne System wechseln und mit auf die Rechnungen müssen

2) Lange Vorlaufzeiten, bis der Connector aus der Tabelle jtl_wawi_connector die zu importierenden / exportierenden Daten gesammelt haben. Momentane Vorlaufzeit mit eingefrorenem Fenster bis der Sync Vorgang bei uns startet: > 2 Minuten. Meine Idee dazu war, dass man alle Kundennummern und Bestellnummern unter xy schonmal komplett ignoriert und auch dann die aufwändigen Join-Abfragen für z.B. 15.000 Bestellungen nicht braucht.

3) Um einen schnellen Überblick zu haben, welche Produke im Shop gerade sichtbar sind oder nicht (online = grüner Zeilenhintergrund, nicht aktiv = weißer Hintergrund), hätten wir gerne, dass nicht mehr die 0 oder die 1 bei den Produkt-Attributen ( Gambio-Attibut "Aktiv"), sondern die "Webshop" checkbox ausschlaggebend ist

4) Ggf.: Lieferzeiten von der verfügbaren Menge abhängig machen (Gambio benutzt ja sowieso keine Tage, sondern Stati, denen Zeiträume zugeordnet sind). Das könnte aber auch über Workflows funktionieren, oder?

VG

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Hallo,

offenbar kann man mit dem Workflow die Zahlungsart nicht ändern... Habe die Bedingung zwar erstellen können, aber eine Aktion zur Änderung der Zahlungsweise habe ich nicht gefunden...

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

@daniel.jtl Plugin-Anfragen angekommen? Wie würde man denn vorgehen, wenn man doch mit dem ungepackten Connector arbeiten würde? Wenn ich das Ding von Gitlab herunterlade, fehlen offenbar irgendwelche Ordner/Dateien, die benötigt, aber nicht mit im Paket sind, z.B. die Datei vendor/autoload.php (bzw. komplett der Ordner vendor)...

 

[daniel.jtl]

AW: Weitere Zahlungsmodule ergänzen

@daniel.jtl Plugin-Anfragen angekommen?

Ja, aber noch keine Zeit gehabt mir das im Detail anzugucken. Werde ich wohl diese Woche zu kommen...

Wie würde man denn vorgehen, wenn man doch mit dem ungepackten Connector arbeiten würde? Wenn ich das Ding von Gitlab herunterlade, fehlen offenbar irgendwelche Ordner/Dateien, die benötigt, aber nicht mit im Paket sind, z.B. die Datei vendor/autoload.php (bzw. komplett der Ordner vendor)...

Ja, vollkommen richtig. Es müssen die Abhängigkeiten mittels Composer installiert werden.

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Unser Entwickler hat jetzt was Superkompliziertes vorgeschlagen, weil er meint, dass er mit dem CustomerOrderAfterPull Event nur Daten ändern aber keine hinzufügen kann:

We analyzed information and suppose that this task is little bit wider then just plugin creation. As possible solution we see the way to use unpacked connector as "vendor". Then we create own connector that will extend JTL connector and will inherit all its features. Then override some parts in our connector that will allow to add new options. Then create plugins base on events way. Then we will need to create own phar package that will have our code and original code. In case when original connector will update from developpers? we will just unpack it, upload to "vendor" separate folder, that we will keep untouchede and then we will need to repack the new phar. In addition it will require creating Fixtures that will allow to have etaon data, that will be used for Unit tests, that must be created for two reasons. First it will allow emulate PC software to send RPC requests and debug development. Second point: to be safe in modifications.

Scheint mir sehr aufwändig und vermutlich auch überflüssig? Wenn ich dich richtig verstehe, Daniel, könnte man einfach nach dem CustomerOrderAfterPull Event kurz prüfen, ob ein Zahlungsmodul gemappt werden konnte und wenn nicht eine aussagekräftige und als Konstante definierte Zahlungsartbezeichnung festlegen, die den Modulnamen ersetzt? Oder noch einfacher: Mit preg_replace ersetzen?

Ja, vollkommen richtig. Es müssen die Abhängigkeiten mittels Composer installiert werden.

Keine Ahnung wovon du sprichst leider. Ist das schwer? Gibt es eine Anleitung?

Ich glaube, ich warte lieber noch auf deine Plugin-Angebote...

 

[daniel.jtl]

AW: Weitere Zahlungsmodule ergänzen

Scheint mir sehr aufwändig und vermutlich auch überflüssig? Wenn ich dich richtig verstehe, Daniel, könnte man einfach nach dem CustomerOrderAfterPull Event kurz prüfen, ob ein Zahlungsmodul gemappt werden konnte und wenn nicht eine aussagekräftige und als Konstante definierte Zahlungsartbezeichnung festlegen, die den Modulnamen ersetzt?

Absolut exakt. Also was dein Entwickler da schreibt ist leider Quatsch und stimmt nicht. Die Daten können bei allen Events und Aktionen jeweils vor und nach der connector-internen Funktion vollständig modifiziert werden.

Keine Ahnung wovon du sprichst leider. Ist das schwer? Gibt es eine Anleitung?

Composer ist ein Paket-Verwaltungs-Tool für PHP-Code und absoluter Branchen-Standard.
Das würde aber den Rahmen sprengen das hier im Detail zu erläutern.
Prinzipiell ist es aber nicht sehr schwer, einfach mal googeln oder auf der offiziellen Website umschauen: https://getcomposer.org/

 

[bork]

AW: Weitere Zahlungsmodule ergänzen

Ich glaube, ich warte lieber noch auf deine Plugin-Angebote...

Die Zeit rennt und wir sind immer noch nicht weiter. Zwei weitere Freelancer die versprochen haben, dass die Plugins überhaupt kein Problem sind und das alles innerhalb von einer Stunde fertig ist, haben nach 3-8 Tagen das Handtuch geworfen. JTL hatte auch noch keine Zeit ein Angebot zu erstellen, und ich habe auch noch keinen Servicepartner gefunden, der sich mit den Plugins auskennt. Ich selbst als Nicht-Programmierer bin auch nur bedingt weitergekommen ( http://forum.jtl-software.de/gambio-connector/89094-plugin-coaching-gefragt-ist-falsch.html ). Daher möchte ich jetzt die Notlösung mit dem entpackten Phar fahren, hilft ja alles nix. Ich gehe davon aus, dass alle manuellen Änderungen in gitlab dokumentiert werden und von mir händisch nachgepflegt werden können? Gibt es denn hierzu

Ja, vollkommen richtig. Es müssen die Abhängigkeiten mittels Composer installiert werden.

noch irgendwo eine Schritt-für-Schritt-Anleitung?

Wenn jemand noch Ideen, Tipps oder Alternativen hat - gerne her damit...

 

[daniel.jtl]

AW: Weitere Zahlungsmodule ergänzen

Ich gehe davon aus, dass alle manuellen Änderungen in gitlab dokumentiert werden und von mir händisch nachgepflegt werden können?

Klar, was sich wo geändert hat ist dort ja ersichtlich. Je nach Umfang ist es aber natürlich erhebliche Arbeit das alles nachzuhalten und immer manuell anzupassen.

Gibt es denn hierzu noch irgendwo eine Schritt-für-Schritt-Anleitung?

Anleitungen zu Composer gibt es wie Sand am Meer und auch direkt auf der Website des Tools. Da bitte einfach mal Google bemühen...