У каждого поля один хозяин
Цену и остаток ведёт 1С, маркетинговое описание чаще ведёт сайт, статус отгрузки — снова 1С. Записываем это в таблицу до начала работ. Иначе системы затирают друг друга, и никто не понимает, кто виноват.
Интеграция сайта с 1С — это обмен, при котором каталог, цены и остатки попадают на витрину сами, а заказ приходит в учёт с тем составом, ценой и статусом, которые видел покупатель. Менеджер ничего не перебивает руками, а сбой обмена виден в журнале раньше, чем в жалобе.
Базовый обмен — от 150 000 ₽Журнал, сверка и оповещения с первого дняИсходники и доступы — у вас
Первая — главная. Без неё любой обмен рано или поздно превращается в спор двух систем о том, чьи данные правильные.
Цену и остаток ведёт 1С, маркетинговое описание чаще ведёт сайт, статус отгрузки — снова 1С. Записываем это в таблицу до начала работ. Иначе системы затирают друг друга, и никто не понимает, кто виноват.
Покупатель видит данные из копии на стороне сайта. Если 1С занята, перезапускается или обновляется, витрина работает, а заказы ждут в очереди и доезжают сами.
Каждая сессия записана: что, когда, с каким результатом. Раз в сутки сайт и 1С сверяются между собой. Вопрос «где заказ?» решается за минуту, а не расследованием.
Типовой обмен закрывает основную схему, и писать своё там, где хватает готового, мы не будем. Честно скажем, где он упрётся: комплекты, договорные цены, частичные отгрузки.
Менеджер копирует заказ из письма или админки сайта в 1С. Ошибки в позициях, потерянные заказы в пиковые дни.
Остатки на сайте обновляются файлом по утрам, а склад продаёт и принимает весь день.
Цену или акцию изменили в 1С, а на сайте они обновятся только при следующей выгрузке. До этого покупатели оформляют заказы по старой цене, и менеджер объясняется с каждым.
Карточки заводят и в 1С, и в админке сайта. Артикулы расходятся, появляются дубли, правки теряются.
Обмен зависает на середине, сайт тормозит, и об этом узнают, когда придёт первый звонок покупателя.
Оплата и отгрузка проведены в 1С, а на сайте заказ «в обработке». Покупатель звонит, менеджер идёт в учёт смотреть.
Восемь потоков данных между сайтом и учётной системой. В каждом из них есть место, где обмен ломается тихо, поэтому в последнем столбце — на что смотреть.
Таблица — типичная раскладка. Реальную составляем с вашим коммерческим отделом, бухгалтерией и теми, кто ведёт каталог.
Здесь нет «лучшего» варианта: есть тот, который упирается позже. Таблица — наши рабочие критерии. Версии и возможности продуктов меняются, поэтому для вашей установки уточняем отдельно.
Подробнее о самом формате и его подводных камнях — в материале про обмен 1С с сайтом по CommerceML.
Восемь шагов. На каждом — место, где без продуманной интеграции заказ задваивается, теряется или меняет сумму.
У каждого способа оплаты свой источник истины. Если его не назвать заранее, статус «оплачен» появляется на сайте раньше, чем деньги в учёте, или не появляется вовсе.
Кассовые чеки формирует онлайн-касса или платёжный сервис, мы их не заменяем. Мы сверяем статус заказа с фактом оплаты. Как проводить операции в учёте, решает ваш бухгалтер. Детали зависят от договора с эквайрингом и банком.
Десять мест, где типовая выгрузка перестаёт справляться. Если хотя бы три из них про вас, одной настройки модуля обычно мало.
Комплекты — отдельная ловушка при выгрузке остатков. Если комплект собирается из компонентов при заказе, показывать нужно не сумму остатков, а то, сколько комплектов реально можно собрать.
Для каждого компонента разделите его остаток на количество в комплекте и возьмите минимум, округлив вниз до целого числа комплектов. Условный пример (числа условные): комплект собирается из двух штук А и одной штуки Б. На складе 10 штук А и 3 штуки Б. По А получается 10 / 2 = 5 комплектов, по Б — 3 / 1 = 3. Доступно три комплекта.
Если комплект хранится на складе уже собранным, правило другое. Какой у вас случай и как это заведено в вашей конфигурации 1С, выясняем на разборе. Для вашей версии механизм комплектов и наборов уточняем отдельно.
Журнал отвечает на вопрос «что случилось с этим заказом», ночная сверка — на вопрос «всё ли сейчас совпадает». Обмен может отработать без ошибок и всё равно потерять часть данных, поэтому нужны обе вещи. Правая колонка — то, что мы кладём поверх готового модуля или собственной сборки.
Сроки — ориентиры по каждому направлению отдельно, а не за весь набор сразу; что берём в первый этап, решаем после схемы. Цены — по тарифам: базовый односторонний обмен — от 150 000 ₽, типовой обмен 1С — 150 000–350 000 ₽. Не обязательно брать всё сразу: чаще начинают с каталога и остатков, а заказы добавляют следом.
Что и куда ходит, кто главный в каждом поле, таблицы статусов и способов оплаты. Результат — документ, по которому потом не спорят.
Выгрузка каталога из 1С на сайт: группы, варианты, комплекты, единицы, фото. Здесь чаще всего находится скрытый объём работы.
Типы цен для групп покупателей, склады, видимые на сайте, свободный остаток и страховой запас на ходовые позиции.
Очередь, ключ заказа, поиск контрагента, цены и скидки из заказа без пересчёта, резерв.
Таблица статусов, частичные отгрузки, признак оплаты, трек-номер, отмены и возвраты.
Личные цены, задолженность и лимит из 1С, счета и УПД в личном кабинете. Данные только для чтения.
Журнал каждой сессии, ночная сверка, оповещение о сбое и о росте длительности обмена.
Мониторинг, правки при обновлении сайта и 1С, развитие схемы. Пакеты по часам, ставка сверх пакета — по тарифам.
Тестовая копия — не формальность. Подключить непроверенный обмен к боевой базе — самый дорогой способ его проверить.
Платформа сайта, конфигурация и версия 1С, что обменивается сейчас, где теряются данные и заказы. Таблица «кто главный» по вашим полям.
Письменно: что, куда, как часто и по какому ключу. Таблицы статусов, способов оплаты и доставки. Документ, по которому потом не спорят.
Копия базы 1С и тестовый сайт. В копии 1С отключаем регламентные задания, обмены с банком, ЭДО и почтой; на тестовом сайте — письма, СМС и боевые платежи.
Готовый обмен там, где он подходит, доработка там, где нет. Журнал, очередь и сверка собираем сразу, а не после первого сбоя.
Сначала чтение боевых данных, потом запись. Заказы с сайта попадают в 1С непроведёнными, менеджер сверяет их с тем, что видит покупатель.
Каталог, затем остатки и цены, затем заказы, затем статусы и оплаты, затем документы в кабинет. Остановиться можно после любого этапа; дальше — сопровождение.
Те же принципы (один хозяин у поля, очередь, журнал) на других парах систем и подробности про сам формат обмена.
Из чего состоит сеанс обмена, какие файлы ходят и почему при росте каталога он начинает тормозить.
Разбор типовой задачи: остатки, цены и заказы между учётом, сайтом и площадками. Где такой обмен обычно рассыпается.
Семь причин расхождения и способ найти свою за час. Большинство применимо и к остаткам на сайте.
Обзор всех направлений обмена с 1С, пакеты работ и две ступени цены.
Названия — примеры, а не обязательный набор. Платформа сайта и версия 1С определяют, что взять готовым, а что написать.
Сайт на 1С-Битрикс, WooCommerce или OpenCart, учёт в 1С. Обмен либо делается руками, либо «почти работает» и теряет частные случаи.
Договорные цены, лимиты, документы в кабинете (что включать в кабинет партнёра). Типовая выгрузка здесь заканчивается, и начинается проектирование.
Модуль справляется с основным потоком, а при обновлении или росте каталога встаёт. Журнал и сверка снимают слепоту.
Сайт плюс маркетплейсы, склад один, 1С одна. Чем больше каналов, тем дороже любой рассинхрон остатков.
Короткий созвон: какая платформа сайта, какая конфигурация 1С и что сейчас переносится руками. По итогам скажем, с чего начинать, сколько это стоит и что нужно от вас.
Сначала описывают, что и в какую сторону ходит и кто главный в каждом поле. Затем делают тестовые копии 1С и сайта, настраивают обмен и прогоняют его на копии. Только после этого включают на боевых данных по этапам: каталог, остатки и цены, заказы, статусы и оплаты. Формат (CommerceML, HTTP-сервисы или своя доработка) выбирают по задаче, а не наоборот.
Для типового магазина обычно хватает CommerceML: он хорош для каталога, цен, остатков и заказов пачками по расписанию, формат стандартный, его понимают типовые модули. API (HTTP-сервисы или OData 1С) добавляют, когда данные нужны сразу и по конкретному клиенту: договорные цены, лимит, документы. Но сайт не должен спрашивать 1С при каждом открытии страницы: между ними нужен кэш.
Для базовой схемы часто подойдёт. У 1С-Битрикс обмен с 1С по CommerceML входит в состав магазина, но возможности зависят от редакции и версии. Для WooCommerce и OpenCart обычно берут модули сторонних авторов, и их возможности заметно отличаются. Типовой обмен упирается в комплекты, договорные цены, частичные отгрузки и правку заказа после оплаты. Что подойдёт вам, скажем на разборе по вашим версиям сайта и 1С.
Зависит от оборота. Ходовые позиции обновляют чаще, медленные реже, и обычно речь о минутах, а не о секундах и не о раз в сутки. Обмен в реальном времени не цель: окно между продажей и обновлением остаётся. Его закрывают небольшим страховым запасом и проверкой резерва при оформлении заказа.
Типичные причины такие. Сессия обмена не отработала, и никто об этом не узнал. Заказ не подошёл под фильтр выгрузки на сайте, например по статусу или способу оплаты. Повтор после таймаута создал второй заказ, потому что у заказа нет ключа. Контрагента не нашли, и заказ остановился на ошибке. В журнале видна каждая попытка, ключ заказа не даёт создать дубль, а ошибки приходят оповещением.
Каталог идёт файлом по CommerceML или через собственный обмен. Заранее решают три вещи: по какому ключу товар опознаётся (внутренний идентификатор надёжнее артикула), как характеристики 1С превращаются в варианты товара на сайте и где ведутся фото. Первую полную выгрузку делают на тестовом сайте, а не на боевом.
Разделить потоки. Остатки и цены передавать маленькими порциями и чаще, описания, характеристики и фото только по изменениям, полную выгрузку редко и ночью. Длительность каждой сессии пишется в журнал, а рост длительности вызывает оповещение, поэтому проблему видно до того, как она станет жалобой.
Закрытый контур — рабочий случай: 1С остаётся за периметром, обмен идёт по согласованному каналу, сторонние облачные посредники не нужны. В классической схеме соединение открывает сама 1С, а если сайту нужны данные сразу, наружу публикуют только согласованный сервис. С файловой базой есть ограничения по одновременной работе и фоновым заданиям: для регулярного обмена и публикации сервисов обычно удобнее клиент-серверный вариант или отдельный постоянный сеанс. Что возможно у вас, смотрим на разборе, по версии платформы и конфигурации.
Базовый односторонний обмен — от 150 000 ₽. Типовой обмен 1С по типовой схеме (каталог, остатки, заказы и статусы) — 150 000–350 000 ₽; нестандартные случаи вроде договорных цен, комплектов и частичных отгрузок оцениваем отдельно после схемы обмена. Если кроме сайта есть маркетплейсы, B2B-кабинет или несколько баз, сначала делают обследование по тарифам: от 200 000 ₽ за один-два процесса, от 350 000 ₽ за несколько систем; оно вычитается из следующего этапа. Сопровождение обмена — от 20 000 ₽ в месяц. Точную цену называем после схемы обмена.
1С-Битрикс: Управление сайтом — платформа сайта и интернет-магазина, по ней идут каталог, цены, остатки и заказы. Битрикс24 чаще связывают с 1С как CRM: клиенты, сделки, счета. Схемы обмена разные. Если ваш магазин собран внутри Битрикс24, скажите об этом на разборе: схема будет другой.
По трём признакам. Журнал показывает каждую сессию с результатом. Ночная сверка сравнивает товары, остатки, цены и статусы заказов на сайте и в 1С и присылает список расхождений. При остановке обмена вам приходит оповещение. Если этого нет, «работает» значит «пока никто не жаловался».