Updating Default dimensions -- the best possible way

 

Ever come across a situation, where you needed to update the default financial dimensions, runtime? Suppose you have sales lines, and they dimensions like [Costcenter-purpose-department-Employee]. There is a requirement, that asks you to update: depending on certain situations, the dimension code on 'Purpose' needs to be changed. This sorta requirement is quite common, and I bet you have confronted several situations like this, before.

Even a few versions of D365FO this, was damn easy. There was this function, which can let you change twitch between any Fin. dimension values:

 ledgerDimensionDefaultFacade::serviceReplaceAttributeValue(SalesLine.DefaultDimension, InventTable.DefaultDimension, DimensionAttribute::findByName("ProdLine").RecId);

But this method has changed and it looks like the following:

dimension = LedgerDimensionDefaultFacade::serviceReplaceAttributeValue(

                        _defaultDimension,

                        _dimensionDefaultMap.DefaultDimension,

                        dimensionAttributeRecId);

Whereby you have to generate a new dimension and then assign it to the original dimension.

Oh Rama....there could be sheer chances of again the structure of this method getting changed and we have to refurbish our code again.

Here is a pretty easy-to-use code, that can help you anytime to replace any dimension value with a new one -- regardless of whatever changes happen to any of these underlying Dimension classes.

private DimensionDefault updateDefaultDimension(SalesLine   _salesLine, InventLocationId  _newLocationVal)

    {

        DimensionDefault        fromDimensionDefault = _salesLine.DefaultDimension, 

                                toDimensionDefault;

        DefaultDimensionView    defaultDimensionView;

        Map                     mapDimvalues = new Map(Types::String, Types::String);

        Counter                 repeats = 1;

        

        while select DisplayValue, Name from defaultDimensionView

            order by RecId asc

                where defaultDimensionView.DefaultDimension == fromDimensionDefault

        {

            if (repeats == 1)

            {

                mapDimvalues.insert(defaultDimensionView.Name, _newLocationVal);

            }

            else

            {

                mapDimvalues.insert(defaultDimensionView.Name, defaultDimensionView.DisplayValue);

            }   

            repeats ++;

        }


        DimensionAttributeValueSetStorage   valueSetStorage = new DimensionAttributeValueSetStorage();        

        MapEnumerator                       dimValEnum = mapDimvalues.getEnumerator();

       

        DimensionAttributeValue             dimensionAttributeValue;


        while (dimValEnum.moveNext())

        {

            DimensionAttribute  dimensionAttribute = dimensionAttribute::findByName(dimValEnum.currentKey());

            if (dimensionAttribute.RecId == 0)

            {

                continue;

            }

            DimensionValue dimValue = dimValEnum.currentValue();

            if (dimValue != "")

            {

                dimensionAttributeValue = dimensionAttributeValue::findByDimensionAttributeAndValue(dimensionAttribute, dimValue, false, true);

                valueSetStorage.addItem(dimensionAttributeValue);

            }

        }

    

        toDimensionDefault = valueSetStorage.save();


        return toDimensionDefault;

    }

Here, as per our business need, I needed to change the first dimension (i.e.: cost-center from CostCenter-Purpose-Department-Employee-Region combination) with a new code. That's what the 'if (repeats == 1)' check is doing. You can change it to any value you want, depending on the which dimension value you want to update (3rd/4th/5th and so on). The all-time favorite 'DefaultDimensionView ' holds all the records of any given dimension combination (field DefaultDimension) which we can loop through as per our requirement. 


Comments

Post a Comment

Popular posts from this blog

Make your menu items visible on main menu, conditionally,, using this cool feature of D365FO

Image
  Wassup guys? I am sure you must have encountered this situation where you needed to display your menuItems, on main menu, based on some condition, haven't you? This was only possible by using config keys and flights. Things get a bit tricky,  when suppose you have a requirement like this: you need to make it dynamic, by introducing a toggle switch on a field on a paremeter form.  Suppose on Accounts Receivables Parameters >> You have a field called ' Show US customer '. You have a requirement that says when you turn on this toggle, then only the menuItem ' Input SSN details ', under AR module. This is now highly acheivable by leveraging subscription to 'SysMenuNavigationObjectFactory' class, simply by saying a. Create a new class USMenuItemsVisibilityManager b. Copy the following method, with proper documentation (don't change signature/anything else) [SubscribesTo(classstr(SysMenuNavigationObjectFactory), staticdelegatestr(SysMenuNavigationObjec...
Read more

X++ : mistakes which developers commit the most

Image
   The most important thing is to remember where and when to write the code. a. Developers have an inherent habit of writing erratic select statements: select * from custTable where custTable.AccountNum == <SomeValue> Where in essence we need to make use of optimized choice of fields in the select statement. b. Making use of 'continue' keywords: While select custTrans where <someConditions> { if (cusTTrans.CustGroup != mappingTable.CustGroup) { continue; } } 'Continue' statements are precisely a very unhygienic way of designing your code. The above statement could have been easily ornamented by using exists/not exists joins. Using Continue statements would eventually result in a high performance impact. Also select statements should be made punctuated with a 'firstonly' clause -- just not from best practise standpoint, but also from performance considerations. c. Writing nested loops: This is a common mistake that perha...
Read more

Are you still using macros? Be sure you read this.

Image
  You still use a lot of macros in your code, don't you? Of course you should: Macros, as per Microsoft,  are p recompiler directives are processed before the code is compiled. The directives declare and handle macros and their values. The directives are removed by the precompiler so that the X++ compiler never encounters them. The X++ compiler only sees the sequence of characters written into the X++ code by the directives. However macros, are not quite recomended by Microsoft. They are slow, they can be subsequently deorectaed at any later time.  The Macros are  actually  a type of classes, only that they are not instantiated and not need be defined as classes. Hence runtime garbage collection could be a huge issue, consquently (a class when gets out of scope, gets garbage-collected owing to the destructor classes of DOT net instrumentation classes). Summing up, macrros are a bit old way of writing code. Use static classes instead. public static class MyIdenti...
Read more