AddOn Sammelkontenauflösung

Problemstellung

• Kreditorische Debitoren sind Kunden, gegenüber denen man als Unternehmen nicht wie üblich eine Forderung hat, sondern eine Verbindlichkeit - das wird vor allem ausgelöst bei Warenrücksendung, Stornos, Gutschriften etc.

• Bei manchen Lieferanten haben wir ein Guthaben, daher haben wir gegenüber Ihnen keine Verbindlichkeit (wie üblich), sondern eine Forderung.

• Das sind Kunden / Lieferanten mit “negativem Vorzeichen” auf dem Personenkonto

• Werden diese Kunden / Lieferanten mit den anderen Kunden / Lieferanten in einem Sammelkonto saldiert, erscheint die Gesamtsumme der Forderungen / Verbindlichkeiten geringer, da die negative Werte die positiven reduzieren

• Die Forderungen / Verbindlichkeiten werden durch diese Saldierung in der Bilanz zu niedrig ausgewiesen → die Bilanzsumme stimmt nicht → viele Bilanzkennzahlen stimmen nicht

Zielstellung

• Die jeweils “falschen” Debitoren / Kreditoren werden in eigenen Sammelkonten zusammengefasst, welche auf die jeweils andere Bilanzseite zugeordnet werden. → Bilanzsumme stimmt → Bilanzkennzahlen stimmen

• Es erfolgt keine Veränderung der Originalbuchungen. Nur in der aggregierten Tabelle für die Bilanzdarstellung result.tREWE_fBuchungsaggregation_FiBu werden aggregierte Periodenwerte umgegliedert.

Funktionsvoraussetzung auf Konnektorebene

• Beim Import der Daten des Vorsystem in die Integration Schicht des REWE Modell wurden in der Tabelle integration.tREWE_Konten die Klassifizierung der Konten im Hinblick auf die Sammelkonteneigenschaften korrekt vorgenommen.

  • an Sammelkonten wurde hinterlegt, dass es ein Sammelkonto ist (Kennzeichen SKD und SKK)

  • an Debitoren / Kreditoren wurde hinterlegt, zu welchem Sammelkonto sie gehören

• Sollte der Konnektor diese Voraussetzungen nicht geschaffen haben, müssen diese durch einen custom UPDATE Step etc. innerhalb der Pipeline geschaffen werden.

Lösung: Duplizierung jedes Sammelkontos in die S/H Variante

• Konzept

  • Jedes Sammelkonto wird verdoppelt - in die Variante _S für alle Unterkonten mit Soll Saldo und die Variante _H für alle Unterkonten mit Haben Saldo.

  • Die Unterkonten wechseln von Periode zu Periode zwischen der _S und der _H Variante des Sammelkonto, passend zu ihrem jeweiligen Saldo.

  • Die Umsetzung erfolgt nur in der aggregieren Faktentabelle der FiBu, wo fertige Salden zur Unterscheidung vorliegen.

• Umsetzung

  • In der Dimension Konten werden alle Sammelkonten in die _S und _H Variante verdoppelt.

  • Alle Buchungen im Buchungsjournal auf den Sammelkonten werden gelöscht.

  • Die Umsetzung erfolgt im result Schema, da für die Behandlung die Salden pro Periode und Debitor / Kreditor benötigt werden.

  • Die aggregierten Buchungen auf den Unterkonten werden pro Periode, Sammelkonto und Sammelkonto aggregiert und neu in das Buchungsjournal auf dem _S und _H Konto eingefügt.

• Ergebnis

  • Die Endsalden pro Konto stimmen und können von Folgesystemen importiert werden, welche mit Endsaldoimport arbeiten.

  • Die Bewegungen auf den Konten stimmen in Summe, führen aber beim Import der reinen Bewegungswerte zu falschen Endsalden auf den Sammelkonten. Die Ausbuchung fehlt immer beim Seitenwechsel.

  • Drilldowns auf das Buchungsjournal funktionieren nicht von den Sammelkonten, da das Buchungsjournal die neuen Sammelkonten nicht kennt.

Vorher

Nachher

Installation

• Fügen Sie in der Pipeline REWELOAD am Ende zwei Steps “Wechselkontenerzeugung” und “Wechselkontenbuchung” vom Typ SQL Ausführung ein und kopieren Sie in diesen den gelieferten SQL Code des AddONs.

Anwendung

• Machen Sie sich mit den existierenden Sammelkonten und ihren Unterkonten in der Auswertung “Sammelkontenabgleich” in der REWE integration Validierung vertraut.

• Nach der Prozessausführung müssen Sie in der Kontrollansicht der Summen- und Saldenliste für jedes Sammelkonto mit “falschen” Nebenbuchkonten ein zweites Konto mit einem Präfix finden, welches die Wechselkandidaten aufnimmt. Das Sammelkonto muss einen anderen (höheren) Saldo aufweisen als im unkorrigierten Original.

• Die Summen- und Saldenliste mit angepassten Sammelkonten muss wie vorher auf null aufgehen.

Leitungsgrenzen

• Da nur Positionen in der aggregierten Tabelle für die Bilanzdarstellung result.tREWE_fBuchungsaggregation_FiBu erzeugt / geändert werden, sind diese in einer eventuell implementierten Drilldown Funktion auf result.tREWE_fBuchungsjournal nicht oder nicht vollständig verfügbar.

Deinstallation

• Löschen Sie die erstellten Steps zur Sammelkontenauflösung.

Alternative Lösungsmethode - Arbeit mit den Einzel-Personenkonten statt den Sammelkonten

• Konzept

  • Die Sammelkonten, welche die Summe einer Menge an Unterkonten zeigen, werden nicht verwendet, stattdessen die Unterkonten.

  • Das System verhält sich ab dann so, als würde es keine Sammelkonten geben.

• Umsetzung

  • Alle Buchungen im Buchungsjournal auf den Sammelkonten werden gelöscht.

  • Die Debitoren / Kreditorenkonten werden zum Typ Bilanz gemacht.

  • In der Bilanz werden die einzelnen Debitoren / Kreditorenkonten wie andere Bilanzkonten auch als Wechselkonto behandelt oder nicht

• Ergebnis

  • Alle Aggregationsvarianten arbeiten automatisch mit den Einzelkonten und zeigen keine Sammelkonten mehr.

  • In allen Bilanzarten (ggf. auch Bilanzen pro Kostendimension) sind die Einzelkonten ausgewiesen.

  • Alle Drilldowns zeigen korrekte Werte, da die Ursprungsdaten passend sind.

  • Alle Kontobewegungen bleiben korrekt - ein Folgesystem kann daher sowohl die Endsalden pro Konto oder die Bewegungen pro Konto importieren. Beides führt zum korrekten Ergebnis.

• Nebenwirkungen

  • Die Bilanz wird durch die vielen weiteren Konten ggf. sehr viel länger.

  • Die Konten müssen in der Bilanz gruppiert werden, um einen gruppierten Ausweis analog den Sammelkonten zu erhalten.

    • durch eine Zusatzkonfiguration in der OCT Modellierung

    • durch Zuordnung im Reportingwerkzeug (z.B. Corporate Planner)