Интернет-магазин с каталогом 10 000+ товаров перешёл с 1С:Управление торговлей 11.4 на 1С:Комплексная автоматизация 2.5 — и при этом сайт на Битрикс не останавливался ни на один день. Мы перенесли все накопленные за годы доработки, починили ошибки обмена, убрали двойной пересчёт скидок и без единого сбоя загрузили больше 20 000 исторических заказов.
Кому пригодится наш опыт
Этот кейс будет полезен, если вы:
планируете перейти с одной конфигурации 1С на другую и переживаете за сохранность доработок;
уже работаете с обменом 1С — Битрикс и сталкиваетесь с ошибками, непредсказуемым поведением скидок или «ломающимися» заказами;
хотите расширить стандартный обмен под реальные процессы своего магазина.
Битрикс «из коробки» рассчитан на усреднённый магазин. Вашего магазина в этом расчёте, скорее всего, нет
Обмен 1С с сайтом на Битрикс выглядит как решённая задача: ставишь модуль, делаешь несложные настройки, нажимаешь «Выполнить обмен данными» и обмен запускается. 1С и сайт обмениваются товарами и заказами. Так и есть — ровно до того момента, пока у вас типовой магазин без единой доработки.
Стандартный модуль обмена проектируют под усреднённый сценарий: есть товары, есть цены, есть заказы — обменивайтесь на здоровье. Но реальный магазин почти никогда не усреднённый. Стараясь отличаться и быть лучше других, компании вводят разные механики скидок, разрабатывают свою логику распределения заказов по складам, дорабатывают карточки заказов и еще много чего.
Каждая такая деталь — это уже доработка, то есть выход за пределы того, что вендор гарантирует «из коробки». Простой обмен становится сложным, требует дополнительных усилий в поддержке, а при переходе на новую конфигурацию «переезд» становится инженерной задачей.
Расскажем, как это было у нашего клиента.
С чем пришёл клиент
Заказчик — интернет-магазин в деликатной нише, где покупателю важна приватность. У компании несколько складов, а также есть розничные магазины. Сайт работает на 1С-Битрикс, учёт ведётся в 1С, в каталоге больше 10 000 товаров. В магазине применяются разные системы скидок: накопительные карты, промокоды, подарочные сертификаты.
Несколько лет магазин работал на связке 1С:Управление торговлей 11.4 + сайт на Битрикс. За это время в 1С появились доработки, которые касаются обмена с сайтом — выгрузка настраиваемой структуры каталога, расчёт акционных цен, красивые описания товаров, передача карт лояльности и сертификатов. Всё это работало, и всё это нужно было сохранить.
Проблема в том, что 1С прекращала поддержку УТ 11.4 и вставал вопрос: обновляться на УТ 11.5 или переходить на более функциональные конфигурации. Клиент решил переходить на 1С:Комплексная автоматизация (КА), так как в ней есть возможность вести бухгалтерский учёт.
И тут встал главный вопрос: как перейти на новую конфигурацию не потеряв ни одну доработку и не остановив интернет-магазин. Сложностей было две:
Доработанный модуль обмена. «Просто перенести» доработки невозможно. Модуль обмена Битрикс в КА устроен иначе, чем в УТ. Доработки, написанные под одну конфигурацию, не работают в другой без адаптации. А код доработок был вплетён в типовые модули настолько глубоко, что «скопировать и вставить» не получится.
Смежные с обменом доработки в самой конфигурации УТ. Они не затрагивали сам модуль, но использовали данные, которые приходили с сайта. Такие доработки надо тоже переносить.
"Нам нужно перейти на КА, но чтобы сайт продолжал работать так же, как раньше. Обмен товарами, ценами, заказами, скидками — всё должно работать. И нам важно, чтобы обмен был максимально штатным."
Директор интернет-магазина
Как мы обеспечили переход без остановки магазина
Главный страх любого, кто задумывается о миграции данных: «а вдруг сайт встанет на время переезда». Поэтому мы построили работу так, чтобы рабочие системы не трогались до самого финала.
Сначала мы подготовили тестовую среду: подготовили тестовую базу, загрузили в неё конфигурацию 1С:Комплексная автоматизация. А коллеги — разработчики сайтов Битрикс, подготовили копию сайта.
Все доработки, перенос обмена, отладку сложных сценариев и загрузку данных мы выполняли и проверяли именно там. Рабочая база и действующий магазин всё это время продолжали работать в штатном режиме и приносить продажи.
Только когда всё было собрано и протестировано, мы перенесли готовое решение в боевой контур. Перенос был спланирован так, чтобы покупатели не заметили изменений: магазин принимал и обрабатывал заказы без перерыва. Именно поэтому проект занял время (см. раздел «Сколько стоит»), но при этом ни одного дня простоя у магазина не было.
Что мы сделали
Перенесли доработки и модуль обмена
После создания тестовой среды начался кропотливый ручной перенос доработок: сравнили старую конфигурацию с новой, выявили все изменения и перенесли их из УТ в КА.
Что касается модуля обмена, то здесь была сложность. Перенести доработки «один в один» было нельзя. Доработки были сделаны под модуль обмена с УТ, а код КА отличается. Поэтому доработки надо было не просто перенести, а еще адаптировать под требования модуля обмена для КА. Пришлось «сшивать» изменения с двух сторон, чтобы сохранить и наши доработки, и штатные улучшения новой конфигурации.
Перенесли расширения и упростили их архитектуру
В УТ работало расширение для передачи акционных цен. Суть акционных цен — показать клиенту «старую» цену (до скидки) и новую, со скидкой. Для этого на сайт для акционных товаров передавалось две цены: получив их из 1С, сайт поставлял их в карточку товара и зачёркивал «старую» цену. Мы не просто скопировали это расширение, а перенесли его в основную конфигурацию.
Что это даёт бизнесу: покупатель сразу видит размер выгоды, а магазин управляет акционными ценами из 1С без отдельного расширения.
Другое расширение создавало возможность использовать промокоды в УТ и на сайте. Клиент решил отказаться от промокодов в пользу карт лояльности — мы воспользовались этим и упростили архитектуру, удалив ненужные компоненты.
Настроили и доработали обмен заказами — самый объёмный этап
Это потребовало слаженной работы трёх сторон: нашей команды, клиента и разработчиков сайта на Битрикс.
Регулирование скидки и карты лояльности
Те компании, у кого сайт работает в связке с 1С и на сайте используются скидки, скорее всего сталкивались с двойным расчётом скидок. Так было и у нашего клиента. Покупатель интернет-магазина должен всегда видеть актуальную цену, в том числе, когда применяет скидку. Это значит, что скидка должна рассчитываться на сайте, а в 1С заказ должен приходить с конечной ценой. Но в новой конфигурации 1С так не работало.
Когда заказ приходил с сайта в 1С, 1С применяла скидку повторно. А после повторного обмена могла отдать на сайт цену с двойной скидкой. Получается, что клиент оплатил за заказ одну сумму, а через некоторое время увидел в заказе сумму меньше. В самой 1С учёт тоже сбивался. Проблема с двойным расчётом скидок касалась еще и накоплений по картам лояльности: если скидка применилась повторно, то на карту лояльность зачислилось меньше накоплений.
После тестирования и отладки различных сценариев обмена совместно с разработчиками Битрикс, мы сделали так, чтобы 1С принимала цены в заказе с сайта «как есть» и не рассчитывала скидки повторно. Это позволило решить проблему некорректного расчёта стоимости заказов и неправильных начислений накоплений по картам.
Блок подмены контактных данных
В своём интернет-магазине заказчик использует накопительные карты лояльности. При первом заказе с использованием карты в 1С создаётся контрагент — фактический владелец скидки. К контрагенту привязываются контакты (ФИО, телефон, почта), которые покупатель указал при первом оформлении заказа. В дальнейшем часть аналитики строится в разрезе контрагентов.
В этой нише многие покупатели хотят сохранить приватность, поэтому при оформлении заказов указывают вымышленные ФИО и контактные данные. А ещё владелец карты может передать её другим людям, которые будут делать покупки и указывать свои ФИО и телефон. Если покупатель будет каждый раз указывать новые данные, то карточка контрагента может быть перезаписана, а аналитика будет ошибочна.
Клиент попросил сделать так, чтобы при использовании карты лояльности заказ 1С был оформлен на владельца карты, но можно было видеть какие контактные данные указал покупатель при оформлении заказа.
Мы доработали в 1С документ «Заказ клиента» — добавили в него специальные поля для ФИО, номера телефона, почты. Когда менеджер проверяет заказ в 1С, он видит владельца карты, но при подтверждении заказа обращается к покупателю так, как он указал себя при оформлении заказа.
Что это даёт бизнесу: аналитика по контрагентам не ломается, а клиент сохраняет приватность — важно для деликатной ниши.
Пометка “Не звонить”
Если покупатель на сайте отметил галочку «Не звонить для подтверждения заказа», менеджер должен сразу это увидеть. Мы добавили в форму заказа крупную красную надпись, которая появляется автоматически — пропустить её невозможно.
Что это даёт бизнесу: меньше нежелательных звонков от менеджеров — меньше негатива от клиентов. Опять же критично для деликатной ниши.
Автоматический выбор склада-отправителя
Раньше склад назначался вручную. Клиент хотел, чтобы система сама определяла, откуда отгружать: с основного склада, из розничного магазина или от поставщика. Мы написали алгоритм, который проверяет остатки и заполняет склад по приоритету: сначала основной склад, потом магазин, в крайнем случае — поставщик. Менеджерам больше не нужно проверять остатки вручную и выбирать склад при каждом заказе — 1С сама проверит остатки и выберет нужный склад отгрузки.
Что это даёт бизнесу: меньше ручной рутины и ошибок отгрузки, быстрее обработка заказов.
Разобрались с выгрузкой подарочных сертификатов
Клиент перешёл на новый механизм учёта сертификатов, и статусы сертификатов с остатками перестали корректно передаваться на сайт. Мы разобрались с механикой передачи данных сертификатов и выяснили, что данные в карточке сертификата формировались из одного источника, а в справочник попадали из другого — и только по расписанию. Мы переписали процедуру синхронизации и остатки стали передаваться корректно.
Что это даёт бизнесу: покупатель видит актуальный баланс сертификата, а магазин избегает споров о «несгораемых» или «исчезнувших» суммах.
Загрузили 20 000 исторических заказов
После того, как все изменения были протестированы и подготовлены к переносу в рабочую базу, клиент решил, что хочет начать вести учёт «с нуля». Причиной тому были накопленные ошибки учёта и аналитики. Поэтому подготовленные изменения были перенесены в чистую базу.
Но нужно было сделать так, чтобы в базе отразились накопления по картам лояльности и история по контрагентам. Сделать это можно было, если создать в новой базе документы «Заказ клиента» на основе заказов с сайта. Мы разработали специальный загрузчик, который загружает в 1С заказы с сайта, при этом создаёт контрагентов и необходимые смежные данные. Загрузка шла пакетами по 5 000 заказов с промежуточным резервным копированием.
Что получилось в итоге
В рамках проекта реализован полный цикл работ — от развёртывания тестовой среды до загрузки данных в рабочую базу. Всего решено 37 задач разной сложности. Помимо описанного выше, мы также:
устранили ошибки обмена с Битрикс по товарам и ценам;
исправили ошибки заполнения полей документов в 1С;
реализовали выгрузку настраиваемого каталога товаров на сайт;
создали загрузчик номенклатуры из файлов сайта Битрикс;
решили ряд других ошибок и выполнили необходимые настройки.
Итог проекта:
Полноценная связка КА — Битрикс. Двусторонний обмен товарами (10 000+ позиций), ценами, остатками, заказами, оплатами и данными о доставке работает в штатном режиме.
Корректная система скидок. Карты лояльности и подарочные сертификаты правильно передаются между 1С и сайтом: накопления считаются, статусы обновляются, двойного пересчёта нет.
Автоматизация рутины. Склад-отправитель определяется автоматически по остаткам, контактные данные сохраняются в каждом заказе, метка «Не звонить» видна менеджеру сразу.
Стабильная миграция без простоя. Более 20 000 исторических заказов загружены без единой ошибки, магазин не останавливался ни на день.
Сколько стоит
Проект перехода на КА с сохранением обмена занял 8 месяцев — большая часть времени ушла на аккуратную работу в изолированной тестовой среде и поэтапное тестирование, чтобы магазин не останавливался. По текущему прайсу стоимость такого проекта — от 750 000 рублей.
Сталкиваетесь с похожими задачами? Напишите нам — разберёмся в вашей ситуации и предложим решение.