This article will cover advanced x++ to show how developers can serialize financial dimensions to create a default dimension surrogate key from a series of financial dimensions.
In Microsoft Dynamics AX 2012 the financial dimensions are stored as a 64bit integer surrogate key in the database. For example, the following financial dimension combination of BusinessUnit = 001, ItemGroup = Service in AX it is represented as 22565424233. For example, an integration or import process may require a combination of financial dimensions to be serialized in order to save this information in Microsoft Dynamics AX.
There have been significant changes in how financial dimensions are stored in Microsoft Dynamics AX 2012 versus previous versions, and this blog post can assist developers who are not familiar with Microsoft Dynamics AX 2012 financial dimension architecture. This blog explains how this can be used, using a simple import routine. Please refer to my other post about How to Deserialize a Default Dimension in Microsoft Dynamics AX 2012.
Financial dimensions are stored as a 64bit integer surrogate key in the database. When reading/importing financial dimensions it is necessary to create this 64bit integer surrogate key to be stored in the database. This blog explains some of the common Microsoft Dynamics APIs available to save/create a default dimension surrogate key. I’ve created a simple job to demonstrate this.
In this example, we will be working with the financial dimensions of a customer and we will be reading its financial dimensions out of a CSV file and we are filling out the default dimensions in AX.
These financial dimensions are stored in the SQL database as a 64 bit integer, right now for customer US-001 there are no financial dimensions, thus we have the DefaultDimension field equal 0.
The following script is created to demonstrate:
– The DimensionAttributeValueSetStorage class is used to iterate through all the financial dimensions in the DefaultDimension.
– The DimensionAttributeValue table is used, this stores a link to the VALUE of the financial dimension we want to display, for example a department or cost center number. This is usually linked via a surrogate key, e.g. DimensionAttibuteValue.EntityInstance is a surrogate key to the exact record we wish to display.
– The DimensionAttribute table is used, this stores information so we can understand the TYPE of financial dimension. This stores the object ID of the view or tabled used as backing entity, e.g. 11765 = DimAttributeOMDepartment
– The DimensionAttribute record contains a “ValueAttibute” field, which is the field id in the backing entity view that stores the VALUE of the financial dimension, this is a natural key, for example a department ID (e.g. Department 10).
Thanks for reading this blog, let me know if you liked it or if you want to hear about something else in my next post!
The post Serializing Financial Dimensions in Microsoft Dynamics AX 2012 – Default Dimensions appeared first on Avantiico.
Microsoft and Avantiico will be hosting a free informational event in Irvine, CA on December 1st, 2017 to answer any questions the community may have regarding how to properly evaluate an ERP or CRM system and transition from your legacy platform.
We will also feature a Q/A with a representative from NOVA Steel about their current implementation process of Microsoft Dynamics 365.
Attend Evolve: The Journey to Microsoft Dynamics 365.
RSVP here while seats are still available!
View the agenda here.
The post The Journey to Microsoft Dynamics 365 appeared first on Avantiico.
In conversations with organizations from various industries, we have noticed an increasing awareness over the last twelve to eighteen months of the limits of legacy ERP and CRM solutions. Even for companies that had invested in Dynamics ERP solutions several years ago, the advances in SaaS and hybrid solutions from Microsoft seem to be sparking new interest.
But evaluating new ERP or CRM investments is as important and demanding as ever. We have been refining the ways we help our clients do their homework on Dynamics 365, and have identified the most important areas that any executive or line of business manager needs to account for. What follows is a list of the details that any systems integrator should be able to help you understand.
We will be diving into these themes in more detail, both from a customer and service provider perspective, at our December 1st Dynamics 365 evaluation event, hosted by Avantiico and Microsoft at the Microsoft Training Center in Irvine, CA.
Our most successful Dynamics 365 clients did not make the mistake of underestimating the importance of setting the right evaluation criteria and then diving deep to really understand out of the box options in combination with trusted third-party solutions. Some of the most common evaluation points where a deep dive is critical include:
– Module breakdown
– Reporting tools: OOTB Power BI content packs, integration to third party reporting systems, Excel integration, etc.
Microsoft has done a huge amount of work to make the Azure cloud an easy choice for organizations of all sizes. But the reality is that many enterprise application buyers still live in a hybrid world and will for many years to come. On-premises, private hosting, and public cloud all offer their own strengths, and the truth is that establishing the optimal architecture requires dedicated expertise.
We work with cloud experts at Microsoft and our infrastructure partners, and they frame the decision process around what is the best fit for our clients whether it be fully cloud, hybrid or on premise deployments.
The Dynamics 365 Lifecycle Services (LCS) platform is a competitive differentiator for Microsoft that can be easy to overlook. Unlike other vendors’ “quick start” tools, LCS is comprehensive. The greatest value, thanks to the step by step process, is its ability to guide our clients through a reliable, detailed process and keep us all in the loop as to where the project currently stands at all times.
LCS also plays a part in managing licensing options for D365 ERP clients. In a subscription-based ERP environment Microsoft gives us new ways to optimize ERP spending through advanced analytics. These tools have led to real savings for customers.
Every enterprise software purchase decision should factor in industry-specific needs. We encourage our clients to press vendors and service providers for answers to the hardest questions related to their own businesses and to their industries. Events like the upcoming evaluation day at Microsoft Training Center Irvine is just such an opportunity. Because while there is no one-size-fits-all approach to successful ERP, our experience with Dynamics 365 for Finance and Operations, Enterprise has demonstrated that it can suit a growing range of needs.
The post What New Microsoft D365 Customers are Doing Right appeared first on Avantiico.
With the release of Dynamics 365 for Finance and Operations, Enterprise edition July, 2017 update, configuration data packages were introduced that allow users to quickly download best practice data from Life-cycle Services to quickly create an initial “golden” data build.
While these data packages are useful for creating demo data, they can’t be used to move data from one environment to another during a project’s implementation phase. Enter: configuration data templates.
Configuration data templates are predefined lists of data entities that can be used in these data projects, already sequenced in the correct order. These data templates contain the same data entities that are included in configuration data packages, but can then be used from the data management workspace to move data from one environment into another. Configuration data templates can help implementers ensure that all entities for a specific task have been selected, and that they are sequenced in the correct order.
Default data templates can be downloaded into a user’s data management workspace, and used to create templates of entities. The default templates can help users to easily create a list of data entities to support common areas of data for migration purposes.
In this post, users will learn how to load default data templates, modify , and use them to export data as data packages, and then import data into another environment.
This post assumes that users are running at least Microsoft Dynamics 365 for Finance and operations, Enterprise Edition, platform release Update 10 (August, 2017) or greater.
To view the entities associated with a default template, that template must first be downloaded. To download a default template, an implementer will need to open the data management workspace, click on the templates tile to open the templates area, and using the enhanced view, they will need to load default templates.
There are several default templates that are available to be downloaded, and an implementer can download one, some or all of the default templates. Once the default templates have been downloaded, they are available in the template area of the data management workspace.
When a template is loaded from a default, the level in execution and sequence number have already defaulted, so that the data will be imported in the correct order. With addresses, for example, States must be imported before Cities and Cities must be imported before zip codes (or postal codes). By loading the default templates, these sequences are already defined.
Now that the default template has been imported, some modifications may need to be made. The implementer will then review the entities included in the template, and update the template as needed by removing, adding or re-sequencing the data entities. Once any desired changes to the template have been completed, the data for the template’s entities can be exported.
To export data from a template, the implementer must first create an export project, which they will then add the template entities to. The export project is then used to export the data.
Entity data should be exported as a data package. Data packages can be loaded into Lifecycle Services, which can then be used to deployed multiple times, into multiple environments. An export definition group can be configured to automatically generate a data package. If the option is not selected during the setup of the definition group, the data package can still be generated after the export is ran.
When creating an export definition group, implementers should consider if they want to create one definition group with entities in it from many template, or if they will export data from each template as a separate export. If the source environment has many companies, it may make sense to create definition groups that contain many modules (and therefore many templates), as opposed to multiple export groups. To export a company, it is a cleaner approach to only export one or two sets of data per company, as opposed to 20 per company. Note that when creating an export (or an import) definition group, an implementer can assign the applicable legal entity. This can help to ensure that the data being exported or imported is being done from the correct legal entity.
When creating the export definition group, the implementer can use the enhanced view to enable the loading of entities from an existing template. Multiple templates can be loaded into the same export definition group.
Once an implementer has exported the data from the source environment, they can import it into a target environment.
To import the entity data from a saved template that was downloaded as a package, the implementer will click on the data management workspace, and click on the import tile. The import definition is given a name. By using the enhanced view, the implementer can easily see the list of entities being added with the upload and add the data package that was exported.
The sequence for adding a data package to a definition group is done by adding the source data format first, identifying if the staging tables should be skipped or not second, and then by uploading and adding the package data file.
Default templates are a helpful way to get started on the path of data migration, as they provide module-specific collections of entities, that are already sequenced in a way that eases the burden of an implementer.
For more information about Data Migration Templates, this is a great resource: https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/data-entities/configuration-data-templates
The post Templates for Data Management Help Save Time and Resources in Microsoft Dynamics 365 appeared first on Avantiico.