Rechnungswesen (REWE)
Modul zur Abbildung des Rechnungswesens - vollständig in deutsch mit den Bereichen Finanzbuchhaltung, Kostenrechnung, offene Posten und Anlagevermögen.
Status: 03/2025: Produktivbetrieb bei BETA Kunden
Zugang
Alle Unterlagen zum Modul REWE werden in folgendem Repository verwaltet https://bitbucket.org/SX_Admin/modul_rechnungswesen_rewe/src/main/
Fachliche Zielstellung
Mehrmandentenfähige Abbildung von GuV und Bilanz mit Detailgliederung nach Kostenrechnungsebenen
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 Ladeprozess (fehlgeschlagene Mandanten nachladen, nur erfolgreich geladene Mandanten auf result Ebene überführen)
Modellierungsfunktionalität für alle Dimensionen
besitzt vordefinierte Funktionalität für die Überleitung bei
Kontenrahmenwechsel
Änderung der Kontennummernlänge
Geschäftsjahreswechsel
Aufgaben der Datenebenen und ihrer Ladeprozesse
staging Schema
in der Regel nur im Einsatz, falls kein Datenbankzugriff auf das Vorsystem möglich ist
originalgetreue Speicherung der Rohdaten des Vorsystems
Tabellen und Spaltennamen entsprechen weitgehend denen des Vorsystems, zur leichten Vergleichbarkeit mit dem Vorsystem
zwingende Anpassungen bei Exporteinschränkungen des Vorsystems (z.B. Auflösung Kontenverteilungsschlüssel in DATEV)
Sichten zur Validierung der Vorsystemdaten mit Pivotauswertungen in OCT oder Excel
Abbildung der technischen Intelligenz der partitionierten Beladung (Output auf CSV / parquet umleiten, Stagingpufferung in Cloud) bei hohen Performanceanforderungen
Aufbereitungsprozess staging → integration bzw. Vorsystemabfrage → integration
Mandantenmanagement
aus den Mandanten des Vorsystems werden die technischen Mandanten des Aufbereitungsprozesses erzeugt
falls Mandanten im Vorsystem jahresbezogen verwaltet werden (z.B. DATEV) werden bei Strukturbrüchen zwischen den Jahren (Kontorahmenwechsel) getrennte technische Mandanten erzeugt
Buchungskreismanagement
Aufbau passender Buchungskreise aus den Buchungskreisen des Vorsystems
ggf. Zusammenführung von Basisbuchungskreisen mit Differenzbuchungskreisen
Sammelkontenerkennung
Kennzeichung von Sachkonten, welche Sammelkonten sind
Zuordnung der Debitoren / Kreditoren zu ihren Sammelkonten
Umsetzung von Regeln
Filterung
Ersetzen von Werten
Kennzeichnen von Zeilen
integration Schema
Speicherung der Daten in einem generischen Format, unabhängig von der Datenstruktur des Vorsystem
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
result Schema
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