Как мы делали интернет-магазин с интеграцией 1С: разбор проекта

«Нужен интернет-магазин с интеграцией 1С» — с этой фразы начинается едва ли не половина проектов в нашей практике. Звучит как один пункт в брифе, а на деле за ним стоят месяцы работы, десятки согласований и целый слой решений, который заказчик обычно не видит. Разберём реальный проект: что делали, где спотыкались, какие решения оказались удачными, а какие мы бы сегодня приняли иначе.

Вводные: что было у заказчика

Компания торгует профессиональным инструментом: опт и розница, около 4000 SKU, часть позиций с характеристиками и аналогами. Учёт полностью ведётся в 1С:Управление торговлей 11.4. Сайт существовал лет семь и держался на старой CMS с самодельным обменом.

К моменту старта проекта проблемы накопились предсказуемые:

• менеджеры вручную переносили заказы из сайта в 1С — до получаса на крупный заказ;
• цены на сайте обновлялись раз в неделю, из-за чего часть заказов отменялась после согласования;
• остатки на сайте и в учёте расходились, особенно по позициям с нескольких складов;
• заказы терялись: письмо уходило, но в базе не появлялось.

Задача звучала так: новый магазин, который живёт данными из 1С и отдаёт заказы обратно без ручного труда. Срок в брифе — четыре месяца, и это была первая честная договорённость с заказчиком: интеграцию мы оценивали отдельно от сайта и сразу сказали, что её доля — примерно половина бюджета.

Что такое интеграция с 1С на практике

Заказчику полезно понимать: «интеграция» — это не кнопка и не один скрипт, а набор сценариев обмена. У каждого своё направление, частота и правила обработки конфликтов. Мы разложили задачу на четыре независимых потока.

Товары, характеристики, цены

Из 1С на сайт уходят номенклатура, группы, свойства, штрихкоды, единицы измерения, цены по типам (розничная, оптовая), скидки и акционные правила. Объём — около 4000 позиций плюс изображения. Полный обмен занимал порядка 12–15 минут, поэтому сделали инкрементальный: 1С отдаёт только изменённые с определённой даты объекты.

Остатки и склады

Остатки меняются чаще всего, но публиковать их в реальном времени не нужно: заказчик сам попросил аккуратность вместо мгновенности. Итоговое решение — обмен раз в 10 минут по трём складам, при этом на карточке показываем не точное число, а статус: «в наличии», «мало», «под заказ». Это снимает большинство претензий и убирает гонку за последним товаром.

Заказы и документы

Обратный поток: заказ с сайта, статусы обработки, резерв, номера документов реализации и оплат. Здесь важно было не только передать данные, но и вернуть на сайт актуальный статус, чтобы клиент видел реальную картину, а не «обрабатывается» в течение трёх дней.

Архитектура: как это было устроено

Сайт мы переписали на Laravel, база — MySQL, очередь — Redis. На стороне 1С опубликовали HTTP-сервисы, которые отдают данные порциями и принимают заказы. Между системами поставили прослойку-обменник: он ходит в 1С по расписанию, складывает полученное в очередь и разбирает её воркерами.

Альтернативу — классический файловый обмен через каталог на FTP — рассмотрели и отклонили. Она дешевле на старте, но плохо показывает, что именно сломалось, и почти не умеет ретраи. Прослойка стоила дороже, зато дала журнал каждого обмена, повторные попытки и метрики.

Что оказалось сложнее всего

Ожидаемо тяжело пошло не там, где мы думали.

• Номенклатура. В 1С процветали дубли и позиции с одинаковыми названиями. Пришлось вводить правило: сайт доверяет 1С, но требует уникальный внешний идентификатор, а спорные карточки разбирает менеджер.
• Цены и скидки. Логика скидок в УТ11 сложная: правила, группы, ручные скидки в заказе. Мы отказались от идеи переносить её на сайт целиком и настроили двухуровневую схему — простая скидка на витрине, финальный пересчёт в 1С.
• Резервы. Момент между «клиент оформил заказ» и «менеджер подтвердил» — самый конфликтный. Решили через мягкий резерв на 30 минут и понятное сообщение клиенту, если товар ушёл.
• Производительность. Полная синхронизация картинок и характеристик валила сервер на первых прогонах. Помогли батчи, кэш и отложенная загрузка изображений.

Как проверяли

За две недели до сдачи мы устроили серию прогонов на копии боевой базы: меняли цены, удаляли товары, оформляли заказы с оптовыми ценами, специально роняли обмен и смотрели, как система восстанавливается. Отдельно проверяли поведение при недоступной 1С — сайт должен продолжать продавать, а не показывать ошибку.

Результаты

• ручной перенос заказов исчез полностью;
• цены и остатки на сайте отстают от учёта не более чем на 10–15 минут;
• потери заказов прекратились — каждый обмен логируется и повторяется при сбое;
• менеджеры переключились на работу с клиентами вместо копирования данных.

Что бы сделали иначе

Мы бы раньше вычистили справочник номенклатуры вместе с заказчиком — это заняло больше времени, чем сама разработка обменника. И заложили бы админку для правил маппинга с первого дня: часть настроек пришлось менять уже после запуска, и без интерфейса это делалось руками в коде.

Главный вывод простой: интеграция с 1С — это проект внутри проекта. Её нельзя оценивать как «модуль за N тысяч». Это отдельная система со своими сценариями, тестами и поддержкой, и чем честнее об этом сказать заказчику на старте, тем меньше сюрпризов будет на сдаче.