Hello and Willkommen (german; english: welcome) to our 20th Episode of the Project Operations Advent Calendar. It feels like a small milestone but also very close to the end 🎅🏼
Project Operations - better integrated
Project Operations is a Dynamics 365 Business Application. So the whole world of Power Apps and Power Platform is eligible for integrations and extensions.
In the special case of Project Operations, Microsoft delivers an out-of-the-box integration with Dynamics 365 Finance. Based on Dual-Write an additional deployment scenario is available on top of the CE (Customer Engagement) and Finance only version.
Microsoft's Project Operations is now the first product that offers cross-platform capabilities, specifically in the areas of CE and Finance.
In addition to the default deployment option for the integrated scenario, it is possible that the target or source environment may not be related to D365 Finance, but rather any other ERP environment available in the market.
It is also possible to connect and integrate any type of existing environment or software, like a tool for time recording and absence handling.
If you can access an API and obtain the necessary information or transfer the data into Dataverse through Cloud Flows, Excel (.csv), or other means, then you are all set.
BYOS - Bring your own Scheduling
Bring your own Scheduling emerged with the further integration of Project for the Web in Project Operations. For use cases and Projects disconnected from Microsoft's scheduling engine, a potential integration to any other scheduling is available.
In this case even potentially available per Project, so project managers will be able to decide if they want to move on with the out-of-the-box Project for the Web integration or a custom logic.
The custom logic does not necessarily have to be an integration but if the client may already have access to a similar scheduling engine, it might be easier to connect.
With the BYOS feature, the Project for the Web (PexWeb) control will be disabled and all validation and logic on the Project Task level won't apply anymore.
There is no verification to ensure that the Start date comes before the End date, but there is also no computation for the Duration or Effort.
Be aware of these conditions, you will lose not only the planning control itself but also full validation of your project structure - on the other hand, this will enable Project Operations functionality and logic with your desired project planning interface.
In order to utilize the custom scheduling method for the project, the Scheduling Engine flag must first be visible.
Note: For already existing Projects there will be no option to change this behavior. Only on creation, this option will be available to set.
Once set, this Project will be disconnected from the Microsoft Scheduling Engine.
The field is hidden by default on the Project form. The best practice here is to create a copy of the default form first, before making any changes.
Integration for Sales
Another common integration for Project Operations happens on the Sales side. Project Operations is might not the first Business Application and has to be integrated into an existing Sales Process - unrelated if this happens in the Dynamics 365 context or not.
Crucial for Sales-related data is the Project Contract (salesorder), which should be always in place if any Sales-related logic is required. Even if the process doesn't call for a Project Contract.
The Project Contract in Project Operations is the same table representing the Order in the default Sales Process.
Despite sharing tables like Opportunity, Quote, and Project Contract / Order, a Sales Opportunity and Project Operations Opportunity are not exactly equal.
The difference is quite detailed but significant. If the field Order Type (msdyn_ordertype) equals Work based the system automatically considers the Project Operations form, features, and rules.
The default Sales Order Type is Item based.
A recommendation here - Project Operations Orders (Service Orders) will also cover the known Product Catalog features. Starting from scratch it should be considered only creating Opportunity, Quote and Project Contract records with Order Type = Work based.
On integrating into an existing Dynamics Sales process, either the current Sales data needs to migrate to the Work based Order Type to enable Project Operations features, or both processes should remain separated.
Alternatively, the Project Contract can be also created in the background and linked with the Project. Switching up the Type later in the process is not possible.
For integrating an external Sales process, e.g. any ERP, the overall process needs to be clarified first.
Often only won Opportunities / Quotes are considered, because it won't be necessary to track lost / closed records in a new system. Consequently, the process in Dynamics could directly start with the Project Contract.
It is necessary to maintain the Order Type again, as well as define a potential mapping between values from the ERP to the mandatory fields in Project Operations:
Name
Account / Customer
Sales Price List
Contracting Unit
Currency
Besides the Project Operations fields, all ERP-related data can be tracked as custom fields on the desired table. That extension at this point is handled as usual and any other Order extension that would be performed on the Sales side.
From the Order / Project Contract, the out-of-the-box process should be followed - creating and linking the Project on the Project Contract Line level, before starting the project planning phase.
Quote and Opportunity are not required for the Project Operations process and could be skipped for the integration process.
Integration for Invoicing and Accounting
When talking about an ERP integration to receive Sales data, there is most likely also a process to extract the data from Dynamics back into the ERP.
But also covering the Invoice-facing processes can be part of this integration. Especially in Germany and neighboring countries, an additional accounting/invoicing platform is quite common.
Generally speaking, Project Operations offers decent capabilities when it comes to invoicing. But don't expect a full-fledged tax engine or country-specific regulations. This is and should always be part of the ERP side of the process.
For an integration to pull data from Dynamics to a target environment, two common options are available.
One option on the Invoicing level - here a pro forma invoice will be created with all the approved services and product fees. The invoice is created in the Dynamics environment and receives values like Invoice ID, Document and Billing Date, and so on.
This kind of invoice functions as an initial draft to review including time entries, expenses, and materials. After the sign-off the data necessary to create the real invoice e.g. the ERP will be pushed to the very same.
Adding such a quality gate to the process can help to identify potential issues and left-out values before the data reaches the potentially more complex ERP environment.
Such a controlled and approval-required synchronization is preferred for a lot of client scenarios.
The second option is to push the data to the target environment a bit earlier in the process - with the Actuals.
Actuals are created by the system after the Approval. Depending if intercompany charges are available, there can be up to four Actuals to track all Sales and Cost efforts.
These Actuals contain all necessary billing and accounting data, including custom extensions and calculations which are considered for the customer-facing invoicing.
The values can be grouped or synchronized individually to the target environment, to ensure correct numbers and indicators for the invoice cycle on the e.g. ERP system.
The Dual Write-based integration will use Actuals to transfer information to Dynamics 365 Finance.
Integration for historical data
Another recurring use case of integration to Project Operations is the migration of historical data, especially with a focus on Actuals and Time Entries / Expenses.
Particularly for clients who used a similar tool before, running Projects that have to continue with their related historical data in the new system.
Because out-of-the-box Project Controlling options are based on the Actual values, these records qualify perfectly for the migration scenarios.
In order to save storage and make evaluation of past values more accessible we recommend aggregating Actuals on a Monthly and optional Project Team Member level. In the minimal approach, the Project will receive only one Actual per Month of past data.
Why not use Time Entries directly?
In certain situations, using the Time Entry function may not be the most practical option. If an alternate system is utilized for Time sheet management, it is still recommended to import information at the Actuals level.
Time Entries have a limitation of 24 hours per record. That limitation also applies if the time entry would stretch over several days. The imported data usually gets aggregated for a week/month in one record.
Additionally, when using historical data or external time tracking software, the data is probably already approved and represents validated data. Time entries cannot be created in any other state than draft and it would be necessary to be submitted and approved in the Project Operations System again.
If any of these quality gates happened in the source environment, you don't want to force the user to redo these steps.
From a data model perspective, the ERP data has to be mapped to the corresponding Actuals, including the Transaction Type that differentiates Sales and Cost positions and the Transaction Class that defines if the record is based on Time (Time recording), Expenses, or Fee values. The Quantity defines the duration, while the Unit determines if we talk about hours or something else.
Here it would be also possible to track the Unit in Days, depending on the data from the source environment.
Establishing the connection between Bookable Resource, Project, and the Project Task, will make the values available for Project controlling and tracking. Please make sure the Bookable Resource is also part of the Project Team, so every hour can be recorded correctly.
In terms of the currency on Actuals, it will be surely possible to mix them at some point. My recommendation is to stick to a single currency per Project and Order. Just to keep the topic of currency conversion off your chest - this will only add more layers of complexity.
A further common approach for integrating any data is creating a custom import table for each table that gets imported first to do certain validation and quality checks.
An illustration to consider is the creation of an Account. The initial step involves the development of a custom table called "Imported Accounts" where fresh data from the interface will be produced.
Plugin-based validation or manual sign-offs can happen right there without having invalid or unwanted Accounts accessible for the end users.
Working with data always requires prioritizing data quality.
Overall you have plenty of scenarios and options to integrate existing structures and processes into Project Operations or enrich your existing ones with the Project planning tool.
It is crucial to remember that the foundation and basic data setup for the Project, including the Project Contract and associated Project-based lines, Price Lists, and the Actuals table for authorized services, should always be revisited. This will serve as your primary point of connection.
Establishing your desired tools is possible as long as you adhere to that data model.
I hope you enjoyed today's episode, sorry it was more text and fewer pictures today than usual 😅 many thanks from my side for stopping by 😊🎅🏼
Comments