Aufbereitung debitorischer Kreditoren

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.

Weitere Bezeichnung für diese Thematik

• Wechselsammelkonten - Weil aus dem Sammelkonto Forderungen, einige Kundenkonten auf die andere Seite zu den Kreditoren müssen.

Manche unserer Kunden haben ein Guthaben, daher haben wir gegenüber Ihnen keine Forderung (wie üblich), sondern eine Verbindlichkeit

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

Behandlung debitorischer Kreditoren (vica versa)

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

• jedes Sammelkonto wird in zwei Sammelkonten aufgesplittet - jeweils in das Konto mit den Nebenbuchkonten mit Soll Saldo und denen mit Haben Saldo

Vorher

Nachher

Validierung

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

Lösungsmethode A - systemweite Lösung im Buchungsjournal

• Konzept

  • schon im Buchungsjournal werden die Sammelkonten entfernt und die Einzelkonten aufgenommen - das System verhält sich ab dann so, als hätte es Sammelkonten nie gegeben

• 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 Konten auch als Wechelkonto 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 ggf. sehr viel länger durch die vielen weiteren Konten

  • die Konten müssen in der Bilanz selbst gruppiert werden, um einen gruppierten Ausweis zu erhalten

Lösungsmethode B - 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

  • alle Buchungen im Buchungsjournal auf den Sammelkonten werden gelöscht

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

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

• Ergebnis

  • die Endsalden pro Konto stimmen und können importiert werden von Folgesystemen, 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 funktioneren nicht von den Sammelkonten, da das Buchungsjournal die neuen Sammelkonten nicht kennt

• Variante

  • die Bewegungen werden via Rückrechnung künstlich erzeugt und stimmen dann als Summenwert, erlauben aber weiterhin nicht den korrekten Drilldown