GLPI contract and supplier management

Match each contract to assets using a stable identifier that exists in both the source system and GLPI, such as serial number, asset tag or hostname, and record the match in a mapping sheet before any import. Export the asset list from GLPI first, then check each contract line against it. Where the old tool used internal names that never existed in GLPI, build a crosswalk table and review every unmatched row by hand. Duplicate hostnames and reused asset tags are the most common cause of wrong links, so resolve those cases before loading. Keep the mapping file as an audit record of how each link was decided.

Load them as contracts without asset links, but record the reason in a field or comment so the gap is visible and not mistaken for an error. Typical cases are software subscriptions, support agreements that cover a service rather than a device, and loan contracts for equipment that has since been retired. Assign an owner to each unlinked contract so someone decides whether it should be attached to an asset, linked to a supplier only, or closed. Review the unlinked list with the business owners before cutover, because contracts with no asset are the ones most likely to be forgotten during renewal.

Check every start date, end date, notice period and value against the signed source document, not only against the spreadsheet or old tool. Look for common errors such as day and month swapped in European or US date formats, end dates earlier than start dates, currency columns without codes, and values entered as text. Standardize the format in the staging file, then run row-level checks that flag blanks and impossible ranges. Sample a set of contracts from each supplier and compare them with the originals. Record who approved the validated dataset, since that record is what your auditors will ask for later.

Yes, and you should. Install a separate GLPI instance that matches the production version and plugin set, then import the staged data there before any production load. Test the whole chain: supplier records, contract types, asset links, financial fields and the notification behavior. Check that imported contracts show the correct end dates and that the renewal alerts fire for a known test date. Use the test run to measure how long the import and checks take, and to confirm which data needs cleanup. Keep the test database after each run so you can compare results when you repeat the load.

Freeze the source data at a fixed cutover date, then reconcile active and expiring contracts between the old system and GLPI. Produce a list of every contract whose end date falls within the notice window around cutover and confirm each one exists in GLPI with an alert and an owner. Compare counts by supplier and by contract type, and sample contracts that ended recently to check they are marked as expired rather than active. Run the expiry notifications in the test instance first, and confirm that notification recipients are valid users in production. Keep the old system read-only for a defined period so you can check disputed records.

Map the fields that drive renewal, cost and evidence, and treat the rest as optional. The essential set usually includes the contract name and number, supplier, contract type, start and end dates, notice period, renewal behavior, value and currency, and the owner or contact. Map supplier identifiers to a single supplier record so one company does not appear under several spellings. Decide early how attachments such as signed PDFs will be handled, because storing them separately from the contract record can break the audit trail. Confirm the exact field names and options in the GLPI version you run, since they vary by release.

Often yes, if the team has ownership of the source data, someone who can read the contracts, and time for reconciliation. The work falls into four parts: extraction, mapping, validation and cutover. Extraction and mapping are usually the largest effort because contract data is scattered across spreadsheets, shared drives and email. A partner typically adds value in building repeatable import scripts, designing the reconciliation checks and documenting the decisions. Ask any provider for a written scope that lists source systems, record counts, the test plan and the cutover checks, and compare that scope with what your own team can staff.

The cost depends mainly on how many contracts you hold, how many link to assets, and how much of your existing contract data must be cleaned up before import. Most of the work is one-time: defining contract types and supplier records, designing the link between contracts, assets and financial records, configuring renewal alerts, and loading the initial data. Recurring costs are smaller and usually limited to reviewing contract data as renewals come in. No DeployOpen price list is published, so ask for a quote built from a written scope that names the number of contract records, the asset types involved, the sources you are migrating from, and whether finance approvals must be modeled in GLPI. If you use GLPI Network subscriptions, those are separate recurring fees set by the vendor, and the GLPI Network subscriptions page lists the current tiers.

Duration is set by data readiness more than by configuration effort. A clean list of contracts, suppliers and linked assets can be configured quickly, while contracts stored in spreadsheets, email or paper usually need weeks of reconciliation before they can be loaded. Other drivers include how many notification recipients and renewal rules you need, whether contracts must tie into budgets and purchasing, and how many approval steps finance and procurement require. Ask the implementation partner for a timeline tied to named milestones in the written scope, and confirm when your finance and procurement reviewers are available, since those reviews often set the critical path.

Contract management touches three groups, and the project depends on each one providing data and decisions. Procurement should supply the authoritative contract list, supplier names, terms, notice periods and renewal rules, and should decide which contracts require explicit renewal. Finance should confirm cost centers, currencies, amortization or payment schedules, and how contracts must appear in financial records. The asset team should confirm which assets each contract covers, using identifiers already in GLPI or in their asset register. Agree early on one owner for each dataset, because unresolved conflicts between these sources are the most common cause of delay.

Yes, a capable internal team can configure contract records, types and renewal notifications in GLPI, since the contracts module is part of the core product. The harder parts are the design decisions: how contracts link to assets and entities, how financial data is recorded, how notifications reach the right owners, and how the data is kept accurate after go-live. Teams that lack spare time in procurement, finance or IT operations often bring in a partner for a fixed-scope piece, such as data migration or the notification design, and keep ongoing upkeep in-house. Check your own capacity, then compare an internal plan with a written partner scope before deciding.

Contracts, budgets and software licenses are separate GLPI topics that share data. A maintenance or support contract often represents a recurring cost that should appear in a budget, and a software license contract may cover counts that must be checked against inventoried installations. Design the links before loading data, so the same supplier, cost center and asset identifiers are used across all three. Confirm with your finance team which budget periods and amounts are tracked in GLPI and which stay in your accounting system, and decide who maintains license counts, because the GLPI license management topic explains why those records still need manual upkeep.

After handover, contract records remain in your GLPI instance, which runs in infrastructure you control, so ownership of the data stays with your organization. The ongoing work is keeping records current: adding renewals, closing expired contracts, updating supplier details, and reviewing whether renewal notifications still reach the right people. Ask whether the written scope includes documentation of the contract types, notification rules and financial links, and who will maintain them. Database backups must cover the GLPI database and configuration files, and any change to contract logic should be tested before it reaches production.

Engineers should verify four items before go-live. First, confirm that contracts link to the assets they cover and that the links display correctly for entities with restricted visibility. Second, test renewal and end-of-contract notifications for contracts marked as requiring explicit renewal, using a test contract with a near-term end date. Third, check that financial data entered on contracts matches the values finance expects. Fourth, confirm that the GLPI version you run, and any plugins, still behave as expected after upgrades. The GLPI documentation on contracts describes how notifications and financial integration are configured.