Магазин и учётная система расходятся в данных ровно там, где не договорились об источнике истины. Мы начинаем с обследования вашей конфигурации, фиксируем, какое поле откуда приходит, и настраиваем обмен товарами, ценами, остатками и заказами с журналом и тестовым контуром.
Страница для компаний, у которых учёт ведётся в 1С. Если узнаёте несколько пунктов, задача сформулирована верно.
Цены на сайте и в учёте расходятся, и никто точно не знает, какая версия верная.
Остатки обновляются вручную, поэтому заказы приходят на позиции, которых нет.
Заказы с сайта переносятся в 1С руками, а часть данных теряется по дороге.
Новый товар появляется на сайте с задержкой, потому что карточку заводят отдельно.
Варианты и характеристики в учёте и на сайте устроены по-разному.
Когда обмен ломается, об этом узнают по жалобам, а не из журнала.
Если учёт ведётся не в 1С, а в облачном сервисе, точнее подойдёт страница про интеграцию с МоимСкладом
Основная проблема
Расхождение данных — следствие неопределённого источника истины
Пока обмена нет, магазин и 1С существуют как две независимые базы, и каждая считает себя основной. Менеджер меняет цену в учёте, контент-менеджер — на сайте, и через месяц уже невозможно сказать, где актуальное значение. То же происходит с остатками: сайт продаёт то, что физически отгрузить нельзя, и заказ превращается в отмену или в разговор о замене.
Вторая часть проблемы — заказы. Ручной перенос заявки в учётную систему допускает расхождения в артикулах, количествах и реквизитах, а также растягивает обработку. При этом сам факт заказа существует в двух местах в разных состояниях: на сайте он оплачен, в учёте — ещё нет, и статус для покупателя перестаёт соответствовать реальности.
Правильная интеграция начинается не с настройки обмена, а с решения о том, какое поле принадлежит какой системе. После этого обмен становится технической задачей: односторонняя или двусторонняя передача, расписание, сопоставление номенклатуры, поведение при конфликте и журнал, по которому видно каждую операцию. И здесь важна честность: 1С — это не одна система, а множество конфигураций и доработок, поэтому объём работ можно назвать только после обследования вашей.
Что происходит без изменений
Что следует из отсутствия обмена
Только логические следствия. Мы не приводим выдуманных цифр потерь.
Заказы на отсутствующий товар
Остатки на сайте отстают от учёта, поэтому часть заказов приходится отменять или согласовывать замену.
Продажи по устаревшим ценам
Изменение цены в учёте не доходит до сайта, и заказ оформляется по значению, которое уже не действует.
Двойная работа по каждому заказу
Заявка обрабатывается сначала на сайте, затем переносится в учёт вручную.
Ошибки в артикулах и количествах
Ручной перенос данных допускает расхождения, которые обнаруживаются на сборке заказа.
Каталог обновляется с задержкой
Новые позиции появляются на сайте позже, чем в учёте, и часть спроса приходит в пустоту.
Сбои остаются незамеченными
Без журнала и уведомлений остановка обмена обнаруживается по последствиям, а не по факту.
Что создаётся
Что создаётся
Результат — работающий и наблюдаемый обмен, а не одноразовая выгрузка файла.
Карта источников данных
Фиксируем по каждому полю, какая система является источником: наименование, цена, остаток, характеристики, статусы.
Снимает: Расхождения перестают возникать: у каждого значения есть один владелец.
Обследование конфигурации со стороны обмена и фиксация ограничений.
Проектирование карты источников истины и правил конфликта.
Сопоставление номенклатуры, вариантов и характеристик.
Передача цен, остатков, заказов и статусов, защита от дублей.
Журналирование, повторные попытки и уведомления о сбоях.
Тестовый контур, контрольные сценарии и наблюдение после запуска.
Клиент
Доступ к учётной системе, тестовая копия и сетевая доступность.
Решение о владельце каждого поля и правилах конфликта.
Качество данных в учёте: идентификаторы, характеристики, типы цен, склады.
Доработки самой конфигурации 1С силами своего специалиста или подрядчика.
Дисциплина проставления статусов и обработки заказов в учёте.
Лицензии 1С и её сопровождение.
Стоимость
Что влияет на оценку
Стоимость интеграции определяется вашей конфигурацией, а не количеством товаров. Поэтому фиксированной цены до обследования не существует.
Конфигурация и доработки
Типовая конфигурация и сильно доработанная требуют разного объёма работ и разных способов обмена.
Доступный интерфейс обмена
Наличие штатного механизма обмена сокращает работу; его отсутствие требует иного решения.
Состав передаваемых данных
Номенклатура, характеристики, изображения, типы цен, склады, документы и статусы оцениваются по фактическому перечню.
Качество данных в учёте
Отсутствие устойчивых идентификаторов и незаполненные характеристики добавляют работу по сопоставлению.
Требования к частоте обмена
Обновление раз в сутки и обновление в течение минут — разные технические решения.
Требования к наблюдаемости
Глубина журналирования, уведомления и тестовый контур влияют на трудоёмкость.
Расчёт формируем после обследования: до него любая цифра была бы предположением. Ценовая лестница интернет-магазинов на интеграцию автоматически не переносится.
Вопросы и ответы
Вопросы об интеграции с 1С
Потому что 1С — это семейство конфигураций с индивидуальными доработками. От того, есть ли штатный механизм обмена, как устроены справочники и что именно нужно передавать, объём работ меняется кардинально. Мы сначала проводим обследование и только затем даём расчёт: назвать цифру раньше означало бы пообещать то, что может оказаться технически иным.
Как решите по карте источников истины. Типовая схема: из 1С на сайт идут номенклатура, цены и остатки, с сайта в 1С — заказы, обратно на сайт возвращаются статусы. Двусторонняя передача одного и того же поля — источник конфликтов, поэтому у каждого значения должен быть один владелец.
Частоту согласуем исходя из ваших процессов и возможностей системы. Для части магазинов достаточно нескольких раз в сутки, для других нужны более короткие интервалы. Важно понимать зависимость: чем короче интервал, тем выше требования к каналу обмена и к производительности учётной системы.
Именно для этого настраиваются журнал, повторные попытки и уведомления. Заказ, который не удалось передать, не теряется: он остаётся в очереди и отправляется повторно, а ответственный получает уведомление о сбое. Разбор инцидента идёт по журналу, где видно состав переданных данных.
Защита от дублей — обязательная часть работы и отдельный пункт приёмки. Повторная отправка одного и того же заказа не должна создавать второй документ. Это проверяется искусственно вызванным повтором на тестовом контуре до запуска.
Нужен доступ к тестовой копии для обследования и настройки, а также согласованный канал обмена для продакшена. Права запрашиваем минимально необходимые. Если политика безопасности не допускает внешнего доступа, работаем через вашего специалиста по 1С — тогда часть работ выполняет он по согласованной технической спецификации.
Нет. Обмен переносит значения, а не проверяет их корректность. Если в учёте пустые характеристики, дубли позиций или неверные цены, они окажутся на сайте. Поэтому обследование часто заканчивается перечнем данных, которые нужно привести в порядок на стороне учёта — эту работу мы обозначаем явно.
Технически да, и на старте это иногда оправдано. Но у ручной выгрузки нет наблюдаемости: никто не знает, когда она выполнялась последний раз и что попало в файл. Как только объём заказов вырастает, ручной режим становится источником расхождений — именно тех, из-за которых интеграцию и заказывают.
Следующий шаг
Обсудим интеграцию с 1С
Напишите, какая у вас конфигурация, что нужно передавать и есть ли тестовая копия. Предложим порядок обследования и состав работ.
