• Home
  • About
  • Contact
  • German

Dynamics 365FO/AX Finance & Controlling

Dynamics 365FO/AX Finance & Controlling

Monthly Archives: August 2017

Cost accounting (7)

22 Tuesday Aug 2017

Posted by Ludwig Reinhard in Cost accounting

≈ 2 Comments

Tags

Controlling, Cost accounting module, Cost center accounting, Formula based allocations, Management Accounting

In the previous post, the costs that have been accumulated on the indirect cost centers no. 110, 120 and 130 were allocated to the other cost centers based on amounts that have been recorded on selected cost elements (ledger accounts 851000 and 852000).

Within this post, we will investigate an alternative, formula-based allocation method that allocates the costs of the indirect cost centers (based on the amounts that have been recorded on multiple cost elements) to the operative cost centers no. 210-250.

As in the previous post, the allocations will be made based on the following accounting data that have been recorded in the finance modules.

To implement the formula-based allocation approach, a formula allocation base needs to be setup first. Setting up this allocation base requires first that an association to the existing predefined allocation bases is made (1). In the example shown below, all cost elements (ledger accounts) that have been used are simply selected and associated with an abbreviated alias.

Once the association to the predefined allocation bases is made, the formula that calculates the allocation base is defined in a second step (2) by making use of mathematical operators.

Currently, the following mathematical operators are available for specifying allocation based formulas.

The next step consists of defining the allocation policy; this time, by specifying that the costs of the indirect cost centers no. 110, 120 and 130 shall be allocated to the other operative cost centers (no. 210-250) based on total direct costs. This is realized by associating the previously defined formula allocation base to the indirect cost centers and is illustrated in the next screenprint.

Once the allocations are processed – not shown for reasons of brevity; for details, see the prior post – the following costs remain at various cost centers:

From the screenprints shown above, one can identify that the costs of the indirect cost centers no. 110, 120 and 130 have been cleared. However, different from the previous post, more allocations are made. Take cost center 110 as an example, which does not only allocate its own primary costs ($32000) to the other cost centers but also the secondary costs it receives from the other operative cost centers ($626.01 from the car pool cost center and $1841.20 from the product management cost center).

Executing such kind of allocations necessitates the use of an iterative approach that allocates the costs of the indirect cost centers several times until all costs are allocated to the operative (‘direct’) cost centers no. 210-250.

The next Excel document summarizes the different allocations made and highlights the fact that allocations are not only made from the indirect cost centers (110-130) to the operative cost centers (210-250) but also within the group of indirect cost centers.

In the first post on the cost accounting module it was mentioned that cost allocations can also be made in the General Ledger (GL) module by making use of the allocation functionality. The GL allocation functionality suffers, however, from the fact that it cannot handle iterative cost allocations as the cost accounting module can. For complex allocation scenarios, the cost accounting module is thus the one to go for.

In the next post we will take a look at a third alternative allocation scenario that makes use of statistical measures for allocating costs. Till then.

Cost accounting (6)

13 Sunday Aug 2017

Posted by Ludwig Reinhard in Cost accounting

≈ Comments Off on Cost accounting (6)

Tags

Controlling, Cost accounting module, Cost center accounting, Management Accounting, Predefined dimension member allocations

This and the following posts will focus on the second pillar of a classical cost accounting system – the cost center accounting pillar. As mentioned in the previous posts on cost accounting, the cost center accounting system associates costs to its origin. The next figure illustrates this association for different kinds of costs (illustrated in the first column) with its origin cost centers.

Because the first three cost centers no. 110, 120 and 130 support all the other operative cost centers, the costs that have been accumulated on the supporting cost centers shall be allocated to the other ‘direct’ or ‘operative’ cost centers.

Within this post, the total direct costs of the supporting cost centers will be allocated to the operating cost centers (no. 210-250) based on the amounts that have been posted on other ledger accounts (cost elements). The next posts will show other, alternative allocation methods and provide a comparison with the allocations that will be generated in the following.

 

Before costs can be allocated, the different cost elements need to be specified first in the cost element dimension form. In the example used, the primary cost elements were transferred from the General Ledger’s Chart of Accounts (CoA) whereas the secondary cost elements (‘Allocation 110 Supplies’, ‘Allocation 120 Car pool’, ‘Allocation 130 Product management’) were created manually in the cost accounting module to track cost allocations in detail.

The second required setup for running cost allocations concerns the cost objects; in the example used, the cost centers, which were also transferred from the D365 ledger modules. For details, please see the following screenprint.

Once cost elements and cost objects are defined, they can be classified in cost element and cost object dimension hierarchies. The set up of those hierarchies is illustrated in the next figures.

The next setup relates to the cost allocations that shall be executed. Those cost allocations are set up in the cost allocation policy form, which is exemplified below.

 

In the cost allocation policy form that is illustrated above, the costs of cost center ‘110 Supplies’ are allocated to the other cost centers based on the amounts that have been posted on ledger account (cost element) 851000.

Similarly, the costs of the other supporting cost centers ‘120 Car Pool’ and ‘130 Product Management’ are allocated to the other cost centers based on the amounts that have been posted with ledger account (cost element) 852000.

With the so-called spring release that became publicly available in July 2017, additional predefined allocation bases became available. The next screenprint illustrates some of those predefined allocation bases, which comprise main accounts, cost elements and statistical elements that have been imported into the cost accounting module.

To identify the cost allocations made, a cost rollup policy is set up in addition to the previously shown cost allocation policy. Cost rollup policies establish a linkage between the cost object from where the costs are allocated from and the secondary cost elements that detail the cost allocations for the various cost objects.

Cost allocation and cost rollup policies do not allocate costs without being assigned to a cost accounting ledger. For that reason, a cost accounting ledger is set up next.

Please note that the arrows shown in the cost allocation and cost rollup policy forms identify the button through which the association between the policies and the cost accounting ledgers is made.

Similar to what has been shown in prior posts on the cost accounting module, the cost accounting ledger needs a linkage to the cost elements, the cost element hierarchy, cost objects and the cost object hierarchy, which is exemplified in the next figures.

After the cost accounting ledger is setup and after the source data are processed – for details, please see the prior posts – the cost allocation can be executed through the overhead calculation button.

For the illustration of the cost allocations in the cost controlling workspace, the workspace needs to be setup first. This set up is illustrated below.

 The only major difference in the setup of the cost controlling workspace to what has been shown in the prior posts is that a linkage to the overhead calculation version needs to be made. This is indicated by the arrow in the previous screen.

 

Once also this is made, the cost object data can be analyzed in the cost controlling workspace. The next screenprints document the obtained results.

For a better overview, the allocated costs data are summarized and highlighted in the following Excel document.

In the next post, we will take a look at an alternative cost allocation methodology that allocates the costs of the supporting cost centers based on the total direct costs recorded on the other cost centers. Till then.

Cost accounting (5)

05 Saturday Aug 2017

Posted by Ludwig Reinhard in Cost accounting

≈ Comments Off on Cost accounting (5)

Tags

Combine Data from different companies, Controlling, Corrections, Cost accounting module, Management Accounting

Within this post, we will focus on another two cost accounting topics that are related to the first pillar of a classical cost accounting module before we move on to the second pillar and take a deeper look at the cost center accounting features.

 

Part 1: Corrections
Sometimes it is necessary to make corrections to the data recorded (transferred) to the cost accounting module. As an example, let’s assume that $150 taxi costs that are posted in combination with the admin cost center no. 400 do actually belong to the sales cost center no. 500.

In the ‚old’ cost accounting module, cost accountants could simply correct such errors by making use of cost accounting journals that did not have an influence on the financial accounting system. In other words, adjustments that were made in the cost accounting module had no effect on the other finance modules.

With the new cost accounting module, this option is no longer available and necessary changes to transferred accounting data must either be made by importing adjustment transactions through data entities directly into the new cost accounting module or – better – by recording adjustments in the originating finance modules.

 

Part 2: Combine data from different companies
The previous (old) cost accounting module was limited to a single company and could not analyze data originating from different companies. This has been changed in the new cost accounting module, which allows analyzing data from multiple companies that are either setup in D365 or that use other (external) ERP systems.

Within the following, we will have a look at a simplified example where financial data from two companies (DEMF & USMF) will be analyzed together. To understand and follow the example, please note that the two companies use different Chart of Accounts and different currencies. The financial data used for the following illustrations can be identified in the next figure.

To get the financial data analyzed together, three cost element dimensions need to be specified:

  • The first one (CA_CostElements) has already been used before and holds the main accounts/cost elements from company USMF
  • The second one (CA_CostElements2) holds the cost elements that were previously imported and that will be used for the combined analysis of the data.
  • The last cost element dimension illustrated in the previous screenprint holds the main accounts/cost elements that originate from company DEMF.

Because the second cost element dimension will be used for the combined analysis, the DEMF and USMF cost elements need to be mapped to this dimension. The next screenprint exemplifies this for the DEMF cost elements.

Once the different cost elements are mapped, a cost element dimension hierarchy needs to be setup because it is required for the configuration of the cost accounting ledger.

The cost accounting ledger refers then to this cost element dimension hierarchy and the cost control units (cost centers). As the setup of the cost control units is identical to what has been shown in the previous posts, reference is made to those previous explanations to conserve space.

The next required setup step consists of configuring the data provider for the cost accounting ledger, which is necessary for getting the cost accounting data transferred to the cost accounting ledger. Because two companies are now connected to the cost accounting ledger, two data provider need to be specified. This is illustrated in the next screenprint.

 Please note that the data providers need to be configured in a way that they refer to the cost element dimensions of the specific entity.

Once the configuration is made, the data can be imported into the cost accounting ledger as shown before. The next step is then the setup of the cost controlling workspace, which links the control unit, the cost element and the cost object hierarchies.

After the cost controlling workspace is setup, the combined business data can be analyzed, as exemplified below.

 Please note that an exchange rate of 1 EUR = 2 USD has been used for the currency conversion of the EUR data in order to consolidate them into the combined USD data that are illustrated in the cost controlling workspace.

 

This post ends the series on the first pillar of a classical cost accounting system – the classification of a company’s costs. The previous posts showed that also the new cost accounting module allows classifying costs according to their behavior (fixed vs. variable), their nature (primary vs. secondary) and by functions (admin, travel, etc.). Compared to the previous cost accounting module, users have more options in regards to the data that can be analyzed in the new cost accounting module (cross-company & integration of posting layers). Those enhanced options come, however at the price that additional / more complex setups are required.

The following posts will investigate how cost center accounting functionalities are supported in the new cost accounting module. Till then.

← Older posts

Communities4Future

Dynamics UserGroup Deutschland

Project Accounting Book – Part 2

Project accounting book

Categories

  • Accounts Payable
  • Accounts Receivable
  • Bank Management
  • Book reviews
  • Budgeting
  • Cost accounting
  • Fixed Assets
  • General Ledger
  • Inventory
  • Management Reporter
  • Miscellaneous
  • Podcast
  • Project
  • Sustainability
  • Uncategorized

Tags

Advanced bank reconciliation Allocations Bank reconciliation Budgeting Controlling Cost accounting Cost accounting module Cost center accounting customer D365 D365FO Dynamics AX Dynamics AX 2012 Electronic reporting Email Environment Fixed asset statement General Ledger journal Global Warming indirect costs intercompany Inventory Inventory reconciliation invoice invoice recording IOT Management Accounting Management Reporter Modern Finance MS Flow MT940 PowerApps PowerAutomate PowerPlatform Project Project module Purchase Order Resource scheduling Sensor settlement SharePoint Sustainability Sustainability Accounting Tax time recording timesheet Vendor invoice recording Vendor payments WBS workflow

Important Websites

  • Dynamics AX/365FO Links

Legal

  • Disclaimer

Subcribe

  • RSS - Posts
  • RSS - Comments

Enter your email address to follow this blog and receive notifications of new posts by email.

Archives

  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

Blog at WordPress.com.

  • Follow Following
    • Dynamics 365FO/AX Finance & Controlling
    • Join 569 other followers
    • Already have a WordPress.com account? Log in now.
    • Dynamics 365FO/AX Finance & Controlling
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...