Интеграция сайта или веб-системы на Laravel с 1С позволяет убрать ручной перенос данных между сайтом и учётной системой. Товары, цены и остатки могут автоматически передаваться из 1С на сайт, новые заказы — уходить с сайта в 1С, а изменившиеся статусы заказов — возвращаться обратно в личный кабинет клиента.
Универсального способа интеграции не существует. В зависимости от конфигурации 1С, объёма данных и требований проекта можно использовать HTTP-сервисы, REST/OData, JSON, XML, CommerceML или файловый обмен. Для Laravel-проекта интеграцию обычно имеет смысл выносить в отдельный слой приложения и выполнять тяжёлые операции через очереди. Ориентиры по бюджету Laravel — на странице услуг.
Состав обмена зависит от конкретного бизнеса. Чаще всего интеграция затрагивает товары, остатки, цены, заказы, клиентов и документы. Для интернет-магазина на Laravel 1С часто остаётся основной системой учёта товаров, а Laravel отвечает за отображение каталога и пользовательскую часть сайта.
Важный принцип: необходимо заранее определить, какая система является источником истины для каждого типа данных. Например: 1С → название, артикул, цена, остаток; Laravel → SEO-текст, фотографии, URL, метатеги. Иначе менеджер меняет данные на сайте, а следующая синхронизация из 1С перезаписывает изменения.
Из 1С можно получать:
Если проект — не типовой магазин на CMS, а B2B-кабинет с индивидуальными условиями, обычно выбирают Laravel вместо WordPress. Пример реализации — кейс B2B с интеграцией 1С.
Одна из самых частых задач интеграции — автоматическое обновление складских остатков. 1С передаёт остатки по складам, Laravel показывает наличие товара, разрешает или запрещает заказ и рассчитывает доступное количество.
1С
→ склад Минск: 12 шт.
→ склад Гомель: 4 шт.
→ склад Брест: 0 шт.
↓
Laravel
→ показывает наличие
→ разрешает или запрещает заказ
→ рассчитывает доступное количество
Можно передавать как общий остаток, так и остатки по каждому складу. Если данные меняются часто, необязательно полностью синхронизировать весь каталог — обычно эффективнее передавать только изменившиеся позиции.
Из 1С можно получать несколько типов цен: розничную, оптовую, дилерскую, акционную, индивидуальную, цену для определённой группы клиентов. Это особенно полезно для B2B-систем.
Например, два авторизованных клиента могут видеть разные цены на один и тот же товар: обычный покупатель — 120 BYN, дилер — 105 BYN, оптовый клиент — 98 BYN. Laravel определяет пользователя, а интеграция с 1С позволяет получить или обновить соответствующий тип цены.
Интеграция может работать в обратном направлении: клиент оформляет заказ на сайте, Laravel передаёт его через API или очередь в 1С, где создаётся заказ покупателя. После обработки менеджером статус возвращается в личный кабинет — например, «Заказ готов к отгрузке».
Клиент оформляет заказ
↓
Laravel
↓
API / очередь обмена
↓
1С
↓
создаётся заказ покупателя
Официальный протокол обмена 1С с интернет-магазинами предусматривает как публикацию каталога, цен и остатков на сайте, так и передачу заказов с сайта в 1С и последующую синхронизацию их параметров.
В B2B-проектах интеграция часто затрагивает не только товары, но и клиентов. Можно синхронизировать физических и юридических лиц, контрагентов, договоры, индивидуальные условия, скидки, задолженность, лимиты, менеджеров и реквизиты организации.
После авторизации клиент может увидеть персональную скидку, доступный кредитный лимит, задолженность и закреплённого менеджера. Сайт превращается не просто в интернет-магазин, а в полноценный B2B-кабинет, связанный с учётной системой компании.
Более сложная интеграция может включать обмен документами: счетами, накладными, актами, заказами, договорами, реализациями, платёжными документами. Клиент может зайти в личный кабинет и скачать сформированный для него счёт без обращения к менеджеру.
Нельзя сказать, что REST API всегда лучше CommerceML или что XML обязательно нужно заменить JSON. Способ обмена выбирается исходя из конкретной задачи и существующей конфигурации 1С. Сравнение с готовыми CMS — в материале Laravel vs Битрикс и OpenCart.
Для нового индивидуального проекта это часто один из наиболее удобных вариантов. В 1С создаётся HTTP-сервис с необходимыми методами — Laravel отправляет запрос и получает данные в JSON.
GET /api/products GET /api/stocks GET /api/prices POST /api/orders
Подходит, если создаётся новый Laravel-проект, можно дорабатывать конфигурацию 1С и нужна индивидуальная бизнес-логика с двусторонним обменом.
В платформе 1С существует стандартный REST-интерфейс на базе OData. Через HTTP можно получать и изменять данные, ответы передаются в JSON. Это позволяет подключать Laravel к данным 1С без разработки отдельного API для каждой простой операции.
Но открывать наружу большое количество внутренних объектов 1С только ради удобства интеграции не всегда оправданно. Для сложной бизнес-логики отдельный контролируемый HTTP API зачастую получается понятнее.
CommerceML — стандарт электронного обмена коммерческой информацией для обмена между учётными и торговыми системами. Используется для передачи каталогов, товаров, цен, остатков, коммерческих предложений, заказов и документов.
Имеет смысл, если в существующей 1С уже настроена стандартная выгрузка для сайта. Для новой индивидуальной B2B-системы REST/HTTP + JSON иногда оказывается удобнее, но автоматически отказываться от CommerceML только потому, что это XML, не стоит.
Laravel и 1С могут обмениваться собственными структурами данных. JSON удобен при API-интеграциях, XML — при работе с существующими механизмами 1С и CommerceML.
Если 1С находится во внутренней сети и её нельзя напрямую опубликовать в интернете, возможна схема: 1С → XML/JSON/CSV → защищённое хранилище → Laravel. Такой вариант выглядит менее современно, чем REST API, но иногда это наиболее надёжное и экономически оправданное решение.
| Задача | Обычно стоит рассмотреть |
|---|---|
| Новый индивидуальный B2B-кабинет | HTTP API / JSON |
| Интернет-магазин со стандартным обменом 1С | CommerceML |
| Простое получение объектов 1С | REST / OData |
| Старая конфигурация без удобного API | XML / файлы |
| Сложная двусторонняя бизнес-логика | собственный HTTP API |
| Изолированная 1С во внутренней сети | промежуточный или файловый обмен |
Это не жёсткое правило. Перед разработкой необходимо посмотреть конкретную конфигурацию 1С и понять, какие возможности в ней уже реализованы.
Это один из первых вопросов, который нужно решить до начала разработки.
1С ↓ Товары, цены, остатки ↓ Laravel
Laravel только получает информацию. Это сравнительно простой вариант.
1С → товары / цены / остатки → Laravel Laravel → заказы / клиенты → 1С 1С → статусы заказов → Laravel
Необходимо продумать идентификаторы объектов, конфликты данных, повторную отправку, обработку ошибок, очерёдность операций, защиту от дублирования и журнал обмена.
Для среднего Laravel-проекта схема может выглядеть так:
1С
│
HTTP / JSON
│
▼
Integration API
│
▼
Laravel
│
Queue / Jobs
┌──────┼───────┐
▼ ▼ ▼
товары цены остатки
│ │ │
└──────┼───────┘
▼
Database
│
┌───────┴────────┐
▼ ▼
Сайт B2B-кабинет
Обратный поток использует ту же инфраструктуру: новый заказ → Laravel → Queue → Integration Service → 1С. Такой подход позволяет отделить работу пользователя с сайтом от работы интеграции. Подробнее о разработке на фреймворке — в услугах Laravel.
Представим, что из 1С необходимо обновить 40 000 товаров. Плохой вариант — получить все товары и обновить все записи внутри одного HTTP-запроса пользователя. Пользовательский запрос может выполняться слишком долго или завершиться ошибкой.
Лучше разбить обработку на отдельные задачи: запрос синхронизации → получение данных → Queue → пакетная обработка → Database. Laravel имеет встроенную систему очередей, включая механизмы повторных попыток, ограничения параллельного выполнения и обработки failed jobs. Это особенно важно при интеграции с внешней системой, доступность которой Laravel не контролирует.
Это нормальная ситуация, которую нужно предусмотреть архитектурно. Laravel отправляет заказ в 1С, но 1С временно недоступна. Неправильный вариант — «Ошибка. Заказ потерян». Правильнее: заказ создан на сайте → отправка в очередь → попытка передать в 1С → при ошибке повтор через определённое время → успешная доставка после восстановления.
HTTP Client Laravel поддерживает автоматические повторные попытки запроса с управлением количеством попыток и задержками. После превышения допустимого количества попыток задача может быть помещена в список failed jobs для последующего анализа или повторного запуска.
Допустим, Laravel отправил POST /orders, 1С создала заказ №12345, но ответ не дошёл до Laravel из-за сетевой ошибки. Laravel считает операцию неуспешной и повторяет запрос. Если интеграция спроектирована неправильно, в 1С появляются два заказа, хотя пользователь оформил только один.
Поэтому критические операции желательно проектировать как идемпотентные. Laravel передаёт собственный уникальный идентификатор (external_id), а 1С перед созданием заказа проверяет, существует ли заказ с таким идентификатором. Если существует — новый объект не создаётся.
Интеграция без журнала обмена становится дорогой в поддержке Laravel-проекта. Когда менеджер спрашивает «Почему заказ 1845 не появился в 1С?», у разработчика должен быть способ это проверить.
Дата: 14.08.2026 09:32 Направление: Laravel → 1С Операция: create_order Объект: order #1845 Статус: error HTTP: 500 Попытка: 2 / 5 Ошибка: 1C service unavailable
Для критичных интеграций также полезно видеть время последней успешной синхронизации, количество обработанных объектов, количество ошибок, задачи в очереди, failed jobs и среднее время выполнения.
На небольшом магазине можно периодически получить все товары. Если каталог содержит десятки или сотни тысяч позиций, полная синхронизация становится неэффективной. Лучше предусмотреть:
updated_at > last_syncДопустим, есть B2B-магазин строительных материалов. В 1С — 35 000 товаров, 4 склада, 5 типов цен, клиенты, договоры и заказы. На Laravel работает личный кабинет дилера. Подробности реализации — в кейсе B2B платформы с 1С.
Товары → характеристики → цены → остатки → контрагенты → договоры
Новый заказ → состав → контрагент → адрес доставки → комментарий
Номер заказа → статус → сумма → документы
В результате клиент самостоятельно видит актуальные данные, а менеджерам не приходится вручную переносить заказы с сайта.
API 1С не стоит просто публиковать в интернете без ограничений. В зависимости от инфраструктуры проекта могут использоваться HTTPS, токены доступа, отдельный технический пользователь, ограниченные права, VPN, whitelist IP, журналирование запросов, ограничение частоты запросов и отдельная интеграционная точка доступа.
Laravel имеет встроенные механизмы rate limiting. API лучше отдавать только те данные и операции, которые действительно нужны сайту. Если Laravel необходимо получать остатки товаров, ему не требуется полный доступ ко всей информационной базе 1С.
В Laravel товар имеет ID = 174, в 1С — ID = 9385. Если связь между ними не зафиксирована, синхронизация быстро превращается в проблему. Обычно сохраняют внешний идентификатор 1С отдельно.
Если изменился один остаток, нет смысла повторно импортировать весь каталог.
Пользователь не должен ждать, пока Laravel закончит тяжёлый обмен с 1С. Для этого лучше использовать фоновые задачи и очереди.
Любая внешняя система периодически может быть недоступна. Ошибка связи не должна автоматически означать потерю данных.
Особенно опасно для заказов, клиентов, платежей и документов.
Через несколько месяцев невозможно понять, почему именно этот товар не обновился.
Запросы к 1С лучше не размещать непосредственно в контроллерах каталога, корзины или личного кабинета. Интеграцию стоит вынести в отдельный слой:
app/
Integrations/
OneC/
OneCClient
ProductSync
PriceSync
StockSync
OrderExporter
CustomerImporter
Конкретная структура зависит от архитектуры проекта, но смысл один: интеграция должна быть отделена от основной бизнес-логики.
Стоимость зависит не столько от самого факта использования Laravel и 1С, сколько от количества объектов и сложности обмена. Для предварительной оценки полезнее считать объём в часах. Общие ориентиры по проектам — в материале сколько стоит сайт на Laravel.
| Работа | Расчётный объём |
|---|---|
| Анализ конфигурации и проектирование | 6–16 часов |
| Товары | 12–30 часов |
| Цены и остатки | 10–24 часа |
| Заказы | 16–32 часа |
| Клиенты / контрагенты | 12–30 часов |
| Очереди и повторные попытки | 8–20 часов |
| Логирование | 6–16 часов |
| Тестирование | 12–30 часов |
Это не готовый прайс, а пример того, как может рассчитываться интеграция. Простая односторонняя выгрузка товаров и цен и полноценный B2B-кабинет с двусторонним обменом — принципиально разные проекты.
Типовая конфигурация с уже существующими механизмами обмена может существенно упростить разработку. Сильно доработанная 1С, наоборот, требует предварительного изучения.
Передавать только товары проще, чем одновременно синхронизировать товары, цены, остатки, клиентов, договоры, заказы и документы.
Односторонняя схема обычно проще двусторонней.
5 000 и 500 000 товаров предъявляют разные требования к архитектуре. Раз в сутки и практически в реальном времени — разные задачи.
Иногда основная сложность находится не в Laravel, а в старой доработанной конфигурации 1С. Перед выбором исполнителя полезен чек-лист — в материале как выбрать Laravel-разработчика.
Для предварительной оценки необязательно сразу писать большое техническое задание. Достаточно ответить на несколько вопросов.
После этого уже можно выбирать архитектуру и оценить ориентировочный объём разработки.
Индивидуальные цены, остатки, договор, задолженность, история заказов, документы.
Несколько складов, типов цен, разные правила доставки, персональные скидки, большие каталоги.
Персональные условия для каждого контрагента.
Laravel может выступать промежуточным API-слоем между 1С и внешними клиентами.
Иногда достаточно стандартного обмена: небольшой интернет-магазин, один тип цены, один склад, нет B2B-функций, используются типовые механизмы CMS, достаточно выгружать товары и получать заказы. В таком проекте разработка большого индивидуального API может быть неоправданной.
Задача разработчика — не сделать интеграцию максимально сложной, а выбрать минимальное решение, которое надёжно закрывает бизнес-задачу. Когда CMS достаточно — см. когда Laravel не нужен, Laravel или WordPress и Laravel vs Битрикс и OpenCart.
Интеграция Laravel с 1С может автоматизировать практически весь обмен между веб-системой и внутренним учётом: товары, цены, остатки → Laravel → заказы, клиенты → 1С.
Для новой системы чаще всего стоит рассматривать HTTP API и JSON, для существующих интернет-магазинов может быть рационально использовать CommerceML, а в некоторых проектах вполне оправдан файловый обмен. Выбор технологии должен начинаться с анализа существующей конфигурации, а не с заранее выбранного протокола.
Со стороны Laravel надёжная интеграция обычно включает не только отправку HTTP-запросов, но и очереди, повторные попытки, контроль дублирования, логирование и обработку ошибок.
Когда real-time эксплуатация не укладывается в ERP, Laravel может стать узким операционным слоем поверх 1С — пример в кейсе узкого слоя над учётной системой для сети парковок.
HTTP-сервисы, REST/OData, CommerceML, собственные XML/JSON-структуры и файловый обмен. Выбор зависит от конфигурации 1С, направления обмена и требований к архитектуре.
CommerceML рационален, если в 1С уже настроен стандартный обмен с сайтом. Для нового B2B-кабинета с индивидуальной логикой чаще удобнее собственный HTTP API и JSON.
Чтобы тяжёлые операции — обновление большого каталога, отправка заказов — не выполнялись внутри HTTP-запроса пользователя. Очереди позволяют обрабатывать данные пакетами, повторять попытки и не блокировать сайт.
Критические операции проектируют как идемпотентные: Laravel передаёт уникальный external_id, а 1С проверяет его перед созданием объекта. Повторный запрос с тем же идентификатором не создаёт дубликат.
Зависит от количества объектов, направления обмена и сложности конфигурации 1С. Простая выгрузка товаров и цен — одна задача, полноценный B2B-кабинет с двусторонним обменом — другая. Ориентиры по часам — в таблице выше и в материале сколько стоит сайт на Laravel.
Когда бизнес-процессы не укладываются в типовой интернет-магазин: B2B-кабинет, индивидуальные цены, несколько складов, сложный checkout, обмен документами. Пример — кейс B2B с 1С.
Для предварительной оценки не обязательно готовить подробное ТЗ. Достаточно прислать конфигурацию 1С, список данных для обмена, примерный объём каталога, требуемую частоту обновления и описание существующего сайта или веб-системы.