Что именно обменивается
Интеграция магазина с учётной системой — это не один поток, а несколько, и у каждого свои правила. Если их смешать в одном описании, проект буксует: разработчик делает обмен «вообще», а на приёмке выясняется, что остатки обновляются с задержкой, которой никто не ожидал.
| Поток | Направление | Что важно определить |
|---|---|---|
| Номенклатура и структура каталога | Из 1С на сайт | Что считается товаром, как строятся разделы и свойства |
| Цены | Из 1С на сайт | Какая цена главная, что делать с акциями и скидками |
| Остатки | Из 1С на сайт | Частота обмена, учёт складов, резервы |
| Заказы | С сайта в 1С | Момент создания документа, состав данных, статусы |
| Статусы и оплаты | Из 1С на сайт | Кто меняет статус и как клиент об этом узнаёт |
Разделение на потоки полезно и технически: у них разная частота, разный объём и разные последствия сбоя. Потеря обновления цены — неприятно, потеря заказа — критично.
Номенклатура: как из учёта получается каталог
В учётной системе товар описан так, как удобно бухгалтерии и складу. На сайте нужна другая структура: разделы, фильтры, карточки с фотографиями и понятными характеристиками. Между этими представлениями всегда есть разрыв, и его нужно описать до разработки.
- Что является единицей каталога: позиция номенклатуры, товар с вариантами или торговое предложение
- Как строятся разделы: из групп в 1С, из отдельного справочника или вручную на сайте
- Какие свойства попадают в фильтры, а какие остаются только в карточке
- Что делать с позициями без фото и описания: скрывать, показывать, помечать
- Как обрабатываются архивные и снятые с производства позиции
- Кто отвечает за контент карточек: магазин, контент-менеджер или поставщик
Практический совет: начинайте с 20–30 реальных позиций и прогоните их через правила вручную. Это быстрее, чем обнаружить, что половина каталога не имеет характеристик, уже после запуска обмена.
Цены и остатки: самое частое место сбоев
Цены и остатки обновляются часто и меняются без предупреждения. Именно здесь чаще всего возникают расхождения между сайтом и учётом, и именно они вызывают самые неприятные звонки: клиент оформил заказ на товар, которого нет.
- Определите главную цену и правило округления: скидки, наценки, несколько типов цен
- Решите, учитывать ли несколько складов и как показывать остаток: точное число, «в наличии», «под заказ»
- Продумайте резервы: остаётся ли товар доступным, пока заказ не подтверждён в 1С
- Задайте период актуальности: если обмен не прошёл два часа, стоит ли скрывать остатки
- Опишите поведение при нулевом остатке: скрыть, показать «нет в наличии», разрешить предзаказ
Отдельный вопрос — частота. Обмен «раз в сутки» подходит для медленно меняющегося ассортимента, но плохо работает для товаров с быстрым движением. Иногда разумнее обновлять остатки часто и небольшими порциями, а полную выгрузку каталога делать реже.
Проверка на здравый смысл: если обмен остатков остановится на сутки, что увидит клиент? Ответ на этот вопрос определяет требования к мониторингу и резервному сценарию.
Заказы: от корзины до документа
Заказ с сайта должен превратиться в документ учётной системы, а его статус — вернуться на сайт и, желательно, уйти клиенту уведомлением. В этой цепочке важны две вещи: момент создания документа и правило повторной отправки.
- Заказ создаётся сразу при оформлении или после подтверждения менеджером
- Что делать, если 1С недоступна: сохранить заказ на сайте, поставить в очередь, уведомить сотрудника
- Как избежать дублей: уникальный идентификатор заказа и идемпотентная отправка
- Кто и как меняет статус: оплачен, собран, отправлен, отменён
- Как статус отображается клиенту и нужно ли уведомление
- Что происходит с заказом, если товар закончился после оформления
Дубли заказов — типичная проблема первых версий обмена: пользователь нажал кнопку дважды, сеть повторила запрос, и в 1С появились два одинаковых документа. Решается это не уговорами быть аккуратнее, а идентификатором заказа и проверкой на стороне приёмника.
Контент и изображения
Обмен обычно передаёт данные, но не создаёт качественный контент. Фотографии, описания и характеристики — отдельная работа, и её стоит планировать заранее: карточка без фото продаёт хуже, даже если цена и остаток идеальны.
- Кто готовит фотографии и в каком формате они попадают на сайт
- Есть ли требования к размеру и пропорциям, чтобы карточки выглядели одинаково
- Как обрабатываются описания: переносятся из 1С, пишутся отдельно или генерируются
- Что делать с позициями, у которых нет описания: временный шаблон или скрытие
- Кто отвечает за актуальность характеристик после изменения модели
Практика показывает: обмен и контент лучше разводить по срокам. Сначала настраивается передача данных на ограниченном наборе товаров, затем подключается остальной каталог вместе с контентом.
Кто участвует в проекте
Интеграция с учётной системой почти никогда не делается силами одной команды. Чтобы обмен заработал и не развалился через месяц, нужны три стороны, и у каждой своя зона ответственности.
- Разработчик магазина. Приём и обработка данных, карточки, корзина, оформление заказа, отображение статусов
- Специалист по 1С. Настройка выгрузки, правила формирования цен и остатков, создание документов из заказов
- Контент-менеджер. Фотографии, описания, характеристики, разделы и фильтры
- Владелец процесса. Решает спорные вопросы: какая цена главная, что делать с резервами, кто отвечает за расхождения
Самая частая причина затянутых проектов — отсутствие четвёртой роли. Технические вопросы решаются быстро, а организационные («почему в 1С цена одна, а на сайте другая») зависают на недели, потому что решения нет ни у разработчика, ни у 1С-специалиста.
Полезно сразу договориться о тестовом контуре: отдельная копия базы и тестовый сайт. Проверять обмен на рабочих данных рискованно — ошибка в правилах создаёт лишние документы, которые потом разбирать вручную.
Что ломается чаще всего
- Расхождение ключей: одну и ту же позицию в учёте пересоздали, и на сайте появился дубль
- Остановка обмена без уведомления: цены и остатки «замерли» на прошлой неделе
- Права доступа: обмен работает под учётной записью сотрудника, который уволился
- Тайм-ауты на больших выгрузках: каталог обрывается на середине
- Кодировки и специальные символы в названиях: часть позиций приходит с «кракозябрами»
- Статусы, которые меняются в 1С, но не доходят до сайта, и клиент видит устаревшее состояние
Для диагностики нужен журнал обмена: когда запускался, сколько записей обработано, какие ошибки возникли. Без журнала разбор сводится к догадкам, а проблема повторяется.
Дополнительные каналы: маркетплейсы и не только
Часто после запуска обмена возникает задача выгрузить тот же каталог на маркетплейсы или в прайс-агрегаторы. Это отдельные потоки со своими требованиями к формату, категориям и остаткам.
- Категории маркетплейса не совпадают с разделами сайта: нужна таблица соответствия
- Требования к карточке жёстче: обязательные характеристики, фото, единицы измерения
- Остатки и цены могут отличаться от сайтовых из-за комиссии и правил площадки
- Заказы с маркетплейсов приходят в своих статусах и требуют отдельной обработки
Практический порядок: сначала стабилизировать обмен с собственной учётной системой, потом добавлять каналы по одному. Если запускать всё сразу, ошибки будет невозможно локализовать — непонятно, какой именно поток дал расхождение.
Как принимать работу по обмену
Приёмка интеграции — это набор воспроизводимых проверок, а не демонстрация «смотрите, всё работает». Ниже минимальный список, который стоит прогнать вместе с подрядчиком.
- Новая позиция в 1С появляется на сайте с корректными разделами и свойствами
- Изменение цены и остатка доходит до сайта за оговорённое время
- Позиция, снятая с продажи, перестаёт быть доступной для заказа
- Заказ с сайта создаёт документ в 1С без дублей при повторной отправке
- Изменение статуса в 1С отражается на сайте и в уведомлении клиенту
- При недоступности 1С заказ не теряется и попадает в очередь
- Журнал обмена доступен и содержит ошибки с понятным описанием
- Доступы к обмену оформлены на рабочую учётную запись, а не на сотрудника
Эти же проверки полезно оформить как регламент: тогда при смене подрядчика или обновлении конфигурации понятно, что именно проверять.
Сроки и стоимость
Стоимость обмена определяется числом потоков и правил, а не «версией 1С». Простой обмен каталогом и остатками — один объём; двусторонний обмен с заказами, статусами, резервами и несколькими складами — совсем другой.
В 7АРТ интернет-магазин с каталогом, корзиной, оформлением заказа, оплатой и обменом с 1С стартует от 59 990 ₽; итоговый состав и сроки фиксируются в договоре. Подробности — на странице интернет-магазин.
И отдельно: обмен редко бывает «сделан один раз». Конфигурация обновляется, появляются новые склады и типы цен, меняются правила. Поэтому в бюджете стоит предусмотреть сопровождение, а не только запуск.
Когда обмен не нужен
Если ассортимент небольшой и меняется редко, ручная выгрузка раз в неделю может оказаться дешевле интеграции. Обмен оправдан, когда позиций много, цены и остатки меняются часто, а заказы нужно вести в учёте без двойного ввода.
Промежуточный вариант — обмен только в одну сторону: каталог и цены из 1С, заказы приходят на почту или в CRM. Это дешевле и часто достаточно на старте, если объём заказов небольшой.
Если вы уже понимаете, какие потоки нужны, обсудить их можно через форму обсуждения проекта. Общая логика подготовки к интеграции — в статье интеграция сайта с CRM и 1С.