-
Modify Dataverse UI to allow multiple F&O virtual entities to be made visible at once
Admin reference for enabling F&O virtual entities in Dataverse - https://experience.dynamics.com/ideas/idea/?ideaid=5a367fe0-b8cd-eb11-ba5e-0003ff45ac2b - makes it clear that each entity that the administrator wishes to enable must be opened individually & made visible with its own checkbox. From a user experience perspective, it would be (significantly?) quicker if the "Available Finance and Operations Entities" results lists had the visibility checkbox editable in-grid to allow for multiple entities to be made visible as one action. -
Importing unmanaged Power Apps solution should provide more explicit guidance on missing dependencies
When moving an unmanaged solution from one environment to another (perhaps via source control), an administrator may encounter errors on import referring to missing dependencies (example below). The error message refers to versioned packages which are present in D365 Apps, but there appears to be no explicit way of identifying which package is contained in which app (the documentation on this point - https://docs.microsoft.com/en-us/powerapps/maker/data-platform/import-update-export-solutions - states that there will be a link available to install the app, but that's not my experience). It would be helpful if the error message either (a) explicitly stated which app should be installed to resolve each dependency or (b) included a link to a list that allowed the user to identify the app that contains each package. ---- There are missing dependencies. Install the following solutions before installing this one: "Dynamics365Company (2.2.2.5)", "Dynamics365FinanceAndOperationsCommon (2.2.2.50)", "Dynamics365FinanceExtended (2.2.2.98)", "FieldServiceCommon (1.0.0.134)", "Dynamics365SupplyChainExtended (2.2.2.98)", "HCMCommon (2.2.0.3)" ---- -
Provide more meaningful error messages when Cloud-hosted environment deployment fails
We recently encountered two errors when attempting to deploy cloud-hosted environments within LCS. (1) "Lifecycle Services cannot perform the current {0} operation. Received null or empty value for parameter {1}" Diagnosis was that we were accessing LCS with an account in a different AAD domain than the Azure subscription tenant. It's possible this would have been more apparent if the string formatting placeholders "{0}" and "{1}" had been populated with more meaningful values. (2) Failed to fetch deployment error from outputXml. Diagnosis was that the VNet selected for "existing network" in the environment "Advanced Settings" was associated with an NSG that didn't have the required Remote PowerShell ports open. An error message such as “Remote PowerShell connection could not be established”, or even the slightly vaguer “Remote PowerShell script could not complete” would give LCS users a better chance of establishing the problem -
HR/Finance infrastructure merge should provide "Open positions" tiles on Manager self service regardless of HR parameter "Recruitment experience" option
D365 HR standalone allows managers to see Open positions - Extended reports and Open positions - Direct reports tiles within the Employee self service > My team tab. Following the infrastructure merge, it feels reasonable to expect that the same HR functionality would be available when using the Human resources parameters > Recruitment > Recruitment experience option HR recruitment, but that's not currently the case. The tiles are visible when the Recruitment experience option Recruitment projects is configured, but that impacts the way recruitment processes and requests are managed such that it's not as feature-rich as HR recruitment. The tiles should be included in both experiences, even if different data sources are relevant.
-
Project funding source data entity error messages could be more helpful
The "Project funding source" data entity (staging table ProjFundingSourceStaging) seems to require the "PartyNumber" field populating: when left blank for an import project, the error message below is logged.
"Results. The party ID specified does not exist. Results. validateWrite failed on data source 'ProjFundingSource (ProjFundingSource)'"
However, for records where the "FundingType" field is "Customer", it doesn't use that "PartyNumber" field for the customer lookup, but instead uses the "CustomerOrganization" field. This makes the message at best misleading, if not plain wrong: if the value isn't going to be used, it shouldn't fail validation when left blank.
Process:
- Ensure you have two customers, and identify their customer number & party number
- Ensure you have a project contract created
- Create a DMF input file for the Project funding source data entity specifying the project contract above & the customer number for one customer in the CustomerOrganization field and the party number for the other customer in PartyNumber
- Import through DMF
- Review the project contract
- Observe that the funding source added has used the CustomerOrganization field for the associated customer
- Create a copy of DMF input file, modifying it by removing the PartyNumber and changing the FundingSourceID
- Import through DMF
- Observe error The party ID specified does not exist. even though DMF isn’t going to use the party ID in question
-
Project funding source data entity error messages could be more helpful
The "Project funding source" data entity (staging table ProjFundingSourceStaging) seems to require the "PartyNumber" field populating, reporting the error message below when a DMF import project does not include a value:
"Results. The party ID specified does not exist. Results. validateWrite failed on data source 'ProjFundingSource (ProjFundingSource)'"
But then for records where the "FundingType" field is "Customer", it doesn't use that "PartyNumber" field for the customer lookup, but instead uses the "CustomerOrganization" field. I appreciate the validateWrite method above is on the ProjFundingSource table which will be reached through code paths other than the data entity, but I believe that just means the data entity/DMF should handle the scenario earlier, i.e. by using the Party ID for the customer.
Demonstration process:
- Ensure you have two customers, and identify their customer number & party number
- Ensure you have a project contract created
- Create a DMF input file for the Project funding source data entity specifying the project contract above & the customer number for one customer in the CustomerOrganization field and the party number for the other customer in PartyNumber
- Import through DMF
- Review the project contract
- Observe that the funding source added has used the CustomerOrganization field for the associated customer
- Create a copy of DMF input file, modifying it by removing the PartyNumber and changing the FundingSourceID
- Import through DMF
- Observe error The party ID specified does not exist. even though DMF isn’t going to use the party ID in question
-
Registration numbers data entity validation messages should be more specific
The data entity Registration numbers fails to insert records to the TaxRegistrationLegislativeStaging table, reporting the generic message The data value violates integrity constraints, when either the PartyNumber or LocationId fields reference records that aren't found in the relevant parent table. Would it be possible to make the message more specific?
-
The same TZID offset should be stored in back end tables regardless of how a form that addresses tables is created
LCS support call 2305020050002383 was raised with the observation that a single personnel action (hiring a worker and assigning them to a position) results in different TZID offsets being stored across the three backend tables HcmPositionWorkerAssignment, HCMEmployment & HcmEmploymentDetails, with the first storing the users' timezone preference, whilst the second & third always store the UTC timezone despite the datetime values to which the offset is applied all holding the same value. As such, any application of the timezone across the tables would result in different offset values.
I'm told that this is because the form for HcmPositionWorkerAssignment is created through X++ form designer, with that engine handling record creation, whilst the HCMEmployment & HcmEmploymentDetails forms are created in code. This distinction doesn't clearly explain why a different offset would be desirable, so it seems reasonable to aim for consistency.
-
Document template form should allow multiple templates for the Open lines in Excel menu
Previously logged as an idea directly under the D365 Finance category - https://experience.dynamics.com/ideas/idea/?ideaid=33f8c142-9af2-ec11-b5cf-0003ff45834c - MS support suggested it's appropriate here. Within F&O, the Document template form allows custom templates to be uploaded for any LedgerJournalTable menu item (GL, vendor invoice journal, vendor payment journal, etc.). The UI gives the impression it's possible to have multiple distinct options, but they'll all point to the single customer/override template.
The extension to provide a custom Template ID which retains the standard system template - https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/user-interface/add-templates-open-lines-excel-menu - is relatively small, but given the UI appears to allow multiple templates, it would be nice to have this ability back.
-
Customer free text invoice data entity should support specifying invoice & delivery address
The Customer free text invoice data entity is a denormalised entity for creating Accounts Receivable/Sales Ledger invoices that doesn't provide all functionality available within the UI. Within the UI, when creating an AR invoice, it's possible to select from the customer's recorded addresses which should be used as the Invoice address (to which the invoice is sent) and/or the Delivery address (to which the product/service should be provided). The data entity would be more useful if it included fields to specify the two address fields, ideally by a user-meaningful value like Name or description, but Address location Id might be sufficient for some use cases. If these fields are blank, the current functionality to use primary address could be the default position, but if populated, DMF should change the address on the invoice header