Готовый модуль и собственная интеграция с 1С в смете на три года

В одном предложении на обмен с 1С написано «установить модуль», в другом — «разработать интеграцию». Сравнить итоговые суммы легко. Гораздо труднее понять, включают ли они одну и ту же работу через год, когда изменится учётная конфигурация или появится новый склад.

Перед выбором стоит привести оба варианта к одинаковому горизонту и одинаковой задаче. Готовый модуль может сократить объём разработки, а собственный обмен — точнее соответствовать нестандартному процессу. Ни один вариант не освобождает магазин от сопровождения и ответственности за данные.

У «1С-Битрикс: Управление сайтом» есть штатные возможности обмена с 1С. Официальная документация описывает взаимодействие на основе CommerceML и ограничения по редакциям продукта. Это основание проверить встроенный вариант до покупки дополнительного решения, но не обещание совместимости со всеми изменёнными конфигурациями 1С.

Отдельно существуют решения сторонних разработчиков. В их стоимости могут различаться лицензия, право получать обновления, установка и сопровождение. Нужно читать условия конкретного продукта и конкретного предложения. Формулировка «поддерживается 1С» слишком широка: значение имеют конфигурация, её редакция и доработки, версия модуля на сайте, направления обмена и состав данных.

Для собственной интеграции вопрос столь же предметный. Заказчик получает не абстрактный «исходный код», а определённый набор компонентов, документацию и порядок сопровождения. Код без инструкции по развёртыванию, тестовых данных и описания соответствий полей может остаться зависимым от автора не меньше, чем закрытый модуль.

Условный магазин продаёт обычные товары по одному прайсу и передаёт заказы в типовую учётную систему. Если поддерживаемый обмен уже покрывает эту задачу, написание всех операций заново требует отдельного обоснования. Само желание «всё контролировать» ещё не показывает, за какую пользу платит бизнес.

Другой магазин получает цены из 1С, ограничения продажи — из отдельной системы, а доступность считает по правилам резервирования между складами. Готовый модуль может закрывать часть цепочки, но вокруг него появятся дополнительные обработчики. Сравнивать нужно полную систему, включая эти обработчики, а не её самый заметный компонент.

Полезно выписать обязательные сценарии и отдельно исключения: повтор события после сбоя, отмена заказа после частичного исполнения, изменение состава заказа, расхождение справочников. В этом сравнении не нужен новый огромный документ приёмки. Нужны несколько примеров, которые показывают границу применимости готового решения. Попросите исполнителя указать, какой сценарий поддерживается настройкой, какой требует расширения и какой вообще не входит в предложение.

Если ради одного нестандартного поля предлагается заменить весь обмен, стоит спросить о локальном расширении. Если ради экономии предлагается изменить ключевой бизнес-процесс под модуль, следует оценить цену такого изменения для сотрудников. Иногда сочетание штатного обмена и небольшого изолированного дополнения оказывается третьим вариантом, который теряется в споре «купить или написать».

Ниже учебный пример в тысячах рублей, а не рыночные цены и не предложение услуг. Горизонт — три года с момента запуска. Налоги и общие расходы магазина исключены из обоих вариантов одинаково. Вариант А использует готовое решение с адаптацией; вариант Б — собственную интеграцию. Состав обязательных операций у них одинаков.

Для А получается 570 тысяч рублей: 60 + 180 + 90 + 240. Для Б — 840 тысяч: 420 + 60 + 360. В этой модели готовое решение дешевле на 270 тысяч. Но результат относится только к выбранным исходным данным; он не доказывает, что любой модуль выгоднее собственной разработки.

Теперь выясняется, что одно обязательное изменение формата обмена потребует у А отдельной переработки стоимостью 320 тысяч, а у Б такая работа уже включена в согласованный объём сопровождения. Тогда суммы станут 890 и 840 тысяч соответственно, и разница поменяет знак. Если у Б изменение тоже оплачивается отдельно, его стоимость нужно добавить в ту же модель. Нельзя считать доработку бесплатной только потому, что код принадлежит заказчику.

Этот пример показывает полезный вопрос к смете: какие события способны изменить итог? Не нужно придумывать десятки аварий с произвольными вероятностями. Достаточно выделить известные планы магазина, например переход на новую конфигурацию учёта, и получить оценку для обоих вариантов. Неопределённые расходы лучше показать диапазоном, чем прятать за точной, но необоснованной суммой.

Строка «техническая поддержка» часто объединяет разные услуги. Ответить на обращение, найти причину сбоя, исправить код и повторно провести пропущенные данные — не одно и то же. Если оплачено только консультирование по модулю, ежедневное восстановление обмена может остаться задачей команды магазина.

В предложении полезно отдельно видеть, кто наблюдает за остановкой обмена, кто разбирает ошибки на стороне 1С и сайта, кто проверяет совместимость обновлений и кто выполняет повторную обработку. Это распределение работы, а не требование назначить одного исполнителя виновным за любую неисправность. У сторон могут быть разные зоны доступа и разные обязательства.

Обновления тоже имеют стоимость даже без нового счёта за лицензию. Нужны тестовая копия, время специалиста и понятное возвращение к прежней версии при ошибке. Доработка непосредственно внутри чужого модуля может усложнить последующее обновление: изменения придётся сопоставлять и переносить. Изолированное расширение иногда уменьшает такую зависимость, но возможность и устойчивость расширения проверяют для выбранного решения.

В смету стоит включить передачу сопровождения. Следующая команда должна получить описание потоков, мест хранения настроек, порядка выпуска и повторной обработки. Секреты передаются штатным защищённым способом, а не в пояснительной записке. Возможность заменить исполнителя оценивают по воспроизводимости работ и понятности системы, а не по одному обещанию «всё открыто».

Для магазина, который ещё проверяет ассортимент и процессы, быстрый запуск на поддерживаемом типовом обмене бывает оправдан. В этом случае полезно заранее признать ограничения и определить признаки пересмотра решения. Например, регулярная ручная обработка исключений стала занимать несколько часов в день или новое направление продаж нельзя подключить без глубокой переработки.

Для устойчивого нестандартного процесса собственная интеграция может уменьшить количество обходных решений. Но это аргумент в её пользу только при наличии команды и бюджета на дальнейшее развитие. Разработка, для которой после запуска не предусмотрено сопровождение, не становится самостоятельной от того, что её назвали индивидуальной.

Выбор можно завершить короткой записью: одинаковый набор задач, полный трёхлетний расчёт, известные исключения, ответственные за эксплуатацию и события для пересмотра. Тогда через год у магазина останется объяснение принятого решения. Сравнивать новый запрос на доработку придётся с согласованными границами, а не с памятью о том, что при запуске «обещали интеграцию целиком».

One proposal for 1C exchange says "install the module," while another says "develop an integration." Comparing final sums is easy. It is much harder to understand whether they include the same work a year later, when the accounting configuration changes or a new warehouse appears.

Before choosing, bring both options to the same horizon and the same task. A ready-made module may reduce development volume, while a custom exchange may better match non-standard processes. Neither option frees the store from maintenance and responsibility for data.

1C-Bitrix: Site Management has built-in capabilities for exchange with 1C. Official documentation describes interaction based on CommerceML and limitations by product edition. This is a basis to check the built-in option before purchasing an additional solution, but not a guarantee of compatibility with all modified 1C configurations.

Separate solutions from third-party developers exist. Their costs may differ regarding licenses, rights to receive updates, installation, and maintenance. You must read the terms of the specific product and the specific offer. The phrasing "supported by 1C" is too broad: the configuration, its edition, and customizations, the module version on the site, exchange directions, and data composition matter.

For custom integration, the question is equally specific. The client receives not an abstract "source code" but a defined set of components, documentation, and a maintenance procedure. Code without deployment instructions, test data, and field mapping descriptions can remain dependent on the author just as much as a closed module.

A hypothetical store sells standard products at a single price list and sends orders to a standard accounting system. If the supported exchange already covers this task, rewriting all operations requires separate justification. The mere desire to "control everything" does not show what benefit the business pays for.

Another store receives prices from 1C, sales restrictions from a separate system, and calculates availability based on reservation rules between warehouses. A ready-made module may cover part of the chain, but additional handlers will appear around it. You must compare the full system, including these handlers, not just its most visible component.

It is useful to list mandatory scenarios separately from exceptions: event retry after a failure, order cancellation after partial fulfillment, order composition changes, and discrepancies between reference data. This comparison does not require a new massive acceptance document. A few examples showing the boundaries of applicability for a ready-made solution are sufficient. Ask the implementer to specify which scenario is supported by configuration, which requires extension, and which is not covered by the proposal.

If replacing the entire data exchange is proposed for a single non-standard field, ask about a local extension. If a key business process is proposed to be modified for the sake of a module to save costs, evaluate the cost of such changes for employees. Sometimes a combination of standard exchange and a small isolated add-on turns out to be a third option that gets lost in the "buy or build" debate.

Below is a training example in thousands of rubles, not market prices or a service offer. The horizon is three years from launch. Taxes and general store expenses are excluded from both options equally. Option A uses a ready-made solution with adaptation; Option B uses a custom integration. The set of mandatory operations is identical for both.

For A, the total is 570 thousand rubles: 60 + 180 + 90 + 240. For B, it is 840 thousand: 420 + 60 + 360. In this model, the ready-made solution is 270 thousand cheaper. However, this result applies only to the selected initial data; it does not prove that any module is more cost-effective than custom development.

It now turns out that one mandatory format change will require A to perform separate work costing 320 thousand, while for B this work is already included in the agreed maintenance scope. The totals then become 890 and 840 thousand respectively, and the difference changes sign. If B also pays for the change separately, its cost must be added to the same model. One must not consider a modification free just because the code belongs to the customer.

This example highlights a useful question for the estimate: which events can change the final result? There is no need to invent dozens of accidents with arbitrary probabilities. It is enough to identify known store plans, such as a transition to a new accounting configuration, and obtain an estimate for both options. Uncertain expenses are better shown as a range than hidden behind a precise but unsubstantiated figure.

The "technical support" line often bundles different services. Responding to a ticket, finding the cause of a failure, fixing code, and reprocessing missed data are not the same thing. If only module consultation is paid for, daily synchronization recovery may remain the store team's responsibility.

In the proposal, it is useful to clearly see who monitors the synchronization stop, who analyzes errors on the 1C and website sides, who checks update compatibility, and who performs reprocessing. This is a distribution of work, not a requirement to assign a single person as responsible for any malfunction. Parties may have different access zones and different obligations.

Updates also carry a cost even without a new license invoice. A test copy, specialist time, and a clear path back to the previous version in case of error are needed. Direct modifications inside a third-party module can complicate future updates: changes must be matched and ported. An isolated extension can sometimes reduce such dependency, but the extension's capability and stability must be verified for the chosen solution.

The estimate should include the transfer of support responsibilities. The next team must receive documentation describing data flows, configuration storage locations, release procedures, and reprocessing workflows. Secrets must be transferred via standard secure channels, not included in explanatory notes. The ability to replace the vendor is evaluated based on work reproducibility and system clarity, not on a single promise that everything is open.

For a store still validating its assortment and processes, a quick launch using a supported standard exchange may be justified. In this case, it is useful to acknowledge limitations in advance and define criteria for revisiting the decision. For example, regular manual handling of exceptions may begin consuming several hours per day, or a new sales direction cannot be integrated without deep restructuring.

For a stable, non-standard process, a custom integration can reduce the number of workarounds. However, this argument holds only if there is a team and budget for further development. Development that lacks post-launch support does not become independent simply because it was labeled as individual.

The choice can be summarized in a brief note: an identical set of tasks, a complete three-year calculation, known exceptions, operational owners, and events for review. Then, after a year, the store will have an explanation for the decision made. Any new request for modifications must be compared against the agreed boundaries, not against the memory of what was promised at launch: full integration.