The Bitrix24 commercial proposal template breaks on deals
Manual CP assembly breaks not at approval, but earlier — at the moment the document is prepared.
The manager opens a file sent in the chat, manually inserts prices from the latest email, takes terms from a previous deal, and counterparty details from a card that was not checked after the legal entity changed.
As a result, the client receives a document with an outdated discount, and accounting receives an invoice with wrong details.
The Bitrix24 commercial proposal template works differently: the deal print form is generated on the system side and inserts values from the card fields — amounts, item list, timelines, company and counterparty details.
As long as the document lives in the template rather than in a separate file, it has one data source and one version.
Document version divergence begins where the template goes off on its own. Someone edits the terms in a local file, the manager changes the discount in the deal — and two different sets of numbers go to print.
The more such copies are sent by email, the higher the chance that the client will see terms we are no longer ready to fulfill.
Errors in details are a separate loss category: the legal entity name, tax number, and bank details are inserted by copying from an old document, and the discrepancy surfaces only at payment.
The invoice does not go through, the deal stalls, and the investigation eats up the manager's and accountant's time. We explain how this is closed by configuring the template and deal print forms.
What changes when the CP is assembled from the deal
The template in Bitrix24 assembles the document directly from the deal card: it pulls in the client's details, item composition, prices, and payment terms, while the manager only checks the result.
The source fields and the template are linked, so a value that is not in the deal cannot get into the CP.
The CP preparation time stops depending on the manager's workload. Previously, the file was assembled manually after discount approval: items were transferred, prices were checked, and confirmation from the manager was awaited.
Now the document is generated with a button in the deal in minutes — the template inserts current prices and terms itself, and when the composition changes, it is enough to regenerate the file rather than re-layout the document.
The number of discrepancies between the deal and the sent file is reduced to isolated cases. A single data source removes manual transfer: the price, deadline, or term changes in the deal and reaches the CP from there as well.
A discrepancy becomes an exception visible in the generation log, not the norm that is discovered only after sending to the client.
The share of returns for rework falls due to a single document standard. The template fixes the structure, block order, formatting, and required sections, so each CP does not need to be checked for compliance with the regulation.
Edits are made once in the template and then apply to all new documents — the standard holds without manual control, and the manager focuses on the deal rather than layout.
Template formats: deal print form, blocks, external layout
In Bitrix24, a commercial proposal can be issued in three ways, and they are not interchangeable: each has its own data source and its own edit point.
The choice determines who can change the template — an administrator, a manager, or a designer — and how the document will behave on a deal with a non-standard composition.
| Option | When it fits | Limitations |
|---|---|---|
| Deal print form | One or two standard documents are needed directly from the card, without manual layout | Works based on deal fields and product items; conditional blocks and calculations require customization; edits are made by an administrator |
| Block builder | A manager assembles a CP from ready-made sections for a client request | The set of blocks is limited; non-standard layout is reproduced only partially; an abundance of sections slows down assembly |
| External CP layout | A document with complex layout, footnotes, and appendices is needed | Data is transferred by export — discrepancies in fields cause errors; the layout is maintained by a designer, the manager does not edit it |
How the mode is chosen
The choice of CP issuance mode is determined by deal frequency, composition variability, and the strictness of corporate style requirements.
In practice, the formats are combined: the standard form covers the flow, while the external layout covers large deals with individual appendices. We fix the mode during task analysis: it determines which deal fields must be filled in and where the template master copy is stored.
How we assemble the CP: from field audit to handover
The Bitrix24 commercial proposal template breaks not in the layout, but in the data. One deal field is empty, another is pulled from the contact card, the manager edits a third manually — and the sent file has the wrong price.
That is why we start with a field audit and finish by training those who print from the template every day.
- Deal field audit — data sources: deal, product items, company, contact. We mark required values, duplicates, and fields that come through empty.
- Data insertion scheme — a "template variable → field → rule" map. For each item, we decide: insert directly, calculate by formula, take a default value, or hide the block.
- Template and print form setup — document assembly, page breaks, tables for an extremely long specification rather than a single line.
- CP test runs — reference deals with scenarios: empty contact, discount, many items. We check the file line by line against the expected result.
- Access rights and versions — who edits the template and who only prints. Changes go through the responsible person, and the version is recorded.
- Handover of the solution into operation — regulations, instructions, review of typical errors, so the solution does not remain in the chat.
- Manager training — we show, using their deals, where each line comes from and what to do with an empty field.
Acceptance is not the first page, but the share of CPs going to the client without manual edits. We measure it in the second week after handover.
What you receive: CP layouts, field schemes, regulations
The handover package describes not what we did, but how you will continue to issue CPs on your own. All artifacts are stored in Bitrix24, linked to deal entities, and tested on a person who is seeing the system for the first time.
- Deal field scheme — what the manager fills in manually, what is pulled from the client and product cards, and which fields are required to generate the document.
- CP layouts — a template with insertion areas, variants for different service lines, formatting rules: logo, margins, page numbering.
- CP issuance regulations — at which funnel stage the document is generated, who approves it, and how the version and the fact of sending to the client are recorded.
- Access rules — a rights matrix: who edits the template, who only generates documents, and the procedure for granting and revoking access when an employee changes.
- Manager instructions — a review of typical situations: the client asks for a discount, a new item is needed, a resend or edit of an approved CP is required.
- Exchange map with 1C — which details and prices come from the accounting system, at what frequency, and what to do in case of a discrepancy.
- Change log — what and when changed in the template, so edits do not break documents already sent to clients.
We check each item with a test run: an employee who did not participate in the project assembles a CP from the deal card to the finished file using the instructions.
If a "where can I look at this" comes up along the way, the documentation is incomplete, and we finish writing it before delivery.
Case study: instead of manual CP layout — assembly directly from the deal
The client is a manufacturing company with a sales department of about fifteen managers.
The commercial proposal was assembled manually: the previous document was copied, the composition, prices, and details were replaced, and then the tables were proofread together with the manager. One document took 40–60 minutes.
Only 38% of 120 CPs sent per quarter went to the client without edits after the first draft. The rest were returned to the manager: a discrepancy in items, a previous price, the wrong header, or the wrong terms block. Support received 25–30 formatting requests per month, and half of them repeated the same error.
What we changed
The template was assembled inside Bitrix24 and linked to the deal card: the composition is pulled from product items, prices and discounts from deal fields, and terms and details are inserted by client type.
The manager checks the data and exports the finished document — the layout is fixed, and the header and signatures are inserted automatically.
A month after launch, time per document dropped to 6–8 minutes, the share of CPs without manual edits grew from 38% to 91%, and formatting support requests fell to 3–5 per month. The manager ceased to be a mandatory approval step: they review only non-standard terms.
We separately defined behavior for incomplete data: if a field in the deal is empty, the block does not disappear but is marked for the manager. Price list edits are made in one reference book, not in a hundred copies of documents on disk.
How does the deal print form differ from an external layout?
The deal print form is a template inside the card: the system itself inserts the client's data, item composition, discounts, and responsible person's details, and the document is assembled with a button from the current state of the deal.
Edits in the fields immediately go into the next generated file, so there are no discrepancies between what is in the system and what went to the client. This is the main option when the proposal must be assembled quickly and identically for all managers.
An external layout is a separate file that is prepared and stored outside the card. It offers almost unlimited formatting flexibility: a non-standard grid, corporate graphics, multi-page layout, and signature fields.
The price for this is that data is transferred manually, which means there is a risk of outdated prices and typos.
The differences between the formats are visible in three things. Data composition: the print form takes everything from the deal fields and product items, while the external layout takes only what was put into it by hand.
Formatting flexibility is inversely proportional to data connectivity: the freer the layout, the less automation.
Document maintenance matters more than it seems. In the print form, changes are centralized: edit the template — it updates for everyone, and the edit history is tracked.
With an external layout, each version is a separate file, and six months later no one remembers which one is current, while clients receive different editions in parallel.
In practice, a hybrid is chosen more often: the print form is responsible for data, and the external layout for the visual shell in special cases. We will analyze which option suits your situation.
Technical doubts before the start
A commercial proposal template is not a document but a bundle: deal card, fields, print form, and the rule by which it is assembled. Therefore, before the start, we fix what remains on our side after handover and what you cover yourself.
What can be edited after handover?
Texts, block composition, section order, and the logo are changed in the visual editor without a developer. We edit the field insertion logic and output conditions — a targeted customization so the link with the card does not break. Along with the solution, we provide regulations describing this division.
What if deal fields change?
Output is linked to the field identifier, not its name, so renaming breaks nothing. If the type changes or a new field is added, we update the insertion rule in one place, and then the template picks it up itself. We mark the fields required for the proposal; otherwise the document will go out with empty places.
Does one template work for several sales funnels?
Yes: the form is assembled according to conditions — funnel, stage, client type. If the funnels have different field structures, we make a template for each and a shared details block so as not to duplicate data and desynchronize it.
What are the limitations of the approach?
The template does not fix data: if managers fill in the card partially, the proposal will have gaps. Complex layout with a floating table structure is limited by what the print form can do — we agree on such places in advance and move them into fixed blocks.
What is included in solution support?
We update the bundle when cards and funnels change, investigate output failures, and refine blocks according to your edits. Requests follow the regulations with an agreed response procedure — no "catch the developer" on the day of sending to the client.
Let's discuss the task: what is needed to start
To come back with an estimate and work plan rather than general wording, we need input on your environment. Below is what we request from your side and what we clarify ourselves: this is enough to calculate the scope of work, start order, and timelines.
- Access: a Bitrix24 portal with administrator rights or a separate account for our team, and a test environment where documents can be assembled without affecting live deals.
- Data: which fields about the client, items, discounts, and terms are inserted into the document now and which should be — including calculations that are done manually today.
- Samples: two or three current commercial proposals in printed and electronic form, logos, requirements for the printed version, signatures, and the approval procedure.
- Scenario: by which event the Bitrix24 commercial proposal template is generated, whether document versions, edit history, invoice, and contract are needed in the same chain.
- Roles and access: who sees and edits the template, who approves the final version, and what rights restrictions are already set in the portal.
- Limitations: which portal settings must not be changed, and whether there are external systems from which prices and stock come.
On our side, we will check what is covered by the portal's standard tools and what requires customization, and we will come back with a work plan and start order. Describe the task — we will clarify the details on a call and send an estimate.