Learn Dynamics 365 Finance and Operations(Axapta)

 After you've successfully applied the update in the sandbox environment and are ready to move the update over to the production environment, follow these steps to mark an update as a release candidate. 1. Open the environment history page by selecting History > Environment changes on the environment details page. 2. Select the update to move over to the production environment. 3. In the details for the update, select Mark as release candidate. The Is Release Candidate option is set to Yes. After you've marked an update as a release candidate, follow these steps to update your environment. 1. Open the environment details page for the production environment. 2. Select Maintain > Update environment to apply an update. 3. In the Available sandboxes list, select the source sandbox environment where the update was applied, validated, and marked as a release candidate. 4. In the grid, select the update to apply to the production environment. This grid shows only u

Nice post my Rachit Garg https://brewingthought.com/2021/09/27/converting-database-from-tier-2-bacpac-to-tier-1-bak-on-new-developer-vm-released-with-10-0-21/

N avigate to   System administration > Setup > Office app parameters. In the App parameters fast tab, click  Initialize app parameters button App Parameters will be initialised In the Registered applets fast tab, click  Initialize applet registration button . Registered resources will look like this             Settings for store type - office store ·        App ID : WA104379629 ·        Store : en-US ·        Store Type : Office Store Settings for Store Type centralized deployment ·        App ID : 61bcc63f-b860-4280-8280-3e4fb5ea7726 ·        Store : EXCatalog ·        Store Type : Centralized Deployment

Today we will talk about the objects' IDs and SQLDictionary table from SQL Server. Each object in AX (mainly classes,  tables and the columns, with the emphasis placed on tables and columns right now, since that is what gets committed in SQL Server) gets an ID in order to identify them. In AX 2012 the ID is allocated at the moment of the object's creation in the ax system (either through a xpo import, new object in AOT, or model import). Now, how does AX works with the tables in the SQL Server? The system will take the definition in the AOT and will commit that (the columns, their name, lenght, type) in SQL. So far, everything is going ok, but how is AX keeping track of what it has in the SQL Server? Matching the names of the objects would be enough? Let's see.  A table in SQL could be matched by it's name in the AX AOT. So, imagine that there is a change in a table's name, or easier, for the moment, a table column's name, going from colA to colB. The table, on

Do not place code in a form unless you cannot place it in a class or in a table method. Code written on forms cannot be reused and is difficult to customize. A class that processes all the logic in a form should have the same name as the form with "Form" as the suffix. If you have a complex form, create a class for server-related tasks. This class should have the same name as the form, but with "Server" as the suffix. If you have code in the form, the code should be for making only simple changes to the appearance of the form or to the form’s query. Try to place the code on the form or on the data source. Place code directly on controls only when you are absolutely certain that there is no other solution, and then use the AutoDeclaration property on these controls. Reasons for Removing Code from Forms ·         Forms are entirely client-based. There should be no code in them that manipulates the database (business logic). The code should be removed from t

If you are a senior developer on Dynamics AX, you may wonder how come these issues still exist. This is the reason why I decided to write this article. Developments are now shared among diverse team, sometimes across multiple partners and outsourced to vendors, meaning different skills and processes. Therefore such well known issues still remain in production when customized best practices rules and internal review are not properly defined. The following list is not exhaustive and is only based on our experience from the field. 1. Wrong caching leads to unnecessary database calls This is one of the most fundamental feature of the product today. The three tiers architecture of Dynamics AX allows you to define caching on AOS and client. Not using caching properly is the first root cause for performance. Make sure the following rules are defined: All your customized tables have relevant table group defined in AOT. For example, master data should have “Main” category and transact