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 and component across, and takes its subsystem from the defect’s product group where one is set. 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.

​
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.

​
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