-
Allow negative quantity on Service document
Since year 2005 there is limitation on table 5902 Service line which prevents entering negative quantities. It is on fields Quantity Quantity (Base) Qty. to Invoice Qty. to Invoice (Base) Qty. to Ship Qty. to Ship (Base) Qty. to Consume Qty. to Consume (Base) The code in OnValidate of this fields is if Quantity < 0 then FieldError(Quantity, Text029); We are removing this limitation for last 10 years and the negative quantities are working as expected, e.g. when you are returning old item and shipping new one through one service order. Rest of the code is ready for cases that quantities could be negative. Only limitation is this test, which makes the whole service documents not in line with rest of the system, where negative quantities are working as expected. Now, when using extensions, is this limitation breaking usability of the module and there is no easy way how to overcome this. The idea is to remove this tests or make them possible to handle through handled pattern, making the Service module more in line with rest of the system. -
MFA support in the product (e.g. Outlook addin)
All our customers using BC online are using MFA to secure the environment. But this makes some parts not working. This is bad surprise for the customer, buying the product because these features. E.g. they are unable to use Outlook addin because are unable to publish it. Microsoft should support own security features which is forcing to partners and recommending to customers. All default features which are connecting to Microsoft apps must be able to work with MFA enabled on he used account. -
Splitting Admin role and User role of Delegated users
Right now, thanks to GDAP, partner could ask customer to have Dynamics 365 Admin role in the tenant, to be able to access the BC and support customers.
But for many customers (mostly corporate customers having centralized tenant administration) this brings a problem. In these environments, the administration is done in-house. In this case there is not possibility to assign permissions to partner to be able to connect BC environment as delegated user to support end-users, but disallow him to manage the environments. Another problem is, that in these cases there are multiple BC partners doing support for different environments (e.g. UK, US, CZ environments in one tenant, each "supported" by local partner in the country) and in this case, there is no standard way how to limit each partner to connect only to selected Environment (could be workadounded by removing default permissions for Delegated admin license and let someone assign the permissions when some Partner's user need access). But still, Partner from CZ could easilly delete environemnt of partner from UK (for example).
Possible solutions:
- Split Delegated Admin rights (to access admin portal as delegated admin) from Delegated User rights (access BC environment as delegated user) - it means partner could ask to be admin (D365 Admin role) or user (some new role?)
- Add possibility for customer to assign environments to GDAP Partner relation - it means if environment is created by partner A, it will be maintained by partner A, not B,C etc. and other partners will not have access into it. Customer must be able to assign the Partner relation to the environment (in case of change of the partner etc.)
Possibility 2 is better because the Partner will have access to admin tools like Active Session list, App list etc. and can work with these for environments, which are under his relation.
-
Include implicit Application dependency into output of Get-NAVAppInfo
Since the Application dependency is now implicit (not part of the Dependencies property in App.json but as separate property "Application"), it is not reported as part of the output of Get-NAVAppInfo as a dependency. It means, there is no info about which Application version is supported by given app version. This makes problems in CI/CD when development is done for different versions. In most cases, CI/CD is using Highest dependency policy when using nuget packages, but it leads to situations, when some app is already upgraded to support e.g. newest BC version, but the pipeline is running for some older version (e.g. version of the customer's environment). The pipeline will fail because it cannot install this latest application, because it depends on newer base Application.
Adding the Application dependency into dependencies will help us to create correct nuget packages and filter them based on the supported base Application to only these versions, which are compatible. This will be more critical even for development for SaaS, because if Customer's will not be "pushed" to install Cumulative Updates, we can easily be cough in this trap.
You’re offline. This is a read only version of the page.
