Tags
Do you know … how to embed QR payment codes in customer invoices?
19 Wednesday Aug 2020
Posted in Accounts Receivable, Project
Category Archives: Project
Project Stage Workflows
19 Tuesday Nov 2019
Posted in Project
This blog post builds upon the code adjustment illustrated in the previous post and demonstrates how MS-Flow can be used for implementing a project stage workflow that assigns tasks to different users. Want to see how? Then have a look at this post.
Intercompany project cost analysis – Part 2
02 Saturday Nov 2019
Posted in Project
In this blog continues the first one and focuses on a weakness that we experienced in the process that was shown in the previous part. To overcome this weakness, I asked for some help from my follow #MVP Ievgen who helped me getting things fixed. Want to see how? Then have a look at this second part.
Intercompany project cost analysis – Part 1
26 Saturday Oct 2019
Posted in Project
In this blog post I demonstrate how one can analyze the overall profit/loss of a cross-company project operated in D365FO. Have a look at how this can be realized – as usual – without making any system adjustment and leveraging the PowerPlatform.
Investment management process… by the way
11 Friday Oct 2019
Posted in Fixed Assets, Project
A small note on how one can improve the investment management process shown in the previous post.
Investment management process
09 Wednesday Oct 2019
Posted in Fixed Assets, Miscellaneous, Project
Allocate depreciation postings to projects with the help of MS-Flow
11 Wednesday Apr 2018
Posted in Cost accounting, Fixed Assets, Project
Tags
In this webcast, I show you how you can use MS-Flow for allocating depreciation costs from the fixed asset module to the projects that you operate in the project management and accounting module. Everything works out of the box without a system modification – something that was not possible in the past.
A note on committed project costs
06 Friday Jan 2017
Posted in Project
Project related expense invoices can be recorded in a number of different forms and journals, such as the Accounts Payable (AP) invoice journal, the project expense journal or the AP invoice workbench, to mention only some. When it comes to expense invoice recording for projects, an important consideration is the time at which those expenses can be identified at the project level. The timing aspect is important especially in companies that face long invoice throughput times due to detailed invoice control and approval procedures.
To identify process related differences in expense invoice recording, an expense invoice for $150 will be recorded next through a standard AP invoice journal. This process will then be compared with entering a similar invoice through the so-called invoice workbench.
Let’s get started with the process of recording an expense invoice for a project through a vendor invoice journal, which is shown in the next figure. Please note that the vendor invoice line and the project to which the expenses are posted to, are shown in the upper part of the next screen-print whereas all project specific information is included in the project tab shown in the lower part of the same screen-print.
As one might expect, after recording the invoice but before posting it, no costs can be identified at the project level. Please see the next figure.
Once the invoice is posted, the respective project expenses are recorded as actual project costs. This can be identified from the actual cost column of the cost control window shown in in the next screen-print.
Let’s now have a look at what difference recording a similar invoice through the vendor invoice workbench – exemplified in the following screen-print – makes.
Except for the way how the expense invoice data are entered, the same information is recorded in the vendor invoice workbench shown below.
Yet, different from before, the project expense can already be identified at the project level, once the invoice has been recorded. For details, please see the project expense amount shown in the committed cost column of the cost control form that is illustrated in the next figure.
It is this ability of showing recorded project expenses early that differentiates the process of entering project related expense invoices through the vendor invoice workbench from recording them through vendor invoice journals. A knowledge of this difference is important especially in companies that see long invoice throughput times because an early identification of (forthcoming) project expenses can avoid wrong interpretations and subsequent actions.
Note: A prerequisite for becoming able to identify project expenses early through the committed cost functionality is the activation of the corresponding project cost control parameters shown in the next screen-print.
In addition, a periodic batch job needs to be setup that identifies and illustrates the committed costs at the project level. Example:
Summary:
Using the committed cost functionality can be of vital importance for companies that face comparatively long invoice throughput times. Companies with short invoice throughput times do, on the other hand side, not considerably benefit from using the committed cost invoice feature that is only available for invoices recorded through the vendor invoice workbench. Expressed differently, companies, with short invoice throughput times have a greater flexibility when it comes to entering expense related project invoices.
Timesheets & missing working time
06 Tuesday Dec 2016
Posted in Project
≈ Comments Off on Timesheets & missing working time
Tags
Before invoicing project customers and/or preparing the month-end close, it is a common practice to verify that all employees have recorded their working time. Dynamics AX supports this verification process through the missing timesheet report shown in the next screen-print.
Note: The manager that can be identified in the last column of the missing timesheet report is the one that is specified in the ‘reports to’ field of the employee’s position assignment and can be found in the Human Resource (HR) module.
An alternative to generating the missing timesheet report is using the periodic missing timesheet email notification functionality. This periodic process sends automatic email reminders to those employees – not their superiors/managers (!) – that have not recorded their working time through timesheets. The content of the email is thereby defined in an email template, which needs to be linked to the Email Id field in the project parameters form shown in the next figure.
A major problem with the missing timesheet report (and the email notification process) is that it only verifies that some working time has been recorded. It does, however, not check whether and how much time is missing. The following screen-prints demonstrate the aforementioned by showing the content of the missing timesheet report for an employee (‘Julia’) that creates and saves her timesheet in a first step, submits it later on and finally gets it posted.
Step 1: Create & save timesheet
Step 2: Submit timesheet
Step 3: Post timesheet
As one can identify from the previous screen-prints, the missing timesheet report does not include the employee (‘Julia’) anymore once the timesheet has been posted. This outcome is quite astonishing because only a single hour of working time has been recorded, which is by far less than what has been contractually agreed upon with the employee (40 hours/week).
Against the background of this result, it can be summarized that the missing timesheet functionality and the periodic email notification process are per se not sufficient to ensure that employees recorded all of their working time.
If the missing timesheet functionalities are not sufficient to verify whether or not employees recorded all of their working time, the question arises what other additional instruments are available that can help ensuring that employees record at least their contractually determined working time.
The main instrument available for that purpose is the timesheet policy feature. Provided that the contractual working time of employees is setup in a calendar and given that the timesheet policy prevents employees from submitting their timesheets if less than the contractually determined working time has been recorded, one can ensure that employees record their complete working time. The following example demonstrates how this can be achieved based on the timesheet policy configuration shown in the next screen-print.
The timesheet policy illustrated in the screen-print above prevents users from submitting and posting timesheets with less than 40 hours working time recorded. Timesheets that include less hours – such as the one shown below – cannot be submitted and will consequently be picked up in the missing timesheet report. The following screen-prints exemplify this system behavior.
Please note that what has been said for timesheets that include less time than the one specified in the timesheet policy also applies for employees that have not even created a timesheet. It is thus the combined application of the timesheet policy and the missing timesheet report which help ensuring that employees recorded all of their working time.
Note: The illustrated timesheet policy and application of the missing timesheet report assume (a) that employees submit their working times only once a week in a single timesheet and (b) that employees record their full working time including absence times for holiday, illness, etc. Through a slightly different setup, the same result can also be achieved if employees are supposed to record their working time on a daily basis.
Project related intercompany cost allocations (3)
19 Saturday Nov 2016
Posted in Project
≈ Comments Off on Project related intercompany cost allocations (3)
Example 3: Revenues realized at the subsidiary level are allocated back to the corporate headquarters level
Part A: Scenario
The underlying scenario for the subsequent illustrations and explanations is the development of a software product by the corporate headquarter company that requires regular updates and maintenance e.g. in order to comply with changes in legal regulations.
The initial development of the software product was completed by a team of developers from the corporate headquarters company (USSI) several years ago. All costs related to this product development were recorded on an internal development project U1 that was closed after the initial product development ended. Thereafter, all costs related to product updates and changes are tracked in a separate project U2.
In order to run & treat the internal product development team as a profit center and not a cost center, the corporate management decided that the subsidiaries that make use of and sell the software product need to pay a fraction of their sales revenue to the corporate headquarters as a license fee. All respective intercompany contracts have been signed and need to be applied in the ERP system. How this application can be realized in standard Dynamics AX will be subject of this post.
Before digging into details, let’s have a quick look at the following illustration that shows the different companies and projects involved in this scenario.
Part B: System setup
Setup B.1: Intercompany dummy vendor account company FRSI & GBSI
Similar what has been shown in the prior post on intercompany costs allocations, the first thing that needs to be setup are intercompany dummy vendor accounts. The only difference to what has been described in the previous post is that two rather than a single dummy vendor account need to be setup.
Setup B.2: IC customer & vendor accounts
The second setup step is also identical to the one shown in the prior post. However, slightly different from before, intercompany customer accounts need to be setup in the subsidiaries FRSI & GBSI and two separate intercompany vendor accounts in the corporate headquarters company USSI.
Setup B.3: Project category setup
The third setup step relates to the project category setup, which is required for the intercompany invoicing and transaction recording. Different from before, this time, two separate project categories – one for each subsidiary – need to be established because the project ledger posting setup in the project module does not allow a separation based on the company account.
Please note both categories are linked to the transaction type “expense”.
Setup B.4: Procurement category setup company FRSI/GBSI
Also the setup of the procurement categories is mainly identical to the setup that has been shown in the previous post except that two rather than a single procurement category need to be setup – one for each subsidiary.
Setup B.5: Project setup companies
The project setup in the different companies involved in the intercompany scenario follows the structure shown in the graphic of the initial scenario section above. The next screen-prints exemplify how the corresponding projects are setup in the headquarters (USSI) and subsidiaries companies (FRSI & GBSI).
As mentioned in the prior post on intercompany cost allocations, there is nothing that requires special attention when setting up the different projects except that each of those projects should be linked to a default intercompany financial dimension value – at a minimum.
Setup B.6: Project posting setup
In regards to the project posting setup, reference can be made to what has been mentioned in the prior post except that the direction of the setup is flipped. That is, while intercompany revenue accounts need to be setup in the subsidiary companies (FRSI & GBSI), intercompany cost accounts need to be setup in the headquarters company. The same holds for the setup of the ledger posting integration for the procurement categories.
Part C: Process steps
Step C.1: Record transactions & invoice the external customer in FRSI/GBSI
Against the background of those setups, the first process step consists of recording costs and revenues on the external customer projects that are run in the subsidiary companies. For reasons of simplicity and brevity only hour transactions are recorded and subsequently invoiced for a single project in each of the subsidiary companies. The next screen-print shows the vouchers created in company FRSI for the time recorded and invoiced.
As the vouchers created in company GBSI are basically identical to the one created in company FRSI, they are not explicitly illustrated here to conserve space. They are, however, included in the next accounting overview.
(IC = Intercompany financial dimension, PRO = Project financial dimension)
The prior accounting overview shows ordinary project accounting transactions that debit a project cost account for the hours recorded and credit the payroll allocation account for the cost of those hours recorded. The second vouchers record the receivable against the external customer and credit a project revenue account (highlighted in yellow color).
Step C.2.: Record internal vendor invoice in FRSI/GBSI
Whereas most of you have seen and are familiar with the first process step, you might not have seen the following second one that posts an internal transaction on a dummy vendor account.
Slightly different from the prior post where only a single line was used to create a transaction on the internal dummy vendor account, this time two lines are recorded and posted. The first line is used to record an expense on the external customer project – in the screen-print below – in company FRSI. This expense transaction represents the license costs charged by the corporate headquarters to the subsidiary for using the developed software product.
The second line is used for the subsequent creation of the intercompany credit note and consequently entered with a negative quantity & amount. Please note that this second line links to the support & maintenance project in company USSI.
Note: Whereas recoding such internal transactions is feasible in situations where a limited number of external customer projects exist, it becomes infeasible in companies that run many external customer projects. What might help in those cases is the standard Excel-Addin for Dynamics AX that allows importing transactions into the invoice workbench form shown above.
The voucher resulting from posting the internal transaction can be identified in the next screen-print and is summarized in the next accounting overview.
The first notable outcome that can be identified from above is that no open vendor position is created on the internal dummy vendor account, as the two lines recorded offset each other.
In addition, the debit account transaction on the ledger accounts 707451 (FRSI) and 402451 (GBSI) – that represent the license costs for the use of the software product developed by the corporate headquarters (USSI) – lower the profit for those projects and allow project managers taking a look at the full costs of their projects. The next screen-print, which shows the project statement for the external customer project in company FRSI shows this in more detail.
Step C.3.: Create intercompany credit note in FRSI/GBSI
The third process steps consists of creating the intercompany project invoices (credit notes) in company FRSI and GBSI. As this step mirrors the one shown in the previous post, reference can be made to what has been said there.
The voucher that results from posting the intercompany project invoice (credit note) can be identified in the next screen-print.
As before, the next accounting overview summaries the postings recorded thus far.
Please note that the accounts highlighted in light-grey color offset each other and do thus not exert an influence on the project and corporate profitability in the subsidiary companies.
Step C.4.: Post pending credit notes in USSI
The last process step described in this post consists of posting the pending vendor invoices (credit notes) in the corporate headquarters company USSI shown in the next screen-print.
Posting those credit notes results in vouchers that debit – and therefore reduce – an intercompany liability account and credit an intercompany P&L account. For that reason, the profit in the corporate headquarters company increases correspondingly.
The next accounting overview summarizes all transactions recorded within the four process steps shown above.
The yellow-highlighted arrows and fields illustrate that a part of the revenue from the external customer projects in the subsidiaries (FRSI & GBSI) is shifted to the corporate headquarters company that developed the overall software product sold to the customer.
With this revenue shifted to the support & maintenance project in the headquarters company, a comparison of the initial development cost and the ongoing maintenance costs of the developed software product with the resulting license revenues can be made. This is a major prerequisite for treating the internal development team / project as a profit center.
Summary
Within this and the previous posts I illustrated how indirect costs can be allocated to projects – either within a single company or between companies – by using standard Dynamics AX functionalities. The major outcome of those posts is that the standard Dynamics AX tools do in general support all kinds of those project allocation scenarios require, however, the one or the other system modification in order to get the allocations fully automated.
