Hallo Hr. @eliansawatzki,
auf diese Antwort habe ich nur gewartet. Sie und natürlich auch die DATEV unterstellen hier aber, dass es nur einen Zahlungsdienstleister namens PayPal gibt. Und nur für diesen einen Zahlungsdienstleister wurde eine eigene neue Schnittstelle geschaffen. Neben PayPal gibt es aber noch zig andere Zahlungsdienstleister und diese wollen auch bearbeitet werden. Jeder dieser Dienstleister hat dabei seine eigenen Attribute um den OP-Ausgleich vorzunehmen.
Mit dem Bankenimport wurde seinerzeit von DATEV ein universelles und sehr gute Möglichkeit geschaffen, Zahlungsdaten zu importieren und zu verarbeiten. Hier hätte jeder halbwegs intelligente Programmierer/Entwickler auf diese Schnittstelle aufgesetzt und eine zukunftssichere und universelle Importmöglichkeit geschaffen. Dazu wäre es nur nötig gewesen, wenn die Bankdaten um ein Attribut Zahlungsdienstleister erweitert worden wären. Der OP-Ausgleich wäre dann immer der gleiche, egal ob CoBa oder PayPal, da diese ja den gleichen Datenaufbau haben. Die Prüfroutinen wären auf alle Felder zu erweitern, unabhängig ob da nun eine Email-Adressen drinsteht oder nicht. Warum soll auch das Rad 2 x erfunden werden. Meine Vermutung mit der eigenen Schnittstelle ist die, dass DATEV hier zusätzlich abkassieren kann, da es ja eben seitens DATEV keine offene Schnittstelle zum Import von PayPal-Daten gibt.
Aber zurück zu meinem Mandanten:
Mein Mandant hat im Monat ca. 2000 Ausgangsrechnungen, die über
- PayPal
- Avocado
- Stripe Payments
- und normale Banken bezahlt werden.
Bleiben wir einmal bei PayPal.
Hier ist das entscheidende Ausgleichskriterium der Transferticketcode, welches alternativ in die Auftrags-Nr. eingetragen werden soll. Der Import dieses Transferticketcode stellt keine Hürde da, aber dieser Import gilt dann für alle Ausgangsrechnungen!
Aber was mache ich den bei den anderen Zahlungsdienstleistern und Banken? Da brauche ich diese nicht, sondern die OrderID!
Hier denkt wieder die DATEV zu kurz und löst nur genau ein Problem. Alles andere wird ignoriert.
Diese ganzen Probleme hätte man nicht, wenn die PayPal-Routine in die normale Programmroutine Bankenabruf integriert wäre und der OP-Ausgleich um mögliche Meta-Informationen erweitert hätte. Damit wäre der Anwender frei in seiner Entscheidung ob er den Abruf oder den Import wählen will/muss, weil DATEV nicht alles abdeckt (andere Zahlungsdienstleister). So wurde aber genau ein Problem (PayPal) gelöst und man kann sehen wie man hunderte von Buchungen bei den anderen Dienstleistern ausgleicht.
Genau diese kurzsichtige Sichtweise zwingt mich, meinen eigene OP-Ausgleich durchzuführen, indem ich jegliche Meta-Daten sammele und die Bankendatei so erweitere, dass DATEV damit einen "Banken-OP-Ausgleich" vornehmen kann.
Auch hätte ich als Entscheider, die Zusatzfelder genutzt (s. Datensatzaufbau f. Rewe-Daten), um diese als zusätzliche OP-Ausgleichsinfos zu erweitern. Hierzu wäre es ganz einfach, wenn die Felddefinition um ein Attribut (neben der Bezeichnung) erweitert worden wäre (z. B. #OP#[Feldname]). Beim Import von Ausgangsrechnungen könnte man somit einfach diese Zusatzfelder nutzen um eventuelle Informationen nutzen zu können, die ausschließlich für den OP-Ausgleich gebraucht werden. DATEV kann doch mehrere Zusatzinfos (insg. 8 Felder stehen zur Verfügung) verwalten.
Das würde dem Anwender ein Handwerkszeug an die Handgeben, das überhaupt keine Wünsche mehr offen lassen würde. Das ist echte Zukunftsmusik.
Stattdessen, wird an einem Symptom (PayPal) rumgebastelt und dann ist gut. In der Vergangenheit gab es z. B. vermehrt Probleme mit dem Abruf der PayPal-Daten. Die Schuld trägt zwar nicht DATEV, aber der Anwender sucht sich jetzt dumm und dusselig um die Salden abzustimmen. Auch kann der Anwender nicht bequem über DATEV-Bankendatei nach Inhalten in den PayPal-Auszügen suchen. Nein, stattdessen darf er entweder die PDF-Auszüge zusätzlich herunterladen und hier suchen, oder er es macht das Online im PayPal-Portal. Alles doppelte Arbeit und unnötig,
Und wenn wir schon beim OP-Ausgleich sind:
Warum findet DATEV eigentlich keine Werte, wenn eine Rechnung mehrfach bezahlt wurde?
Es kann doch nicht so schwer sein, statt und in den OP-Werten zu suchen, die gesamte OP-Datei zu durchsuchen und wenn eine Rechnung gefunden wurde die noch offen ist, diesen vorzuschlagen mit OP-Ausgleichsdialog (Makrierungen der RgNr.) und wenn kein OP gefunden wurde, dann zumindest doch die Kundennummer vorzugeben.
Jetzt suche ich nach einer Rechnung die bereits ausgeglichen wurde und findet nichts mehr. Also raus aus der Erfassung und rein die Buchnungsübersicht damit ICH WIEDER MANUELL NACH DER KUNDENNUMMER SUCHEN KANN. Das ist die KI von DATEV.
Gruß Achilleus, der Besserwisser