Dynamics Views
Einblicke, Meinungen und News rund um Microsoft Dynamics 365 Finance und Supply Chain Management sowie Dynamics AX
Anlagenmigration in Dynamics AX mit Atlas – Pain Points und Lösungen
Um Anlagen in Dynamics AX zu migrieren, setzen wir seit Jahren Atlas – eine vielseitige Microsoft-Office-Erweiterung von Global Software – ein. Sowohl das Tool als auch unser Vorgehen haben sich bewährt. Nichtsdestotrotz kann ein komplexer Prozess wie die Migration von Anlagen in Dynamics AX eine Reihe von Problemstellungen mit sich bringen. Ich beschäftige ich mich hier mit den Pain Points, denen ich in meiner Projektpraxis als Dynamics-AX-Berater bei Anlagenmigrationen begegnet bin – und gebe unsere Lösungsansätze preis.
Problem 1
Das größte Problem bei der Anlagenmigration ist oft die Qualität der Quelldaten. Diese müssen gut gepflegt und für die Migration vorbereitet sein. Wenn zum Beispiel das Abgangs-/Verschrottungsdatum das maßgebende Kriterium ist, ob die Anlage zu migrieren ist, dann muss das Datum in dem zugehörigen Feld im Quellsystem gepflegt sein, und zwar über alle Anlagen und alle Mandanten hinweg.
Lösung:
Zeit und Budget für die Migrationsvorbereitung einplanen.
Problem 2
Felder wie AssetTable.Worker und AssetTable.Location sind mit einem RecID auf die jeweiligen Tabellen verknüpft. Diese Daten müssen in den jeweiligen Tabellen schon vorhanden sein und die RecIDs müssen ermittelt werden, bevor AssetTable hochgeladen wird.
Lösung:
Um die Migration leichter zu machen: Solche Felder NICHT migrieren, außer wenn dies explizit angefordert ist; die zahlreichen String-Felder statt der RecID-Felder benutzen.
Problem 3
Atlas ergibt Fehler, wenn ein Feld mit RecID Referenz leer ist.
Lösung:
Leere RecID Felder müssen mit null belegt sein.
Problem 4
Das Feld „Status des Wertmodells“ lässt sich nicht hochladen.
Lösung:
Der Standardwert für neue Anlagen ist „noch nicht erworben“ und kann nur durch Anlagenbuchungen oder X++ Job auf „offen“ gesetzt sein. Danach ist eine Änderung per Hand oder Atlas-Update möglich.
Problem 5
Das Mapping ist wegen der hohen Anzahl von Feldern aufwendig.
Lösung:
Nicht übermäßig gewissenhaft mit den Uploads sein: Leere Felder müssen nicht gemappt oder hochgeladen werden; bei Feldern, die durchgehend nur einen Wert haben, den Wert einfach eintippen statt aus der Importtabelle zu lesen.
Problem 6
Die Kontierungseinstellungen im Anlagenbuchungsprofil sind versteckt und nicht direkt über Anlage oder Anlagengruppe sichtbar.
Lösung:
Prüfen, ob die Anlagengruppen analog zu den Bilanzkonten benannt werden können, die hinter der Gruppe als Anschaffungskonto stecken. Somit ist das „Bilanzkonto“ direkt in der Anlage sichtbar; die Buchhalter lieben es!
Problem 7
In den Tabellen mit Sachkontoreferenz (z. B. AssetLedgerAccounts und LedgerJournalTrans) sind die Sachkonten nicht direkt, sondern mit RecIds einer Dimensionstabelle referenziert.
Lösung:
Dies ist eigentlich kein Problem mit Atlas: Atlas generiert virtuelle Felder in den Tabellen, und die sind mit „LedgerDimension_MainAccount“ bzw. „OffsetLedgerDimension_MainAccount“ kennzeichnet. Sachkontonummer kann in „human readable“ Format hochgeladen werden; Atlas ermittelt die RecIds selbstständig.
Problem 8
Dasselbe Uploadtemplate wird für mehrere Unternehmen verwendet. Da es bei jedem Upload unterschiedlich viele Zeilen beinhaltet, muss der Zellbereich jedes Mal geändert werden, z. B. $A$4:$A$1000 à $A$4:$A$4500. Diese Referenzen sind außerdem schwer lesbar.
Lösung:
Mit Namen (Named area) und Tabellen arbeiten wie folgt:
- Tabelle aus den Uploaddaten machen (Strg+T)
- Die neue Tabelle aussagekräftig benennen unter dem Reiter „Tabellentools“ in „ActionPane“ (bspw. MyUploadData)
- Die Spalten benennen mit Tabellenreferenz:
- Diese Namen (bspw. AcquisitionDate) beim Mapping in Atlas als Referenz verwenden, anstatt Zellenbereiche =$P$3:$P$96
Vorteil 1: Sie können Zeilen in Ihrem Template löschen und hinzufügen, OHNE dass die Referenzen geändert werden müssen!
Vorteil 2: Sie können solche Named Areas in den Mappingfeldern per Rechtsklicken verwenden. Alternativ lassen sich die Tabellenreferenzen wie =MyUploadData[AcquisitionDate] auch direkt in Atlas verwenden.
Sonstige Überlegungen
- Die Atlas-Funktion „Finden und Ersetzen“ immer vermeiden. Es ist sehr leicht, Daten versehentlich zu löschen. Lieber erst die Zieltabelle in Dynamics AX per Strg+A, Alt+F9 reinigen.
- Um ein Journal für Anlagevermögen mit Atlas hochzuladen, gibt es zwei Dinge zu beachten:
Im Gegensatz zu normalen Journaluploads müssen drei Tabellen angesprochen werden: LedgerJournaTable, LedgerJournalTrans und zusätzlich LedgerJournalTrans_Assets. Letztere wird mit ledgerJournalTrans über RecID und RefRecID verknüpft. RefRecID muss zwingend als Feld von LedgerJournalTrans_Assets ausgewählt werden und auf die übergeordnete Feldliste zu RecID verweisen.
Schreiben Sie einen Kommentar
Kommentar...