OData 1С в сервисы: REST, который понимает разработчик и AI

Штатный обмен 1С по протоколу OData даёт доступ почти ко всем справочникам и документам учётки. Для интегратора это и сила, и ловушка: сайт, CRM или AI-ассистент вынуждены знать внутренние имена объектов, обязательные поля шапки и как искать контрагента среди дублей.

Мы решаем иначе. OData (или другой канал) остаётся транспортом. Снаружи команда сайта, интернет-магазина, CRM или десктоп-программы вызывает короткие операции бизнеса: «создать коммерческое предложение», «найти услугу», «завести поставщика». Так устроены готовый REST API для 1С:Бухгалтерия, заказные сервисы на стороне 1С и библиотека в вашей системе, которую пишем под ваш стек и нужный протокол.

Если счета и акты в 1С:Бухгалтерия 3.0 нужны уже сейчас, а ждать разработку обёртки нет смысла — берите готовое расширение: JSON, обычные URL, без изучения OData. Ниже — как устроена такая обёртка на нашем примере; продукт можно заказать отдельно, без проекта «с нуля».

REST API для 1С: лицензия bit_http_api — 137 250 ₽, внедрение при необходимости — 30 000 ₽. Заказать · документация

Содержание: зачем обёртка · пример: КП в УНФ · почему это понятно AI и веб-разработчику · готовый REST · библиотека для вашей системы · вопросы

OData «как есть» и сервис «сделай документ»

Представьте склад без витрины: можно взять любой ящик, если знаете стеллаж, ряд и этикетку на языке кладовщика. OData — такой склад. Нужно создать заказ покупателя — в 1С это отдельный вид документа, таблица строк, договор, вид цен, организация, способ доставки, признак проведения.

Веб-программист или нейросеть не обязаны это помнить. Им нужна одна операция: кому продать, что в строках, по какой цене, черновик или сразу проведённый документ.

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

Как мы это сделали у себя: коммерческое предложение

У направления TechSpot типовой сценарий: клиент + строки номенклатуры с ценой → в 1С:Управление нашей фирмой появляется документ, который менеджер видит как заказ покупателя / коммерческое предложение.

Снаружи вызывающий не передаёт «весь документ 1С». Он говорит:

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

Шаг 1. Проверка без записи в учётку

Сначала смотрим, что получится. В 1С ещё ничего нет. Если контрагентов с похожим названием несколько — сервис не угадывает: возвращает список карточек, и нужно указать конкретную. То же с номенклатурой.

{
  "counterparty_query": "ООО Ромашка",
  "items": [
    {
      "nomenclature_query": "замена ФН",
      "quantity": 1,
      "content": "Замена ФН 36 мес. · выезд"
    }
  ],
  "dry_run": true
}

Ответ — сумма, договор, строки и откуда взялась цена: из запроса или из прайса в 1С. Можно показать человеку и только потом писать документ.

Шаг 2. Черновик КП

После проверки передаём однозначные карточки и явно разрешаем запись. Документ по умолчанию не проводится: менеджер видит его в 1С и проводит сам или вы просите провести отдельным признаком.

{
  "counterparty_key": "…guid контрагента…",
  "items": [
    {
      "nomenclature_key": "…guid услуги…",
      "quantity": 1,
      "price": 4500,
      "content": "Замена ФН 36 мес."
    }
  ],
  "comment": "по звонку 22.08",
  "confirm": true,
  "post": false
}

В ответе — номер, сумма, ссылка на документ. Дальше номер уходит клиенту вместе со счётом — так у нас работает публичная заявка с сайта: ИНН + код услуги + цена из прайса CRM → тот же сервис → письмо.

Что сервис закрывает сам

Организация, вид цен, НДС, самовывоз, безнал, состояние «в работе» — константы этой базы. Для другой фирмы передают свою организацию и обычно свой договор. Это не универсальный клиент ко всей 1С России, а слой «операция учётки + правила нашей компании». Именно так и делают заказные интеграции: правила ваши, принцип тот же.

Почему это читает и программист без 1С, и AI

Модель языка и разработчик сайта одинаково спотыкаются о метаданные 1С: длинные имена объектов, GUID, обязательные реквизиты, проведение отдельным действием, а не «полем posted».

Сервис снимает это тремя правилами:

1. Имена с бизнеса. «Создать заказ покупателя», а не «POST в коллекцию документов платформы».
2. Сначала превью. Пока нет явного подтверждения — в учётке пусто. Ошиблись названием компании — увидели список, а не два документа-двойника.
3. Ошибки с выбором, не с кодом 500. Несколько карточек — вернули варианты. Нет цены — сказали указать. Нет договора — сказали завести.

Такой контракт можно положить в описание инструмента для AI или в OpenAPI для Postman. Ассистент вызывает одну операцию; 1С-эксперт один раз зашил шапку и таблицы. Дальше сайт, CRM и чат пользуются одним и тем же входом.

Похожий ход для счетов и актов в 1С:Бухгалтерия мы вынесли в готовый продукт: JSON, обычные URL, без изучения OData. Разбор POST счёта — в отдельной статье, сравнение каналов — в REST, OData или типовой обмен.

Нет времени на разработку — готовый REST API

Заказная обёртка, как в примере с КП, — это проект: разобрать ваши документы, зашить правила фирмы, отдать контракт команде сайта. Если задача уже типовая — выставить счёт, акт, найти или создать контрагента, отдать PDF из 1С:Бухгалтерия 3.0 — отдельно писать слой не нужно.

Готовый продукт bit_http_api: расширение ставится в вашу базу, HTTP-сервис публикуется, дальше backend работает с JSON. Лицензия — фиксированная цена, внедрение на вашей базе при необходимости отдельно. Это не «обсудить интеграцию», а заказ со страницы продукта.

• Нет времени / нет 1С-разработчика в штате — REST API для 1С:Бухгалтерия: счета, акты, контрагенты, PDF. Стенд за день — чеклист.
• Нужны свои документы в УНФ, УТ — слой на стороне 1С: превью, поиск по ИНН и коду, запись только по подтверждению.
• Каталог, цены, остатки пакетами — чаще CommerceML, REST рядом для оперативных документов.

Не обещаем «подключим OData и уедет всё само». Для Бухгалтерии — готовый контракт. Если готового продукта мало — экспертная разработка: либо сервисы в 1С, либо библиотека в вашей программе.

Библиотека для сайта, магазина, CRM или десктопа

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

Протокол выбираете вы: штатный обмен 1С по OData, наш или ваш REST, файловый обмен, смешанная схема. Мы закладываем ту же дисциплину, что в примере с КП: проверка без записи, однозначный поиск карточек, понятные ошибки. Команда магазина или CRM не становится экспертами по 1С.

Это экспертная разработка CodeLab под ваш контур, не коробочная лицензия. Имеет смысл, когда готовый REST для Бухгалтерии не покрывает сценарий, а «просто дать OData разработчикам сайта» слишком дорого по времени и ошибкам.

Что заказать. Счета и акты в Бухгалтерии без проекта — готовый REST API. Слой в 1С или библиотека для сайта, ИМ, CRM, десктопа под ваш протокол — заявка в CodeLab. Если сомневаетесь: опишите, из какой программы что должно попадать в 1С; часто хватает готового REST.

См. также: REST без сырого OData, стенд за день, AI и закупка в 1С, 1С-разработка.