Hallo Hr. Kohlberg,
wie so oft sprechen Sie mir aus dem Herzen.
Zu Ihren Ausführung will ich mal meinen Kommetar/Lösungsvorschlag beifügen:
Dazu kommt jeden Monat die Problematik, daß wir diverse Paypal- Zahlungen ohne Rechnung haben, die ja erst zum Zeitpunkt der Auslieferung erstellt wird.
Das ist leider traurige Realität und wird von DATEV leider komplett ignoriert.
Als ersten Schritt haben wir den dringenden Wunsch nach einem Belegfeld 2, welches die Vorgangsnummer aus dem WaWi- System enthalten kann und nach dem dann auch das automatische Ausziffern erfolgen kann.
Dem ist nichts weiter hinzuzufügen. Das das Belegfeld2 als abweichende Fälligkeit missbraucht wird, ist mir unbegreiflich. Zumal es DATEV bis heute, also seit mehr als 30 Jahren es nicht geschafft hat, hier einmal eine zukunftsweisende Lösung zu finden. Schließlich stammt dieser Mißbrauch ja noch aus den alten DOS-Zeiten.
Ein weiterer Wusch wäre, daß man in den Buchungssatz ein Feld für einen Freitext bekommt, welches mit OPOS- Funktionen ausgestattet ist. Damit könnte das WaWi- System die registrierte Email- Adresse des PayPal- Nutzers übergeben, die dann mit den Paypal- Umsätzen abstimmbar wäre.
In meinem VBS-Tool habe ich die EMail-Adresse in den Verwendungszwecken in der Bankendatei mit aufgenommen. Es ware aber wirklich toll, wenn man bei einer Suche in der Buchungserfassung auch nach diesen Infos suchen kann. Jetzt muss ich immer erst in die Bankenauswertung wechseln und dort meine Suche durchführen. Das ist doch etwas umständlich, wäre aber zu verschmerzen, wenn man
a) in der Bankenauswertung auch in die Vergangenheit wechseln könnte und
b) man aus den gefundenen Bankenumsatz direkt per Doppelklick in die Buchhaltung zu dem Buchungssatz springen könnte. Es müsste also eine direkte Verknüpfung von FiBu-Buchungssatz und Bankenbewegung geben. Das sollte doch nun wirklich kein großes Problem sein.
Ob es je eine Möglichkeit geben wird Vorauskasse- Zahlungen zum Monatsende nach Eingang der Rechnung im Folgemonat ohne Umwege mit der korrekten Belegnummer und dem korrekten Gegenkonto ins System zu bekommen? Bei dem heutigen Festschreibewahn sehe ich da keine Möglichkeiten... Wie soll man später abstimmen, wenn alle Zahlungen ohne Rechnungen erst über # 1590 gebucht werden, um die Zahlungen nachträglich unter Verlust der Beleginfos dann manuell umzubuchen?
Das der Umsatz teilweise erst im neuen Monat ausgeführt, die Zahlung aber in der laufenden Buchhaltung (z. B. 02/2018) erfolgt, löse ich so, dass ich erst einmal proforma die Umsatzerlöse für den neuen Monat (03/2018) einspiele. Dann kann ich zumindest mit einer richtigen OP-Funktion arbeiten. Aber Sie haben natürlich recht mit dem Festschreibewahnsinn, denn bevor ich jetzt irgendetwas mache, muss ich ja immer wieder den Zukunftsvorlauf löschen. Ein nachträgliches Umstellen auf Stapelvorlauf ist ja nicht möglich. Mit einem reinen Stapelvorlauf habe ich aber keine OPOS-Funktion. Vielen Dank DATEV für den Klasse WorkFlow. Das einzige was hier immer wieder fließt, ist meine wertvolle Zeit (nur als Anmerkung: Problem der nachträglichen Datumänderungen im Vorlauf; mehr Arbeit kann man gar nicht programmieren).
Eine Möglichkeit wäre, wenn der Anwender nicht zuordenbare Zahlungen trotzdem auf das Debitoren- Konto buchen dürfte und das System Interims- Belegnummern vergeben würde, so daß im Folgemonat wenigstens ein unfallfreies manuelles Abstimmen möglich wird.
Dieses Problem hat sich damit nämlich erledigt, da ja die Zahlungen schon einmal mit richtiger Belegnummer und KdNr. gebucht werden.
Beim Buchen ohne Belegnummer werden ja alle Posten gerafft und damit ist das System unbedienbar. Daß sich die Buchhaltung eigene Belegnummern aus den Fingern saugen soll... ??? das kann und darf einfach nicht sein!!!
Schlimmer ist es sogar, dass ich nachträglich nicht die OPOS-Nummer neu vergeben kann. Bei unserem alten Simba-Programm konnte man einfach nachträglich Zahlungen auf einen neue OP-Nummer zuordnen. Die eigentliche Belegnummer wird ja nicht geändert. Auch DATEV arbeitet mit einer externen Belegnummer und einer internen OP-Nummer. Es ist also überhaupt kein Problem, dass auch hier einführen zu können.
PS: Als Debitorkonto wird natürlich 10000 verwendet und nicht für jeden Ebay- Kunden neuer Debitor.
Solange sich unser Mandant sich mit seinen Kundennummern sich im Kontenbereich bewegt, werde ich die Forderungen einzeln buchen. Ansonsten haben Sie natürlich Recht. In so einem Fall ware es natürlich klasse, wenn man hier Freifelder hätte, wo man die externe Kundennummer dann auch hinterlegen kann (s. o.).
Fazit:
Die gesamte OPOS-Verwaltung ist so altbacken und hat sich seit DOS-Zeiten nicht mehr geändert. Es wurde immer nur an der Oberfläche gewerkelt, der Quellcode ist aber nie auf die Zukunft ausgerichtet worden. In der alten DOS-Welt hatte uns die DATEV immer wieder gewungen mit absurdisten Tastenkombinationen von OP-Buchung / klassische Buchung zu wechseln. Dieses Programmverhalten hat letztendlich die DATEV immer noch beibehalten, ist aber komfortabler geworden (sonst würde ich mir auch die Kugel geben 
). Für eine wirkliche umfassende OPOS-Verwaltung im Zeitalter des Internethandels ist DATEV noch auf Jahre hin nicht gerüstet und läuft mit hängender Zunge den Innovationen anderer Anbieter hinterher. Ich möchte nur mal an die EU-Versandhandelsregelung anmerken. Dafür gibt es bis heute keine Auswertung bzw. Überwachung. Obwohl man sofort bei überschreiten der Grenzen sofort die Versteuerung ändern müsste.
Auch das Problem mit der vorschüssigen Zahlung und der Anforderung an einer zweiten Belegnummer wird nicht angegangen, obwohl das Problem schon seit Decaden vorhanden ist. Schließlich gibt es viele Mandaten, die für Ihren WE eine eigene Belegnummer vergeben, man aber gerne in der BF auch die Originalbelegnummer des Lieferanten aufnehmen möchte. Lösung á la DATEV: Nehmens Sie den Buchungstext! 
Ja geht's noch? Warum soll ich den Buchungstext nehmen, wenn es ein Belegfeld2 gibt? DATEV muss sich hier etwas anderes überlegen, und nicht der Anwender! Schließlich hat die DATEV die Probleme verbockt und nicht wir.
Aber der Marktmacht und der großen Verbreitung unter den Steuerberatern und des Phlegmas der Anwender sich auch um Alternativen umzuschauen, ist es zu verdanken, dass DATEV aus der sicheren Position heraus agiert. Die DATEV hat es einfach nicht nötig sich um die Belange der Anwender zu kümmern. Anders kann man sich doch das Verhalten der DATEV erklären (s. Diskussionen 3-Kontenmodell der DATEV; Einrichtungen/EB-Werte der Sachkonten-OP), wie hier eklatante Probleme einfach tod geschwiegen werden. Auch wie die DATEV an den Anforderungen der Anwender vorbei arbeitet, kann man dem Festschreibewahn von EB-Werten sehen. Hier macht sich die DATEV einfach zum Deppen, denn keiner von der Finanzverwaltung hat gefordert, dass EB-Werte festgeschrieben werden; es war und ist immer nur von der laufenden Buchführung die Rede (Zumindest habe ich keine Gegenteiligen Infos hierzu gefunden).
DATEV hat doch in den letzten Jahren keine tragenden Innovationen in Ihrem Kerngeschäft (Rewe) mehr entwickelt. Im Gegenteil, es wurden immer wieder neue Problemfelder neu geschaffen, alte aber nie richtig angegangen. Die paar Änderungen sind nun wirklich nicht die Rede wert, zumal der Berg der Probleme ja nicht kleiner wird.
Und DATEV möchte in die Steuerprogramme für den normalen Erdenbürger?
Ja, dann sollten Sie erst einmal die Steuerprogramme für Steuerberater überarbeiten. Warum z. B. kann ich Daten aus der GewSt. nicht in die ESt. übernehmen? Nur weil es eine andere Abteilung ist?
Und wie ist es mit Planspielen bzw. Vorausberechnungen?
Privat arbeite ich mittlerweile mit WiSo-Steuerprogramm und das ist richtig klasse. Bessere Assistenten kann man sich gar nicht wünschen. Da ist DATEV einfach der letzte Mist. Sorry, aber so ein blödsinniges Programm wie DATEV-ESt. habe ich noch nicht gesehen. Für jede kleinste Aufstellung jedesmal Excel bemühen? Bei diesem grottigen Programmverhalten?
Ne, DATEV. Kümmert Euch erst einmal um Euer Kerngeschäft und schafft endlich die Probleme ab. Baut eine einheitliche Datenbasis (Stammdaten) auf , so dass jedes Programm sich direkt bedienen kann und nicht jedesmal irgendwelche Daten verschoben werden müssen. Überarbeitet endlich die Drucksteuerung; allein dieses Thema würde schon Seiten füllen. Mit Euren Steuerprogramm würdet Ihr am freien Markt nämlich kläglich scheitern. Dafür sind andere Anbieter viel besser aufgestellt.
Gruß A. Martens
P.S.
An dieser Stelle möchte ich auch einmal an die Toolbox erinnern.
Da wurde alles in Excel programmiert, obwohl die Finanzverwaltung selber wunderbare Erfassungsformulare bereitstellt.
Und sogar für eine simple USt.-VA muss ich erst mühsamst die Toolbox bemühen, nur um eine paar Daten per Elster zu versenden.