If you have worked with Docentric AX in Dynamics 365, you have already met the DDSP (Docentric Data Source Packages) file, even if you did not notice it. It is one of those quiet helpers doing a lot of work in the background.
Let’s make it simple: A DDSP file is a dataset formatted for Docentric. The Docentric engine can work with different kinds of datasets, but this one is specifically formatted and implemented for Dynamics 365.
It defines which data is available and how it is structured, so the Docentric AX Designer knows what data can be used when building a report template. That version is called the design-time DDSP. It is the one you use when creating or updating a template.
Once the template is ready and you run the report in Dynamics 365, another DDSP takes over. This is the run-time DDSP. It carries the real business data and fills your template to generate the final document.
In short, the design-time DDSP helps you build the template layout. The run-time DDSP fills that template with real data when the report is executed in Dynamics 365 Finance.
Why These Two DDSPs Can Look Different
Sometimes users notice that the report output in Docentric AX Designer does not match what they see when running the same report in Dynamics 365.
This happens because the design-time and run-time DDSPs are not always identical.
That does not mean something is wrong. It simply depends on the actual data available in your system.
In standard SSRS reports, such as Sales Invoice or Purchase Order, several line types like transactions, taxes, prepayments, and charges are stored in one shared table called SalesInvoiceTmp. This setup works fine for developers but not for template designers who want to display each line type separately.
To solve this, Docentric reshapes the data.
In our replica DSP classes, we split that large table into clear, separate record groups.
This process is called reshaping, and it makes the data easier to understand and use in the Docentric AX designer.
However, not all documents contain every line type. For example, an invoice might only have transaction lines and no taxes or charges. If we only used real data, those missing groups would not appear in the DDSP. That would break the field bindings in your Word template.
To avoid this, Docentric adds a dummy record for each missing group when creating the design-time DDSP.This record is empty but keeps the structure complete so you can bind all fields.
When creating the run-time DDSP, Docentric does not add dummy records.
It includes only real data, exactly as it appears in the report.
That is why the two DDSPs can look different.
What Happens in the Background
Both DDSPs start the same way. The SSRS engine collects the data, and the Docentric engine takes it and converts it into a DDSP structure. This process is called serialization.
When you export a DDSP to design a template, the structure is saved as a file, downloaded through your browser, and then loaded into Docentric AX Designer. This is the design-time DDSP.
When you run a report in D365FO, the same process happens again, and everything runs in memory. The Docentric Engine creates a run-time DDSP, merges it with the Word template, and produces the final output as a Word document. Docentric always creates the Word file first and then converts it to the desired format, such as PDF.
Design-Time Flow
SSRS Engine → Docentric Engine → design-time DDSP → Browser Download → AX Designer
Run-Time Flow
SSRS Engine → Docentric Engine → Run-time DDSP (in memory) → Word Template → Word Document → PDF Document
Both flows start the same way but have different goals.
Why This Difference Matters
Understanding how and why these two DDSPs differ can save a lot of time when designing or troubleshooting reports. If your run-time DDSP looks incomplete, it usually means that the data simply does not exist in that specific document, but it may be available in other documents. Nothing is missing. It just was not present in the data source.
Design-time DDSPs show everything that is possible.
Run-time DDSPs show what is actually there.
Both are correct and serve their purpose.
How to Compare Them
To complete the dataset, we need to get both DDSP files. Once we have them, we can compare and see the differences.
First, let’s download the design-time DDSP file. There are two ways to generate it:
Enable the Generate DDSP when report runs flag in the report setup under Data Source, or
Use the Print Destination called Generated DS to generate the DDSP file.
Both methods will produce an identical DDSP file that you can use for template design.
When it comes to the run-time DDSP file, it’s stored in memory. To capture it, we can use the Docentric Tracing Framework, which helps us understand what happens when a report runs in the background.
If you want to see exactly what data the report uses at runtime, enable the Trace DDSP option.
This allows you to download the run-time DDSP file directly from your browser when the report runs.
Once you have both DDSP files (design-time and run-time), you can open them in your favorite text editor and compare them to find the dataset or field causing the issue. For example, you can check if certain fields are present and what values they hold.
Please note that the run-time DDSP is not meant for report design, so you will not be able to load it directly in the Docentric AX designer.
The Takeaway
The DDSP file is not just another export. It is the key connection between Dynamics 365 data and your Docentric templates.
The design-time DDSP helps you design confidently by showing all possible data. The run-time DDSP keeps your reports accurate by including only real data.
So if your report looks different in Docentric AX Designer than it does when you run it in Dynamics 365, that is not an error. It is simply one face of the same process.
Design-time helps you build. Run-time helps you deliver.
Two faces. One goal.