Aus der Notsituation ergab sich eine Idee ein Plugin zu entwickeln, der die verloren gegangene (gelöschte) Buchungen "wiederfindet".
Es ist nicht so, dass das Plugin sie wiederherstellen kann und die Rede ist nur von Ausgabenbuchungen, die als Sammelposten auftauchen.
Man stelle sich eine Situation vor:
Man hat einen Sammelposten mit 5 Jahren AfA. Aus Versehen löscht man im 2. Jahr der Abschreibung die Buchung. Was nun? Kommt der Jahreswechsel, so verschwindet die Buchung auch im neuen Jahr, genauer genommen verschwindet die Buchung für immer!
Wenn das am Jahresanfang passiert, dann ist die Sache einfach: Man druckt gegebenenfalls die Buchungen aus, geht in das alte Jahr zurück und führt den Jahreswechsel erneut aus. Anschließend vervollständigt man ggf. neue Buchungen. Was ist aber, wenn es schon zu viele neue Buchungen sind? Dann verbringt man zu viel Zeit damit, die Buchungen ins Reine zu bringen.
Hier kommt die Lösung:
Nachdem mir das widerfahren ist, habe ich beschlossen nicht den langen Weg zu gehen, die Buchungen ausdrucken und dann neu zu tippen, sondern den langen Weg zu gehen, ein Plugin zu entwickeln, das die AfA-Buchungen des Vor-Vorjahres, vor dem Ausführen des Jahreswechsels, in eine externe Datenbank aufnimmt und mit den Buchungen des Vorjahres vergleicht, ob jene oder welche fehlen. Sollte das Plugin feststellen, dass eine Buchung, die natürlich im Vor-Vorjahr nicht abgelaufen ist, im Vorjahr fehlt, dann kann diese im Vorjahr vervollständigt werden und wird im neuen Jahr mittels der Funktion "Jahreswechsel" auftauchen, sofern diese im Vorjahr nicht ablief.
Nun stehe ich aber vor einer entscheidenden Frage überhaupt: Jede Buchung hat eine eigene ID, damit man sie eindeutig identifizieren kann. Wenn nun eine Buchung durch den Jahreswechsel übertragen wird, hat sie denn die selbe ID wie im Vorjahr?
Die ID des Buchungs-Objekts ist nur gültig während das Objekt im Arbeitsspeicher der Anwendung existiert. Tatsächlich ist die ID die binäre Speicheradresse und wird sich bei jedem Neustart ändern. Die beste Möglichkeit, die Buchung wiederzufinden, wäre den Beschreibungstext zu nehmen. Aber das ist natürlich nur eine Heuristik und sollte vom Nutzer nochmal bestätigt werden.
Es war mir auch schon in den Sinn gekommen die Buchungen über die Beschreibung zu identifizieren, und auch ich bin darüber gestolpert, dass das auch nur etwa 30 % genaue Identifikation wäre. Stattdessen könnte man die kompletten Angaben nehmen, bis auf die Buchungsnummer, denn die wäre aufgrund fehlender Buchung durch eine andere Buchung belegt. Diese Methode wäre aber mit einem mehr oder weniger komplexen Aufwand verbunden und selbst dann wäre die Genauigkeit von etwa 95 %.
Ihre Idee mit dem Buchungstext, über den ich auch schon nachgedacht hatte, hat mir aber eine Idee gebracht. Der Buchungstext und Index sind in einem Gedanken verschmolzen: Ich habe mir überlegt, dass man im Buchungstext an letzter Stelle von Hand einen Index angibt, der durch bspw. ein "Pipe" vom Buchungstext getrennt wird. Über eine Split-Funktion, könnte man dann auf den zweiten Teil des Buchungstextes zugreifen und hätte dann eine eindeutige Identifikation, die nur dann fehlschlagen würde, wenn man selbst einen Fehler macht, indem man z. B. einen Index zwei mal verwendet.
Da dies nur eine Vorübergehende Lösung ist und auch fehleranfällig ist, wäre zu überlegen, ob man beim Buchungsobjekt nicht eine Eigenschaft "Index" hinzufügt, die nur Intern eingetragen wird und dann auch nur bei Ausgabenbuchungen und selbst dann, wenn die Abschreibungsdauer mehr als 1 Jahr beträgt. An dieser stelle würde ich auch mit einem Teil des Codes helfen, denn Sie nur anzupassen bräuchten.
Ich bekomme ja häufig Daten zu Testzwecken. Die Beschreibungstexte bei AfAs sind immer sehr sprechend. Ich würde von 99.9% ausgehen, was, da es sich nicht um eine Routine-Anwendung handelt, voll ausreichen dürfte. Ich würde die Datenstruktur nicht aufbohren, wenn es nicht 100%ig nötig wäre -- einfach um es 'easy' zu lassen.
Hier der C++ Code, mit dem ich die AfAs in das neue Jahr übertrage:
(Bitte den Pointersalat einfach ignorieren. **ppB ist die neue Buchung/Rate, *pB die alte.)
Kann sich natürlich ändern, z.B. sollte ich nochmal degressive Abschreibungen einbauen. Vielleicht sollte ich das als Methode des Buchungs-Objekts zugänglich machen...
Bearbeitet von mielket am 30.01.2010 22:34:37
mielket geschrieben:
Kann sich natürlich ändern, z.B. sollte ich nochmal degressive Abschreibungen einbauen. Vielleicht sollte ich das als Methode des Buchungs-Objekts zugänglich machen...
ja, bitte mach das mal. ich würde dein programm gerne an investoren von photovoltaik-anlagen weiterempfehlen. die haben ja ordentlich was abzuschreiben und möchten das oft degressiv tun.
Springe ins Forum:
Forensuche
Shoutbox
Du musst dich einloggen um eine Nachricht zu senden.
mielket
14.10.2025 10:40:17
Naja, wäre EC&T nativ für MacOS entwickelt worden und man bräuche einen Mac-Emulator drumrum, damit es auf Windows läuft, gäbe es auch Reibungsverluste.
Thomas R
04.10.2025 11:39:18
Danke, ich weiß schon, warum ich lieber in der Win-Welt lebe.
mielket
04.10.2025 11:12:27
Der Plugin-Manager kann nur EC&T updaten, nicht das Crossover, das im EasyCT4Mac.zip Paket enthalten ist.
mielket
04.10.2025 11:09:47
nicht ganz: Das Problem war, dass der Fehler nicht in der EC&T-Software an sich steckte, sondern in der Windows-Simulation der Firma Codeweavers drum herum.
Thomas R
04.10.2025 07:48:12
@thomas_stahl Wenn du auf das Icon des Button "Plugin" klickst geht dein Wunsch in Erfüllung.
thomas_stahl
03.10.2025 20:43:01
Version 3.4. hat meine Druck-Probleme gelöst! Danke
thomas_stahl
03.10.2025 20:37:06
Warum gibt es keinen Button "Update" wo ich einfach die neueste version einfach Installieren kann?
