Skip to main content
Warranty is where a fault becomes a commercial conversation with a supplier. A claim is raised from a defect, optionally joined into a group for negotiation, and moved through a status workflow with two sides: the operator and the supplier.

​
Tabs

​
Claims

A claim is created from a defect and is one-to-one with it — a defect can raise at most one claim, and every claim comes from a defect. Creation copies the defect’s title, description, vehicle, component and product group across. The product group link is fixed for the life of the claim. Every claim and group carries an immutable reference — WC-YYYY-NNNN for claims, WCG-YYYY-NNNN for groups — numbered per project and per calendar year. A claim also carries a type: DELIVERY (the default) for a fault in the product as delivered, or REPARATION for rework on a previously repaired asset. A REPARATION claim also records the original defect it reworks, picked from the recurrence matches when the claim is raised (see Recurring faults). Both the type and the link are fixed at creation; DELIVERY claims carry no original defect. Only claims in DRAFT can be edited or deleted. After submission the record is fixed and changes happen through status transitions, each of which writes an immutable entry in the claim’s history.

​
The status workflow

The same seven statuses and the same machine apply to both claims and groups.
There is no single CLOSED status. Closure splits into ACCEPTED_CLOSED and REJECTED_CLOSED so the outcome survives in the record. The close action picks the right one automatically from the current status.Rejection is not final: a rejected claim can be reopened to DRAFT, revised, and submitted again.

​
Claim Groups

A group collects claims that are being negotiated together — typically a systematic fault appearing across many vehicles. Groups have a type of SYSTEMATIC or MISC and run through the identical status workflow. Every group is classified on one product group, chosen at creation from one of the project’s vehicle types; the link is fixed afterwards.

​
Joining a claim to a group

Association is a two-party handshake:
1

The Warranty Manager proposes

Adds a claim to a group. The association is created as PENDING.
2

The Warranty Supplier decides

Accepting marks the association ACCEPTED and records who reviewed it and when. Rejecting removes the proposal entirely — there is no rejected state to look back on, and the pair can be proposed again later.
Two database constraints shape what is possible:
  • A claim belongs to at most one group. Only one accepted association per claim.
  • A claim can have at most one outstanding proposal, so the same claim cannot be offered to two groups at once.
Claims that are REJECTED or REJECTED_CLOSED cannot be proposed, and neither can claims already associated.

​
Status inheritance

When a group’s status changes, its accepted claims follow. This is the point of grouping: one decision on a systematic fault applies to every claim in it. The mechanics are worth understanding, because the effect is larger than it first appears:
  • A claim jumps straight to the group’s status, even when that means crossing several transitions at once. A group being closed can take a claim from DRAFT all the way to ACCEPTED_CLOSED in a single step. The intermediate statuses are never recorded.
  • Claims already at or beyond the group’s status are left alone, so inheritance never moves a claim backwards.
  • A claim also inherits the group’s current status at the moment its association is accepted.
  • Only ACCEPTED associations inherit. A claim with a pending proposal is untouched.
A group rejection propagates REJECTED to its accepted claims without a per-claim comment — the explanation lives on the group’s history rather than on each claim. Those claims then become ineligible for future association while still linked to the group.Removing a claim from a group does not roll back a status it inherited.

​
Recurring faults

The tab lists defects that already occurred on the same asset. Every pair carries one basis, the strongest reason it matched. Asset identity is the gate; the wording only has to line up where the taxonomy is too coarse to say “same fault” on its own. The matched defect must have occurred within the 90 days before the subject defect; a defect never matches a later one, so a pair is listed once, on the later defect. A defect is never matched against itself. Only recent defects get a row: those from the last 2 full weeks (Monday to Sunday, UTC) plus the current, unfinished week. Their matches still reach back the full 90 days. The drawer opened from a link shows a defect’s matches whatever its date. The Cross group basis catches a recurrence reported under the wrong product group; its threshold is a separate server setting from the text-match threshold. Text similarity is PostgreSQL trigram similarity over the concatenated title and description, shown as a percentage for every pair. It is a filter only on the Similar text and Cross group bases, where it must reach the threshold; on the other three it is informational and may be low. On every same-vehicle basis the recorded location and component act as filters: two defects with different non-empty locations, or with different components, are not a pair at all. A missing location or component on either side is neutral. Each grid row is one defect, aggregating its matches. Three columns show whether any match shares the component, the fault code or a deep product group (a green check badge, or a grey cross badge), and the Text column shows the top trigram score on a red-to-green gradient. A pair can tick several columns at once. Rows sort by the strongest criterion in the order of the table, then by descending score; the drawer shows the same four indicators per match. The number of weeks, the window and both thresholds are server settings.

Recurring faults logic

The decision order behind every match, as a flowchart, and what hides a pair.

​
Hidden rows

Two states take a defect out of the list. The tab never shows them; the API returns them flagged with the reason when asked (include_hidden):
  • Dismissed — a Warranty Manager judged the pair not to be a recurrence. The dismissal is stored as a normalised, symmetric defect pair per project, so it holds in both directions and at any threshold. It is permanent: no application action reverses it, only deletion of the similarity_recurrence_dismissal row.
  • Handled — the defect already carries a warranty claim of type REPARATION.
Dismissal is done from the drawer, one match at a time or with Dismiss all matches. The drawer also carries a Create warranty claim shortcut, which raises a REPARATION claim from the defect and so marks that defect handled. The claim records the matched defect as its original defect: a single visible match is used directly, several prompt for a pick, and with none visible the shortcut is not offered. Both actions are Warranty Manager only.

​
Comments, documents and history

Claims and groups both carry a timeline combining status changes, comments and uploaded documents. Status entries are immutable — they cannot be edited or deleted by anyone. Comments and attachments can be edited or removed by their author.

​
Tables

Field reference

warranty_claim, warranty_claim_group and the association table.

​
Roles