Das das Problem an der WAWI-Seite hängt, wurde schon hinreichend erklärt und auch das die Lösung auch nur auf WAWI Seite zu finden ist.
Fazit vom ganzen: PayPal gibts vor, Gambio hats umgesetzt, die WaWi Anbieter wollen nicht, bleiben lieber beim alten System.... Verfahrene Situation die nur die Kunden mit dem WaWi Anbieter regeln können und die dazu bringen müssen endlich auch neue Wege zu gehn. Sprich die RestAPI vom Shop entsprechend ansprechen.
Wir drehen uns im Kreis. Das ist ja klar dass das so geht, aber das beschriebene Szenario darf eine FIBU nicht machen, lies dazu nochmal die GoB. Ich muss alle zu jeder Buchung relevanten Daten speichern, bei mir, wo ich die Daten im Zugriff habe und auch dafür verantwortlich bin (Datensicherung etc.) dass diese nicht geändert oder gelöscht werden. Klar könnte die ERP den ganzen Kram von PP abrufen und in eine db speichern. Dann müsste man aber wiederum die Daten im Shop beim Aufruf der Bestellung aus der ERP holen und NICHT nochmal von PP, da hier sonst Inkonsistenzen entstehen könnten. PP kann mal down sein, oder ein Hacker tut sich gütlich an PP, oder die gehen sogar pleite, was weiß ich. Dann habe ich keine Möglichkeit mehr die Daten abzuholen und wenn ich die dann nicht gespeichert habe......
In der Buchhaltung hast du doch den PayPal Kontoauszug und deine Rechnungen. fertig. Alles andere ist doch nur für die automatisierung. Und ob Zahlungen eingegangen sind damit Rechung weiter bearbeitest. Aber am ende buchst du den PayPal Kontoauszug gegen deine Rechnungen in der FiBu. Die Frage ist doch eher welche Daten nutzt du für deine FiBu - da wäre der PayPal direkt ontoauszug doch sinniger als Bestellbezogene Daten die die WaWi braucht um BEstellungen frei zu geben, weil bezahlt.
Du bekommst doch darüber alle Daten zu dem Vorgang und kannst diese auch speichern. Der Unterschied besteht doch nur darin, das Du nicht 5 Transaktions-IDs abrufst, sondern 1 Payment-ID, welche Dir die 5 Transaktionen liefert. Die einzelnen Transaktionen bleiben doch mit Datum erhalten.
Den Punkt den optima anspricht hatte ich so noch gar nicht auf dem Schirm, aber dieser ist in der Tat begründet. Ob sich nun ein Prüfer für diese Details interessiert ist natürlich ein anderes Thema, aber ab eine gewissen Firmengrösse steht man nun mal mehr im Fokus beim FA als z.B. Kleinunternehmer. Wenn die Zahlung über Paypal durchgeführt wird, wird dann auch die Order-ID an Paypal übertragen und taucht diese dann im Kontoauszg auf ? Auf die Schnelle konnte ich bei den Einstellungen keinen Punkt finden wo man dies einstellen kann. Wenn ja, dann könnte diese als Referenz verwendet werden, weil ebenfalls eindeutig (auf den jeweiligen Shop gesehen).
die Order-ID wird übergeben, steht aber nicht im Kontoauszug. Für einen Zahlungsabgleich kann diese aber als Zuordnungsmerkmal genutzt werden.....
Und wie bringe ich die zusammen? Auf dem PayPal-Kontoauszug habe ich keine PaymenID und keine orders_id stehen. Über die E-Mail des Kunden wäre es nicht eindeutig, selbst E-Mail und Betrag muss nicht unique sein. TransactionID hätte ich zu jeder Zalhung und könnte die dem Kunden und der Rechnugn eindeutig zuordnen. Meine Wawi bucht die PayPal-Zahlungen über ein Interimskonto automatisch in die FiBu, dass können wir bei der Menge an Buchungen nicht händisch machen. Dann nochmal als Resümee: Im PayPal Kontoauszug und bei der Zahlung steht keine PaymenID, nur die TransactionID. Die TransactionID steht aber nicht im Shop(-datenbank) und somit auch nicht in der Wawi. Die orders_id steht im Shop und in der Wawi, aber nicht auf dem PayPal-Auszug. Es bleibt mir also nicht weiteres als über die TransactionID der Zahlung aus der ERP die PaymentID herauszufinden um dann damit der Zahlung dann einem Vorgang zuordnen zu können.
Doch wenn die WaWi beim abruf über die Rest Schnitstelle vom Shop die Daten holt. Holt sie sich die Daten selbst aus der DB muss der Anbieter mit er Payment-ID die Transaktions-IDs selbst bei PayPal abrufen. Resümee: Der WaWi / ERP Abieter muss seine Hausaufgaben machen und das so umsetzen wie es Stand der Dinge Heute ist und nicht bei veralteter Art bleiben.
Ich finde Dein Resümee falsch, warum soll sich die Wawi die Daten bei PayPal holen ? Dein Denkansatz ist aus meiner Sicht LOGISCH VÖLLIG FALSCH. Der Verkauf und das CASH-HANDLING finden im Shop statt und daher gehören alle relvante Daten in den Shop! Die Eindeuitige Zuordnung zwischen Bestellung und Zahlung sollte im Shop abgelegt werden (was offenbar auch kein Problem wäre), dann wären eine Menge Posts nicht geschrieben worden. Sorry, jm2c
die Daten sind im Shop abrufbar. die WaWi muss jetzt nur über die Rest-API die Payment-ID ziehen - in der alles andere enthalten ist, nicht wir früher jede Transaktion einzeln. Man bekommt alle Daten über den Shop, man muss nur anders danach fragen. Nur wenn man weiterhin die Transaktions-IDs einzeln haben will, muss man das direkt bei PayPal abfragen. Die WaWi muss hier handeln - so oder so.
Dann verstehst du nicht was ich schrieb: So sollte es sein: WaWi ruft per RestAPI die Daten vom Shop ab. - Hier bekommt sie alles was sie braucht auch die Trasactions IDs. Aktuell machen WaWis aber so: Eigene Scripte die Daten aus der DB vom SHop holen. Da der Shop die Transactioons IDs nicht speichert MUSSSS die WaWi diesen Job dann selbst machen WEIL sie NICHT die RestAPI vom SHop nutzte. Fazit: Da die WaWi nicht die vorgegebenen Wege nutzt sodern eigene geht MUSS sie AUCH BEI PAYPAL eigene Wege gehen und die Transaktions IDs mittels der vom SHop gespeicherten Payment ID selbst abrufen. das ist durchaus logisch und nachvollziehbar !
ich verstehe gar nicht warum hier jeden Tag die gleiche Leiher gespielt wird. Der Shop ist keine FIBI und muss dementsprechend keine FIBU-Daten bevorraten. Der Gemeinsame Nenner ist die Payment-ID, anhand dieser der Einkauf in der WAWI mit der von der WAWI bei PAYPAL abgerufenen Daten dann zugeprdnet werden kann. ( NUR DER KAUF SELBST) in der FIBU der WAWI werden dann zu dem Einkauf die jeweiligen Zahlungen (Ein- und Ausgänge) per Transaktions-ID verbucht (GodB konform). Zusammengefasst: Shop liefert Bestellung mit Payment ID, WAWI zieht Zahlungsdaten bei PayPal ( Payment- und Trans-ID) WAWI führt diese in der Bestellbuchung zusammmen und verbucht die Trans-ID´s in der FIBU. FERTIG
Oder wie es eigentlich sein sollte wenn die WaWi mal von eigenen Scripten die auf die DB zugreifen über schnitstellen gehen die es dafür gibt dann bekommst: WAWI zieht Zahlungsdaten per RestAPI vom Shop ( Payment- und Trans-ID) WAWI führt diese in der Bestellbuchung zusammmen und verbucht die Trans-ID´s in der FIBU.
Dennis, das stimmt so nicht, Wie Wilken und Marco ja schreiben wird die Trans-ID in der Bestellung "LIVE" abgebildet, also im Moment der Ansicht gezogen und dargestellt, die Datenbank bleibt dazu leer. Die Trans-ID MUSS von PayPal zur WAWI übertragen werden und die PAYMENT-ID kommt mit den Bestelldaten vom Shop in die WAWI, Die PayMent-ID dient dann im Anschluss als Zuordnungsmerkmal. Die Zahlungsbuchungen werden in der FIBU per Trans-ID verbucht.
Doch stimmt laut Marco, da der Shop das alles macht sobald du per RestAPI die Daten abrufst Jedenfalls ist es das was ich da rauslese Aussage von Marco: Und voilà, schon hat man sämtliche Daten, die PayPal zu der Payment-ID ausspuckt, die der Bestellung zugeordnet ist. Inklusive der Sale-Transaktion und ihrer TransactionID. Das ist genau das, was eine FiBu-/WaWi-/ERP-/Whatever-Software tun würde, wenn sie die REST-Schnittstelle des Shops benutzt
Nein, wird live bei Paypal abgerufen wenn man die Payment_Details über die Rest-API abruft, nicht die Bestellung selbst. Gespeichert wird nur die Payment-ID.