@Wilken: ich nehme Bezug auf diesen Thread: https://www.gambio.de/forum/threads/rest-api-python3-excel-rechnungsexport.40880/ Zu aller erst einmal finde ich die Aussage bezüglich "in 2012 stehen geblieben" sehr daneben, denn nicht alles was "oldschool" ist, ist auch zwangsweise schlecht, ganz im Gegenteil. Auch in GX3 gibt es reichlich Verschlimmbesserungen. Bezüglich Paypal Transaktions-ID bin ich mir nicht sicher ob wir von der gleichen ID Reden oder nicht, denn das was Du beschreibst macht eigentlich die Transaktions-ID. Ich hänge mal ein Bild an von der Nummer die ich meine. Ist dies die Nummer / ID / Code denn Du auch meinst oder ein anderer ? Gruß, Dirk
Man muss die Dinge doch mal nennen wie sie sind. Was zum Beispiel Datev angeht: Überleg mal wie lange die Lösungen auf Silverlight Basis propagiert haben, die auch nur im Internet Explorer liefen. Es ist nicht lange her, dass ich das letzte mal bei jemandem für "Unternehmen Online" kräftig Dinge verbogen habe. Beim IE weiss jeder einigermassen wie lange der schon defakto tot ist, bei Silverlight ist die erste Ankündigung vom Ende aus 2014, früh in 2015 wurde dann endgültigst zementiert. Obwohl das einen dringend nötigen Wechsel bei der Applikations-Basistechnologie ausgelöst hat, ohne die kein Nutzer Datevkernprodukte mehr nutzen könnte, hat Datev gute 4-5 Jahre für eine Adaption benötigt und auf den letzten Drücker geliefert. Haarscharf... Datev ist nie schnell. Datev ist eher "hart lahm". Oldschool ist keine Entschuldigung, alle anderen bleiben ja nicht stehen. Wollen wir auch nicht, könnten wir auch nicht, das wäre gegen das Interesse unserer Kunden, auch wenn die das nicht immer ahnen. Oldschool heisst ganz oft aufgeben. Das ist mir zu pauschal um darauf einzugehen. Dann bitte konkrete Themen nennen, dann reden wir drüber. Ich rede von Payment IDs und von Transkations IDs. Das im Bild ist eine Transaktions ID. Die speichern wir nicht, da gilt mein gesagtes.
Danke für die Antwort. Sehr schade dass diese ID nicht gespeichert wird. Das bedeutet, dass man diese ID erst über die REST API anfordern muss wenn man z.B. die Bestellungen aus dem Online-Shop in die WaWi zur Weiterverarbeitung übernimmt ?
Wenn die Wawi nicht mit modernem PayPal kann: ja. Die Wawi Schnittstelle der Wahl ist aber eh die REST-API. Das ist genau der Ort über den Wawis gehen sollten, wenn sie relevant bleiben wollen.
Okay, ich weiss Bescheid. Danke. Weitere Kommentare und Diskussionen dürften nichts bringen, daher werde ich auch auf den obigen Beitrag von Dir nicht weiter eingehen, sicherlich nachvollziehbar und wir können mit der Zeit die wir sparen andere Dinge erledigen ;-)
Kurz gesagt: Wer Zukunftssicher bleiben will, sollte soweit es geht immer die REST-API nutzen - nur dann kann Gambio im Hintergrund auch endlich optimieren ohne das Verbindugen zu externen kaputt gehen oder was kaputt machen. Old school mag oft praktisch und einfacher sein, ist langfristig aber eben das was im Wort steckt: old. Je länger solche Verknüpfungen bestehen bleiben um so langsammer ist der Optimierungsfortschritt. Die wenigsten WaWis lassen dich direkt an die DB von deren Software, da musst auch immer schnittstellen und importe nutzen. Festgelegte Wege statt eigene Brücken zu bauen. Updatesicherheiten und optimierungen kann es nur geben wenn man vorgefertigte Pfade nutzt und nicht über den Rasen rennt und alles platttrampelt
Das ist ja alles schön und gut aber über Standard-Schnittstellen können nun mal nur Standards abgebildet werden, und wenn es Ausnahmen gibt dann ist dort Schluss. In diesem Fall geht es eigentlich nur darum, dass Daten mit denen auch Paypal primär arbeitet (beim Paypal CSV Export wird die Transaktions-ID auch als übergeordnete ID aus gegeben, verwende Paypal und kein Paypal Plus) vorenthalten und umständlich abgerufen werden müssen, damit die nachgeschalteten System die Zahlungen sauber verarbeiten können. Ich verstehe nicht was der Vergleich mit "Silverlight" damit zu tun haben soll.
Sollte wohl nur aufzeigen, dass die Uralte Technik die lange auf dem Stand "Wird bald abgeschaltet, ändert eure Software" stand, von denen erst ganz zum Schluss erst umgeschaltet wurde als das Ende quasi schon durch die Tür kam und es zwangsweise endlich gemacht werden musste. Software und die Nutzung verändert sich doch alle 1-2 Jahre. Datev aber ur alle 5-10 Jahre. Da kommt immer irgendwann der Punkt wo es eng wird.
PayPal oder PayPal Plus ist egal, das läuft normal inzwischen überall per PayPal REST-API. Für den Shop und viele andere Systeme macht das damit 0 Unterschied, alles dasselbe. Der Punkt ist eher das CSV Exporte auch son zweidimensionales Relikt sind, bei denen sich kein Player am Markt mehr richtig Mühe gibt die zu warten. Wir nicht, andere wie PayPal auch nicht. Es wollen alle, dass die sterben. Silverlight ist ein Beispiel für vollkommen überholte Technik, die praktisch kaum noch zu benutzen ist, weil sie nicht mehr gewartet wird und die Schnittstellen zu immer mehr neuer Software wie Browsern abhanden kommt. Das geht nicht mal mehr in MS Edge, dem aktuellen Browser desselben Konzerns. Es muss vorwärts gehen, sonst geht alles kaputt.
Mit der CSV Daten erziele ich eine Trefferrate von 99.9% bei der Zurordnung Paypal-Zahlung an Bestellung und Aufbereitung der Daten für Datev, sprich eine nahezu vollautomatische Verarbeitung der Paypal-Daten und eine damit verbundene enorme Zeiteinsparung, bei mehreren Tausend Datensätze im Monat kommt da einiges zusammen. Wozu so ein Relikt alles gut sein kann... Aber wie gesagt: bringt nichts weiter zu Diskutieren. Ich habe euren Standpunkt verstanden, den muss ich auch respektieren und ist momentan aus eurer Sicht sicherlich nachvollziehbar. Alles weitere wird die Zukunft zeigen.
Wir rufen PayPal wie ein Bankkonto ab, da braucht es keine CSV Dateien. Die Frage ist ja dann nicht dein abgleich sondern eher wie du die Zahlungen in deine Software holst. Die PayPal Mailadresse dürfte aber evtl. als match auch passen, die sollte im Shop und in dem Verwendungszweck passen. CSV ist ja nur immer die minimalste Form des Daten ex und imports.
Der Abruf der Paypal-Daten selbst ist nicht das Thema. Ob CSV oder über die REST-API ist erst einmal egal, solange die Inhalte identisch sind. Mir geht es um die Transaktions-ID selbst, welche derzeit (Modified-Shop) in der DB steht und wenn ich die Bestellungen aus dem Online-Shop in die Wawi übernehme, mit ausgegeben und im jeweiligen Auftrag in der WaWi eingetragen wird. Dadurch kann ich später dann eine genaue Zuordnung Paypal-Zahlung an Auftrag durchführen und daraus dann den kompletten Buchungssatz erzeugen welcher dann in Datev eingelesen wird und zwar so wie ich es haben möchte (den gleichen Weg beschreitet auch Datev selbst nur eben über den Umweg Datev-Rechenzentrum plus Gebühr... sowas ;-)) . Trefferquote wenn die Trx-ID vorhanden ist: 100%, ohne Trx-ID muss über eMail, Datum, Betrag gegangen werden, was die Zuordnung ungenauer und fehleranfälliger macht. Ob das Mitführen eine Transaktions-ID, welche nicht nur bei Paypal sondern auch bei anderen Zahlungsdiensten existiert (Sofort, Kreditkarte, Bank), so ein grosses Problem und Old-School ist bezweifele ich stark, ganz im Gegenteil. Um jetzt an die Trx-ID zu kommen muss ich zusätzlich - zumindest habe ich es so verstanden - beim Export der Bestellungen aus dem Shop pro Bestellung einen Aufruf an die Gambio REST API stellen, welche dann wiederum einen Aufruf an Paypal's REST API richtet um die Daten ab zu rufen, welche eigentlich bereits beim Zeitpunkt der Zahlung selbst bereits bereit standen aber nicht gespeichert wurden. Wenn dieser Ablauf so erfolgt wie von mir beschrieben, dann erlaube ich mich zu fragen, was daran nun Fortschritt sein soll - und diese Frage ist sicherlich berechtigt. Wie gesagt, sollte ich falsch liegen, dann verbessert mich gerne.
Die Zuordnung Bestellung ↔ PayPal-Transaktionen ist nicht 1:1, sondern 1:n:m. Eine Bestellung kann mehrere zugeordnete PayPal-Payments haben, ein PayPal-Payment kann mehrere Transaktionen enthalten.
Natürlich ist sie dies nicht, aber für jede weitere Transaktion wird eine eigene Transaktionsnummer vergebn welche die Transaktion eindeutig identifiziert und es muss auch ein eigener Vorgaben vorhanden sein, z.B. Gutschrift oder Rückerstattung oder Storno. Die Zahlungs-ID stellt eigentlich nur eine Gruppe da, wenn ich Wilken richtig verstanden habe. Leider taucht diese Zahlungs-ID auch an keiner Stelle auf wenn man sich die Transaktionen auf Paypal selbst anschaut, oder ich finde sie nicht ? Auf alle Fälle habe ich mal das oben beschriebene getestet und ich bestätige meine Aussage wie der Zugriff erfolgen muss. Anmerkung: beim Paypal Modul sollte die Möglichkeit bestehen, die Übertragung des Gesamten Warenkorbs an Paypal zu unterbinden bzw. durch einen "Dummy"-Artikel zu ersetzen. Ich kenne diese Forderung nur von Paypal, und diese dürfte spätestens seit der DSGVO hochproblematisch sein, wenn man bedenkt, dass man schon eine Einwilligung einholen soll, wenn man die eMail-Adresse des Kunden an den Paketdienstleister schicken will um die Trackingdaten zu übermitteln. Grüße, Dirk
Du willst unbedingt Zahlungssubtransaktion gegen Posten verbuchen. PayPal denkt in Zahlungsvorgang gegen Posten. Es macht nicht den geringsten Sinn das wie Zahlungen anders darstellen als PayPal diese selbst behandelt. Die "Orderlines" müssen zu PayPal, da sonst diverse PayPal Zahlungsoptionen gar nicht abbildbar sind, wie die Rechnungszahlung oder Ratenzahlung. Die DSGVO ist da kein Argument.
Mit den Transaktionen werfolgt die Abbildung genau so wie auf Seiten Paypal auch, damit ist auch eine genauer Abgleich der Salden möglich. Mache ich so schon seit 4 Jahren. Ob dies Sinn macht oder nicht ist meine Sache. Ich suche nur vernünftigen Weg die "Verbindungen" Bestellung-Zahlung herzustellen. Nicht mehr und nicht weniger. Wenn man keine Rechnungs oder Ratenzahlung anbietet ist dieses Argument irrelevant. Klarna bietet doch auch Rechnungskauf an. Müssen dort ebenfalls die Warenkörbe komplett übertragen werden ?
Das lässt sich leicht beantworten: Die Anbieter von solchen Rechnungszahlungen (egal, ob PayPal, Klarna oder sonstwer) benutzen die Daten dafür, das Risiko für die Übernahme der Forderung einzuschätzen. Und natürlich, um hinterher zu wissen, wofür sie da eigentlich eine Forderung eintreiben.
Bei Klarna siehst im Klarna Account auch alle Produkte und Shops wo du eingekauft hast. PP prüft z.B. ob digitale Güter, Gutscheine oder so Zeugs dabei ist.