In this video, we look at a simple example of how Power Query can supercharge your reporting abilities for values brought into excel via the data connector.
I’ve found Power Query to be a great tool for efficiently combining data that lives across two different D365 data entities. It is a fantastic tool for data migration or analysis in general.
Some Concepts:
Pivot Tables
Refreshing Data
Connecting Data to Power Query
Merging Two Data Sources in Power Query
D365 Relationship Between Projects, Project Contracts, and Sales Currency
In our previous posts in this series we looked at understanding project categories and using project categories. Completing the series, today we’ll look at uploading project categories through a package in the data migration framework.
Remembering our initial diagram, project category data don’t exist on a single table, but are on a set of related tables. To manually create a Project category, you need to
Configure a Category group
Configure a Shared category
Create a Project category
Update Expense or Cost category details (if necessary)
The same holds true when uploading project categories through the data management workspace. We will need to upload data through multiple data entities to successfully build our project categories.
Data management workspace
A quick refresher on the Data management workspace – The Data management workspace relies on data entities to pass data in and out of D365. An Import project can be created to pass data into D365. An Export project can be created to pass data out of D365. When examining data in an existing system, it can sometimes help to create an Export project to view the available data.
Above is an export project with the data entities related to project categories
Project category group
Shared category
Category table
Project category
Expense category
Clicking export processes the data in these entities so they can be downloaded in a package. Refresh the following screen until the completed checkbox appears – you can now click Download package.
The downloaded package is a zip file containing excel files for your data entities as well as two .xml files – Manifest.xml and PackageHeader.xml. You can extract the contents of the zip file to examine the contents of the project category data. The xml files will be helpful when we make changes or additions to the project category data and are ready to import those changes back into D365. As we will see in the next post, the xml files tell the Data management workspace what data entities we want to upload and the order in which we want to upload them.
“How many project categories do I need?” is a common D365 implementation question. Remembering the rules from our initial project categories post, a project category can be of only one transaction type – so you will need at least one project category group for each transaction type used and at least one project category within each project category group.
Below is a survey of places where project categories are used in D365 for Finance and Operations. The list is not exhaustive, and project categories are not the only drivers of the below (for instance, there are many attributes that can be used to drive sales prices), but the below can be a good starting point for thinking about how granularly an organization’s project categories ought to be defined.
Ledger Posting Setup
Project and category relationships are the two main drivers of both cost and revenue account posting profiles in the Project management and accounting module.
Sales prices
Hour, Expense, and Fee transaction types all have their own sales price tables. Sales prices for items are set through trade agreements. Project category is one of many attributes that can be used to drive sales prices.
Cost prices
While it is more common for cost prices to be driven at the resource or role level, specific cost prices can also be set at the project category level.
Line property defaults
Line property default behaviors are configured on the project/group line properties table. For some organizations, it makes sense to have billable and non-billable expense categories instead of having users directly select the line property on their expense report lines.
Expense category attributes
Different expense types have different attributes – for instance, an expense type of mileage requires a number of miles to be entered on the expense report, calculating a reimbursement amount, instead of allowing the user to directly enter their mileage expense reimbursement amount.
Expense policies
Different company expense policies can be applied specifically to project categories of certain expense types.
Indirect costs
If using indirect costing, indirect cost components need to be associated to an indirect cost project category. Less frequently used, project categories can be used to drive whether indirect costs are applied through the Indirect cost component group assignment rules configuration.
Item sales tax groups
Different sales tax codes apply to different goods and services. In D365, this sales tax configuration is applied through the item sales tax group on the project category.
Posted transaction reporting
Whether viewing posted transactions in D365 or an external reporting solution, project category can be an important reporting dimension. In the image above, the hours transactions form is grouped by project category.
Project forecast reporting
As with posted transactions, project categories can be a useful dimension for project forecast reporting. Sometimes forecasting is done at a more general level of project category than those anticipated for posting. (For example, an “Expense forecast” project category may be used to estimate all the different expense postings anticipated on a project)
Project invoice document
Project categories display on the project invoice document – which makes sense especially if sales prices are being driven by project categories. That being the case, it is worth considering what customers would like to see related to the project categories displayed.
Do you see an important project category function missing from the list above? Call it out in the comments!
Fun fact: Aristotle thought there were ten categories. Possibly related fact: Aristotle never used the D365 Projects Module.
Project categories are not a new concept in D365. A quick search will show that categories date back at least to AX2012, and perhaps even time immemorial. The latest project category documentation (see here, here, or here) is 5+ years old – more ancient than Aristotle in tech-years.
Why do I think I can explain an old topic any better than it’s already been explained? Aristotle would call this Hubris.
What Are Project Categories?
Understanding project categories requires knowing a few D365 projects module rules:
Cost or revenue associated with a project must be defined by a project category.
A project category can only be of one transaction type (Hour, Expense, Item, Fee).
A project category can only be used within its own legal entity.
To work with the Expense module, a Project category needs to be setup as an Expense category.
To work with the production module, a Project category needs to be setup as a Cost category.
These rules lead to a D365 category table structure that looks like this:
Why so complicated? The complexity comes from the rules…let’s examine.
1) Category group
Category groups…groups categories! Project categories can only have one transaction type, and the category group is where the category’s transaction type is defined. All project categories in the same category group will be of the same transaction type.
2) Shared category
Because a project category can be used only within its own legal entity, the concept of a global “shared category” exists in D365 to link project categories across different legal entities. The shared category is also where the category’s identity as a “Project category” for use in the Project management and accounting module is defined. The Shared category is also where a category’s use in the Production or Expense management modules is defined if applicable.
3) Project category
Once a category group and shared category have been setup, the project category can be created. When creating a new project category on the project category form, the category ID dropdown will show all shared categories not yet associated to project categories in the current legal entity. Notice that Category group is a required field for the project category, and that selecting the category group sets the project category’s transaction type.
4) Production category
When “Use in production” is enabled on the Shared category, the associated Project category is also setup as a Cost category. An additional fastab related to Production attributes is displayed on the project category (this additional production information is stored on the Cost Category table). The category is also visible in the production module. This is the same category record information, just viewed from a filtered list of categories used in production.
5) Expense category
When “Use in expense” is enabled on the Shared category, the associated Project category is also setup as an Expense category. Two additional fastabs related to expense attributes are displayed on the project category (this additional information is stored on the expense category table), and the category is also visible in the Expense management module. Like the Cost category, the Expense category record in Expense management displays its same record information as in the Project category list.
As you can see, setting up a new Project category is as easy as 1, 2, 3 (configurations for Category groups, Shared categories, and Project categories)…and possibly 4 or 5 (additional configurations for Cost categories or Expense categories, if applicable). In a future post, I plan to look at different results that can be driven by Project categories, as well as how to efficiently upload Project categories through data management.
In this post we’ll walk through the steps to set up a project and bill time in Microsoft Dynamics 365 for Finance and Operations.
Setup
a. Worker Setup
i. Make sure user is associated with Worker
Click edit and select the applicable resource in the person field. If the value is populated, this can also be adjusted by clicking the maintain versions button.
ii. Worker must have a period
On the Project tab, in the Set up group, click Project setup
Click edit and select the applicable period code.
iii. Ensure Employee has proper financial dimensions
On the employment tab, select the applicable financial dimensions
iamJoshKnox 