1С и учётные системы — FAQ

Сайт, интернет-магазин, B2B-портал или внутренняя система могут обмениваться данными с 1С автоматически.

Обычно для интеграции используют API, HTTP-запросы, веб-сервисы, файлы обмена, промежуточный интеграционный сервис или регламентные задания.

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

Способы обмена и архитектура слоя интеграции разобраны на странице интеграции Laravel с 1С. Рабочий пример двустороннего обмена — в кейсе B2B-портала.

Набор данных зависит от конкретного проекта.

Чаще всего из 1С в Laravel передают товары, категории, артикулы, характеристики, цены, остатки, контрагентов, договоры, персональные скидки, статусы заказов и документы.

Из Laravel в 1С обычно передают новые заказы, состав заказа, данные клиента, адрес доставки, способ оплаты, комментарии, изменения заказа, заявки и регистрационные данные нового контрагента.

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

1С отвечает за цены и остатки, а Laravel — за работу личного кабинета и оформление заказов.

Такой принцип «источника истины» описан в разделе про интеграцию и реализован в B2B-кабинете: цены и остатки из 1С, заказы и интерфейс — на стороне Laravel.

Остатки можно регулярно получать из 1С и обновлять на сайте или в B2B-портале.

Можно передавать общий доступный остаток, остатки по каждому складу, количество в резерве, свободный остаток и ожидаемые поступления.

Склад Минск — 35 шт.
Склад Брест — 12 шт.
В резерве — 10 шт.
Доступно для заказа — 37 шт.

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

В дилерском портале остатки приходят из учётной системы; подробнее про складской контур — в теме FAQ: склад и остатки.

Цены можно автоматически получать из 1С и обновлять на сайте.

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

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

Розничный клиент — 120 BYN.
Дилер — 105 BYN.
VIP-дилер — 98 BYN.

При изменении цены в 1С новые значения автоматически передаются на сайт. Персональные оптовые прайсы — в кейсе B2B-портала; несколько типов цен для дилеров — в портале сантехники.

После оформления заказа сайт формирует структурированный набор данных и передаёт его в 1С.

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

После успешной передачи 1С может вернуть внутренний номер документа, статус, дату обработки или сообщение об ошибке.

Заказ №1548 на сайте → Заказ покупателя №00001258 в 1С.

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

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

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

14:05 — заказ создан.
14:05 — 1С недоступна.
14:10 — повторная попытка.
14:15 — заказ успешно передан.

Пользователь при этом не обязан повторно оформлять заказ. Очереди и отложенная отправка — один из принципов в архитектуре интеграции Laravel + 1С; на практике это заложено в B2B-портале.

Для каждого объекта нужно использовать уникальный идентификатор. Например, для заказа можно хранить ID заказа на сайте, ID документа в 1С, внешний UUID или номер обмена.

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

Заказ №1520 уже связан с документом 1С №000145.

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

Связка идентификаторов между системами — в разделе про интеграцию; похожий механизм при повторных заказах — в FAQ про заказы.

Каждая операция обмена должна иметь понятный статус: ожидает отправки, отправляется, успешно, ошибка, требуется повтор, требует ручной проверки.

Для ошибок желательно сохранять техническое сообщение.

Не найден контрагент.
Неизвестный артикул товара.
Сервер 1С не отвечает.

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

Типовые ошибки обмена и их разбор — на странице интеграции Laravel с 1С; мониторинг статусов заказа — в B2B-кабинете.

Да. Для многих проектов постоянная синхронизация в режиме реального времени вообще не требуется.

Можно обновлять данные каждые 5 или 15 минут, каждый час, несколько раз в день или один раз ночью. Например, цены можно обновлять раз в час, а каталог товаров — один раз в сутки.

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

Регламентный обмен по расписанию — типовой сценарий в интеграции Laravel + 1С; в B2B-портале цены и каталог обновляются по заданному интервалу, а не при каждом запросе.

Частота зависит от скорости продаж и особенностей бизнеса.

Для компании с небольшим количеством заказов может быть достаточно обновления раз в 30–60 минут. Для активного интернет-магазина или B2B-портала может потребоваться обновление каждые 1–5 минут, при каждом изменении остатка или перед подтверждением заказа.

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

Подробнее про складской контур — в FAQ: склад и остатки; пример синхронизации остатков для дилеров — в портале сантехники.

Лучше не связывать товары только по названию. Для сопоставления можно использовать внутренний ID, UUID, артикул 1С, артикул сайта или специальную таблицу соответствий.

Сайт: SHOWER-125 → 1С: 000012568
Сайт: MIXER-44 → 1С: МС-0044

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

Таблица соответствий — стандартный элемент слоя интеграции; в дилерском портале каталог из 1С сопоставляется с карточками на сайте по внутренним кодам.

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

19.09.2026, 12:45 — Заказ №1542 — Laravel → 1С — Статус: успешно

19.09.2026, 12:48 — Товар №882 — 1С → Laravel — Статус: ошибка — Причина: неизвестная категория.

Журнал особенно полезен, если интеграция работает автоматически и выполняет тысячи операций. Логирование обмена описано в архитектуре интеграции; аудит действий по заказу — в FAQ про заказы и заявки.

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

Попытка 1 — ошибка.
Через 5 минут — попытка 2.
Через 15 минут — попытка 3.

После нескольких неудачных попыток операция переводится в статус «Требует проверки». Важно, чтобы повторная отправка не создавала дубль — перед каждым повтором система проверяет идентификатор объекта.

Очереди и политика повторов — в интеграции Laravel + 1С; сценарий недоступности 1С с отложенной отправкой — в B2B-портале.

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

Надёжнее использовать контролируемый интерфейс обмена.

Laravel → API → 1С
или
Laravel → интеграционный сервис → 1С.

Так каждая система остаётся относительно независимой. Рекомендуемые способы обмена — HTTP-сервисы, REST/OData, файловый обмен через очереди — на странице интеграции Laravel с 1С.

Да. Одна веб-система может обмениваться данными сразу с несколькими базами 1С.

Например: Беларусь — отдельная база, Россия — отдельная база, розничные продажи — одна база, оптовые продажи — другая база.

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

Для такого обмена важно заранее определить правила маршрутизации и избежать конфликтов между одинаковыми товарами, клиентами и документами в разных базах. Мультибазовые сценарии обсуждаются в разделе про интеграцию; единый кабинет при разных условиях — в B2B-портале.