Rechnungswesen (REWE)

Schlankes Modul zur Abbildung des Rechnungswesens - vollständig in deutsch mit den Bereichen Finanzbuchhaltung, Kostenrechnung, offene Posten und Anlagevermögen.

Status: 01/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/

Leistungsumfang

• Finanzbuchhaltung

• Kostenstellenrechnung

• Kostenrechnung (weitere Buchungskreise)

• Offene Posten

• Anlagevermögen

• Import nach CP in Variante FiBu und KoRe

• Drilldown aus CP

Zielstellung

• Kompaktes Modell für die Abbildung des Rechnungswesens

• vollständig in deutscher Sprache

• möglichst leichte Verständlichkeit und schnelle Erlernbarkeit

• umfasst Buchhaltung / Kostenrechnung / offene Posten und Anlagevermögen

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

• Drei Kostenrechnungsdimensionen

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

• einfache Methodik der Überleitung Kalenderjahr / Finanzjahr

• ausgelegt auf monatsweise inkrementelle Beladung

• nutzt nicht die OCT Mandantenverwaltung, sondern erstellt eigene Steuerungstabellen

• bietet Modellierungsfunktionalität für GuV / Bilanz

• 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

Aufbereitungsprozess staging → integration bzw. Vorsystemabfrage → integration

• Aufbau passender generischer Buchungskreise aus den Buchungskreisen des Vorsystems, ggf. Zusammenführung von Basisbuchungskreisen mit Differenzbuchungskreisen

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

• Technische Mandanten werden zu logischen Mandanten fusioniert

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