In this post I will show you how you can inform people about newly setup ledger accounts in D365FO. Even though Alerts and MS Flow triggers are currently not available for D365FO, you can make use of the standard D365FO functionalities and MS Flow to send notifications to those who are for example responsible for setting up reports to ensure that they don’t miss newly setup ledger accounts.
This video post shows you how you can attach documents such as a dunning letters to Emails that you send out to customers. If no Email is provided a document is automatically printed and can be send by letter post. In case an invalid Email address was setup, the bouncing Emails are tracked through MS Flow and other products of the MS stack. All the things shown in the video can be achieved in the D365FO standard application in combination with products from the MS stack without making any system modification. Hope you enjoy and see you next time.
Inspired by a previous post of my follow MVP colleague Fredrik (see: https://dyntips.com/2017/08/02/data-validation-checklist/) I decided to take a closer look at the data validation checklist functionality
(a) for checking that all necessary system setups are made and
(b) for establishing a data migration or cutover plan, which helps ensuring that nothing important is forgotten before going live with D365FO.
Once the project was created, I started with the setup of the task areas, which can be realized by opening the configuration menu shown next.
While setting up those task areas, I noticed that this setup can easily become a lengthy and time-consuming process. Luckily, D365FO ships with a handy Excel add-in that alleviates the setup of those task areas. For details, please see the following screenprint.
The task areas can be setup in numerous ways. I decided to use the different D365FO modules as my task areas. If you want to follow the same approach, you can download the attached SampleGoLiveChecklistTaskAreas Excel File and use it for importing the task areas in your environment.
After the task areas are setup, the legal entities need to be specified …
… before the tasks can be setup. Setting up the data validation checklist tasks is the core of the data validation functionality. When setting up those tasks, you need to take the elements highlighted in the next screenprint into consideration. In the following, the highlighted elements will be explained in more detail.
No 1: Task
Here you have to provide a task description that you can freely define.
No 2: Area
This field allows linking the tasks to the task areas that have been setup before.
No 3: Menu item name
The menu item name allows you establishing a link to the setup form. Once this link is established, users can directly jump to the form where they have to make their setup.
The menu item linkage functionality is probably the most important functionality of the data validation checklist because it allows users opening the respective setup form without a lengthy search in the D365FO menu structure. There is, however, a catch with this menu item linkage. The catch is that unless you know all of the different menu items by heart and can enter them directly through the Excel add-in, you have to select them manually, which is a very time consuming process. To help you with this setup, I attached you the different tasks and menu item in this file (SampleGoLiveChecklist) that can be downloaded and used as a starting point for your own data validation project. Please note that this file includes tasks for all except the retail and warehouse management modules.
No 4: Display order
The display order code allows defining how the tasks are sorted and displayed in the task list.
No 5 & 6: Status & assigned to
The status and assigned to fields allow tracking the progress and the person responsible for a specific task.
No 7: Attachments
The attachment functionality is another great feature that is incorporated into the data validation checklist. It allows attaching comments through notes, links – for example to VSTS backlog items – and files that can be used to document the setups that have been made.
If you downloaded and imported the sample task areas and sample tasks that I provided for download, you will get a task list similar to the one shown in the next screenprint.
After doing some tests with PowerApps, I feel that this and the other previously mentioned functionalities (work items, alerts, MS Flow) do not add much value but might rather complicate working on the different setup and configuration tasks. As a result, working directly on the data validation checklist seems – from the author’s perspective – the easiest and most efficient way.
Hope you enjoyed reading this post and that you find the provided downloadable task areas and task Excel documents useful. Till next time.
Within this post I would like to share some of the experiences that I made with the import of transactions from Excel to D365 general ledger journals. The story began in the general journals form, which allows users opening, editing and re-importing accounting transactions in Excel.
The standard general journal line entry template that ships with D365 opens an Excel document similar to the one shown in the next screenprint that has (1) a link to the general ledger journal batch number and (2) a link to the main account(s) used.
Those linkages and functionalities are nice. However, I wanted to (a) enter main accounts and financial dimensions and (b) create new journals and not open already existing ones. Within the following, we will see how (a) and (b) can be achieved.
(a) Enter main accounts and financial dimensions
Fixing the first issue is easy and can be achieved by adding the account display value field via the workbook designer. The next screenprint exemplifies this.
A disadvantage of using the account display value field for recording main accounts and financial dimension combinations is that you cannot easily identify the sequence of the different financial dimensions used and thus do not know how to enter your transactions. That is because this sequence is defined in the following integration form in the general ledger module.
A second disadvantage of entering the main account-financial dimension combinations in a single field is that no tooltip or lookup is available that would help users entering their transactions. Luckily this disadvantage can easily be overcome by implementing a minor system modification that is described on the following website: https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/financial/dimensions-overview. The next screenprint that was taken for a different D365 environment that has this modification implemented illustrates that the system modification allows entering main accounts and financial dimensions in separate columns of the Excel template.
Even though the workbook designer and the optional system modification help to overcome my first issue, you will quickly notice that all Excel design changes that are made via the Office add-in designer are gone the next time you open the Excel template. To fix also this problem, one has to design its own template.
Creating and designing an own template might sound complicated. However, you do not have to design everything from scratch but can rather make use of the things that are already available. In other words, you can make use of the existing standard templates and easily modify them yourself as required. The only thing you need to do to realize that is opening the document templates form…
…identify the existing template and download it.
When downloading and saving the template, take care of the name that you give to this file because this name will be important later on when making the file available for usage.
Once the template is downloaded and saved, you can open it in Excel and start creating your own design.
After all design change are made, the new template can be made available by creating a new document template and importing the Excel document as illustrated in the next screenprint.
Please note that the template name defaults to the file name that has been uploaded. In my example, it ends with _L1. If you do not delete this suffix and make use of the original template name (‘LedgerJournalLineEntryTemplate’), the upload will succeed but you won’t be able to make use of the document template.
Provided that you managed creating your new template, it finally becomes available for selection in the general journals form…
… and can be used for recording accounting transactions.
(b) Create new journals
Using the general journal Excel add-in is nice. Yet, you might have noticed that all my Excel documents shown before had a link to an already existing general ledger journal. What I wanted to do though was creating new journals directly from Excel and not creating a journal in D365 that can be opened in Excel.
In the following, I will show you how creating new journals can be realized by making use of the Excel document template functionality. To make this exercise a bit more challenging, I decided to demonstrate the creation and posting of a new journal by ‘copying’ the lines from an already posted journal. For that reason, I selected one of the already posted journals and transferred all lines into my newly created template.
Once that export was done, I put my cursor into the header section and selected ‘New’ in the Office add-in data connector, which allowed me entering a new description and name that I could publish.
As a result a new batch number became visible (00459)…
… and a new journal was created in the D365 web client.
Happy about what I have achieved so far, I continued my exercise by changing the existing lines that I could still identify in the template. Trying to publish those modified lines to my newly generated general ledger journal went, however, terribly wrong and I got many error messages. After a while, I noticed that something might be wrong with the journal line association. To check this, I added the journal batch number field into my template and noticed that the existing lines still had a relationship to the old and posted journal no. 00001.
When I tried to overwrite those lines, I basically tried to tell D365 to delete already posted vouchers and replace them with some new ones. D365 did of course not allow me doing this and consequently generated the error messages. After becoming aware of this issue, I simply copied the existing lines from journal 00001 to the end of my template, entered the new journal batch number created (00459) and modified the posting date.
Those changes finally allowed me uploading and posting my journal.
I hope that this information and the experiences that I made are helpful for you and allow you circumventing those problems when using the document template in D365. Till next time.
Within the previous posts, many different ways how cost allocations can be made have been illustrated. As the cost allocation transactions recorded are quite complex, summary Excel documents that showed the allocation bases and amounts have manually been prepared.
Preparing those summary Excel documents manually is time consuming and feasible only for the simplified examples used.
If the manual preparation of those summary Excel documents is not feasible in practice, the question arises, how one can follow up and track cost allocations in live environments?
To answer this question, the following four cost accounting ledger Excel export options have been reviewed:
The costs allocations made for this post are identical to what has been shown in post no. 8 on the new cost accounting module. That is, the supplies cost center costs are allocated to the other cost centers based on the number of employees. The car pool cost center costs are allocated based on the number of company cars and the product management cost center costs are allocated to the other cost centers based on production quantities. For details, please see post no. 8.
Excel export option 1:
Making use of the first Excel export option (‘cost entries with dimension hierarchies’) results in the following outcome:
As one can identify from the highlighted columns in the previous screenshot, the first Excel export option is not very helpful because it exports the primary costs only. The secondary costs, that is, the cost allocation data are, however, missing.
Excel export option 2:
The second Excel export option (‘statistical entries and cost entries with dimension hierarchies’) resulted in the same outcome that is shown in the previous screenprint and did also not include the cost allocations posted on the secondary cost elements.
Excel export option 3:
For the third Excel export option (‘statistical entries with dimension hierarchies’), the Excel export returned no data.
Excel export option 4:
The last Excel export option (‘cost accounting ledgers’) finally resulted in the following outcome, which does not help with the intended detailed analysis of the cost allocations made.
As none of the previous Excel exports resulted in the intended outcome, the following data export option was investigated:
Making use of this data export functionality finally resulted in the intended outcome. That is, the Excel export also included the cost allocation data, which are highlighted in green color in the next screenprint.
After exporting the primary and secondary cost accounting data to Excel, a pivot table was created. This pivot table is almost – except for the allocation base information – identical to the summary Excel documents that have previously been prepared manually.
The last data export functionality shown results in a dynamics Excel export. That is, subsequent cost accounting ledger transactions do not require a new Excel export but a simple data refresh only. The next screenshots prove this standard behavior by making use of a step-wise illustration.
Additional repair costs are recorded on the repair cost account no. 855000 for cost center 240 in a General Ledger journal.
Those costs are transferred to the cost accounting module for example through a periodic batch run.
After the data are transferred to the cost accounting module, the Excel document is refreshed and shows the additional costs recorded.
The data export functionality used for the illustration of the cost allocations made helped illustrating the recorded cost allocation amounts. It did, however, not provide any information on how those allocations were made.
In order to find out how cost allocations were made, one can analyze the cost allocation journals that have been created in D365. Let’s take the $32,983.43 that have been allocated from cost center 110 as an example.
By making use of the cost entries button, one can identify the other cost centers that got those costs allocated.
While this information can be retrieved from the Excel pivot chart shown above, the allocation base information that is shown next, is available only in the D365 cost accounting module.
As the current data export functionalities do not support the export of the allocation base data, an idea has been created on the D365 ideas portal and it would be great if you could vote for it. Here is the link: https://ideas.dynamics.com/ideas/dynamics-operations/ID0002454
Many thanks and see you again in the next post on cost accounting security.
The previous posts showed three different approaches how cost allocations in the cost accounting module can be made based on recorded project hour transactions. The approaches used
- project hour quantities that were imported into the cost accounting module for making cost allocations based on the recorded project hour quantities,
- project hour transaction vouchers that were generated by making use of the project module ledger integration, and
- overhead rate policies that allocated the costs to other cost centers based on project hour quantities recorded in the project module.
A major disadvantage of the first approach is that the complete cost center costs of the car pool cost center are allocated to the other operative cost centers irrespective of whether those costs are too high or low compared to an external market price.
The second and third approach did not completely allocate the car pool cost center costs but did not provide a benchmark of the required cost rate needed to allocate the complete cost center costs.
In this post, we will investigate how such a benchmark can be obtained by making use of the overhead rate policy feature, which is described on a step-by-step basis in the following.
Step 1: Record hours in the project module
To get the cost allocation and overhead rate policy incorporated, hours are recorded in the project module first.
Please note that no additional projects and postings have been created but that the transactions shown and recorded in the previous post have simply been reused. The next screenprints consequently document the previous postings and resulting costs only.
Step 2: Setup statistical measure provider template
Also the second and third setup steps are identical to what has been shown in the previous posts. Therefore, reference is made to what has been described there and the following screenprints are included for reasons of completeness only.
Step 3: Setup statistical dimension measure
Step 4: Create cost accounting ledger
The set up of the cost accounting ledger slightly differs from the cost accounting ledgers that have been used before. That is because the project cost and payroll allocation accounts (853100 and 853200) have not been included in the cost element and dimension hierarchies used before. The next screenprints document the minor changes that have been made to the newly created cost element dimension (‘DEMF CE P16’) and the newly created cost element dimension hierarchy (‘DEMF CEH P16’).
Step 5: Create cost allocation policy
The cost allocation policy that is used in this post is identical to the one that has been used in post no. 14 except that the newly set up cost element dimension (‘DEMF CE P16’) is used.
Step 6: Create cost rollup policy
Also the cost rollup policy is identical to the one used in post no. 14 except for the newly set up cost element dimension hierarchy.
Step 7: Create overhead rate policy
The overhead rate policy used in this post differs from the one used previously in the overhead rate policy type (‘fiscal period’ vs. ‘user specified’). Because of the ‘fiscal period’ type selected, one cannot enter an overhead rate in the rule section, as D365 calculates the rates automatically.
Step 8: Process data in cost accounting ledger and configure workspace
After processing the data and policies and after setting up a cost controlling workspace, the following costs can be identified for the various cost centers used:
The next overview summarizes the cost allocations made.
From the previous screenprint it can be identified that two allocations were made; one in the project module for the hours recorded with a cost price of $180/hour and a second one in the cost accounting module, where all remaining costs of the indirect cost centers no. 110-130 were allocated.
Only the cost allocations made in the cost accounting module result in secondary cost transactions. The cost allocations made in the project module are considered to be primary costs from a cost accounting module perspective.
After allocating all costs from the supporting or indirect cost centers no. 110-130 to the direct operative cost centers no. 210-250, the initially raised question on the benchmark cost rate for the car pool cost center has not been answered. An investigation of the overhead rate policy form – shown in the next figure – allows answering this question.
The overhead rate policy form shows a cost rate of $1640.43 for 40 units (hours) of work for the car pool cost center. Dividing the amount by the units results in a rate of $41.01 per hour. Because the cost accounting module allocated the remaining costs only that were not previously allocated through the postings in the project module, the $41.01 represent a cost rate difference. That is, in order to allocate the full costs of the car pool cost center, a rate of ($180 + $41.01 =) 221.01 is required.
If a ‘fiscal period’ overhead rate policy is applied to the cost accounting ledger that has been used in the previous post no. 14, the same rate can be identified. For details, please see the next screenprint.
In the next post, we will investigate how cost allocations that are made in D365 can be tracked and analyzed. Till then.
In the previous post, we had a look at how transactions that were recorded in the project module can be used as statistical measure for making cost allocations. This post will introduce two alternative options that illustrate how those allocations can be made.
Option 1: Project module
A first possibility how cost allocations between cost centers – based on recorded project hours – can be made is through project costing vouchers. Those vouchers can be realized by making use of a project group that has the ledger integration parameter for hour related postings activated. This is the case for the projects shown in the next screenprint.
Posting the very same hour transactions for the car pool cost center manager that have been recorded in the previous post results in a voucher that is shown in the next screenprint.
The voucher above shows that a project cost account (no. 853100) is – in combination with the operative cost centers – debited. The credit transaction is made on another profit and loss (P&L) account (no. 853200). As the debit and credit ledger accounts are both P&L accounts, no effect on company’s profit arises. However, because of the financial dimensions used, an allocation from the car pool cost center costs to the other direct cost centers occurs. This allocation effect is illustrated in the next figure.
- A cost price of $180/hour has been setup in the project module for recording the project hours of the car pool manager.
- From a cost accounting module perspective, the cost allocations made in the project module occur at the primary cost level. That is because the cost allocations are made outside of the cost accounting module
- The cost center financial dimension of the car pool manager that is credited is set up at the employee level in the Human Resource module.
From the previous screenprint, one can identify that some costs remain at the car pool cost center no. 120. Those remaining costs are a sign that the cost price of $180/hour is not sufficient to allocate all costs from the car pool cost center to the other operative cost centers. Provided that the $180 is a market rate (price), the costs remaining on cost center no. 120 can be taken as a sign that the internal management of the car pool is more expensive compared to an external (outsourced) management of that cost center services.
Option 2: Cost accounting module
The second alternative for the cost allocation of the car pool cost center costs is the use of an overhead rate policy, which is exemplified in the next screenprint.
Making use of an overhead rate policy requires that a link to the statistical measure allocation base (‘4. PROJ HOURS’) is made (1). In addition, a secondary cost element that records the cost allocations (2) and the financial dimension to which the overhead rate is applied (3) need to be set up.
Most importantly, an overhead rate that is used for the creation of the cost allocations has to be determined (4). In the example shown above, a rate of $190 has been used to differentiate it from the cost rate that has been setup and used in the project module example shown before.
Similar to what has been shown in the previous post, a statistical measure provider template needs to be setup next for the transfer of the recorded project transactions (hours) to the cost accounting module.
The only difference in the setup of the statistical measure provider template used in this post compared to the one used in the previous post is that a range for the newly set up projects has been specified. This is necessary because the hours of the cost center manager have – for illustrative purposes – been recorded twice; a first time at the projects ending with the number 26ff and a second time at the projects ending with the number 27ff.
Processing the overhead rate policy through a cost accounting ledger results in the following costs for the different cost centers:
As shown in the previous posts, the next graphic summarizes the cost allocations made and the total costs that remain at the operative cost centers no. 210-250.
Please note that a rate of $190 is not sufficient for allocating all costs of the car pool cost center to the other ones. This can be identified by the $900 that remain at the car pool cost center after the allocations are made.
In the next post, we will investigate an approach that makes use of cost allocations in the project module and an overhead rate policy in the cost accounting module. Till then.
In this post, we will analyze how transactions – or more general records – that are entered in other D365 modules can be used as statistical measures for making cost allocations.
To illustrate how such cost allocations can be realized the same demo data that have been used in prior posts will be used again. However, this time, the costs of the car pool cost center no. 120 will be allocated to the other direct cost centers based on the hours that the cost center manager recorded in the project module. Details thereof as well as the allocation bases used can be found in the next screenprint.
Step 1: Record hours in the project module
For recording the hours of the car pool cost center manager, a project with several subprojects – one for each cost center – has been setup.
All projects used in this post are setup with a project group that does not generate a voucher for hour transactions. This has been realized by making use of the ‘never ledger’ project accounting integration setup. As a result, time recordings made in the project module record quantities only.
Step 2: Setup statistical measure provider template
Once all costs are recorded for the different projects, a statistical measure provider template is setup. This template is required to transfer the recorded project hour data into the cost accounting module.
When setting up this statistical measure provider template, one has to select the source table that holds the data, which will be used for the definition of the cost allocation basis. In the example used, the data are held in the ProjEmplTrans table (1). In addition to the table that holds the statistical data, one has to specify (2) the function (sum vs. count), (3) the sum field (hours) and (4) the date field (project date) in order to get the data correctly transferred into the cost accounting module.
Step 3: Setup statistical dimension measure
The next required setup for using the recorded project hours as statistical measure in the cost accounting module is the creation of a new statistical member (‘4. PROJ HOURS’), which is shown in the next screenprint.
Step 4: Setup cost accounting ledger
Thereafter, the cost accounting ledger can be setup in the same way as it has been shown in the prior posts.
Setting up the cost accounting ledger necessitates the configuration of the statistical measure data providers. This configuration of the project hour related measure is shown in the next screenprint and requires that a link between the statistical dimension measure (‘4. PROJ HOURS’) from step 3 and the previously setup statistical measure provider template (‘P14_LRE_ProjectHours’) from step 2 is made.
Step 5: Create cost accounting policy
Finally, the cost allocation policies can be created. Please note that the cost allocation for the car pool cost center is made on the basis of the project hours recorded.
Step 6: Process data and overhead calculation
The outcome of processing the cost allocation policy on the sample data can be observed from the next screenprints.
In the next post, we will take a look at the overhead rate policies and how they can be used for making cost allocations. Till then.
This post focuses on cost distribution policies and how they differ from cost allocation policies. According to the D365 documentation, cost distribution and cost allocation policies differ in a way that cost distributions always occur at the level of the primary cost element of the original costs.
Applied to the previously used example, cost distribution policies should distribute the costs from the indirect cost centers to the direct ones, as indicated by the arrows shown in the next figure.
To verify this, the following cost distribution policy has been setup:
Please note from the previous screenprint that cost distribution policies also refer to a cost object dimension (‚INDIRECT CC’), as cost allocation policies do. Yet, different from cost allocation policies, a cost element node needs to be specified. The remaining cost behavior and allocation base columns are once again identical to what has been shown for cost allocation policies.
After setting up the cost accounting ledger and processing the data and the cost distribution policy, the following costs can be observed from the cost controlling workspace for the different indirect cost centers:
As one can identify from the prior screenprints, some costs remain at the indirect cost centers no. 120 and 130. The underlying reason for this outcome are cost distributions that are made within the group of the indirect cost centers. Those distributions are caused by the employee allocation basis used. The next graphical overview aims to illustrate the underlying issue.
To avoid that costs remain at the indirect cost centers, the cost distribution policy is slightly modified in a way that a hierarchy allocation base (‚DEMF_P13_B’) is used.
The major advantage of using a hierarchy allocation base is that one can specify to which cost objects cost distributions (or cost allocations) shall be made. In the example shown above, to the direct cost centers (‘DIRECT CC’) only.
Reprocessing the cost distributions with the modified cost distribution policy finally results in the cost data shown in the next figures.
The next graphic has been prepared for a better overview of the cost distributions made.
Before ending this post, please note the following concluding remarks:
- The distributed costs won’t be shown as secondary costs even if a cost rollup policy is defined and assigned to the cost accounting ledger.
- The same outcome that has been shown above can be achieved by making use of a cost allocation policy that is not linked to a cost rollup policy.
The next post will introduce how to import statistical measure data from other D365 modules. Till then.
In this post, we will take a look at a more advanced allocation scenario where fixed and variable parts of selected cost elements are allocated from indirect to direct cost centers based on separate allocation bases. The next graphic illustrates the allocation approach applied in this post.
Step 1: Setup dimension hierarchy
To get this allocation approach incorporated into D365, the previously used dimension hierarchy that differentiates between direct and indirect cost centers is used once again.
Step 2: Setup cost behavior policy
The next setup required concerns the cost center behavior policy of the different cost elements. The following screenprint documents how this setup has been made.
Please note the different fixed percentage rates for the cost elements 853000, 854000 and 855000 from the screenshot shown above. To ensure that no other fixed costs are setup and caught by the allocation policy, an additional cost element dimension hierarchy node (‘DEMF CEH’) – with a fixed percentage rate of 0.00% – has been included in the cost behavior policy rule section.
Step 3: Setup hierarchy allocation bases
The third setup step relates to the hierarchy allocation bases that will be used for allocating the fixed and variable costs.
The first hierarchy allocation base (‚DEMF_P12_FIX’) that will be used for the allocation of the fixed costs from the indirect cost centers to the direct cost centers refers to the numbers of bikes produced.
The second hierarchy allocation base (‘DEMF_P12_VAR) also allocates costs to the direct cost centers. However, different from the fixed cost part, the employment related statistical measure (‘1. EMPL STAT DATA’) is used as allocation base for the variable costs.
Step 4: Setup cost allocation policies
The cost allocation policy shown next, combines the different ‘pieces’ that have been setup and explained before. Because the setup of cost allocation policies have already been explained in previous posts, no further explanations are made here and reference is made to the previous posts on the new cost accounting module.
Step 5: Setup cost accounting ledger & process data
After the cost accounting ledger is created and the costs and policies processed – not shown for reasons of brevity – the following costs can be observed from the cost controlling workspace for the different cost centers used.
For a better overview of the fixed and variable cost allocations made, the following graphic has been developed, which summarizes the different costs and allocations for the cost centers used.
In the next post, we will take a look at cost distribution policies and how they differ from cost allocation policies. Till then.