Asset service contracts

Service entitlements in xMatix are two layers. A service contract definition (the Item Service Contract record) is authored once against the contract item you sell — its validity in days, its usage windows, its grace allowances, its covered scope, and how covered work is billed. An asset service contract is one asset's copy of that definition, created when the contract item is invoiced against that asset, and it is what the platform actually checks when a service line claims contract cover. The definition is the product; the asset contract is the entitlement.

Read the screen

123456 Expand

1. 1

   Name is the generated entitlement number; open it to see the scope lines and the full date, hours and reading limits.

2. 2

   Asset is what the contract resolver matches on together with the definition named on the service order or line.

3. 3

   Billing Account is the payer for covered work; blank on generated rows until someone sets it.

4. 4

   Due Date is what contract-schedule campaigns watch for reminders; Activated Date (right) is the day cover began — the invoice document date on generated rows.

5. 5

   Is Utilized marks a consumed single-use entitlement; the platform never sets it, so a True here was ticked by a person or an automation.

6. 6

   New creates an entitlement by hand for cover that did not arrive through an invoice.

Start in All Asset Service Contracts. The register shows each entitlement's name, covered asset, billing account, due and activated dates and the Is Utilized flag. Filter by asset before opening a row: a definition existing in setup is not proof that this asset holds an eligible entitlement, and a row flagged utilised, or one whose valid-till date plus grace has passed, will be refused even though it points at the same definition as a live one. The entity is reached from whichever app your administrator placed it in (or directly by its list at /AssetServiceContract); it is not an entry of the Service app.

123456 Expand

1. 1

   Name is the only mandatory field; give the entitlement a name that identifies the asset and the contract so it can be found from the service order.

2. 2

   Activated Date is the day cover began. On generated entitlements it is the invoice document date and the Due and Valid Till dates are counted from it.

3. 3

   Service Contract Item is the sellable item; Service Contract (right) is the Item Service Contract definition whose flags and posting treatment decide how this entitlement is enforced.

4. 4

   Asset is the covered unit the resolver matches on; Billing Account is the payer for covered work and is never filled by the invoice generator.

5. 5

   Due In, Valid Till and Grace Usage each carry a date, an hours ceiling and a usage-reading ceiling; the lapse check evaluates them separately.

6. 6

   Populate Contract Lines lets a new service order, opportunity or quote for this asset and contract pull the entitlement's scope lines in automatically, for the quantities still pending.

The create form is one activated entitlement, not the reusable definition. Name is the only mandatory field. Service Contract Item and Service Contract name the originating item and definition — the definition is the one whose flags (active contract required, single use, restricted scope) and posting treatment are enforced; Asset is the covered unit; Activated Date starts the entitlement history; Billing Account is the payer for covered work. Contract Posting Treatment appears on the form but is a calculated field with no formula on this entity, so it stays blank — the treatment that counts is the one on the definition (and, as a fallback for lines, the entitlement's own free-text Posting Type, which the generator does not fill either). The Due In, Valid Till and Grace Usage tabs hold the three limit families — calendar dates, usage hours and usage readings — which the lapse check evaluates independently, so never collapse them into one informal expiry date. Populate Contract Lines is a live switch: when it is on and the entitlement is not utilised, a new service order, opportunity or quote that names this asset and this definition receives one line per scope line that still has a pending quantity (the service order only when it was not itself created from a quote or opportunity). Hand-created entitlements get their scope lines from the Lines tab of the saved record.

123456 Expand

1. 1

   The header names the definition (Service Contract), the Activated Date and the Due and Val Till dates that the lapse check and reminder campaigns read.

2. 2

   Lines is the scope tab; Details holds the limit and billing fields.

3. 3

   The record count shows how many scope lines the entitlement carries — one per definition line on generated rows.

4. 4

   Component Item and Quantity: a Part or Work Item line on the service order must appear here to be covered. Open a line for its utilised and pending quantities.

5. 5

   Quick Add adds a scope line by hand — how a hand-created entitlement gets its scope.

6. 6

   Edit and Delete are the only header actions; no field is locked after creation.

After saving, the record header summarises the service contract, activated, due and val-till dates, and the body opens on two tabs. Lines lists the entitlement's scope lines — one per covered component item with its quantity; open a line for its utilised and pending quantities — and Quick Add is how a hand-created entitlement gets its scope. Open this tab whenever restricted coverage matters, because that is where covered items and quantities live.

123456 Expand

1. 1

   Service Contract is the Item Service Contract definition whose flags and posting treatment are enforced; Service Contract Item (left) is the sellable item.

2. 2

   Contract Posting Treatment is a calculated field with no formula on this entity, so it stays blank — the definition's treatment is what applies.

3. 3

   Val Till Date, Hours and Usage Reading are the expiry ceilings; each is extended by its Grace Usage value before the lapse check fails.

4. 4

   Due In holds the next-service thresholds that contract-schedule campaigns use for reminders.

5. 5

   Populate Contract Lines: when on, a new service order, opportunity or quote for this asset and definition pulls in the scope lines that still have pending quantity.

6. 6

   Billing Account is the payer for covered work; generated entitlements leave it blank.

Details is the entitlement audit: Key Information binds definition, activation date and asset (Contract Posting Treatment stays blank here by design); Valid Till, Due In and Grace Usage separate the date, hours and reading thresholds; Billing Account names the payer. Reconcile these values with the definition before approving covered work. The header actions are the platform's Edit and Delete (Clone is also granted on the entity); the platform fences no field on this entity, so any value can be corrected by an editor.

The definition: authored on the item

A service contract definition carries:

The entitlement: created when the contract is sold

The entitlement is created by the invoice's inventory posting (the posting action, not a plain save) for every invoice line whose item is of type Service Contract. The platform finds the definition by the line's item or SKU, checks the definition's date-effective window against the invoice's document date, and takes the asset from the line (or from the package parent line when the contract was sold inside a package). Asset contracts can also be created by hand for entitlements that were not sold through an invoice; enforcement is identical.

Three honest limits of the current generation. The Billing Account and the entitlement's own Posting Type are left blank on generated rows. Each generated scope line's pending quantity starts at zero: invoicing a service order adds the consumed quantity to the scope line's utilised quantity, but nothing recomputes the pending quantity from quantity and utilised quantity. Because the restricted-scope check compares the service line's quantity with that pending quantity, and because Populate Contract Lines only copies lines whose pending quantity is positive, a scope-restricted or auto-populating entitlement does nothing useful until someone fills the pending quantities on its scope lines by hand — and keeps them in step with what has been consumed.

The due date on the entitlement is what contract-schedule campaigns watch to generate reminder leads before the service falls due; those campaigns skip entitlements that are already utilised or whose val-till date has passed.

How contracts shape service work

The contract is named in two places. The Service Contract field on the service opportunity or service order header tags the whole job; each line can also carry its own Item Service Contract. In both cases the platform resolves the asset's matching entitlement automatically — the asset contract for that asset and that definition which is not utilised and not lapsed — and stamps it onto the header or line (an entitlement someone picked that belongs to a different definition is cleared and re-resolved). Lapse during this resolution is judged on the failure date recorded on the document where there is one, otherwise the document date. A header contract also switches on the usage band check: the usage reading and usage hours captured on the order (or on a check-in inspection linked to the opportunity) must sit between the definition's minimum and maximum usage reading and hours, inclusive; a bound left at zero is treated as not configured. From there the checks apply in this order, each with its own message:

• Definition not found — Missing Contract. Please check if the Service Contract exists and try again.
• Active contract required with no eligible entitlement — No Active Asset Service Contract. This Service Contract requires an active Asset Service Contract! (restricted-scope and single-use definitions have their own variants of this message).
• Single use already consumed — This is a Single Use contract and has already been utilised!
• Lapse, with the specific limit — The validity of this contract has lapsed!, The Usage Hours for this contract has lapsed!, or KM reading exceeds service contract usage limit. Each limit is extended by its grace allowance first; this validation judges dates against the document date.
• Restricted scope — the line's item must appear in the entitlement's scope lines (The Item is not in scope of active Service Contract!) and its quantity must fit the scope line's pending quantity (The quantity of the Item exceeds the quantity allowed under this Service Contract!).
• Line fence on service orders — a Part or Work Item line whose own Item Service Contract does not list that item on its lines is refused with Item '…' is not covered by Item Service Contract '…'. Only Items listed on that contract's lines can be added. Charge items and nested contract items are not fenced, a line with no contract is unconstrained (paid labour), and a definition with no component lines has no scope to enforce. This fence applies to service-order lines only, not to opportunity or quote lines.

Contracts also decide the money. When an opportunity, quote or service-order line is saved, its posting type is overwritten with the definition's posting treatment if the line's item is on the definition's scope lines; when no treatment applies (no contract on the line, item outside the definition's lines, treatment not configured) the line falls back to Generate Invoices only if its posting type is still blank — an existing value is never replaced. A line that reaches contract validation with a blank posting type takes the entitlement's own posting type first, then the definition's treatment. Lines posted as Generate Claims or Auto Generate Claims route to claims on the paying principal at invoicing time, while Generate Invoices lines bill the customer — decided per line, on the same order.

Common questions

Where do asset service contracts come from?

Automatically, when an invoice carrying a Service Contract item is posted: the line against the asset creates the entitlement with dates, usage windows, grace and scope derived from the definition. Manually, for entitlements that arrive another way. Either way the enforcement is identical.

The customer clearly has a contract — why is the line refused?

Read the exact message. Missing Contract means the definition itself was not found; No Active Asset Service Contract means no eligible entitlement matches the asset and definition; the lapse messages (validity, usage hours, KM reading) mean an entitlement exists but a limit plus its grace has passed; the single-use message means it was already consumed; the scope messages mean the item or quantity is outside the entitlement's scope lines — and remember that generated scope lines carry a zero pending quantity until edited.

What does the grace allowance actually do?

It extends every limit before the lapse check fails: days past the val-till date, hours past the usage-hour ceiling, distance past the reading ceiling. It exists so a customer marginally over the limit is not refused cover on arrival.

Who can create or edit asset service contracts?

Anyone whose security profile grants the Asset Service Contract entity: the record carries the standard New, Edit, Clone and Delete actions and no Service-specific permission, and the platform does not lock any field after creation. Because a hand-edited entitlement changes what the service order validates against, keep write access narrow and leave the definition-derived fields alone unless you are deliberately correcting a generated row — or maintaining the two values only a person maintains today: Is Utilized on single-use entitlements and the pending quantity of scope lines.

Who pays for contract-covered work?

Whoever the posting treatment says. Generate Invoices bills the customer; Generate Claims and Auto Generate Claims turn the covered lines into claims on the paying principal at invoicing time. The routing happens line by line, so one order can bill the customer for consumables and the principal for the covered repair.

Related topics

• Estimates and invoicing
• Running service campaigns
• Contract records
• Trade claims
• Asset — entity reference
• Contract — entity reference
• Asset Service Contract — entity reference