Bereinigung von Kleinsalden – Ergänzung

06 Sonntag Mär 2016

Schlagwörter

Ausgleich, Dynamics AX, Kunden, Zahlungen

In einem vorherigen Beitrag habe ich Ihnen aufgezeigt wie Kleinsalden über die Einrichtung eines Debitorenpools und einer entsprechenden Filterung in der Inkassimaske ausgebucht werden können. Hier nochmals die zugehörigen Screenshots zur Erinnerung.

Problem
Was in dem vorherigen Beitrag nicht im Detail angesprochen wurde ist ein Problem, das immer dann zu Tage tritt, wenn negative Kleinsalden ausgebucht werden sollen. In diesen Fällen generiert Dynamics AX die folgende Fehlermeldung und unterbricht den Ausbuchungsvorgang.

Ursächlich für diese Fehlermeldung ist die Aktivierung des folgenden Debitorenparameters, welcher sicherstellt, dass bei der Ausbuchung der offenen Position eine entsprechende Steuerkorrektur durchgeführt wird (siehe den folgenden Screenshot).

Hinweis: Ist der Parameter „Separate Mehrwertsteuer“ nicht aktiviert, so wird die Fehlermeldung nicht generiert und die Abschreibung der offenen Posten kann gebucht werden. Eine Deaktivierung des Parameters ist allerdings keine Option, da eine Steuerkorrektur regelmäßig erforderlich ist.

Neben der aufgezeigten Problematik der Abschreibung negativer Debitorensalden tritt die oben erwähnte Fehlermeldung auch dann auf, wenn auf den ersten Blick alles in Ordnung erscheint. Beispiel:

In solchen Fällen liegt die Ursache für die Fehlermeldung zumeist in dem Umstand begründet, dass der Gesamtsaldo des Debitors einen negativen Betrag beinhaltet.

Lösungsmöglichkeit 1
Um die aufgezeigten Probleme zu beheben bestehen grundsätzlich zwei Möglichkeiten. Die erste Möglichkeit den Fehler zu vermeiden besteht darin, die in den folgenden beiden Screenshots aufgezeigten Codeanpassungen umzusetzen.

Im Ergebnis lässt sich nun zum einen der negative Debitorensaldo – einschließlich der zugehörigen Steuerkorrektur – ausbuchen.

Zum anderen können durch die Codeanpassung auch solche Kleinsalden ausgebucht werden, die Gutschriftspositionen beinhalten. Beispiel:

Hinweis: Wie man aus dem obenstehenden Screenshot erkennen kann, fasst Dynamics AX die zugehörigen Sachkontobuchungen zusammen und bucht diese nicht einzeln aus. Für den Fall dass die auszubuchenden Positionen mit unterschiedlichen Steuersätzen gebucht wurden, erfolgt eine entsprechende anteilige Steuerkorrektur entsprechenden verschiedenen Steuersätzen.

Lösungsmöglichkeit 2
Für den Fall dass keine Codeanpassung erwünscht ist bzw. für den Fall dass Sie mit älteren Dynamics AX Versionen arbeiten, in denen die Inkassifunktion noch nicht zur Verfügung steht, bietet sich die folgende alternative Vorgehensweise zur Ausbuchung von Kleinsalden an, auf die mich ein Kollege aufmerksam gemacht hat.

Schritt 1: Anlage eines neuen Debitoren Zahlungserfassungsjournals

Schritt 2: Erstellung eines Zahlungsvorschlags

Schritt 3: Filterung der auszubuchenden Kleinbeträge

Hinweise:
Die Selektion der auszubuchenden Beträge findet hier über ein SQL statement statt. Siehe hierzu auch die Hinweis auf der folgenden Seite.
Im Gegensatz zur weiter oben aufgezeigten Lösungsmöglichkeit 1 wird aufgrund der hier verwendeten Abfrage nicht auf den Gesamtsaldo des Debitors abgestellt, sondern auf Einzelbuchungen.

Schritt 4: Änderung der Zahlungsmethode
Um sicherstellen zu können dass die hier durchgeführten Ausbuchungen nicht gegen ein Zahlungs-(Bank-)Konto durchgeführt werden, empfiehlt sich die Einrichtung einer eigenen Zahlungsmethode mit einem entsprechend hinterlegten Abschreibungskonto (im Beispiel Konto 618170). Für die auszubuchenden Transaktionen ist demnach die Zahlungsmethode in der Zahlungsvorschlagsmaske entsprechend abzuändern, wie dies im folgenden Screenshot dargestellt ist.

Schritt 5: Auswahl Steuergruppen
Um sicherstellen zu können dass die entsprechenden Ausbuchungen auf den Debitorenkonten mit einer steuerlichen Wertkorrektur durchgeführt werden ist schließlich im letzten Schritt vor der Journalbuchung sicherzustellen, dass die entsprechenden Mehrwertsteuergruppen und Artikelmehrwertsteuergruppen hinterlegt werden.

Problemstellungen für Handelsunternehmen die das Projektmodul nutzen

01 Dienstag Mär 2016

Posted by Ludwig Reinhard in Projekt

≈ Hinterlasse einen Kommentar

Schlagwörter

Auftrag, Bestellung, Lagerbewertung, Projektmodul

Für Unternehmen die nicht primär im Projektumfeld agieren kann der Einsatz des Projektmoduls zahlreiche insbesondere auswertungstechnische Vorteile mit sich bringen. Diese Vorteile werden allerdings zum Preis einer höheren Komplexität speziell im Bereich der Lagerbewertung erkauft. Im Folgenden möchte ich Ihnen diese höhere Komplexität darstellen und ein paar Hinweise geben wie sie diese überwinden bzw. reduzieren können.

Ausgangspunkt für die folgenden Ausführungen sind Aufwandsprojekte (T&M-Projekte), die so eingestellt wurden dass alle Kosten auf Gewinn- und Verlustkonten (GuV) erfasst werden. Um die Unterschiede zu Aufwandsprojekten mit Bilanzbuchungen aufzuzeigen wurde zudem parallel eine zweite Projektgruppe mit Bilanzbuchungseinstellungen eingerichtet. Siehe hierzu auch den folgenden Screenshot.

Hinweis: Aus Vereinfachungsgründen wird nachfolgend das Projekt mit den Bilanz-Buchungseinstellungen als „WIP-Projekt“ und das Projekt mit den GuV-Buchungseinstellungen als „Nicht-WIP“ bzw. „gewöhnliches“ Projekt bezeichnet.

Zur Durchführung der verschiedenen Sachkontobuchungen wurden zudem die folgenden Sachkonten eingerichtet, die aus Vereinfachungsgründen gleichlaufend mit den Projektbuchungstypen angelegt wurden.

Vor dem Hintergrund dieser Einstellungen wurden zwei Aufwandsprojekte angelegt – eines mit und eines ohne WIP Buchungen – um einen gewöhnlichen Geschäftszyklus eines Handelsunternehmens angefangen von der Bestellung bis hin zur Kundenrechnung abzubilden. Die einzelnen Schritte dieses Zyklus werden im nachfolgend einzeln aufgezeigt.

Schritt 1: Anlage Bestellung
Mit der Anlage der Bestellung generiert Dynamics AX keinerlei Lager- oder Sachkontobuchung. In Abhängigkeit von den Projektmoduleinstellungen kann allerdings bereits zu diesem Zeitpunkt ein sog. Artikelbedarf generiert werden, der es erlaubt bereits zum Zeitpunkt der Bestellung einen Überblick über die demnächst auftretenden Kosten zu werfen.

Schritt 2: Buchung Bestell-Lieferschein
Der zweite Schritt im Geschäftszyklus besteht in der Buchung des Bestell-Lieferscheins. In meinem Beispielfall für 100 Stück eines Produkts zu einem Preis von 10 EUR / Stück.

Für das Aufwandsprojekt mit WIP-Buchungen werden hierbei die folgenden beiden Buchungsbelege generiert:

Zum einen der rot hervorgehobene Lieferscheinbeleg aus der Bestellung, welcher den gewöhnlichen Produktzugang abbildet und
Zum anderen der blau hervorgehobene Projektbuchungsbeleg, der den Lagerbestand unmittelbar reduziert und den zugehörigen Wert auf das WIP Konto (154600) umbucht.

Für das Aufwandsprojekt mit der gewöhnlichen GuV-Buchungseinstellung werden die folgenden beiden Belege generiert:

Zum einen der rot hervorgehobene Lieferscheinbeleg aus der Bestellung, welcher den gewöhnlichen Produktzugang abbildet und
Zum anderen der gelb hervorgehobene Projektbuchungsbeleg der – wie zuvor – den Lagerbestand unmittelbar reduziert und als Projektkosten auf dem Konto 540500 erfasst.

Der nächste Screenshot zeigt den Inhalt des Lagerwertberichts nach Durchführung der Bestell-Lieferscheinbuchung auf.

Hinweis: Der erste Artikel (“L13300”) wurde für das WIP Aufwandsprojekt verwendet und der zweite Artikel (“L13400”) für das gewöhnliche Aufwandsprojekt.

Was man dem Lagerwertbericht entnehmen kann ist zum einen die rot hervorgehobene Lagerzugangsbuchung aus der Bestell-Lieferscheinbuchung.
Gleichzeitig mit dieser Buchung wurden finanzielle Abgangsbuchungen aufgrund der Buchungen auf Projektebene erstellt, so dass sich insgesamt ein Lagerwert und eine Lagermenge von 0 ergibt.
Mit anderen Worten, trotz der Tatsache dass dem Kunden die vom Lieferanten angelieferten Teile weder verkauft, noch geliefert bzw. berechnet wurden kann man diesen Zugang über den Lagerwertbericht nicht mehr identifizieren, da die Teile bereits auf das Projekt „verbraucht“ wurden.

Schritt 3: Buchung Bestellrechnung
Im nächsten Schritt habe ich die Bestellrechnung gebucht. Hierbei wurde der folgende Buchungsbeleg sowohl für das gewöhnliche Aufwandsprojekt als auch das WIP-Projekt erstellt:

Im Anschluss an die Buchung der Bestellrechnung habe ich nochmals über den Lagerwertbericht versucht die Lagerbestände zu kontrollieren, musste allerdings feststellen, dass der Lagerwertbericht keinerlei Mengen und Werte ausweist.

Da der Lagerwertbericht keine Bestandsmengen und –werte ausweist stellt sich die Frage, wie diese bspw. Prüfern nachgewiesen werden können.

Eine Möglichkeit diesen Nachweis zu führen besteht darin den sog. Projekt-WIP-Bericht zu nutzen.

Dieser Bericht zeigt allerdings den Bestandswert der zugegangenen Teile lediglich für das WIP-Projekt, d.h. für das Aufwandsprojekt mit den Bilanzbuchungseinstellungen auf. Um auch für das gewöhnliche Aufwandsprojekt zumindest den Bestandswert ermitteln zu können habe ich darüber hinaus den folgenden Projektbericht aufgerufen, der einen Wechsel der Ansicht (GuV bzw. WIP) über die Auswahl im Projektaufstellungsfeld erlaubt.

Unabhängig hiervon kann an dieser Stelle bereits festgehalten werden dass beide Berichte lediglich das Wert-, nicht aber das Mengengerüst der am Lager befindlichen Teile abbilden können.

Schritt 4: Kundenrechnung über 30 Stück der gelieferten Teile
Der letzte Schritt im hier dargestellten Geschäftszyklus ist die Lieferungen und in Rechnungstellung von 30 Stück (a 100 EUR) des gelieferten Produkts an den Kunden.

Die Buchung der Kundenrechnung löst auf dem WIP Projekt die folgende Buchung aus:

Auf dem gewöhnlichen Aufwandsprojekt wird hingegen die folgende Buchung generiert.

Aufgrund des Verkaufs befinden sich im gewählten Beispielfall noch 70 Stück der Teile zu einem Einkaufspreis in Höhe von 700 EUR auf Lager. Der zuvor verwendete WIP Bericht weist diesen Wert für das WIP Projekt entsprechend aus.

Für das gewöhnliche Aufwandsprojekt existiert allerdings leider kein vergleichbarer Bericht so dass dieser individuell z.B. für Jahresabschlusszwecke entwickelt werden muss.

Zusammenfassung:
Trotz der unzweifelhaft bestehenden auswertungstechnischen Vorteile die sich aus der Nutzung des Projektmoduls auch für Handelsunternehmen ergeben können gilt es die in diesem Beitrag aufgeführten Probleme im Hinblick auf die Lagerbewertung zu berücksichtigen. Nach Meinung des Verfassers erscheinen Projekte mit Bilanzbuchungseinstellungen („WIP Projekte“) aus bewertungstechnischer Sicht prinzipiell besser geeignet als Projekte mit GuV-Buchungseinstellungen. Unabhängig hiervon kann man allerdings davon ausgehen, dass Prüfer mit hoher Wahrscheinlichkeit einen speziell angepassten Bericht für die auf Projekten befindlichen Artikel verlangen werden der individuell zu entwickeln ist. Dieser (Kosten-) Nachteil ist den Vorteilen aus den zusätzlichen Auswertungsmöglichkeiten im Projektmodul grundsätzlich gegenüberzustellen bevor eine Entscheidung darüber getroffen werden kann ob und in welchem Umfang das Projektmodul auch im Handelsbereich Einsatz findet.

Indirekte Projektkosten

20 Samstag Feb 2016

Posted by Ludwig Reinhard in Projekt

≈ Hinterlasse einen Kommentar

Schlagwörter

Finanzberichte, indirekte Kosten, Projektmanagement

Im vorherigen Beitrag habe ich Ihnen aufgezeigt welchen Effekt die Nutzung der sog. effektiven Arbeitsrate auf die Projektkosten und den Ausweis selbiger in der Gewinn- und Verlustrechnung (GuV) haben kann. In diesem Beitrag möchte ich das Augenmerk auf eine weitere Projektfunktion richten – indirekte Kosten – die ähnliche finanztechnische Effekte hervorrufen kann.

Da die Einrichtung und Nutzung von indirekten Kosten bereits auf zahlreichen Internet-/Blog-Seiten beschreiben ist (siehe z.B. Blog-Link) möchte ich an dieser Stelle nicht weiter auf die grundlegende Einrichtung eingehen, sondern den Blick vielmehr auf die Finanz- und Controlling-Seite legen. Für diesen Zweck wurden die folgenden indirekten Kostensätze eingerichtet:

Diese Kostensätze definieren, dass für jede gebuchte Projektstunde zusätzlich 5 EUR an indirekten Kosten, 6 EUR an Erlösabgrenzung bzw. 7 EUR an den Kunden berechnet bzw. gebucht werden.

Um Ihnen den Effekt der unterschiedlichen indirekten Kostenraten aufzuzeigen, wurde für die folgenden Darstellungen ein Aufwandsprojekt mit Erlösantizipation verwendet.

Auf dieses Projekt wurden im ersten Schritt 20 Stunden (mit einem Projektstundensatz von 50 EUR/Stunde) an Projektzeiten gebucht. Das Ergebnis dieser Buchung kann im folgenden Screenshot betrachtet werden:

Was Sie dem obenstehenden Screenshot entnehmen können, sind zum einen die Projektkosten in Höhe von 1000 EUR (20 Stunden * 50 EUR/Stunde), sowie die hiermit gleichzeitig gebuchten indirekten Kosten in Höhe von 100 EUR (20 Stunden * 5 EUR/Stunde).
Daneben kann über die hellblau hervorgehobenen Buchungszeilen die zusätzlich generierte Erlösabgrenzung in Höhe von 120 EUR (20 Stunden * 6 EUR/Stunde) identifiziert werden.
Schließlich kann man den rot hervorgehobenen Zeilen entnehmen, dass der Kunde 140 EUR für die gebuchten indirekten Kosten zusätzlich in Rechnung gestellt bekommt.

Betrachtet man sich die Rechnungsbuchung, so erkennt man diesen zusätzlich berechneten Betrag sehr einfach, da er auf das gleiche Erlöskonto gebucht wird wie die gewöhnlichen Projektumsatzerlöse (im folgenden Screenshot rot hervorgehoben).

(Hinweis: die ersten vier Buchungszeilen stellen die Umkehrung der bei der Stundenbuchung vorgenommenen Erlösabgrenzung dar).

Der nächste Screenshot fasst nochmals alle gebuchten Transaktionen zusammen und beinhaltet darüber hinaus eine Buchung über 4000 EUR, welche die Lohn- und Gehaltszahlung des Mitarbeiters repräsentiert. Diese letzte Buchungszeile wird für die folgende Darstellung bzw. Vergleich in der Gewinn- und Verlustrechnung (GuV) benötigt.

Die erfassten Beispieldaten sind in der folgenden GuV Darstellung in der ersten Spalte enthalten. Dieser kann man entnehmen, dass neben Umsatzerlösen in Höhe von 2140 EUR (2000 EUR + 140 EUR indirekte Kostenbelastung), Umsatzkosten in Höhe von 1100 EUR (1000 EUR + 100 EUR indirekte Kosten) entstanden sind, was zu einem Rohertrag in Höhe von 1040 EUR bzw. 48,6% führt.

In der zweiten Spalte wird davon ausgegangen, dass Projektkunden die zusätzliche indirekte Rechnungsrate von 140 EUR nicht zahlen und stattdessen nur von der indirekten Kostenrate Gebrauch gemacht wird. Aufgrund dessen ergibt sich erwartungsgemäß eine geringere Rohertragsmarge in Höhe von 45%.
Die letzte Spalte stellt schließlich eine Situation gegenüber in der von den indirekten Projektkosten kein Gebrauch gemacht wird. Auch hier ergibt sich aufgrund dessen eine andere Rohertragsmarge in Höhe von 50%.

Basierend auf diesem Vergleich kann man schlussfolgern, dass der Einsatz der indirekten Projektkostenfunktion einen Einfluss auf den Ergebnisausweis in der Gewinn- und Verlustrechnung ausüben kann und einen gewissen Spielraum für „Bilanzpolitik“ einräumt.

Ein zweiter Gesichtspunkt auf den ich an dieser Stelle eingehen möchte bezieht sich auf die Kosten, die über die indirekte Kostenfunktion auf Projekte verteilt werden können.
In diesem Zusammenhang führt IAS 11 aus, dass lediglich solche indirekten Kosten die im unmittelbaren Zusammenhang mit einem Projekt stehen auf Projekte verteilt werden dürfen. Allgemeine Kosten der Verwaltung, Vertriebskosten, F&E Kosten, usw. dürfen hingegen nicht auf Projekte umgelegt (verteilt) werden. Da viele nationale Standardsetter ähnliche Vorschriften beinhalten kann man davon ausgehen, dass regelmäßig nur direkt im Zusammenhang mit Projekten stehende Kosten auf diese verteilt werden können.

Diese allgemeine Buchhaltungsvorschrift ist für die Anwendung der indirekten Kostenfunktion im Dynamics AX Projektmodul insofern problematisch als dass die meisten direkt zurechenbaren indirekten Kosten (wie z.B. Abschreibungen für im Projekt eingesetzte Anlagen & Maschinen) in keinem unmittelbarem Zusammenhang zu den Produktstundenbuchungen stehen. Die Problematik besteht an dieser Stelle darin, dass die indirekte Kostenfunktion lediglich für Projektstundenbuchungen zur Verfügung steht.

Man könnte nun zwar versuchen alle indirekten Projektkosten über einen allgemeinen indirekten Produktstundensatz abzubilden. Fraglich hierbei ist allerdings ob Prüfer einen solchen „Pauschalsatz“ anerkennen würden, da er nicht dem Verursachungsprinzip entspricht.

Zusammengefasst lässt sich somit an dieser Stelle festhalten, dass sich zwar über den Einsatz der indirekten Kostenfunktionalität im Projektmodul in einem gewissen Maße Bilanzpolitik betreiben lässt, dass der allgemeine Einsatz dieser Funktion allerdings entscheidend davon abhängt ob Prüfer bzw. nationale Rechnungslegungsbehörden diesen akzeptieren oder nicht.