WICHTIG: Steuerhinterziehung durch MB bei Verwendung von PayPal

Hallo zusammen,

kann mir bitte jemand kurz nochmal einen Tipp zu den lästigen "Temporary Hold" Buchungen geben?
Den Abruf habe ich von SOAP auf REST-Api umgestellt gehabt.

Nun hatte ich Guthaben auf dem Paypalkonto. Für dieses Guthaben habe ich dann bei einem Händler etwas verkauft.

Beim Abruf erhalte ich nun eine "Temporary Hold"-Buchung und der Kontostand stimmt danach nicht mehr. Irgendwelche Gegenbuchungen etc. in 1970 gibt es auch nicht.

Wie soll ich hier vorgehen?

Über die Suche habe ich gelesen, dass ich über die Direktfunktion (-> ltconvert) bestimmte Buchungen beim Abruf ignorieren kann.

Dann hieß es irgendwo das der Filter nicht mehr klappt, dann wieder schon usw. Jedenfalls scheint es bei mir nicht zu funktionieren.

Er ruft immer noch die blöde Buchung ab. Getestet habe ich es mit T1500, T1501, T1502 und T1503 ausprobiert (Liste).

Hat jemand eine Idee?

Bin für jeden Tipp dankbar.

Moin,

im Verwendungszweck bei einem Paypalumsatz wird immer auch die dazugehörige Ziffernfolge aufgeführt. Sieh einfach die Tempory Hold Umsätze an und scrolle den Verwendungszweck ganz nach unten.

Zitat von Buecherwurm

Hallo zusammen,

kann mir bitte jemand kurz nochmal einen Tipp zu den lästigen "Temporary Hold" Buchungen geben?
Den Abruf habe ich von SOAP auf REST-Api umgestellt gehabt.

Nun hatte ich Guthaben auf dem Paypalkonto. Für dieses Guthaben habe ich dann bei einem Händler etwas verkauft.

Beim Abruf erhalte ich nun eine "Temporary Hold"-Buchung und der Kontostand stimmt danach nicht mehr. Irgendwelche Gegenbuchungen etc. in 1970 gibt es auch nicht.

Alles anzeigen

Bank deposit entsteht doch durch Lastschrift vom Bankkonto. Das Bank deposit als Umbuchung Bank, und die Bank Abbuchung Umbuchung Paypal deklarieren, dann landen beide auf dem Verrechnungskonto und gleichen sich aus auf Null.

Zitat von Mausko

Moin,

im Verwendungszweck bei einem Paypalumsatz wird immer auch die dazugehörige Ziffernfolge aufgeführt. Sieh einfach die Tempory Hold Umsätze an und scrolle den Verwendungszweck ganz nach unten.

Den Hinweis habe ich auch in Deinem anderen Beitrag gesehen. Aber bei mir ist im Verwendungszweck keine Nummer enthalten (siehe Screenshot oben).

Ich habe lediglich

Removed
Bestellnummer 1234....
Temporary Hold

Zitat von Michael1972

Bank deposit entsteht doch durch Lastschrift vom Bankkonto.

Bei mir ist die Zahlung aber über PayPal-Guthaben erfolgt. Schau mal:

Was mir aber auffällit:

Bei PayPal sehe ich drei Transaktionen. WMB holt aber nur zwei Transaktionen ab.

Neben der eigentlichen Buchung und der Temporary Buchung gibt es noch eine mit gleichen umgekehrten Betrag welche den Endbetrag wieder korrigieren sollte.

Das heißt:

Entweder ich kriege die Temporary Buchung ignoriert oder aber ich kriege WMB dazu auch die dritte Buchung abzuholen...

Edit: Ein kurzes Update meinerseits:

Über Postman habe ich eine manuelle API-Abfrage gemacht um die Event Codes herauszufinden.

Nr. 3 dürfte die "normale" Zahlung sein. Nr. 1 wird von WMB ignoriert.

Mausko kann es sein, dass die Lösung darin besteht T1105 in den Filter zu nehmen?

Das tut mir sehr Leid Buecherwurm ! Buhl schreibt sie holen mit der neuen Schnittstelle ALLE Buchungen von PayPal ab und nun ist es doch nicht so?

Kann das jemand bestätigen der bereits von SOAP auf REST-Api umgestellt hat?

Zitat von babylonian

Das tut mir sehr Leid Buecherwurm ! Buhl schreibt sie holen mit der neuen Schnittstelle ALLE Buchungen von PayPal ab und nun ist es doch nicht so?

Kann das jemand bestätigen der bereits von SOAP auf REST-Api umgestellt hat?

Ich hab vor einer Weile umgestellt und hab bisher alle Buchungen ausgeglichen bekommen.

Moin,

ich habe dort T1105,T1501 stehen und es ist Ruhe mit den Tempory Hold Buchungen. Aber wie ich schon ursprünglich hingewiesen habe, es sollte über die Direktfunktion nur etwas geändert werden, wenn man weiß, was man tut.

Zitat von Mausko

Moin,

ich habe dort T1105,T1501 stehen und es ist Ruhe mit den Tempory Hold Buchungen. Aber wie ich schon ursprünglich hingewiesen habe, es sollte über die Direktfunktion nur etwas geändert werden, wenn man weiß, was man tut.

Danke für Dein Feedback. Ich habe testweise T1105,T1501 (ohne Leerzeichen) und T1105, T1501 (mit Leerzeichen) eingetragen. Dennoch ruft er immer noch Fleißig die T1105 ab.

Mausko nur zur Sicherheit: Direktfunktion -> Code eintragen -> GO -> Bei PayPal "Zahlungsfilter" die zwei T-Nummern rein -> OK -> OK -> Umsatz abrufen. Hab ich hier eventuell noch irgendwas vergessen?

Ich werde wohl ein Ticket erstellen müssen. Selbst wenn die Filter mittlerweile ignoriert werden, muss WMB laut Aussage von Buhl Support C. Diel eigentlich ja mittlerweile alle Umsätze abrufen und das tut es definitiv (zumindest bei mir) nicht.

Das der Saldo in WMB am Ende mit dem Saldo bei PayPal nicht mehr übereinstimmt setzt dem Ganzen noch die Krone auf.

Moin,

ich habe nochmal in meiner Korrespondenz mit Buhl geschaut. Ich habe denen damals geschrieben: "Es können beim erneuten Abholen der Auszüge offenbar die gleichen Umsätze unter anderem Namen wieder auftauchen. Die Codes sollten dann kommasepariert in dem Zahlungsfilter eingetragen werden, bis die Umsätze und der Saldo wieder stimmen. Bevor die Aktion gestartet wird, sollte das PayPal Konto nach dem Notieren der Codes offline gestellt werden und die entsprechenden Umsätze gelöscht werden.""

Darüber hinaus habe ich noch ein Häkchen bei Paypal LT Umsatzabgleich.

Mach bitte immer vorab eine Datensicherung.

Zitat von Mausko

Mach bitte immer vorab eine Datensicherung.

Die mache ich definitiv, keine Sorge

Ich habe hier sogar noch mein Backup bevor ich den Abruf gemacht habe. D.h. ich kann testen und bei Widerherstellung kennt WMB die falschen Umsätze noch nicht . PayPal nutzte ich mittlerweile sehr sehr selten, so dass eigentlich auf dem Konto kaum was los ist.

Ich werde berichten sobald ich eine Antwort vom Support habe.

Zitat von Buecherwurm

Ich werde berichten sobald ich eine Antwort vom Support habe.

Kurzes Feedback meinerseits.

Ticket habe ich letzte Woche Freitag erstellt. Bis heute immer noch keine Rückmeldung erhalten. Telefonisch kommt man zum Support auch nicht durch...

Offensichtlich ging die letzte saftige Preiserhöhung nicht mal Anteilig in den Support....

Ich berichte sobald endlich eine Antwort vorliegt.

Mit viel Geduld habe ich es heute mehrfach über den Telefonsupport versucht - mit Erfolg.

Was gemacht wurde:

1. PayPal - Konto auf offline stellen.

2. Temporary Hold + die "normale" Abbuchung gelöscht

3. Konto auf online gestellt

4. Abruf

Dadurch habe ich aber wieder eine 1970er Buchung bekommen. Das Saldo stimmt aber nun da ich in 1970 eine Buchung mit -13.99 erhalten habe.
Laut der Mitarbeiterin sei dies kein Problem.

Mir gefällt diese Lösung aber nicht... Was meint ihr?

Sie meinte eine Umstellung von REST auf SOAP sollte möglich sein. Mit SOAP lief alles bei mir prima... Eine Anleitung wollte sie mir zuschicken. Noch habe ich nichts erhalten.

Was ich aber gerade bemerkt habe:

Ich kann die 1970er Buchung komplett ändern (Buchungsdatum / Wertstellungsdatum / Betreff .... ) d.h. ich kann mir dadurch eigentlich die fehlende Buchung die WMB abholen sollte "basteln".

Buecherwurm, vielen Dank für den Tipp, ich warte jetzt seit 11.08 auf eine Antwort vom Support.

Bei mir hat geholfen, dass Bankkonto auf offline und dann wieder online zustellen, jetzt stimmt der Saldo wieder überein.

Guten Tag Buhl-Support-Team,
Guten Tag Herr Buhl Support C. Diel

im März 2022 schrieben Sie mir, dass die von mir zu Recht bemängelten Punkte in der neuen PayPal-Schnittstelle bekannt sind und eine korrekte Sortierung und Vereinfachungen im Programm "geprüft" werden.

Bitte teilen Sie mir mit, ob die Probleme

1. Reihenfolge der Paypal-Buchungen

2. Verbuchung bei extern gestellter Rechnung (aufwändige Split-Buchung)

behoben wurden. Sollten Sie die Probleme behoben haben, bitte ich um Screenshots und / oder Erkärung wie es nun funkioniert.

Ist zum jetzigen Zeitpunkt davon ausgehen, dass die aktuell noch gut funktionierende SOAP-Schnittstelle noch eine Weile von Ihnen gepflegt wird oder planen Sie in absehbarer Zukunft eine Zwangsumstellung auf die REST-Schnittstelle?

Mit freundlichen Grüßen

Ralf

Zitat von babylonian

Buhl hat sich auf mein ebenfalls erstelltes Ticket zurück gemeldet

Zitat

Christoph Diel 16.03.2022 08:44:33

vielen Dank für Ihre Anfrage.

Zu den von Ihnen genannten Punkten haben wir mit unseren Entwicklern Rücksprache gehalten und möchten gerne wie folgt Stellung nehmen:

1. Reihenfolge der Paypal-Buchungen

Bei der aktuellen Sortierung der Paypal-Umsätze wird sichergestellt, dass die Buchungen tagesgenau im Programm abgebildet werden. Die tagesweisen Salden stimmen also mit denen von Paypal überein. Die Reihenfolge der Darstellung der Buchung im Programm WISO MeinBüro Desktop kann allerdings abweichen gegenüber jener auf der Paypal-Seite. Damit einhergehen können dann auch Abweichungen beim Saldo, der in der Spalte "Saldo" im Programm angezeigt wird.

Wir prüfen hier derzeit weitere Optionen. Bis dahin sei aber gesagt, dass zwar der Abgleich der Salden der Paypal-Buchungen im Programm WISO MeinBüro Desktop mit den Salden auf der Paypal-Seite nicht immer direkt möglich ist, buchhalterisch betrachtet durch die Zuordnung zum entsprechenden Datum und den damit tagesweisen korrekten Salden aber die relevanten Vorgaben hinsichtlich der korrekten zeitlichen Abgrenzung der Buchungen eingehalten werden.

2. Verbuchung extern gestellter Rechnungen

Mit der REST-API liefert Paypal die Buchungen bedauerlicherweise nur noch direkt mit dem um die Gebühren reduzierten Betrag. Aus diesem Grund besteht beim Ausgleich von Rechnungen, die nicht mit unserem Programm erstellt wurden, aktuell lediglich die Möglichkeit einer etwas aufwändigeren Splittbuchung. Auch hier prüfen wir, ob sich Vereinfachungen im Programm integrieren lassen. Eine abschließende Entscheidung oder einen schnelleren Workaround gibt es hierzu allerdings noch nicht.

3. Paypal-Filter

Die Paypal-Filter sind sowohl mit der Anbindung über SOAP- wie auch über REST-API noch nutzbar. Mit dem Update wurden lediglich die bereits hinterlegten Filter entfernt. Grundsätzlich steht der Nutzung der Filter nichts im Wege.

Allerdings supporten wir die Filter nicht und werden auch keine FAQ dazu erstellen. Grund ist, dass erfahrungsgemäß eine solche Anleitung zu Missverständnissen führen würde. Wir veröffentlichen schriftlich nicht einmal den Weg zu den Filtereinstellungen, weil diese in einem Programmbereich vorgenommen werden, der äußerst sensibel ist. Unkorrekte Eintragungen an dieser Stelle können zu schweren und irreparablen Schäden an der Datenbank führen. Auf direkte Anfrage im Rahmen eines Anrufs bei unserer Hotline führen wir unsere Kunden gerne an die entsprechende Stelle. Allerdings geben wir keine Beratung zu den genauen Filtereinstellungen. All diese Informationen sind zwar im Internet und auch im Forum zu finden, wir möchten aber noch einmal betonen, dass die entsprechenden Einstellungen immer auf eigene Verantwortung erfolgen.

Abschließend weisen wir gerne noch einmal auf einen Punkt hin, den Sie selbst ja völlig zutreffend bereits erwähnt haben: Die SOAP-Anbindung wird nicht mehr weiterentwickelt. Insofern werden auch wir unseren Fokus künftig auf die REST-Schnittstelle legen. Die Verbuchung der Gebühren bei der Zuordnung eines Geldeingangs über REST-API zu einer Rechnung im Programm erfolgt korrekt, und wir prüfen, wie erwähnt, aktuell auch Optionen für eine einfachere Verbuchung von Einnahmen, zu denen es keine Rechnung in unserem Programm gibt.

Für weitere Fragen, Anregungen und Hinweise stehen wir Ihnen selbstverständlich gerne zur Verfügung.

Alles anzeigen

ich habe dazu heute folgende Antwort geschrieben

Zitat

Sehr geehrter Herr Diehl,

vielen Dank für Ihre Antwort.

1. Reihenfolge der Paypal-Buchungen

leider entspricht Ihre Aussage nicht der Realität. Wie Sie hier eindeutig sehen können:

RE: WICHTIG: Steuerhinterziehung durch MB bei Verwendung von PayPal

stimmt von 12 Salden kein einziger überein. 1 Saldo scheint auf den ersten Blick mit dem von PayPal angegebenen identisch zu sein, jedoch bei einer völlig anderen Transaktion. Es stimmt also in diesem Beispiel mit 12 Transaktionen KEINER der Salden mit PayPal überein.

Sie schreiben: "die tagesweisen Salden stimmen also mit denen von Paypal überein." Das ist falsch. Es gibt keine tagweisen Salden welche übereinstimmen. Sie schreiben weiterhin "buchhalterisch betrachtet durch die Zuordnung zum entsprechenden Datum und den damit tagesweisen korrekten Salden aber die relevanten Vorgaben hinsichtlich der korrekten zeitlichen Abgrenzung der Buchungen eingehalten werden." Wie schon gesagt, es gibt die korrekten tagweisen Salden nicht. Gern können Sie mir das Gegenteil darlegen (bei mehr als 5 PP-Transaktionen pro Tag). Das wird aber kaum gelingen, ich habe die neue Schnittstelle bereits eingehend getestet. Die Salden sind völlig chaotisch, ein zufällig übereinstimmender Saldo wäre ein reiner Glücksfall. Der herunterladbare Kontoauszug von PayPal ist für die Finanzverwaltung der relevante Beleg. Ihre Salden müssen mit diesem übereinstimmen. Sie würden ja auch nicht beim klassischen Bankkonto chaotisch sortierte Buchungen und vom Kontoauszug abweichende Salden akzeptieren. PayPal wird von der Finanzverwaltung als Bankkonto eingestuft.

Sie schreiben: "Die Reihenfolge der Darstellung der Buchung im Programm WISO MeinBüro Desktop kann allerdings abweichen gegenüber jener auf der Paypal-Seite." Warum ist das so? Wieso sortieren Sie die Buchungen nicht einfach korrekt anhand des Zeitstempels, der unzweifelhaft von PayPal über die API übermittelt wird (List transactions: GET/v1/reporting/transactions -> transaction_initiation_date": "2014-07-11T04:03:52+0000"). Bei der alten Schnittstelle haben Sie es (nach Jahren der Bitten) dann ja auch hin bekommen die Buchungen endlich korrekt zu sortieren. Nun wurde diese "Errungenschaft" gleich wieder zunichte gemacht.

Schreiben Sie also bitte nicht Aussagen wie: "Wir prüfen hier derzeit weitere Optionen." Sondern bis spätestens ____ werden die Zeitstempel korrekt implementiert und die Umsätze dementsprechend korrekt sortiert. Die Technik möge bitte bei der Implementierung auch die Zeitzone berücksichtigen, sodass es nicht wieder zu stundenweisen Abweichungen kommt, welche am Tagesende/Quartalsende/Jahresende wieder zu falschen Buchungstagen führt.

Falls unlösbare Gründe dagegen sprechen, bitte ich um Auskunft, welche das sind.

2. Verbuchung der PayPal-Umsätze bei extern gestellter Rechnungen

Sie schreiben: "Mit der REST-API liefert Paypal die Buchungen bedauerlicherweise nur noch direkt mit dem um die Gebühren reduzierten Betrag." Sie begründen also die für o.g. Kundengruppe unbrauchbar gewordene Verbuchung damit, dass PayPal angeblich den Brutto-Betrag nicht über die REST-API übermitteln würde. Sind Sie sich dessen so sicher? Ich muss das stark anzweifeln. Der Brutto-Betrag ist über die REST-API abrufbar, zum Beispiel über den Befehl:

GET/v1/reporting/transactions

dieser gibt neben dem Zeitstempel wie oben erwähnt außerdem aus:

"transaction_amount": {

"currency_code": "USD",

"value": "465.00"

"fee_amount": {

"currency_code": "USD",

"value": "-13.79"

Somit ließe sich der Bruttobetrag und die Gebühr leicht getrennt abbilden.

Sie schreiben es gibt "aktuell lediglich die Möglichkeit einer ETWAS aufwändigeren Splittbuchung." Wir reden hier nicht über eine ETWAS aufwendigere Buchung, sondern über eine praktisch nicht nutzbare Funktion. Es ist zeitlich völlig unzumutbar mehrere duzend oder gar hundert Transaktionen täglich einzeln über eine Splittbuchung zu erfassen.

Bisher konnten tausende Gebühren-Transaktionen gefiltert und dann entweder über: Weitere Funktionen F3 -> zuordnen innerhalb von Sekunden korrekt zugeordnet werden. Wenn man den Zuorndungs-Assistenten benutzt ließen sie sich mit OK & Weiter F12 mit einem Knopfdruck erledigen. Damit kann man ebenfalls mehrere duzend Buchungen innerhalb von einer Minute verarbeiten. Gleiches gilt für alle PayPal Erlöse für die das gleiche Verfahren angewandt werden kann.

Nun mit der Splittbuchung ist das alles nicht mehr möglich. JEDE einzelne PayPal Transaktion sollen wir nun händisch anfassen und brauchen dann weit über 10 Mausklicks, Eingaben, diverse Auswahlen und Scrolls bis eine Splittbuchung gebucht werden kann. Von der Fehleranfälligkeit den falschen Betrag einzugeben oder die falsche Steuerkategorie auszuwählen ganz zu schweigen. Vielleicht wird Ihnen nun klar, dass diese Art der Verbuchung völlig unpraktikabel ist und eine Zumutung für bestehende, zahlende Kunden, welche Ihre Software seit Jahren verwenden und sich eine Verbesserung und keine Verschlechterung erhoffen. Auch zu diesem Punkt hilft Ihre Aussage: "Auch hier prüfen wir, ob sich Vereinfachungen im Programm integrieren lassen." nicht, denn natürlich lässt sich das integrieren, sie müssen es nur machen.

Ich möchte Sie und Buhl/Deltra hiermit auch im Namen der anderen Nutzer darum bitten die beiden o.g. Punkte Zeitstempel/Sortierung und PayPal ohne Splittbuchung mit wichtiger und dringender Priorität in Ihre ToDo-Liste aufzunehmen.

Danke schon jetzt, für Ihre positive Antwort und Ihre Bemühungen Wiso MeinBüro besser zu machen.

Mit freundlichen Grüßen

Alles anzeigen

Alles anzeigen

Hallo zusammen,

ich muss das Thema noch mal hochholen. Ich nutze die Rest-API für PayPal habe aber immer noch mit den Hold-for-Dispute- und Reversal-Buchungen zu kämpfen, die ich mühselig mit dem Verrechnungskonto verrechnen muss. Gibt es hier immer noch keine Lösung durch Wiso mein Büro, dass ausschließlich die relevante Buchung gezogen wird? Vielen Dank.

Gruß

Marcel

Bei mir werden schon seit längerem beide Buchungen angezeigt.

Ich buche beide auf 1590 Durchlaufender Posten, hebt sich gegenseitig auf