Skip to main content
Skip table of contents

Technischer Implementierungshintergrund

Diese Informationen sind nur für Personen gedacht, die selbst als Entwickler das Modul RESTRUKT in seinen Basisfunktionen anpassen wollen. Es setzt tiefgreifende SQL Kenntnisse voraus.

RESTRUKT arbeitet nach dem Prinzip eines Buchungsautomaten. Alle finanzielle relevanten Werte und Parameter werden im Hintergrund in einer Buchung im Buchungsjournal umgesetzt.

Buchungsmethodik

Jede Buchung muss folgende Parameter ermitteln

  • KontoID - KontoID, auf welchem die Buchung erfolgt

  • UrsprungskontoID - KontoID des Kontos, welche die Buchungskette ausgelöst hat → somit nicht zwingend das Gegenkonto

  • Quelle - Ursprungskonto mit Urspungsperiode

  • VerteilungsID - ID der Verteilungsmethode, über welcher ein Monatswert auf Tage zerlegt wurde

  • Buchungskreis - Kalkulationsprozess, welcher diese Buchung ausgelöst hat → somit kein Buchungskreis im buchhalterischen Sinne

  • Buchungsdatum - Zuordnung zu einem Monat (Buchungsperiode 13 etc. existiert nicht)

  • Buchungstext - aussagekräftiger Text für alle Drilldownanzeigen

  • Betrag - Dezimalwert mit 10 Nachkommastellen → nicht auf Cent reduziert, da sonst viele Rundungsdifferenzen bei Split von Monatswerten auf Tage

  • Bewegungsart

Systemkonten

Restrukt benötigt zwingend eine Satz an Systemkonten für die korrekte Arbeit

  • GuV Systemkonten

    • STEE - Einkommensteuer, geplanter Steueraufwand wird immer als Zuführung Steuerrückstellungen gebucht

  • Bilanz Systemkonten

    • BANK - Konto für alle liquiditätswirksamen Bewegungen

    • GVV - Gewinn-/Verlustvortrag

    • JÜ - Jahresüberschuss (Pseudokonto für Druck der Bilanz), zählt nicht in die Summe GuV / Bilanz

    • STRST - Steuerrückstellungen

    • BAUS - Konto für Bilanzausgleich

Factorykonventionen

  • Es muss eine Factory ZT geben, diese nimmt alle Steuerungsproducts auf

  • alle anderen Factories werden frei als Mandantenfactories verwendet

Productlinekonventionen

Innerhalb einer Factory

  • Muss es immer die Productline ST geben, diese enthält Steuerungsproducts welche direkt adressiert werden

  • Muss es immer die Productline BIL geben, diese enthält die Bilanz

  • allen anderen Productlines können beliebige IDs verwenden, die Datenverarbeitung erfolgt auschließlich auf Basis der Templates

  • Ausserhalb von ST / BIL könnten (sollten aber nicht) somit auch Products gemischt verwendet werden (außer Products vom Typ Bilanz / Steuerung)

  • die Anzeigereihenfolge der Productlines wird über das Globalattribut Anzeigereihenfolge gesteuert

Bewegungsarten

Über Bewegungsarten wird gesteuert

  • Kapitalflussrechnung - Unterscheidung von zahlungswirksamen und nicht zahlungswirksamen Bilanzbewegungen

  • Direkter Finanzplan - separieren von Zahlungen innerhalb der Bilanzbewegungen

  • Unterscheidung der Spalten Abbau und Aufbau an Bilanzkonten

Detail beschreibt die Unterseite zu Bewegungsarten

Datenbankschema

Prinzip des indirekten Finanzplans

Der indirekte Finanzplan erklärt die Bank, zeigt aber viele Bewegungen welche die Bank überhaupt nicht betreffen → diesen Plan versteht nur der erfahrene Leser einer Bilanz - er zeigt eine Bilanzdifferenz.

Der indirekte Finanzplan erklärt die Bankveränderung einer Periode durch Auflistung der Bewegungen aller anderen Bilanzkonten.

  • GuV Ergebnis

  • - alle zahlungsunwirksamen GuV Erträge (Ertragskonten, GUV.NZW)

  • + alle zahlungsunwirksamen GuV Kosten (Auswandskonten, GUV.NZW)

  • +/- Veränderung aller Bilanzkonten (außer BANK, alle Bewegungen außer BIL.GUV.ZU.NZW, BIL.GUV.AB.NZW)

  • = Bewegung der Bank

Alles was aus der GuV IN die Bilanz fließt (Abschreibung, Zuschreibung….) gilt als zahlungsunwirksam, alles was aus der GuV direkt über die Bank läuft oder was DURCH die Bilanz läuft (Forderungen, Verbindlichkeiten, Umsatzsteuer...) gilt als zahlungswirksam. IN die Bilanz bedeutet es kommt aus der GuV und geht dann eigene Wege (Rückstellung → mal sehen, was mit der Zeit kommt → Bank oder Auflösung), DURCH die Bilanz bedeutet, der Weg ist von Anfang an vorgeplant und läuft meist genau so ab (Umsatz → Forderung → 30 Tage → Bank).

Prinzip des direkten Finanzplans

Der direkte Finanzplan zeigt sehr anschaulich alle Bewegungen der Bank, verbirgt aber viele Ursachen → diesen Plan versteht jeder, der sein Portmonnaie versteht (Geld rein, Geld raus)

Der direkte Finanzplan erklärt die Bankveränderung einer Periode durch Auflistung aller Bewegungen, welche tatsächlich stattfinden.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.