How to integrate NAXT and Lasernet ERP printing with Print Director

NAXT is the Microsoft Dynamics 365-based ERP used by Caterpillar dealers. Like most Dynamics 365 deployments with heavy document output, it does not print business documents itself: it hands them to Lasernet (by Formpipe), an output-management server that formats and prints ERP documents such as invoices, delivery notes, work orders and picking lists.

Print Director adds what this pipeline does not do on its own: capture, tracking, cost allocation and central control of every document the ERP prints, alongside the secure-release printing your users already have. ERP system documents must print immediately (a picking list has to be on the warehouse printer when the picker walks over), so Print Director is configured to release these jobs instantly, adding tracking and control without delaying anything.

How the NAXT to Lasernet to printer pipeline works

1. A user or batch process in NAXT (Dynamics 365) triggers a document. The Lasernet FO Connector inside Dynamics sends the report data as XML, together with the target printer name, to the Lasernet server (via Azure Service Bus or HTTP).
2. The Lasernet server’s form engine merges the XML with the designed document template and renders the finished document. (Lasernet replaces SSRS report layouts; the rendering happens on the Lasernet server, not in Dynamics.)
3. Lasernet’s printer output module prints the rendered document through the Windows print spooler on the Lasernet server, using the printer driver installed on that queue. This is a normal Windows print path, which is why Lasernet deployments prescribe which drivers to install.
4. The job lands in the Windows print queue under the Lasernet service account: every ERP document prints as the same Windows user, regardless of which ERP user or process triggered it.

Print Director inserts itself at step 4: it takes control of those Windows queues, captures each job, records it (pages, colour, document name, target printer), allocates the cost, and passes it straight through to the physical printer. When it sends the job, Print Director injects authentication credentials into the spool data, so the job is accepted by printers that have Print Director embedded and authentication enforced. The job arrives as an authenticated Print Director job, not as anonymous raw data.

Secure release is not possible for these jobs, by design. Because Lasernet submits every job as the same Windows user, Print Director cannot tell which person a document belongs to, so there is no meaningful user to hold it for. This has two configuration consequences:

• One Windows queue per physical printer. The queue is what tells Print Director which device the job must go to, so the Lasernet server needs a dedicated queue for each target printer. This matches how Lasernet is configured anyway: Dynamics selects a named printer per document.
• Override secure release on those queues. In Resource Manager, set each Lasernet queue’s Secure release setting to “Release jobs immediately (override device settings)”: capture, record, allocate, print, with no hold.

Where this fits. This guide covers system/batch ERP output: documents that must print immediately at a designated printer. Interactive documents a user previews in the Dynamics web UI and prints locally follow the normal workstation print path and need no special setup: they are captured by the user’s own Print Director queue with full secure release.

Prerequisites

You will need all of the following:

• Print Director: any recent version; no specific minimum release is required for this integration.
• Access to the Lasernet server (test and/or production) with local administrator rights. Print Director (PDServer + PDAgent, or PDAgent joined to an existing PDServer) is installed on the Lasernet server itself, because that is where the Windows queues live.
• A database for Print Director: an existing central PD database, or SQL Server Express on the Lasernet server for a standalone install.
• The list of Windows print queues Lasernet prints to, and the drivers Lasernet prescribes for them. Use drivers suitable for Lasernet and the target printers; this integration does not prescribe a particular driver model.
• The Lasernet service account name: all captured ERP jobs arrive under this Windows account, and it is the user account they will be recorded and costed against in Print Director (auto-created on first capture unless user auto-creation is disabled; see step 5).
• A decision on cost allocation for system prints: typically a dedicated system or department account (e.g. “NAXT System Prints”), or per-branch accounts if branch printers are distinguishable by queue.
• Print Director embedded on the target printers (optional but recommended) so the same devices also serve secure-release users; system prints bypass the hold and print immediately.

Setup overview

1. Install Print Director on the Lasernet server. Standalone (PDServer + PDAgent + SQL Express) or PDAgent-only joined to your existing PD server.
2. Take over the Lasernet queues. If a Windows queue’s port already points at the IP address of a printer registered in Print Director, the queue is taken over automatically when Print Director is installed. Bring any remaining queues under PD control manually. Ensure there is one queue per physical printer (see above), and do not rename queues; Lasernet targets them by name from the Dynamics printer selection.
3. Convert the queues to Print Director local LPR ports. In Resource Manager, on each Lasernet queue set Alter Port to “Change to local LPR” and select “create a pool of 3 ports” (at least 3), so concurrent ERP output doesn’t queue behind a single port.
4. Verify the drivers on those queues are suitable for Lasernet and the target printers. There is no need to change a working driver solely for this integration.
5. Know the user account the ERP jobs will be recorded against. By default, when Print Director captures a job whose owner doesn’t match an existing user record, it auto-creates the user, so the Lasernet service account appears in Print Director automatically after the first job; you only need to create it manually if user auto-creation has been disabled on the device record. Either way, be aware of this account: if you have Rules in place (quotas, colour restrictions, denials), make sure this account is excluded from any rule that could block or alter ERP output.
6. Override secure release on the Lasernet queues. In Resource Manager, set each queue’s Secure release setting to “Release jobs immediately (override device settings)”: no hold, no user interaction; capture, record, allocate, print.
7. Test end-to-end: trigger representative documents from NAXT (invoice, delivery note, label if applicable) and confirm each prints without added delay, appears in Print Director reporting with correct page/colour counts, and is recorded against the Lasernet service account as expected.

Can ERP jobs print to authentication-enforced printers? Yes.

A common worry from SAP-era deployments: the old ERP print path pushed data directly to the printer’s raw 9100 port, and on printers with authentication enforced (for example a Konica Minolta with Print without Authentication set to Restrict), the device deleted those anonymous jobs. The workaround was to leave ERP printers un-embedded and unauthenticated, losing control of those devices.

That problem does not exist on this integration. ERP jobs now flow through Print Director, and Print Director authenticates each job to the device: it injects the credentials into the spool data it sends, so an embedded, authentication-enforced printer accepts the job like any other authenticated Print Director job. The NAXT/Lasernet printers can therefore be fully embedded with Print Director, with authentication enforced, and still print ERP system documents immediately.

Things to check on your Lasernet server

• Direct/raw output paths. Lasernet can also generate printer language (PCL, PostScript, ZPL) directly and send it raw to the printer on port 9100, bypassing the Windows spooler entirely; this is commonly used for label printers. Documents on this path never enter the Windows queues Print Director controls. If you need them captured, route them into Print Director via an LPR/RAW listener queue instead; otherwise document them as out of scope. Ask your Lasernet consultant which output modules each document type uses.
• No formatting risk. Lasernet renders the document before it reaches the queue, so Print Director’s queue takeover cannot affect document formatting. The only shared surface is the queue and driver configuration.
• Queue availability. Lasernet expects its queues to accept jobs at all times. Print Director’s capture keeps the queue available and passes jobs straight through; do not leave queues paused after maintenance.
• Prod vs. test. Lasernet deployments typically run separate production and test servers. Prove the integration on the test server first; the setup is identical.

What you get

• Every ERP document tracked: printer, queue, document name, pages, colour, time.
• Cost allocation of ERP output to a system, department or branch account, visible in the same Print Director reports as user printing.
• Central control of the ERP print fleet: redirect a failed printer’s queue, apply rules (e.g. force mono on internal documents), and monitor volumes.
• Zero delay on system documents, and unchanged Lasernet/NAXT configuration beyond queue and driver settings.