Intercompany project invoicing in practice: Process

Intercompany project invoicing in practice: Process

With the Intercompany project invoicing in practice: Setup in place, let’s proceed with the business process step by step.

Timesheet entry

Go to Project management and accounting > Timesheets > My timesheets and create a new one. People often experience issues here for the first time. These may be traced to 2 possible causes: a wrong/missing user-employee relation and/or missing timesheet periods or timesheet weeks records (every employee has a set of his/her own: refer to Part 1, Show/Update timesheet periods).

Pick the borrowing Legal entity, and the list of the eligible projects becomes available. All the constraints in the borrowing entity are respected: the project stage, a possible worker/project validation, billing Line properties etc. Unfortunately, this goes as far as to the extraction of the final sales price to the end customer and the ultimate customer-facing VAT group from the borrowing LE side. These parameters are ‘frozen’ once the timesheet is posted in the lending entity, but the game is not yet over: one can fix them after.

Perhaps the most critical flaw in the design of intercompany timesheets is the derivation of the financial dimensions: the project financial dimensions do not propagate the lending entity at all, despite the common chart of accounts and accounting structures. Instead, the employee dimensions are taken, and nothing else. This is going to hit us hard at the moment of the IC free text invoice booking, because the revenue account structures very often require a cost/profit centre, a line of business dimension and so forth.
The workaround may be to set the P&L dimensions in every employee card (which is awkward and may not always fit) or to extend the /Tables/TSTimesheetLine/Methods/initFromProjTable method.

The issue is aggravated by the fact, that an entity-backed Project ID dimension cannot span multiple legal entities, while the project itself obviously can! A common ‘solution’ is a custom or a manual Project ID financial dimension (business case: booking an asset depreciation against a project, booking service revenues against a CAPEX project and so on).

Either way, as soon as the first hours have been entered, they already appear in the Manage / Pending transactions view with the final sales price to the customer:

Submit the timesheet to the Workflow in due time, get it approved (learn the Reassign button in the Workflow history). The timesheets may either be configured for the automatic posting or they may be posted manually in the Project management and accounting > Timesheets > Unposted timesheets list. Beware that no Project transactions (ProjEmplTrans) get produced, the transactions are still “pending”.

Intercompany customer invoice

Run the Project management and accounting > Periodic > Project invoices > Create intercompany customer invoices function to collect desired types of transactions and bill them at once to the borrowing IC partner.
The result appears on the Project management and accounting > Project invoices > Intercompany customer invoice list:

In essence, it is a usual free text invoice with a few project extras. Every timesheet day results in one IC customer invoice line (!) and the printout may be quite long. To preview the invoice, use the common Sales ledger (en-us: Accounts receivable) > Invoices > All free text invoices form. Once the invoice is created, the pending project transactions in the borrowing LE disappear for a short moment of time.

Should anything be wrong, the invoice may be simply deleted and re-created at will. You cannot correct the source dimensions in the timesheet anymore, but the dimensions or the accounting distribution in the free text invoice may be amended… line by line.
Post the invoice. This is the moment when the system makes a copy of it in the borrowing legal entity as a Supplier pending invoice; the transactions reappear on the pending project transactions list.

Pending supplier invoice

In the borrowing legal entity, locate the Purchase ledger (en-us: Accounts payable) > Invoices > Pending supplier invoices. The IC invoice must be there with the free text invoice number from the lending entity. The lending LE financial dimensions have been overwritten with the dimensions of the project in the borrowing LE.

This is the fist chance to fix timesheet errors by amending the Billable/Non-billable Line property, the final Sales price, etc. The quantities (hours) are better tended by adjusting the resulting project transactions, once the Supplier invoice is posted.
Namely, there is one key constraint to realise: there is no facility to cancel the original IC customer invoice in the lending entity, therefore no legal options to fix it in terms of the cost amount (i.e. the transfer price), quantities etc. in the borrowing entity either. Game over. The lending entity may only issue an all-manual free text invoice for the disputed difference.

Post the invoice. The invoice lines finally appear as Posted project transactions in the project, where the sales price comes from the borrowing LE and the cost price = transfer price originates in the lending LE.

Note one weird thing about the transactions: the Origin is the Supplier invoice of the expense project transaction type, yet the categories are the hour categories. The project date is the original date on the timesheet (there used to be a bug around that, but it was fixed).

This concludes the specific intercompany part of the process. In the case of a Fixed fee project, it all ends with the cost, WIP and the revenue recognition at the end of the month. In the case of a Time and material project, the hours and/or expenses may be billed regularly:
Project proposal → [Invoice proposal workflow] → Project invoice, either detailed or condensed.

Intercompany project invoicing in practice: Setup

Intercompany project invoicing in practice: Setup

The most comprehensive guidance on the Intercompany Project Management in Dynamics 365 for Finance used to be the blog of Brian Welcker, the historical product manager of the feature. The original source must have disappeared from the Microsoft sites, but a copy remains in the community archive:

However inspiring this source used to be, consultants face a challenge setting this up: in which company which configuration needs to be placed? I will try to fill this knowledge gap.

Prerequisite setup

First of all, you need to go to the General ledger > Posting setup > Intercompany accounting form, pick some accounts and journals and establish a connection between the borrowing legal entity (the one leveraging resources of a subsidiary and issuing invoices to the end customer) and the lending entity (the one providing the workforce and absorbing the cost). Use the button Create reciprocal relationship to make the connection bi-directional.

The reason for this setup is the most profane: without it you cannot choose the lending / borrowing entities in any of the following configuration forms.

In the borrowing company, create a supplier (en-us: vendor) representing the lending company. Pick the known name from the global address book to reuse the legal entity addresses, phones etc. in the supplier card. You can also create a supplier right from the GAB.
In the lending entity, create a customer record representing the borrowing company in a similar manner. With the button General / Intercompany, establish a trading relationship between the two by connecting the supplier with the customer or vice versa. No other Intercompany settings are relevant, because the project intercompany recharge works through the free text invoices and pending supplier invoices with procurement categories (and not through the sales orders and purchase orders with items).

Core Lending company configuration

The lending legal entity barely requires any project management and accounting configuration at all! The project groups, projects, the billing project categories, the “line properties” (billable vs. non-billable) remain in the borrowing entity.

Still, you better replicate the relevant project categories in the lending company, because without it the system is going to fail deriving the Item VAT groups (en-us: Sales tax item groups) when making an intercompany invoice to the borrowing entity, and it is a reason weighty enough. Since you need the project categories, you will create the project Category group(s) too.

The project category does not really require any project-specific GL integration. However, a notorious ‘feature’ of the timesheet posting demands a ledger account for the Project cost and the Payroll allocation, even if the project group stipulates Never ledger i.e. do not post the hours into the General ledger. Moreover, a setting per Category group will not work for a reason unknown; it must be an All-All line in Project management and accounting > Setup > Posting > Ledger posting setup:

On the Revenue accounts tab, select the Intercompany revenue account(s). Again, only the All-All seems to work.
Should the same subsidiary provide multiple fellow companies with the services, the revenue accounts may vary (e. g. between domestic IC partners and export partners). In Dynamics, they may be differentiated by the Borrowing legal entity (this column did not exist in Dynamics Ax2012, an improvement indeed):

The most crucial setup is actually the [weekly] timesheet period template (Project management and accounting > Setup > Timesheets > Timesheet period types):

Use the Generate periods button to pre-populate the weeks one year ahead, then navigate to Human resources > Workers > Employees and assign this TSWeek Period type under the Project / Project setup button to all the employees who must record time, then come back, click the obscure Update timesheets periods and Update worker periods. No, these manipulations do not make much sense, but they are absolutely necessary.

Next, open Project management and accounting > Setup > Project management and accounting parameters and make sure that the Timesheet and the Timesheet voucher number sequences are set, but most importantly, flip the Enable intercompany resource… slider and choose the Borrowing legal entity below.

The Timesheet review workflows are [sadly] local to every legal entity: Project management and accounting > Setup > Project management and accounting workflows. The timesheet approvers may (and should) be people from different companies, an access to the lending company and the Project supervisor role provided. The workflow setup may be easily exported from one company and imported into another.

Finally, set the Project management and accounting > Setup > Prices > Transfer price: this is what the headquarters will be charged for the services provided.

Most of the time, there will be a fixed internal price per hour, and a setting to recharge [travel] expenses and – possibly – subcontracted services with no or little uplift (that’s the rationale behind the Contribution ratio = 0 on the above screenshot).
And no, the fixed transfer price can hardly be further differentiated by departments but only the [customer-facing, billing] project categories. This can be a nuisance; still, the different internal cost rates by department/maturity/roles may be accounted for by a [tedious] list of prices by single persons (see the Resource column) or by Role IDs (however, the latter option puts a burden of picking the proper roles in every timesheet line).

Core Borrowing company configuration

The borrowing company holds most of the Project management and accounting machinery, including the projects themselves, the billing settings and the [higher] sales prices for hours and expenses, should the project be billable on a time and material basis:

Check the Project management and accounting parameters: do NOT set the flag Set the cost price as the sales price by default on the General tab: this will erase the hours sales price from the posted IC invoice and the billing of the services to the end customer is going to fail.
Most importantly, the Default category must be selected on the Intercompany tab:

This single procurement category is used as a stub in all incoming pending IC invoice lines; in fact, it must not be integrated with the project categories or posting at all! It doesn’t even need to be integrated with the GL in the Inventory management module either, as the special Intercompany cost account is used at all times:

When looking for the cost account, the pending supplier (en-us: AP) invoice accounting distribution respects the original hour categories chosen in the timesheet, not the expense procurement category used as a placeholder in the invoice line. In conjunction with the Lending legal entity column (fun fact: the Lending legal entity may not be selected from the drop-down list, but only manually typed in) this helps assign different cost account by different ICO parties and/or kind of services delivered.

This concludes the specific configuration of the borrowing LE.


Let’s dive into the business process demonstration: Intercompany project invoicing in practice: Process!

Electronic Reporting (ER) Cookbook 4: References in a model

Electronic Reporting (ER) Cookbook 4: References in a model

The “Item reference” in Dynamics 365 Electronic Reporting models has been an elusive concept for me for quite a long time. A reference creates a kind of a cross-link between the ER model parts, but what for? Now I think I have figured out some important use cases:

  • Re-use structures and record list definitions within the model, especially for UNIONs
  • Map the same model in different ways and export similarly structured files from different sources

References to facilitate LISTJOINs

The LISTJOIN ER function is an analogue to the SQL UNION. It combines heterogenous record lists into one list of a common type. For example, a LISTJOIN(model.PurchaseLines, model.SalesLines) creates a typed single record list with their common fields: Product no, Quantity, Delivery date, Warehouse etc. However, for the LISTJOIN to recognize the common fields, the fields must be aligned, i.e. follow in exactly the same order, bear exactly the same names.

Here is where the references come into play. One can organize a “Dictionary” root entry in the model, define the most elementary composite entries there, then click the Switch item reference button elsewhere and include this small “brick” into a larger record. From the small bricks one may build larger bricks and so on. Such cross references are indicated by the asterisk (*):

In the above example, an Order record includes the CategoryComposite, Coverage order, Item order nested 1:1 records, and uses fields of the Category type and Line status enumerations. The resulting common Order record type is further assigned to the Sales and Purchase record lists, and this makes their structure in the model identical. The LISTJOIN() then produces a list of records with the following fields:

@.’Qty avail’
@.Category.’Category ID’

and so on.
By the way, the root node Item dictionary here is a Container. A Container is used simply to put together diverse artefacts, a way to make the model definition more readable.

References to apply different mappings to the same model

Imagine you need to export sales order lines and purchase order lines into 2 different files, similar in structure. You need a model to abstractly describe a generic Order line list, then a Sales line format export definition, a Purch line format definition both preferrably derived from a common Order line format, and 2 mappings: Sales line to model and Purch line to model to populate the Order line list model from 2 different data sources in Dynamics 365.

Try to run the Sales line format file. It is going to start complaining about 2 models present: “More than one model mapping exists. Set one of the configurations as default.” You set the Sales line to model as Default for model mapping = Yes and the export starts working.
No try to run the Purch line format. It is going to export sales order lines in the purchase order line format, because a link between the format and the outbound mapping is through the model node they use:

Format → Model [node] → [default] Model mapping

To fix this, the 2 formats should be mapped to different nodes in the model!

I’ve got a similar issue when I was trying to use the same model both for the export and for the import of data. There was a Counting journal model and 2 formats: Export to Kardex and Import from Kardex. There was a Counting model mapping for the export and a Counting model to destination mapping for the import.

Tried to run the export Export to Kardex and it asked to “Set one of the configurations as default“, which I did.
Then I tried to run the Counting model to destination mapping but it was not prompting any files for the upload, because a link between the inbound mapping to the import format was established through the model and it was pointing to the export format:

Model mapping to destination → Model [node] → Format

The trick is to use different nodes! The import format should write the data from the inbound file into one Record list in the model, while the export format should read data from another Record list in the model. The mappings then bind the same table to the one node and another, respectively. To reuse the data types and the structure, one node references the other (Switch item reference).