GLPI purchase order management setup

How GLPI purchase order management connects buying to the asset register

IT teams often buy hardware and licenses through one process and record the results in the asset register through another, so the register lags behind what was ordered and delivered. The GLPI Order management plugin is intended to keep purchase orders, deliveries and the resulting asset records in one tool, which lets the register reflect a purchase from the moment it is approved. Before you plan around this, confirm the exact feature set of the plugin version that matches your GLPI release, since GLPI 11 and 12 change how plugins are installed, reactivated and supported. Treat the plugin's documentation and its release notes as the authority for which steps are automated and which remain manual.

Teams usually take this on at a specific pressure point: before a large hardware refresh, when budgets are split across entities and each entity needs its own view of spend, or when an auditor asks where a given asset came from and the answer is spread across email, spreadsheets and invoices. Each trigger points to a different design question. A refresh needs product references and quantities that match how the catalog is structured. Split budgets need approval circuits and budget records aligned with your GLPI entity model. Audit questions need a clear chain from purchase order to delivery to the asset record, with the purchase order documents attached. Before the build starts, decide who owns each step: who raises the order, who approves it at each value threshold, who confirms receipt and who creates or updates the asset record. Ask the plugin's maintainers or your implementation partner to show how a delivery partially fulfils an order and how automatic asset creation handles serial numbers that arrive later. Those answers determine how much manual reconciliation your team keeps.

What the Order management plugin does in GLPI

The Order management plugin covers the purchasing cycle from request to asset record. Each capability below touches the same purchase order, so a gap in one (a missing product reference, an unassigned approver) shows up in budgets, receiving and the asset inventory. Verify each one against the plugin version you intend to install, because purchasing features change between releases and between GLPI core versions.

Product references

Product references link what you order to the catalog entries GLPI uses for hardware, software and consumables, including supplier part numbers and manufacturer codes. Clean references decide whether a received line can become a typed asset with the right model, category and warranty data. Check whether the plugin matches on your existing catalog, how it handles a product that has no reference yet, and whether you can merge duplicates after the fact.

Approval circuits

An approval circuit defines who must sign off a purchase order and in what order, often by amount, cost center or requester group. This is where spending controls live, so confirm the thresholds, the fallback approver when someone is absent, and whether an approver can edit lines after approving. Test a rejected order and a changed order to see how the circuit restarts.

Budgets

Budget tracking compares committed and received spend against the amounts assigned to an entity or cost center. Ask whether the plugin reserves budget when an order is approved or only when it is invoiced, and how it treats partial deliveries and cancelled lines. Your finance team needs to agree on that rule before go-live, because it changes what the budget report shows.

Purchase order documents

Purchase order documents are the generated or attached files that go to the supplier and sit on the record for audit. Confirm the template fields the plugin can fill, how numbering works across entities, and where the signed or supplier-returned copy is stored. Retention of these files should match your finance and records policy, not the plugin default.

Delivery tracking

Delivery tracking records what was shipped, what arrived and what is still open against each order line. Partial deliveries and split shipments are where most data quality problems start, so test them early. Check whether receiving can be done per line, whether you can record a delivery note number and whether a closed order can be reopened for a late item.

Automatic asset creation

On receipt, the plugin can create asset records from received lines so inventory starts when the goods arrive rather than weeks later. Confirm how many assets one line creates for a quantity of ten, which fields are copied from the order (serial numbers are usually entered at receipt), and how the record links back to the purchase order and supplier. Treat the first receipt in a test instance as a rehearsal for your asset data model.

Which purchasing decisions to make before configuration

This table compares the decisions a team must settle before building purchase workflows in GLPI Order management, with the options for each, when each fits and the risk of deciding late. Read it as a checklist: the rows that cost the most to change later are the ones tied to asset types, entities and document numbering.

Decision	Options	When each option fits	Risk of deciding late
Product reference mapping	Map each catalog reference to one GLPI asset type and model, or keep references as purchasing-only items	Map when the receiving team expects a ready asset record; keep purchasing-only when catalog items are mostly consumables or services	Duplicate models and inconsistent asset types appear in inventory, and reports then need manual cleanup
Approval circuit owners	Single approver per entity, tiered by amount, or tiered by spend category	Tiered by amount suits organizations with clear spending limits; category tiers suit mixed IT, licence and hardware buying	Approvers are assigned ad hoc, so orders stall or bypass the circuit during the first real purchase cycle
Approval thresholds	Fixed amount bands agreed by finance, or no threshold and approval for every order	Amount bands fit stable budgets; approval for every order fits small teams with low volume	Thresholds set after orders are in flight force retroactive reviews and weaken audit trails
Budget ownership	Budgets follow GLPI entities, or budgets follow cost centers held outside GLPI	Entities fit when each business unit already maps to an entity; cost centers fit when finance reports on a separate chart of accounts	Budget totals diverge from the finance ledger, and reconciling them later is a manual exercise
Purchase order numbering	Sequential numbers per entity, or a numbering scheme tied to fiscal year and entity	Per-entity sequences fit decentralized buying; fiscal-year schemes fit finance reporting by period	Numbers are reused or reset after a migration, which breaks references in invoices and supplier records
Purchase order document storage	Attach documents to each order in GLPI, or link to a document repository	Attachments in GLPI keep the record self-contained; links fit organizations with an existing document management system	Signed quotes and invoices end up in personal mailboxes, and assessors cannot trace the approval
Receipt creates asset or pending record	Create the asset on delivery, or create a pending record until a technician confirms serial and location	Immediate creation fits standard hardware with serial numbers on the delivery note; pending records fit partial deliveries and staged installs	Assets appear in inventory before they are physically verified, or receipts pile up unprocessed
Delivery tracking granularity	Track at order level, or track each line item and partial delivery	Order level fits small, single-shipment orders; line-level tracking fits multi-shipment or backordered purchases	Partial deliveries are recorded as complete, and the remaining quantity disappears from open orders

Loading suppliers, products and open orders by starting point

A new GLPI instance with no purchasing history has the simplest load but still needs deliberate setup. Nothing has to be converted, so the work is designing the reference data first: which suppliers you buy from, how products are identified, which budgets exist and who approves what. Loading an empty instance with incomplete reference data is the most common reason teams rebuild their setup a few months later.

Suppliers: Agree on one naming rule and one record per legal entity before the first order is created. Decide who owns supplier creation so duplicates do not appear from different requesters.
Product references: Define the catalog structure and reference format, including how manufacturer part numbers map to your internal codes.
Budgets and approvers: Write down the budget owners, approval thresholds and the approval circuit for each entity, then load them as configuration rather than as free text.
Test load: Enter a small set of real orders through the full cycle, from request to receipt to asset creation, before loading the rest.

Before go-live, confirm that the approval circuit, budget reporting and asset creation behave as your finance and asset teams expect, using the plugin documentation for your GLPI version.

How the implementation sequence runs from design to go-live

The sequence moves from confirming the plugin and GLPI versions to a rehearsed, end-to-end purchase cycle, so that the first live order behaves the way purchasing, finance and receiving expect. Each step closes with a named output that the team checks before starting the next one.

Confirm plugin and GLPI version compatibility
Before any configuration, confirm which GLPI release is running in production and which version of the purchasing plugin matches it. Check the plugin's documentation or its release notes against the GLPI version, and confirm the PHP and database versions the GLPI release requires. Compare the target version with the GLPI update procedure, which requires a full backup and plugin reactivation after major updates. Output: a written compatibility record naming the GLPI version, the plugin version, the PHP and database versions, and the agreed upgrade path if the versions differ.
Design the approval and budget model
Hold working sessions with purchasing, finance and the business owners who request equipment. Define who can create an order, who approves at each value or category threshold, which budgets or cost centers each order draws on, and what happens when a request exceeds the budget. Map each rule to the GLPI entities and profiles that will enforce it, and record who signs off on the model. Output: an approval and budget matrix signed by purchasing and finance, with each rule traced to a GLPI setting or an explicit manual step.
Configure product references and suppliers
Build the catalog of products and suppliers that purchasing actually buys. Create product references with the manufacturer, model, and the asset type each reference should produce when goods are received. Load supplier records with the contact and account details finance needs for purchase order documents. Agree a naming and reference convention with the team that will maintain the catalog after go-live. Output: a reviewed catalog export that purchasing confirms matches its current price lists and product lines, with an owner named for future changes.
Load and test sample orders
Create a set of test orders that cover the common cases: a single item, a multi-line order from one supplier, an order that needs escalation, and an order that exceeds its budget. Run each through creation, approval and status changes to confirm that the approval circuit and budget checks behave as designed. Record the results against the approval matrix, and fix any gaps in configuration before the end-to-end test. Output: a test log where every case has an expected result and an observed result, with no unexplained differences.
Run one full cycle in a non-production copy
Restore a recent copy of the production database and files into a separate, non-production GLPI environment that uses the same plugin version. Run one complete cycle: request, approval, purchase order document, partial and full delivery, receipt, and automatic asset creation. Check that the asset records carry the right references, locations, entities and owners, and that the delivery state matches what receiving reports. Output: a signed walkthrough record with screenshots or exports from each stage, and a list of defects that have been fixed or accepted.
Train approvers and receivers
Run separate sessions for requesters, approvers, finance users and the people who receive deliveries, because each group uses a different part of the workflow. Give each group a short procedure that covers the screens and actions they perform and the cases they must escalate. Confirm that users can sign in with the accounts and profiles they will use in production. Output: a list of trained users per role, each with a completed exercise performed on the non-production copy, and a named contact for questions after go-live.
Go live with an agreed cutover for open orders
Agree in writing a cutover date and the handling of orders that are already open. Decide whether open orders are completed in the old process, re-entered in GLPI, or migrated, and record the decision for each category of order. On the cutover date, freeze new work in the old process, run the final data checks, and enable the production workflow. Output: a cutover record that lists the open orders and their handling, the post-cutover checks that passed, and a review date to examine the first live month of orders.

What drives the effort of a purchasing setup

This table lists the main drivers of effort in a GLPI purchasing setup, how each one changes the work, and what a team can do to keep it down. Read the last column first to see which choices are cheap to make early and which become recurring work as the catalog changes.

Driver	Why it changes the work	How to keep it down	One-time or recurring
Approval levels and exceptions	Each approval circuit needs rules for who approves, at what amount and in what order, and every exception path must be tested before go-live.	Start with the fewest levels the policy allows and document exceptions as a short, named list.	Mostly one-time, with changes when policy changes
Entities and budget owners	Each entity can need its own budgets, approvers and visibility rules, which multiplies configuration and test cases.	Map entities and budget owners in a single agreed table before configuring anything.	One-time setup, recurring when owners change
Product catalog quality	Duplicate, unnamed or inconsistent product references make ordering slow and break matching at receipt.	Clean and de-duplicate references, agree naming rules and assign an owner before import.	One-time cleanup, recurring as new products enter the catalog
Open orders to migrate	Open purchase orders carry line items, partial deliveries and supplier links that must be mapped and checked against receipts.	Migrate only orders still open at cutover, and reconcile totals with finance before loading.	One-time, unless migration is repeated in waves
Finance or ERP exports	Exports of orders, invoices or cost centers need field mapping, agreed formats and reconciliation rules with the finance system.	Agree the export format and the system of record for each figure early, and limit the first release to what finance needs.	Build is one-time, and each format change recurs
Asset types created on receipt	Each asset type that GLPI creates automatically needs mapping from the product reference, required fields and inventory linkage.	Start with the asset types that carry the most volume and add others in later releases.	One-time per asset type, plus upkeep when fields change
Delivery and receiving process	Partial deliveries, substitutes and returns add branches to the receiving workflow and to asset creation rules.	Define the handling of partial and substituted deliveries as a written rule set before testing.	One-time design, with recurring review of exceptions
Document and evidence requirements	Purchase order documents and approvals must be retained in a form auditors or finance can trace, which adds storage and access rules.	Confirm the retention and access requirements with finance and compliance before designing document flows.	One-time design, with recurring storage and access checks

Where approval and budget setups go wrong

The most expensive mistake in a purchasing setup is copying the paper process into GLPI without checking who actually holds signing authority. Approval circuits drawn from an old procedure manual often route a request to a manager who left, or to a level that cannot legally commit the budget. Before go-live, export the current delegation of authority from finance and compare it line by line with the approval steps configured in the Order management plugin. Test with one request per threshold band and per entity, and confirm that each step lands with a person who can approve that amount. Finance and the budget owners should sign off on this matrix, not the IT team alone.

Budgets fail for a different reason: they are defined at a level that does not match the entity tree. If a budget is attached to a parent entity but purchases are raised in child entities, spending may not reconcile with the cost centers finance reports on, and month-end totals will disagree with the ledger. Run a reconciliation test by raising a small set of orders in each entity, closing them, and comparing the GLPI totals with what finance expects for the same period. Confirm with the finance lead how budget periods, currency and tax are reported, because those rules are rarely the same as the ones in the plugin defaults.

Duplicate product references split stock and cost across several records, so the same laptop model appears as three items with three prices and three stock counts. Receiving then creates assets against whichever reference the person picked, and reporting on unit cost becomes unreliable. Ask the procurement and asset teams to agree one naming and reference rule before the catalog is loaded, and run a duplicate check on the product list as a pre-go-live gate. Receiving is the last failure point: if goods are received without serial numbers, or without an owner or location, automatic asset creation produces records that cannot be traced or audited. Test a receipt that is missing a serial, confirm the blocking or follow-up behavior, and agree with the asset owner who signs off the receiving checklist.

How purchasing connects to the rest of GLPI and other systems

A purchase order in GLPI is only as useful as the records around it. The cards below cover the systems and GLPI modules that feed orders, receive their outcomes, or depend on them, and what to confirm in your environment before you rely on each link.

Confirming receipts with GLPI Agent

Once hardware arrives, the question is whether the device on the shelf matches the delivery line. GLPI Agent collects hardware and software inventory and sends it to GLPI, so received equipment can be compared with the order and the asset record it created. Confirm which devices the agent can reach at delivery time, whether serial numbers are captured the same way on the purchased model, and who signs off when a discovered device does not match a line on the order.

Approver identity from LDAP or SSO

Approval circuits only work if the people in them resolve to the right accounts and groups. Approvers and budget holders are usually identified through LDAP, Active Directory, or a web server SSO layer, and group membership decides who can approve. Confirm that approver groups sync reliably, that departed staff are removed from approval paths, and that the authentication method your approvers use is the one configured in GLPI.

Linking orders to contracts and cost

Orders carry cost, and cost usually belongs to a contract, a supplier, or a financial record. The contracts and financial management modules let you attach an order to the agreement it falls under and to the cost data that finance reports on. Confirm which contract types your suppliers use, whether one order can span several contracts, and whether amounts entered on the order must match invoice figures before the record is closed.

Helpdesk requests that start a purchase

Many purchases begin as a ticket, such as a laptop replacement or a licence renewal. Decide whether a ticket can create an order, whether the requester sees the purchase status, and which fields carry over from the ticket to the order. Confirm that approval steps for tickets and orders do not conflict, and that a rejected request closes both records cleanly.

Finance exports and the OAuth2 API

Finance teams often run their own ledger, accounts payable, or procurement system, and GLPI has to hand data across. The OAuth2 API and scheduled exports are the two typical routes. Confirm which order fields the finance system needs, the format and frequency of exports, how supplier and product codes are matched, and who owns the API client credentials and their rotation.

Entity structure for budget ownership

GLPI entities separate data by organizational unit, and that structure decides which budget an order draws on and who can see it. Map each budget holder to an entity before the first order is created, and confirm whether purchasing rights should be restricted by entity, whether child entities inherit approvals, and how shared suppliers are handled across units. Changing entity structure after orders exist is costly, so settle it early.

Questions buyers ask before setting up GLPI purchasing

What does it cost to set up GLPI purchasing?

The cost depends on the purchasing workflow you need, how many approval levels and budget owners exist, how many product references and suppliers you load, and how many existing records must be cleaned up before they can be used. Costs fall into two groups: one-time work (requirements, configuration, data preparation, testing, training and cutover) and recurring work (maintenance, plugin updates and support after each GLPI release). Ask any provider for a fixed-scope quote that lists each deliverable separately, so you can see what is included and what would be a change request. Also confirm whether the quote covers a test environment and whether plugin licensing or subscriptions are billed separately.

How long does a GLPI purchasing setup take?

Timeline is driven by the number of approval circuits, the state of your product catalog and supplier data, the number of integrations with finance or ERP systems, and how many people must review and sign off each stage. A simple single-approver workflow with a clean catalog moves much faster than a multi-level circuit tied to budgets by entity. Your own change windows and the availability of purchasing and finance reviewers often set the pace more than technical work. Ask for a written schedule with dependencies, and confirm which milestones depend on your decisions rather than on the implementer.

What does purchasing and finance need to provide?

Purchasing and finance own the business rules, so they must decide them before configuration starts. That includes who may create and approve orders, the approval thresholds per entity, budget structures and how they are tracked, supplier and product reference standards, tax and currency handling, and how receipts are matched to invoices. They also need to supply sample purchase orders and existing supplier lists for data preparation. Without signed-off rules, the implementation team has to guess, and the approval design will need rework. Name one accountable owner on each side before the project begins.

Can an internal IT team set up GLPI purchasing alone?

A capable internal team can do it if it has someone who knows GLPI administration, has time for the configuration and testing work, and can get purchasing and finance decisions in writing. The risks are usually not technical: they include unclear approval rules, incomplete test cases, unplanned data cleanup and no plan for how the workflow changes after go-live. An external partner is most useful when the scope is fixed, the timeline is tight or the team has no time to run parallel testing. Whichever route you choose, write the acceptance tests before building. Check the plugin's current documentation first, since you need to confirm which features apply to your GLPI version.

How does GLPI purchasing fit alongside an existing ERP?

GLPI can record purchase orders, approvals, deliveries and the asset records created from them, but it does not replace a general ledger or an ERP's accounting, stock and payables functions. Decide early which system is the source of truth for supplier master data, invoices, payments and cost centers. If data must move between them, define the fields, the direction of each sync, the frequency and the handling of rejected records. Confirm whether your ERP offers a supported interface or whether an export and import process is more appropriate. Test invoice matching and cost allocation with real month-end data before you rely on either system for reporting.

Does the Order management plugin support the GLPI version we run?

Plugin compatibility is tied to specific GLPI releases, so check the plugin's published compatibility notes against the exact GLPI version you run or plan to move to. GLPI 11 changed how plugins behave during updates: plugins are suspended after a new version is detected and must be reactivated after major updates. That means a version upgrade can stop purchasing workflows until a compatible plugin release is installed and tested. Plan the GLPI upgrade and the plugin version together, and keep a staging copy of the database and files to test both. Do not assume a plugin version works on a newer GLPI release until you have confirmed it in your own test environment.

What happens to open purchase orders at cutover?

Open orders need an explicit decision before cutover. Typical options are completing them in the old process, re-entering them in GLPI with their original references, or closing them and recreating only the lines still awaiting delivery. Each option affects approvals, budget commitments and the asset records created on receipt, so finance should confirm which budgets carry over. Plan a freeze period for new orders, reconcile counts and values between the old and new records, and confirm that no delivery is received twice and no asset is created twice. Keep the old records readable for audit purposes and confirm your retention requirements with your own compliance owner.

How DeployOpen scopes and delivers a GLPI purchasing implementation

DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and purchasing with GLPI Order management follows the same method. The work starts with a written scope that names the approval paths, budget rules, receiving steps and asset mappings to be built, then moves through build, test and handover in your environment.

How we scope

Map your current purchase request, approval, receiving and invoicing steps before choosing plugin configuration.
Agree in writing which product references, approval circuits, budgets and document templates are in scope.
Confirm the GLPI version, plugin version and database platform the purchasing setup must run on.

How we build

Configure product references and supplier data in a non-production GLPI copy first, then review them with your purchasing team.
Build approval circuits and budget checks from the rules you approved, and test each rejection and escalation path.
Test automatic asset creation from delivery records against sample receipts, including serial numbers and entity assignment.

How we hand over

Document configuration decisions, approval rules, budget ownership and the receiving procedure for your staff.
Run a supervised walkthrough of a full order, from request to delivery tracking to created assets, with your team present.
Deliver the configuration record and the test results so your team can repeat the checks after changes.

How we support

Engagements are fixed-scope, so changes to approval rules or plugin versions are agreed as written scope changes.
Ongoing support, upgrades and continuous testing are available as a retainer, including checks after GLPI and plugin updates.
Ask any partner to confirm how plugin version compatibility with your GLPI release will be verified before each upgrade.

Purchasing and receiving assets with GLPI Order management