Project Operations Lite version 4.58.0.123
The time-zone agnostic price defaulting capability was introduced in the September 2022 update for the lite and resource/non-stocked deployments of Dynamics 365 Project Operations. The core idea of the capability is for pricing of time entries, basic expense entries, and material usage logs to default based on a new column called Transaction date (msdyn_transactiondate). While this solves some pricing and date-related issues with price lists, the big value in this capability is in the time-zone agnostic column for a transaction’s date. Before you read on, be sure to check Learn for the official docs article here.
The challenges with transaction dates
Time entries and project approvals in Dynamics 365 Project Operations are notorious for using a column called Date (msdyn_date) to display the date of a time entry. The behavior of this column is set to User Local OOTB. While Learn states that behavior can be changed once, changing the value in Project Operations isn’t recommended, as I’ve previously written in this post. With User Local behavior, the database value of the date column naturally reflects the time zone of the user who created and submitted the time entry. This means that as I’m in UTC +2, the date column will have a database value of 2022-12-25T22:00:00Z for any time entries and project approvals that I’ve created for the 26th in ProjOps. If DST is applied, it will also have an impact on the time component.
What about columns that display dates related to the original transaction on actuals and journal lines? All these columns are User Local in behavior, so you can already guess where I’m heading with this. When, in my example, the date of a time entry is the 26th of a given month in the UI, and the entry is submitted and approved, the resulting journal lines and actuals will hold the following values in the date columns related to the transaction.
| Table | Column | Value |
| Journal Line | msdyn_accountingdate | 2022-12-25T22:00:00Z |
| Journal Line | msdyn_documentdate | 2022-12-25T22:00:00Z |
| Actual | msdyn_accountingdate | 2022-12-25T22:00:00Z |
| Actual | msdyn_documentdate | 2022-12-25T22:00:00Z |
The conclusion naturally is that a time entry created for the 26th of a given month has a transactional date value for the 25th. This is simply put extremely bad because there’s no consistency between what a user has inserted in the UI (TE grid, basic expenses, or material usage logs) and what is displayed as a transaction’s date on a related journal line and actual. This is where the huge upside of the new time-zone agnostic price defaulting capability comes into the picture.
Transaction date to the rescue
The Product Group has introduced a new column called Transaction date (msdyn_transactiondate) as part of the new time-zone agnostic price defaulting capability. This column is used to save the time-zone agnostic value of a transaction’s (time entry, basic approval, material usage log) date. This way, we finally have a means of getting our hands on the actual value of the transaction that a user entered in the UI. In my example, the value in msdyn_transactiondate on a journal line, an actual, and an invoice line detail would be 2022-12-26, since my original time entry was entered for the 26th in the time entry grid.
While the transaction date column can help organizations using the lite deployment align their transactions with the correct date, organizations running the integrated deployment still have to keep biting their tongue. In F&O, the date of the transaction is the same as the transaction date of the original actual. In my example, it is the 25th. The transaction date can be seen in the Project Operations Integration Journal as well as by looking at staging tables.
While the transaction date column is a relief for lite deployments, integrated deployments still suffer from the discrepancy between what was punched in the UI and what comes out at the end of the process in F&O. What are some ways you’ve solved this discrepancy in your implementations? Leave a comment below to share your experiences with transaction dates for time, expenses, and materials.