Implementation Methodology

This page describes how to deliver Docentric AX on a D365FO project, end to end. It is organized into five stages:

1. Set up the environment and tooling
2. Analyze and decide – scope, approach, template strategy, and storage
3. Build and prove the first report, then repeat the pattern
4. Distribution – print destinations and Print management
5. Test, release, and hand over

The stages are a sequence, but not too rigid. In particular, Build (Stage 3) and Distribution (Stage 4) run together in practice – you configure distribution for each report as you build it. Some activities (scope, distribution requirements, Print management) are part of any D365FO implementation; where that is the case, this guide focuses on what Docentric adds or changes rather than repeating standard project practice.

The guiding principle throughout: implement one representative report end to end, document the pattern, then apply the same pattern across the rest of the document scope.

Stage 1: Set up the environment and tooling

1.1 Prepare the D365FO environment

Install the Docentric AX Framework in the appropriate D365FO development or sandbox environment. (Prerequisites, model list, and version support are in Before You Start.)

• Install the models. Start with the core four: Docentric AX, Docentric AX Extension, Docentric AX Emails, and Docentric AX SSRS Replicas. Install them via scripts or manually.
• Apply the license. Unlock the product with the appropriate license. Note for partners: do not use your partner license in client environments.
• Load the system templates. They ship as AOT resources with the Docentric AX SSRS Replicas model. In the Docentric AX Workspace, click the Reports tile and confirm the prompt to load them. This adds around 80 entries to the Docentric AX report setup form, each configuring an SSRS report/format combination with its matching Docentric replica template.
• Verify the out-of-the-box install. Reprint one test report that has not been customized – Purchase order confirmation is a good choice. Use Preview/Print > Original preview - it should automatically use the Docentric replica template. If you cannot see a difference from the standard SSRS output, enable the Discover report technical name option and re-preview – the info message confirms which template was used.
• Configure security roles. Decide who will work on templates, setup, and technical extensions, then assign the relevant Docentric security roles and confirm users can reach the Docentric forms.

Useful references: D365FO installation guide, Docentric AX parameters, Docentric AX reports setup.

1.2 Prepare local machines for template design

Install the Docentric AX Designer (Microsoft Word with the Docentric Add-in) on the machines used for template design. Requirements and the reason the Add-in is mandatory for data-bound content are covered in Foundations. After installation, confirm Word shows the new Docentric AX or Docentric ribbon tab.

Stage 2: Analyze and decide

This stage produces the decisions that shape everything later on: what is in scope, how each report will be implemented, and how templates will be owned, stored, and versioned.

2.1 Define the document and report scope

Defining scope is a standard part of any D365FO project, but do it early and capture, for each report or business document:

• business process,
• path to reprint the report (useful for testing),
• report name and technical SSRS report name,
• legal entity scope,
• language requirements,
• branding requirements,
• output format,
• print destination requirements (email, printing, archiving, integrations, attachments),
• additional data requirements,
• ownership of the data source and template design after go-live (this drives the approach decision in 2.2).

Capture the distribution requirements here too, even though you configure them later in Stage 4. Discovering them late is a common cause of rework.

A common starter set (the exact set depends on the customer's processes, country, localization, and scope):

• Invoices: Sales invoice, Free text invoice, Project invoice
• Purchase order confirmation
• Sales order confirmation
• Packing slip
• Customer account statement
• Vendor payment advice
• Check
• Collection letter

2.2 Choose the implementation approach for each report

For each document, decide three things: the data source type, how you will maintain the data source, and the format starting point. Answer these questions first:

• Do you anticipate data source modifications? Are they simple (for example, adding existing table fields) or complex (adding lists of transactions, complex calculations, external integrations)?
• Who will implement and maintain the data source: project team, support team, or customer, and do they have the right skills (developers, ER specialists)?
• Do you anticipate format modifications? Does a Docentric replica exist for this report, and is it close to the required result?

Then work through the decisions:

DECISION 1: Data source type

Decide between an SSRS-based and ER-based data source.

SSRS-based data source gives you full X++ flexibility for complex data requirements. Choose it if:

• Developers are available, while ER specialists have little or no experience.
• Complex data source needs are identified.
• SSRS-based customizations have already been done before introducing Docentric.

ER-based data source enables the configuration-based approach, without coding and without deployment. Choose it if:

• Simple to moderate data source needs are identified.
• Experienced ER specialists are available.

DECISION 2: How to maintain the data source

Decide between the Docentric pattern, SSRS pattern and ER configurations.

Docentric pattern is based on implementing or extending Docentric DSP classes. It is usually an optimal choice, preferred by developers. Choose it if:

• You use the SSRS-based data source. This is a default choice for most developers.
• You use the ER-based data source, but the requirements turn out to be more complex than anticipated. With no experienced ER specialists, but developers available, the Docentric pattern is the better choice.

SSRS pattern is a standard D365FO pattern for modifying the SSRS data source, by extending the RDP tables and DP classes (or, less frequently, queries). You might want to choose this option if:

• The report has already been customized before you introduced Docentric. Therefore, you have already extended multiple SSRS-related artefacts, and it makes sense to keep maintaining them. Alternatively, if you haven’t made too many changes so far, you might want to consider moving the implementation to a DSP class and continue to use the Docentric pattern.
• You have just started your first Docentric project and are still not familiar with the Docentric pattern, but you are under time pressure to deliver the report. In that case, it is perfectly OK to pick the SSRS pattern. Once your developers feel the simplicity of the Docentric pattern, they will never want to go back to the SSRS pattern 😊.

ER configurations are the default choice if you decide to use the ER-based data source, based on the expected complexity of the requirements and experience  of your ER specialists.

DECISION 3: What is the format starting point

Decide between the Docentric replica template, Docentric template from scratch and ER format.

Docentric replica template as a starting point guarantees the fastest results. It can be combined with all three data source maintenance techniques selected in the previous step. Choose it whenever:

• Docentric replica template is available for your report, and
• The replica is close enough to the expected result, so no serious rearranging of the layout is required.

Docentric template from scratch is an alternative to the first option if you want to use Docentric templates. Just as when starting from the existing replica design, you can combine it with all data source maintenance approaches. Choose it if:

• A Docentric replica template for the report isn’t available, or
• The replica design is too different from the target layout.

ER format completes the standard ER pipeline. It can be combined only with a pure ER-based data source that is maintained through ER configurations. Choose it if:

• Minimal design changes are anticipated, and
• ER specialists are available.

You can mix and match approaches across reports. One possible outcome:

Report	Data source type	Data source maintenance	Format starting point
Sales order confirmation	SSRS	SSRS RDP + DP extension (previously already done)	Docentric SSRS replica template
Sales invoice	SSRS	Docentric DSP extension	Docentric SSRS replica template
Collection letter	ER	ER configurations (minimal changes expected)	Docentric CBD replica template
Purchase order	SSRS	Docentric dSP extension	Docentric template from scratch

2.3 Define the template strategy

Before creating many templates, agree on:

• who owns templates during implementation, and after go-live,
• where templates are stored (see 2.4),
• how templates are named,
• how versions are controlled,
• how templates move from DEV to TEST/UAT to PROD,
• who maintains them: consultants, developers, or trained customer users.

2.4 Choose the template storage

Choose storage based on governance, ownership, deployment, security, and post-go-live maintenance:

• AOT resources: when templates should be source-controlled and deployed with code. Suits partner-owned baseline templates, regulated documents, or anything that should follow the code release process.
• Azure Blob storage: when templates should be stored centrally and maintained outside the deployable-package process. Suits project- and customer-owned templates that may change after go-live.
• SharePoint: when business or key users need easier access and the organization already uses SharePoint for document governance. Suits project- and customer-owned templates that may change after go-live.
• File system: available for on-premises environments only.

Stage 3: Build and prove the first report

Do not convert many reports in parallel. Start with one representative, not-too-complex Print management report (Purchase order is a good choice) and make it your reference implementation.

3.1 Implement the first end-to-end report

The first report should prove the complete pattern:

• Register the report in the Docentric report setup (if it is not already registered from the SSRS Replicas model).
• Generate the DDSP file.
• Create a template from scratch or modify the replica template in the Designer.
• Assign the template to the report and store it on the agreed storage type.
• Configure the print destination.
• Test preview, print, email, download, and archive.
• Test interactive and batch execution, with and without Print management destinations.
• Document the decisions made.

Reuse the same pattern for the next reports.

3.2 Design templates in the Docentric AX Designer

Recommended practices:

• Start from a replica when one is available.
• Keep the layout simple and readable, and use Word styles consistently.
• Use standard Word features and Word tables for clean layout.
• Separate header, body, totals, and footer areas clearly.
• Test with realistic data, and test edge cases: long addresses, high values, many lines, discounts, multiple tax rates, and multiple pages.
• Test language and legal entity variations.

The goal is not only correct output at go-live, but a template that is easy to maintain later.

3.3 Add data through a DSP class when needed

When the required data is not in the standard report data source, or additional document processing or distribution is required, use a Docentric DSP class. Typical cases: adding fields or records (delivery, payment, tax, bank, legal-entity-specific, or calculated data), custom placeholders, extra attachments not supported through the UI, or special delivery and integration requirements.

Recommended practice:

• Implement the logic to add the required data, placeholders, attachments, or integrations.
• Regenerate and reload the DDSP file after data source changes.
• Add the new fields to the templates.
• Retest all templates that depend on the changed data source, and the scenarios that required the new placeholders, attachments, or integrations.

This is a technical task with the Docentric Technical training as a precondition. Study the patterns in the existing replica DSP classes, and search the blog and forum for DSP method examples.

Stage 4: Print destinations and distribution

Defining how documents are distributed is a standard part of any D365FO project, but Docentric significantly extends what is possible, so it is worth matching requirements to Docentric capabilities early. Capture these requirements during Stage 2 and configure them here, alongside building each report.

4.1 Define print destination and distribution rules

For each document, clarify:

• Should it be printed, emailed, downloaded, archived, or saved to SharePoint, Azure Blob storage, or another destination?
• Should email parts (subject, body, output filename) be static or dynamic? If dynamic, which placeholders or business data should be available?
• Should files be attached? Should they be loaded from document attachments, or generated dynamically?
• Should the output be signed, encrypted, zipped, or PDF/A conformant? Saved with metadata?
• Are different settings needed for original, copy, internal, external, or batch scenarios?

When a document is emailed, also clarify: who receives it (Customer/Vendor contacts, purpose, custom logic, or manual selection); whether Cc/Bcc are needed; whether the sender is fixed, the current user, legal-entity-specific, or a system account; whether body and subject depend on language or legal entity; and how failures are logged, retried, or handled.

Map these to Docentric print destinations, Print management setup, email templates, placeholders, archive settings, and any custom data extensions. See the Print destinations how-to manuals and the Advanced functional training videos.

4.2 Manage Print management setup carefully

Print management can become complex; Docentric provides tools that simplify its review, maintenance, export, and migration.

Recommended practices:

• Keep settings as simple as possible and avoid unnecessary overrides.
• Prefer conditional Print management settings over multiple overrides where possible.
• Document why each override and each conditional setting exists, and use consistent naming.
• Test original and copy scenarios, all conditional settings, batch and non-batch execution, and all legal entities in scope.
• Use the Docentric Print Management Utilities form for tabular review and manipulation.
• Use the Docentric Print Management Settings Package data entity to move settings between environments and to export them for review.

Stage 5: Test, release, and hand over

5.1 Test business scenarios

For each implemented document, test:

• preview from the business process,
• print destination execution,
• email recipient resolution, subject, body, output filename, and attachments,
• archiving and file saving to required storage,
• PDF generation,
• batch execution,
• Print management original, copy, conditional, and override behavior,
• different legal entities, languages, customer/vendor groups, and currencies,
• long addresses and item descriptions,
• zero, negative, and large amounts,
• multi-page output,
• security and user access,
• migration from UAT to PROD.

5.2 Versioning, lifecycle, and moving between environments

Define how templates are versioned and promoted. A recommended lifecycle:

• Draft in DEV or sandbox.
• Review with the functional consultant.
• Test with realistic data.
• Review with the business owner.
• Promote to UAT.
• Freeze before go-live.
• Move to PROD through the agreed deployment process.
• Keep a backup of the approved go-live version.
• Apply later changes through change requests.

Avoid ad hoc changes directly in production unless the customer has explicitly accepted that governance model.

When moving Docentric setup between environments:

• Keep Docentric models aligned between source and target.
• Templates, report setup, Print management settings, and storage references may all need migration.
• AOT-stored templates follow the deployable-package/source-control process; Azure Blob storage and SharePoint templates require storage access and governance.
• Export/import Print management settings with the Docentric data entities, and always test imported settings in UAT before production.
• Keep a backup/export of approved production settings before major changes.

5.3 Hand over and train

Before go-live, prepare a short handover package:

• list of implemented reports,
• report setup overview,
• template storage locations and ownership,
• versioning rules,
• Print management notes,
• known limitations,
• troubleshooting steps,
• support contact points,
• instructions for changing a template safely.

For the customer to own the solution after go-live, train these customer groups:

• Functional consultants and key users.
• Optionally: technical consultants and developers.

The training tracks, what each group should be able to do, and the self-serve resources are detailed in Enablement, Demo Environment and Training. The same tracks apply to customer teams.

Summary

A successful Docentric AX implementation is more than designing templates. It needs a clear approach to report scope, data sources, template storage, Print management, distribution, environment migration, testing, and ownership after go-live.

The reliable way to start is to implement one representative report end to end, document the pattern, and then apply that pattern across the customer's document scope.

See also

Implementation Guide (main page) >>
Before You Start >>
Enablement, Demo Environment and Training >>