CONTENTS
X

Implementation Guide

IN THIS ARTICLE

What this guide is

This guide explains how to implement Docentric AX in a Dynamics 365 Finance & Operations (D365FO) project in a structured, repeatable way, from the first install through to go-live and hand-over.

It is written primarily for implementation partners who are adding Docentric AX to their standard D365FO delivery and want a consistent, best-practice approach they can reuse on every project. It is equally useful to customers implementing Docentric AX directly, and to any D365FO professional evaluating how Docentric fits their reporting and document output.

You do not need prior hands-on Docentric experience to follow it. Wherever a step benefits from deeper material, we link to the relevant how-to manual, video tutorial, or training.

This guide is organized into three parts, described at the end of this page: Foundations, Learn Docentric first, and Implementation methodology.

A note for partners: commercial details, like licensing specifics, your contact person at Docentric, the support channel, and access to the partner resource center, are arranged separately as part of your partnership onboarding, not on this page. This guide focuses purely on the how.

How Docentric AX fits the D365FO reporting pipeline

Standard D365FO produces business documents, such as invoices, order confirmations, packing slips, statements, and so on, in two main ways:

  • Classic SSRS reports: Report Data Provider (RDP) prepares the report data source, which is combined with an SSRS layout to generate the output document.
  • ER-based business documents: Electronic Reporting (ER)-based framework starts from the same SSRS/RDP data source, enriches it through an ER model- and model mapping configuration, and combines it with an ER format. The solution was originally branded Configurable Business Documents (CBD) and later renamed to ER-based business documents. In our documentation we still refer to them as CBD, for legacy reasons.

Docentric AX does not replace these pipelines. It layers on top of them, taking over the prepared data source and adding elements that standard D365FO does not provide:

  • A Microsoft Word–based template for the layout, designed and maintained in the Docentric AX Designer instead of in SSRS or ER – see Docentric TEMPLATE element in the image below.
  • A Data Source Provider (DSP) class, where developers can shape the data in X++, add custom placeholders, and override how the document is generated and distributed. It produces the final data source – see DDSP (Docentric Data Source Package) element in the image below.
  • Additional document processing options, such as encryption, electronic signing, PDF/A support, etc. – see Docentric POST-PROCESSING below.
  • Rich document distribution options, available through Docentric improved print destinations – see Docentric Document DISTRIBUTOR and Docentric PD (Print Destination) below.

For most frequently used reports, Docentric ships a ready-made replica as a starting point:

  • A Docentric SSRS replica for SSRS-based reports: a replica Word template, producing the same printout as the related SSRS format, together with its DSP class.
  • A Docentric CBD replica for ER-CBD-based reports: a replica Word template, producing the same printout as the related ER format, together with extension of the related SSRS replica’s DSP class.

The takeaway for a newcomer: you keep the standard D365FO data foundation, Docentric replaces the layout step with a Word template, and you gain a far richer data-shaping, document post-processing and distribution layer on top.

We recommend introducing Docentric early in the implementation, ideally during the solution design phase for business documents and reporting, alongside the related business processes.

Do not wait until UAT to start with public-facing documents. Invoices, purchase orders, confirmations, statements, labels, payment advice, and similar documents often carry legal, branding, localization, distribution, and archiving requirements. These are best collected and designed together with the related business process, not retrofitted at the end. This is consistent with Microsoft's own implementation guidance, which brings ISV solutions into the early design phase rather than treating them as a late add-on.

Start here: your first hour

If you have never touched Docentric, the fastest way to build confidence is to prove the full loop once in your own development or sandbox environment. You can do this before reading any further:

  1. Install the core models: Docentric AX, Docentric AX Extension, Docentric AX Emails, and the Docentric AX SSRS Replicas model.
  2. Apply your license.
  3. Load the system templates: open the Docentric AX Workspace and click the Reports tile, then confirm the prompt to load them. This registers a large set of standard report/format combinations (around 80 at the time of writing), each with its matching Docentric replica template.
  4. Preview a Purchase order confirmation using Preview/Print > Original preview. It automatically uses the Docentric replica template.
  5. Install the Docentric AX Designer (a Microsoft Word add-in), download that PO confirmation template, change something small using standard Word features (for example, a title color), re-apply it, and preview again.

That is the entire template loop: install, register, preview, modify, re-preview – proven on a single report. Full step-by-step detail is in the Implementation methodology.

Why Purchase order confirmation? It is representative but not overly complex. Sales invoice is usually the most complicated document, so don't start there. We use Purchase order confirmation as the running example throughout this guide.

Common pitfalls to avoid

The mistakes we most often see from teams new to Docentric:

  • Waiting until UAT to start on public-facing documents. Start during solution design.
  • Starting with the hardest report. Prove the pattern on Purchase order confirmation first, not Sales invoice.
  • Converting many reports in parallel. Implement one report end-to-end, document the pattern, then repeat it.
  • Editing a template without the Docentric AX Designer installed. The data bindings are lost. Always design templates with the Designer.
  • Over-engineering templates. Start from a replica and keep the layout simple and maintainable.
  • Leaving Print management and distribution to the end. Capture output and distribution requirements early, keep Print management settings simple, and avoid unnecessary overrides.
  • (Partners) Using your partner license in a client environment. Client environments must use the customer license.

How this guide is organized

Most teams arrive with some version of three questions. The guide is built around them:

1. Before you start: Prerequisites and environment/version compatibility, the roles involved in a Docentric implementation, and the key terms glossary.
Start here if you want the groundwork and vocabulary first >>

2. Learn Docentric first – enablement, demo environment & training: A recommended learning order for teams new to Docentric, how to build an internal demo and training environment, and the recommended materials and training for both functional and technical consultants.
Start here if your first goal is getting your own team ready >>

3. Implementation methodology: The end-to-end delivery approach in five stages: Set up, Analyze & decide, Build & prove, Distribution, and Test / release / hand-over.
Start here when you are implementing on a real project >>

See also

Implementation Guide: Before You Start >>
Implementation Guide: Enablement, Demo Environment and Training >>
Implementation Guide: Implementation Methodology >>

IN THIS ARTICLE