Связать 1С с сайтом можно пятью способами: типовым обменом в формате CommerceML, HTTP-сервисами в расширении конфигурации, стандартным интерфейсом OData, файловой выгрузкой по расписанию и планами обмена. Настройка типового обмена на живой конфигурации стоит 40 000–120 000 ₽ и занимает от трёх рабочих дней; полноценный двусторонний обмен с заказами, статусами и оплатами на HTTP-сервисах — 260 000–520 000 ₽ и 4–7 недель. Всё, что дешевле нижней границы, — либо готовый модуль без настройки под ваш справочник, либо обещание, которое закончится счётом на доработку.
Дальше — механика каждого способа, а не рекламные формулировки. Что именно он умеет возить, с какой задержкой, что происходит при обрыве связи, кто должен писать код, переживёт ли решение очередное обновление конфигурации и во что обходится год эксплуатации. Отдельно разобраны пять ошибок, из-за которых обмен ломается не на запуске, а на втором месяце, и способы поймать каждую до того, как о ней сообщит клиент.
Материал написан для владельца или коммерческого директора, которому предстоит выбрать подрядчика и подписать смету. Разбираться в устройстве HTTP-сервиса не обязательно — обязательно понимать, за что вы платите и какие вопросы задать, чтобы отличить инженерное предложение от «настроим за день». К концу текста эти вопросы собраны в чек-лист приёмки.
Пять способов обмена и чем они на самом деле отличаются
Порядок в списке — не рейтинг. Это разные инструменты под разные объёмы, и правильный выбор зависит от трёх вещей: сколько позиций в каталоге, какая допустима задержка между изменением в учёте и изменением на витрине, и сколько направлений обмена нужно на самом деле. Каталог на 800 позиций с ежедневным обновлением цен и каталог на 60 000 позиций с посекундными остатками — это два разных проекта, и одинаковый способ обмена в них не годится.
- 1Типовой обмен CommerceML
Штатная подсистема «Обмен с сайтом», которая есть в 1С:УНФ, УТ, КА, ERP и Рознице. Регламентное задание формирует XML в формате CommerceML: отдельно карточки товаров с картинками и свойствами, отдельно предложения — цены, остатки, характеристики. 1С сама обращается к скрипту обмена на стороне сайта, авторизуется и передаёт данные порциями; встречное направление — выгрузка заказов с сайта в учёт. Формат понимают 1С-Битрикс, InSales, UMI.CMS, Shop-Script, и почти для любой другой CMS есть модуль-приёмник. Плюс: подсистема типовая, её поддерживает вендор, программист на старте не нужен. Минус: формат жёсткий, за его границы (сложные характеристики, свои статусы, частичные остатки по складам) выйти нельзя без доработки.
- 2HTTP-сервисы в расширении конфигурации
Собственный набор методов: «отдай остатки по этим 40 артикулам», «создай заказ», «верни статус». Пишутся 1С-программистом и выносятся в расширение — отдельный файл, который живёт рядом с типовой конфигурацией и не требует снимать её с поддержки. Один метод — 4–8 часов работы. Плюсы: возится ровно то, что нужно, задержка от секунды, нагрузка на базу минимальная. Минусы: нужна публикация базы на веб-сервере и внешний доступ к ней (обычно через реверс-прокси или VPN), нужен живой 1С-специалист и нужна дисциплина версионирования — метод, который поменяли не предупредив, роняет сайт.
- 3Стандартный интерфейс OData
Включается галочкой при публикации базы и открывает справочники и документы как объекты по адресу. Внешний разработчик читает и пишет их без единой строки кода в 1С — этим OData и соблазняет на старте. Ограничения появляются на объёме: у большинства объектов нет отметки времени изменения, поэтому «забрать только новое» невозможно, приходится вычитывать выборку целиком, а постраничный обход тяжёлых справочников нагружает рабочую базу так, что операционисты начинают жаловаться на скорость. Проведение документов через OData тоже устроено не как бизнес-операция, а как установка флага, и на этом ломаются взаиморасчёты. Разумный сценарий: справочники и небольшие объёмы, на чтение, вне часов пиковой нагрузки.
- 4Файловый обмен по расписанию
Регламентное задание выкладывает срез данных — прайс, остатки, реестр заказов — в каталог, на FTP или в объектное хранилище, сайт забирает файл и разбирает. Формат ваш собственный, обычно CSV или JSON. Способ выглядит архаично, но у него самая высокая устойчивость: файл лежит, пока его не забрали, и никакой обрыв связи данные не теряет. Публиковать базу наружу не нужно, риск для учёта нулевой. Расплата — задержка в один цикл выгрузки и то, что обратное направление приходится делать вторым, отдельным каналом.
- 5Планы обмена
Платформенный механизм: при изменении объекта система регистрирует это изменение для каждого узла обмена и держит регистрацию, пока узел не подтвердит приём номером сообщения. Отсюда два свойства, которых нет ни у одного другого способа: возится только изменившееся, и разрыв связи не теряет ничего — после восстановления догоняется вся очередь. Это механизм, на котором работают штатные обмены между конфигурациями 1С. Минус один и весомый: разработка дороже втрое, потому что помимо самого узла пишутся правила конвертации данных. Для витрины на 2 000 позиций это перебор; для каталога на 60 000 позиций и трёх складов — единственный способ не задохнуться на полных выгрузках.
| Способ | Задержка | Что при обрыве связи | После обновления конфигурации | Срок | Цена |
|---|---|---|---|---|---|
| Типовой обмен CommerceML | 15 минут — сутки | Сессия рвётся по таймауту, порция теряется до следующего запуска | Переживает: подсистема типовая, её обновляет вендор | 3–10 рабочих дней | 40 000–120 000 ₽ |
| HTTP-сервисы в расширении | 1–30 секунд | Запрос теряется, если на стороне сайта нет очереди повторов | Переживает, если код в расширении; ломается, если врезан в типовую | 2–5 недель | 150 000–400 000 ₽ |
| OData | Секунды на объект, минуты на выборку | Ничего не гарантирует: нет ни очереди, ни подтверждения приёма | Ломается на переименовании реквизитов, о котором вас не предупредят | 1–2 недели | 80 000–200 000 ₽ |
| Файловый обмен по расписанию | Период выгрузки, обычно 15 минут — сутки | Ничего не теряется: файл лежит, пока его не забрали | Практически не ломается: формат ваш, а не вендорский | 1–3 недели | 60 000–150 000 ₽ |
| Планы обмена | От 1 минуты | Изменение остаётся зарегистрированным до подтверждения приёма | Переживает: механизм платформенный, живёт независимо от релизов | 4–8 недель | 250 000–600 000 ₽ |
Колонка про обрыв связи — та, которую в коммерческих предложениях не пишут вообще, а она определяет, сколько раз в год вам придётся разбираться с расхождениями вручную. Обрыв — это не экзотика: перезагрузка сервера сайта, плановые работы у хостинга, забитый канал в час пиковой выгрузки. На CommerceML это выглядит как «половина цен обновилась, половина нет»; на OData — как тихая потеря куска данных без всякого следа в журнале; на файловом обмене и планах обмена — никак, потому что данные дождутся следующей попытки.
Схема: слева блок «1С (УТ, УНФ, КА, ERP, Розница)», справа блок «Сайт / CMS». Между ними пять горизонтальных каналов сверху вниз: «Типовой обмен CommerceML — 15 мин–сутки — 40 000–120 000 ₽», «HTTP-сервисы в расширении — 1–30 сек — 150 000–400 000 ₽», «OData — секунды на объект — 80 000–200 000 ₽», «Файловый обмен по расписанию — период выгрузки — 60 000–150 000 ₽», «Планы обмена — от 1 минуты — 250 000–600 000 ₽». У каждого канала маленькая пометка справа: «теряет порцию», «нужна очередь повторов», «теряет молча», «не теряет», «не теряет». Чертёжная манера, только русские подписи.
Albato, ApiX-Drive и n8n на собственном сервере в РФ решают задачу маршрутизации и преобразования данных, но с 1С они всё равно разговаривают одним из пяти способов выше — чаще всего через HTTP-сервис или OData. Платформа экономит на разработке связок между сайтом, CRM и телефонией, а не на подключении к учёту. Zapier и Make для российской компании из этого списка выпадают: доступа из РФ у них нет.
Что именно возят между 1С и сайтом
Фраза «настроить обмен с сайтом» ничего не означает, пока не названы направления. Их шесть, каждое имеет свою частоту, свою цену и свои условия приёмки, и каждое можно включить или не включать. Именно на этом месте расходятся смета на 90 000 ₽ и смета на 450 000 ₽ — не в качестве работы, а в том, что в первой оплачено одно направление из шести.
| Направление | Куда идёт | Разумная частота | Что ломается, если сделать плохо | Доля в смете |
|---|---|---|---|---|
| Номенклатура и характеристики | 1С → сайт | Раз в сутки или по изменению | Дубли карточек, потеря размеров и цветов | 20–30% |
| Цены и виды цен | 1С → сайт | 1–4 раза в сутки | Продажа по старой цене, цена без НДС на витрине | 10–15% |
| Остатки по складам | 1С → сайт | Каждые 10–60 минут | Заказ на товар, которого нет; отмены и возвраты | 15–25% |
| Заказы покупателей | Сайт → 1С | Мгновенно, по событию | Потерянные и задвоенные заказы | 20–30% |
| Статусы и отгрузки | 1С → сайт → клиент | По изменению статуса | Клиент звонит спрашивать, где заказ | 10–15% |
| Оплаты и возвраты | Сайт ↔ 1С | По событию платежа | Расхождения в кассе и взаиморасчётах | 10–20% |
Правило, которое стоит запомнить до разговора с подрядчиком: направления «из учёта на сайт» дешевле направлений «с сайта в учёт» примерно вдвое. В первом случае мы читаем факт и показываем его; ошибка стоит неверной цифры на витрине. Во втором мы создаём в боевом учёте документ, который дальше пойдёт в отгрузку, в кассу и в отчётность; ошибка стоит расхождения в закрытом периоде. Поэтому запись всегда идёт через официальный интерфейс — HTTP-сервис или типовой механизм обмена — и никогда напрямую в таблицы базы. Прямая запись мимо механизма проведения ломает регистры накопления, обнаруживается через месяц при закрытии и откатом не чинится.
Карта связей: три узла — «1С (учёт)» слева, «Сайт» в центре, «Покупатель» справа. Стрелки с подписями: от 1С к сайту — «номенклатура и характеристики, раз в сутки», «цены, 1–4 раза в сутки», «остатки, каждые 10–60 минут»; от сайта к 1С — «заказы, мгновенно», «оплаты, по событию платежа»; от 1С через сайт к покупателю — «статусы и отгрузки, по изменению». Рядом с каждой стрелкой мелкая подпись доли в смете: 20–30%, 10–15%, 15–25%, 20–30%, 10–20%, 10–15%. Чертёжная манера, русские подписи.
Конфигурация решает больше, чем CMS
Первый вопрос обследования — не «какой у вас сайт», а «какая конфигурация 1С и в какой редакции». Ответ определяет, что вообще возможно возить, и в половине случаев меняет саму постановку задачи. Разница между конфигурациями не косметическая: у одних есть заказ клиента как документ и характеристики номенклатуры, у других этих объектов нет физически, и никакой обмен их не придумает.
| Конфигурация | Есть ли товарный контур для витрины | Типовой обмен с сайтом | Что учесть |
|---|---|---|---|
| 1С:Бухгалтерия предприятия 3.0 | Нет: ни характеристик, ни заказа клиента, ни видов цен в нужном разрезе | Не предусмотрен | Сайт на неё не сажают. Ставится УНФ или УТ, Бухгалтерия остаётся регламентированным учётом и получает данные обменом |
| 1С:Управление нашей фирмой (УНФ) | Да: номенклатура с характеристиками, заказы, цены, простой склад | Есть, штатный обмен CommerceML | Оптимальна для магазина до 10 000 позиций и одного-двух складов |
| 1С:Управление торговлей 11 (УТ) | Да, полный: виды цен, характеристики, резервы, статусы заказов | Есть, штатный обмен CommerceML | Основной вариант для интернет-магазина с несколькими складами. Резервы обязательно учитывать в остатке для витрины |
| 1С:Комплексная автоматизация (КА), 1С:ERP | Да, плюс производство и заказы поставщикам | Есть, но объектов больше и обследование длиннее | Срок проекта растёт на 1–3 недели за счёт согласования того, чей остаток считать доступным |
| 1С:Розница | Да, но в логике магазинов и касс, а не склада | Есть, ограниченный | Часто правильнее схема «Розница — УТ — сайт»: центральный узел сводит остатки магазинов |
| 1С:Документооборот | Нет, это не товарная система | Не применимо | Подключается отдельно — для согласований и договоров, а не для витрины |
Отдельная строка — доработанная конфигурация. Если в вашей УТ пять лет жили сторонние доработки и её сняли с поддержки, обследование дорожает на 20–40%: прежде чем писать обмен, нужно понять, что там переопределено в проведении документов и в расчёте остатка. Это не повод менять систему — мы разбирали, почему автоматизация почти никогда не требует замены учётной системы, — но повод заложить в смету строку «разбор доработок» отдельно, а не узнать о ней в середине проекта.
Таблица сравнения из двух колонок и шести строк-объектов. Колонки: «1С:Бухгалтерия 3.0» и «1С:УНФ / УТ 11 / КА / ERP». Строки с отметками «есть»/«нет»: «Характеристики номенклатуры», «Виды цен в разрезе для витрины», «Заказ клиента как документ», «Резервы под заказ», «Остатки по нескольким складам», «Штатный обмен CommerceML». В колонке Бухгалтерии почти всё «нет», в правой почти всё «есть». Внизу подпись: «Розница — свой контур: остатки по магазинам и кассам». Чертёжная манера, русские подписи.
Количество, которое можно продать прямо сейчас: физический остаток минус резервы под уже принятые заказы, минус товар в отгрузке, минус страховой буфер. Витрина должна получать именно его, а не физический остаток из отчёта по складу. Разница между этими двумя числами — главный источник отменённых заказов после запуска обмена.
Односторонний обмен против двустороннего
Односторонний обмен — это выгрузка каталога, цен и остатков из учёта на сайт. Двусторонний добавляет обратное движение: заказы, оплаты и статусы. Второй стоит примерно втрое дороже первого, и разница не в объёме кода, а в том, что появляется ответственность за запись в боевую базу. Односторонняя выгрузка в худшем случае показывает неверную цену; двусторонний обмен в худшем случае создаёт документ, который уйдёт в отгрузку и в отчётность.
- Идемпотентность. Сайт отправил заказ, ответа не дождался из-за таймаута и отправил повторно — в учёте не должно появиться два документа. Достигается внешним идентификатором заказа и проверкой на стороне 1С: 6–10 часов работы, которые почти всегда забывают в дешёвых сметах.
- Очередь и повторы. Заказ, не доставленный с первого раза, встаёт в очередь и повторяется по нарастающему интервалу, а не теряется. Плюс 8–16 часов на стороне сайта или интеграционного контура.
- Соответствие справочников в обе стороны. Товар с сайта должен опознаться в 1С по устойчивому ключу, а не по наименованию; контрагент-физлицо — создаться по правилу, а не плодить дубли.
- Разграничение прав. Отдельный пользователь интеграции с ограниченной ролью: тогда всё, что сделал обмен, видно в журнале регистрации под его именем и отделимо от действий людей.
- Правило закрытого периода. Если событие с сайта касается уже закрытого месяца, обмен не переписывает историю, а готовит документ-корректировку и оставляет его человеку на проведение.
Практический вывод: начинать почти всегда стоит с односторонней выгрузки и включать обратное направление вторым этапом, через 3–4 недели работы. За это время видно, сходятся ли цифры на витрине с отчётами, и цена ошибки в этот период — неверная строка в каталоге, а не испорченный документ в учёте. Обратный порядок — сразу двусторонний обмен «под ключ» — экономит две недели календаря и стоит потом трёх недель разбора расхождений.
Две колонки сравнения. Левая «Односторонний обмен: 1С → сайт»: строки «Направления: номенклатура, цены, остатки», «Цена: 90 000–180 000 ₽», «Срок: 1–3 недели», «Цена ошибки: неверная цифра на витрине», «Что нужно дополнительно: ничего». Правая «Двусторонний обмен: 1С ↔ сайт»: «Направления: плюс заказы, оплаты, статусы», «Цена: 260 000–520 000 ₽», «Срок: 4–7 недель», «Цена ошибки: испорченный документ в учёте», «Что нужно дополнительно: идемпотентность, очередь повторов, права, правило закрытого периода». Чертёжная манера, русские подписи.
Модельный расчёт: 5 000 позиций и 400 заказов в месяц
Вводные модельного примера: интернет-магазин на 1С:УТ 11, каталог 5 000 активных позиций, 400 заказов в месяц, средний чек 6 000 ₽, валовая маржа 25% — то есть 1 500 ₽ с заказа. Сейчас менеджер выгружает прайс и остатки в Excel и заливает на сайт раз в неделю, а заказы переносит в 1С руками. Стоимость часа сотрудника с налогами — 700 ₽. Цифры модельные: подставьте свои, арифметика останется той же.
Самая крупная строка здесь — не зарплата, а отмены. При выгрузке остатков раз в неделю витрина почти всё время показывает вчерашнюю правду, и часть заказов приходит на позиции, которых уже нет. Семь процентов — модельная оценка для каталога с быстрой оборачиваемостью; 1 900 ₽ в строке складываются из потерянной маржи 1 500 ₽ и примерно 400 ₽ рабочего времени на звонок, извинение и оформление возврата. Если у вас товар оборачивается медленно и на складе лежат месячные запасы, эта строка будет втрое меньше — и вся экономика проекта поменяется, поэтому считать надо на своих числах, а не на средних по рынку.
Двухосевой график на 12 месяцев. Сплошная линия — накопленный чистый эффект по 52 800 ₽ в месяц, горизонтальная штриховая — разовое вложение 350 000 ₽. Точка пересечения на седьмом месяце подписана «окупаемость». Оси: месяцы (1–12) и рубли (0–650 000). Под графиком подпись: «модель: 5 000 SKU, 400 заказов в месяц, средний чек 6 000 ₽».
Пять ошибок, из-за которых обмен ломается на втором месяце
Обмен почти никогда не падает на запуске: на запуске за ним смотрят. Он ломается через три-шесть недель, когда все расслабились, и обнаруживается по звонку клиента или по странной цифре в отчёте. Ниже — пять поломок, которые встречаются чаще остальных, с признаком, по которому каждая ловится автоматически.
- 1Дубли номенклатуры
Причина одна: товар опознаётся по наименованию или артикулу, а не по неизменяемому идентификатору. Менеджер поправил название — обмен решил, что это новый товар, и создал вторую карточку. Через месяц в каталоге 5 300 позиций вместо 5 000, у половины дублей нулевой остаток, и покупатель попадает именно на них. Ловится счётчиком: если за одну сессию обмена создано больше 1% новых карточек от объёма каталога, приходит алерт. Чинится переходом на идентификатор из 1С в качестве внешнего ключа — и это надо делать до первой боевой выгрузки, а не после.
- 2Пересорт характеристик
В CommerceML товар и его характеристика — разные сущности: карточка отдельно, предложения с размерами и цветами отдельно. Если характеристики не выгружаются или связываются по неустойчивому ключу, остаток размера 42 попадает на всю карточку целиком. Внешне сайт выглядит нормально, а на складе при сборке выясняется, что 42-го давно нет. Ловится сверкой: сумма остатков по характеристикам на сайте должна совпадать с суммой по 1С поштучно, а не по карточке в целом.
- 3Разные справочники
У 1С своя иерархия групп, свои единицы измерения, свои виды цен и ставки НДС; у сайта — свои категории и свойства фильтров. Классика жанра: в 1С есть «Розничная» и «Розничная (с НДС)», обмен настроен на первую, и витрина показывает цену без налога. Или единица «упаковка» приезжает как «штука», и клиент заказывает 10 штук вместо 10 упаковок. Лечится только письменным соответствием справочников до начала работ и приёмочным прогоном по 30–50 реальным позициям, где сверяется каждое поле.
- 4Обмен молча отвалился
Самый частый и самый дорогой случай. Регламентное задание отключилось после перезапуска сервера, у пользователя обмена сменили пароль по политике безопасности, кончилось место на диске, протух сертификат. Признак снаружи: витрина показывает данные суточной давности, и никто этого не видит, пока не позвонит клиент. Ловится сигналом присутствия: каждая успешная сессия обмена оставляет отметку времени, а внешний монитор проверяет, что отметка не старше двух периодов. Тишина — тоже событие, и алерт должен приходить именно на неё.
- 5Задвоенные заказы
Сайт отправил заказ, не дождался ответа, повторил — и в учёте два документа с одним содержимым. Дальше их обоих собирают на складе. Причина — отсутствие идемпотентности: приём заказа не проверяет внешний идентификатор. Ловится ежедневным запросом на одинаковые заказы одного контрагента за короткое окно; чинится правильно, только на стороне приёма, а не «менеджер будет смотреть».
Мониторинг обмена, который следит только за ошибками, бесполезен: самая дорогая поломка не выдаёт ошибку, она просто перестаёт присылать данные. Обязательны два правила: алерт на отсутствие успешной сессии дольше двух периодов обмена и алерт на аномальный объём — если выгрузка вернула ноль строк или на 40% меньше обычного, инженер должен узнать об этом раньше покупателя. Настройка обоих — 20 000–40 000 ₽ один раз.
Схема канала обмена «1С → очередь → сайт» с тремя датчиками сверху. Датчик 1 «Отметка времени сессии»: подпись «нет успешной сессии дольше двух периодов — алерт». Датчик 2 «Объём выгрузки»: подпись «ноль строк или на 40% меньше обычного — алерт». Датчик 3 «Счётчик новых карточек»: подпись «создано больше 1% от каталога за сессию — алерт». Справа блок «Инженер» со стрелками от всех трёх датчиков. Чертёжная манера, русские подписи.
Ломает ли обмен обновление конфигурации
Обновление ломает не «интеграцию вообще», а конкретный способ — и по-разному. Типовой обмен CommerceML переживает релизы штатно: подсистему сопровождает вендор, и если вы не влезали в неё руками, обновление её не касается. HTTP-сервисы, вынесенные в расширение, переживают обновление в подавляющем большинстве случаев: расширение — отдельный файл, который не переписывается вместе с типовой конфигурацией. OData ломается тише и обиднее всего: реквизит переименовали, запрос вернул ошибку или пустоту, и вы узнаете об этом по пустому каталогу. Файловый обмен зависит только от вашего собственного формата и потому почти не страдает.
По нашей практике на типовой конфигурации за год случается одно-два обновления, требующих вмешательства в обмен, и каждое — это 2–4 часа работы, а не переделка проекта. Это и есть содержание строки «поддержка» в договоре. Чтобы обновление не превращалось в аварию, нужны четыре вещи, каждая из которых дешевле одного дня простоя витрины.
- Код в расширении, а не в типовой конфигурации: тогда ваша 1С остаётся на поддержке вендора и обновляется штатно.
- Контракт данных: письменный список полей обмена и их смысла. Любое расхождение с ним — событие с известной процедурой, а не сюрприз посреди рабочего дня.
- Тестовый прогон на копии базы перед плановым обновлением: 2–3 часа при условии, что о дате обновления сказали заранее.
- Окно сопровождения после обновления: сутки повышенного внимания к алертам и правка карты полей в тот же день.
Интеграцию ломает не обновление, а отсутствие письменного контракта данных: без него любое изменение в конфигурации — сюрприз.
Чек-лист приёмки: что проверить до оплаты
Обмен принимается не демонстрацией «смотрите, товары появились», а прогоном по списку. Ниже — минимальный набор проверок, который стоит внести в договор как условия приёмки; каждая занимает от пяти минут до получаса, а вместе они закрывают почти все поломки, которые иначе всплывут на втором месяце. Что ещё должно быть зафиксировано на бумаге, мы разбирали в материале о договоре на разработку.
- 1Выгрузка полного каталога прошла дважды подряд, и во второй раз не создано ни одной новой карточки. Если создались — товар опознаётся по неустойчивому ключу, и дубли начнутся через месяц.
- 2Сумма остатков по 30 случайным позициям на сайте совпадает с доступным остатком в 1С поштучно, включая характеристики.
- 3Цена на витрине совпадает с нужным видом цены и содержит НДС в том виде, в каком его видит покупатель.
- 4Заказ, отправленный с сайта дважды подряд с одним идентификатором, создал в 1С один документ, а не два.
- 5Заказ, отправленный при выключенном обмене, доехал после включения — то есть очередь повторов существует и работает.
- 6Изменение статуса в 1С доехало до личного кабинета покупателя за оговорённое время, а не «когда-нибудь ночью».
- 7Обмен работает под отдельным пользователем с ограниченной ролью, и его действия видны в журнале регистрации отдельно от действий людей.
- 8Алерт на остановку обмена приходит инженеру и заказчику: проверяется искусственной остановкой регламентного задания на 40 минут.
- 9Есть письменный контракт данных: список полей, направлений и частот, подписанный обеими сторонами.
- 10Передан доступ к коду обмена и правилам соответствия справочников — вы должны иметь возможность отдать это другому подрядчику.
Три случая, когда интеграцию делать не надо
Обмен — это не только разработка, но и постоянная статья расходов: поддержка, реакция на обновления, разбор расхождений. Если он экономит меньше, чем стоит, честный ответ — не делать его и вернуться к разговору, когда изменится объём. Три ситуации, в которых мы сами отговариваем.
- 1Меньше 30 заказов в месяц
Считаем на тех же ставках: 30 заказов × 3 минуты = 1,5 часа переноса, около 1 050 ₽. Обновление прайса на небольшом каталоге — ещё 2 часа, 1 400 ₽. Пара отменённых заказов из-за неверного остатка — примерно 3 800 ₽. Всего около 6 250 ₽ в месяц против 15 000 ₽ минимальной поддержки обмена. Обмен дороже проблемы, которую решает. Порог, ниже которого мы не рекомендуем начинать, — примерно 120–150 заказов в месяц.
- 2Каталог почти не меняется
Производственная компания с 200 позициями, ценами по прайсу на год и остатками «под заказ» ничего не выиграет от автоматической выгрузки. Здесь работает регламент: выгрузка прайса раз в квартал руками, 40 минут работы. Тратить 150 000 ₽ на то, чтобы четыре раза в год не нажимать кнопку, смысла нет.
- 3Товар делается под заказ
Если позиции на сайте — это не складские остатки, а конфигурации, которые считаются под клиента, синхронизировать нечего: остатка не существует, а цена определяется расчётом. Полезнее вложить те же деньги в форму заявки, которая доносит параметры до расчётчика без потерь, и в автозаполнение CRM — это дешевле обмена и даёт эффект сразу.
Две колонки. Левая «30 заказов в месяц»: «ручной перенос 1 050 ₽», «обновление прайса 1 400 ₽», «отмены 3 800 ₽», итог «эффект 6 250 ₽/мес», «поддержка обмена 15 000 ₽/мес», вывод «обмен дороже проблемы». Правая «400 заказов в месяц»: «ручной перенос 14 000 ₽», «обновление прайса 5 600 ₽», «отмены 53 200 ₽», итог «эффект 72 800 ₽/мес», «поддержка обмена 20 000 ₽/мес», вывод «окупаемость на седьмом месяце». Чертёжная манера, русские подписи.
Во всех остальных случаях порядок один и тот же: сначала обследование и письменный контракт данных, потом односторонняя выгрузка каталога, цен и остатков, потом три-четыре недели наблюдения за расхождениями, и только затем — приём заказов и статусы. Такой порядок стоит на 10–15% дороже по календарю и заметно дешевле по итогу, потому что каждая ошибка ловится, пока она стоит неверной строки на витрине, а не испорченного документа в закрытом периоде.
Горизонтальная лента из пяти этапов с длительностью и результатом. «Неделя 1: обследование и контракт данных → подписанный список полей и частот». «Неделя 2: справочники и соответствия → карта единиц, НДС, видов цен, чистый справочник». «Недели 2–3: выгрузка каталога, цен, остатков → каталог на сайте совпадает с учётом». «Недели 4–6: приём заказов и статусы → заказ с сайта создаёт один документ в 1С». «Неделя 7: мониторинг и приёмка → алерты работают, чек-лист пройден». Чертёжная манера, русские подписи.
И последнее, что стоит знать до разговора с подрядчиком: одинаковый по описанию обмен может стоить 80 000 ₽ и 600 000 ₽ совершенно законно — просто в первую смету вошло одно направление из шести, а во вторую все шесть с тестовым контуром и мониторингом. Разбор структуры сметы и шесть вопросов, которые сдвигают цену в обе стороны, вынесены в отдельный материал о стоимости интеграции 1С. А устройство обмена именно для интернет-магазина — частота выгрузок, резервы, статусы доставки — разобрано в статье об обмене магазина с учётом; там же собрана карта раздела о сайтах и электронной торговле.
