Monday, December 12, 2016

Quick tips for Dynamics AX Implementations

Having worked on a number of AX projects over the years I have learned many things and wanted to share a few to help you with your project.

  1. Make sure your partner is both capable and compatible. Most companies focus on finding a partner that is capable or has specific industry experience. Just as important is finding a partner that meshes with your team, that can fit with your culture and use these to achieve results. 
  2. Very few of your users will have had any training on what it means to test software properly and how to document the results. Consider sitting everyone for a quick training session on how to test and document properly.
  3. Speaking of documentation, make sure yours is complete. Don't skimp or think it can be done later. This is where your partner's expertise really comes. All the forms and notes and memo's are there for a reason. Post go-live consider adopting a similar process internally to keep your system running smoothly. 
  4. Make all of your meetings effective and efficient. Have an agenda, a specific duration and actions. If the goal is to get a decision made, make sure it gets made. Keep to your duration, everyone is busy. This requires strong leadership at every meeting.
  5. Understand that team members have a day job they are probably going to have to continue to do. That means that resource planning is difficult. Between meetings (4 above) team members are often given homework, but their day jobs get in the way. Try and have team members get away from their desks to their homework. It will be much more effective.
  6. As I have said many times, if you didn't start Data Migration the day you started your project, you are behind.
  7. Lastly, make sure everyone is trained and then trained again.

Thursday, May 19, 2016

Detailing AX Security Roles Through SQL

So I was trying to find an easy way to list all security roles, including customization's and ISV products in a way that I can hand to a user to show what each role contains. There are several add-on solutions that will do this. This also pulls all the label text for names and descriptions. Here is the quick and dirty SQL I came up with:

SELECT 
a.aotname as [System Name], 
b.text as [Name], 
c.text as [Description], 
e.AOTName as [Duty/Privilege System Name], 
f.text as [Duty/Privilege Name]--,
,CASE WHEN e.description like '@%' THEN (SELECT TEXT FROM ModelElementLabel G WHERE right(e.description, len(e.description)-4) = g.labelid and G.language='en_us' and g.module = substring(e.description, 2, 3)) ELSE '' END AS [Duty/Privilege Description] 

FROM SECURITYROLE A
INNER JOIN ModelElementLabel b on right(a.name, len(a.name)-4) = b.labelid and b.language='en_us' and b.module = substring(a.name, 2, 3)
INNER JOIN ModelElementLabel c on right(a.description, len(a.description)-4) = c.labelid and c.language='en_us' and c.module = substring(a.description, 2, 3)
INNER JOIN SecurityRoleTaskGrant d on d.SecurityRole = a.recid
INNER JOIN SecurityTask e on d.securitytask = e.recid
INNER JOIN ModelElementLabel f on right(e.name, len(e.name)-4) = f.labelid and f.language='en_us' and f.module = substring(e.name, 2, 3)

ORDER BY a.aotname, e.aotname

Monday, January 18, 2016

Revisiting the Data Import Export Framework

I had a chance recently to revisit using the DIXF on a new project we have to integrate data from multiple ERP's. The target environment is AX 2012 R3 CU10 with the latest and greatest DIXF. I have covered DIXF in previous posts and talked about it Data Migration presentations as s good tool if you can get it to work. In my revisit test, I found it quick and easy to bring in the complete Chart of Accounts (Main Accounts) from AX 2009. 


Environment


  • AX 2012 R3 CU10
  • Blank database, initialization checklist completed.
  • SQL 2014 components installed

Process

  1. After initialization complete, I setup a 64 bit User DSN in ODBC
  2. Create a test company in AX 2012
  3. Create a fiscal calendar in General Ledger - Setup - Fiscal Calendar 
  4. Setup the basic Ledger in General Ledger - Setup - Ledger. Chose the Calendar I had created and currency.
  5. In DIXF setup a Source Data format for an ODBC connection created in Step 1 
  6.  Create a processing group in DIXF 

  7. Select Entities and choose the Main Account Entity
  8. Click Modify source mapping and update the map 
  9. One note as AX 2009 does not have the Chart of Accounts option and this is a required field in 2012, I hard coded this in the mapping the the "Shared" accounts I chose above. With a string value. You do this by clicking Mapping details, adding a new row, select the destination field and select default value. 
  10. Then you are all set, from Processing Group click Get Staging Data and then Copy data to Target. Total time about 20 minutes to get a complete set of Main Accounts in the system.

Monday, October 19, 2015

Setting AX coding standards for contractors and consultants

Maintaining a consistent code base in your application is very important. When dealing with external resources to provide code for your environment it is important they understand what you expect beyond "code that works". It needs to work with everything else you have done. To help ensure I provide the following to everyone to agree to before they provide code. 


  1. All custom development requires an approved functional design and technical design document.  These can be part of the same document, but customer sign-off is required before any coding is started.
  2. Code is to:
    1. Be written on the CUS layer of the development environment.
    2. Compile error free.
    3. Not have any best practices errors.
    4. Be fully commented including name, date, short description of functionality, and definition of any parameters.
    5. All custom tables, enums, EDT's, classes, forms, etc are to be prefaced with PREFIX
    6. Any custom methods on existing items are to be prefaced with PREFIX
    7. Fields on tables and forms are NEVER to be repurposed. Create a new field as needed.
    8. Make names as descriptive as possible.
    9. Use a label file for all labels
    10. Follow Microsoft X++ Coding standards (http://msdn.microsoft.com/en-us/library/aa855488.aspx)
  3. Performance:
    1. All code is to be designed with performance execution in mind. Eliminating unnecessary code calls and validation. 
    2. Any tables created are required to have a clustered index and additional indexes as required
    3. Code should be tested under expected load and optimized as appropriate.
  4. Upon completion and unit testing of code, a code review will be completed by our technical resources before moving to the test environment. Any technical issues will need to be addressed before the code is accepted.
  5. Code Moves
    1. AX 2009 – Regular code is to be moved via Layer files, not XPO.  XPO can only be used for emergency hot fixes.
    2. AX 2012 – Regular code is to be moved via AX Model Stores, not XPO.  XPO can only be used for emergency hot fixes.
  6. When in doubt, ask a question.


Tuesday, October 6, 2015

AXUG Summit INReno15 Speaker

Once again I will be speaking at the AXUG Summit in Reno. I will be speaking about:
  • Why you should volunteer with AXUG
  • Microsoft Dynamics AX 2009 Security Round table
  • Best Practices for Dynamics AX 2012 Data Migration
  • Data Migration Approaches with Dynamics AX
  • Optimize Enterprise Portal
You may also see me and others wearing a lab coat as an AXUG medic. The medic's are there to answer any questions you have about AX and are a great resource.

Hope to see you in Reno!