In this chapter, we will learn about configuration planning, collecting configuration data, the tools available to facilitate configuration, and the various approaches towards configuration management and promoting configurations from one environment to another.
The configuration of an ERP system is one of the most important parts of the process. Configuration means setting up the base data and parameters to enable your product features such as financial, shipping, sales tax, and so on.
Dynamics AX has been developed based on the generic requirements of various organizations and contains the business processes belonging to diverse business segments. It is a very configurable product that allows the implementation team to configure features based on specific business needs. During the project, the implementation team identifies the relevant components of the system and sets up and aligns these components to meet the specific business requirements. This process starts in the analysis phase of the project carrying on through the design, development, and deployment phases.
Configuration management is different from data migration. Data migration broadly covers the transactional data of the legacy system and core master data, such as opening balances, Open AR, Open AP, customers, vendors, and so on. When we talk about configuration management, we are referring to items like general ledger, fiscal years and periods, chart of accounts, segments, and defining applicable rules, journal types, customer groups, terms of payments, module-based parameters, workflows, number sequences, and the like. In a broader sense, configuration covers the basic parameters, master data, and reference data that you configure for the different modules in Dynamics AX.
The following diagram shows the different phases of configuration management:
Configuration planning is, basically, identifying all the configurations required for your implementation project. Most configuration requirements are known from the solution design phase and finalized with the sign-off of the functional and technical design specifications.
The first step towards configuration planning is to identify the modules and functional areas which need be to be configured. The following are some pointers for getting started with the planning:
Configuration |
Environment |
Value |
---|---|---|
Web service URL for sales tax software |
Development |
|
Testing |
| |
Production |
| |
Payment gateway setting |
Development |
|
Testing |
| |
Production |
| |
File-share path (document management) |
Development |
|
Testing |
| |
Production |
|
Columns |
Description |
Example 1 |
Example 2 |
---|---|---|---|
Batch job name |
Name of the batch job |
Auto-invoicing domestic orders |
Product creation batch |
Functional area |
AP, AR, Inventory, and so on. |
AR |
Product information management |
Business owner |
Who, from business, should be contacted for testing, errors (If batch job fails, once you go to Production) |
AR manager |
PIM manager |
Consulting owner |
Person responsible from the consulting team |
Yogesh Kasat |
JJ Yadav |
IT owner |
Person responsible from the internal IT team |
Finance BSA |
PIM BSA |
Frequency |
How often does the batch job need to run (for example, every 15 minutes, every day at 6 P.M.) |
Every 15 minutes; from 6 a.m. through 7 p.m. (timings are driven by batch group and active AOS as batch) |
Everyday at 6 p.m |
Parameters |
Any filters or parameters to be defined while scheduling the batch job |
Sales origin = 'Domestic' |
Record status = "Ready" |
Dependencies |
Scheduling dependencies between batch jobs | ||
Path or class name |
Path from where to access the menu or class to be used for scheduling the batch job |
ARperiodicupdateinvoice |
PIMperiodic832 item creation (custom) |
Batch group |
DayTime* |
NightTime | |
Comments |
Additional comments |
*The DayTime batch group has AOS defined as a batch AOS only during business hours (6 a.m. through 7 p.m.).