Bitrix24 and 1C integration
A deal in Bitrix24 becomes an order and an invoice in 1C, and the payment and the stock figure come back to the deal card. No amount is typed twice.
- Buildfrom $2,150
- Timeline2–3 weeks
- Supportfrom $420/mo
Who this suits: Companies where a manager runs the deal in Bitrix24, somebody enters the same order into 1C again, and the month closes with the two disagreeing.
What is in the first version
- deals and orders
- nomenclature map
- invoices and payments
- free stock
The figures above are the package this sits on: Integration and data pipeline. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
The deal reaches the document stage
You name that stage yourselves, and nothing is created in 1C before it: a lost deal leaves no order.
- 02
The invoice and payment come back
Payments accumulate on the card, and paid is derived from the sum rather than from the first payment arriving.
- 03
Stock goes out to the storefront
Stock travels from 1C on a schedule, already reduced by what unshipped orders have reserved.
What decides whether this works or annoys people
Nomenclature matches on a code
Matching runs on the 1C code, with the unit and VAT in the same row, and unpaired items wait for a person.
Payment is not yes or no
A deal with two states, paid and unpaid, breaks on the first deposit, so it carries an amount and computes the status.
The exchange survives a configuration update
The exchange lives in an extension and talks through a published service, so a 1C update stays an ordinary update.
What to measure once it is live
- deals reaching an invoice with no manual entry
- gaps between the deal and invoice amounts
- time from a payment to the status
- items with no pair in the nomenclature
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- Exchange and queuesPythonFastAPINode.jsTemporalRedisn8n
- Storage and deploymentPostgreSQLDockerS3Grafana
- The matching screenTypeScriptReactNext.js
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- 1C licences and the Bitrix24 plan
- the ITS subscription and franchisee work
- the exchange server and 1C publication
- an EDI operator for closing documents
Asked before the first call
- Our configuration has been modified. Will the exchange survive a 1C update?
- Yes, and that is why we do not edit the standard configuration. The exchange is an extension going through a published HTTP service, and we hand you the list of places to check after an update.
- Our Bitrix24 is in the cloud and 1C sits in the office. Will they connect?
- It will. The 1C side reaches out itself, so no port has to be opened, and if 1C is switched off for the night the tasks queue up until morning.
- Can we do one direction only to make it cheaper?
- You can, and often that is the right start. The rule for whose record wins is only needed where both systems are edited, and we name the fields you lose before the estimate.