> ## Documentation Index
> Fetch the complete documentation index at: https://docs.a7manager.se/llms.txt
> Use this file to discover all available pages before exploring further.

# Warranty

> Claims raised from defects, grouped for negotiation, and taken through an approval workflow.

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

| Tab                    | Shows                                                                          |
| ---------------------- | ------------------------------------------------------------------------------ |
| **Claims** *(default)* | Individual warranty claims, with a detail drawer carrying the claim's timeline |
| **Claim Groups**       | Groups of claims negotiated together, and the claims associated with each      |

***

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

```mermaid theme={null}
stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> SUBMITTED: submit
    SUBMITTED --> UNDER_INVESTIGATION: investigate
    UNDER_INVESTIGATION --> ACCEPTED: accept
    UNDER_INVESTIGATION --> REJECTED: reject
    ACCEPTED --> ACCEPTED_CLOSED: close
    REJECTED --> REJECTED_CLOSED: close
    REJECTED --> DRAFT: reopen
    ACCEPTED_CLOSED --> [*]
    REJECTED_CLOSED --> [*]
```

| Transition                          | Who                                           |
| ----------------------------------- | --------------------------------------------- |
| `DRAFT` → `SUBMITTED`               | Warranty Manager                              |
| `SUBMITTED` → `UNDER_INVESTIGATION` | Warranty Supplier                             |
| `UNDER_INVESTIGATION` → `ACCEPTED`  | Warranty Supplier                             |
| `UNDER_INVESTIGATION` → `REJECTED`  | Warranty Supplier — a comment is **required** |
| `ACCEPTED` → `ACCEPTED_CLOSED`      | Warranty Manager                              |
| `REJECTED` → `REJECTED_CLOSED`      | Warranty Manager                              |
| `REJECTED` → `DRAFT` (reopen)       | Warranty Manager                              |

<Note>
  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.
</Note>

***

### 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:

<Steps>
  <Step title="The Warranty Manager proposes">
    Adds a claim to a group. The association is created as `PENDING`.
  </Step>

  <Step title="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.
  </Step>
</Steps>

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.

<Warning>
  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.
</Warning>

***

## 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

<Card title="Field reference" icon="table" href="/data/tables/warranty">
  `warranty_claim`, `warranty_claim_group` and the association table.
</Card>

## Roles

| Role                  | Capabilities                                                                                                             |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Warranty Manager**  | Create, edit and delete draft claims and groups; submit, close, reopen; propose and remove associations                  |
| **Warranty Supplier** | Investigate, accept, reject claims and groups; accept or reject association proposals                                    |
| **Asset Manager**     | Read claims, groups and history; **may post comments and upload documents**, but cannot change any status or association |
| **Project Admin**     | Everything above                                                                                                         |