Das war echt falsch. Das auch. Das würde ich so unterschreiben und dann meinetwegen der Datev auch... faxen.
darfst Du gerne machen, bin auf die Reaktion gespannt. Ach, ich liebe diese Schuldaufdenanderenschieben-Spielereien, das bringt einem echt weiter...
Im Grunde ist es doch ganz einfach: damit Datev in Zukunft richtig funktioniert, darf sich niemals etwas irgendwo am System ( egal ob im Shop oder bei einem Zahlungsanbieter) ändern. Am Besten man installiert sich eine Software, die schon 3 Jahre alt ist (die Rechtslage ist völlig egal) und macht nie wieder ein Update. Na gut, PayPal und andere werden dann irgendwann nicht mehr funktionieren, weil die sich eben doch weiter entwickeln, Dann bleibt eben nur noch Vorkasse und Rechnung auf eigenes Risiko - Aber das ERP läuft wie am Schnürchen
Du machst eigentlich nicht viel anderes, ich nehm dir den schwarzen Peter nur nicht ab. Ich hab schon mehrfach beschrieben warum wir handeln wie wirs tun, und warum wir das speichern was wir speichern, und warum wir einiges nicht speichern und warum wir das so insgesamt auch für richtig halten. Du kennst nun auch Datev, die was anderes wollen. Und das was die wollen war schon immer richtig, damit muss es jetzt auch richtig sein. Die Antwort ist aus unserer Sicht dann nein, die haben nicht mehr recht, die verhalten sich anachronistisch. Das werde ich immer wieder so sagen, denn das ist exakt meine Meinung dazu. Sicher ist: Wir werden uns da nicht bewegen, eine Rolle rückwärts wäre für alle schädlich. Nicht mehr alle PayPal Produkte anbieten - wer will das? Historische Daten speichern, die mal irgendwann gestimmt haben, wem bringt das was? Niemandem. Ein Onlineshopsystem das in der Zeit stehenbleibt, wer soll das auf mittlere Sicht benutzen? Das können und werden wir nicht, das ist das Versprechen. Datev wird nun wahrscheinlich so schnell keine Rolle vorwärts machen, die brauchen immer lang. ERPs gern auch. Ist so. Das als Zwickmühle aufzufassen nehm ich dir sofort ab, das ist eine, wenn man nicht beweglich ist. Wir schreiben bei Zahlungen aber auch immer zum Beispiel die Bestellnummer zu PayPal. Es gibt auch noch andere Daten. Du darfst auch nicht stehenbleiben, du musst dir einen Plan B bauen.
Fall bei einer befreundeten Firma: Softwarehersteller A sollte mit Softwarehersteller B kommunizieren aber keiner wollte sich bewegen und unbedingt an der eigenen, ganz tollen Schnittstelle festhalten. Der Chef stand dazwischen, schaute sich die Sache eine Zeit an und nahm dann Softwarehersteller C. A und B gucken heute noch blöd aus der Wäsche. Im Prinzip ist es mir ja egal, da ich mir helfen kann und die Daten halt auf anderem Weg beschaffe - unnötig für die Umsetzung aber nun ja, ist halt so. Andere können dies vielleicht nicht, schauen sich das Treiben eine Zeit an und fällen dann eine Entscheidung, vielleicht ähnlich wie Chefchen aus obigen Beispiel. Ruf mal bei Datev an und sag denen, dass Gambio sagt dass die Paypal Transaktions-ID Quatsch ist und man diese nicht benötigt. Ich vermute Datev fragt dann: wer oder was ist Gambio ? Mal unter uns, weil es mich interessiert: wo liegt das Problem in der entsprechenden Tabelle eine weitere Spalte vor zu sehen und dort dann die Transaktions-ID zu speichern, die bei der Rückmeldung von Paypal sowieso übermittelt wird. Bei früheren Versionen von Gambio war dies doch auch der Fall, oder. Ist es so schwer über den eigenen Schatten zu springen ? Nennt man glaube ich Kundenservice, wenn ich mich nicht täusche.
Klingt aus Sicht des Entscheiders plausibel. Kann passieren, muss man dann mit leben. Kann sein. Erstmal definiert PayPal die Transaktions IDs nicht als 1:1 sondern als 1:n. Wenn PayPal die eigene API so spezifiziert, hat PayPal recht. Die bestimmen wie ihre Daten funktionieren, wir zeigen die nur sinnvoll an. EIne Spalte tut also nicht. Zweitens wäre das eine Lüge gegenüber unserem Nutzer. Der Shop ist nicht der einzige Weg eine Transaktion zu beeinflussen, es gibt genug andere Systeme die auch "PayPal API" können und die Daten verändern können. Wenn der Shop das dann nie merkt, weil er sich auf einen Historismus beruft, dann ist das eine Fehlleistung. Wir speichern die nötigen Daten um gut zu handeln, und das ist es dann. Man müsste die auch eher extra holen anstatt die zu haben. Da ist ein Liveergebnis 300x besser, das zeigt an was gerade wirklich ist. PayPal 3 kam mit GX 2.4 in den Shopkern, seit dem nicht mehr. Das alte davor war vor grob 4 Jahren und hat abgebildet wie PayPal 2012-2012 war, nicht das PayPal wie es 2019 ist. Es wär ein leichtes da irgendeinen Schmufix hinzuballern, es wäre nur dumm, darum machen wir das nicht. Wir sind Kundenservice orientiert, wir geben uns immer Mühe und versuchen hilfreich zu sein. Dazu gehört aber auch Leuten mal zu sagen wenn diese ein totes Pferd reiten. Machen wir auch, finden wir fair und wirklich guten Service.
Dann sollte man der Fairness halber auch erwähnen, dass die Pferde nicht an altersschwäche sterben, sondern einem in regelmässigen Abständen vom Viehhändler unter dem Arsch weggeknallt werden um einem ein "neues und besseres" Pferd verkaufen zu können. (Nein, mit dem Viehhändler ist nicht Gambio gemeint.)
Komisch nur, dass Paypal selbst bei Fragen und Problemen immer nach der TransactionID fragt und NIE nach der PaymentID. Im PayPalkonto wird auch nur die TransactionID angezeigt und man kann auch nur nach dieser suchen. Mit der PaymentID kommt man selbst bei PayPal also nicht sehr weit. Ich denke hier sollte sich das Gambio nochmal überlegen, mag zwar so theoretisch richtiger zu sein, hilft aber den meisten ehern nicht. Lösungsansatz: Schreibt doch alle TransactionIDs, semikolongetrennt, in eine Spalte, fertig.
Ich erwähne das noch mal, weil das in der Diskussion hier gerade untergeht: Das Shopsystem liefert über die die aktuelle, REST/JSON-basierte Schnittstelle sämtliche Daten, die PayPal zur Verfügung stellt. Die PayPal-APIs anzusprechen ist kein Hexenwerk, die Hersteller von WaWi- und ERP-Software könnten das auch tun und sich anhand der vom Shopsystem gespeicherten Payment-IDs sämtliche Daten zur selbstständigen Verarbeitung abholen. Sie könnten sich dort sogar einen Webhook registrieren, um die Zahlungsbestätigungen von PayPal geliefert zu bekommen.
Der Markt verändert sich, die Werkzeuge und Produkte haben sich zu verändern. Am Beispiel von PayPal sind die viele Schritte vorwärts gegangen. Da sind mal neue Zahlungsweisen dazugekommen, die technischen Schnittstellen haben sich stark verändert, das alles mit Nutzen. Der Kunde hat nicht nur mehr Auswahl als früher, das funktioniert alles auch viel stabiler. Dass man das letzte mal von Cent-Rundungsfehlern und Abbrüchen deshalb mit PayPal gelesen hat ist zum Beispiel lang her und viele andere Dinge. Ich halte überhaupt nichts von "früher war alles besser", dann kucke ich mir das früher sehr genau an und stelle fest das stimmt oft überhaupt nicht. Und wenn das so ist, dann war es gut, dass die alten Pferde abgeknallt werden, alles richtig gemacht. Nochmal: Wir wollen keine historischen Daten dauerhaft schreiben, die dem Shop 0 nützen, die vom Shop unbemerkt mit echten Daten auseinander laufen können und für die wir die Vollständigkeit und damit Korrektheit nicht im Ansatz garantieren können. Wem nützt das was? Das ist komplette Augenwischerei, und das kann man nicht als Lösung verkaufen. Was Marco da gerade schreibt ist die letztlich die Wahrheit: Da tricksen sich eure Lösungen elegant aus der Affäre selbst mit PayPal zu reden um ihre benötigten Subdaten zu bekommen, und damit eine echte Lösung für PayPal Transaktionen anzubieten, behaupten aber offensichtlich sie können PayPal. Die können nur PayPal 2010, damals als man Steintafeln benutzte. Die werden umständlich lückenhaftere Buchungen erzeugen, weil die aus Unfähigkeit, Stillstand oder Inkompetenz mit Kerzen im Nebel arbeiten. Im Prinzip ist das für eine hiesige Lösung und eine hier hochrelevante Zahlungsweise hochtraurig. Ihr fordert dann von uns eine Pfuschreparatur, denn mehr könnte es beim besten Willen nicht werden, obwohl die Baustelle und die nachhaltige Lösungsmöglichkeit andere als wir haben. Wir sagen Nein, machen wir nicht, wollen wir nicht.
Habt Ihr eine Liste von ERPs für die es eine funktionierende Schnittstelle für REST gibt? Nunja, die werden halt genau so argumentieren wie Gambio und dann den Steuerberater oder die DATEV in die Pflicht nehmen, die Daten ebenfalls in real-time abzuholen. Nur haben diese den PayPal-Zugang wohl eher nicht. Irgendwer muss diese TransactionID also speichern, da ich diese ja in der Buchhaltung eh brauche. Gambio will es nicht mehr machen, also müssen wir die ganze in Gambio integrierte PayPal-Schnittstelle nochmal in die ERP einbauen, ja? Meine Buchhalterin wird sich freuen, wenn sie bei jedem Aufruf des Buchhungssatzes auf die Rückmeldung der PayPal-API warten muss. Davon abgesehen, habe ich in der db überhaupt die PaymentsID, wird die in der XML übermittelt? Ich finde in der db nur einen "gambio_hub_transaction_code". Was ist das wieder?
Die TransactionsID ist doch einmalig und ändert sich nicht mehr. Da kann auch nichts auseinanderlaufen. Ich buche ja in der FiBu mit der TransactionID, weil das die einzige unique Buchungsnummer zu dieser Zahlung ist. Du behauptest ja damit, dass meine Buchhaltung inkonsistent wäre - ist sie aber nicht. Wie in meinem Vorposting schon geschrieben, ab einer bestimmten Menge an Buchungen am Tag, ist realtime, leider auch heute noch, nicht mehr machbar. Kommt mal vorbei, ich lasse euch gerne mal buchen und dabei die ID von PayPal abrufen, mal schauen ob Ihr euer Tagesziel erreicht. Ich denke nicht. Und jetzt bitte nicht auf die Performance unserer Internetleitung oder die der Paypal-Server schieben. Im Endeffekt gibt es für eine Firma ein sehr wichtiges Kriterium zur Entscheidungsfindung und das ist der Kunde. Wenn also viele Kunden keine TransactionID haben wollen, dann ist ja alles gut....
Die Oberste Ordnung einer Zahlung ist die Payment ID. Nach Definition von PayPal können innerhalb dieser Zahlungsvorgänge zu beliebigen Zeitpunkten Transaktionen dazukommen (wahrscheinlicher) oder entfernt (unwahrscheinlicher) werden. Beliebiger Zeitpunkt meint durch andere an das Konto angeschlossene Systeme, durch Aktionen im PayPal Händlerportal oder durch Aktionen des PayPal Supports. Der Shop könnte höchstens abbilden was zum Zahlungszeitpunkt mal galt, wenn dann durch einen der besagten Schritte jemand am Kartenhaus wackelt würden wir sofort Blech liefern. Das wollen wir nicht, wir werden unsere Meinung dazu keinsfalls ändern. Ich behaupte es gibt passable Chancen, dass die Buchhaltung inkonsistent wird, je komplexer das Setup als Händler ist desto eher. Eine Transaktions ID ist ein Subelement, ein Subdatum eines Zahlungsvorgangs. Wenn eure Systeme das haben wollen müssen sie auch fähig sein sich das zu besorgen und auf Konsistenz zu prüfen, sowie mit sich weiterevolvierenden Zahlungsvorgängen umzugehen. Könnte ja mal ein Refund, etc. dazukommen... Die PayPal API kann das, wir können das auch, und wir sind keine Zauberer. Alle Gambio Shops holen seit Jahren grosse Mengen an Daten live aus PayPal. Im Hub machen wir das an einer Stelle im grossen Stil um die Daten in anfragende Shops zu spielen. Das geht gut. Die Aussage war unfundiert. Mit ner DSL1000 Leitung ist man ausreichend bewaffnet um in kurzer Zeit tausende Bestellungen bei PayPal zu pollen. Das die da ist setze ich vorraus, der Shop wird ja auch irgendwie abgeholt. Die Software am Ende muss nur unterstützend wirken statt bremsend und helfen das zu automatisieren statt mit Anachronismen zu bremsen. Wir arbeiten sehr kundenzentriert... ...aber wir bauen deswegen nicht jeden Mist. Wenn ein Kunde sagt springt von der Brücke, dann machen wir das trotzdem nicht. Es gibt eine Sinngrenze, darum werden wir uns da nach Überlegung nicht ändern. Letztes Wort. Im besten Fall sagt ihr euren anderen Enden "Gambio will nicht, die sind richtig blöd". Mit noch mehr Glück setzen die sich dann auf ihren Hosenboden und machen ihre Hausaufgaben endlich mal. Das wäre der einzig gültige Weg vorwärts, darum sende ich genau diese Botschaft. Wir werden uns da nicht ändern.
Die Paypal Transaktions-ID ist eindeutig einer Transaktion zu gewiesen mit der genau DIESE Transaktion identifiziert wird. Die Payment-ID ist ein Überbegriff und kann mehrere Transaktions enthalten. Belege mir das Gegenteil, dann bin ich gerne bereit diese Aussage zu überdenken. Ob dies nun Mist ist oder nicht hängt sicherlich vom Standpunkt ab, aber einen Standpunkt kann man auch ändern, wenn es notwendig ist und hilft. Software soll grundsätzlich Probleme lösen und keine neuen schaffen, leider muss ich immer wider feststellen, dass die bei den Programmieren nicht immer auch so ankommt und man lieber technische "Neuerungen" bedient als die eigentlichen Probleme zu lösen. Mein subjektiver Eindruck: wenn nur halb so viel Energie in Dinge gesteckt wird die seit mehreren Jahren immer wieder nachgefragt und dem eigentlich Sinn und Zweck eines Online-Shop zugeordnet werden (Bundles, Bestellartikel individuell bei jedem Artikel definieren und nicht pauschal im Shop, Filterdarstellungen, Grafische Attribute etc..) wie zum Beispiel in die Entwicklung der Rest-API, die dem eigentlichen Anwender und auch dem Kunden eigentlich gar nichts bringt, dann wäre Gambio sehr fortschrittlich. Wie gesagt, ist mein subjektiver Standpunkt und sollte als konstruktive Kritik verstanden werden und nicht als Schimpfe. So, und jetzt gehe ich wieder ans ausbügeln der Probleme, die uns die Entwickler so aufs Auge drücken
Sagt jemand der seinen Lebensunterhalt mit der Softwareentwicklung verdient. Gut, ich erwarte auch von einem Steuerberater nicht wirklich dass er sich für eine Vereinfachung des Steuerrechts einsetzt, oder von einem Anwalt dass er für einfachere Gesetzgebung plädiert. Ich zum Beispiel halte gar nichts davon wenn man jede Art von Kritik an einem sich weiter entwickelnden System als "Anachronismus" abzubügeln versucht, dann hat man nämlich nicht verstanden was das Wort "Kritik" bedeutet und läuft Gefahr sich jeder Art von Diskussion zu verschliessen mit Sätzen wie: "Wir werden uns da nicht ändern." oder "Letztes Wort." oder "...wir werden unsere Meinung dazu keinsfalls ändern." (Manchmal hat man den Eindruck Gambio spricht ex cathedra) Ich sage das noch einmal, falls es noch nicht jeder verstanden hat: Das etwas neu ist, heisst nicht automatisch dass es auch besser ist. Gerade das, was in den letzten Jahren im Bereich des Ecommerce und der Medien etc. passiert ist, hat wenig bis gar nichts damit zu tun was Technik eigentlich sein soll, nämlich ein Hilfsmittel um das Leben einfacher und angenehmer zu machen, sondern wird mehr und mehr zum Selbstzweck um in möglichst kurzer Zeit, möglichst viel Profit, aus möglichst vielen Menschen zu pressen.
Ich und die Firma verdienen dann Geld, wenn wir unseren Kunden ein funktionierendes Ökosystem anbieten, heute und in Zukunft. Ich tue also gut daran die Interessen vieler Leute zu vereinen, eine Quintessenz zu ziehen und dem ganzen dann eine Richtung zu geben. Innehalten wo es gut ist, und voran wo eben das gut ist. Beides sind Optionen, beides muss man weise einsetzen. Damit das gelingt muss Softwareentwicklung passieren, aber das nur alleine als Softwareentwicklung zu bezeichnen ist nur die halbe Medaille. Ich bin ein Drittel des Tages Handwerker, ein weiteres Drittel Architekt und ein Drittel Politiker und Stratege. Ich denke insgesamt mehr im Erhalt und Ausbau des Ökosystem als im Shopcode. Wir sind nicht allein auf der Welt, ich sprach eben schon vom Ökosystem. Ein Ökosystem lebt vom Zusammenspiel vieler Hände. Bei Partnern und Dienstleistern muss man regelmässig mal klare Worte sprechen, damit am Ende alle an einen Tisch passen. Es gibt Regeln, an die man sich zu halten hat. Wir sind ab und zu Empfänger solcher Ansprachen, ab und zu sind wir Sender solcher Ansprachen. Jeder muss das da tun, wo es seine Verantwortung ist. Ich hab 0 Skrupel auch mal klare und absolut eindeutige Botschaften abzusetzen. Was du nicht tun solltest: Das was ich hier klipp und klar aussage als Antwort auf jede andere Frage betrachten. Hier gehts um die Antwort dieser Frage hier, keiner anderen, und da ist die Aussage klar. Das kann man als in diesem Fall hier wenn man denn will wie du es sagst als päpstlich sehen, ich steige bei anderen Fragen aber sofort von "meiner Kanzel". Ich sage das auch noch einmal, falls es noch nicht jeder verstanden hat: Das etwas alt ist, heisst nicht automatisch dass es besser war. Für Generalisierungen solcher Aussagen "wie alles was neu ist...alles was alt ist..." bin ich 0 zu haben, keinen Zentimeter. Man sehe sich eine konkrete Sache und ihre Evolution an, sammele Wissen dazu, betrachte die Optionen und urteile dann so fachkundig wie man es zu tun vermag. Und das über jede Sache einzeln. Wer das mit mir macht, kriegt einen lebendigen und offenen Diskurs mit mir. Andere Kollegen hier funktionieren genauso. Generalisierung, Pauschalisierung, unkonkret. Find ich so sachlich ziemlichen Käse.
"Käse" ist lediglich, wenn man nicht weiß was Fundamentalkritik ist, oder wie man damit umgehen soll. Als selbständiger Unternehmer in Deutschland verbringe ich mittlerweile ein gutes Viertel meiner Arbeitszeit mit dem Befolgen teilweise vollkommen schwachsinniger gesetzlicher Vorgaben (von den finanziellen Aufwendungen hierfür mal ganz abgesehen). Diesem Beispiel folgend: Ich werde nicht weitere Stunden und Tage damit vertrödeln Stundenzettel zu schreiben, Berichte und Statistiken zu den verschiedenen, ganz konkreten Gesetzen und Verordnungen zu erstellen um den Vorwurf der "Pauschalisierung" oder "Generalisierung" zu entkräften, um dann am Ende ein "das sind ja alles nicht repräsentative Einzelfälle" zu hören. Wenn Du die gesamtgesellschaftliche Entwicklung der letzten 10 Jahre gut findest, dann ist das Deine Meinung, die steht Dir zu. Wenn ich mich umsehe und feststelle dass das Streben nach immer mehr Wohlstand und Profit von immer mehr Menschen zu immer mehr Reglementierung und Unfreiheit des Einzelnen führt, dann ist das meine. Die steht mir zu.
Da meine Cola und Popkorn jetzt erstmal alle sind, muss ich auch mal noch meinen Senf hier abladen. Ich bin selbst auch direkt schon seit 2016 mit dieser Situation betroffen, dass die WAWI zwar PayPal Daten abrufen kann aber dank fehlender einheitlicher Daten, keine automatisierter Zahlungsabgleich mit den Bestellimporten erfolgen kann. Anfangs dachte ich auch das es ein Gambio-Problem sei und hier doch dringend die Transaktions-ID übergeben werden muss. Mittlerweile bin ich aber schon einen Schritt weiter und stelle fest das es doch an der unflexiblen WAWI bzw. derren Machern liegt, das es hier keinen Fortschritt gibt. Bei uns kommt es schon regelmäsig vor das mehrere PayPal Zahlungen zu einem Einkauf gehören und wir hierfür dann sogar noch Teil-/Rückzahlungen vornehmen. Insofern kann ich Wilkens/Gambios Standpunkt klar nachvollziehen und würde mir auch eher wünschen das auf WAWI Seite mal was vorwärts geht.
Und jeder Zahlung und auch jede Rückzahlung wird eindeutig durch eine Transaktions-ID definiert, welche in der Payment-ID gruppiert sein kann, sofern der Bezug zur Bestellung vorhanden ist oder eigenständig frei im Raum stehen kann weil der Kunde einfach von Hand Geld per Paypal geschickt hat. Ich bin jetzt kein Rechtsberater aber wenn ich es noch richtig im Hinterkopf habe, dann muss laut Steuergesetzgebung jede Zahlung (egal in welche Richtung) eindeutig identifiziert werden können, was mit der Transaktions-ID problemlos möglich ist, da diese der Fingerabdruck darstellt. Oder ? Wenn der Hersteller der WaWi unflexibel ist oder der Hersteller der Buchhaltung oder sonst wer mag zwar unschön sein, dies zu wissen trägt aber nicht zur Lösung des Problems bei. Und wann dann noch die sturen Hersteller dazu kommen, dann wird's richtig lustig. Ich glaub ich hol mir jetzt auch ne Tüte Popcorn ;-)