Understanding Process Data Packages in LCS
There are thirty-two words in the thesaurus for “package”. When the new Dynamics AX (v7) was developed, it seems like everything new was named a package; perhaps it’s because amalgamation does not have the same je ne sais quoi. The nuanced world of Process Data Packages is superfluously delved into forthwith.
AX Data Package Dictionary
There are a few data loading concepts around AX to have in mind:
- Data Entity – An Entity is a view containing one or more tables that can read or write data. Data entities are the only mechanism to import data to and export data from Dynamics AX.
- Data Package – A collection of Data entities with a specified order. The output of Data packages is a ZIP file containing Excel files.
- Process Data Package (PDP) – A collection of Data Packages with a specified order. PDPs are defined in LCS to load a series of Data Packages into a target environment.
- Supreme Data Packages Traversing All Space and Time – Just kidding.
Data Load Scenarios
Continuing with the definition theme, there are some scenarios to keep in mind why Process Data Packages would be used, versus just using individual Data entities to load data.
- Default data – When starting an AX implementation, it’s useful to seed an environment with some standard setups for a solution. Providing default data means not having to start from scratch on every implementation.
- Company copy – When doing multi-entity rollouts, many times one company will be fully configured as the master company for testing. The master company’s setups will then be copied to other Legal entities and localized.
- Initial data conversion loads – For a Conference Room Pilot, putting some master files in an environment will help users have a starting point for entering transactions with their data.
Creating Data Packages
Microsoft has sample Process Data Packages in LCS. In an LCS project, go into Asset library > Process data package > Import to bring the Data packages into the LCS project (Asset library > Data packages). These can be used as reference material or consumed.
Examining the Microsoft packages does not necessarily help conceptualize the organization of Data Packages. The sections below explain why Data Packages should be split up a certain way. Keep in mind the scenario of loading data into a blank AX database, which would include the Default data plus Initial data conversion load experiences.
The first tables that need to be populated are shared tables. This would include entities like Currencies, Address tables, Chart of accounts, Calendars, and Account structures.
Number sequences is a special case since the tables include shared and company specific data. It is possible to divide the data up using a Company filter in the Data Package definition. Splitting the number sequence between shared and entity specific also helps more closely align default data packages with the company copy scenario.
Shared tables that reference a legal entity
There are four common cases of a shared table with Legal entity specific data. Our recommendation is to put all four of these entities into one Data Package since each of these Excel files will need to be modified.
The entities are:
- Legal entity
- Number sequence code (Company specific)
- Number sequence references (Company specific)
Naming this Data Package something obvious like “Edit Legal Entity Id Before Import” hopefully clues the user into the fact that this package requires editing.
Data Package editing tip: Make sure the ZIP file has the same structure before and after editing the Excel files. All the files must be in the root directory of the ZIP file. It’s easy with Windows technology to re-zip things in a sub-folder.
Company specific tables
At this point the goal is to go module by module building up the company specific configuration data. Order of importing is important; the basic order starts with the General ledger and works through the other modules from there. Referencing the Microsoft provided packages will help get entities in the right order.
Within the module the order of entity load matters. For example, the Accounts receivable posting profile is referenced in the Accounts receivable parameters. Therefore, the posting profile needs to be loaded first.
Initial data conversion loads
In many ways these entities are very similar to the Company specific tables. When editing complex entities in Excel, one key difference is giving the user a more manageable template. Providing the Vendors entity with all 150 columns is an exercise in frustration when trying to execute an initial data load.
When defining a Data entity inside of a Data package, it’s possible to upload a spreadsheet with only the most commonly used fields as the Entity definition. This way a user can be presented with a Vendors spreadsheet that has 10% of the total fields – a much more manageable approach.
The other concept that’s helpful for initial data conversion is putting some scenario based data into the spreadsheets. Sticking with the vendor load concept, the files could have sample vendors named “Trade Vendor”, “Employee Vendor”, and “1099 Vendor”; each of these types of vendors have the appropriate vendor entity fields populated.
Defining Process Data Packages
Process Data Packages generally will align with the data scenarios – Default data, Company copy, and Initial data conversion. All of these make sense as PDPs because the data in these scenarios is all loaded at the same time.
The Data Packages are uploaded to LCS, then the PDP is defined to select the Data Packages to include.
Linking Process Data Packages to Business Processes
The “process” in Process Data Packages is related to the fact Data packages must be linked to nodes in a Business process library. This is an advanced piece of functionality that’s somewhat overbaked for the basic scenarios.
For basic data load scenarios like the ones listed above, it probably makes sense just to link the Process data packages to one Business process, such as a “System configuration” business process. Doing a simple link will help quickly navigate the PDP consumption process.
For advanced data load scenarios, it could make sense to tie a Data package to a business process. An example of an advanced process might be setting up United States tax rules versus typical VAT rules. Depending on the country, a specific tax parameter “Apply sales tax taxation rules” needs to be on, and the tax posting profiles are set up differently. It could make sense to tie one Data Package to the tax rules and parameters for the USA and another for regular VAT. Advanced scenarios take a lot of planning as they generally are more specific than just loading tables – many times advanced data loads require specific parameters or a subset of records to support the scenario.
Defining an Export Data Package from an existing Data Package ZIP file
It is possible to use the Data Package ZIP file to define the Export definition in Dynamics AX. This is especially useful if Data Packages have already been defined for Default Data and will be reused for a Company Copy. The Data Package definitions for these two scenarios will be very similar, except the shared tables are omitted for a company copy.
To import the definition of a package, create a Data Management Export Group and select a file type of “Package”. Then upload the ZIP file.
Consuming Process Data Packages
When consuming PDPs, the name of the target environment is only displayed one at the beginning of the consumption process. So use the name of the target environment in the consumption description.
If the link between PDPs and Business process has been kept simple, the approval process for consuming PDPs should be quick. Just Approve the System configuration business process and move on to consuming the Data packages.
Depending on the nature of the Data Packages, many of them are simply deployed to the target environment. Some Data Packages like the Legal entity or Initial data conversion Data Package must be edited before import.
Too much editing of Excel files before import can be a risky proposition, because it is not easy to keep track of all the data dependencies. It’s better to keep the editing limited, and modify the data as needed once it is in AX. The same Data Entities used in these data loads work with the Excel add-in.
Legal entity Id tip: Get it right the first time. Make sure the appropriate company stakeholders (generally a Financial controller) understand where the Legal entity Id shows up and that they are making a final decision. There’s only one chance to do this in a Staging/Gold/Prod environment because changing it means starting over.
There’s a lot of legwork involved in structuring the Process Data Packages for consumption. A number of tasks need to align including: creating Data Entities, setting up Default Data, exporting the Data Packages, defining the experience in LCS, and doing test data deployments to a test target environment. With the right data solution, AX can go from a blank or Contoso environment directly into posting test transactions for a solution.
- Azure Marketplace and the new Dynamics AX (v7)
- Workspaces in Dynamics AX (v7) - Let’s Make them Awesome
- Packaging Extensions for Dynamics AX