MySklad: Integration with Bitrix24

What this solution does

This module integrates Bitrix24 CRM with MySklad warehouse accounting into a single operational workflow. Sales managers manage deals within the CRM interface, while corresponding customer or supplier orders are automatically generated in MySklad with full details, including client data, product composition, prices, discounts, and VAT rates. Any modifications made to documents in the accounting system are immediately reflected in the deal card. Data exchange occurs without the need for export files, manual push buttons, or manual line transfers.

The synchronization process is modular and flexible: each workflow, direction, and field can be configured independently. Implementation does not require activating all features at once; you can start by exporting deals, then add order composition, the client database, reference books, and bidirectional change synchronization.

Supported synchronization objects:

MySklad deals and customer orders (two-way sync).

MySklad deals and supplier orders (separate workflow with individual settings).

Bitrix24 contacts and companies, along with MySklad counterparties (including legal entities, individual entrepreneurs, and private individuals).

Client details: TIN, KPP, OGRN, full legal name, addresses, phone numbers, email addresses, and websites.

The integration synchronizes order composition, including deal line items and document positions: product name, quantity, price, discount, and VAT rate. Full nomenclature is supported: products, services, kits, and modifications (trade offers) with images and characteristics. The system transfers deal stages, document statuses, and counterparty statuses, along with data on the responsible manager and document currency. Configuration includes synchronization of counterparty tags (groups) and custom user fields from both systems. Supported reference books cover employees, currencies, units of measurement, and VAT rates.

The module operates on an event-driven basis without scheduled polling. When a manager saves a deal, the module instantly captures the event and queues the task, ensuring immediate card saving without waiting for an external service response. The queue independently checks filter criteria, searches for existing links, creates or updates documents, retrieves customer and product composition data, and records the association. Bidirectional synchronization works similarly: when a document or counterparty changes in MySklad, the module receives a notification, queues it, and updates the card in Bitrix24. The absence of scheduled API polling eliminates delays and reduces load on the accounting system's limits.

During repeated synchronization, the module compares collected data with the current state and transmits only changed fields. If no changes are detected, no write request is generated. Order composition is compared line by line: matching items remain untouched, while only those that have actually changed are updated.

Configuration without a programmer

All settings are managed through the module interface using lists and mapping tables, without requiring code editing.

Field mapping. Any field of a deal, contact, or company in Bitrix24 can be linked to any field of a document or counterparty in MySklad—standard, user-defined, or additional (attribute). Each pair has its own synchronization direction: to MySklad, to Bitrix24, or bidirectional.

Default values. Constant parameters such as organization, account, warehouse, or sales channel, which are not stored in the CRM, are configured via a rule rather than by creating separate fields in Bitrix24.

Linked record search fields. Connections between records are established using existing data fields: external code, tax ID (INN), or contract number.

Synchronization filters. Conditions set on fields determine which deals are sent to accounting and which documents are accepted back.

Mapping directories. Employees, currencies, units of measurement, and VAT rates are linked via an explicit table. This allows you to clearly see the connections between data and understand why a value was not transferred.

Automatic CRM field creation. The module automatically creates service fields required for integration (document type flag, counterparty type, status, tags) based on its own settings. No access to the Bitrix24 field builder is required.

Catalog setup assistant. Information blocks, sections, MySklad product groups, and link fields are selected from pre-filled lists, eliminating the need to manually enter identifiers.

Isolated settings. All parameters are stored within the exchange profile. Different profiles have their own matching settings, filters, and fields that do not interfere with each other.

Reliability: queues, checks, and error handling. The integration is designed to handle predictable failures, such as service unavailability, API request rate limits, or incorrect field data.

Exchange queue. Tasks accumulate in a separate queue for each profile and are processed in batches. Repeated changes to a single deal are merged into one task, preventing multiple requests to MySklad for a series of edits. If a failure occurs, the task is not lost but is retried with an increasing delay.

Configuration readiness check

Before each synchronization, the module verifies that settings are sufficient to locate and link records. If the configuration is incomplete, the exchange is not started to prevent the creation of duplicates. The status of synchronization for two document types, three counterparty categories, and four reference books is displayed on the dashboard.

Duplicate protection

Before creating a new record, the module searches for its counterpart on the other side and updates the found record. If the search fails due to an error, the exchange is paused and retried later. Creating a record blindly after an error is impossible, as this would guarantee a duplicate.

Prevention of circular exchanges

Records created by the module do not trigger a reciprocal exchange. Neither CRM events nor MySklad notifications are triggered for these records.

Queue management page

Every task is visible, showing direction, document type, status, number of attempts, and the full error text. Tasks can be executed manually or deleted without waiting for the scheduled time. An agent card is displayed nearby, indicating activity status, the time of the next launch, and buttons to reinstall or manually run the process.

Products and catalog

The product section is the most labor-intensive part of any integration, and here it is detailed thoroughly.

Products are searched using the selected link field: the external code (XML_ID) or a specific infoblock property in Bitrix24, and by the external code or internal identifier in MySklad. If the XML_ID is already occupied by an export from 1C or an online store, the module switches the link to a different property without disrupting existing integrations. Once a product is created, the link code is written back to ensure subsequent exchanges locate the existing item rather than creating a duplicate.

If a product does not exist in the second system, the module creates it automatically, transferring the name, description, unit of measure, images, and characteristics. Related entities are handled hierarchically: for a modification, the parent product is created first; for a kit, the components are created first. Trade offer properties (color, size, volume) are mapped to MySklad product characteristics, including lists, infoblock element bindings, and Highload-block dictionaries.

This approach allows order exchange to start without pre-exporting the entire catalog. The product list is populated as real orders arrive while maintaining synchronization on both sides.

FAQ

Is the data exchange one-way or two-way?

The integration supports two-way synchronization with granular direction control. You can configure data flow separately for each document type, product composition, responsible person, currency, tags, and specific field pairs. For instance, you can send the responsible person to MySklad without receiving it back.

Managers do not need to press an 'Export' button. The exchange is triggered automatically by CRM events: the creation or modification of a deal, contact, or company. The card interface contains no export buttons, allowing users to work normally without managing integration details.

Changes are typically transferred to MySklad immediately. After a task is created, the module attempts to process it in the background without waiting for the next agent run. Standard queue processing occurs once per minute. Updates from MySklad arrive as notifications at the moment a document is edited.

If MySklad is unavailable or the API request rate is limited, the task remains in the queue and retries automatically. The system performs up to three attempts with increasing delays between them. Temporary failures and rate limit exceedances are handled by automatic retry logic. If authorization in MySklad fails, the queue pauses to avoid wasting attempts.

The module employs matching mechanisms to prevent the creation of duplicate deals, orders, and counterparties.

Document exchange will not start unless at least one field for searching a linked record is configured. This is a mandatory system requirement, not a recommendation.

Can only a subset of deals be exported?

Yes. The filter allows setting conditions on fields such as direction, source, stage, date, and custom user fields. Available comparison operators include: equals, not equals, greater than, less than, contains, and does not contain. A separate set of conditions applies to importing documents from MySklad, for example, accepting only orders from a specific warehouse or organization.

How does the module distinguish between sales and purchases?

The type is determined by a rule you define using a custom deal field and its value. For instance, if the 'Deal Type' field is set to 'Purchase', the deal is treated as an order to a supplier. Deals without a specified flag are treated as customer orders by default. When importing from MySklad, this field is populated automatically.

Does the exchange support individual entrepreneurs and individuals, not just legal entities?

The module supports three counterparty types in MySklad: legal entities, individual entrepreneurs, and individuals. For each type, a separate link to a contact or company in Bitrix24 is configured, with specific fields and invoice templates selected for transfer. For legal entities, the system transfers TIN, KPP, and legal address; for individuals, it transfers passport details and contact information.

Invoice details, addresses, and phone numbers are transferred correctly. In Bitrix24, invoice details are stored in a separate linked entity. The module locates the appropriate template or creates a new one to store the values. Addresses are grouped by type, while phone numbers, email addresses, and websites are written to multiple fields on the card. Addresses and multiple values are transferred from MySklad to Bitrix24.

Pre-exporting the client base is not required. Since an order in MySklad cannot exist without a counterparty, client data is transferred automatically alongside the deal. Only clients with actual orders will be recorded in the system. Full exchange of the entire client base can be enabled separately when needed.

Deal stages and order statuses are synchronized.

Field mapping is performed manually via a correspondence table; automatic matching by name is not supported. When processing deals, the module automatically determines the sales funnel based on the stage. Without this mechanism, Bitrix24 could incorrectly change the stage by moving it to a different funnel. Stages without a corresponding match remain unchanged.

Product stock levels and price lists are not synchronized. The module synchronizes documents, contacts, and nomenclature cards. Prices and discounts are transferred as part of a specific document line item, meaning the actual price of the order is recorded rather than the current catalog price.

Deletion operations are not synchronized. Deleting a deal in one system does not delete the corresponding order in the other, and vice versa. This is an intentional safety measure: deletion is an irreversible operation, and automatically propagating it between systems poses a risk of data loss.

Leads are not included in the exchange. Synchronization covers only deals, contacts, and companies.

To diagnose why an order did not appear in the accounting system, open the task queue page. It displays the status of each task, the number of retry attempts, and the full error message. This allows for troubleshooting without reading server logs or contacting support. The queue also indicates the reason for skipping a task, such as a filter condition, missing settings, or no data changes.

The integration between MySklad and Bitrix24 uses a Bitrix24 agent scheduler (cron) to process the task queue and a public webhook URL on the portal to receive notifications from MySklad. The module automatically deploys the notification handler file via its interface and verifies the address availability with a real request, eliminating the need for FTP server access.

Requirements include: a boxed version of Bitrix24 with the CRM module installed; the 'Trade Catalog' and 'Information Blocks' modules for exchanging order composition and nomenclature; a MySklad account connected via access token or login and password (permissions are determined by the account that issued the token); a configured Bitrix24 agent scheduler; and a publicly accessible URL on the portal for MySklad webhooks.

Functional limitations:

The module does not synchronize stock levels or price lists.

It does not transfer record deletions in either direction.

It does not exchange lead data.

It does not synchronize product image changes after creation.

It does not resolve edit conflicts: if the same field is modified on both sides, the change executed last takes precedence.

The module does not automatically detect correspondences for employees, currencies, units of measure, or VAT rates. These parameters must be mapped manually, ensuring predictable behavior.

Setup begins by connecting to MySklad using a token or login with password. Service fields for the CRM are created directly within the module settings. Next, activate the required exchange contour — either customer orders or supplier orders — and specify the fields to search for related records. Then map the exchange fields and, if necessary, link stages to statuses.

The configuration status is displayed on the dashboard, showing what is ready and what remains to be adjusted. Once the main contour is operational, you can enable synchronization of product composition, the customer base, and the reception of notifications from MySklad.

General iT can install and configure this module and check how it works on your website.