Заказы с сайта в 1С руками: какой способ обмена выбрать

Кому и когда это нужно

Ситуация знакомая: менеджер перепечатывает заказ из письма в 1С, покупатель заказал товар, которого на складе уже нет, а цена на сайте старая. Условный пример, цифры придуманы: 40 заказов в день по 4 минуты на ввод дают 160 минут работы менеджера ежедневно, плюс опечатки в количестве и адресе. Растёт число отмен и звонков «где мой заказ». Подробный разбор технической стороны есть в статье про интеграцию сайта с 1С, здесь разбираю выбор способа и вопросы, которые надо решить заранее.

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

Три способа и что у каждого с поддержкой

Первый способ описан в документации 1С для сайтов: в схеме для 1С-Битрикс обмен идёт по формату CommerceML, и инициатор обмена 1С. В типовых конфигурациях для торговли есть механизм обмена с сайтом, какие CMS поддержаны, смотрите у вендора модуля, список не проверял. Второй способ опирается на HTTP-сервисы платформы и стандартный интерфейс OData, оба описаны в документации платформы. Цен не называю, из чего складывается стоимость, написано в статье про цену интеграции по API. Для пробного периода и совсем небольшого каталога третий путь допустим, но потом его обычно заменяют вторым или первым.

Как выбрать и запустить: 6 шагов

1. Выпишите, что нужно: остатки, цены, заказы, статусы. Лишнее вычеркните.
2. Назначьте главную систему по каждому полю: остатки и цены в 1С, тексты и фото обычно на сайте.
3. Выберите единый ключ товара (ниже).
4. Типовая 1С и типовая CMS: начните с CommerceML. Нужны живые остатки или своё правило резерва: API.
5. Сделайте тестовую копию базы и тестовый сайт. На боевой базе первая кривая выгрузка плодит дубли.
6. Прогоните пилот на одной группе товаров, неделю сверяйте остатки вручную, включите журнал обмена и оповещение об ошибке в Telegram.

Вопросы, которые решают до запуска

Ключ товара. Артикул вводят руками, он повторяется и правится. Внутренний идентификатор 1С не меняется при правке артикула, но у пересозданной карточки он будет новым. Сопоставляйте по идентификатору, артикул держите как проверку, оба поля храните на сайте.

Частота. Остатки обновляйте чаще, каталог раз-два в сутки ночью, заказы по событию или раз в несколько минут.

Отказ. Если 1С недоступна, сайт принимает заказ в очередь, а повторная отправка не создаёт второй документ. Для этого у заказа свой ключ.

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

Частичная отгрузка. Отгрузили 2 из 3 позиций: на сайте это «отгружен частично», а не «выполнен». Цены и склады: какой тип цены уходит на сайт и какие склады считаются наличием.

Чек и оплата. Обмен заказами чек не пробивает. По пункту 2 статьи 1.2 54-ФЗ чек при расчёте выдают на бумаге или отправляют на телефон или почту, которые покупатель дал до расчёта; текст статьи я по первоисточнику не открывал, сверьте со своей схемой по статье про онлайн-кассу.

Данные клиентов. Имя, телефон и адрес уходят в 1С: по статье 5 152-ФЗ объём данных должен соответствовать цели. Где хранится база и кто к ней имеет доступ, покажите юристу, общий фон в статье про мифы о 152-ФЗ.

Где ошибаются чаще всего

Разные артикулы в 1С и на сайте: после выгрузки появляются две карточки одного товара.

Обмен в одну сторону: заказы идут в 1С, а статусы и остатки не возвращаются, и покупатель видит «в обработке» неделю.

Нет теста на копии базы: ошибка в сопоставлении цен всплывает у покупателей.

Правки прямо в типовой конфигурации без плана обновления: после обновления 1С обмен ломается. Безопаснее доработки через расширения.

Нет оповещения об ошибке: обмен встал в понедельник, заметили через неделю.

Где здесь поможет автоматизация

В моих проектах палетного учёта есть HTTP-сервис в расширении для 1С:УТ, через который мобильное приложение склада обменивается с базой: вход по токену, ключ операции, чтобы повтор не проводился дважды, версия объекта для конфликтов, коды ошибок. Для остатков между кассой и сайтом и для оптовых заказов из 1С я описывал схемы в отдельных статьях. Готового модуля обмена сайта с 1С по CommerceML как продукта я не заявляю, собираю под вашу базу в рамках автоматизации бизнеса.

Что делаю: настройка и доработка обмена, оповещение об ошибках в Telegram, ежедневная сверка остатков, паспорт обмена с доступами и описанием, как в статье про зависимость от подрядчика. На старте можно не делать двусторонний обмен всего: контрагентов, картинок и описаний хватит вести на одной стороне.

Частые вопросы

Какой способ дешевле на старте?

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

Что будет с обменом при обновлении 1С?

Может сломаться, особенно если правили типовую конфигурацию. Перед обновлением прогоните обмен на копии базы.

Нужно ли сразу обменивать клиентов и картинки?

Нет. Начните с остатков, цен и заказов, остальное добавьте после пилота.

Коротко о главном

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

Хотите, чтобы я связал ваш сайт и 1С: заказы, остатки, цены и контроль ошибок? Напишите мне в Telegram слово «ОБМЕН».