Префиксы объектов 1С ODATA

Что это и зачем

endpoints.md описывает операции единообразно для всех префиксов. На практике префикс заметно меняет картину: у документа есть команды Post/Unpost, у регистра — виртуальные таблицы, у константы — фиксированный нулевой guid вместо ключа, у регистра бухгалтерии — обязательный read-modify-PATCH ритуал. Этот раздел собирает per-prefix отличия в одно место.

Сводная матрица

¹ TP — табличные части. ✓ означает поддержку через эндпоинты _<ТЧ> (чтение коллекции строк), _<ТЧ>_RowType (чтение одной строки), а также запись через PATCH родителя. ² Service-operations (корневые, не привязанные к экземпляру через путь): целью выступает значение query-параметра DataExchangePoint. См. Типы эндпоинтов §6.

---

Catalog

Справочник — базовый объектный тип.

• Стандартные поля: Ref_Key, Code, Description, DeletionMark, IsFolder, Parent_Key, DataVersion.
• Иерархия — поле Parent_Key ссылается на родителя; IsFolder=true для групп.
• Создание — обычный POST на коллекцию.
• Пометка на удаление — PATCH {"DeletionMark": true}. Отдельной команды нет.
• Физическое удаление — DELETE (без пометки, сразу).
• Табличные части — пишутся только целиком через PATCH родителя (endpoints.md §8.3).

Document

Документ. Главное отличие — состояние "проведён" управляется командами, не полем.

• Стандартные поля: Ref_Key, Date, Number, Posted, DeletionMark, DataVersion.
• Проведение — POST B/Document_<Имя>(<key>)/Post?PostingModeOperational=<true|false>.
• Отмена проведения — POST B/Document_<Имя>(<key>)/Unpost.
• Поле Posted — не пишется через PATCH; попытка → код 16 или молчаливо игнорируется.
• Дата (Date) — обязательное поле типа Edm.DateTime.
• Табличные части — пишутся только целиком через PATCH родителя.
• Подчинённые регистры — пишутся не из документа, а через эндпоинты регистров (см. ниже).

DocumentJournal

Журнал документов — агрегированная коллекция разнотипных документов.

• Обычно read-only — журнал нельзя пополнять напрямую, документы создаются через свои эндпоинты Document_<Имя> и автоматически попадают в журнал.
• Чтение — GET B/DocumentJournal_<Имя>?... с теми же query-параметрами, что и у обычной коллекции.

Constant

Константа — единственный «объект», у которого нет реального ключа, но синтаксис требует ключ.

• Ключ — всегда guid'00000000-0000-0000-0000-000000000000'.
• Чтение — GET B/Constant_<Имя>(guid'00000000-...').
• Запись — только PATCH B/Constant_<Имя>(guid'00000000-...')?$format=json с телом {"Value": <значение>}. POST не имеет смысла — одна "сущность" на константу.
• Тип значения — определяется конфигурацией; в JSON — соответствующий примитив (число / строка / булево / Edm.DateTime).

ExchangePlan

План обмена.

• Сами узлы — обычная коллекция/одиночные эндпоинты как у Catalog.
• Получение изменений — POST B/SelectChanges?DataExchangePoint='<URL узла>'&MessageNo=<N>. Возвращает только atom-feed, json-варианта не существует.
• Подтверждение приёма — POST B/NotifyChangesReceived?DataExchangePoint='<URL узла>'&MessageNo=<N>.
• Парсинг feed'а — atom + <at:deleted-entry> (RFC 6721). Стандартный JSON-парсер OData не сработает; нужен отдельный atom-xml ридер.
• DataExchangePoint — канонический URL узла (включая guid'...') в одинарных кавычках.

ChartOfAccounts / ChartOfCalculationTypes / ChartOfCharacteristicTypes

«Планы …». Снаружи — справочники с дополнительной поверхностью:

• Свои табличные части (виды субконто, ведущие, базовые).
• ChartOfCharacteristicTypes часто выступает источником значений ExtDimension* для бухгалтерских регистров.
• Иерархия (Parent_Key, IsFolder) и DeletionMark — как у Catalog.

Уникальной API-поверхности (специальных команд, виртуальных таблиц) в стандартной справке у этих префиксов нет — действуют общие правила endpoints.md §5–§9.

InformationRegister

Регистр сведений — делится надвое:

Независимый — ключ собирается из измерений.

• Чтение одной записи: GET B/InformationRegister_<Имя>(Period=datetime'...', Измерение_Key=guid'...').
• Эквивалентно: GET B/InformationRegister_<Имя>_RecordType(<dims>).

Подчинённый регистратору — ключ = Recorder_Key (+ измерения для отдельной записи).

• Чтение набора по регистратору: GET B/InformationRegister_<Имя>(Recorder_Key=guid'...').
• Чтение одной записи: GET B/InformationRegister_<Имя>_RecordType(Recorder_Key=guid'...', Измерение_Key=...).

Виртуальные таблицы:

• SliceLast(Period=..., Condition='...') — срез последних.
• SliceFirst(Period=..., Condition='...') — срез первых.

Для подчинённого регистра функцию вызывают на эндпоинте _RecordType:

GET B/InformationRegister_КурсыВалют_RecordType/SliceLast?Condition=...

AccumulationRegister

Регистр накопления. Всегда подчинён регистратору.

• Ключ записи — Recorder_Key.
• Чтение набора по регистратору — GET B/AccumulationRegister_<Имя>(guid'<recorder>').
• Виртуальные таблицы:
  • Balance(Period=datetime'...', Condition='...') — остатки.
  • Turnovers(StartPeriod=..., EndPeriod=..., Condition='...') — обороты.
  • BalanceAndTurnovers(StartPeriod=..., EndPeriod=..., Condition='...') — комбинированно.

CalculationRegister

Регистр расчёта. Доступен через общие правила регистров (коллекция по Recorder_Key, виртуальные таблицы через /<Func>(...)). Набор виртуальных таблиц зависит от типа регистра (с действием / без, с периодом действия). Сверять с $metadata целевой конфигурации.

AccountingRegister

Регистр бухгалтерии. Самый «тяжёлый» префикс — отличается во всём.

• Чтение набора по регистратору — GET B/AccountingRegister_<Имя>(guid'<recorder>')?$format=json. В ответе — Recorder_Key + массив RecordSet.
• Запись набора — только read-modify-PATCH:
  1. GET текущего набора (получить шаблон с RecordSet).
  2. Модификация массива локально.
  3. PATCH с обязательной "шапкой":

     {
       "odata.type": "StandardODATA.AccountingRegister_<Имя>_RowType",
       "Recorder_Key": "<guid>",
       "RecordSet@odata.type": "Collection(StandardODATA.AccountingRegister_<Имя>_RowType)",
       "RecordSet": [ /* строки */ ]
     }

• Виртуальная таблица Balance — с необычным набором параметров:
  • AccountCondition='Account_Key eq guid''...''' — отбор по счёту.
  • Condition='ExtDimension1 eq cast(guid''...'' , ''Catalog_Контрагенты'')' — отбор по субконто (через cast()).
  • ExtraDimensions='<value>' — дополнительные субконто.

Подробнее: endpoints.md §8.4, §11.3.

BusinessProcess / Task

Бизнес-процесс и задача — объектные типы. Через стандартный интерфейс OData доступны как обычные сущности (коллекция, GET/POST/PATCH/DELETE), с табличными частями. Специальные команды управления маршрутом (Старт, Выполнение) в стандартной справке 1С не описаны — если такие нужны, обычно реализуют через HTTP-сервисы конфигурации.

---

См. также

• Типы эндпоинтов — какие семейства URL поддерживает каждый префикс.
• endpoints.md — детальные параметры запросов.
• reference.md §17.4.4 — официальные правила формирования имени ресурса.