Как связать сайт с 1С и не потерять остатки: обмен по CommerceML на практике

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

Обмен между сайтом и 1С решает эту задачу, если он настроен под ваш учёт. Одного «включения» для этого мало. Разберём, как он устроен и где обычно возникают расхождения.

Что такое CommerceML и что по нему передаётся

CommerceML это открытый формат обмена коммерческими данными на основе XML. Его поддерживают типовые конфигурации 1С и большинство платформ для интернет-магазинов, в том числе 1С-Битрикс. Поэтому базовый обмен между ними можно настроить без программирования с нуля.

По стандартной схеме передаются:

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

Обмен запускается со стороны 1С: по расписанию или вручную. 1С сама обращается к сайту, авторизуется, отдаёт файлы и забирает новые заказы.

Главный принцип: у каждого товара один идентификатор

Сайт и 1С узнают товар не по названию и не по артикулу, а по внутреннему идентификатору, который создаёт 1С. Отсюда типичная проблема.

Менеджер удалил товар в 1С и завёл его заново, потому что «так было проще». Для 1С это новый товар с новым идентификатором. При следующем обмене на сайте появляется второй товар с тем же названием, а старый остаётся с прежними отзывами, адресом и позициями в поиске, но без остатков.

Правило простое: товары в 1С не пересоздают, а редактируют. Если без пересоздания не обойтись, сопоставление нужно делать вручную или специальной обработкой.

Почему остатки на сайте не совпадают с 1С

Это самая частая жалоба. Причин несколько, и они складываются.

Задержка между обменами

Если обмен идёт раз в час, в течение часа сайт показывает остаток, который уже мог измениться. Для товаров, которые продаются по одной штуке в неделю, это неважно. Для ходовых позиций с небольшим остатком это гарантированные «продажи воздуха».

Решение не в том, чтобы запускать полный обмен каждую минуту, а в том, чтобы передавать только изменения и делать это чаще. Полная выгрузка всего каталога нагружает и 1С, и сайт, и при большом каталоге может не успевать закончиться до следующего запуска.

Какой остаток считать

В 1С есть остаток на складе, резерв под заказы, товары в пути, остатки на разных складах и в магазинах. Что из этого показывать на сайте, решает бизнес, а не программист:

• только свободный остаток на складе интернет-магазина;
• сумму по всем складам;
• остаток с учётом ожидаемых поступлений;
• просто «в наличии» или «под заказ» без цифр.

Если это не решено явно, обмен выгружает то, что настроено по умолчанию, и цифры на сайте не совпадают с ожиданиями менеджеров.

Резервы под заказы с сайта

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

Характеристики и торговые предложения

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

Заказы: обратное направление

Обмен заказами устроен сложнее, потому что данные идут в обе стороны.

С сайта в 1С приходят состав заказа, покупатель, способ доставки и оплаты. Здесь важно заранее договориться:

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

Из 1С на сайт возвращаются статусы: подтверждён, собран, отгружен, оплачен. Если статусы не передаются, покупатель в личном кабинете видит «новый» заказ, который давно доставлен.

Онлайн-оплата добавляет ещё один слой: чек по 54-ФЗ должен пробиваться в правильный момент и одной системой, а не дважды, сайтом и 1С. Это стоит проверить отдельно до запуска.

Когда стандартного обмена мало

Типовой CommerceML закрывает большинство задач розничного магазина. Доработка нужна, если:

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

В таких случаях используют доработку стандартного обмена, HTTP-сервисы или OData 1С, а на стороне сайта REST API. Выбор зависит от задачи, и решать его лучше до разработки, а не после запуска.

Картинки, описания и SEO: где хранить контент

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

Обычно выбирают одну из схем:

• Всё в 1С. Подходит для небольших каталогов, где описание короткое и почти не меняется. Плюс: один источник данных. Минус: менеджеры по контенту работают в 1С, а выгрузка картинок утяжеляет обмен.
• Учётные данные в 1С, контент на сайте. Название, артикул, цены, остатки и характеристики приходят из 1С, а описания, фотографии и SEO-тексты ведутся в админке сайта. Обмен настраивают так, чтобы он не перезаписывал эти поля.
• Отдельная система для товарного контента. Оправдана для больших каталогов и нескольких каналов продаж: сайт, маркетплейсы, печатный каталог.

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

Как понять, что обмен работает

Обмен нельзя настроить и забыть. Он ломается тихо: истёк пароль пользователя для обмена, переполнился диск, после обновления изменился формат. Минимальный контроль выглядит так:

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

На такую проверку уходит несколько минут, а ошибки ловятся до того, как о них сообщат покупатели.

Чек-лист перед запуском обмена

1. Решено, какие склады и какой остаток показывать на сайте.
2. Решено, какой тип цен выгружается и для каких покупателей.
3. Товары в 1С наведены в порядок: нет дублей, заполнены артикулы и группы.
4. Настроены характеристики и их отображение как торговых предложений.
5. Решено, как сопоставляются покупатели и контрагенты.
6. Определён набор документов, которые создаются из заказа.
7. Настроена передача статусов заказа на сайт.
8. Обмен идёт только изменениями, а не полной выгрузкой каждый раз.
9. Заказ резервирует остаток на сайте до попадания в 1С.
10. Есть журнал обмена и уведомление, если обмен не прошёл.

Типичные ошибки

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

Если обмен уже работает, но тормозит учёт, загляните в нашу статью о том, что проверить, если 1С стала работать медленнее: тяжёлые обмены там одна из частых причин.

Кто за что отвечает

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

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

Коротко

• CommerceML позволяет связать сайт и 1С стандартными средствами: каталог, цены, остатки, заказы.
• Товары связываются по идентификатору 1С, поэтому их не пересоздают, а редактируют.
• Какой остаток показывать на сайте, решает бизнес, и это нужно зафиксировать до настройки.
• Передавайте изменения, а не весь каталог, и резервируйте товар на сайте сразу при заказе.
• За обмен должна отвечать одна команда, которая видит и сайт, и 1С.