Интеграция с 1С

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

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

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

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

Частоту выбирают по типу данных. Первая полная выгрузка каталога занимает больше всего времени, дальше передаются только изменения. Цены и остатки обычно обновляются раз в несколько часов, заказы уходят сразу или с коротким интервалом. Если тот же товар продаётся в обычном магазине и запас небольшой, обмен остатками стоит сделать чаще, чтобы сайт не продавал то, чего уже нет.

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

Вторая тема - НДС. В 1С может быть несколько типов цен, с налогом и без. В интернет-магазине частный покупатель должен видеть конечную цену с НДС, который в Эстонии с июля 2025 года составляет 24%. Нужно точно определить, какой тип цен уходит на сайт и кто добавляет налог: 1С или магазин. Иначе цена окажется либо с двойным налогом, либо без него.

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

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

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

Если учёт ведётся не в 1С, а в одной из эстонских бухгалтерских программ, например Merit Aktiva, описанный здесь обмен CommerceML не подойдёт. Там интеграция строится через интерфейсы самой программы, объём и цена считаются отдельно. Напишите, чем пользуетесь, и мы скажем, что возможно.