Rechnungswesen (REWE)

Fachliche Zielstellung

• Mehrmandentenfähige Abbildung von GuV und Bilanz mit Detailgliederung nach bis zu drei Kostenrechnungsdimensionen

• Auswertungen der Offenen Posten und der Anlagevermögensentwicklung

• Detailnachweis aller Werte bis zum Buchungsbeleg

• Zusammenführung verschiedener Buchhaltungssysteme und Abbildung nach einem einheitlichen Standard

• Umfangreiche Abbildung von Adjustmentprozessen

  • Mappings (z.B. Überleitung von lokalen Kontenrahmen auf Konzernkontenrahmen)

  • Gruppierungen (z.B. von Debitoren / Kreditoren)

  • Zuatzbuchungen

  • Auflösung von Sammelkonten zur seitengerechten Abbildung von debitorischen Kreditoren u.U.

Technische Zielstellung

• vollständig deutsche Datenbankmodell zur leichten fachlichen Verständlichkeit

• schnelle Erlernbarkeit für Datenmodellierer

• detailierte Validierungsmöglichkeit aller Aufbereitungsstufen

• Abbildung von Geschäftjahren mit 12 Perioden gemäß Managementperspektive, Perioden > 12 sind als Attribut verfügbar

• einfache Methodik der Überleitung Kalenderjahr / Finanzjahr

• Drei Kostenrechnungsdimensionen

• alle IDs sind auf NVARCHAR(50) limitiert, für bessere Indexabdeckung

• partitionierte Beladungsoptionen (nach Mandant, nach Monat, nach Bestandstyp)

• weitreichende Steuerungsoptionen für Ladeprozesse (fehlgeschlagene Mandanten nachladen, nur erfolgreich geladene Mandanten auf result Ebene überführen)

• Modellierungsfunktionalität für alle Dimensionen

Aufgaben der Datenebenen und ihrer Ladeprozesse

integration Schema - Datenspeicherung pro technischem Mandant

• Speicherung der Daten in einem generischen Format, unabhängig von der Datenstruktur des Vorsystem

• Speicherung beliebig vieler Vorsysteme mit jeweils beliebig vielen Instanzen in den gleichen Tabellen

Aufbereitungsprozess integration → result

• IC Partnerkennzeichen an Buchungen werden über Lookupregeln etc ermittelt

• Buchungen für Gewinnverwendung

• Buchungen für Bewegungswertkorrektur

• Technische Mandanten werden zu logischen Mandanten fusioniert

  • Überleitung früherer Kontenrahmen in aktuellen Kontenrahmen

  • Überleitung verschobener Geschäftsjahre in aktuelle Geschäftsjahreslogik

• Behandlung der debitorischer Kreditoren - Sammelkonten zu typgetrennten Sammelkonten expandieren

• Erzeugung eines JÜ Konto in der Bilanz - um das GuV Ergebnis in die Bilanzansicht zu übertragen (optional)

result Schema - Datenspeicherung pro logischem Mandant

• Speicherung der Daten in einem generischen Format, unabhängig von der Datenstruktur des Vorsystem und des Zielsystems

Wechsel des Kontenrahmens

• Grundstrategie: es erfolgt immer eine Überleitung der historischen Jahre auf den aktuellen Kontenrahmen

• in der integration Schicht werden technisch getrennte Mandanten geführt

• in der Tabelle für das Kontenmapping werden den historischen Kontonummern die neuen Kontonummern hinterlegt

• im result Prozess werden die technischen Mandanten fusioniert und die Kontennummern im Buchungsjournal ersetzt, die historischen MandantenIDs / KontenIDs werden in den CustomValuesJSON gesichert (ggf. müssen historisch bebuchte Konten noch in der Dimension dKonten des aktuellen Mandanten erzeugt werden, da ggf. der neue Mandanten noch nicht intensiv bebucht wurde)

Wechsel der Kontonummernlänge

• Grundstrategie: es erfolgt immer eine Überleitung der historischen Kontonummernlänge auf die aktuelle Kontonummernlänge, da in der Regel eine Verlängerung erfolgt

Wechsel des Geschäftsjahres

Leistungsgrenzen

• Geschäftsjahre müssen am 01. eines Monats beginnen (somit z.B. nicht am 11.11. wie beim früheren landwirtschaftlichen Geschäftsjahr, oder insolvenzbedingte Geschäftsjahreswechsel)

• noch keine Datenquellenübergreifende Mandantenfusion

• Modell orientiert sich an Managementperspektive mit 12 Perioden pro Jahr - andere Perioden sind als Attribut verfügbar, aber nicht Zielebene in Aggrgationsprozessen