Главное достоинство OData в 1С заодно и главная его опасность: чтобы отдать данные наружу, программист 1С не нужен. Достаточно поставить пару галочек в конфигураторе.
Из-за этого настройку обычно делает системный администратор или веб-разработчик, который 1С видит впервые. Данные начинают отдаваться, все довольны, а через месяц выясняется, что наружу торчит вся база под правами администратора, а выгрузка каталога кладёт рабочую базу в обед.
Разберём настройку по шагам, с местами, где это ломается. Общий обзор способов интеграции есть в большом гайде по 1С. Здесь только OData и подробно.
Что такое стандартный интерфейс OData в 1С
1С умеет автоматически публиковать объекты конфигурации как REST-подобный интерфейс. Справочники, документы, регистры сведений и накопления становятся доступны по HTTP без единой строчки кода на стороне 1С.
Возможность появилась в платформе 8.3.5. Важная деталь, которая экономит часы: 1С работает по OData версии 3.0, а не 4.0. Большая часть примеров в интернете написана под четвёртую версию, и её синтаксис здесь просто не сработает. К конкретным различиям вернёмся ниже.
Когда OData подходит:
- нужно читать справочники, остатки, цены
- объёмы умеренные, до нескольких тысяч записей на запрос
- нет требования к сложной бизнес-логике на стороне 1С
Когда не подходит:
- нужны расчёты и проверки при записи, которых нет в типовой конфигурации
- запросы сложнее, чем позволяет фильтрация OData
- нагрузка высокая, а база рабочая
В последних случаях пишут HTTP-сервисы: там вы сами управляете и запросом, и логикой.
Шаг 1. Публикация на веб-сервере
1С отдаёт OData не сама по себе: ей нужен веб-сервер (IIS или Apache) и опубликованная база.
Публикуют базу из конфигуратора: Администрирование → Публикация на веб-сервере. В окне публикации есть флажок «Публиковать стандартный интерфейс OData». Без него ничего работать не будет.
После публикации базовый адрес выглядит так:
http://ваш-сервер/имя-базы/odata/standard.odata/
Проверить, что публикация жива, проще всего запросом схемы:
GET http://ваш-сервер/имя-базы/odata/standard.odata/$metadata
В ответ приедет XML с описанием всех доступных сущностей. Если приехал, половина дела сделана.
Шаг 2. Состав интерфейса: ловушка, на которой встают все
Публикация включена, $metadata отвечает, а список сущностей пустой либо в нём нет нужного справочника. Это самая частая точка остановки.
Дело в том, что в актуальных версиях платформы объекты не публикуются автоматически. Нужно явно задать состав стандартного интерфейса OData — указать, какие именно справочники, документы и регистры выставлены наружу.
Задать его можно либо в конфигураторе, либо программно, вызвав метод установки состава интерфейса. И это не бюрократия, а правильное поведение: публиковать всю базу целиком не нужно.
Практическое правило: выставляйте наружу только те объекты, которые реально участвуют в обмене. Каталог, цены, остатки, заказы. Не вся конфигурация.
Шаг 3. Отдельный пользователь и права
Соблазн зайти под администратором велик, особенно когда «надо просто проверить». Проверка обычно и остаётся в проде навсегда.
Заведите отдельного пользователя информационной базы под обмен и выдайте ему роль с минимально нужными правами: чтение того, что читается, запись того, что пишется. Аутентифицируется всё это обычным HTTP Basic:
curl -u "web_exchange:пароль" \
"http://ваш-сервер/base/odata/standard.odata/Catalog_Номенклатура?\$format=json&\$top=1"
Отсюда же вытекает требование к транспорту. Basic-аутентификация передаёт пару логин-пароль в заголовке при каждом запросе, поэтому канал обязан быть HTTPS. По HTTP это равносильно тому, чтобы отдать доступ к базе всем, кто окажется между вами и сервером.
Шаг 4. Имена сущностей
Имя сущности склеивается из типа объекта и его имени в конфигурации, через подчёркивание:
| Объект конфигурации |
Имя в OData |
| Справочник «Номенклатура» |
Catalog_Номенклатура |
| Документ «ЗаказПокупателя» |
Document_ЗаказПокупателя |
| Регистр сведений «ЦеныНоменклатуры» |
InformationRegister_ЦеныНоменклатуры |
| Регистр накопления «ТоварыНаСкладах» |
AccumulationRegister_ТоварыНаСкладах |
Русские имена в адресе допустимы, но их нужно кодировать при передаче. Большинство HTTP-клиентов делает это само; проблемы начинаются, когда адрес собирают конкатенацией строк вручную.
К табличным частям обращаются через имя владельца, а точный вид всегда можно подсмотреть в $metadata. Это вообще главный совет по OData в 1С: не угадывайте имена, читайте схему.
Шаг 5. Фильтры и выборка
Здесь и расходятся дороги с четвёртой версией протокола, из-за чего чужие примеры не работают.
Формат ответа. По умолчанию приезжает Atom/XML. JSON нужно просить явно:
?$format=json
Отбор. Ссылочные значения передаются как GUID со специальным литералом, даты — со своим:
?$filter=Номенклатура_Key eq guid'a1b2c3d4-0000-0000-0000-000000000000'
?$filter=Дата ge datetime'2026-09-01T00:00:00'
?$filter=ПометкаУдаления eq false
Только нужные поля. Экономит и трафик, и время формирования ответа на стороне 1С:
?$select=Ref_Key,Наименование,Артикул
Постраничность. Работает как обычно:
?$top=100&$skip=200
Общее количество. Вот характерное различие: в OData 4.0 это $count=true, а в 1С, где реализована версия 3.0, нужно писать иначе:
?$inlinecount=allpages
Если видите в примере $count=true, значит, пример не про 1С.
Отдельно отметим, что $inlinecount, $orderby и $expand применимы только к запросам, возвращающим список. К запросу одной записи по ключу их прикручивать бессмысленно.
Шаг 6. Запись данных обратно
OData умеет и записывать. Новая запись создаётся обычным POST на коллекцию:
POST /base/odata/standard.odata/Document_ЗаказПокупателя?$format=json
Content-Type: application/json
{
"Date": "2026-09-01T14:30:00",
"Контрагент_Key": "a1b2c3d4-0000-0000-0000-000000000000",
"Товары": [
{ "Номенклатура_Key": "...", "Количество": 2, "Цена": 1500 }
]
}
Изменение существующей записи делается через PATCH по ключу. И тут важный момент, который упускают: создание документа не означает его проведение. Документ появится в базе как черновик, а движения по регистрам не сформируются. Для проведения у документов есть отдельное действие, и его нужно вызывать явно.
Выглядит это узнаваемо: заказы с сайта приходят, менеджер их видит, а в остатках и взаиморасчётах их нет.
Производительность: почему обмен кладёт базу
OData удобен, но он ходит в базу через обычный механизм запросов 1С, и подкрутить этот запрос вы не можете. Отсюда три типичные проблемы.
Выгрузка всего каталога одним запросом. На десятках тысяч позиций это долгая транзакция, которая мешает работе пользователей. Лечится так: листайте страницами и забирайте только то, что изменилось с прошлой синхронизации.
Запросы в рабочее время. Тяжёлые выгрузки уводите на ночь либо гоняйте по копии базы.
Отсутствие $select. Без него 1С собирает полный набор полей каждого объекта, включая те, что вам не нужны.
Если после всех мер обмен всё равно тяжёлый, это сигнал, что задача переросла OData, и пора писать HTTP-сервисы с нормальными запросами на стороне 1С.
Чек-лист настройки
Заключение
OData закрывает большую часть задач обмена и не требует разработки на стороне 1С — за это его и любят. Но лёгкость настройки не отменяет двух вещей: наружу должно торчать ровно необходимое, и делать это должен отдельный пользователь с ограниченными правами.
Если после настройки обмен работает медленно, дело обычно не в OData, а в том, что через него пытаются протащить объёмы, для которых он не предназначен. Тогда правильный следующий шаг не в том, чтобы дошлифовывать фильтры, а в том, чтобы перейти на HTTP-сервисы.
Читайте также
