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:
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.
Your own separate objects don't usually need much attention during upgrades. Especially if they have no relation or dependency to standard objects.
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.
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.
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".
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
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.
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!
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.
André Arnaud de Cal...
291,965
Super User 2025 Season 1
Martin Dráb
230,817
Most Valuable Professional
nmaenpaa
101,156