Техническое задание на интеграцию сайта с 1С: поля, направления обмена и приёмка

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

Зачем бизнесу отдельное ТЗ на обмен сайта с 1С

Обмен между сайтом и учётной системой — это не одна кнопка, а набор договорённостей. Кто-то должен решить, что считается источником истины для цены, остатка и названия товара. Если эти решения не записаны, каждый участник проекта трактует их по-своему: контент-менеджер правит описание на сайте, бухгалтер меняет цену в 1С, и после ближайшей выгрузки правки на сайте исчезают.

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

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

Отдельная причина писать ТЗ — оценка. Исполнитель считает объём по составу сущностей, числу полей, количеству развилок и требованиям к обработке ошибок. Чем конкретнее описан обмен, тем меньше запас «на неизвестность» в оценке и тем меньше вероятность, что часть работ всплывёт уже в процессе.

Границы проекта: что входит в обмен, а что нет

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

За границами часто остаются: маркетинговые описания и фотографии, которые готовит контент-менеджер на сайте; контент блога и статей; персональные данные покупателей, если они не нужны в учётной системе. Эти блоки лучше явно перечислить как «не входит», чтобы не спорить о них на этапе приёмки.

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

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

Карта полей и владельцев: кто источник истины

Карта полей — обязательный артефакт ТЗ. Это таблица, где для каждого значимого поля указано: направление передачи, владелец (кто может менять), что происходит при конфликте и как часто данные обновляются.

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

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

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

Как оформить карту полей

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

Что делать с полями без владельца

Если поле никто не готов взять, это сигнал: либо оно не нужно в обмене, либо решение ещё не принято. Оставлять его «на потом» рискованно — именно такие поля чаще всего вызывают споры при приёмке.

Направления обмена и что поддерживается штатно

Направление обмена — один из первых пунктов, который нужно проверить до написания требований. В типовых конфигурациях 1С-Битрикс (например, Битрикс24 и стандартные решения на базе 1С) инициация обмена часто происходит со стороны 1С, каталог выгружается из 1С на сайт, а обратная выгрузка каталога с сайта в 1С штатно не предусмотрена. Обмен заказами возможен, но учёт ведётся только по заказам, сделанным на сайте.

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

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

Подробнее о типовых сценариях и настройке читайте в материале про Интеграция Битрикс с 1С: как настроить обмен товарами и заказами.

Частота и формат обмена

Опишите, как часто запускается обмен и по какому событию: по расписанию, вручную или после изменения данных. Укажите, что происходит, если предыдущий обмен не завершился. Формат передачи данных тоже стоит зафиксировать, но без привязки к конкретным версиям и настройкам серверов — это зона исполнителя.

Как описать товары, цены и торговые предложения

Каталог — самая объёмная часть обмена. Здесь важно не ограничиваться фразой «выгружать товары», а описать структуру.

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

Торговые предложения. Если у товара есть варианты — размер, цвет, комплектация — и цена или остаток зависят от варианта, это торговые предложения. В ТЗ нужно указать, какие характеристики образуют вариант, как формируется его идентификатор и что происходит, когда вариант пропадает из выгрузки.

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

Остатки и резервирование. Решите, ведётся ли учёт остатков, показывается ли остаток покупателю, что происходит при нулевом остатке — товар скрывается, помечается «нет в наличии» или остаётся доступным для заказа. Отдельно опишите, резервируется ли товар при оформлении заказа и как резерв снимается.

Изображения и файлы. Укажите, откуда берутся изображения, сколько их на товар, что делать с изображениями, которых нет в выгрузке. Частая развилка: удалять ли картинку на сайте, если в 1С её убрали, или оставлять.

Скидки и правила корзины

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

Заказы, статусы и обратная передача

Заказы — вторая по важности часть. Здесь ТЗ должно отвечать на вопросы: какой заказ попадает в 1С, в каком виде, что происходит при повторной передаче и как меняется статус.

Состав заказа. Перечислите поля: номер, дата, покупатель, состав с товарами и количествами, суммы, скидки, доставка, оплата. Укажите, передаются ли персональные данные и в каком объёме — это граница, которую стоит согласовать с профильным специалистом по защите данных.

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

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

Оплата и отгрузка. Если оплата фиксируется на сайте, а отгрузка в 1С, укажите, как эти события связываются и какой статус видит покупатель.

Что делать с заказами, оформленными не на сайте

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

Ошибки, ответственность и критерии приёмки

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

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

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

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

План возврата

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

Таблица принятия решения: как выбрать схему обмена

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

Таблица не заменяет решение, но помогает увидеть цену выбора. Чем больше направлений обмена, тем больше полей нужно описать и тем выше требования к обработке конфликтов.

Учебный пример: ТЗ для условного магазина

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Условная компания продаёт инструмент через сайт и ведёт учёт в 1С. В каталоге около 4000 товаров, часть с вариантами по размеру. Есть два типа цен: розничная и оптовая. Заказы оформляются на сайте, отгрузка фиксируется в 1С. Обмен запускается по расписанию.

Что зафиксировали в ТЗ. Источник истины по названию, цене и остатку — 1С. Описание и изображения товара ведёт контент-менеджер на сайте, обмен их не перезаписывает. Торговые предложения формируются по характеристике «размер». Если вариант пропал из выгрузки, он скрывается на сайте, но не удаляется, чтобы сохранить историю заказов. При нулевом остатке товар остаётся на сайте с пометкой «нет в наличии». Заказ передаётся в 1С один раз; повторная передача обновляет существующий заказ по внешнему идентификатору. Статусы: «новый» на сайте — «к обработке» в 1С, «отгружен» в 1С — «выполнен» на сайте.

Действия при проверке. Команда подготовила тестовый набор: несколько товаров с вариантами, товар с нулевым остатком, товар без изображения, заказ с двумя позициями и заказ с оптовой ценой. Прогнали обмен, сверили каталог, цены и остатки, оформили тестовые заказы и проверили их появление в 1С.

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

Что показал пример. Основные спорные места — не сам обмен, а правила поведения при неполных данных и при повторной передаче. Их описание в ТЗ сэкономило время на приёмке и убрало часть вопросов «а как должно быть».

Как проверить результат и принять работу

Приёмка опирается на критерии из ТЗ и на тестовый набор данных. Ниже — чек-лист, который можно использовать как основу.

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

Если какой-то пункт не проходит, это не повод принимать работу «с замечаниями». Лучше вернуть на доработку и повторить проверку на том же наборе.

Типичные ошибки и ограничения

Ошибка первая — описывать обмен общими словами. Формулировка «синхронизировать товары и заказы» не даёт исполнителю ничего проверить. Используйте конкретные глаголы: «выгрузить», «создать», «обновить».

Ошибка вторая — не назначать владельца поля. Тогда при конфликте правок никто не знает, чья версия правильная.

Ошибка третья — забыть про удаление и скрытие. Что делать с товаром, который исчез из 1С: удалить, скрыть, оставить? Ответ нужен в ТЗ.

Ошибка четвёртая — не описать повторную передачу. Без правила по внешнему идентификатору легко получить дубли заказов.

Ошибка пятая — рассчитывать на двусторонний обмен каталогом без отдельного требования. Штатные сценарии стоит сверить с документацией, а не предполагать.

Ограничения. Обмен зависит от качества данных в 1С: дубли артикулов, пустые обязательные поля, разные единицы измерения ломают выгрузку. Частота обмена влияет на актуальность цен и остатков. Персональные данные покупателей — отдельная граница, которую нужно согласовать с профильным специалистом. Если обмен уже работает и даёт сбои, полезно сначала разобрать причины, а не переписывать ТЗ целиком: часть проблем описана в материале про то, что делать, если обмен с 1С сломался.

Какие исходные данные подготовить для оценки

Чтобы исполнитель мог оценить работу, а не угадывать, соберите пакет исходных данных.

Список того, что нужно подготовить: перечень сущностей для обмена; карта полей с владельцами; примеры выгрузок из 1С; описание типов цен и правил скидок; описание статусов заказов; схема систем и посредников; требования к частоте обмена; тестовый стенд или его описание; ограничения по персональным данным.

Чем конкретнее примеры данных, тем точнее оценка. Если каких-то данных нет, это тоже фиксируется: неопределённость — часть объёма работ. Полезно заранее посмотреть, как устроен типовой обмен сайта на Битрикс с 1С, чтобы понимать базовые сценарии и не описывать их заново.

FAQ