How to Draft a Technical Specification for Integrating an Online Store with 1C: What to Describe Before Development

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

Хорошее техническое задание не обязано описывать программный код. Оно должно снять неопределённость: какие данные участвуют в обмене, где находится их источник, как сопоставляются объекты и что должно произойти при ошибке.

Начинать удобнее не со списка полей, а с таблицы потоков. Для каждого объекта укажите источник, получателя, направление, частоту и ответственного владельца данных.

Например:

Эта карта сразу обнаруживает конфликты. Если менеджер может менять цену и в 1С, и на сайте, нужно заранее определить, чьё изменение имеет приоритет. Иначе обмен будет исправно перезаписывать работу одного из сотрудников.

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

В ТЗ следует указать:

Для обмена через CommerceML обычно важны внешние идентификаторы объектов, но само наличие стандарта не отменяет проектирования. Доработанные конфигурации 1С, несколько инфоблоков или каталог поставщика могут менять схему сопоставления.

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

Отдельно ответьте на вопросы:

Чем точнее эти правила, тем меньше ручной уборки после первой полной выгрузки.

Заказ — не один документ, а последовательность изменений. В ТЗ полезно описать весь путь: создание на сайте, передача в 1С, резервирование, оплата, сборка, отгрузка, отмена и возврат.

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

Нужно заранее определить соответствие статусов. Статус «выполнен» на сайте и документ реализации в 1С могут отражать разные моменты процесса. Простое сопоставление по похожим названиям часто даёт ложные уведомления покупателю.

CommerceML, REST API, очереди сообщений и файловый обмен — это способы доставки данных, а не цель проекта. Выбор зависит от объёма каталога, допустимой задержки, версии продуктов, возможностей конфигурации 1С и требований к устойчивости.

В техническом задании стоит зафиксировать ограничения: сколько товаров и предложений передаётся, как часто должны обновляться остатки, допустимо ли полное обновление, есть ли несколько сайтов или баз, какие порты и адреса доступны, требуется ли шифрование и ограничение по IP.

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

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

В ТЗ должны быть ответы:

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

Формулировка «данные синхронизируются корректно» непроверяема. Замените её конкретными сценариями. Например: изменение остатка в 1С появляется на сайте не позднее чем через десять минут; повторная загрузка того же пакета не создаёт второй товар; оплаченный заказ передаётся в 1С один раз; неизвестное значение свойства попадает в журнал и не останавливает остальные позиции.

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

Практичное задание можно собрать из девяти разделов:

Такой документ не отменяет обследование, но переводит разговор из области «связать две системы» в набор проверяемых решений. Это помогает точнее оценить проект и, главное, не обнаруживать бизнес-правила уже после запуска.

The phrase "connect the website to 1C" sounds like a task, but it contains almost no data for estimation or development. In one project, the accounting system transmits only stock levels; in another, it sends the entire catalog, prices, and images, while orders are returned. Even the same word "price" can mean retail price, wholesale price, contract price, or a price calculated after authorization.

A good technical specification does not need to describe source code. It must eliminate ambiguity: which data participates in the exchange, where the source is located, how objects are matched, and what should happen in case of an error.

It is better to start not with a list of fields, but with a flow table. For each object, specify the source, recipient, direction, frequency, and the responsible data owner.

For example:

This map immediately detects conflicts. If a manager can change prices both in 1C and on the website, you must determine in advance whose change takes priority. Otherwise, the exchange will reliably overwrite the work of one of the employees.

The name and article number are not always suitable for linking objects. Names are edited, article numbers sometimes repeat, and one product on the website can have multiple product variants by color and size.

The technical specification should specify:

For exchange via CommerceML, external object identifiers are usually important, but the mere existence of the standard does not eliminate the need for design. Modified 1C configurations, several information blocks, or a supplier catalog can change the mapping scheme.

The phrase "export product cards" is too broad. List the fields and rules for each entity: name, article number, VAT rate, unit of measurement, brand, properties, weight, dimensions, barcodes, images, categories, prices, and stock.

Separately answer the following questions:

The more precise these rules are, the less manual cleanup is required after the initial full export.

An order is not a single document but a sequence of changes. The technical specification should describe the entire path: creation on the website, transfer to 1C, reservation, payment, picking, shipping, cancellation, and return.

For each stage, specify which data is transferred and who can modify it. Scenarios where an order is edited after synchronization are especially critical: the buyer changes the address, the manager replaces an item, payment arrives late, or the delivery service splits the shipment.

You must define status mapping in advance. The "completed" status on the website and the sales document in 1C may reflect different stages of the process. Simple matching by similar names often triggers false notifications for buyers.

CommerceML, REST API, message queues, and file exchange are methods of data delivery, not the project goal. The choice depends on catalog volume, acceptable latency, product versions, 1C configuration capabilities, and reliability requirements.

The technical specification should document constraints: how many products and variants are transferred, how frequently stock levels must update, whether full updates are allowed, if there are multiple websites or databases, which ports and addresses are available, and whether encryption and IP restrictions are required.

For frequent exchange of small changes, incremental transfer is essential. For large exports, split into parts and resume after a failure. If these requirements are not specified, a scheme working on a test catalog may not withstand production volume.

Integration runs for a long time, so rare failures are inevitable. The question is not whether an error will occur, but whether it will be noticed and whether the exchange can continue without duplicates.

The technical specification must include answers to:

The message "exchange completed" is insufficient. A useful log shows the time, direction, count of read, created, updated, and rejected objects, as well as a clear reason for rejection.

The formulation "data synchronizes correctly" is untestable. Replace it with specific scenarios. For example: a stock change in 1C appears on the site no later than ten minutes later; re-uploading the same package does not create a second product; a paid order is transferred to 1C only once; an unknown property value goes into the log and does not stop other items.

Acceptance testing requires a set of control products and orders: a simple product, a variant product, zero stock, multiple prices, a discount, cancellation, partial shipment, and a return. The expected result is fixed before the test, not explained after it.

A practical assignment can be assembled from nine sections:

Such a document does not replace an audit, but shifts the discussion from the abstract concept of 'connecting two systems' to a set of verifiable solutions. This helps evaluate the project more accurately and, most importantly, prevents discovering business rules only after launch.