27

Thanks for extending the concept of Attributes from the Product information/Procurement module to HR module. 


It will really be good to have this functionality available for Master Data as well. Although D365 has come a long way with functionality we still need to go through development effort for simple custom fields that client want on master records at implementation stage. 


It will be really good to have an ATTRIBUTES fast tab, like in 'Product Configuration model' fast tab, which allows the definition of attributes for each of the master records. This will save a large amount of development during implementation where the client want a few additional fields added to the standard D365 fields  with the option of making them mandatory for selection. 


 


This can be started initially with say the CUSTOMER, VENDORS, PROJECT CONTRACTS and PROJECTS and then extended to Purchase Order and Sales Orders in the Future. 

Category: User Experience
STATUS DETAILS
Under Review

Comments

K

Excellent idea - very much needed by our Company for Vendors, Customers, all Address Book records.
We're using Product & Channel Attributes and see this as a basic requirement that would be ideal to be met with standard functionality.

Category: User Experience

K

Thanks

Category: User Experience

K

Well if it is already there for RETAIL / HR/ PRODUCT MANAGEMENT/ PRODUCT CONFIGURATION/PROCUREMENT(is even available for Free Text invoicing when you use 'Billing code custom fields') Why is it missing from the rest? It sounds to me all the underlying artefacts are already there... and some thinking to improving performance and considerations around UI should already have happened for the ones that already have it...


 


A well thought-out vision can allow the same tables to be used for all, with the necessary filtering on based on the master entities or records within each table.


In a Cloud provision as current with D365 operations, why should each customer continue to make changes to the application which can be solved with simple extension of functionality that already exist. 


 


And lastly, Dynamics 365/AX is the only ERP outside its competitors that is missing this functionality on master records and other main documents.  This is way overdue, is a bit like the days where AX was missing document branding. Customers couldn't believe why the product did not have any inbuilt mechanism that allowed them to make the necessary changes instead of being charged huge fees for development (think about the development cycle and costs...functional spec, technical specs, develop, unit test, functional test, UAT, deploy...not even thinking yet of extending each field to data entities, etc). It sounds a simple thing to do if you were to custom develop it, but if you think about what normally happens in real implementation, why would you want to go through the pain of the whole cycle just because the client want maybe 5 simple fields on a master project/customer form? A better vision for 365 operations is to extend this functionality and make it available across the product. 


 


 


 

Category: User Experience

K

If adding a few fields requires a large amount of development, something is wrong with the implementation project and that's the problem that should be fixed (not the product).


While I understand that users want to set up more things by themselves, adding such a model isn't for free. It means more complex data model - more joins (worse performance), more complicated UI, more code to contain bugs, more complicated data entities and so on. Just adding a field is usually more efficient.


I think there should be a stronger business case for this requirement than a problem with a development team.

Category: User Experience