• Home
  • Über mich
  • Kontakt
  • Englisch
  • FAQs

Microsoft BizApps Finance & Controlling

Microsoft BizApps Finance & Controlling

Schlagwort-Archiv: Lagerbewertung

Parallele Lagerbewertung – ein alternativer Ansatz (Teil 1)

05 Sonntag Mär 2017

Posted by Ludwig Reinhard in Hauptbuch, Lager

≈ Hinterlasse einen Kommentar

Schlagwörter

Einkaufspreisabweichung, Lager, Lagerbewertung, Standardkosten

In einem früheren Beitrag wurde die Problemstellung einer parallelen Lagerbewertung nach unterschiedlichen Bewertungsprinzipien bereits im Detail aufgezeigt.

Während im vorherigen Beitrag im speziellen die russische sog. dual warehouse Funktion im Vordergrund stand und im Detail betrachtet wurde, soll im Rahmen dieses Beitrag ein alternativer Bewertungsansatz vorgestellt werden, der nicht auf landesspezifische Funktionen abstellt, sondern auf allgemein im Standard von Dynamics AX/365 for Operations Funktionen aufbaut.

 

Ausgangssituation:
Der nachfolgend vorgestellte alternative Bewertungsansatz basiert auf der Annahme, dass ein Unternehmen, welches seine Lagerbestände zu Standardkosten bewertet eine auf aktuellen Kosten basierende Lagerbewertung für externe Berichtszwecke benötigt.

Aus Gründen der einfacheren Nachvollziehbarkeit wird der vorgestellte alternative Bewertungsansatz basierend auf den folgenden Beispielbuchungen für einen Handelsartikel dargestellt.

203_0015
(DOM = Day Of the Month)

Die erste Transaktion in der obenstehenden Darstellung repräsentiert eine Bestellung über 50 Stück des Artikels, der zu einem Preis von $110 eingekauft wird. Aufgrund der hinterlegten Standardkosten in Höhe von $100/Stück, ergibt sich aus dieser ersten Bestelltransaktion eine Einkaufspreisabweichung (Purchase Price Variance, PPV) in Höhe von $500.

Die zweite Transaktion stellt ebenfalls eine Bestellung über weitere 150 Stück des Artikels dar, die zu einem Preis von $95 eingekauft werden. Der wesentliche Unterschied zur ersten Bestelltransaktion besteht darin, dass für diese Zweite lediglich der Bestell-Lieferschein, nicht aber die Bestell-Rechnung gebucht wird.

Die dritte und vierte Beispieltransaktion umfassen Lagerkorrekturbuchungen, die zu keinerlei Einkaufspreisabweichung führen.

Im Anschluss an die beiden internen Lagerkorrekturbuchungen wurde erneut eine Bestellung über 250 Stück des Artikels zu einem Preis in Höhe von $105 erfasst, die in ihrer Gesamtheit zu einer Einkaufspreisabweichung in Höhe von $1250 führte.

Nach all den Zugangs- und internen Lagerkorrekturbuchungen wurden schließlich 50 Stück des Artikels verkauft. Aufgrund des hinterlegten Standardkostenpreises von $100/Stück wurde der Lagerwert entsprechend um $5000 reduziert.

Die folgende Übersicht fasst die sich aus den Beispieltransaktionen ergebenden Bilanz- und GuV-Darstellungen zusammen.

203_0020

Aus der obenstehenden Übersicht kann zum einen ein zu Standardkosten bewerteter Lagerbestand in Höhe von $45000, sowie zum anderen eine Einkaufspreisabweichung (PPV) in Höhe von $1000 entnommen werden.

 

Nach der Darstellung dieser Finanzwerte ging ich zunächst daran einmal manuell einen theoretischen auf aktuellen Kosten basierenden Lagerbestandswert zu errechnen, um hierdurch einen Anhaltspunkt bzw. ein Gefühl für den ‚korrekten‘ Lagerwert zu erhalten.

Um dies zu realisieren wurde in einem ersten Schritt – ähnlich wie dies Dynamics AX/365 for Operations macht – vor jeder Abgangsbuchung ein durchschnittlicher Lagerwert bzw. Preis berechnet, mit dem im Anschluss die Abgangsbuchungen bewertet wurden. Die nachfolgende Übersicht stellt diese ‚Rechenübung‘ exemplarisch dar.

203_0025

warningsign1 Zu beachten ist bei dieser manuellen Berechnung, dass sich je nach gewählter Durchschnittsberechnungsmethode ein anderer theoretischer Lagerwert ergibt. Wird die Durchschnittspreisberechnung bspw. derart durchgeführt, dass ein einziger Durchschnittspreis für alle Abgangsbuchungen verwendet wird, so ergibt sich ein Lagerwert in Höhe von $45849.06.

 

Diese Unterschiede sind für die nachfolgenden Darstellungen allerdings nur von sekundärer Bedeutung. Von primärer Bedeutung ist hingegen die Erkenntnis, dass die zu Standardkosten bewerteten Abgangswerte einer Anpassung bedürfen.

 

Wie eine solche Anpassung umgesetzt werden kann ist in der folgenden Übersicht dargestellt, die davon ausgeht, dass die gesamte Einkaufspreisabweichung (PPV) in zwei Teile aufgespalten werden kann. Zum einen in einen Teil, der den Lagerzugängen (receipts) zugeordnet werden kann und zum anderen in einen Teil, der den Lagerabgängen (issues) zugeordnet werden kann.

203_0030

Der in der obenstehenden Darstellung aufgezeigte Betrag in Höhe von $868.85, welcher den Zugangsbuchungen (receipts) zugeordnet wurde, kann über eine einfache Dreisatzrechnung ermittelt werden ($868.85 = $1000/($53000+$8000) * $53000).

warningsign1 Im Rahmen dieser Berechnung ist zu beachten, dass sich ein geringfügig anderes Ergebnis einstellt, wenn die internen Zu- und Abgangsbuchungen – die zu keiner Einkaufspreisabweichung führten – aus der Berechnung herausgelassen werden. Die folgende Grafik zeigt die sich alternativ ergebenden anteiligen Einkaufspreisabweichungsbestandteile auf.

203_0035

Ausgehend von der zuletzt aufgezeigten Aufspaltung der Einkaufspreisabweichung kann ein auf aktuellen Kosten basierender Lagerwert durch die Zuordnung des auf die Zugänge entfallenden Anteils der Einkaufspreisabweichung ermittelt werden. Diese Zuordnung und der sich insgesamt ergebende Lagerwert sind in der nachfolgenden Übersicht zusammenfassend dargestellt.

203_0040

 

Nachdem von theoretischer Seite die Ableitung eines auf aktuellen Kosten basierenden Lagerwertes dargestellt wurde, stellt sich nun die Frage, wie dieser Bewertungsansatz in Dynamics AX/365 for Operations umgesetzt werden kann.

Diese Frage lässt sich dergestalt beantworten, dass hierfür die im Hauptbuch verfügbaren Allokationsregeln verwendet werden können.

Der folgende Screenshot zeigt die im Rahmen dieses Beitrags verwendete Allokationsregel auf, die von der sog. ‚basis‘ Allokationsmethode Gebrauch macht.

203_0045

Das Einkaufspreisabweichungskonto (Nr. 540400) wurde im Rahmen der Einrichtung der Allokationsregel in der Quellmaske hinterlegt.

203_0050

warningsign1 An dieser Stelle ist zu beachten, dass die Hinterlegung des Einkaufspreisabweichungskontos 540400 im Zusammenhang mit der Finanzdimension ‘itemgroup’ (Artikelgruppe) erfolgte. Diese Einrichtung führt streng genommen nicht zu einer Einzelbewertung des Artikels, sondern zu einer vereinfachten Gruppenbewertung gleichnamiger ‚trade‘ bzw. Handelsartikel. Aus Sicht des Verfassers lässt sich diese Vereinfachung allerdings mit den geltenden Rechnungslegungs- und Steuervorschriften vereinbaren. Darüber hinaus ist zu beachten, dass Finanzberichte an externe Adressaten regelmäßig nicht einen Einzelausweis aller bestandsgeführten Artikel vorsehen, sondern diese nach unterschiedlichen Gruppen zusammenfassen.

 

Um die Einrichtung der Allokationsregel fortzusetzen ist des Weiteren die Hinterlegung eines Verteilungskontos für die Einkaufspreisabweichung erforderlich. Bei dieser Hinterlegung ist darauf zu achten, dass nicht das originäre Einkaufspreisabweichungskonto hinterlegt wird.

203_0055

 

Im letzten Einrichtungsschritt, sind schließlich die sog. Zielbeziehungen zu definieren, die im Beispielfall so vorgenommen wurden, dass eine verhältnismäßige Aufteilung der gesamten Einkaufspreisabweichung entsprechend den durchgeführten Zu- und Abgangsbuchungen erfolgte. Die beiden folgenden Screenshots fassen die hierfür vorgenommenen Einstellungen nochmals zusammen.

203_0060 203_0065

Im Rahmen des letzten Einrichtungsschrittes ist zu beachten, dass der den Zugängen zugeordnete Teil der Einkaufspreisabweichung auf ein Bilanzkonto (Nr. 140499) gebucht wird. Der den Abgängen zugeordnete Teil der Einkaufspreisabweichung verbleibt hingegen in der GuV – im Beispiel auf dem Konto 540401.

Wird die derart eingerichtete Allokationsregel schließlich aktiviert und verarbeitet, so erstellt Dynamics AX/365 for Operations ein Allokationsjournal mit folgendem Inhalt:

203_0070

Die folgende Finanzdarstellung stellt die sich aus der durchgeführten Allokationsbuchung resultierenden Bilanz- und GuV-Darstellungen nochmals zusammenfassend dar.

203_0075

 

Beurteilung:
Der im Rahmen dieses Beitrags vorgestellte parallele Bewertungsansatz setzt voraus, dass alle Artikel mit einer Finanzdimension für die dem Artikel zugeordnete Artikelgruppe bzw. Artikelnummer eingerichtet wurden. Darüber hinaus ist es erforderlich unterschiedliche Sachkonten für die Zugangs- und Abgangskonten zu verwenden.

Abgesehen von diesen Einrichtungsgesichtspunkten ergeben sich aus der Anwendung der dargestellten Bewertungsmethode die folgenden Nachteile:

  1. Zum einen, dass der zu aktuellen Kosten bewertete Lagerbestand lediglich im Hauptbuch identifiziert werden kann und
  2. Zum anderen, dass der hier dargestellte Bewertungsansatz die Nutzung von Standardkosten voraussetzt.

Trotz dieser Nachteile erscheint der hier dargestellte Ansatz besser geeignet zu sein als alternative Vorgehensweisen denen der Verfasser im Laufe der Vergangenheit begegnet ist, wie z.B. die Entwicklung gesonderter de facto nicht nachvollziehbarer Lagerberichtsauswertungen, die als Grundlage für die Durchführung von Anpassungsbuchungen im Hauptbuch verwendet werden oder die Durchführung ‚kreativer‘ Excelberechnungen, um einen wie auch immer gearteten auf aktuellen Kosten basierenden Lagerwert zu ermitteln. Darüber hinaus ist zu beachten, dass n.M. des Verfassers der hier dargestellte Ansatz mit den sog. ‚specific identification‘, d.h. den Einzel- bzw. Gruppen-Bewertungsvorschriften von IFRS und US-GAAP im Einklang steht.

Im Rahmen des der nächsten Beiträge wird der hier vorgestellte Bewertungsansatz für weitere Standardkostenabweichungsarten dargestellt.

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.
DE_83_0005
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.
DE_83_0010

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.
DE_83_0015

 

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. DE_83_0020

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. DE_83_0025

Der nächste Screenshot zeigt den Inhalt des Lagerwertberichts nach Durchführung der Bestell-Lieferscheinbuchung auf.
DE_83_0030
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:
DE_83_0035
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.
DE_83_0040
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.
DE_83_0045
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.
DE_83_0050
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:
DE_83_0055

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

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.
DE_83_0065
Für das gewöhnliche Aufwandsprojekt existiert allerdings leider kein vergleichbarer Bericht so dass dieser individuell z.B. für Jahresabschlusszwecke entwickelt werden muss.
DE_83_0070

 

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.

Parallele Lagerbewertung

09 Mittwoch Dez 2015

Posted by Ludwig Reinhard in Lager

≈ Ein Kommentar

Schlagwörter

Dual warehouse, Lagerbewertung, Lagersteuerungsgruppe

Vielleicht hat der eine oder andere von ihnen bereits einmal der Anforderung begegnet die Lagerbestände nach mehr als einem Verbrauchsfolgeverfahren bewerten zu müssen z.B. weil Steuerprüfer danach verlangen. Die Möglichkeit der parallelen Bewertung von Lagerbeständen besteht bereits seit einiger Zeit in Dynamics AX über die sog. Dual Warehouse Funktion. Siehe hierzu beispielhaft auch den folgenden Screenshot, der eine Lagersteuerungsgruppe aufzeigt, die eine gleichzeitige Bewertung nach FIFO und LIFO erlaubt.
DE_70_0005

Sucht man im Internet nach der Dynamics AX Dual Warehouse Funktion so findet man nur einige wenige Informationen (siehe z.B. die folgende Webseite, so dass einem regelmäßig nichts anderes übrig bleibt als die Funktion auszutesten.

Um die Dual Warehouse Funktion auszutesten ging ich zunächst davon aus, dass man über die Aktivierung des entsprechenden Konfigurationsschlüssels die Funktion generell bereitstellen kann.
DE_70_0010

Leider war dies zu kurz gedacht und auch nach der Synchronisation und Kompilierung meiner Test-Datenbank bestand keine Möglichkeit ein zweites Lagermodell in der Lagersteuerungsgruppenmaske einrichten zu können.

Mein nächster Versucht bestand darin im AOT nach dem Begriff „dual warehousing“ zu suchen. Bei dieser Suche stieß ich auf das folgende Projekt.
DE_70_0015

Über die Suche nach Länderschlüsseln in diesem Projekt habe ich nun versucht die Dual Warehouse Funktion allgemein verfügbar zu machen.
DE_70_0020

Die Erweiterung der entsprechenden Konfiguration im Programmcode war etwas aufwendig, brachte allerdings auch nicht den erhofften Erfolg; im Gegenteil, nach der Erweiterung des Programmcodes dieses Projekts funktionierten einige Standardfunktionen nicht mehr ordnungsgemäß.

Aufgrund dessen setzte ich die Anpassung aller zugehörigen Tabellen, Klassen, usw. fort bis die Dual Warehouse Funktion schließlich auch in meiner deutschen Test-Firma bereitstand. Nach der Bereitstellung dieser Funktion ging ich daran die Funktion anhand der folgenden Testtransaktionen zu prüfen.
DE_70_0025

Nach der Erfassung aller Testbuchungen konnte ich in der „Am Lager“ Maske den folgenden laufenden Durchschnittspreis erkennen, der mit meinen Berechnungen soweit übereinstimmte.
DE_70_0030

Von diesen Daten ausgehend habe ich anschließend das Lager zweimal reguliert; zunächst mit Hilfe der Standard „Abschluss und Regulierungsfunktion“ und anschließend über die „Close and adjustment in currency“ Funktion.
DE_70_0035

Im Ergebnis konnte man anschließend die folgenden beiden Anpassungsbeträge bei der erfassten Verkaufsbuchung erkennen.
DE_70_0040

Der gewöhnliche Lagerwertbericht zeigte wie erwartet den FIFO-Wert entsprechend dem ersten eingerichteten Wertmodell.
DE_70_0045

Da es keinen eigenen Lagerwertbericht für die Duale Warehouse Funktion gibt konnte kein vergleichbarer Bericht für die LIFO-Bewertung erstellt werden, da ein solcher Bericht erst entwickelt werden muss.

Zusammenfassung & Evaluierung
Die Möglichkeit einer parallelen Lagerbewertung ist sehr interessant speziell in Fällen wo bspw. Steuerbehörden nach einer zweiten alternativen Lagerbewertung verlangen.

Selbst wenn eine solche Anforderung nicht besteht kann der Einsatz der Dual Warehouse Funktion hilfreich sein, da hierüber eine Bestandsbewertung in einer zweiten Währung möglich ist, die es bspw. erlaubt die Effektivität von eingesetzten Währungssicherungsinstrumenten im Warenbereich zu beurteilen.

Trotz dieser potentiellen Vorteile gilt es allerdings folgendes zu beachten:

  • Die Dual Warehouse Funktion erlaubt lediglich den Einsatz einer zusätzlichen Lagerbewertungsmethode,
  • Ein eigener Dual Warehouse Lagerwertbericht ist nicht vorhanden und muss erst entwickelt werden,
  • Wenn die Berichts- und Buchhaltungswährung voneinander abweichen ist eine parallele Bestandsbewertung praktisch nicht möglich da Währungseffekte immer zu einer Verzerrung der ausgewiesenen Werte führen,
  • Die größte Problematik besteht allerdings im sog. „development footprint“ welche die Dual Warehouse Funktion in einem System hinterlässt. Der nächste Screenshot zeigt einige (!) der Tabellen und Klassen auf, die von der Bereitstellung dieser Funktion beeinflusst werden. DE_70_0050

Aus diesem Auszug kann man bereits erkennen dass die Dual Warehouse Funktion praktisch das gesamte System und somit auch die Möglichkeit späterer Upgrades erheblich beeinflusst.

Darüber hinaus gilt es zu beachten, dass vor der Bereitstellung der Dual Warehouse Funktion eine detaillierte Codeanalyse und Codeanpassung erforderlich ist. Andernfalls erhält man ein System mit vielen zusätzlichen Funktionen, Einstellfenstern, usw. die man ohne weitere Recherche gar nicht einrichten kann.

Aufgrund der letztgemachten Anmerkungen erscheinen mir die Risiken und potentiellen Probleme der Dual Warehouse Funktion im Vergleich zu den erwünschten Vorteilen zu groß speziell wenn man eigentlich nur an einem zweiten Lagerwertbericht interessiert ist, der die Bestände nach einem anderen Verbrauchsfolgeverfahren bewertet. Im letzten Fall erscheint eine einfache Berichtsentwicklung basierend auf math. statistischen Verfahren deutlich einfacher umsetzbar als der Einsatz der Dual Warehouse Funktion.

← Ältere Beiträge
Neuere Beiträge →

Microsoft BizApps Deutschland Podcast

Meetup Dynamics Deutschland

Kategorien

  • Anlagen
  • Bank
  • Buchrezension
  • Budgetierung
  • Debitoren
  • Hauptbuch
  • Kostenrechnung
  • Kreditoren
  • Lager
  • Management Reporter
  • Nachhaltigkeit
  • Podcast
  • PowerPlatform
  • Projekt
  • Sonstiges
  • Uncategorized

Tags

Artificial Intelligence Budgetierung Controlling Copilot Studio D365 D365FO Dynamics 365 Dynamics AX Dynamics AX 2012 Electronic Reporting Email Finanzberichte Flow Genehmigung Globale Erwaermung Intercompany IOT Kontoauszugsverarbeitung Kostenrechnung Kostenstellenrechnung Kreditorenzahlungen Kuenstliche Intelligenz Lager Lagerabstimmung Lagerbewertung Management Reporter Modern Finance MS Flow MT940 Nachhaltigkeit Neues Kostenrechnungsmodul PowerApps PowerAutomate PowerPlatform Projekt Projektmodul Rechnung Rechnungserfassung RPA SharePoint Steuer Sustainability Sustainability Accounting Sustainability Manager time&attendance Umlagen Umwelt WBS Workflow Zeiterfassung

Wichtige Webseiten

  • Dynamics AX Links

Rechtliches

  • Impressum

Abbonieren

  • RSS - Beiträge
  • RSS - Kommentare

Klicken Sie hier um diesem Blog zu folgen und automatische Emails bei der Veröffentlichung neuer Beiträge zu erhalten.

Archiv

  • März 2024
  • Februar 2024
  • Januar 2024
  • Dezember 2023
  • November 2023
  • Oktober 2023
  • September 2023
  • August 2023
  • Juli 2023
  • Juni 2023
  • Mai 2023
  • April 2023
  • März 2023
  • Februar 2023
  • Januar 2023
  • Dezember 2022
  • November 2022
  • Oktober 2022
  • September 2022
  • August 2022
  • Juli 2022
  • Juni 2022
  • Mai 2022
  • April 2022
  • März 2022
  • Februar 2022
  • Januar 2022
  • Dezember 2021
  • November 2021
  • Oktober 2021
  • September 2021
  • August 2021
  • Juli 2021
  • Juni 2021
  • Mai 2021
  • April 2021
  • März 2021
  • Februar 2021
  • Januar 2021
  • Dezember 2020
  • November 2020
  • Oktober 2020
  • September 2020
  • August 2020
  • Juli 2020
  • Juni 2020
  • Mai 2020
  • April 2020
  • März 2020
  • Februar 2020
  • Januar 2020
  • Dezember 2019
  • November 2019
  • Oktober 2019
  • September 2019
  • August 2019
  • Juli 2019
  • Juni 2019
  • Mai 2019
  • April 2019
  • März 2019
  • Februar 2019
  • Januar 2019
  • Dezember 2018
  • November 2018
  • Oktober 2018
  • September 2018
  • August 2018
  • Juli 2018
  • Juni 2018
  • Mai 2018
  • April 2018
  • März 2018
  • Februar 2018
  • Januar 2018
  • Dezember 2017
  • November 2017
  • Oktober 2017
  • September 2017
  • August 2017
  • Juli 2017
  • Juni 2017
  • Mai 2017
  • April 2017
  • März 2017
  • Februar 2017
  • Januar 2017
  • Dezember 2016
  • November 2016
  • Oktober 2016
  • September 2016
  • August 2016
  • Juli 2016
  • Juni 2016
  • Mai 2016
  • April 2016
  • März 2016
  • Februar 2016
  • Januar 2016
  • Dezember 2015
  • November 2015
  • Oktober 2015
  • September 2015
  • August 2015
  • Juli 2015
  • Juni 2015
  • Mai 2015
  • April 2015
  • März 2015
  • Februar 2015

Bloggen auf WordPress.com.

  • Abonnieren Abonniert
    • Microsoft BizApps Finance & Controlling
    • Schließe dich 121 anderen Abonnenten an
    • Du hast bereits ein WordPress.com-Konto? Melde dich jetzt an.
    • Microsoft BizApps Finance & Controlling
    • Abonnieren Abonniert
    • Registrieren
    • Anmelden
    • Melde diesen Inhalt
    • Website im Reader anzeigen
    • Abonnements verwalten
    • Diese Leiste einklappen
 

Kommentare werden geladen …