How Can We Help?
When you add an assembly to an item on a Service
Order — the Line Assemblies button on the item opens the Order Line Assemblies
picker — each row is assessed against the original order’s warranty, the same way a
ticket line is.
The Warranty and Remaining columns
| Column | What it tells you |
|---|---|
| Warranty | The number of days the assembly’s warranty group allows. |
| Remaining | The number of days of cover left, as of today. |
Both cells are tinted, so the picture reads at a glance without having to read the
numbers.
Remaining can never show more than Warranty
The Remaining column is capped at the Warranty column’s figure. The clock counts from the
order’s delivery date, and on an order that has not shipped yet that is still a
planned date — so the raw count can legitimately run past the full term (a 365-day
warranty starting in 19 days computes as 384 days remaining). Showing that would read as a bug,
so the cell is capped at the allowance and its tooltip says when cover actually starts.
The Remaining column is capped at the Warranty column’s figure. The clock counts from the
order’s delivery date, and on an order that has not shipped yet that is still a
planned date — so the raw count can legitimately run past the full term (a 365-day
warranty starting in 19 days computes as 384 days remaining). Showing that would read as a bug,
so the cell is capped at the allowance and its tooltip says when cover actually starts.
A red cell with a zero Warranty is undetermined, not expired
A Warranty of zero, shown in red, means no cover could be determined for that assembly at
all — almost always a missing Family → Group mapping (see
Troubleshooting). It is a configuration gap to fix, not an
expired warranty, and it is not by itself a reason to charge the customer.
A Warranty of zero, shown in red, means no cover could be determined for that assembly at
all — almost always a missing Family → Group mapping (see
Troubleshooting). It is a configuration gap to fix, not an
expired warranty, and it is not by itself a reason to charge the customer.
The order’s job type can switch automatically
Accepting assemblies onto a service order looks at what was just added:
- If any assembly is provably out of warranty — a determinate assessment with no days
remaining — the job type switches to whichever job type your administrator has flagged as the
chargeable service type, and you are told so on screen. - If nothing is out of warranty but at least one assembly is provably covered, the job
type switches instead to whichever job type is flagged as the warranty (no-charge)
type. - An assembly whose cover could not be determined changes nothing either way.
Chargeable wins, and it sticks
Once an order has switched to the chargeable job type, adding a covered assembly afterwards does
not switch it back — the order stays chargeable. Un-billing work that has already proved
billable has to be a deliberate choice, made by hand on the Job Type combo, not something
a later assembly quietly undoes.
Once an order has switched to the chargeable job type, adding a covered assembly afterwards does
not switch it back — the order stays chargeable. Un-billing work that has already proved
billable has to be a deliberate choice, made by hand on the Job Type combo, not something
a later assembly quietly undoes.
Inert until an administrator sets it up
Both the chargeable and the warranty job types are flagged per tenant by an administrator, on
the job type itself (the underlying fields are
Warranty and Remaining columns still show, but the job type is never switched.
Both the chargeable and the warranty job types are flagged per tenant by an administrator, on
the job type itself (the underlying fields are
order_type.chargeable_service andorder_type.warranty_service). Until that is done, this whole feature is inert — theWarranty and Remaining columns still show, but the job type is never switched.