Rechnungswesen (REWE)

Status: Produktivbetrieb bei BETA Kunden

Alle Unterlagen zum Modul REWE werden in folgendem Repository verwaltet https://bitbucket.org/SX_Admin/modul_rechnungswesen_rewe/src/main/

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

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 zu 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

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)

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

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