365 business PDF

365 business PDF post-processes the PDF documents Microsoft Dynamics 365 Business Central produces: it applies stationery, concatenates documents, attaches further documents, signs and protects them, and turns sales invoices into ZUGFeRD / Factur-X documents. The processing itself runs in the 365 business API PDF service; the app is the Business Central side of it.

This page is the entry point for using the app from your own extension. There are three ways to do that, and they solve different problems:

You want to	Start here
Apply stationery, merge documents or read a stored PDF file from your own code	The codeunit chapters below
Change or skip what the app does to a printed report	Extensibility Events
Add a document to a sales or purchase document from outside Business Central	Document Attachment API

Dependency

Add a dependency to the 365 business PDF app in the dependencies node of your app.json:

Code
    {
      "id": "66745141-90b6-4fb0-906a-94400600f856",
      "name": "365 business PDF",
      "publisher": "365 business development",
      "version": "20.5.0.0"
    }

Which version you need

The codeunits described here have been introduced with 20.5, which split the former bdev.Pdf API codeunit into one codeunit per capability. On an older version only bdev.Pdf API is available.

The public objects

The objects below are the supported surface of the app. The three capability codeunits, the event publisher and the reference table declare Access = Public; the enums and the obsolete bdev.Pdf API are public by the AL default. Everything else in the app is either Access = Internal or an implementation detail that may change without notice, even where AL leaves it public.

Object	Type	What it is for
`bdev.Pdf - Stationery`	Codeunit (`5523673`)	Apply stationery to a PDF document.
`bdev.Pdf - Concatenate`	Codeunit (`5523674`)	Merge PDF documents into one, optionally in several copies.
`bdev.Pdf - File`	Codeunit (`5523672`)	Read a PDF file stored in `PDF Files`, in the language you need.
`bdev.PDF`	Codeunit (`5523675`)	The integration point of the report processing. It only publishes an event.
`bdev.Pdf ZUGFeRD TaxCat.Reason`	Table (`5523599`)	The tax category exemption reasons a ZUGFeRD document can state. Reference data, pointed at by the `Tax Category Reason Code` field the app adds to `VAT Posting Setup`.
`bdev.Pdf API`	Codeunit (`5523590`)	The predecessor of the three codeunits above. Obsolete since 20.5, but still the only way to sign a document from AL.

Two enums are part of that surface:

Enum	Values	Meaning
`bdev.Pdf Document Print Intent` (`5523591`)	`Print`, `Preview`, `Download`, `Save`	What the user asked for. A configuration states per intent whether it applies, which is why the intent is a parameter of the stationery methods and of the event. Extensible.
`bdev.Pdf Rotation` (`5523594`)	`None`, `RotateAngle90`, `RotateAngle180`, `RotateAngle270`	How a document is rotated when it is merged into another one. Set per document attachment; not extensible.

How a printed report is processed

Knowing the order the app works in makes both the events and the codeunits easier to place. Whenever Business Central has rendered a report to PDF and the report selection carries a 365 business PDF configuration, the app runs the following:

The base record of the report is resolved. A report printed for exactly one record is a single print, anything else is a bulk print.
The print intent is read from the object payload; on a single print the language code is taken from the document.
OnBeforePerformAdditionalActionsOnPdf is raised. A subscriber can replace the document, change the report selection, or stop the processing here.
A security configuration on the report selection is remembered and applied to the service calls that follow.
The stationery configuration is applied.
The concatenate configuration is applied.
On a single print, the document attachments of the record are added.
The signing configuration is applied - unless the intent is Print, as a signature on a document that goes to a printer serves no purpose.
On a single print, the document is converted to ZUGFeRD / Factur-X.

Bulk print is not the same as single print

Steps 7 and 9 are skipped on a bulk print, and stationery that is configured per page position is skipped as well - the app cannot tell where one document ends and the next begins in a merged bulk print, and sends a notification instead. Extensions that rely on document attachments or on ZUGFeRD must expect them to be absent when a user prints a batch.

Everything goes through the PDF service

Every method of the codeunits described here ends in an HTTP call to the 365 business API PDF service. Two things must be in place for such a call to succeed:

the 365 business PDF feature must be licensed for the tenant;
outgoing HTTP calls must be allowed for the 365 business PDF extension. In a sandbox this is off by default and the call fails.

Both are properties of the environment, not of your extension - but your error handling has to cope with them.

365 business PDF

Dependency

The public objects

How a printed report is processed

Everything goes through the PDF service

See also