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

Microsoft BizApps Finance & Controlling

Microsoft BizApps Finance & Controlling

Kategorien-Archiv: Hauptbuch

Dynamics AX Hauptbuch

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.

Automatische Buchung von Journalen

17 Mittwoch Aug 2016

Posted by Ludwig Reinhard in Anlagen, Debitoren, Hauptbuch, Kreditoren

≈ Hinterlasse einen Kommentar

Schlagwörter

automatisierte & periodische Verarbeitung, Journalbuchungen

Während es im vorherigen Beitrag primär darum ging, wie man sicherstellen kann, dass nur bestimmte Benutzer bestimmte Buchungsjournale auswählen und buchen können, möchte ich im Rahmen dieses Beitrags aufzeigen, wie man Journale automatisiert buchen kann.

Die Funktionalität auf die nachfolgend eingegangen werden soll, kann man im Hauptbuch im Bereich der Journaleinträge unter dem Menüpunkt „Erfassungen buchen“ (bzw. in den Vorversionen unter dem gleichen Namen im Bereich der periodischen Aufgaben) finden.

Da die von Microsoft zu dieser Funktion bereitgestellten Informationen etwas dürftig sind und in der Vergangenheit des Öfteren Fragen zu dieser Funktion aufkamen, möchte ich im Rahmen dieses Beitrags die Funktionsweise der automatisierten & periodischen Buchungsfunktion anhand von Beispielen näher erläutern.

Hinweis: Nachfolgend wird lediglich die Verarbeitung von allgemeinen Hauptbuchjournalen aufgezeigt. Diese Verarbeitung kann allerdings auch auf die Buchung weiterer Journale angewendet werden. Siehe hierzu die Informationen auf der folgenden Seite.

 

Ausgangspunkt für die nachfolgenden Darstellungen ist die Erfassung von mehreren Buchungsjournalen, die teilweise vollständig korrekt („OK“), teilweise mit einzelnen fehlerhaften Buchungszeilen („Partly ok“) bzw. komplett fehlerhaft („Error“) angelegt wurden, indem bspw. das Gegenkonto nicht erfasst wurde. Siehe hierzu auch den folgenden Screenshot.
DE_127_0005

 

Option 1: Selektion und Buchung der erfassten Journale
Um die erfassten Journale (soweit möglich) buchen zu können, wurden diese zunächst über die Funktion „Erfassungen buchen“ wie folgt ausgewählt…
DE_127_0010 DE_127_0015
… um den Buchungsprozess anschließend mit OK zu starten.
DE_127_0020
Ergebnis:
Ergebnis dieses Verarbeitungsprozesses war, dass alle fehlerfreien Journale gebucht und die mit Fehler behafteten Journale mit einem Fehlerprotokoll entsprechend ungebucht stehen blieben. Wurden weitere fehlerfrei erstellte Journale angelegt, so fand keine weitere automatisierte Buchung dieser Journale statt.
DE_127_0025

 

Option 2: Selektion und Buchung der erfassten Journale mit Hilfe eines Batchjobs
Um auch später angelegte Journale automatisiert buchen zu können wurden zunächst die fehlerhaften stehen gebliebenen Journale gelöscht und erneut fünf Buchungsjournale in gleicher Weise wie zuvor angelegt und ausgewählt. Siehe den folgenden Screenshot.
DE_127_0030
Im Gegensatz zu vorher wurde nun allerdings die Buchungsverarbeitung der Journale über einen Stapelvearbeitungslauf gesteuert, der im 5-Minutentakt lief.
DE_127_0035
Ergebnis:
Wie zuvor wurden lediglich die drei fehlerfreien Journale gebucht und die beiden fehlerhaften Journale blieben ungebucht stehen.
DE_127_0040
Wurde nun ein neues fehlerfreies Buchungsjournal angelegt, …
DE_127_0045
…so passierte trotz des eingerichteten Stapelverarbeitungslaufes nichts weiter, weil der Verarbeitungslauf nach den ersten identifizierten fehlerhaften Journalen – im Beispiel Journal Nr. 183 und Nr. 186 – abgebrochen wurde.
DE_127_0050

 

Option 3: Wie Option 2 allerdings mit dem Parameter Übertragungsfehler aktiviert
Nachdem die Verarbeitung weiterer neu angelegter Journale über die vorherigen Einstellungen nicht funktionierte, habe ich im nächsten Schritt die alten und ungebuchten Journale gelöscht, um anschließend fünf neue Buchungsjournale in gleicher Weise wie zuvor anzulegen. Im Gegensatz zu vorher wurde die Buchungsverarbeitung diesmal mit den aktivierten Übertragungsfehler-Parametern gestartet, wie dies im folgenden Screenshot dargestellt ist.
DE_127_0055
Ergebnis:
Nachdem auch hier die fehlerhaften Journale erwartungsgemäß nicht gebucht wurden und ich ein neues Buchungsjournal angelegt habe…
DE_127_0060
… wurde leider auch dieses neue Journal nicht gebucht, da der Batchprozess aufgrund der fehlerhaften vorherigen Journalverarbeitung erneut abbrach.
DE_127_0065
Hinweis: Der wesentliche Unterschied zwischen dieser und der vorherigen Buchungs-Option 2 besteht darin, dass die korrekt im teilweise fehlerhaften Buchungsjournal Nr. 189 erfassten Buchungen gebucht und die in diesem Journal enthaltenen Fehler in ein neues Journal mit der Nr. 191 übertragen wurden. Siehe hierzu auch nochmals die obenstehenden Screenshots.

 

Option 4: Wie Option 3 allerdings mit den Parameter „späte Auswahl“ und Übertragungsfehler aktiviert
Nachdem ich alle ungebuchten Journale nochmals gelöscht und neue Journale angelegt habe, wurde der Buchungsprozess schließlich mit der folgenden geänderten Parameterauswahl gestartet:
DE_127_0075
Hinweis: Mit der Umstellung des Parameters “späte Auswahl” auf JA sind die im oberen Fensterbereich ursprünglich ausgewählten Journale nicht mehr sichtbar.

Ergebnis:
Wie zuvor blieben auch in diesem Fall die beiden vorherigen vollständigen bzw. teilweise fehlerhaften Journale bzw. Journalzeilen ungebucht stehen; neu angelegte fehlerfreie Journale – im Beispiel Journal Nr. 196 – wurden allerdings gebucht, wie die folgenden beiden Screenshots aufzeigen.
DE_127_0080 DE_127_0085
Hinweis: Da der Batchverarbeitungslauf allerdings nach wie vor auf eine Verarbeitungszeit von wenigen Minuten eingestellt ist, läuft er alle paar Minuten auf einen Fehler. Siehe hierzu den nächsten Screenshot.
DE_127_0090
Falls für eine fehlerhafte Batchverarbeitung Warn- bzw. Email-Nachrichten eingerichtet wurden – dies ist derzeit in AX7 nicht möglich – bedeutet dies, dass eine Vielzahl an (unnötigen) Warn- und Fehlermeldungen generiert wird, die ihr Email-Postfach sprichwörtlich überfluten können.

Buchungsjournaleinschränkungen

01 Montag Aug 2016

Posted by Ludwig Reinhard in Hauptbuch

≈ Ein Kommentar

Schlagwörter

Hauptbuch, Journale, Journaleinrichtung

Im Rahmen dieses Beitrags möchte ich auf zwei Fragestellungen eingehen denen ich in der Vergangenheit des Öfteren begegnet bin.

Frage 1:
Wie kann man sicherstellen dass nur bestimmte Benutzer Zugriff auf bestimmte Journale haben und diese anlegen und bearbeiten können?
Frage 2:
Wie kann man andere daran hindern von einem selbst erstellte Journale „wegzubuchen“?

Für die Beantwortung der ersten Frage habe ich folgendes Journal angelegt. Zu beachten ist in diesem Zusammenhang, dass dieses Journal mit einer Einschränkung auf eine bestimmte Benutzergruppe angelegt wurde, der lediglich ein Benutzer „DOC“ zugeordnet wurde.
DE_AX7_122_0005
Im zweiten Schritt habe ich ein Buchungsjournal vom Hauptbuchhalter „DOC“ anlegen lassen …
DE_AX7_122_0010
… um nach einem login mit einem anderen Benutzer („PROF“) zu versuchen das Journal zu buchen. Der folgende Screenshot zeigt das Ergebnis dieses Versuches auf.
DE_AX7_122_0015
Wie sie aus dem obenstehenden Screenshot erkennen können, kann der andere Benutzer das Journal nicht identifizieren und buchen, da er nicht der hinterlegten Benutzergruppe zugehört.

Hinweis: Andere als in der Benutzergruppe zugeordnete Benutzer können das entsprechende Journal „DOC“ nicht einmal auswählen und anlegen (siehe den folgenden Screenshot).
DE_AX7_122_0016

Für die Beantwortung der zweiten Frage habe ich ein zweites Hauptbuchjournal angelegt, das ich diesmal nicht mit einer Benutzergruppe verknüpft habe. Stattdessen habe ich alle Systembenutzer über die Buchungseinschränkungsmaske ausgewählt.DE_AX7_122_0020Ergebnis:
Nachdem der Hauptbuchhalter „DOC“ ein Journal diesen Namens angelegt hat…
DE_AX7_122_0025… können andere Nutzer – hier „PROF“ – das Journal zwar identifizieren aber aufgrund der hinterlegten Buchungseinschränkung nicht buchen. DE_AX7_122_0030

Zusammenfassung:
Wie aufgezeigt können bestimmte unberechtigte Nutzer über die Hinterlegung einer privaten Benutzergruppe daran gehindert werden bestimmte Buchungsjournale anzulegen und zu buchen.
Die Nutzung der Buchungseinschränkungsfunktion ist im Vergleich zur Hinterlegung einer privaten Benutzergruppe weniger restriktiv und erlaubt zumindest die Ansicht, Prüfung und Korrektur von Buchungsjournalen, nicht aber deren Durchbuchung.

 

Ich hoffe dass Ihnen die Informationen in diesem Beitrag helfen konnten und würde mich freuen Sie auch in den nächsten Beiträgen wieder zu sehen.

← Ä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 …