NexTool Solutions

Technical support with no signed proof is a verbal promise. The NexTool OrderService module generates a work order PDF directly inside the GLPI ticket, consolidating the ticket data into a document ready to print, sign and archive. When you sustain service desks that work in the field, that document is the difference between "the technician was there" and "the technician was there, and we have the client signature to prove it".

The problem

Many IT teams still issue work orders in a spreadsheet, a Word template or an external system. That creates rework, inconsistent data and a dangerous disconnect: what is recorded in GLPI and what was handed to the client on paper diverge. When an audit arrives, internal or from a corporate client, manually gathering the ticket data, the relevant followups and the approval flow into a single document costs hours that should not exist.

The native option of "printing" the ticket from GLPI produces raw HTML, with no print-ready formatting and no signature support. OrderService fills exactly that gap: one click, one structured PDF.

How OrderService works

After installing and enabling the module, a new Work Order tab appears on every ticket. There, the technician or administrator sees the work order on screen and uses the Print button, which opens the PDF in a new tab with the consolidated information:

• Ticket data - number, opening date, description, and start and completion dates.
• Requester and assigned technician - requester name, the requester's group (shown as department) and the assigned technician.
• Latest public followups - configurable count; the default includes 10 public followups.
• Related items - assets and equipment linked to the ticket.
• Last solution - the resolution description recorded in GLPI.
• Approval flow - when the ticket went through validation, the section is included automatically.

Sections with no data are omitted: no public followup means no followups section; a ticket with no validation drops the approval section. With signing enabled in the module's Features tab, the same ticket tab shows the requester and technician signature buttons (according to the fields chosen): each one signs on screen, with mouse or touch, whenever it suits them. When the last signature arrives, the signed work order is attached to the ticket with the file's SHA-256 hash and is listed under Management > Service Orders. If a signature never comes, the Generate signed Service Order anyway button issues the document with what has been collected.

OrderService vs GLPI native export

To make clear where the module adds value, it is worth comparing with what GLPI already does on its own:

How to enable

1. Install the NexTool plugin in GLPI.
2. Go to NexTool > Modules.
3. Find the OrderService card and click Install, then Enable.
4. In the module settings, set how many public followups go into the PDF (default: 10).
5. Open any ticket, go to the Work Order tab and generate the test PDF.

Audit hygiene: which tickets have no work order

A detail that only surfaces in operations: issuing the work order is easy; ensuring every ticket that needs proof actually has one attached is what passes the audit. When the client asks "prove there was a document for every ticket closed this month", this diagnostic query lists closed tickets with no linked document - adjust the names to your GLPI version:

-- Closed tickets with no attached document (audit hygiene)
SELECT t.id, t.name, t.date_creation
FROM glpi_tickets t
LEFT JOIN glpi_documents_items di
  ON di.items_id = t.id AND di.itemtype = 'Ticket'
WHERE t.status = 6          -- 6 = Closed
  AND t.is_deleted = 0
  AND di.id IS NULL
ORDER BY t.date_creation DESC;

Sustaining a client that works in the field, the technician had to leave a signed proof on site. Before OrderService they filled a parallel Word file and, over time, the paper data drifted from GLPI. The common mistake we warn about is treating the work order as the source of truth: it is a snapshot of the ticket at the moment it was generated. If you edit the ticket later, generate the PDF again - the document does not update itself.

Who it is for (and when not to use it)

The module is ideal for teams that deliver formal documentation at the end of each service, companies whose clients require proof of service, and service desks that work in the field where a paper signed by the client or technician is needed.

When not to use it: if support is fully remote with no formal proof requirement, the PDF becomes a dead artifact nobody opens. And if your process requires a digital signature with legal validity (a qualified certificate or a platform like a signature service), the manual signature field of the PDF does not replace that validity - in that case, combine OrderService with the digital signature module instead of relying on ink on paper.

Compatibility

• GLPI: 11.x
• Plan: Licensed
• Plugin: NexTool 6.15.0 or later

Next step

OrderService is part of NexTool, the modular plugin for GLPI. Requester and technician signatures are built into the module; for electronic signature through a provider, see the Digital Signature module. Explore all modules or talk to the team.

Reviewed by the NexTool Solutions team.