# Интеграция интернет-магазина с 1С: шесть граблей, на которые наступают все

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

Адрес: https://egerpro.ru/blog/integraciya-magazina-s-1c/
Обновлено: 2026-08-24

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

## 1. Полная выгрузка вместо изменений

Типовой обмен по расписанию выгружает весь каталог целиком. На 300 товарах это незаметно, на 40 000 — база сайта встаёт на десять минут каждый час.

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

## 2. Остатки обновляются реже, чем покупают

Если остатки приходят раз в час, а товар заканчивается за пятнадцать минут, клиент оформит заказ на то, чего нет. Дальше — звонок менеджера с извинениями.

Мы разделяем потоки: каталог и описания едут по расписанию, остатки и цены — отдельным лёгким запросом каждые пять минут. Данных мало, нагрузки почти нет.

Проверка на берегу

Спросите у клиента, сколько времени товар может числиться в наличии, если его уже нет. Ответ «нисколько» означает, что нужен резерв при добавлении в корзину, а не только частый обмен.

## 3. Товар в 1С один, а на сайте два

Сопоставление по названию или артикулу рано или поздно ломается: менеджер поправил название, обмен создал новый товар. Старый остался в поиске и в индексе Яндекса.

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

```
// Сопоставление только по идентификатору 1С
$product = get_posts([
  'post_type'  => 'product',
  'meta_key'   => '_1c_guid',
  'meta_value' => $item['guid'],
  'numberposts' => 1,
]);

// Название могло измениться — это не повод создавать новый товар
if ($product) {
  update_product($product[0]->ID, $item);
} else {
  create_product($item);
}
```

## 4. Заказ ушёл в 1С дважды

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

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

## 5. Статусы заказа не совпадают

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

Таблицу соответствия согласовываем с клиентом до начала работ и фиксируем в техническом задании — потом её никто не помнит.

## 6. Никто не смотрит, что обмен упал

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

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

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

## Сколько это занимает

## Как выбрать направление обмена

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

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

Отдельно стоит договориться про удаление. Товар пропал из выгрузки — это снятие с продажи или сбой обмена? Мы никогда не удаляем автоматически: позиция скрывается и попадает в отчёт, который человек просматривает. Один раз спасённый от удаления каталог окупает эту осторожность.

## Что делать, когда 1С недоступна

Учётная система не работает круглосуточно: обновления, закрытие месяца, перезагрузки. Если сайт при недоступности 1С отдаёт ошибку в корзине, вы теряете заказы в самый неподходящий момент.

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

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

**Как часто должен идти обмен?**

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

**Нужен ли отдельный сервер для обмена?**

Обычно нет. Нужен доступ к 1С снаружи — через [веб-сервис](https://egerpro.ru/uslugi/veb-servisy/) или защищённый канал — и договорённость с администратором о времени регламентных операций. Отдельный сервер оправдан при больших объёмах, когда выгрузка мешает работе бухгалтерии.

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