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.
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, 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:

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:

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), 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

See also

• Contracts — core contracts and templates.
• Leads display — where you enable Fast Contract and the lead components.
• Leads (list) — working with the leads list.