A question around Organization Modeling for AX 2012

I hope that you have had a productive week thus far, filled with all things Microsoft Dynamics! As promised earlier this week, I wanted to post today about a specific question that came from my post on AX 2012 - Understanding & Extending the Organization Model.



The question posed by a reader of that post, is around the modeling of their organization for business units, and associating released products to specific Business Units.

Lets take this possed question a little further, and assume that the business unit association is desired to limit the use of released products.



Since released products, with AX 2012 out-of-the-box, are legal entity specific entities, that is the level of separation that comes as offered. Further out-of-the-box, with configuration, you can have business units used as financial dimensions. Meaning that we could then associate a released product, within a legal entity, to a business unit.



Having this association however, would not by itself limit the use of products, for users of AX, that work within specific business units. We have added something new here right? We can associate business units with released products, as financial dimensions. However the new element that we need to try and achieve is limiting the released products in a legal entity by business unit.

Now let us think about this. We could easily jump right into code driven design, that would allow for releasing products to business units, within legal entities. But why do that? The idea with Microsoft Dynamics AX 2012 is to model more and code less.

Our secret to success in this endeavor then, would be to think in terms of modeling. This includes having Organizational modeling that has an operating model, that gives us legal entities, with business units under them. Further having the financial dimensions modeled and configured so that business units are used as financial dimensions. Finally, we need to model security with the use of Extensible Data Security Framework (XDS).



Now with this, I must warn that there are very specific warnings when using XDS for modeling security. The idea is that it would only be used with Master Data elements, according to best practice. With that warning in mind, my next post on this topic will go into greater detail of how this can be achieved with modeling, and minimum code. Till Next Time!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - Using Financial Dimensions when Creating Products

I hope everyone is having a great week so far, and your knee deep into your Dynamics AX projects. I wanted to take a little time this morning, and post a bit about the use of Financial Dimensions when creating products in AX 2012.

I covered the creation of products, using the EcoResProductService, in the following post: Microsoft Dynamics AX 2012 - A Dive into Services, Consuming Document Services



What I did not cover in this post, is around the filling of the DefaultDimension field, from the InventTable object, during the Releasing of a Product to a legal entity, via the InventItemService. Since the time of that posting, I've had a chance to work with this further, and wanted to share, how you would go about, still using these document services, to assign the Default Dimension for a Released Product.



With the understanding we have from the previous post, we need to know understand our starting point for being able to set the Default Dimension value, for a released product. There is a set of classes, that are apart of the AIF class framework within AX 2012, that enable us to build up the default dimension for a specific released products. These are: AifDimensionAttributeValueSet & AifDimensionAttributeValue.

Also as part of this Dimension value set creation process, there is a need to work with the AfStronglyTypedDataContainerList, which is a container for the AifDimensionAttributeValue objects we build up for setting our product dimension values.

So since this is our starting point, we would need to define these, in the header section of whatever method or job is performing the action of releasing creating products. We would then, have something that looked like the following code.:

    // DefaultDimension variables:
    AifDimensionAttributeValueSet               DefaultDimSet;
    AifDimensionAttributeValue                  dimensionAttributeValue;
    AfStronglyTypedDataContainerList            dimensionAttributeValues;

With this, we know have the variables needed, in which we can use, along with the InventItemService for setting our Default Dimensions. Moving forward then, within this concept, and assuming you've already got the code from the previous post, lets work with these objects and see the process of creating our Default Dimensions.

        // Set DefaultDimension data
        dimensionAttributeValues = new  
       AfStronglyTypedDataContainerList(#AifDimensionAttributeValue);

        dimensionAttributeValue = dimensionAttributeValues.addNew();
        dimensionAttributeValue.parmName("Department");
        dimensionAttributeValue.parmValue("SomeValue");

        dimensionAttributeValue = dimensionAttributeValues.addNew();
        dimensionAttributeValue.parmName("Purpose");
        dimensionAttributeValue.parmValue("SomeValue");

        dimensionAttributeValue = dimensionAttributeValues.addNew();
        dimensionAttributeValue.parmName("CostCenter");
        dimensionAttributeValue.parmValue("SomeValue");
        
        invTbl.createDefaultDimension().parmValues(dimensionAttributeValues);

With the above code example, we can see that via the InvTable variable, which represents an InventItem_InventTable object, we can create our DefaultDimensions, as well as fill in the Financial dimension name as well as value. In doing this, we are now able to set default financial dimensions correctly, for products we are releasing to a specific legal entity.

To help with this topic further, Becky Newell, a super star support engineer for Microsoft, gave us an early Christmas Present this past Dec., in which she gives us code example of working with Financial dimensions, for Journal Entries. You can find that post, at the following: Creating General Journals in AX 2012 in X++.

Well thats all I have time for this post, I hope this helps you out, and futher shows the powerfully simple nature of AX 2012, and the ability to work with the infinitely possible financial dimensions that can exists. Till Next time!



Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.


Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - Items & InventItemSetupSupplyType Table

In past post, I've covered the usage of services for performing operations external to AX, as well as internal.

Some examples that have done recently, were focused around Creating Products in AX 2012, via the EcoResProductService.



As well as creating the new Trade Agreements, via PricePriceDiscJournalService.



The point that I've tried to get across in these examples, is to show how this can be done within AX 2012, as well as the same concepts and constructs can be used externally of AX 2012. This is the right move, specifically if your looking beyond AX 2012, and beyond AX7 even.

With this concept, you can also Release Products to a specific legal entity, which is covered pretty well, via a C# example, found at the following resource.: Product-item data management services.

So again, we see how both X++ and C# can use these constructs, Document Services, to create products, as well as release them to a specific legal entity. With this said, there is something missing, for this process.

Specifically, if we look to have our migrated products, that have been released, to show up on the Purchase Order Lines, Item Id field drop down. If we go to do this, and we created products, and released them for use within a specific legal entity, via the services described in the above references, then our items would not show up for use on Purchase Order lines. They can be entered, but do not show up.



The reason this is the case, is because in AX 2012, the Purchase Order Line, Item Id datasource field, has a new lookup() form it uses, called InventItemIdLookupPurchase. This form, has a datasource, that includes the new table: InventItemSetupSupplyType. [InventItemSetupSupplyType Table [AX 2012]]

This new table, contains sourcing information, related to the Item that is being released to a specific legal entity. When this release takes place, the AX Rich Client UI, will fire the EcoResProductReleaseManager object that has logic which creates a default entry into the InventItemSetupSupplyType table, with a Default Order Type of Purchase.

When creating products and releasing them through the services, specifically for the InventItemService, [InventItemService Class [AX 2012]], it makes use of the AxdItem Query object in AX 2012, in order to create records via.



Since this is the case, and we can see from above that the InventItemSetupSupplyType table does not exists as a datasource, then when creating records via this design concept, will not satisfy the requirement of adding entries into the new table, of InventItemSetupSupplyType.

Therefore, there is a small disconnect between the UI release process, and the document service approach for creating and releasing items. This is a simple fix however, either invoke similar code, found in the EcoResProductReleaseManager class for the createInventItemSetupSupplyType() method. Or the other option, could be to add the datasource, to the AxdItem query, for the InventItemSetupSupplyType table, and regenerate the InventItemService, document service, so it will reflect the new entity within it's WSDL.

Depending on the scope of what your doing, should guide you on which choice you make here. If it's throw away, migration code, the simple, fast option of just invoking the X++ code that lives within the EcoResproductReleaseManager class would be advised.

However, if your doing a longer, value add modification, or integration, then, looking to modifying the InventItemService, via the AxdQuery object should be considered.

Well I know that's a little deep dive, on something very specific, however such deep dives are warranted at times. I believe, it's important to understand this, from a process point of view, but also see the value in showing choice. The ability to solve a need, there is multiple ways. Depending on where the most value is, should guide your choice, for the design and the development of answering a specific scope need.

That's all for now, but check back soon as a whole lot more to come. Till next time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012 - A Dive into Services, Consuming Document Services

With the release of Microsoft Dynamics AX 2012, one of the topics I have been spending a lot of time talking about is around services. There is good reason for this, and we will continue to dive deeper and deeper into the concepts, the reasons for use, and examples of use.

Last I left off, we covered topics related to Custom Services. In this post, I want to take and cover concepts around the consumption of document services.

As I referenced in a previous blog post, there is a great write up already, that covers the technical steps needed to show off how to consume document services, specifically around the Product Data, or the EcoResProductService.

This write up, found here: Product-item data management services, focuses on the consumption of the EcoResProductService, among others, for creating product data, and even releasing that into a given legal entity. Since this is a very nice write up, I will not focus this post on repeating the same effort.

Instead, what I want to focus on, is consuming the EcoResProductService, from within X++, from within AX, for creating Product Master Data. So lets jump right into this.

First thing that we need is an instance of AX 2012, and a project. We will then need, within that project, a custom service group to deploy the out-of-the-box EcoResProductService via. After that, we will need a class, to contain the business logic, and finally for our example a job that kicks off that classes method, and therefore logic for creating our Product Master.



As you can see, from the above image, we have just that for our example. Now since there is nothing we need to really do to the EcoResProductService, lets move into the business logic for creating a Product Master record.

First we need to start with the variables that will be involved in, enabling this.:



You will notice, we have an EcoResProductService variable, which is used to perform the operations that are enabled for a given service, in this case document service, and for our need the create() function.

Next you will see we have a variable that presents the EcoResEcoResProduct object. This is what the EcoResProductService will accept in it's create call that we will see in a bit. This class extends from the AifDocument class, as you can see from the below image.



After that, we have EcoResEcoResProduct_Product_Master class, which is extends from the EcoResEcoResProduct_Product class, which further extends from the AfStronglyTypedDataContainer. You can see this as well, in the image below here.



From there we have variables that represent the EcoResEcoResProduct_Translation, EcoResEcoResProduct_Identifier & EcoResEcoResProduct_ProductDimGroup objects. All of which are used to help make up an EcoResEcoResProduct_Product_Master object.

Now all of that is a mouth full! The point is, we have, in order to work and create Product Master entries, via the Document Services concept, is six objects. These six objects in our example abstract the complexity of the new EcoResProduct data structure, and enable within AX for business logic to move away, from even working directly with the table objects within AX itself. This is very powerful, and very useful.

Now lets move forward, since we have an understanding of the objects that will enable us to create a Product Master record, and look into the code that enables this.



First part of the code, we see in the above image, our logic that initializes the service for use. Then we move towards creating a new instance of the EcoResEcoResProduct object. After that we are creating our Product Master object, and finally filling some of it's parameters, via the use of parameter methods, with values.



Next we are making use of the objects that make up our Product Master object, in the ProdMast variable, for creating the needed: Translation, Identifier and for our example the Product Dimension Group.

You will notice that the code to enable this is ProdMast.createTranslation().addNew(); In doing this, and for the other examples this is true as well, we are creating a new instance of the Translation object, and adding it to the AfStronglyTypeDataContainerList that is represented for the ProdMast variable.



Finally, we come to the bottom of the code block for this business logic, and see we are setting the Variant Configuration Technology. Then adding our ProdMast object to the Strongly Type List for the EcoResProd variable. Finally calling the create method of the service object, passing in our ProdMast variable.

On calling this logic, we get our Product Master record, as shown below.:


So with a total of 17 lines of code, and 6 objects, we are working with Document Services from within AX 2012 itself, and creating Product Master data, without having to work directly with the table objects themselves.

This can then lend itself to be re-used over and over again, and finds value in integration work, as well as data migration. You can also, now take and compare the differences between C# and X++ code for using these document services. They are similar, in theory, but different in syntax and possible approach of course.

That's all I wanted to cover for this series, and for the introduction to services in AX 2012 this just about wraps things up. I plan on doing a summary post, bringing together all the work I've done, all the work Microsoft has done, as well as other community contributors. Till next time!



"Visit the Dynamics AX Community Page today!"

Dynamics Community Article - Master Data Management & Microsoft Dynamics AX 2012

With the release of Microsoft Dynamics AX 2012, a lot of great concepts comes along with it. There are some really great technical things, but this release has been quoted to have more functional adds, than all the major releases of AX combined.

One of these concepts, one that I seem to continue to have a lot of conversations about, is around Master Data Management (MDM). To this end, I thought it would make for a great article, on my guest column for the official Microsoft Dynamics Community site.

Here is a direct link to that article: Master Data Management & Microsoft Dynamics AX 2012

I think for sure it's a timely piece, and of course I welcome plenty of debate, comments, thoughts around all of this. The article expresses my view, of Master Data Management, and gets into the when the context and value makes sense, for using a tool like Master Data Services. Enjoy!

Till next time!



"Visit the Dynamics AX Community Page today!"

Product Management with Microsoft Dynamics AX 2012 - Part IV

I hope everyone had a great long weekend, and that you got a lot of rest, and ready to tackle the short week ahead.

Today, I wanted to post the final part IV, of Product Management with Microsoft Dynamics AX 2012, from guest blogger Brad Edwards. The following is a list of the previous parts of this four part series.:

• Product Management with Microsoft Dynamics AX 2012 - Part I
• Product Management with Microsoft Dynamics AX 2012 - Part II
• Product Management with Microsoft Dynamics AX 2012 - Part III

So far, Brad has really taking us into a good deep dive into some of the great new features around Microsoft Dynamics AX 2012 for Product Data Management (PDM) / Master Data Management (MDM) for products.

Brad wraps up his guest series, with taking us through intercompany implications, Product management for smaller organizations, as well as some closing thoughts. So, lets here what Brad has in store for us here.:


Intercompany implications

In previous versions, items must be carefully setup to be transacted via intercompany sales and purchase orders. With the release of AX 2012’s product hierarchy structure Released products are tied to one another via the Product number, eliminating the need for Company items setup, or External code setup to link items between companies.

Released products may still have different names in different companies. The Released product’s Item number may be changed by using the Record info > Rename function.

While this greatly reduces the time required to setup products for intercompany use, there are some potential drawbacks. As this is the only way to link Released products for intercompany use, it is no longer possible to link a Released product that is tracked by certain product dimensions in one company to a Released product that is not tracked by product dimensions in another company.

For example, if company A sells t-shirts in red, green, and blue under item number TSHIRT with color dimensions Red, Green, and Blue, and company B buys the t-shirts under the item numbers TRED, TGREEN, and TBLUE, AX 2012 will not support this type of setup. So it is important to consider the implications of the new product structure on intercompany processing for the organization in question.

Product management for smaller organizations

Thus far, all of the information discussed has assumed the creation and management of products at the instance level, and the release of products to individual AX companies. However, this structure would provide a large amount of overhead in smaller, single company organizations. However, the capabilities exist for users to create Released products directly in the Released products form. The user may do so by clicking the New Product button in the ribbons section of the form:



As with products at the instance level, the user must still specify the Product number, Product type, and Product sub-type so that the product may be created in the Products table. This method of Released product creation is much more suitable for smaller organizations that wish to manage products in a simpler manner.

Technical note

Thus far, the entire article has focused on the functional changes to the way in which products are managed. However, for the slightly technical users, there are some important technical changes to note. AX 2012 now makes use of table inheritance. This means that fields that appear on the Products form may not actually be on the products table, but on a parent table that the products table extends. Without going into too great of detail, it is important that functional users reference screenshots rather than table and field names when completing functional specs, to eliminate confusion during development.

Closing note

While this article has merely scratched the surface, its intent is to provide a high-level overview of the changes to come in the area of Product management in Microsoft Dynamics AX 2012. It is important to note that the release from which this article was written was based on a public beta instance, and there is still the potential for changes to be made. I hope that you all have found this information useful. Enjoy working with AX2012!


Well I would like to thank Brad for taking us through Product Management review, for Microsoft Dynamics AX 2012. It's hard to work in writing to a already very busy schedule, and so thanks Brad!

From here, we will continue to dive into Microsoft Dynamics AX 2012, including diving deeper into some of the topics touched on in this series of blog post. For example taking and doing some real comparisons, with impact, for orgazations of varying sizes, and how PDM would be different for each.

That's all for now, but check back soon as more to come! Till next time!

"Visit the Dynamics AX Community Page today!"

Product Management with Microsoft Dynamics AX 2012 - Part III

I hope everyone is doing well today, and that your thankful for having another day. I know I am! With that, we continue to dive into Product Management with expert Brad Edwards. This is part III in the series, you can read the first two here.:

• Product Management with Microsoft Dynamics AX 2012 - Part I
• Product Management with Microsoft Dynamics AX 2012 - Part II

In this next installment, Brad dives into Product Variants release as well as Release Product Management.



Product variant release
Once product variants have been created at the instance level, they must be released to individual companies before transactions may be performed in the respective company.

Variants may be released from any of the Products forms (All, Distinct, Product masters), or from the Product variants form by clicking Release products in the ribbon section of the form. This launches the Release products form:



The user will first select the product variants that they wish to release. This is done in the Product variants section for Product master releases, and the Products grid for Distinct product releases.

NOTE: before Product variants can be released for a Product master product, the Product master must be released. This is performed by checking Include product master in the Product variants section.

The user will then click Select companies.



Here, the user will select each of the companies to which the selected products are to be released, and click OK at the bottom of the form.

Any errors that occur may be viewed on the Open product releases form, accessible from Product information management > Common forms:



The user has the ability to view and infolog for each release issue. Once issues have been resolved, the products may be released directly from this form, or the open releases may be removed.

Released product management
Up to now, we have discussed management of products at the instance level. Users in all companies will see the same records in the Product master forms.

Once products have been released, they can be managed within the individual companies by going to Product information management > Common > Released products. This is the AX 2012 company specific item master. Here, the user will only see products and product variants that have been released to the AX company within which they are currently working. The form looks similar to the products form, but much more information can be stored for each Released product.



Much of the information that was setup at the Product level can also be setup at the Released product level. However, there are several fields which, if setup at the Product level, may NOT be changed at the Released product level. The most notable cases of this type of behavior are the Storage dimension group, and the Tracking dimension group.

As with the Product dimension groups, Storage and Tracking dimension groups specify which dimensions are active for the Released product.

As mentioned earlier in the article, Storage and Tracking dimension groups are not required at the Product level. However, if they are specified on the Product, they will default each Released product, and may NOT be changed at the company level. This means that if Storage dimension group were specified for our testProduct product such that site and warehouse were the only active dimensions, then these settings will apply to all companies in which the product will be used. If it desired to maintain different Storage or Tracking dimensions in different companies, then these fields should be setup for each Released product in their respective companies.

Before Released products can be transacted upon within a company, several additional fields must be setup for the Released product:

• Item model group


• Storage dimension group


• Tracking dimension group

Item model group may be specified by clicking Edit in the ribbons section of the form, and changing the value in the Administration section of the form:



The two dimension groups may be modified by clicking Dimension groups in the ribbons section of the form:



If these three fields are not setup, a user will receive an error if trying to create a transaction for the newly Released product. This, however, is a nice improvement from previous versions of AX, where it was necessary to specify this information upon creation of the product. In actuality, the product designer may have no insight as to:

• How the Released product should be costed


• Whether or not physical updates should be posted to the general ledger


• Which WMS strategy should be used


• How reservation logic should occur


• Whether or not the Released product should be lot traceable or serialized

By eliminating the need to specify this information upon product creation, AX has now opened the window for product creation workflow capabilities that did not exist in the past. For example, a possible workflow may be setup such that product managers or engineers design and create the product, accounting specifies the necessary financial information, the warehouse manager specifies the necessary storage dimension group, and the quality manager specifies the necessary tracking dimension group.

One field that was not mentioned in the previous section is the Item group. In AX 2012, Item group may only be specified at the Released product level. However, Item group is no longer a required field. This is a very important change, as it affects the use of inventory posting profiles. While posting profiles still work in the same manner (Table/Group/All), if the Released product does not have an Item group specified, AX will skip the second option, and revert directly to the All items posting profile.

This means that it is very important to consider whether or not an All items posting profile should be used, as it could result in incorrect postings to the ledger. For example, if an All items posting profile is setup to post to the raw materials inventory GL account, and a user fails to specify an Item group for a newly released finished good, transactions will be incorrectly posted to the raw materials account. While this scenario exists in previous versions in the case where a user specified an incorrect Item group, it may be much more likely to occur, as Item group is no longer mandatory.

Now that all required pieces of information have been specified for the Released product, the product may be purchased, inventoried, and sold as defined by all of the specified properties.

Once again, I would like to thank Brad for the continued effort in giving us great insight into what's waiting for us with Microsoft Dynamics AX 2012, relating to Product Management.

This shows off the power of Microsoft Dynamics AX 2012, around Master Data Management (MDM) & Product Data Management (PDM) concepts. All companies need a good plan for this, and it's a very important topic.

That's all for now, check back soon as more to come! Till next time!

"Visit the Dynamics AX Community Page today!"