Строка «есть коннектор к 1С» в описании площадки не означает почти ничего. 1С — не облачный сервис с одним публичным адресом, а платформа, на которой развёрнута ваша конкретная база, обычно внутри локальной сети и почти всегда доработанная. Поэтому связка конструктора с 1С — это два независимых решения: как площадка физически достучится до базы и какой механизм обмена использовать. Перепутать их порядок нельзя: выбор механизма без ответа на первый вопрос переделывается целиком.
Механизмов, применимых для конструктора, четыре: стандартный интерфейс OData, собственный HTTP-сервис, файловый обмен по расписанию и промежуточная база. В модельных сметах это 82 000, 212 000, 92 000 и 150 000 ₽ соответственно, а сроки — от полутора до пяти недель. Разброс задаёт не сложность данных, а требуемая задержка и то, что должно происходить, когда связь оборвалась.
Отдельно отметим то, чего в этом списке нет. Планы обмена — штатный и самый надёжный механизм платформы — здесь не применимы: узлом плана обмена может быть другая база 1С, а не конструктор сценариев. Полный разбор пяти механизмов со стороны самой платформы у нас есть отдельно, в материале про способы обмена с 1С; здесь мы смотрим на ту же задачу со стороны конструктора.
Первый вопрос: как площадка вообще увидит вашу базу
Облачный конструктор живёт в интернете, ваша 1С — в локальной сети за маршрутизатором. Между ними нет пути по умолчанию, и это не техническая деталь для системного администратора, а развилка, которая определяет и бюджет, и распределение ответственности. Вариантов три.
| Вариант | Что делается | Что в нём хорошо | Чем платите |
|---|---|---|---|
| Публикация через обратный прокси | Веб-сервер публикует базу наружу, доступ ограничен списком адресов площадки и отдельным сертификатом | Быстро, ничего не надо разворачивать дополнительно | Учётная база становится доступна из интернета: нужны список адресов, журнал обращений и регулярный пересмотр |
| Канал между сетями | Между офисной сетью и площадкой поднимается защищённый канал, база наружу не публикуется | База остаётся во внутренней сети, поверхность атаки минимальна | Требует администратора и работает не со всеми облачными площадками |
| Конструктор внутри периметра | Своя установка конструктора на сервере рядом с базой, наружу не смотрит ничего | Ни один запрос к 1С не выходит в интернет; закрывает вопрос локализации данных | Своя установка и её обслуживание — отдельная статья расходов |
Третий вариант в России выбирают чаще двух первых, и причина не в цене, а в персональных данных: через сценарии проходят имена, телефоны и адреса клиентов. Что своя установка закрывает по закону, а что нет, мы посчитали в материале про n8n на своём сервере. Если 1С у вас уже арендованная в облаке, развилка выглядит иначе и упирается в то, какой доступ даёт провайдер, — этот случай разобран в материале про облачную 1С и доступ к данным.
Карта связей систем в три горизонтальные полосы. Общие узлы во всех полосах: слева «Конструктор сценариев», справа «Сервер 1С и база», между ними пунктирная вертикаль «граница локальной сети». Полоса 1 «Публикация через обратный прокси»: конструктор → узел «Веб-сервер, отбор по списку адресов» → база; подпись на стрелке «HTTPS, отдельный сертификат». Полоса 2 «Канал между сетями»: конструктор → узел «Защищённый канал» → база; подпись «база наружу не публикуется». Полоса 3 «Конструктор внутри периметра»: узлы «Конструктор» и «База» оба справа от пунктира, стрелка между ними короткая; подпись «ни один запрос не выходит в интернет». Справа от каждой полосы столбец «чем платите»: «база доступна из интернета», «нужен администратор», «своя установка и её обслуживание». Чертёжный стиль, подписи по-русски.
Четыре механизма и что каждый требует от базы
Механизмы различаются не «удобством», а тремя вещами: трогают ли они конфигурацию, какую нагрузку создают и что происходит при обрыве связи. Последний пункт решает чаще всего, потому что обрыв случается не «если», а «когда».
- 1OData: стандартный интерфейс платформы
Включается в самой 1С без единой строки кода: публикуется база, отмечаются объекты, доступные наружу. Конструктор читает справочники и документы напрямую и умеет записывать. Плюс — скорость запуска: полторы недели от начала до приёмки. Минус — интерфейс отдаёт объекты так, как они устроены внутри 1С, поэтому вся бизнес-логика уезжает в сценарий, а каждый запрос выполняется на боевой базе. Механизм хорош для чтения и плох для записи документов со сложным проведением.
- 2Собственный HTTP-сервис: свои методы под свои задачи
Внутри 1С пишутся методы — «отдай заказы за период», «создай реализацию», «верни остаток по складу», — каждый со своей проверкой и своим ответом. Это единственный механизм, в котором логика остаётся на стороне учёта: сценарий говорит, что нужно, а не как это устроено в базе. Один метод стоит от 4 до 18 часов работы; пять типовых методов — около 52 часов вместе с публикацией и журналом обмена.
- 3Файловый обмен по расписанию: самый недооценённый вариант
Регламентное задание 1С кладёт файл в каталог, конструктор его забирает, разбирает и удаляет; обратный поток идёт так же. Не требует ни публикации базы наружу, ни постоянного канала. Задержка — от интервала расписания, обычно 15–60 минут. Там, где эта задержка допустима, это самый дешёвый и самый живучий механизм из четырёх: он переживает и обновления, и смену конструктора.
- 4Промежуточная база: витрина между учётом и сценариями
Рядом с 1С разворачивается отдельная база, куда регламентное задание выкладывает нужные данные, а из неё же забирает команды на запись. Конструктор в 1С не ходит вовсе — он работает только с витриной. Стоит дороже трёх предыдущих, но снимает главную головную боль: боевая база не под нагрузкой, обрыв связи ничего не теряет, а история обмена накапливается сама собой.
Таблица-сравнение из четырёх колонок «OData», «HTTP-сервис», «Файловый обмен», «Промежуточная база» и шести строк: «Модельная цена» — 82 000 ₽ / 212 000 ₽ / 92 000 ₽ / 150 000 ₽; «Срок» — 1–2 недели / 3–5 недель / 2 недели / 3–4 недели; «Задержка» — секунды / секунды / 15–60 минут / 5–15 минут; «Нагрузка на боевую базу» — высокая / средняя / низкая / отсутствует; «Трогает конфигурацию» — нет / да, через расширение / нет / нет; «Что при обрыве связи» — порция теряется / порция теряется / файл дождётся / данные дождутся в витрине. Ячейки с самым выгодным значением в строке выделены штриховкой. Чертёжный стиль, подписи по-русски.
Строка «что при обрыве связи» — единственная, которую нельзя обойти деньгами. У OData и HTTP-сервиса порция данных, не доехавшая в момент разрыва, теряется молча, если очередь и повторы не написал кто-то на стороне конструктора. У файлового обмена и витрины данные просто ждут следующего прогона. Это не значит, что первые два хуже: это значит, что в их смету обязана входить строка «очередь и повторные попытки», и если её там нет, смета неполная.
Конфигурация решает больше, чем внешняя система
Фраза «интегрируем с 1С» ничего не описывает. Конфигурации различаются не оформлением, а составом объектов: в 1С:Бухгалтерии предприятия нет заказов покупателей, резервов и складского учёта в том виде, в каком они есть в товарных конфигурациях, — и это не ограничение доступа, а отсутствие самих объектов. Сценарий «положить заказ в 1С» на Бухгалтерии не собирается никак, пока не решено, во что именно он превращается.
| Конфигурация | Что подключается легко | Что потребует отдельной работы | Типичная ошибка сметы |
|---|---|---|---|
| 1С:Управление торговлей 11 | Заказы, реализации, номенклатура, контрагенты, остатки по складам | Резервы и статусы заказа: их изменение затрагивает проведение и требует своих методов | Считать запись заказа такой же простой, как чтение справочника |
| 1С:Управление нашей фирмой | Заказы, счета, номенклатура, деньги в одной базе | Производственный контур и работы: устроены иначе, чем в УТ, готовых аналогий нет | Переносить решение с УТ один в один |
| 1С:Бухгалтерия предприятия 3.0 | Контрагенты, договоры, поступления и реализации, банковские документы | Всё товарное: заказов и резервов в конфигурации просто нет | Обещать обмен заказами и складскими остатками |
| 1С:Розница | Чеки, номенклатура, цены, остатки по магазину | Обмен исторически построен на распределённой базе: внешний контур встраивается рядом, а не вместо | Не учесть, что магазины работают автономно |
| 1С:ERP и Комплексная автоматизация | Тот же товарный контур, что в УТ, плюс производство и бюджеты | Объём и связность объектов: одно действие затрагивает больше регистров | Оценивать сроки по опыту с УТ |
Практический вывод для разговора с подрядчиком: смета, в которой не названы конфигурация, её редакция и версия платформы, — не смета, а вилка настроения. Разница между УТ 11 и Бухгалтерией 3.0 на одной и той же задаче доходит до трёх раз, а между типовой и сильно доработанной конфигурацией — до пяти, потому что во втором случае к работе добавляется чтение чужого кода. Что делать, если 1С доработана до неузнаваемости, но менять её не хочется, мы разбирали в материале про автоматизацию без замены 1С.
Типовая на поддержке: расширение вместо правки конфигурации
Самая дорогая ошибка этой связки обнаруживается не при запуске, а при первом обновлении. Если код обмена вписан прямо в конфигурацию, она снимается с поддержки, и каждое обновление превращается из получасовой процедуры в проект со сравнением и слиянием. Компания перестаёт обновляться вовремя, отстаёт на две-три редакции, а потом обнаруживает это в момент, когда обновиться надо срочно — из-за изменившейся отчётности или требований площадки.
- OData и файловый обмен конфигурацию не трогают вовсе. OData включается настройкой публикации, файловый обмен можно собрать на регламентном задании во внешней обработке. Типовая остаётся типовой, обновления идут штатно.
- HTTP-сервис требует расширения конфигурации, а не изменения самой конфигурации. Расширение — отдельный объект, который живёт рядом и подключается сверху. Конфигурация остаётся на поддержке, обновление проходит штатно, а после него проверяется только совместимость расширения.
- Промежуточная база трогает конфигурацию минимально: регламентное задание и правила выгрузки тоже размещаются в расширении. Основной код при этом вообще вне 1С — он в самой витрине и в конструкторе.
- Условие «типовая остаётся на поддержке» пишется в договоре до начала работ. Это одна строка, и она стоит дешевле любого последующего спора. Что происходит с доработками при обновлениях и как это считать, разобрано в материале про обновление 1С после доработок.
Расширение переживает большинство обновлений, но не все: если поставщик изменил модуль или структуру объекта, к которому расширение прицепилось, оно перестанет подключаться, и обмен встанет. Поэтому в регламент обновления добавляются два пункта: сначала обновление накатывается на тестовую копию, потом проверяется прогон обмена по контрольному сценарию. Проверка занимает 20 минут и снимает самый частый сценарий «обновились в пятницу, в понедельник заказы не поехали».
Нагрузка: почему опрос каждые пять минут — плохая идея
Конструктор не умеет ждать событие из 1С сам: у платформы нет вебхуков наружу в привычном смысле, и типовое решение — опрос по расписанию. Дальше начинается арифметика, которую обычно никто не делает. Интервал в пять минут даёт 288 прогонов в сутки; при трёх запросах на прогон — чтение новых документов, справочника контрагентов и остатков — это 864 обращения к базе в сутки и 25 920 в месяц.
Деньги здесь не главное. Главное — что 21 600 холостых чтений в месяц выполняются на той же базе, в которой работают люди, и в момент закрытия периода конкурируют с ними за ресурсы. Три правила снимают проблему почти полностью: отбор по дате изменения вместо чтения всего журнала, интервал по реальной срочности вместо интервала по умолчанию и встречный вызов там, где он возможен — сценарий не спрашивает 1С, а 1С сама зовёт сценарий в момент проведения документа, из того же расширения.
Две пары столбцов. Первая пара «Интервал 5 минут»: высокий столбец 25 920 запросов в месяц, внутри него тонкая выделенная полоска 900 с подписью «полезные, 3,5 %»; рядом подпись «операции конструктора 6 480 ₽/мес». Вторая пара «Интервал 30 минут с отбором по дате изменения»: столбец 4 320 запросов, внутри выделенная полоска 900 с подписью «полезные, 20,8 %»; рядом подпись «операции конструктора 1 080 ₽/мес». Между парами горизонтальная стрелка с подписью «−21 600 запросов к базе в месяц, −64 800 ₽ в год». Ось Y — запросы к базе в месяц. Чертёжный стиль, подписи по-русски.
Промежуточная база решает этот вопрос радикально: конструктор опрашивает витрину, а не учёт, и опрашивать её можно хоть каждую минуту — на работу пользователей это не влияет никак. Поэтому четвёртый механизм и стоит дороже: часть его цены — это именно снятие нагрузки с боевого контура.
Схема потоков данных в три вертикальные зоны. Левая зона «1С, боевая база»: блок «Регламентное задание, каждые 5 минут» со стрелкой вправо, подписанной «новые и изменённые документы». Центральная зона «Промежуточная база (витрина)»: два блока — «Исходящие данные» и «Очередь команд на запись», между ними подпись «история обмена накапливается». Правая зона «Конструктор сценариев»: блок «Сценарии», стрелка от витрины к нему с подписью «чтение без ограничений по частоте» и обратная стрелка с подписью «команда: создать документ». Обратная стрелка из очереди команд в 1С подписана «регламентное задание забирает и проводит». Внизу пометка: «боевая база получает 2 обращения в 5 минут вместо 3 запросов на каждый прогон сценария». Чертёжный стиль, подписи по-русски.
Права и учётная запись обмена
Обмен ходит в базу под пользователем, и слишком часто этот пользователь — «Администратор» с полными правами, а его пароль лежит в узле конструктора открытым текстом. Так делать нельзя по двум причинам: любой, кто получит экспорт сценария, получит полный доступ к учётной системе, а разобрать по журналу, что именно сделал обмен, а что человек, будет невозможно.
- 1Отдельный пользователь на каждый обмен, с именем, по которому видно назначение: не «Обмен», а «Обмен_сайт_заказы». При двух и более контурах это единственный способ понять по журналу, кто что сделал.
- 2Права по списку объектов, а не роль «Полные права». Читать — только те справочники и документы, которые реально нужны; писать — только те, в которые обмен обязан писать. Список составляется по методам обмена и пересматривается при каждом расширении задачи.
- 3Интерактивный вход этому пользователю запрещён: учётная запись существует только для обмена, зайти под ней в интерфейс нельзя. Это отсекает и случайное использование сотрудником, и часть сценариев после утечки пароля.
- 4Пароль не хранится в узле конструктора открытым текстом. Он лежит в хранилище секретов площадки или в вашем хранилище, а в сценарий подставляется ссылкой. Порядок разбора классов секретов у нас разобран в материале про то, где хранить пароли и ключи компании.
- 5Журнал регистрации 1С по этому пользователю проверяется отдельно: в нём должно быть видно каждое действие обмена с датой и объектом. Глубина хранения журнала настраивается заранее — по умолчанию она часто короче, чем срок, за который вы будете разбирать спор.
- 6Смена пароля делается с перекрытием: выпустить новый, перевести обмен, убедиться, что он идёт, и только потом отозвать старый. Обратный порядок обрывает обмен и обнаруживается на потерянных документах.
Сроки и вилка стоимости по каждому способу
Модельная задача для всех четырёх смет одинакова: односторонний поток «заказы из внешней системы в 1С» плюс встречное чтение остатков и статусов. Конфигурация — типовая 1С:УТ 11 на поддержке. Ставки: специалист 1С — 3 500 ₽/час, инженер на стороне конструктора — 3 000 ₽/час.
| Способ | Часы 1С | Часы инженера | Модельная смета | Срок | Вилка по рынку |
|---|---|---|---|---|---|
| OData | 8 | 18 | 82 000 ₽ | 1–2 недели | 60 000–140 000 ₽ |
| Файловый обмен по расписанию | 16 | 12 | 92 000 ₽ | 2 недели | 90 000–220 000 ₽ |
| Промежуточная база | 24 | 22 | 150 000 ₽ | 3–4 недели | 130 000–300 000 ₽ |
| Собственный HTTP-сервис, 5 методов | 52 | 10 | 212 000 ₽ | 3–5 недель | 180 000–400 000 ₽ |
Что двигает смету вверх внутри вилки: доработанная конфигурация вместо типовой (плюс 30–60 % на чтение чужого кода), двусторонний обмен вместо одностороннего, запись документов со сложным проведением, сопоставление номенклатуры между системами и требование к задержке меньше минуты. Что двигает вниз: типовая конфигурация, один поток вместо двух, готовность принять задержку в полчаса и отказ от записи в пользу только чтения.
Ни в одну из четырёх смет не входит эксплуатация, и это осознанно: поддержка связки — 12 000–25 000 ₽ в месяц в зависимости от механизма и потока. Самая дешёвая в обслуживании — файловый обмен, самая дорогая — HTTP-сервис, потому что его методы приходится править вместе с изменениями в учёте. Прежде чем считать окупаемость, посмотрите, какие сценарии вообще стоят того, — мы отбирали их по формуле в материале про сценарии, которые окупаются сразу.
Когда конструктор к 1С подключать не надо
Связка с учётной системой — самая дорогая часть любого парка сценариев и самая чувствительная к ошибкам, потому что на том конце документы, деньги и остатки. Пять случаев, в которых мы советуем этого не делать.
- Поток меньше 100 документов в месяц. Любой из четырёх механизмов стоит от 82 000 ₽ плюс поддержка. На таком потоке дешевле и надёжнее выгрузка в таблицу по расписанию, а ввод в 1С оставить человеку: пять минут в день против сметы и вечного риска расхождений.
- Задача — записать документ со сложным проведением. Реализация с резервами, себестоимостью и партиями — это не «создать объект», а вызвать бизнес-логику конфигурации. Через OData это делается плохо и ломается на первом же нетиповом случае; здесь либо HTTP-сервис с методом внутри 1С, либо не делать вовсе.
- Справочники не согласованы. Если номенклатура и контрагенты в двух системах не сопоставлены, обмен не наведёт порядок, а размножит беспорядок в обе стороны. Сначала хозяин справочника и сопоставление, потом обмен — обратный порядок означает, что вы заплатите дважды.
- Конфигурация доработана, а исходного разработчика нет. Тогда первая работа — не интеграция, а обследование: сколько там доработок, что они меняют в проведении и что сломается при обновлении. Прыгать сразу в обмен — значит закладывать в проект неизвестную величину.
- Внутри компании некому владеть связкой. Обмен с учётом — не «настроил и забыл»: он ломается при обновлениях, при смене прав, при изменении полей. Если в компании нет человека, который знает, что делает каждый сценарий, и умеет остановить обмен, связку лучше отложить до появления такого человека или отдать её на поддержку целиком.
Коннектор к 1С не бывает готовым. Готовым бывает только путь до базы — и то не всегда.
