Custom fields on DDSP file

D365FO
1

Is there a limit to the number of custom fields that should be added to a DDSP file?

Wondering about adding a large number of additional fields (potentially 100+ custom attributes) to a Purchase Order Confirmation DDSP and whether there are any concerns or best practices related to:

  • DDSP generation performance

  • Report execution performance

  • Template Designer usability

  • Long-term maintenance

2

Hi @KM12345 ,

Welcome to our community!

Before we advise further, could you please tell us a little more about your scenario? In particular, it would be helpful to know where the 100+ custom attributes would come from and whether they are simple table fields or values that require additional calculations, queries, or display methods.

It would also be useful to know whether all of these fields are expected to be used in the same template, or whether only a subset would be used depending on the scenario.

In the meantime, the following articles may be useful:

Once we understand the data source and usage pattern a little better, we can give you more specific guidance regarding performance and maintainability.

3

Hello! @NatasaKA

Yes, these fields are mainly based on released product attributes and additional tables linked to a specific item. It would mainly be displaying the attribute value, no calculations needed. Based on the Purchase order line, the field would display the associated attribute to the item. These fields would not be expected to all be used in the same template but would depend on the scenario. Let me know if additional information is needed!

4

Hello @KM12345,

There is no specific limit on the number of custom fields that can be added to a DDSP, so having 100+ fields is not itself an issue. Based on your description, where the fields mainly display existing product attribute values and no calculations are involved, I would not expect the number of fields to cause a significant performance concern.

The main consideration would be how efficiently this data is retrieved. As long as it is fetched efficiently and does not result in unnecessary database lookups for each field, the approach should be reasonable. Since not all fields will be used in every template, this is also not necessarily a concern from a report execution perspective.

The main trade-off is the maintenance of the template in the Docentric AX Designer, as a very large data source can become harder to maintain. We would therefore recommend adding the fields that are expected to be useful and grouping/structuring them logically where possible.

Also, usual best practices for standard D365FO development apply here as well. This how-to manual will be a good guide on best practices when customizing your DSP class: How to Customize Docentric SSRS Replicas.

Weā€™re here if you have any further questions!

1 Like