Данные выходят из 1С и возвращаются обратно пятью механизмами: HTTP-сервисы, стандартный интерфейс OData, планы обмена, файловый обмен по расписанию и готовый модуль из маркета. Всё остальное, что вам называют — «интеграция по API», «выгрузка в XML», «коннектор», «шина», — это надстройка над одним из этих пяти. Поэтому первый вопрос к подрядчику звучит не «вы умеете интегрировать 1С», а «каким из пяти механизмов вы это сделаете и почему именно им».
Выбор определяется тремя вещами, и ни одна из них не про технологию. Какая задержка допустима между событием в учёте и его появлением во внешней системе. Что должно произойти, если связь оборвалась посреди передачи. И кто будет сопровождать эту связку через год, когда конфигурацию обновят дважды, а автор кода уйдёт на другой проект. Ответы на эти три вопроса сужают список до одного-двух вариантов ещё до обсуждения цены.
Ниже — разбор каждого механизма: что он делает внутри базы, как ведёт себя при обрыве и при обновлении конфигурации, во что обходится за три года. Расчёты модельные, ставка — 3 500 ₽/час профильного интегратора на сентябрь 2026 года; откуда она берётся, разобрано в материале сколько стоит интеграция 1С.
Пять механизмов и что происходит внутри базы
Порядок в списке — не рейтинг, а движение от простого в разработке к сложному. У каждого механизма своя точка входа: одни работают поверх рабочих данных в момент запроса, другие поднимают собственную служебную структуру и живут независимо от того, кто и когда пришёл за данными.
- 1Стандартный интерфейс OData
Платформенный механизм: в конфигураторе отмечаются объекты, которые публикуются наружу, и внешняя система получает к ним доступ по HTTP как к таблицам. Писать на стороне 1С ничего не нужно — отсюда популярность на старте. Отдаёт объекты ровно так, как они лежат в метаданных, и ничего не считает: доступный остаток и цену по виду цен внешняя система собирает сама из сырых данных.
- 2Файловый обмен по расписанию
Регламентное задание формирует файл — XML, CSV, JSON — и кладёт его в каталог, на FTP или в сетевую папку; приёмник забирает и разбирает. Формат ваш собственный, поэтому обновление конфигурации на нём почти не сказывается. Задержка равна периоду выгрузки: от 15 минут до суток. На этом же принципе построен типовой обмен с сайтом в формате CommerceML — он разобран в опорной статье про интеграцию 1С с сайтом.
- 3Готовый модуль из маркета
Купленное расширение, которое уже умеет связывать вашу конфигурацию с конкретной внешней системой: маркетплейсом, CMS, транспортной компанией. Внутри у него один из четырёх остальных механизмов, чаще HTTP-сервисы. Платите вы не за код, а за то, что автор обязался поддерживать связку при выходе новых релизов.
- 4HTTP-сервисы в расширении конфигурации
Разработчик описывает собственные адреса и пишет код, который на каждый запрос отдаёт готовый ответ — посчитанный, отфильтрованный, в нужном приёмнику формате. Обратное направление такое же: внешняя система вызывает метод приёма заказа, а код внутри проверяет данные, ищет контрагента и создаёт документ. Живёт в расширении — отдельным слоем поверх типовой конфигурации.
- 5Планы обмена
Платформенный механизм, придуманный для распределённых баз и пригодный для любого обмена. Заводится узел — условный адресат, — и платформа сама помечает каждое изменение нужных объектов как предназначенное ему. Пометка снимается только после подтверждения приёма. Единственный из пяти, у которого гарантия доставки встроена в платформу, а не дописана программистом.
| Механизм | Нагрузка на рабочую базу | Задержка | Что при обрыве связи | Риск при обновлении конфигурации | Разработка |
|---|---|---|---|---|---|
| OData | Высокая: выборка идёт по рабочим данным в момент запроса | Секунды на объект, минуты на выборку | Ничего не гарантирует: ни очереди, ни подтверждения приёма | Ломается тихо при переименовании реквизита, о котором не предупредят | 80 000–200 000 ₽ |
| Файловый обмен | Низкая: выгрузка идёт по расписанию, обычно ночью | Период выгрузки: 15 минут — сутки | Ничего не теряется: файл лежит, пока его не забрали | Почти не ломается: формат ваш, а не вендорский | 60 000–150 000 ₽ |
| Готовый модуль | Зависит от внутреннего механизма модуля | От минуты до часа, задаётся автором | Как решил автор модуля; проверяется только опытом | Ждёте обновления модуля; при задержке автора обмен стоит | 30 000–90 000 ₽ настройки плюс подписка |
| HTTP-сервисы | Средняя: код отдаёт готовый ответ, тяжёлые выборки кешируются | 1–30 секунд | Запрос теряется, если у вызывающей стороны нет очереди повторов | Переживает, если код в расширении; ломается, если врезан в типовую | 150 000–400 000 ₽ |
| Планы обмена | Низкая: изменения копятся в служебной таблице регистрации | От 1 минуты | Изменение остаётся зарегистрированным до подтверждения приёма | Переживает: механизм платформенный и не зависит от релизов конфигурации | 250 000–600 000 ₽ |
Колонка про нагрузку в коммерческих предложениях не встречается, а она решает, будет ли база тормозить в первый рабочий час месяца. OData и HTTP-сервисы работают в момент запроса и конкурируют за ресурсы с людьми, которые выписывают документы. Файловый обмен и планы обмена сдвигают тяжёлую часть на своё расписание.
Схема в разрезе. В центре большой прямоугольник «рабочая база 1С» с внутренними зонами «справочники», «документы», «регистры». Снаружи пять входов, каждый подписан: «OData — прямо в рабочие данные, нагрузка высокая», «HTTP-сервис в расширении — через свой код, нагрузка средняя», «Готовый модуль — через механизм автора», «Файловый обмен — в каталог файлов рядом с базой, нагрузка низкая», «План обмена — в служебную таблицу регистрации изменений, нагрузка низкая». Два последних входа нарисованы не внутрь базы, а в отдельные блоки рядом с ней. Чертёжная манера, подписи по-русски.
HTTP-сервисы: цена одного метода в часах
HTTP-сервис — собственный набор адресов, которые понимает только ваша база. Внешней системе не нужно разбираться в метаданных 1С: она вызывает адрес «отдай остатки по складу 3» и получает готовый ответ, где резервы уже вычтены, а товары в отгрузке исключены. Логика остаётся внутри учётной системы, где ей и место.
Объект конфигурации, который публикуется на веб-сервере и отвечает на запросы по фиксированным адресам. У каждого адреса свой код: что принять, что проверить, что вернуть. В отличие от OData отдаёт не сырые таблицы, а результат вашей бизнес-логики — и потому переживает почти любые изменения внутреннего устройства базы.
Трудоёмкость считается по методам, а не по системам целиком. Метод чтения простого справочника — 4–6 часов вместе с постраничной выдачей и авторизацией. Метод, считающий доступный остаток по нескольким складам с учётом резервов, — 10–14 часов. Метод приёма документа самый дорогой: он обязан проверить данные, найти или создать контрагента, отработать повторную отправку по ключу операции и вернуть внятную ошибку. Это 14–18 часов, и экономия здесь возвращается задвоенными документами.
Смету в такой разбивке можно проверить построчно: видно, за что платите, и можно выкинуть направление, которое пока не нужно. Смета из одной строки «интеграция с 1С — 350 000 ₽» выглядит так же, но проверить в ней нечего.
Писать HTTP-сервисы должен разработчик 1С: код живёт внутри конфигурации и подчиняется её правилам. Требование к нему одно — код в расширении, а не в типовой конфигурации. Тогда база остаётся на поддержке вендора и обмен переживает релиз без вмешательства. Врезка в типовую экономит несколько часов на старте и делает каждое обновление отдельным проектом со своей сметой.
OData: удобно на старте, тормоз на объёме
OData включается за час и не требует ни строчки кода на стороне 1С — этим и подкупает. Внешняя система получает доступ к справочникам и документам напрямую. Проблемы начинаются не в первый месяц, а на объёме и на второй год, и они четырёх разных сортов.
- Он отдаёт сырьё, а не ответы. Доступного остатка в базе нет как готового числа: это физический остаток минус резервы, минус товар в отгрузке, минус буфер. Через OData внешняя система вытягивает четыре набора данных и считает сама — логика расчёта дублируется снаружи и однажды разъедется с той, что внутри учёта.
- Он работает по рабочим данным в момент запроса. Выборка идёт порциями, обычно по 1 000 записей, и каждая порция — обращение к базе, где в это время проводят документы. Полная выгрузка каталога на 60 000 позиций — примерно 60 запросов и около 38 минут занятой базы. Тот же каталог HTTP-сервис отдаёт подготовленным набором за 5–7 минут, а план обмена возит только изменения: 400–900 позиций за сутки, то есть 20–40 секунд.
- Он ничего не гарантирует при обрыве. Если связь оборвалась на сороковом запросе из шестидесяти, никто об этом не узнает: 1С отдала что успела, приёмник взял что получил. В журнале будет запись об успехе, в данных — дыра.
- Он ломается тихо. Переименовали реквизит при доработке или обновлении — запрос вернул пустоту. Отличить «товаров нет» от «поле переехало» без отдельной проверки нельзя, и выясняется это по пустому каталогу на витрине.
Горизонтальная столбчатая диаграмма из трёх полос с подписями времени. Полоса 1 «OData: 60 запросов порциями по 1 000 записей — 38 минут» — самая длинная, помечена как «нагрузка на рабочую базу». Полоса 2 «HTTP-сервис под задачу: подготовленный набор — 5–7 минут». Полоса 3 «План обмена: только изменения за сутки, 400–900 позиций — 20–40 секунд» — самая короткая. Подпись под диаграммой: «Модельная база на 60 000 позиций, сентябрь 2026». Чертёжная манера, оси и подписи по-русски.
Если внешняя система ходит за данными в рабочее время, а каталог измеряется десятками тысяч позиций, к концу первого года вы получите жалобы на скорость проведения документов и не сразу свяжете их с обменом. Рабочих обходных путей два: переносить выгрузку на ночную копию базы или заменять OData на механизм, который отдаёт подготовленные данные. Первый вариант стоит около 90 000 ₽ разово и добавляет к задержке сутки, второй — это уже HTTP-сервисы со своей сметой.
Из этого не следует, что OData плох. Он хорошо работает там, где данные читаются редко, объём небольшой, а потеря куска данных ничем не грозит: разовая выгрузка справочника для миграции, ночной сбор витрины для аналитики. Именно так обычно и устроен источник для BI-дашбордов — ночной срез, а не живая база.
Планы обмена: единственный механизм без потерь при разрыве
Планы обмена придуманы для распределённых баз, но механизм универсален и годится для любого обмена, где потеря данных недопустима. Отличие от остальных четырёх в одном: 1С сама помнит, что ещё не доехало до адресата.
План обмена — объект конфигурации со списком узлов-адресатов и составом данных для каждого. Как только объект из этого состава меняется, платформа делает служебную запись: «этот элемент предназначен такому-то узлу». Запись снимается не в момент отправки, а после того, как принимающая сторона подтвердила приём. Пока подтверждения нет, изменение считается недоставленным и уйдёт в следующей попытке.
- 1Менеджер меняет цену у 40 позиций. Платформа регистрирует 40 изменений для узла «CRM» — независимо от того, работает связь в эту секунду.
- 2Обмен формирует сообщение с этими изменениями и отправляет его. Сообщения нумеруются, поэтому приёмник видит, что пришло и в каком порядке.
- 3Связь обрывается на середине. Регистрация не снята, потому что подтверждения не было: данные ждут в служебной таблице.
- 4Через 15 минут связь восстановилась. Обмен отправляет те же 40 изменений заново — не весь справочник и не последние сутки, а именно недоставленное.
- 5Приёмник подтвердил номер сообщения. Только теперь регистрация снимается, и эти позиции перестают участвовать в обмене.
Схема из пяти блоков слева направо со стрелками. Блок 1 «Изменение объекта: 40 позиций». Блок 2 «Таблица регистрации: 40 пометок для узла CRM». Блок 3 «Сообщение обмена с номером». Блок 4 «Приёмник» — от него обратная стрелка вверх с подписью «подтверждение номера сообщения». Блок 5 «Пометки сняты». Отдельной веткой вниз от блока 3 нарисован разрыв провода с подписью «связь оборвалась — пометки остались, уйдут в следующей попытке». Чертёжная манера, подписи по-русски.
За эту гарантию платят дважды. В разработке: нужно описать состав плана, правила регистрации и порядок разрешения конфликтов, когда объект изменили с обеих сторон, — отсюда 250 000–600 000 ₽ и 4–8 недель. И дисциплиной: узлы нельзя множить бесконтрольно, таблицу регистрации надо чистить. Взамен обмен годами не требует ручной сверки, и на этом он окупается.
Если в компании 1С:Розница в магазинах и 1С:УТ в центре, обмен между ними почти наверняка уже построен на планах обмена — так устроена типовая схема распределённой базы. Это важно знать до проектирования: механизм у вас уже есть, люди с ним работают, и внешнюю систему часто дешевле подключить ещё одним узлом, чем строить рядом второй контур обмена другого типа.
Файловый обмен и готовые модули: где они до сих пор уместны
Файловый обмен выглядит архаично и остаётся рабочим решением в четырёх случаях: вторая сторона не умеет ничего, кроме файла; данные нужны раз в сутки; нет прямого сетевого доступа к базе; важнее всего, чтобы ничего не потерялось. Файл — самый честный буфер: он лежит и ждёт, пока его заберут, а если не забрали, это видно по каталогу без всякого мониторинга.
Реальная задержка у него не «раз в час», как написано в задании, а период выгрузки плюс период разбора плюс повторная попытка при сбое. Задание раз в 15 минут на практике означает отставание на 20–40 минут. Для прайсов поставщиков, банковских выписок и ночной аналитики это нормально; для остатков в интернет-магазине — нет.
Готовый модуль — единственный способ получить связку за неделю и 30 000–90 000 ₽ вместо трёх месяцев. Платите вы за две вещи: за написанный код и за обязательство автора выпускать обновления под новые релизы. Вторая дороже первой, и именно она однажды заканчивается.
Типовая ситуация: модуль поставляется закрытым, исходников у вас нет, площадка поменяла формат, а автор не отвечает третий месяц. Обмен стоит, и починить его нельзя даже за деньги. До покупки выясните три вещи: поставляется ли модуль с открытым кодом, есть ли право на самостоятельную доработку и как быстро выходили обновления после предыдущих релизов. Если ответов нет, закладывайте в план запасной вариант на HTTP-сервисах и считайте подписку не платой за удобство, а арендой рабочего процесса.
Как выбор зависит от конфигурации
Конфигурация определяет не только то, какие данные вообще есть в базе, но и то, какой механизм в ней уже развёрнут. Половина проектов начинается с открытия, что нужный обмен частично существует и его дешевле расширить, чем построить рядом второй.
| Конфигурация | Что уже есть штатно | Обычно правильный механизм | Что учесть |
|---|---|---|---|
| 1С:Бухгалтерия предприятия 3.0 | Банк-клиент, 1С-ЭДО, типовой обмен с УТ, УНФ и Розницей | Файловый обмен или OData на чтение | Товарного контура для витрины нет. Писать документы извне опасно: проведение и закрытие периода зависят от учётной политики |
| 1С:Управление нашей фирмой | Обмен с сайтом в формате CommerceML, обмен с Бухгалтерией | Готовый модуль или HTTP-сервисы | План обмена почти всегда избыточен: объёмы малы, а гарантия доставки нужна редко |
| 1С:Управление торговлей 11 | Обмен с сайтом, с Бухгалтерией, с Розницей, бесшовная связка с Документооборотом | HTTP-сервисы в расширении | Основной рабочий вариант для CRM и маркетплейсов. Резервы обязательно учитывать в доступном остатке |
| 1С:Комплексная автоматизация | То же, что в УТ, плюс казначейство, бюджеты, кадры | HTTP-сервисы, на объёме — планы обмена | Объектов больше, обследование длиннее на 1–3 недели: дольше согласуется, чей остаток считать доступным |
| 1С:ERP | Полный набор типовых обменов плюс производственный контур | Планы обмена | Нагрузка критична: OData на рабочую базу здесь не пускают. Любая связка проектируется с очередью и подтверждением приёма |
| 1С:Розница | Распределённая база с УТ, обмен с Бухгалтерией, кассовое оборудование | План обмена, узел в существующей схеме | Механизм уже развёрнут. Писать в неё извне почти никогда не нужно: центральный узел — УТ, туда и подключаются |
| 1С:Документооборот | Бесшовная интеграция с Бухгалтерией, УТ, КА и ERP, собственные веб-сервисы | Штатная бесшовная связка, для внешних систем — HTTP-сервисы | Интеграция идёт по договорам, задачам и маршрутам, а не по товарам. Товарных объектов в ней нет |
Отдельная строка — доработанная конфигурация, снятая с поддержки. Она не запрещает ни один из пяти механизмов, но удорожает обследование на 20–40 %: прежде чем отдавать наружу остаток, нужно понять, что переопределено в проведении документов. Это не повод менять учётную систему — мы разбирали, почему автоматизация почти никогда не требует замены 1С, — а повод завести в смете строку «разбор доработок».
Три года владения: три способа рядом
Сравнивать механизмы по цене разработки бессмысленно: она составляет от четверти до половины трёхлетних расходов. Ниже — одна задача, посчитанная тремя способами. Вводные: оптовик на 1С:УТ 11, обмен с CRM, 12 000 позиций, около 900 документов в месяц, ставка 3 500 ₽/час, ручной разбор расхождений сотрудником по 900 ₽/час.
| Статья расходов за 36 месяцев | OData | HTTP-сервисы | План обмена |
|---|---|---|---|
| Разработка | 120 000 ₽ | 346 500 ₽ | 520 000 ₽ |
| Перевод выгрузки на ночную копию базы | 90 000 ₽ | не нужен | не нужен |
| Поддержка | 12 000 ₽/мес — 432 000 ₽ | 15 000 ₽/мес — 540 000 ₽ | 9 000 ₽/мес — 324 000 ₽ |
| Правки после обновлений конфигурации | 8 событий × 6 ч — 168 000 ₽ | 6 событий × 3 ч — 63 000 ₽ | 6 событий × 2 ч — 42 000 ₽ |
| Ручной разбор расхождений | 2 ч в неделю — 280 800 ₽ | 0,5 ч в неделю — 70 200 ₽ | не требуется |
| Итого за три года | 1 090 800 ₽ | 1 019 700 ₽ | 886 000 ₽ |
Арифметика проверяется на калькуляторе. Разовые вложения в план обмена — 520 000 ₽, у OData с учётом переезда на ночную копию — 210 000 ₽, разница 310 000 ₽. Ежемесячно план обмена обходится в 10 167 ₽, OData — в 24 467 ₽, разница 14 300 ₽. Делим одно на другое и получаем 22-й месяц эксплуатации: до него дешевле OData, после — план обмена. Если горизонт вашего решения меньше двух лет, простой механизм честно выигрывает. Если система живёт пять лет, выбор в пользу OData обходится в 548 000 ₽ переплаты: те же 14 300 ₽ разницы за 60 месяцев минус 310 000 ₽ сэкономленных на старте.
Линейный график за 36 месяцев, три линии накопленных расходов. Линия «OData» стартует с 210 000 ₽ и растёт круче всех, к 36-му месяцу — 1 090 800 ₽. Линия «HTTP-сервисы» стартует с 346 500 ₽, к 36-му месяцу — 1 019 700 ₽. Линия «План обмена» стартует с 520 000 ₽ и растёт положе всех, к 36-му месяцу — 886 000 ₽. Точка пересечения линий OData и плана обмена подписана «22-й месяц» и выделена. Оси: месяцы эксплуатации и рубли. Чертёжная манера, подписи по-русски.
Механизм обмена выбирают не по цене разработки, а по тому, сколько раз в год кто-то будет вручную сверять две базы.
Когда не нужен ни один из пяти способов
Обмен — это не бесплатная функция, а система, у которой есть владелец, поддержка и стоимость простоя. В четырёх ситуациях его правильнее не строить вовсе.
- Меньше 30 документов в месяц в каждую сторону. Ручной перенос заказа — около трёх минут, это 35 ₽ по ставке 700 ₽/час. Тридцать документов дают 1 050 ₽ в месяц против 9 000–15 000 ₽ поддержки самого скромного обмена.
- Данные меняются раз в квартал. Каталогу из 200 позиций с годовым прайсом механизм доставки изменений не нужен: выгрузка вручную занимает 20 минут четыре раза в год.
- Нет доступа к конфигуратору. На тарифах облачной 1С без права менять конфигурацию расширение не опубликовать, и половина механизмов отпадает физически. Что доступно в облаке, разобрано в статье про облачную 1С и свой сервер.
- Нет владельца справочников. Если не решено, где заводится новый товар и новый контрагент, любой обмен начнёт размножать дубли на второй неделе. Сначала договорённость, потом код.
И последнее, что важнее выбора механизма. Любой из пяти способов надёжен ровно настолько, насколько за ним следят. Обмен редко падает громко: он тихо перестаёт возить часть данных, и узнают об этом через неделю от клиента. Поэтому строка мониторинга в смете — часть поставки, а не роскошь; что именно снимать, описано на странице поддержки. Механизм за 600 000 ₽ без единого датчика ведёт себя не лучше файловой выгрузки за 60 000 ₽.
