Интеграция сайта с 1С: товары, остатки и заказы

Как устроен типовой обмен

Изобретать велосипед почти никогда не нужно. У 1С есть собственный стандарт — CommerceML: сайт и 1С обмениваются файлами import.xml (каталог, характеристики) и offers.xml (цены и остатки), а в версиях 3.0–3.1 остатки иногда выгружаются отдельным rests.xml. Заказы летят обратно — из корзины сайта в 1С, с составом и статусом.

Для 1С:УТ, УНФ, КА, ERP и Розницы обмен с сайтом — типовая функция «из коробки» (спасибо самому 1С — стандарт делали они же), и почти любая популярная CMS читает эти файлы без танцев с бубном.

Хорошая новость. Плохая — она касается только момента запуска.

Где обмен реально ломается

Настроить обмен — не значит, что дальше будет тихо. По моей практике, проблемы вылезают не сразу, а спустя месяц-два, когда все расслабились и перестали проверять.

• Кто-то обновил конфигурацию 1С — версия обмена незаметно сдвинулась, формат offers.xml чуть изменился, сайт часть данных читать перестал.
• Обмен идёт по расписанию раз в 15–30 минут; упал в этот момент сервер сайта или 1С — событие теряется, и вы узнаете об этом из жалобы клиента.
• А если складов несколько? Остаток — уже не одно число, а сумма по точкам, и обмену нужно точно понимать, откуда резервировать под заказ.
• Кто-то поправил остаток «руками» прямо в базе 1С, в обход обмена — следующая синхронизация это тихо перезапишет.

Точнее — не сам обмен «ломается», ломается сверка между системами: каждая по отдельности работает штатно, просто они больше не говорят об одном и том же.

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

Что делать с расхождением остатков

Хочется поставить обмен раз в 15 минут и забыть. Не выйдет: событийная синхронизация всегда даёт погрешность, и вопрос не «будет ли расхождение», а «когда вы о нём узнаете» — от клиента или из отчёта.

1. Добавьте суточную полную сверку остатков — не «что-то изменилось», а честное построчное сравнение таблицы 1С с тем, что видит сайт, и отчёт о расхождениях.
2. Ведите журнал ошибок обмена и хотя бы раз в неделю в него заглядывайте. Лог, который никто не читает, бесполезен.
3. Назначьте одного ответственного за обмен. Не «это к подрядчику сайта» и не «это к 1С-нику» — а конкретный человек, который проверяет оба конца.
4. Списывайте остаток по факту резервирования заказа, а не отгрузки — иначе между оплатой и списанием остаётся окно для оверселла.

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

Кто в вашей компании вообще смотрит в лог обмена? Если честно затрудняетесь ответить — это уже ответ.

Ручной ввод, типовой обмен или свой велосипед

Мы все хотим настроить обмен один раз и забыть о нём — реальность обычно не согласна.

На мой взгляд, для большинства интернет-магазинов типового CommerceML достаточно — переплачивать за индивидуальную интеграцию при паре сотен SKU на одном складе смысла нет. Кастом нужен, когда складов несколько или обмен должен идти мгновенно, в момент заказа, а не по расписанию.

У меня в услугах это отдельная линия — интеграции с 1С, CRM и обмен между системами с журналом ошибок. Фиксированной цены на кастомные интеграции нет: смотрю объём на коротком созвоне и называю сумму без вилок «от и до».

Кстати, если магазин ещё не запущен и вы выбираете движок — от CMS зависит, насколько больно дастся обмен: разбирал это в статье про выбор CMS для интернет-магазина.

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