Интеграция сайта с 1С: четыре способа и их последствия

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

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

Четыре рабочие схемы

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

Промежуточная база на практике

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

export async function POST(request: Request) {
  const signature = request.headers.get("x-exchange-signature")
  const body = await request.text()

  if (!verifySignature(body, signature)) {
    return new Response("Подпись не совпадает", { status: 401 })
  }

  // Сначала фиксируем сырую выгрузку: если разбор упадёт,
  // данные не потеряются и обмен можно повторить без 1С
  const batch = await db.insert(exchangeBatches).values({
    payload: body,
    source: "1c",
    status: "received",
  }).returning({ id: exchangeBatches.id })

  await queue.enqueue("exchange.process", { batchId: batch[0].id })

  // 1С получает быстрый ответ и не держит соединение
  return Response.json({ accepted: true, batchId: batch[0].id })
}

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

Что ломается чаще всего

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

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

Как выбрать схему

1. 01Меньше 500 товаров и заказов до десяти в день — файловый обмен по расписанию
2. 02Магазин с типовой конфигурацией — CommerceML, его поддерживают обе стороны
3. 03Нужны данные о клиенте в реальном времени, например баланс — HTTP-сервисы с кэшем и лимитом запросов
4. 04Заметный трафик, акции, несколько каналов продаж — промежуточная база с очередью