# The document lifecycle

```
create business (once per end user)
   └─ create draft ──> PATCH / DELETE freely (a draft is a "קובץ זמני", not a tax document)
         └─ issue ──> IMMUTABLE forever. Number assigned. PDF rendered + digitally signed.
               ├─ prints: origin (מקור): downloadable ONCE ever; then copies (העתק)
               └─ corrections: ONLY by issuing a credit note (or negative receipt)
```

Two rules Israeli law imposes, which the API enforces:

1. **Issued documents can never be edited or deleted**, not by you and not by us (blocked at the database engine). Mistakes are corrected by issuing a **credit note** (חשבונית מס זיכוי) linked to the original, or for receipts a negative receipt. Plan your UX accordingly: confirm before issue.
2. **The origin (מקור) is delivered exactly once** (הוראה 18(ב)2). The first `prints` call with `kind: "origin"` returns the origin PDF and permanently consumes it; every later download must use `kind: "copy"` and returns a PDF watermarked "העתק" (copy). Deliver the origin PDF straight to the end customer. **Recommended: use `kind: "auto"`**, which serves the origin on the first ever print and copies forever after, so a repeat download button never errors; the `X-Print-Variant` response header says which variant you got.

### Document types

| Code | Name | When | Needs lines | Needs payments | VAT |
|---|---|---|---|---|---|
| `305` | חשבונית מס (tax invoice) | Billing, payment later | ✓ | - | ✓ |
| `320` | חשבונית מס/קבלה (invoice/receipt) | Billing + payment together, **the common case** | ✓ | ✓ | ✓ |
| `330` | חשבונית מס זיכוי (credit note) | Correcting 305/320, issued via the credit-note endpoint and not directly | ✓ | - | ✓ |
| `400` | קבלה (receipt) | Payment received (no VAT invoice) | - | ✓ | - |

**Dealer type decides what's allowed:** an עוסק פטור (`"patur"`) may issue **only receipts (400)**, no VAT documents. `"murshe"` (עוסק מורשה), `"company"` (חברה) and `"ngo"` (עמותה) may issue all four. Sending a disallowed type returns `doc_type_not_allowed`. Ask your users their dealer type at onboarding and reflect this in your UI.