---
title: Fast Contract (issue from a lead)
description: Issue an internal contract straight from a lead through a guided dialog — without leaving the commercial flow. PF/PJ beneficiary, template, product category, annex, own numbering, and the number pinned back on the lead.
product: TSync Intelligence 11.3.6
language: en
canonical: https://docs.tsync.pro/fast-contract/
source: https://docs.tsync.pro/llms.txt
---

# Fast Contract (issue from a lead)

**Fast Contract** lets you **issue an internal contract straight from a lead** through a guided dialog, without
stepping through the nomenclatures by hand. You pick the beneficiary type, the template, the product category, fill
in the data and the annex, and the system creates the contract, links it to a real client, and assigns it its **own
number** (e.g. `GC-0253`) which you then see as a link on the lead.

The feature is **optional** and **off by default** — a stock install is unchanged until you enable it.

## Before you start

1. **Enable the feature** — an admin turns it on from the leads settings (the *Fast Contract* option). See
   [Leads display → Components](leads-view-settings.md).
2. **The `Fast Contract` permission** on the role row — admins have it automatically.
3. **At least one contract template** configured in **Contracts → Templates** with its settings:
   - **beneficiary type** (individual / company / both),
   - whether it has an **annex** and whether the annex **populates the contract value**,
   - **own numbering** (prefix, suffix, padding, start number),
   - the **applicable product categories** and the **dynamic texts** (warranty, maintenance, installation, delivery, etc.).

Without a configured template the dialog has nothing to offer — that's why it's the first step.

## Step by step — issuing

1. **Open the lead** (either the standard view or the BX view). Below the lead profile you'll see the **"Issue
   contract"** button and the list of contracts already issued for that lead.
2. Click **"Issue contract"**. The guided dialog opens, prefilled with the lead's data.
3. **Beneficiary** — choose **individual (PF)** or **company (PJ)**. The choice filters the available templates (a
   template marked "company only" won't appear for an individual).
4. **Template** — pick one of the templates suited to the beneficiary. The template decides the clauses, the annex,
   and the numbering.
5. **Product categories** — the list opens from a single button that says how many you have chosen ("2 of 12
   selected"). Click it to open, tick what you need, click it again to close. It starts **closed**, so a long
   nomenclature no longer fills the window and there is nothing to tick by accident; the filter box at the top
   narrows a long list as you type. You can pick **several categories** at once — no key to hold down, and it
   works on a touch screen. Each one brings its own texts (warranty/maintenance/installation/delivery/special
   terms/technical notes). Where the text is the **same** across the categories you picked, it is printed
   **once**; where it differs, it is printed **under each category's name**, so it is clear which condition covers
   which product. If a text is missing under every category, you're warned.

   **Contract currency** — sits in the same top row, beside the template. Choose it **before** you type any
   amounts: it is what gives the contract value, the advance and the balance their meaning, and the annex is
   printed in it.
6. **Contract data** — fill the common fields plus the PF- or PJ-specific ones (IDNP/CNP, address, bank details,
   contact person, etc.). The identity field (IDNP in MD, CNP in RO) is country-aware from the lead's country and
   prefills the client's saved value if there is one.
7. **Annex** — if the template has an annex, add the lines (product, quantity, price). **The total is computed
   live** and, when the template allows, **auto-fills the contract value**. When you picked several categories,
   each line also gets a **Category** column, limited to the categories chosen above; in the contract it prints as
   a column of its own, **Denumire** (Name). With a single category the column is not shown.
   **Price or amount — fill in whichever you have.** If the job was negotiated as one round total (e.g. 15.3 m.l.
   for 12,000), type the **amount**: it is kept exactly as agreed and the unit price is worked out from it. If you
   have a unit price, type that and the amount follows. Don't fill in both — the second one fills itself. This is
   what removes the rounding losses: a price rounded to 2 decimals (784.31 × 15.3 = 11,999.94) can no longer
   break the agreed total.
   **The unit of measure is picked from a list**, no longer typed by hand — the same units as your install's
   nomenclature (pcs, m.l., set, kg…), so you don't end up with "m.l", "ml" and "m.l." across three different
   contracts. If your install has no nomenclature filled in, the field stays free text as before; and if an older
   annex has a hand-typed unit, that one stays selected — nothing you already agreed is rewritten.
   **The specification can span several lines.** Press `Enter` in the field to put, say, the dimension on one
   line, the colour on the second and the material on the third; the issued contract keeps the lines exactly so.

   **You do not have to type the specification by hand.** A **„Choose specification”** button under the field
   opens a list of ready-made options for that line's category: glass thickness and shade, sandblasting,
   accessory finish, profile painting, plus the attributes specific to the category (opening type, fixing
   system, model…). Tick what applies, press **„Apply”**, and the text is composed for you in the field — where
   you can still edit it freely. The point is to stop the same product arriving as „Sliding”, „Slading” and
   „Sliding glass” across three contracts.

   **„Profile painting” is required** and you cannot apply the specification without answering it. The reason is
   concrete: already-signed contracts contain rows printing „RAL (        )” with the colour left blank, and
   that cannot be repaired after signature. If the position genuinely **is not painted** — raw aluminium, inox
   components, a glass-only position — pick the first option in the list, **„fără vopsire”** (no painting).
   Do not invent a colour just to move on: „no painting” is a valid answer, it is recorded in the contract, and
   it reads clearly as a decision rather than a box somebody forgot to fill in.
8. **Advance date** — prefilled with today, i.e. the day you issue the contract, because that is the usual case.
   If the client pays the advance on a different day, pick that date from the calendar; it goes into the contract
   wherever the template asks for the advance date, so you no longer have to reopen the contract after issuing it
   and type the date in by hand.
   **There is one date field here, not two.** Some templates also declare "advance date" among their own
   variables. That variable is filled **automatically** from this field — it was never meant to be typed into — so
   it is no longer drawn a second time. Enter the date once and every place the template prints it follows.
9. **Discount** (optional) — see the section below.
10. Click **"Issue"**.

## Discount on the annex

If you hold the right, a **"Grant a discount"** checkbox appears under the annex table.

**You enter an AMOUNT, not a percentage.** The percentage is worked out for you and shown in a field you cannot
edit, next to the resulting **net total**. That way the two can never disagree on a signed document: the amount
is what was agreed, the percentage is only a reading of it.

On the issued contract the annex gains **a final row named "Discount"**: the **quantity** column carries the
computed percentage and the **amount** column carries the discount amount. The annex total — and through it the
contract value, the advance and the balance — is worked out on the **net**.

A few safety rules:

- The discount **cannot exceed the annex total** — a larger value is capped automatically, so you can never end
  up with a negative contract.
- If you later change the annex lines, **the discount stays the agreed amount** and the net is recomputed
  against the new subtotal.
- With the box unticked, the contract looks **exactly as before** — no extra row.

### Who may grant a discount

This is a **separate permission**, `Can grant a discount on the annex total`, on the **Fast contract** row of the
role matrix. It does not follow from being allowed to issue contracts: someone may be trusted to issue a contract
at list price without being trusted to give money away. Administrators have it automatically.

If a user lacks the permission the checkbox **does not appear** at all — and if someone tried to submit a
discount anyway by going around the interface, the server **rejects** it with a message rather than quietly
ignoring it.

## What happens on issue

- **Duplicate check** — the system looks for an existing client by fiscal code / IDNP / name / phone / e-mail and,
  if it finds one, offers "use existing / create new" before duplicating.
- **Client created or linked** — a **real client** is created (or linked) in the Contracts module, with the
  signatory and the link to the lead, so the contract is fully functional.
- **The economic partner comes first** — if the lead is already linked to an
  [Economic Partner](modules/economic-partners.md), the contract is bound to **that partner's** client, and the
  beneficiary details (company name, fiscal code, address) are filled from the partner first, the client second
  and the lead last. That's what keeps one company from ending up as two identities — the contract appears in the
  partner's dossier instead of hanging off a look-alike client created from a phone number.
- **Own number** — the next number in the template's series is allocated **transactionally** (no duplicates),
  consumed only on issue.
- **Frozen snapshot** — the template, category, texts, parties, and annex are saved as a **snapshot**; later edits
  to the template do **not** change already-issued contracts.
- **Number pinned on the lead** — the lead shows **"Contract no. GC-0253"** as a link to the contract.
- **No negative figures** — a negative quantity, price or amount on an annex line is refused with a clear
  message, on the issue dialog and on the later annex editor alike, so a stray minus can never quietly shrink a
  contract's total.

### If you change the contract's currency afterwards

The snapshot is frozen, but the **currency is not stuck**. Change the currency on the contract header and TSync
**re-renders the frozen text and the annex in the new currency** — the table, the total and the amount in words
follow. The figures themselves are not re-converted (a contract negotiated as 12,000 stays 12,000); it is the
currency label and the written-out amount that are brought back in step, so the document never reads "RON" over
a EUR contract. The change is written to the audit log.

## Opening the editable contract on generation

Turn on **Configurare → Lead-uri → Componente → "Open contract text on generation"** and, when you issue a contract
via Fast Contract, the system takes you **straight to the editable contract** — a complete preview you can review and
edit before printing:

- **Fields already filled in** — every merge field shows its real value (company, fiscal code, address, dates…); an
  empty field is left **blank**, so you never see a raw `{slug}` on the document.
- **Header and footer visible** — if your company has set a document letterhead (antet & subsol) scoped to contracts,
  it renders around the text.
- **Fully editable** — if you have free contract-text editing rights, you can change anything.

### Save button on the toolbar

The editor's toolbar (the WYSIWYG bar at the top of the **"Contract"** text tab) carries a **Save** button — a
floppy-disk icon (hover shows "Salvează"), first, right next to the built-in **Undo** and **Redo**. The toolbar is
**sticky**, so it stays pinned at the top while you scroll a multi-page document — you don't have to scroll back up or
switch to the "Informații contract" tab to save. **Save** writes the contract exactly like **Ctrl+S**; **Undo/Redo**
step through your edits. The toolbar is a fixed bar centred on the screen and stays put while you scroll; its buttons
lay out on multiple rows so they are all visible without a horizontal scrollbar.

### Editing the annex at review (automatic recalculation)

The annex table in a Fast-Contract-emitted contract is generated automatically from the annex data, so in the editor it
appears as a **locked** region (you don't type directly into the cells — that would break the link to the data and, in the
past, duplicated the table). To change it at review, use the **"Edit annex"** button above the text (or click the annex
table itself) — a grid opens where you edit each line's **specification, quantity, unit and price**:

- the **line amount** (quantity × price) and the **total** recalculate **live** as you type;
- the **amount in words** is rewritten automatically below the grid;
- you can **add** or **remove** rows;
- if the contract covers **several categories**, each line also has a **Category** picker (limited to the
  contract's own categories), and the category prints in the annex table's **Denumire** column;
- you can edit the **amount** directly: the unit price is recomputed and the negotiated amount is left alone (and
  if you then change the quantity, the amount stands while the price adjusts).

When you press **Save annex**, the system recomputes everything and **renews in place**: the annex table, the **contract
value in figures and in words** in the contract text, and — if the advance is set as a **percentage** — the advance/balance
amounts and their wording. The contract body doesn't need a separate save; the new values show in the preview and in the
printed PDF. A **signed contract** cannot be edited this way.

## Several annexes on one contract

A long-running contract is not delivered in one go: the work arrives in tranches, agreed one at a time. So a
contract can carry **several annexes** — Annex 1, Annex 2, Annex 3 and so on.

Below the contract text you will find the **"Annexes to the contract"** panel. It lists each annex with its
number, date, value and status, plus the **cumulative value** (the sum of every annex). The contract's own value
does **not** change: it stays the figure it was signed at, and the total is shown separately, as information.

> If the annexes are in **different currencies**, the system will not add them into one total — that would be an
> invented number. It shows the breakdown instead.

### Annex 1 is different from the rest

**Annex 1 is part of the contract text** — it prints inside it, and you edit it from the "Edit annex" button
above the text. It has no number or date of its own: it borrows the contract's.

**Annexes 2, 3, 4…** are **documents in their own right**. Each has its own number and date, prints separately
(the **PDF** button on its row) and **does not touch the contract text**. That matters: a contract signed in
January must still be exactly the document that was signed after you issue Annex 3 in November.

### Adding and filling an annex

1. **Add annex** — it appears immediately, with the next number and today's date.
2. **Edit** on its row — the same grid as Annex 1 opens, where you enter specifications, quantities, units and
   prices.
3. **PDF** — prints the annex as a separate document.

An annex with **no lines** cannot be printed: a page headed "Annex No.3" with nothing under it is not a document.

If the annex covers a **product category** the contract did not, that category's texts (warranty, installation,
delivery, special clauses) print as **additional provisions below the annex table** — never inside the contract
body, for the same reason: a signed contract must not change.

## Signing supplementary annexes

Annexes 2, 3, 4… are **signed separately from the contract**, each on its own date.

An annex that has lines shows a **"Mark as signed"** button. It asks for **the date the parties signed** — not
the day you got round to recording it, because those are rarely the same day. The row then reads
**"Signed · date"**.

**Annex 1** shows **"Signed with the contract"**: it prints inside the contract text, so it is signed together
with it and cannot be signed on its own.

### What changes once it is signed

- The annex **can no longer be edited or deleted** — the buttons are simply gone, not greyed out.
- The annex **prints exactly as it was signed**. The document is frozen at the moment of signing, so a later
  change to the layout (column widths, hiding the Price column) does **not** alter what the client already
  holds.
- A **contract that is already signed can still be given new annexes** — precisely the case this exists for.

If you marked an annex as signed by mistake, **"Undo signature"** returns it to an editable state. That action
is written to the audit log, as is signing.

> **This is not an electronic signature.** The system records that the parties signed (on paper), who recorded
> it and when — the same as "mark as signed" on a contract. There is no client-facing signing page and no
> acceptance name/e-mail/IP is collected.

## Managing issued contracts

In the lead's contract list (both the standard dialog and the BX-view block) each contract has actions:

- **Open the PDF** — the contract number links to the completed PDF (`/admin/contracts/pdf/<id>`).
- **Edit** — reopens the dialog prefilled from the contract; on save it **re-issues keeping the number** and deletes
  the old row only after the new one is created (a failed re-edit never loses your original).
- **Delete** — for a contract issued by mistake; it cleans the contract, the lead link, the meta, and the annex
  (blocked on a signed contract). If the contract row is already gone (an orphaned link), delete cleans the leftovers.
- **Regenerate from template** — re-applies the current template text keeping the same number and parties (the
  historical parties and annex stay frozen); never on a signed contract.

## The "Contract" card (leads imported from amoCRM)

If the lead was imported from amoCRM, the **"Contract"** card in the left column shows each contract's **number**
(not the URL), lists **all** of the lead's contracts, and each one links to **download the completed PDF**. The
edit/manage actions stay in the Fast Contract block below.

## Different templates, different fields

Not every contract needs the same things. A commission contract for an architect has **no advance at all** — it
needs a commission percentage instead. A service contract may have no installation deadline.

Each contract template now decides which rows the issue window shows.

### Turning a row off

Open **Setup → Contract templates**, edit the template, and find **"Fast Contract window — which rows to show"**.
Untick a row and it disappears from the issue window **for that template only**.

You can switch off: installation deadline, installation address, contract notes, advance, balance, advance date,
advance as a percentage, and discount.

Everything is ticked by default, so a template you never touch behaves exactly as it always did.

> A row you switch off is not merely hidden. If a value for it somehow arrives anyway — from a browser tab left
> open since before you changed the template — it is discarded. A commission contract cannot end up carrying an
> advance.

### Adding a field that is not on the list

A commission percentage, a warranty period, a delivery term — anything specific to one kind of contract — is
added as a **Variable**, in the panel just above.

1. First create the field once, in **Setup → Custom fields**, for **Contracts**. Name it plainly, e.g.
   *Procent comision*.
2. Back in the template, add it under **Variables**, give it the label the manager should see, and optionally a
   hint that appears under the box.
3. In the template body, write the token the field produces — for a field named *Procent comision* that is
   `{contracts_procent_comision}`.

The field then appears in the issue window under **Template fields**, for that template only, and what the
manager types lands in the contract where you put the token.

Nothing else has to be declared anywhere. The token exists because the custom field exists.

## Merge fields

In the template editor, the **merge-fields** panel offers the tokens that resolve automatically on issue: the
client data (`{client_name}`, `{client_company}`, `{client_vat_number}`, `{client_IDNP}`, address/e-mail/contact
person), the contract number, the installation address/deadline, the value, and the **amount in words**
(`{contract_value_in_words}` and the `_in_words` companion for any numeric field). So your amoCRM-style template
fills in **without** manual edits.

## The signature block is no longer split across pages

The requisites and signature table at the end of a contract — the one with *Contractor / Beneficiary*, the
fiscal codes, the IBANs and the signature lines — **moves whole to the next page** when it no longer fits on
the current one, instead of being cut in half. A page carrying two signatures that no longer says whose they
are is a real document problem, especially when the contract is signed on paper.

Lines written **below** the table (for example "PROJECT MANAGER" and the name) move **with** it.

**Configuration → Leads → Components:**

| Setting | Default | What it does |
|---|---|---|
| **Keep the requisites / signature block on one page** | Yes | The switch. |
| **Largest block, in rows** | 20 | Above this, the table is left exactly as it is today. |
| **Largest block, in characters** | 2000 | Same. |

The budgets exist for a practical reason: a contract pasted out of Word can have **its whole body inside a
single table** as tall as the page. Pushing such a table would blank the page before it — so only a **small**
table at the end of the document is treated as a signature block. Raise the thresholds only if a genuine
signature block is being missed.

> ℹ️ The rule applies **when the PDF is generated**; it does not modify the saved contract text. An
> already-issued contract simply reprints correctly.

## Troubleshooting

## Where each value comes from

The window fills itself from **two different sources**: the lead (contact person, phone, email) and the
**Economic Partner** linked to it (legal name, fiscal code, VAT code, registered office, bank details,
signatory). Until now the fields looked the same whatever filled them, so the only way to check was to open the
partner's record in another tab.

Now, above the beneficiary data, a sentence **names the fields**:

> From the Economic Partner **Premium-Cons Grup SRL**: Company, Fiscal code, VAT, Registered office, Address,
> Bank details, Signatory. **From the lead:** Signatory (client), Phone, Email.

On a lead with **no** linked partner, the sentence says only *"From the lead: …"*.

**The VAT code and the registered office now fill themselves in** when the partner has them. Until v9.5.7 they
were retyped every time — the VAT code was never fetched at all, and the registered office landed in a field
that is hidden on legal-person contracts, which is exactly where it is needed.

> ℹ️ The seat is taken strictly from the address marked **legal** on the partner. If only a delivery address is
> recorded there, the field stays **empty** — a delivery address printed as a company's registered office would
> be a wrong document, not an approximate one. Fill in the legal address on the partner and it will be used.

## What you type on a contract is saved onto the partner

Until now this went one way only: the window READ the Economic Partner record and never wrote back. So when the
director and the phone were missing you typed them onto the contract by hand — and next time they were missing
again. The same question, on every contract.

Now, on emit, what you filled in is saved onto the partner record:

| What you typed on the contract | Where it lands on the partner |
|---|---|
| Company | the legal name |
| Position, phone, e-mail | on the primary contact person |
| Registration number · VAT code | two **separate** identifiers |
| Registered office | the address marked **legal** |
| Bank requisites | the bank account (see below) |
| Signatory, their function and authority | the person **allowed to sign** |

The next contract for the same partner comes up already filled in.

### Nothing is overwritten

**Only empty fields are filled.** If the partner record already holds a value, it stays — even if you typed
something else on the contract.

> A DIFFERENT value arriving is not a correction. It can mean this contract is for somebody else, and silently
> replacing the record would erase exactly that signal.

To change a value on the record, change it **on the record**.

### Bank requisites: an account only when there is an IBAN

The *Requisites* box is free text. A **bank account** is created from it only when the text contains a **valid
IBAN** — validated by its checksum, not merely "looks like one". Whatever is left of the sentence becomes the
bank name.

With no IBAN, a failing checksum, or **several** IBANs, the text is saved as a **note on the partner**, carrying
the number of the contract it came from.

> A note a person reads beats a bank account guessed out of a sentence. A wrong account is a payment
> instruction nobody wrote.

### The signatory

The signatory's name is compared with the people the partner already has — **capitals, extra spaces and
diacritics do not make a different person**, so "ION POPESCU" and "Ion Popescu" are one person and do not
appear twice.

If the person genuinely is not on the record, they are **created** and marked as allowed to sign. The name was
typed precisely because it was missing, and a contract they signed is evidence, not an assumption.

## Re-open a contract and everything comes back

The re-issue button opens the window with the contract's values. Until v10.8.2, five boxes came up **empty**:
*Requisites*, *Phone*, *E-mail*, *Position* and *Registered office*.

The data was saved all along — the window simply never asked for it back. The effect was that re-issuing saved
the emptiness, and it looked as though regenerating "loses" what you typed.

> A value that is stored, correct and never asked for looks exactly like one that was thrown away.

They all come back now. And the **registered office** comes back as the one saved on THAT contract, not the
partner's address today: re-printing an issued contract must show what it was issued with.
## Who signs for the beneficiary

On a **legal person** contract, the window asks separately who **signs** — a different question from "who do we
talk to". If the economic partner has contacts marked with **signing authority** (see
[Economic Partners](modules/economic-partners.md)), a picker appears, and three fields below it fill themselves
in: the **name**, the **position** and the **authority** ("on the basis of the articles of association", "on the
basis of power of attorney no. 12 of 03.02.2026").

Every option in the list says **why** it is offered: *Partner's default signatory*, *Has signing authority*,
*Mandate expired*, or *Primary contact — signing authority not confirmed*. The last option, **"Another
person"**, clears the fields so you can type somebody who is not on the record.

When the proposal does not rest on a recorded mandate, the window **says so** before you issue:

- *"No contact of this partner is marked as having signing authority. The primary contact is being used,
  unverified."*
- *"This person's signing mandate expired on … Check the authorisation before issuing."*

These are **warnings, not blocks** — you may know something the record does not. But you see them before you
press Issue, not after the contract has been signed.

The three values are **frozen into the contract** at issue time, along with the rest of the data. If the
director leaves or the power of attorney is replaced a year later, the already-issued contract stays exactly as
it was signed.

## How the annex table looks in the PDF

The annex is built automatically from the contract lines, so it is the one table you **cannot** reshape by hand
in the template editor. Its appearance is set in a single place:

**Settings → Leads → Components → "Annex table in the PDF"**

- **Column widths** — you give a number for each column (Line no., Name, Specification, Quantity, Unit, Price,
  Amount). Only the **ratio** between them matters: a column set to 20 comes out twice as wide as one set to 10.
  Below the fields there is a **preview bar** showing, live, what share of the page width each column takes —
  change a number and you see the result immediately, without saving and without generating a PDF.
  They are weights rather than percentages because **optional columns disappear when they are empty on every
  row** (no category, no unit of measure, no unit price). With weights, the surviving columns share the freed
  space between them and the table always fills the page width.
- **Column alignment** — under each width you pick Left / Center / Right, and it applies to both the header and
  the rows. Everything is centred by default **except Price and Amount, which stay right**: that is what makes
  `3,578.00` and `15,070.00` start at the same decimal, so figures can be compared at a glance and the **Total**
  row lands under the Amount column. You can centre the money too — just know what it costs you.
- **Row height** — set through the **row padding** (0–20 px). More padding, taller rows.
- **Font size** — `0` keeps the document's font; `6`–`14` pt applies to the annex table only (useful when an
  annex with many lines has to fit on one page).

If you change nothing the table looks right — the defaults are the ones intended for an ordinary contract.

### The Price column can be hidden, per contract

Some clients get the unit price in the annex, others only the per-row amount. In the **annex window** (at issue
time or via "Editează anexa") there is a **"Show the Price column"** tick.

It is saved **on that contract**, not globally. That matters: hiding a column changes what the client sees, so an
annex already sent is never altered because someone changed a setting later. The default for new contracts is
chosen in Components.

The per-row Amount and the Total are unchanged — only the unit-price column goes, and the remaining columns widen
to fill the page.

### The category column, and the annex printed as its own document

The same window carries the tick for the **category column** ("Denumire"), saved on the contract in the same
way. An annex can also be printed as a **separate document** — and that document used to decide the column on
its own, by the old rule *"print it if any line carries a category"*, so the tick you set on the contract
changed the annex inside the contract and not the one you sent separately. Two views of the same annex could
therefore contradict each other.

They no longer can. The printed annex answers in this order:

1. **the annex's own choice**, if it has one;
2. **the contract's choice** — the same document printed two ways may not disagree with itself;
3. **the installation default**, but only when it is switched **on**.

That last restriction matters more than it looks. The default ships **off**, and reading "off" as a firm *no*
would newly hide a column that line categories have been printing for years, on every install that never
touched the setting — removing a capability while appearing to add one. "Off" therefore still means *decide by
the old rule*, and an install that asked for nothing gets exactly the output it had before. An explicit **no**
on the contract is never overridden by a default **yes**: an answer a person gave beats a value nobody chose.

> **Tables you draw yourself** in a template (not the annex) keep the column widths **exactly as you drag them
> in the editor**. There is nothing to configure for those.

## Troubleshooting

| Symptom | Likely cause |
|---------|--------------|
| The "Issue contract" button doesn't appear | the feature is off, or you lack the `Fast Contract` permission |
| No template appears in the dialog | no template is configured for the chosen beneficiary type |
| The contract shows `#id` instead of `SF-…` | that template has no own numbering configured (prefix/suffix) |
| A `{...}` token appears literally in the PDF | the token isn't registered in the template's merge fields |
| In the PDF the annex columns all come out the same width and a text wraps onto two lines | older than v8.7.3 — update; from v8.7.3 the widths are set in Components |
| You widened a column in the editor but the PDF ignores it | older than v8.7.3 (the width was being stripped when the PDF was generated) |

## See also

- [Contracts](contracts.md) — core contracts and templates.
- [Leads display](leads-view-settings.md) — where you enable *Fast Contract* and the lead components.
- [Leads (list)](leads.md) — working with the leads list.