Tadamasa Okada SUPPORT ENG

Definition of the name field of DirParty table is nvarchar(100). But in the EDT definition of name in the CustTable.insert method, the maximum string is 60. Therefore, if we create a DirParty.name with the CustTable.insert method, we can only enter up to 60 digits. This looks like a bug. If we use this method to perform data linkage from an external application in which the customer name is registered in 100 digits to D365FO, the requirements will not be met. We hope this method is fixed.

Definition of the name field of DirParty table is nvarchar(100). But in the EDT definition of name in the CustTable.insert method, the maximum string is 60. Therefore, if we create a DirParty.name with the CustTable.insert method, we can only enter up to 60 digits. This looks like a bug. If we use this method to perform data linkage from an external application in which the customer name is registered in 100 digits to D365FO, the requirements will not be met. We hope this method is fixed.

Older types of licenses don't allow the customer to assign licenses to specific users, while newer types of licenses allow them to assign licenses to users from the Microsoft 365 admin center. Therefore, it becomes very complicated to manage for customers who have two types of licenses, the old type and the new type. As a way to solve this, we would like Microsoft to be able to license users from the Microsoft 365 admin center even with older licenses, or implement other solutions.

Description: Currently, the table browser can only be used in Tier 2 and Production environment with read only permissions in SYSADMIN role. Ask: The customer want to use the table browser in Tier 2 and Production environment with write permissions instead of read only in SYSADMIN role. Justification: The task of deleting unnecessary data in Tier 2 and Production environment can be made easier by using the table browser. The implementation of this feature makes the administrator's operation easier.

When set System administration > Workflow > Workflow parameters > General > Approver > Disallow approval by submitter to Yes, the customer can specify a submitter on a final approver. If the customer execute workflow with a submitter as a final approver, workflow will fail with an error after execution. But it's inconvenient for the customer because they won't notice this mistake until after they execute it. Expected behavior: When "Disallow approval by submitter" on Workflow parameters is set to Yes, the customer unable to specify a submitter on a final approver. Also, when executing workflow with a submitter as a final approver, an error message is displayed and it cannot be executed. Actual behavior: When set System administration > Workflow > Workflow parameters > General > Approver > Disallow approval by submitter to Yes, the customer can specify a submitter on a final approver. Also, if the customer execute workflow with a submitter as a final approver, workflow will fail with an error after execution.

If D365BC user enter a value less than 0.01 in the decimal type field, it will be completed with 0s up to 20 decimal places. For example, when the customer has entered 0.0099 in the decimal type field in Item card and exposed a page as an OData web service, it returned [0.00990000000000000000]. Therefore, extra work is required when getting D365BC data with Odata and linking the data to an external application with the string type. Expected behavior: Odata Web Service return "0.0099" Actual behavior: Odata Web Service return "0.00990000000000000000"

After updating Dynamics 365 BC online to version 17.0, we can no longer enter 0 for no. Of minutes between runs and it will be reset to 1440. Therefore, since the start time of the next job will be 1440 + processing time, we can't predict when jobs in the job queue will end, and in some cases our works will stop. as it will waste our business time, we would like to be able to enter 0 for no. Of minutes between runs.

Japanese customer and partner hope POS of Dynamics 365 commerce supports stamp duty. Stamp duty is the tax governments place on legal documents, usually in the transfer of assets or property. See for more information below. https://www.investopedia.com/terms/s/stampduty.asp#:~:text=Stamp%20duty%20is%20the%20tax%20governments%20place%20on,needed%20to%20legally%20record%20certain%20types%20of%20transactions. In Japanese POS, for example, when a payment that is subject to stamp duty is settled by POS, a mark indicating that this payment is stamp duty and a space to put a stamp are printed on the receipt. there is no such a feature in POS of Dynamics 365 commerce right now, However, it is a feature that is always used by some Japanese retailers (convenience stores), so we hope that this feature will be implemented POS of Dynamics 365 commerce in the future.

Even if the customer enter the same data that already exists in Entity using Excel add-in, no error or warning will occur. If there is duplicate data in Entity, the environment update will fail. Therefore, it is a bad behavior to have no restrictions on data entry using the Excel add-in. We hope to implement restrictions on data entry using Excel add-in to avoid duplicate data.