Darlehensverwaltung
Darlehensverwaltung
Meine Darlehensverwaltung ist eines der komplexeren Probleme gewesen, die ich in iDempiere bisher gelöst habe. Ich dokumentiere es hier, um einerseits ein paar Gedanken darzulegen, die man sich manchen sollte, wenn man in der Buchhaltung etwas ganz neues machen möchte. Andererseits dient dieser Artikel natürlich auch als Anleitung für andere, die Darlehen verwalten wollen.
Beschreibung des Geschäftsvorfalls
Unser Unternehmen gibt Darlehen an Geschäftspartner. Das können im einfachen Fall Darlehen für Warenlieferungen sein (also eher eine Art Zahlungsziel), aber vor allem spreche ich hier von echten Darlehen, denen ein Darlehensvertrag zu Grunde liegt, für die regelmäßige Raten vereinbart werden und für die Zinsen berechnet werden. Darlehen können sich über mehrere Jahre erstrecken und wir brauchen natürlich auch ordentliche Kontoauszüge.
Ich möchte gerne Zahlungsverpflichtungen beihalten, d.h. die fälligen Raten der Darlehensnehmer im Auge behalten.
Zinsrechnungen sollen in unterschiedlichen Abständen erstellt werden. Die eigentliche Zinsberechnung macht bisher ein anderes Programm, sollte aber später auch automatisch erfolgen können.
Kurz und gut - ich möchte eine kleine Bank implementieren.
Überlegungen zum Thema
Da Darlehen in iDempiere eigentlich gar nicht besonders vorgesehen sind, stellt sich die Frage, wie man diese am besten implementiert. Ich habe mich von der Grundregel leiten lassen, möglichst ohne Änderungen an der Software selber und nur mit einer Konfiguration in der Datenbank auszukommen. Dies ist mir weitgehend gelungen.
Die Antwort auf die Frage, wie man Darlehens-Vorfälle auf Belege und Buchungen abbildet ist der Kern der Lösung. Zuerst kam mir der Gedanke, das man in iDempiere bereits zu Rechnungen einen Zahlungsplan machen kann: Ein Beleg, Raten vorher vereinbart, alles prima. Aber wie geht man z.B. mit Zinsen um? Und was ist, wenn ich ein Darlehen zwischendurch verlängere (also wieder aufstocke bzw. Raten stunde, um sie "hinten dranzuhängen")? Als nächstes dachte ich, ich müsste hierfür einen (oder mehrere) neuen Basis-Belegtyp(en) programmieren. Für selbstdefinierte BEleg-Basistypen gilt allerdings ein Leitsatz, der an vielen Stellen in iDempiere gilt, wenn es um das selberprogrammieren geht: Meistens braucht man das nicht, weil es mit den Bordmitteln auch geht.
Grundsätzlich kann ein Kunde auch mehrere Darlehen haben. Da es sich sowieso anbietet, eine eigene Tabelle zu haben, um Darlehensverträge zu verwalten (mit Daten wie Laufzeit, Zinssatz, einer Kopie des Vertrages, etc.) wäre es schön, wenn man die verwendeten Belege einem Vertrag zuordnen könnte. Entweder IST der Vertrag dieser Beleg oder es muss eine Referenz geben. Zuerst habe ich wie gesagt über die erstere Lösung nachgedacht. Allerdings ist es eine Eigenschaft eines Beleges, das er ein fixes Datum und fixe Buchungen hat (wenn er abgeschlossen wird). Die Vielzahl an möglichen Verläufen eines Darlehens verbietet es allerdings, von Anfang an feste Buchungen vorzunehmen. Wir benötigen für jeden einzelnen Vorfall in Zusammenhang mit dem Darlehen einen eigenen Beleg. Daraus folgert, das wir eine Referenz auf eine Vertrags-Tabelle benutzen müssen, um alle Belege zusammenzuhalten, die zu einem Vertrag gehören. Um nun auch die Buchungen zusammenzuhalten, bietet es sich an, für diese Referenz eine der Buchführungsdimensionen zu nutzen.
Die Lösung brachte mir eine andere Sichtweise auf die Belege und Buchführungsdaten in iDempiere. Grundsätzlich ist es so, das es verschiedene Typen von Belegen gibt. Diese Belege erzeugen Buchungen. Diese Buchungen bilden die Grundlage aller Berichte und damit auch der Kontoauszüge etc. Es gibt allerdings eine besondere Art von Belegen. Rechnungen und Zahlungen verwalten nämlich zusammen die offenen Posten (und noch ein paar verwandte Belegtypen wie Gutschriften, Zuordnungen, etc.). Und da wir mit fälligen Beträgen arbeiten, die bezahlt werden sollen, komme ich nicht umhin, das Problem von dort aus zu betrachten. Auch die ursprüngliche Darlehensauszahlung ist zuerst einmal eine fällige Zahlung (an den Kunden). Mein "Darlehensbeleg" muss also entweder ein Zahlungs- oder ein Rechnungs-Beleg sein.
Da eine Bewegung auf meinem Bankkonto immer zuerst einmal eine Zahlung ist und ich für meine Zinsabrechnung ja auch genau deren Datum haben möchte, muss ich entweder die Zahlung mit in meine Darlehensauswertung aufnehmen oder jeweils einen passenden Rechnungsbeleg erstellen, wenn die Zahlung eingeht. Da ich ja die Fälligkeit von Raten im Auge behalten will, bietet es sich hier eher an, bei Fälligkeit eine Rechnung zu erstellen und diese dann bei Zahlungseingang mit einer Zahlung auszugleichen.
Alle Darlehenszahlungen sollen natürlich auf ein eigenes Konto gebucht werden, damit man den aktuellen Darlehensstand eines Kunden ablesen kann.
meine Lösung
Ich definiere drei neue Belegarten, die von vorhandenen Basis-Belegarten "Rechnung" und "Gutschrift" abgeleitet sind. Diese benutzen einen eigenen Nummernkreis sowie eine eigene Buchungsart, um später danach filtern zu können.
Alle Belege benutzen eine eigene Buchführungsdimension. Ich benutze hierzu die "UserElement1" Dimension, da keine der vorgegebenen Dimensionen zu meinem Problem passten. Diese Referenz wird dann an jede Buchung angefügt, die sich aus einem Beleg ergibt, an dem die Referenz angegeben ist. Hierdurch kann ich später einen Kontoauszug erzeugen, der alle Buchungen zu einem Vertrag zusammenfasst.
Zur Verbuchung der Darlehenszahlungen lege ich zwei Direktbuchungen an:
- Darlehenszahlung - bucht auf Konto "1360 Darlehen an Kunden". Nehme ich für Darlehensein- und Ausgänge wie die Darlehensauszahlung und spätere Raten. So ergibt sich eine gewinnneutrale Umbuchung innerhalb des Anlagevermögens von "Verbindlichkeiten aus Lieferungen und Leistungen" (das Konto, auf dem die offenen Posten stehen) zu "Darlehen".
- Zinsertrag Darlehen an Kunden - bucht auf Konto "7100 Zinserträge". Hier ergibt sich ein Gewinn und gleichzeitig eine Forderung an den Kunden. Wer die Zinsen nicht direkt fällig stellen will, braucht eine weitere Rechnungszeile, um den Betrag direkt per "Darlehenszahlung" auf das Darlehen aufzuschlagen. Zinserträge sind übrigens USt-frei zu buchen.
Die von mir neu angelegten Belegarten sind:
Darlehensabschluss
Diese Belegart wird für ein neues Darlehen verwendet, das ausbezahlt werden soll. (Auch eine Verrechnung mit einer offenen Warenrechnung ist im Rahmen der offene-Posten-Verrechnung möglich.) Die Belegart basiert auf einer Kunden-Gutschrift, da hier wie da im Ergebnis ein Guthaben auf dem Forderungskonto entsteht. Ein Beleg dieser Art wird immer eine einzige Zeile mit einer Direktbuchung "Darlehenszahlung" enthalten. Der zugrundeliegende Geschäftsvorfall ist genau genommen die Vereinbarung eines Darlehens. Die eigentliche Auszahlung ergibt sich dann aus der Fälligkeit bzw. der Zahlung, die dieser Gutschrift später zugeordnet wird.
Darlehensrate
Diese Belegart wird für eine fällige Darlehensrate benutzt. Die Belegart basiert auf einer Kunden-Rechnung, da hier wie da ein fälliger offener Posten entsteht. Ein Beleg dieser Art wird immer eine einzige Zeile mit einer Direktbuchung "Darlehenszahlung" enthalten.
Ein Beleg dieser Art kann als wiederkehrender Beleg in iDempiere angelegt werden, so das automatisch am Monatsanfang eine Rate fällig wird.
Zinsberechnung
Diese Belegart wird für eine Zinsabrechnung benutzt. Die Belegart basiert auf einer Kundenrechnung. Ein Beleg dieser Art wird immer eine Zeile mit einer Direktbuchung "Zinsertrag Darlehen an Kunden" haben. Ggf. kann man noch eine weitere Zeile "Darlehenszahlung" einfügen, um die an sich fälligen Zinsen direkt wieder auf das Darlehen zu buchen (das hängt davon ab, wie man die Zinszahlungen mit dem Kunden vereinbart hat).
Es wäre wünschenswert, die Zinsen hier automatisch aus den Zahlungen des Kontoauszugs zu berechnen. Der ganze Beleg könnte auf diese Art automatisiert aus den Vertragsdaten erstellt werden. Für den ersten Schritt werden die (händisch berechneten) Zinsen hier eingegeben.
Änderung am Datenmodell
Ich habe eine neue Tabelle BAY_Contract angelegt (als Vorlage ist übrigens M_FreightCategory nützlich) und hier die Eigenschaften eines Darlehensvertrages erfasst. Dann habe ich entsprechende Felder BAY_Contract_ID in die Tabellen C_Invoice und C_Payment eingefügt.
Ich habe die obengenannten Belegtypen, deren zugehörige Buchungsart und einen Nummernkreis angelegt.
Fenster
Es ist sinnvoll, ein eigenes Fenster zu definieren, in dem die entsprechenden Belege erstellt werden können. Dort gibt man einen Vertrag an und ein Callout sorgt dann dafür, das der entsprechende Geschäftspartner automatisch ausgefüllt wird. Dieser ist also gar nicht direkt zu editieren.
Ein wichtiges Problem ist, das alle Belege dem Vertrag zugeordnet werden müssen. Bei den eigenen Belegtypen ist das relativ einfach. Einerseits legen wir die ja jeweils spezifisch für einen Vertrag an. Andererseits kann ein Callout und/oder ein ModelValidator dafür sorgen, das immer ein Vertrag angegeben ist.
Anpassungen in Prozessen
Etwas schwieriger ist es, alle Zahlungen dem entsprechenden Vertrag zuzuordnen. Das muss aber sichergestellt werden. Zahlungen werden recht häufig automatisch erstellt. Hier müssen also die entsprechenden Prozesse angepasst werden, die z.B. Zahlungen aus offenen Posten oder aus einem Bankauszug erzeugen. Wird eine Zahlung an dieser Stelle aus einer Rechnung erzeugt, muss dafür gesorgt werden, das die Referenz zum Vertrag ebenfalls aus der Rechnung in die Zahlung übernommen wird.
Da ich sowieso im Zuge von Rationalisierungen im Zahlungsverkehr einige neue Prozesse geschrieben habe, habe ich das jeweils beachtet.
An folgenden Stellen musste ich eingreifen:
- automatische Erzeugung von Zahlungen aus dem Kontoauszug (einzeln und alle)
- periodische Replikation von Belegen (für Raten)
TODO - mehr beschreiben, an welchen Stellen ich diesbezüglich eingegriffen habe
Kontoauszüge
Hierfür habe ich einen besonderen Bericht definiert, der die Konten eines Kunden geordnet ausgibt.
TODO - näher erklären - die Filterung ist trickreich
noch wünschenswerte Erweiterungen / Programmierungen
- Automatisierte Erstellung von Dauerauftrags-Rechnungen
- Zinsabrechnung
Typische Geschäftsvorfälle, deren Workflow und Buchungsauswirkungen
Vereinbarung eines Darlehens
Kunde Müller (K4711) unterzeichnet einen Darlehensvertrag und soll 10.000,- € bekommen. Er will monatlich 100,- € zurückbezahlen und zahlt 80% Zinsen. Das ist sein erstes Darlehen bei uns (01).
Ein neues Objekt der Tabelle "BAY_Contract" wird angelegt und die entsprechenden Verwaltungsdaten wie Geschäftspartner (K4711), Zinssatz (8%), Vertragsbezeichnung (4711-01), monatliche Rate (100,- €) etc. werden eingegeben. Dann wird im Darlehensbelege-Fenster ein Beleg vom Typ "Darlehensabschluss" angelegt und eine Zeile mit einer Direktbuchung des Darlehensvertrages auf das Darlehenskonto angelegt.
Erzeugt wird ein gewöhnlicher offener Posten, der beim nächsten Zahlungslauf z.B. per Onlinebanking zur Bank geschickt wird. Es ist natürlich auch möglich, im Beleg eine Fälligkeit anzugeben, falls das Darlehen nicht sofort ausgezahlt werden soll.
Außerdem erzeuge ich am besten direkt die Rechnung für die Ratenfälligkeit (siehe unten).
Gebucht wird dann folgendermassen:
Konto Soll Haben Vertrag Belegart Buchungsart 1360 Darlehen an Kunden 10.000,- € K4711-01 Gutschrift Darlehen an 1200 Forderungen aus Lief. und Leist. 10.000,- € K4711-01 Gutschrift Darlehen
Zur Erklärung: 1360 ergibt sich aus dem Direktbuchungs-Artikel, der im Beleg verwendet wird. 1200 ergibt sich aus dem Geschäftspartner-Buchführungsregister.
Auszahlung eines Darlehens
Die Summe wird (z.B. per Onlinebanking oder aus der Kasse) bezahlt. Da in iDempiere das Kassenbuch wie ein Bankbuch/Bankkonto behandelt wird, gebe ich hier im Beispiel die Buchungen für die Bank an. Es muss darauf geachtet werden, das bei der Zahlung der Vertrag als Referenz angegeben wird!
Konto Soll Haben Vertrag Belegart Buchungsart 1801 Bankbewegungen nicht abgegl. -10.000,- € K4711-01 Zahlung Zahlung an 1803 nicht zugeordnete Eingangszahl. -10.000,- € K4711-01 Zahlung Zahlung 1803 nicht zugeordnete Eingangszahl. -10.000,- € Zuordnung Quittung an 1200 Forderungen aus Lief. und Leist. -10.000,- € Zuordnung Quittung
Zur Erklärung: Es handelt sich um zwei getrennte Belege. Die Zahlung bucht auf zwei Clearingkonten des Bankkontos (1801 und 1803 sind im Buchführungsregister des Bankkontos angegeben). Die Zahlung bucht auf das Forderungskonto des Kunden: 1200 ist beim Geschäftspartner im Buchführungsregister vermerkt.
iDempiere bucht negative Werte, wenn eine Ausgangszahlung zu einer Kundenrechnung stattfindet (eigentlich dienen diese ja dazu, das Geld reinkommt...).
Bemerkenswert ist außerdem, das die Zuordnung nicht den Vertrag an den Buchungssatz schreibt. Ich habe mir überlegt, ob ich das ändern muss, damit das automatisiert geschieht. Allerdings ist eine Zuordnung ja genau dazu da, mehrere unterschiedliche Zahlungen mit mehrereren unterschiedlichen Rechnungen zusammenzubringen. Wo soll der Automat da den Vertrag herholen. Ich habe mich dann letztlich entschieden, das es besser ist, wenn die Vertragszuordnungen manuell eingetragen werden. Und da die Zuordnungen so gut wie nie manuell bearbeitet werden (sondern immer irgendwie automatisch erzeugt werden), nehme ich für meine Kontoauszüge etc. die Zahlung als ausschlaggebenden Beleg.
Fälligkeit einer Rate
Ich erzeuge eine Rechnung (d.h. einen Beleg vom Typ Darlehensrate), deren Fälligkeitsdatum dem vereinbarten Ratentermin entspricht. In die Rechnungszeile schreibe ich eine Direktbuchung auf das Darlehenskonto.
Im Menüpunkt "Periodisch" (im Menü Einstellungen Organisation) kann man diesen Beleg nun als "Abo" definieren, d.h. er wird periodisch z.B. immer am Monatsanfang kopiert und ausgeführt.
Konto Soll Haben Vertrag Belegart Buchungsart 1200 Forderungen aus Lief. und Leist. 100,- € K4711-01 Rechnung Darlehen an 1360 Darlehen an Kunden 100,- € K4711-01 Rechnung Darlehen
Zur Erklärung: 1360 ergibt sich aus dem Direktbuchungs-Artikel, der im Beleg verwendet wird. 1200 ergibt sich aus dem Geschäftspartner-Buchführungsregister.
Rückbuchung einer Rate
Dieser Vorgang wird ganz normal behandelt wie eine gewöhnliche Rückbuchung von Warenbelegen auch. Allerdings ist zu beachten, das an der erzeugten Zahlung die Referenz zum Vertrag angegeben wird. Außerdem sollte darauf geachtet werden, das das Valutadatum (also das Belegdatum) richtig gesetzt ist (für die spätere Zinsrechnung).
Konto Soll Haben Vertrag Belegart Buchungsart 1801 Bankbewegungen nicht abgegl. -100,- € K4711-01 Zahlung Zahlung an 1803 nicht zugeordnete Eingangszahl. -100,- € K4711-01 Zahlung Zahlung
Wird die Rate später bezahlt, ergibt sich eine weitere Zahlung, die mit der Rückbuchung verrechnet wird. Ist bei beiden der Vertrag angegeben, ist alles gut und der Kontoauszug spiegelt das wahre Geschehen genau wieder.
Konto Soll Haben Vertrag Belegart Buchungsart 1801 Bankbewegungen nicht abgegl. 100,- € K4711-01 Zahlung Zahlung an 1803 nicht zugeordnete Eingangszahl. 100,- € K4711-01 Zahlung Zahlung
Wird die Rate nicht nachbezahlt, entspricht das einer Erhöhung des Darlehens. In diesem Falle muss ein Beleg wie bei einer Darlehensauszahlung (mit der identischen Vertragsreferenz) erstellt werden. Damit wird die Rate aus den fälligen Posten herausgenommen und wieder in das Darlehen gebucht.
Konto Soll Haben Vertrag Belegart Buchungsart 1360 Darlehen an Kunden 100,- € K4711-01 Gutschrift Darlehen an 1200 Forderungen aus Lief. und Leist. 100,- € K4711-01 Gutschrift Darlehen
Zinsabrechnung
Die Zinsabrechnung ist im Grunde einer normalen Rechnung sehr ähnlich. Wir erzeugen eine Forderung und einen Gewinn. Sie enthält lediglich zur Zuordnung eine Vertragsreferenz.
Konto Soll Haben Vertrag Belegart Buchungsart 1200 Forderungen aus Lief. und Leist. 800,- € K4711-01 Rechnung Darlehen an 7100 Zinserträge 800,- € K4711-01 Rechnung Darlehen
Wer die Zinsabrechnung nicht direkt fällig stellen will (das hängt von den vereinbarten Darlehenskonditionen ab), kann mit einer zusätzlichen Zeile das Darlehen gleichzeitig um die Summe erhöhen (Direktbuchung mit Minus-Summe):
Konto Soll Haben Vertrag Belegart Buchungsart 1360 Darlehen an Kunden 800,- € K4711-01 Rechnung Darlehen an 1200 Forderungen aus Lief. und Leist. 800,- € K4711-01 Rechnung Darlehen
Fehler bei der Vertragszuordnung
Wie ich mehrfach betont habe, ist es wichtig, an jedem relevanten Beleg den Vertrag anzugeben. Was ist, wenn man das vergessen hat? Es führt kein Weg daran vorbei: Man muss den Beleg stornieren und neu erstellen. Alternativ kann man zwei Belege erstellen und diese gegeneinander verrechnen. Welche Vorgehensweise man wählt, sollte Geschmackssache sein bzw. am besten den sonstigen Abläufen beim Umgang mit Stornos im Unternehmen entsprechen.
Links
- http://wiki.frei-bier.org/wiki/Darlehensverwaltung - alte Seite mit ein paar Überlegungen (größtenteils veraltet)