web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Finance | Project Operations, Human Resources, ... / Can a non certified AX...
Finance | Project Operations, Human Resources, ...
Answered

Can a non certified AX developer make customizations to AX2012

(0) ShareShare
ReportReport
Posted on by CBNestor 46

Hi all,

I come here with some important questions about programming and customizing Ax2012.

We bought some time ago the Ax2012 in order to migrate ax3.0 into ax2012.

we as a general developers in our IT department, have tried to make minor and mayor customizations from the USR layer.

We can notice that we can actually modify almost everything from reports to even the standard behavior of the production module by x++.

the questions is:

  1. Is it ok that we are Customizing our solutions for our own system Ax2012? 
  2. what is the right way to modify our system with our needs?
  3. Is the USR layer enough for our needs?
  4. Do we have to buy a special license for other layers in order to make it professionally?
  5. Can we as non MS Partner and/or ax certified Programmer be able to buy any programming layer? 

notice that we are not selling our solutions to other companies. We are trying to make it internally for our own needs.

I appreciate you guys for your answers in this subject.

I have the same question (0)
  • Verified answer
    nmaenpaa Profile Picture
    nmaenpaa 101,160 Moderator on at

    1. Yes. But if you overlayer (=write "on top" of MS code), you will notice that installing new MS updates is very time consuming since you have to manually compare each object that you have modified against new MS version below, and merge the changes to your customization layer. Additionally, support for AX2012 is going to end quite soon, you need to upgrade to D365 and there you have to redesign all your customizations as extensions. So, I recommend to avoid overlayering as much as possible to minimize workload and problems in the inevitable upgrade. Perhaps you could just go directly to D365 instead.

    2. The best way is to not modify it, instead try to learn how to use the standard system. Try to minimize the nr of customizations. When you do customize, you need good understanding of the standard application so that you can put your customization in the correct place. It's very easy to write code that solves your immediate requirement. But it's very difficult to keep developing stuff for years, keeping everything together, understandable and maintainable. These skills are learned through experience, not certification exams. So it might be good to hire some experienced developer to help you learn these things. In addition to development you need to handle ALM (Application Lifecycle Management) so that you can reliably manage your code (source control) and deploy your customizations to test and prod systems.

    3. Yes, and anyway in D365 the layer has basically no impact anymore.

    4. You need special license to access the lower layers.

    5. This I'm not sure about, but it should not be relevant for you.

  • CBNestor Profile Picture
    CBNestor 46 on at

    Hi Nikolaos,

    Thanks a lot for your reply,

    please allow me to ask a little bit more:

    3. what do you mean that the "layer has basically no impact anymore?". you are talking about the USR or all the layers, and what could be the consequences of that "no impact" to us?

    5. please explain why "should not be relevant"?

    thanks  a lot for your time!

  • Verified answer
    Martin Dráb Profile Picture
    Martin Dráb 237,926 Most Valuable Professional on at

    Layers still technically exist in D365FO, but since overlaying of standard code is no longer possible, they wouldn't have to exist anymore. Therefore you can ignore them working in D365FO.

    In AX 2012, it doesn't matter much in which layer you're working, as long as you need a single layer only. Sometimes you want to keep things separated (e.g. when you have a VAR partner doing development and you're developing your own changes, or when you put hotfixes to a patch layer, e.g. USP). If you don't need multiple layers, you can happily work in USR. Note that you still can use model to separate things inside a single layer (I prefer always keeping the default model - such as "USR Model" - empty and working in a custom one.)

    As Nikolaos mentioned, you should think about the upgrade impact when changing any standard object. It'll save your time and money when upgrading code (both when applying updates and when upgrading to a newer version). Many companies realized too late than they're unable to upgrade their solution.

  • CBNestor Profile Picture
    CBNestor 46 on at

    Hi Martin,

    Thanks a lot for your answer Martin,

    one more thing. When making an update of AX or patch (I have never been in that process). That means I have to "upgrade code" how is that made.

    does it matter if the code comes from a MS consultant partner(e.g VAR) or a humble developer's custom code in the USR layer, still this code have to be "upgraded"?

    when it comes to patches/updates what is the difference that the customizations comes from the VAR/DEV layer or the USR layer. is there any specific consequences?

    I hope you get me point.

    still grateful from your answers guys, I am understand more of this AX ocean with you everytime

  • Verified answer
    nmaenpaa Profile Picture
    nmaenpaa 101,160 Moderator on at

    About MS updates: All custom code on all customization layers (ISV, VAR, CUS, USR) must be upgraded by someone. If it's ISV, then you would ask for a new version from your ISV. For VAR it might be your VAR partner who does it.

    Also the upgrade must be done one layer at a time, starting from lowest layers.

    About VAR updates: if you get a new version from a VAR partner, then you must compare/merge all your higher layer code against the new VAR layer code. This is because objects on VAR layer might have changed, and if you have some customization on the same object on a higher layer it would hide the new VAR version.

    In other words: whenever there are code changes on lower layers, all higher layers must be "upgraded".

  • Verified answer
    Martin Dráb Profile Picture
    Martin Dráb 237,926 Most Valuable Professional on at

    Imagine that you modify a standard method. It means that a copy of the method was placed to USR layer and you made some changes. If the method changes in a lower layer (e.g. SYP or VAR), the change won't have any effect, because you still have your code in USR layer. You need to manually incorporate the changes to your method in USR layer.

    There is an automatic code conflict detection in AX (it's a part of the code upgrade checklist), which is able to detect these cases. Therefore you don't have to review all code to find conflicts; you'll just need to go through the list of conflicts and solve them.

  • CBNestor Profile Picture
    CBNestor 46 on at

    Hi Guys,

    I am very grateful for your answers really. better explained can not be!

    Just my last question so I can close this thread,

    What about new objects.. Lets say I create new table with not FK to any standard object table. or new classes etc. On USR layer.

    what happens when an update comes?, should it be easier for an update that this code has been written over a standard class(SYS) than creating a new class and then just making a link to the standard (only in USR)?

    hope you get my point. As I said never been in the Update process.

    thanks again for all your time and support guys.

  • Suggested answer
    nmaenpaa Profile Picture
    nmaenpaa 101,160 Moderator on at

    Your own separate objects don't usually need much attention during upgrades. Especially if they have no relation or dependency to standard objects.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
Martin Dráb Profile Picture

Martin Dráb 559 Most Valuable Professional

#2
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 464 Super User 2025 Season 2

#3
Sohaib Cheema Profile Picture

Sohaib Cheema 250 User Group Leader

Last 30 days Overall leaderboard

Featured topics

End-of-life Announcement for Microsoft Dynamics GP

Product updates

Dynamics 365 release plans