Произошла внутренняя ошибка odata сервиса

   rubetek

10.02.17 — 17:50

   rubetek

7 — 13.02.17 — 14:10

   rubetek

10 — 13.02.17 — 16:13

В этой статье рассказывается об использовании стандартного интерфейса OData для программного чтения и записи данных приложений абонентов сервиса 1С:Фреш.

OData (Open Data Protocol) — это открытый веб-протокол для запроса, добавления, удаления и обновления данных. OData позволяет выполнять операции с ресурсами с помощью HTTP-запросов и получать ответы в форматах XML или JSON. Подробнее о протоколе OData можно прочесть в Википедии.

Доступ к данным посредством OData можно использовать, например:

• для загрузки и выгрузки данных;
• для интеграции со сторонними информационными системами;
• для реализация дополнительной функциональности сторонними средствами.

2. Поддержка в платформе «1С:Предприятие»

Начиная с версии 8.3.5, в платформе «1С:Предприятие» поддерживается доступ через протокол OData к данным информационных баз «1С:Предприятия». Это позволяет читать и записывать из внешнего приложения данные прикладного решения «1С:Предприятия» без модификации кода этого прикладного решения.

2.1. Автоматически создаваемый REST-интерфейс для использования OData

Разработчикам прикладных решений на платформе «1С:Предприятие» не нужно писать ни строчки кода для того, чтобы с данными прикладного решения можно было работать по протоколу OData. Достаточно включить поддержку OData при публикации на веб-сервере, и платформа «1С:Предприятие» автоматически создаст REST-интерфейс, с помощью которого можно обращаться к данным всего прикладного решения по протоколу OData.

Этот автоматически создаваемый REST-интерфейс прикладных решений на платформе «1С:Предприятие» принято называть стандартным интерфейсом OData.

2.2. Условия использования стандартного интерфейса OData

Для использования стандартного интерфейса OData:

• для доступа к данным следует использовать протокол OData версии 3 (с некоторыми расширениями и ограничениями фирмы 1С);
• состав объектов прикладного решения, к которым разрешен доступ с помощью интерфейса OData, должен быть установлен путем вызова метода глобального контекста УстановитьСоставСтандартногоИнтерфейсаOData.

2.3. Возможности стандартного интерфейса OData

С помощью стандартного интерфейса OData доступны:

• практически все основные виды объектов конфигураций прикладных решений на платформе «1С:Предприятие»: бизнес-процессы, документы, журналы документов, задачи, константы, планы видов расчета, планы видов характеристик, планы обмена, планы счетов, регистры бухгалтерии, регистры накопления, регистры расчета, регистры сведений, справочники (подробнее см. здесь);
• операции чтения, создания, модификации и удаления данных;
• реквизиты объектов конфигурации, табличные части и реквизиты табличных частей;
• получение списков документов, справочников, записей регистров сведений и т. п., возможно, с применением фильтра;
• получение данных документа, элемента справочника, записи регистра сведений и т. д.;
• редактирование данных документа, элемента справочника или другого ссылочного объекта;
• создание нового элемента справочника, документа, набора записей;
• выполнение различных действий с объектами прикладных решений: проведение и отмена проведения документов, выполнение задач, запуск бизнес-процессов, получение остатков и оборотов для регистров накопления и регистров бухгалтерии, и т. п.

При действиях с данными с помощью стандартного интерфейса OData платформа «1С:Предприятие» выполняет все обычные проверки прав доступа и вызывает обработчики событий.

Подробнее о возможностях стандартного интерфейса OData рассказано здесь.

3. Использование интерфейса OData в сервисе 1С:Фреш (1cfresh.com)

В сервисе 1С:Фреш (1cfresh.com) все прикладные информационные базы опубликованы с включенной поддержкой интерфейса OData.

Поэтому для приложений абонентов сервиса 1С:Фреш возможны чтение и запись данных с помощью HTTP-запросов стандартного интерфейса OData.

Ограничение: в сервисе 1С:Фреш в OData-запросах не поддерживается HTTP-заголовок 1C_OData-DataLoadMode: true, позволяющий при записи объектов эмулировать запись, выполняемую во время работы механизма обмена данными (свойство ОбменДанными.Загрузка = Истина). OData-запросы с таким заголовком не будут обработаны.

4. Обработка «Настройка автоматического REST-сервиса»

Для настройки доступа через интерфейс OData в прикладных решениях обычно используется обработка Настройка автоматического REST-сервиса, позволяющая:

1. Создать служебного пользователя, от имени которого может вызываться интерфейс OData.
2. Настроить состав объектов приложения, которые будут доступны через интерфейс OData.

Обработка доступна пользователям, имеющим в приложении административные права (роль Полные права). В сервисе Фреш такие права в приложении имеет владелец абонента.

4.1. Вызов обработки

Команды, которые нужно выбрать в меню приложения для вызова обработки, могут быть следующими:

• Администрирование — Синхронизация данных — Настройки стандартного интерфейса OData;
• Администрирование и НСИ — Синхронизация данных — Настройки стандартного интерфейса OData;
• Настройки — Синхронизация данных — Настройки стандартного интерфейса OData.

4.2. Создание служебного пользователя

Для использования интерфейса OData рекомендуется создать в приложении отдельного служебного пользователя. Это можно сделать в обработке Настройка автоматического REST-сервиса на вкладке Авторизация.

Созданному служебному пользователю будут автоматически назначены права, необходимые для использования интерфейса OData, в частности, роль УдаленныйДоступOData. Этот служебный пользователь не будет отображаться ни в списке пользователей приложения (в режиме «1С:Предприятие»), ни в списке пользователей абонента в менеджере сервиса.

4.3. Настройка состава объектов, доступных через интерфейс OData

На вкладке Состав окна обработки Настройка автоматического REST-сервиса можно указать, какие объекты прикладного решения будут доступны через интерфейс OData.

Рекомендуется включать доступ только для видов объектов, используемых в задачах, для которых будет использоваться интерфейс OData. Если для доступа к каким-либо видам объектов необходимо включить доступ через интерфейс OData также и к подчиненным им видам объектов, то обработка Настройка автоматического REST-сервиса выведет соответствующее сообщение и позволит включить такой доступ.

Не рекомендуется включать доступ через OData к планам обмена, так как их некорректное изменение может привести к неработоспособности приложения абонента.

После задания состава объектов, доступных через интерфейс OData, нужно нажать кнопку
.

5. HTTP-запросы интерфейса OData

5.1. URL запроса

5.1.1. Формат URL

URL HTTP-запросов стандартного интерфейса OData имеет вид:

• URL-приложения/odata/standard.odata/идентификатор-ресурса?параметры

Здесь:

• URL-приложения — адрес, по которому выполняется доступ к приложению в браузере (без кода языка), например, https://1cfresh.com/a/sbm/12345;
• /odata/standard.odata/ — признак обращения к стандартному интерфейсу OData;

• идентификатор-ресурса — особым образом сформированный идентификатор ресурса (возможно, с параметром) или предопределенные ресурсы. Например:

  • Catalog_Контрагенты — обращение к справочнику Контрагенты;
  • Catalog_Контрагенты(guid’c3fbdcaf-b8e1-11e4-8271-001e101f0864′) — обращение к записи справочника Контрагенты с указанным guid;
• параметры — параметры запроса, они указываются в виде пар ключ=значение, разделенных символами &, как это принято в HTTP-запросах. Параметры не обязательны. Если параметры отсутствуют, то и символ ?, разделяющий имя ресурса и параметры, в запросе не указывается.

5.1.2. Пример

Например, в запросе:

GET https://1cfresh.com/a/sbm/12345/odata/standard.odata/Catalog_Номенклатура?$format=json&$filter=Артикул eq '345'

• https://1cfresh.com/a/sbm/12345 — URL приложения, к которому делается запрос;
• /odata/standard.odata/ — признак обращения к стандартному интерфейсу OData;
• Catalog_Номенклатура — наименование ресурса, к которому относится запрос (справочник Номенклатура);
• $format=json и $filter=Артикул eq ‘345’ — параметры запроса, разделенные символами &.

5.2. Заголовок аутентификации

В запросе нужно использовать HTTP-заголовок Authorization: Basic с указанием логина/пароля пользователя, от имени которого осуществляется HTTP-запрос (строка логин:пароль, закодированная в формате base64). Этот пользователь должен иметь в приложении либо административные права (роль Полные права), либо роль УдаленныйДоступOData.

5.3. Метод запроса

HTTP-метод запроса выбирается в зависимости от того, какая операция выполняется:

При использовании для обновления данных метода PATCH в запросе можно указывать только обновляемые свойства сущности, а при использовании метода PUT нужно указывать все свойства сущности.

5.4. Указание строк, уникальных идентификаторов и дат

В запросе OData:

• строки указываются в одинарных кавычках (апострофах). Например: ’Санкт-Петербург’;
• уникальные идентификаторы указываются как guid’строка’. Например: guid’7426fe18-e7e6-11ec-872c-fa163e21d4b7’;
• даты указываются как datetime’yyyy-mm-ddThh:mm:ss’. Например: datetime’2022-09-25T12:30:59’.

5.5. Результат запроса

В результате выполнения запроса клиентское приложение получает ответ сервера, который может содержать данные, предоставленные сервером. Формат этих данных может быть XML (по умолчанию) или JSON.

Чтобы получить от сервера данные в формате JSON, можно:

• указать параметр запроса $format=json
• или указать в запросе HTTP-заголовок Accept: application/json

5.6. Правила формирования идентификатора ресурса

5.6.1. Тип и имя объекта конфигурации

Идентификатор ресурса, указываемый в URL стандартного интерфейса OData, начинается с указания типа и имени объекта конфигурации:

Здесь имя объекта записывается так, как оно показано в свойстве объекта Имя в конфигураторе.

5.6.2. Суффикс имени

После указания типа и имени объекта конфигурации может быть указан суффикс, начинающийся с символа подчеркивания:

5.6.3. Выбор элемента

Для справочников, документов, регистров, задач, бизнес-процессов и табличных частей с помощью стандартного интерфейса OData можно как получать списки элементов, так и обращаться к отдельным элементам, например, к конкретным записям справочника или регистра, к отдельным документам, задачам, экземплярам бизнес-процессов и т.п.

Для обращения к отдельному элементу в URL запроса после указания типа и имени объекта конфигурации, и суффикса, если он имеется, необходимо указать в круглых скобках названия и значения ключевых полей нужного элемента в виде пар название=значение, перечисленных через запятую.

Если ключевых полей более одного, то они должны быть указаны все. Если ключевое поле одно, то в круглых скобках можно указать только значение этого ключевого поля. Например:

5.6.4. Указание действия

В заключительной части идентификатора ресурса можно указать после символа / действие с ресурсом. Например:

Замечание. В ответе можно вывести значение реквизита подчиненного объекта. В этом случае полное имя реквизита формируется с использованием разделителя /. Например, /Контрагент/ИНН означает, что в запросе следует вывести только значение реквизита ИНН объекта, на который ссылается реквизит ответа Контрагент.

5.6.5. Методы

Вот некоторые методы, которые можно использовать в OData-запросах (подробнее см. здесь):

Ниже приведены примеры использования некоторых из этих методов:

• в разделе 6.5.1 — проведение и отмена проведения документов с помощью методов Post и Unpost;
• в разделе 6.5.2 — вывод курса валюты на указанную дату с помощью метода SliceFirst.

Также имеются специальные методы для регистров накопления, бухгалтерии и расчета подробнее (см. здесь, здесь и здесь):

5.7. Параметры запроса

Как уже говорилось, в HTTP-запросе стандартного интерфейса OData после символа ? могут указываться параметры запроса в виде разделенных амперсендами пар ключ=значение. Если параметры отсутствуют, то символ ?, разделяющий имя ресурса и параметры, в запросе не указывается.

5.7.1. Параметры, задающие условия отбора

5.7.2. Параметры, задающие режимы отображения результатов

Параметры $inlinecount, $orderby и $expand применимы только для запросов, выдающих список элементов. Параметр $expand не может использоваться для расширения реквизитов табличных частей.

В параметре $orderby возможны:

• использование вызовов функций (см. раздел 5.10);
• упорядочивание по свойствам дочерних реквизитов — в этом случае полное имя реквизита, по которому выполняется упорядочивание, формируется с использованием разделителя /. Например, $orderby=Контрагент/ИНН asc означает, что упорядочивание будет произведено по возрастанию значения реквизита ИНН объекта, на который ссылается реквизит ответа Контрагент.

В параметре $select при использовании совместно с параметром $expand возможно использование символов * и **:

Подробнее о правилах составления HTTP-запросов стандартного интерфейса OData рассказано здесь и здесь.

5.8. Условия отбора

В параметрах запроса $filter, а также в параметрах Condition, AccountCondition, BalancedAccountCondition применяемых для выполнения действий с ресурсами (см. раздел 5.6.4), указывается условие отбора. Условие формируется из:

• имен реквизитов;
• арифметических и логических операций (см. раздел 5.9);
• вызовов функций (см. раздел 5.10);
• литералов (чисел, строк, дат, уникальных идентификаторов);
• круглых скобок (как обычно, они используются для явного задания порядка вычисления значения).

При указании условий запроса (параметр $filter) или реквизита, по которому выполняется упорядочивание результатов (параметр $orderby) могут применяться следующие функции:

5.9. Арифметические и логические операции

В условиях отбора запросов OData могут использоваться арифметические и логические операции.

5.9.1. Логические операции

Не поддерживаются операции сравнения с реквизитом типа ХранилищеЗначения.

5.9.2. Арифметические операции

5.10. Функции

В параметрах запроса $filter и $orderby, а также в параметрах Condition, AccountCondition, BalancedAccountCondition методов, применяемых для выполнения действий с ресурсами (см. раздел 5.6.4), могут применяться следующие функции.

5.10.1. Функции для работы со строками

5.10.2. Функции для работы с датами

5.10.3. Функции all и any

Для отбора по реквизитам табличных частей в запросах стандартного интерфейса OData можно использовать лямбда-функции all и any. Эти функции проверяют указанное условие для всех строк табличной части объекта, и возвращают значение true:

• для функции any — если условие выполнено хотя бы для одной строки табличной части;
• для функции all — если условие выполнено для всех строк табличной части.

В иных случаях эти функции возвращают значение false.

Поясним синтаксис функций all и any на примере. Пусть нужно отобрать документы РасходТовара, в которых имеется хотя бы один товар с ценой большей 10000. Иными словами, в табличной части Товары этих документов должна быть хотя бы одна строка, в которой значение реквизита Цена больше 10000. Это можно сделать, использовав в запросе OData такую конструкцию:

.../Document_РасходТовара?$filter=Товары/any(d: d/Цена gt 10000)

Как видно, непосредственно перед названием функции any указывается имя табличной части Товары и слеш /. В скобках указывается имя переменной (в данном случае использовано имя d). Эта переменная будет использоваться в логическом выражении, она обозначает строку табличной части. После имени переменной следует двоеточие и затем указывается проверяемое логическое выражение. Обозначение d/Цена означает реквизит Цена строки d табличной части документа.

Аналогично, чтобы отобрать документы РасходТовара, у которых в табличной части Товары во всех строках значение реквизита Цена больше 10000, в запросе OData можно использовать следующую конструкцию:

.../Document_РасходТовара?$filter=Товары/all(d: d/Цена gt 10000)

Ниже в разделе 6.5.1 приведен пример использования функции any.

5.10.4. Прочие функции

6. Примеры запросов с помощью стандартного интерфейса OData

Приведенные ниже примеры показывают лишь некоторые самые простые возможности запросов с помощью стандартного интерфейса OData. Более полные сведения можно прочесть в руководстве разработчика 1С:Предприятия.

6.1. Общие сведения

6.1.1. Приложение для примеров использования стандартного интерфейса OData

Для удобства приведем сквозной пример использования стандартного интерфейса OData. В нем мы будем использовать демонстрационное приложение Управление нашей фирмой. В нем нужно:

1. Включить валютный учет (Настройки — Еще больше возможностей —Деньги —установить флажок Несколько валют.
2. Добавить валюту Доллар США (Деньги —Валюты), включив для нее режим установки курса загружается из Интернета.

3. В обработке Настройка автоматического REST-сервиса (см. раздел 4) включить доступ через интерфейс OData к следующим объектам конфигурации:

   • справочники Номенклатура, Организации, Сотрудники, Физические лица
   • документы Доверенность, ЗаказПокупателя
   • регистр сведений КурсыВалют

6.1.2. Клиент для HTTP-запросов

GET-запросы стандартного интерфейса OData можно выполнять с помощью браузера. В адресной строке браузера нужно вводить только URL, без указания метода GET.

Для выдачи всех видов HTTP-запросов можно использовать расширение REST Client среды разработки Visual Studio Code (ссылка) или любое аналогичное приложение.

6.1.3. ПрефиксURL

Все OData-запросы к приложению начинаются со строки адрес-приложения/odata/standard.odata. Например, если адрес приложения https://1cfresh.com/a/sbm_demo/1962515, то OData-запросы к этому приложению начинаются со строки https://1cfresh.com/a/sbm_demo/1962515/odata/standard.odata

Для наглядности и экономии места мы будем в дальнейшем вместо этой строки использовать обозначение ПрефиксURL.

6.2. Получение списков

Покажем применение методов стандартного интерфейса OData, выдающих списки различных сущностей — записей справочника, записей регистров, документов и т.д. Мы будем это делать на примере справочников Сотрудники, ФизическиеЛица и Номенклатура. Аналогичным образом можно получать сведения о других видах объектов прикладного решения.

6.2.1. Количество объектов

Просмотрим сведения о справочнике Сотрудники. Для начала узнаем количество записей в этом справочнике. Для этого укажем в GET-запросе после имени объекта Catalog_Сотрудники нужное действие /$count:

GET ПрефиксURL/Catalog_Сотрудники/$count

Здесь вместо ПрефиксURL нужно использовать строку, как указано в разделе 6.1.3. Далее это замечание мы повторять не будем.

Запрос можно ввести в адресной строке браузера (только URL, без указания метода GET).

Должен быть выдан ответ — количество сотрудников, например:

29

6.2.2. Вывод списка

Выведем первые 2 записи справочника ФизическиеЛица. Для этого укажем в запросе параметр $top=2. Также зададим в этом запросе и будем указывать в последующих запросах параметр $format=json, указывающий применение формата JSON для кодирования данных в теле ответа и в теле запроса.

GET ПрефиксURL/Catalog_ФизическиеЛица?$format=json&$top=2

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица",
  "value": [
    {
      "Ref_Key": "baebacee-b80e-11e4-826f-001e101fe696",
      "DataVersion": "AAAAAAAAAAA=",
      "DeletionMark": false,
      "Parent_Key": "00000000-0000-0000-0000-000000000000",
      "IsFolder": false,
      "Code": "ФР-0000002",
      "Description": "Абнагимова Ирина Витальевна",
      "ДатаРождения": "1947-08-05T00:00:00",
      "Пол": "Женский",
      "ИНН": "",
      "СтраховойНомерПФР": "",
      "Гражданство_Key": "00000000-0000-0000-0000-000000000000",
      "Недействителен": false,
      "БанковскийСчетПоУмолчанию_Key": "00000000-0000-0000-0000-000000000000",
      "КонтактнаяИнформация": [],
      "ДополнительныеРеквизиты": [],
      "Predefined": false,
      "PredefinedDataName": ""
    },
    {
      "Ref_Key": "baebad03-b80e-11e4-826f-001e101fe696",
      "DataVersion": "AAAAAAAAAAA=",
      "DeletionMark": false,
      "Parent_Key": "00000000-0000-0000-0000-000000000000",
      "IsFolder": false,
      "Code": "ФР-0000003",
      "Description": "Аввакумов Вадим Иванович",
      "ДатаРождения": "1966-06-04T00:00:00",
      "Пол": "Мужской",
      "ИНН": "",
      "СтраховойНомерПФР": "",
      "Гражданство_Key": "00000000-0000-0000-0000-000000000000",
      "Недействителен": false,
      "БанковскийСчетПоУмолчанию_Key": "00000000-0000-0000-0000-000000000000",
      "КонтактнаяИнформация": [],
      "ДополнительныеРеквизиты": [],
      "Predefined": false,
      "PredefinedDataName": ""
    }
  ]
}

6.2.3. Отбор отображаемых реквизитов

Пусть нас интересуют только ФИО, пол и дата рождения. Выведем первые 3 записи справочника ФизическиеЛица только с этими реквизитами. Для этого укажем в запросе параметры $top=3 и $select=Description,Пол,ДатаРождения. Введем GET-запрос:

GET ПрефиксURL/Catalog_ФизическиеЛица?$format=json&$top=3&$select=Description,Пол,ДатаРождения

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица",
  "value": [
    {
      "Description": "Абнагимова Ирина Витальевна",
      "Пол": "Женский",
      "ДатаРождения": "1947-08-05T00:00:00"
    },
    {
      "Description": "Аввакумов Вадим Иванович",
      "Пол": "Мужской",
      "ДатаРождения": "1966-06-04T00:00:00"
    },
    {
      "Description": "Авдеев Александр Алексеевич",
      "Пол": "Мужской",
      "ДатаРождения": "1980-11-15T00:00:00"
    }
  ]
}

6.2.4. Отбор объектов

Пусть нас интересуют только сведения о мужчинах. Выведем ФИО и дату рождения для первых 3 записей справочника ФизическиеЛица, в которых Пол=’Мужской’. Для этого добавим в запрос параметр $filter=Пол eq ‘Мужской’:

GET ПрефиксURL/Catalog_ФизическиеЛица?$format=json&$top=3&$select=Description,ДатаРождения&$filter=Пол eq 'Мужской'

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица",
  "value": [
    {
      "Description": "Аввакумов Вадим Иванович",
      "ДатаРождения": "1966-06-04T00:00:00"
    },
    {
      "Description": "Авдеев Александр Алексеевич",
      "ДатаРождения": "1980-11-15T00:00:00"
    },
    {
      "Description": "Александров Дмитрий Олегович",
      "ДатаРождения": "1977-08-04T00:00:00"
    }
  ]
}

6.2.5. Показ количества объектов, удовлетворяющих условиям отбора

Указав в запросе OData параметр $inlinecount=allpages, можно одновременно получить записи, удовлетворяющие условиям отбора, и общее количество таких записей.

Выведем ФИО и дату рождения для первых 3 записей справочника ФизическиеЛица, в которых Пол=’Мужской’, и получим общее количество записей, в которых Пол=’Мужской’. Введем запрос:

GET ПрефиксURL/Catalog_ФизическиеЛица?$format=json&$top=3&$select=Description,ДатаРождения&$filter=Пол eq 'Мужской'&$inlinecount=allpages

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица",
  "odata.count": "28",
  "value": [
    {
      "Description": "Аввакумов Вадим Иванович",
      "ДатаРождения": "1987-06-04T00:00:00"
    },
    {
      "Description": "Авдеев Александр Алексеевич",
      "ДатаРождения": "1980-11-15T00:00:00"
    },
    {
      "Description": "Александров Дмитрий Олегович",
      "ДатаРождения": "1977-08-04T00:00:00"
    }
  ]
}

Как видно, ответ на запрос такой же, как в разделе 6.2.4, только добавилась строка:

"odata.count": "28",

Это означает, что условиям отбора удовлетворяют 28 записей. Обратите внимание, что в ответе показаны сведения лишь о трех записях, так как использован параметр $top=3.

6.2.6. Использование функций при отборе

В запросе OData, выдающем список, можно использовать функции (см. раздел 5.10):

• при задании условий отбора (параметр $filter, см. раздел 5.7.1);
• при задании порядка сортировки результатов (параметр $orderby, см. раздел 5.7.2).

Покажем пример использования функции при задании условий отбора. Выведем список наименований и артикулов первых трех записей справочника Номенклатура, в которых наименование начинается со строки ‘Таз’.

Для проверки будем использовать функцию startswith. Введем такой запрос:

GET ПрефиксURL/Catalog_Номенклатура?$format=json&$filter=startswith(НаименованиеПолное,'Таз')&$select=НаименованиеПолное,Артикул&$top=3

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Номенклатура",
  "value": [
    {
      "НаименованиеПолное": "Таз пластмассовый овальный с ручками ("POBEDA"), 25 л",
      "Артикул": "8940"
    },
    {
      "НаименованиеПолное": "Таз пластмассовый овальный с ручками ("POBEDA"), 35 л",
      "Артикул": "8941"
    },
    {
      "НаименованиеПолное": "Таз пластмассовый овальный с ручками ("POBEDA"), 55 л",
      "Артикул": "8942"
    }
  ]
}

6.2.7. Раскрытие подчиненных объектов

Посмотрим, как устроена запись справочника Сотрудники:

GET ПрефиксURL/Catalog_Сотрудники?$format=json&$top=1

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Сотрудники",
  "value": [
    {
      "Ref_Key": "baebacef-b80e-11e4-826f-001e101fe696",
      "DataVersion": "AAAAAAAAAAA=",
      "DeletionMark": false,
      "Parent_Key": "00000000-0000-0000-0000-000000000000",
      "IsFolder": false,
      "Code": "В-02",
      "Description": "Абнагимова Ирина Витальевна",
      "Физлицо_Key": "baebacee-b80e-11e4-826f-001e101fe696",
      "ТипЗанятости": "ОсновноеМестоРаботы",
      "СчетРасчетовСПерсоналом_Key": "60f112fb-b5b8-11e4-8355-74d02b7dfd8c",
      "СчетРасчетовСПодотчетниками_Key": "60f112fd-b5b8-11e4-8355-74d02b7dfd8c",
      "СчетРасчетовПоПерерасходу_Key": "60f112fe-b5b8-11e4-8355-74d02b7dfd8c",
      "Недействителен": false,
      "ШтрихКод": "",
      "МагнитныйКод": "",
      "ДополнительныеРеквизиты": [],
      "Predefined": false,
      "PredefinedDataName": "",
      "Физлицо@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/Физлицо",
      "СчетРасчетовСПерсоналом@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/СчетРасчетовСПерсоналом",
      "СчетРасчетовСПодотчетниками@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/СчетРасчетовСПодотчетниками",
      "СчетРасчетовПоПерерасходу@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/СчетРасчетовПоПерерасходу"
    }
  ]
}

Как видно, в этой записи есть реквизит Физлицо_Key. Это ссылка на запись справочника ФизическиеЛица. Попросим включить эту запись в ответ интерфейса OData. Для этого добавим к запросу параметр $expand=Физлицо. Введем запрос:

GET ПрефиксURL/Catalog_Сотрудники??$format=json&$top=1&$expand=Физлицо

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Сотрудники",
  "value": [
    {
      "Ref_Key": "baebacef-b80e-11e4-826f-001e101fe696",
      "DataVersion": "AAAAAAAAAAA=",
      "DeletionMark": false,
      "Parent_Key": "00000000-0000-0000-0000-000000000000",
      "IsFolder": false,
      "Code": "В-02",
      "Description": "Абнагимова Ирина Витальевна",
      "Физлицо_Key": "baebacee-b80e-11e4-826f-001e101fe696",
      "ТипЗанятости": "ОсновноеМестоРаботы",
      "СчетРасчетовСПерсоналом_Key": "60f112fb-b5b8-11e4-8355-74d02b7dfd8c",
      "СчетРасчетовСПодотчетниками_Key": "60f112fd-b5b8-11e4-8355-74d02b7dfd8c",
      "СчетРасчетовПоПерерасходу_Key": "60f112fe-b5b8-11e4-8355-74d02b7dfd8c",
      "Недействителен": false,
      "ШтрихКод": "",
      "МагнитныйКод": "",
      "ДополнительныеРеквизиты": [],
      "Predefined": false,
      "PredefinedDataName": "",
      "Физлицо@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/Физлицо",
      "Физлицо": {
        "Parent_Key": "00000000-0000-0000-0000-000000000000",
        "Гражданство_Key": "00000000-0000-0000-0000-000000000000",
        "БанковскийСчетПоУмолчанию_Key": "00000000-0000-0000-0000-000000000000",
        "DeletionMark": false,
        "IsFolder": false,
        "DataVersion": "AAAAAAAAAAA=",
        "ИНН": "",
        "ДатаРождения": "1947-08-05T00:00:00",
        "Недействителен": false,
        "Predefined": false,
        "Ref_Key": "baebacee-b80e-11e4-826f-001e101fe696",
        "Code": "ФР-0000002",
        "Description": "Абнагимова Ирина Витальевна",
        "СтраховойНомерПФР": "",
        "Пол": "Женский",
        "КонтактнаяИнформация": [],
        "PredefinedDataName": "",
        "ДополнительныеРеквизиты": []
      },
      "СчетРасчетовСПерсоналом@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/СчетРасчетовСПерсоналом",
      "СчетРасчетовСПодотчетниками@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/СчетРасчетовСПодотчетниками",
      "СчетРасчетовПоПерерасходу@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/СчетРасчетовПоПерерасходу"
    }
  ]
}

6.2.8. Раскрытие подчиненных объектов и отбор отображаемых реквизитов

Пусть нам нужны только ФИО, код, тип занятости, дата рождения и пол сотрудника. Переформулируем запрос так, чтобы получать только эту информацию. Для этого добавим в запрос параметр:

$expand=Физлицо&$select=Description,Code,ТипЗанятости,Физлицо/Пол,Физлицо/ДатаРождения

Так как реквизиты Пол и ДатаРождения входят в подчиненный объект Физлицо, то они указываются в параметре $select как Физлицо/Пол и Физлицо/ДатаРождения. Получается следующий запрос:

GET ПрефиксURL/Catalog_Сотрудники?$format=json&$top=1&$expand=Физлицо&$select=Description,Code,ТипЗанятости,Физлицо/Пол,Физлицо/ДатаРождения

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Сотрудники",
  "value": [
    {
      "Description": "Абнагимова Ирина Витальевна",
      "Code": "В-02",
      "ТипЗанятости": "ОсновноеМестоРаботы",
      "Физлицо@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/Физлицо",
      "Физлицо": {
        "Пол": "Женский",
        "ДатаРождения": "1947-08-05T00:00:00"
      }
    }
  ]
}

6.2.9. Сортировка результатов

Упорядочим записи справочника Сотрудники по реквизитам Тип занятости и Code, и выведем значения реквизитов Тип занятости, Code и Description для первых 3 записей упорядоченного списка. Для упорядочения записей в запросе нужно указать параметр $orderby=ТипЗанятости desc,Code:

GET ПрефиксURL/Catalog_Сотрудники?$format=json&$orderby=ТипЗанятости desc,Code&$select=Description,Code,ТипЗанятости&$top=3

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Сотрудники",
  "value": [
    {
      "Description": "Администратор",
      "Code": "",
      "ТипЗанятости": "ОсновноеМестоРаботы"
    },
    {
      "Description": "Абдулов Юрий Владимирович",
      "Code": "В-01",
      "ТипЗанятости": "ОсновноеМестоРаботы"
    },
    {
      "Description": "Абнагимова Ирина Витальевна",
      "Code": "В-02",
      "ТипЗанятости": "ОсновноеМестоРаботы"
    }
  ]
}

6.2.10. Сортировка по полям подчиненного объекта

Пусть нам нужно получить сведения о сотрудниках, упорядоченные по полу, типу занятости и коду. Пол сотрудника хранится в подчиненном объекте Физлицо. Поэтому в запрос нужно включить:

• параметр $expand=Физлицо, включающий в ответ содержимое объекта Физлицо, а не только ссылку на этот объект;
• строку Физлицо/Пол в значения параметров $orderby и $select, чтобы сведения о поле сотрудника учитывались при сортировке результатов и выводились в результатах запроса.

Получается запрос следующего вида:

GET ПрефиксURL/Catalog_Сотрудники?$format=json&$expand=Физлицо&$select=Description,Code,ТипЗанятости,Физлицо/Пол&$orderby=Физлицо/Пол,Code,Description&$top=3

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Сотрудники",
  "value": [
    {
      "Description": "Абдулов Юрий Владимирович",
      "Code": "В-01",
      "ТипЗанятости": "ОсновноеМестоРаботы",
      "Физлицо@navigationLinkUrl": "Catalog_Сотрудники(guid'b770ac08-b76d-11e4-be02-74d02b7dfd8c')/Физлицо",
      "Физлицо": {
        "Пол": "Мужской"
      }
    },
    {
      "Description": "Аввакумов Вадим Иванович",
      "Code": "В-04",
      "ТипЗанятости": "ОсновноеМестоРаботы",
      "Физлицо@navigationLinkUrl": "Catalog_Сотрудники(guid'baebacfa-b80e-11e4-826f-001e101fe696')/Физлицо",
      "Физлицо": {
        "Пол": "Мужской"
      }
    },
    {
      "Description": "Аввакумов Вадим Иванович",
      "Code": "В-05",
      "ТипЗанятости": "Совместительство",
      "Физлицо@navigationLinkUrl": "Catalog_Сотрудники(guid'baebad04-b80e-11e4-826f-001e101fe696')/Физлицо",
      "Физлицо": {
        "Пол": "Мужской"
      }
    }
  ]
}

6.3. Работа с отдельными объектами

С помощью стандартного интерфейса OData можно не только получать списки объектов, но также читать, изменять, создавать и удалять отдельные объекты. Покажем эти действия на примерах.

6.3.1. Получение записи

Получим запись справочника ФизическиеЛица с ключом baebad03-b80e-11e4-826f-001e101fe696:

GET ПрефиксURL/Catalog_ФизическиеЛица(guid'baebad03-b80e-11e4-826f-001e101fe696')?$format=json

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица/@Element",
  "Гражданство_Key": "00000000-0000-0000-0000-000000000000",
  "КонтактнаяИнформация": [],
  "ДополнительныеРеквизиты": [],
  "БанковскийСчетПоУмолчанию_Key": "00000000-0000-0000-0000-000000000000",
  "Недействителен": false,
  "DeletionMark": false,
  "ДатаРождения": "1966-06-04T00:00:00",
  "Пол": "Мужской",
  "Ref_Key": "baebad03-b80e-11e4-826f-001e101fe696",
  "Description": "Аввакумов Вадим Иванович",
  "IsFolder": false,
  "PredefinedDataName": "",
  "DataVersion": "AAAAAAAAAAA=",
  "Code": "ФР-0000003",
  "Parent_Key": "00000000-0000-0000-0000-000000000000",
  "СтраховойНомерПФР": "",
  "ИНН": "",
  "Predefined": false
}

6.3.2. Чтение записи с отбором отображаемых реквизитов

Получим ту же запись справочника, но выведем только ФИО, пол и дату рождения. Для этого нужно добавить в запрос параметр $select=Description,Пол,ДатаРождения:

GET ПрефиксURL/Catalog_ФизическиеЛица(guid'baebad03-b80e-11e4-826f-001e101fe696')?$format=json&$select=Description,Пол,ДатаРождения

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица/@Element",
  "Description": "Аввакумов Вадим Иванович",
  "ДатаРождения": "1966-06-04T00:00:00",
  "Пол": "Мужской"
}

6.3.3. Раскрытие подчиненных объектов и отбор отображаемых реквизитов

При получении одной записи справочника нельзя сразу же раскрыть содержимое подчиненных объектов с помощью оператора $expand. Как было сказано ранее, этот оператор применим только при получении списка элементов. Если требуется получить ФИО, код, тип занятости, дату рождения и пол конкретного сотрудника, то для этого придется выполнить два запроса. Первым запросом получаем ФИО, код, тип занятости сотрудника из записи справочника Сотрудники:

GET ПрефиксURL/Catalog_Сотрудники(guid'baebacfa-b80e-11e4-826f-001e101fe696')?$format=json&$select=Description,Code,ТипЗанятости

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Сотрудники/@Element",
  "ТипЗанятости": "ОсновноеМестоРаботы",
  "Code": "В-04",
  "Description": "Аввакумов Вадим Иванович"
}

Вторым запросом получаем дату рождения и пол из подчиненного объекта Физлицо. Чтобы обратиться к подчиненному объекту, добавляем в URL после выбора записи справочника строку /Физлицо:

GET ПрефиксURL/Catalog_Сотрудники(guid'baebacef-b80e-11e4-826f-001e101fe696')/Физлицо?$format=json&$select=Пол,ДатаРождения

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица/@Element",
  "Пол": "Мужской",
  "ДатаРождения": "1966-06-04T00:00:00"
}

6.3.4. Исправление данных

Исправим данные записи справочника ФизическиеЛица, которую мы получили в разделе 6.3.1. А именно, заменим значение ИНН на ‘772800173088’, а год рождения на 1987.

Для этого можно применить PATCH-запрос:

PATCH ПрефиксURL/Catalog_ФизическиеЛица(guid'baebad03-b80e-11e4-826f-001e101fe696')?$format=json

В теле этого запроса необходимо передать JSON-объект с исправленными данными:

{
    "ИНН": "772800173088",
    "ДатаРождения": "1987-06-04T00:00:00"
}

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица/@Element",
  "DeletionMark": false,
  "ИНН": "772800173088",
  "Parent_Key": "00000000-0000-0000-0000-000000000000",
  "Code": "ФР-0000003",
  "БанковскийСчетПоУмолчанию_Key": "00000000-0000-0000-0000-000000000000",
  "Недействителен": false,
  "Predefined": false,
  "КонтактнаяИнформация": [],
  "ДополнительныеРеквизиты": [],
  "ДатаРождения": "1987-06-04T00:00:00",
  "Пол": "Мужской",
  "Description": "Аввакумов Вадим Иванович",
  "Гражданство_Key": "00000000-0000-0000-0000-000000000000",
  "IsFolder": false,
  "PredefinedDataName": "",
  "Ref_Key": "baebad03-b80e-11e4-826f-001e101fe696",
  "DataVersion": "AAAAAAAAAAE=",
  "СтраховойНомерПФР": ""
}

Как видно, результат запроса — это исправленная запись справочника ФизическиеЛица. Реквизиты ИНН и ДатаРождения в ней получили новые значения.

При желании можно вывести карточку этого физического лица в приложении (меню Персонал — Физические лица), и убедиться, что в карточке показаны исправленные значения реквизитов ИНН и Дата рождения.

6.3.5. Добавление

Добавим в справочник ФизическиеЛица новую запись. Для этого можно использовать POST-запрос:

POST ПрефиксURL/Catalog_ФизическиеЛица?$format=json

В теле этого запроса необходимо передать JSON-объект с данными записи справочника:

{
    "DeletionMark": false,
    "Parent_Key": "00000000-0000-0000-0000-000000000000",
    "IsFolder": false,
    "Code": "ФР-0000041",
    "Description": "Иванов Андрей Борисович",
    "ДатаРождения": "1992-12-13T00:00:00",
    "Пол": "Мужской",
    "ИНН": "772800192179",
    "СтраховойНомерПФР": "",
    "Гражданство_Key": "00000000-0000-0000-0000-000000000000",
    "Недействителен": false,
    "БанковскийСчетПоУмолчанию_Key": "00000000-0000-0000-0000-000000000000",
    "КонтактнаяИнформация": [],
    "ДополнительныеРеквизиты": [],
    "Predefined": false,
    "PredefinedDataName": ""
}

Как видно, здесь указаны те же реквизиты, которые получены при чтении записи справочника (см. раздел 6.3.1), только без служебных реквизитов odata.metadata, DataVersion и Ref_Key.

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_ФизическиеЛица/@Element",
  "Description": "Иванов Андрей Борисович",
  "ИНН": "772800192179",
  "ДатаРождения": "1992-12-13T00:00:00",
  "PredefinedDataName": "",
  "ДополнительныеРеквизиты": [],
  "DataVersion": "AAAAAAAAAAA=",
  "Ref_Key": "1683a3cc-44e5-11ed-8d7b-005056892602",
  "СтраховойНомерПФР": "",
  "Гражданство_Key": "00000000-0000-0000-0000-000000000000",
  "IsFolder": false,
  "КонтактнаяИнформация": [],
  "Predefined": false,
  "Пол": "Мужской",
  "БанковскийСчетПоУмолчанию_Key": "00000000-0000-0000-0000-000000000000",
  "Code": "ФР-0000041",
  "Parent_Key": "00000000-0000-0000-0000-000000000000",
  "DeletionMark": false,
  "Недействителен": false
}

Как видно, результат запроса содержит сведения о добавленной записи справочника ФизическиеЛица.

При желании можно вывести в приложении форму справочника ФизическиеЛица (меню Персонал — Физические лица) и убедиться, что в справочнике имеется добавленная запись.

6.3.6. Удаление

Удалим созданную запись из справочника ФизическиеЛица. Для этого можно использовать DELETE-запрос:

DELETE ПрефиксURL/Catalog_ФизическиеЛица(guid'1683a3cc-44e5-11ed-8d7b-005056892602')

В запросе указывается ключ (guid) той записи, которую нужно удалить.

Ответ на запрос будет с HTTP-кодом состояния 204 No content и пустым телом. При желании можно вывести в приложении форму справочника ФизическиеЛица и убедиться, что запись удалена из справочника.

Внимание. Следует иметь в виду, что при удалении объектов посредством стандартного интерфейса OData пометка на удаление не выполняется, а объект удаляется непосредственно.

6.4. Работа с табличными частями

Стандартный интерфейс OData содержит специальные средства для работы с табличными частями документов, справочников, задач и бизнес-процессов. Покажем их использование на примерах.

6.4.1. Отбор по значениям реквизитов табличных частей

Покажем пример применения функции any. Выведем список документов ЗаказПокупателя, в табличной части Запасы которых имеется хотя бы один товар с ценой большей 50000. В списке покажем только номера, даты и guid документов.

Отбор будет выполнен с помощью указания параметра $filter=Запасы/any(d: d/Цена gt 50000). Синтаксис функций all и any был объяснен в разделе 5.10.3.

Можно использовать следующий запрос:

GET ПрефиксURL/Document_ЗаказПокупателя?$format=json&$select=Number,Date,Ref_Key&$filter=Запасы/any(d: d/Цена gt 50000)

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Document_ЗаказПокупателя",
  "value": [
    {
      "Number": "АСФР-000068",
      "Date": "2017-08-14T12:00:00",
      "Ref_Key": "5977a565-4afc-11e5-808c-74d02b7dfd8c"
    },
    {
      "Number": "АСФР-000026",
      "Date": "2018-03-04T17:43:55",
      "Ref_Key": "e558b378-e040-11e5-9ef1-bcaec5b897eb"
    },
    {
      "Number": "АСФР-000030",
      "Date": "2018-03-18T10:45:53",
      "Ref_Key": "f1a6853a-e5c7-11e5-9ef1-bcaec5b897eb"
    },
    {
      "Number": "АСФР-000032",
      "Date": "2018-04-06T17:34:54",
      "Ref_Key": "f1a6855e-e5c7-11e5-9ef1-bcaec5b897eb"
    }
  ]
}

6.4.2. Чтение табличных частей

В OData-запросе можно вывести список табличных частей объектов. Предположим, что мы хотим получить список типов и представлений контактной информации для записей справочника Организации. Для этого можно использовать следующий запрос:

GET ПрефиксURL/Catalog_Организации_КонтактнаяИнформация/?$format=json&$top=5&$select=Тип,Представление

Здесь мы запросили сведения только о 5 первых строках табличных частей (параметр $top=5). Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Организации_КонтактнаяИнформация",
  "value": [
    {
      "Тип": "АдресЭлектроннойПочты",
      "Представление": "assol@mail.ru"
    },
    {
      "Тип": "АдресЭлектроннойПочты",
      "Представление": "sborka@mail.ru"
    },
    {
      "Тип": "Телефон",
      "Представление": "(495) 5552255, доб. 702"
    },
    {
      "Тип": "Телефон",
      "Представление": "(495) 502-77-55"
    },
    {
      "Тип": "Факс",
      "Представление": "(495) 5553322"
    }
  ]
}

Как видно, для обращения к строкам табличной части КонтактнаяИнформация справочника Организации используется обозначение Catalog_Организации_КонтактнаяИнформация.

6.4.3. Отбор строк табличных частей

В OData-запросе к табличной части можно задать условие отбора. Предположим, что мы заметили неточность в электронной почте assol@mail.ru. Получим все сведения строки табличной части, в которой указана эта электронная почта. Для этого можно использовать следующий запрос:

GET ПрефиксURL/Catalog_Организации_КонтактнаяИнформация/?$format=json&$filter=Представление eq 'assol@mail.ru'

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Catalog_Организации_КонтактнаяИнформация",
  "value": [
    {
      "Ref_Key": "6e3445bb-b5b8-11e4-8355-74d02b7dfd8c",
      "LineNumber": "2",
      "Тип": "АдресЭлектроннойПочты",
      "Вид_Key": "6e34475f-b5b8-11e4-8355-74d02b7dfd8c",
      "Представление": "assol@mail.ru",
      "ЗначенияПолей": "<КонтактнаяИнформация xmlns="http://www.v8.1c.ru/ssl/contactinfo" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Представление="assol@mail.ru"><Комментарий/><Состав xsi:type="ЭлектроннаяПочта" Значение="assol@mail.ru"/>",
      "Страна": "",
      "Регион": "",
      "Город": "",
      "АдресЭП": "assol@mail.ru",
      "ДоменноеИмяСервера": "mail.ru",
      "НомерТелефона": "",
      "НомерТелефонаБезКодов": "",
      "Значение": "",
      "ВидДляСписка_Key": "6e34475f-b5b8-11e4-8355-74d02b7dfd8c",
      "ДействуетС": "0001-01-01T00:00:00",
      "Вид@navigationLinkUrl": "Catalog_Организации_КонтактнаяИнформация(Ref_Key=guid'6e3445bb-b5b8-11e4-8355-74d02b7dfd8c', LineNumber=2)/Вид",
      "ВидДляСписка@navigationLinkUrl": "Catalog_Организации_КонтактнаяИнформация(Ref_Key=guid'6e3445bb-b5b8-11e4-8355-74d02b7dfd8c', LineNumber=2)/ВидДляСписка"
    }
  ]
}

6.4.4. Чтение табличной части объекта

Для показа табличной части объекта можно задать параметр $select=имя-табличной-части. Например, для показа табличной части Запасы документа Доверенность с guid 98043082-f588-11e5-98a6-bcaec5b897eb можно использовать следующий запрос:

GET ПрефиксURL/Document_Доверенность(guid'98043082-f588-11e5-98a6-bcaec5b897eb')/?$format=json&$select=Запасы

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Document_Доверенность/@Element",
  "Запасы": [
    {
      "LineNumber": "1",
      "НаименованиеТовара": "Ручка",
      "ЕдиницаИзмерения": "шт",
      "Количество": 1
    }
  ]
}

Другой способ — указать слеш / и имя табличной части после операции выбора объекта:

GET ПрефиксURL/Document_Доверенность(guid'98043082-f588-11e5-98a6-bcaec5b897eb')/Запасы?$format=json

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Collection(StandardODATA.Document_Доверенность_Запасы_RowType)",
  "value": [
    {
      "LineNumber": "1",
      "НаименованиеТовара": "Ручка",
      "ЕдиницаИзмерения": "шт",
      "Количество": 1
    }
  ]
}

6.4.5. Изменение табличной части

Для изменения табличной части объекта можно использовать PATCH-запрос для объекта, которому принадлежит табличная часть. Например, пусть в документе Доверенность, который мы читали в разделе 6.4.4, нужно изменить в первой строке табличной части количество на 10, и добавить строку табличной части с наименованием Стул и количеством 5. Для этого можно использовать следующий запрос:

PATCH ПрефиксURL/Document_Доверенность(Ref_Key=guid'98043082-f588-11e5-98a6-bcaec5b897eb')/?$format=json

В теле этого запроса необходимо передать JSON-объект с данными табличной части:

{
    "Запасы": [
        {
            "LineNumber": "1",
            "НаименованиеТовара": "Ручка",
            "ЕдиницаИзмерения": "шт",
            "Количество": 10
        },
        {
            "LineNumber": "2",
            "НаименованиеТовара": "Стул",
            "ЕдиницаИзмерения": "шт",
            "Количество": 5
        }
    ]
}

Заметим, что в PATCH-запросе нужно передать все данные табличной части, даже если меняется только один реквизит в одной строке.

В ответе будут выданы данные измененного документе Доверенность.

6.5. Применение методов

Для отдельных видов объектов предусмотрены методы, позволяющие выполнить действия с этими объектами (см. раздел 5.6.5). Покажем два примера:

• проведение и отмена проведения документа;
• применение среза первых для регистра сведений.

6.5.1. Проведение и отмена проведения документа

Покажем возможность проведения и отмены проведения документа на примере документа ЗаказПокупателя. Создадим в приложении заказ покупателя (пункт меню Продажи — Заказы покупателя), например, скопировав один из имеющихся заказов.

Установим для нового заказа состояние Обсуждение КП и заполним дату отгрузки, иначе приложение не позволит провести документ. Сохраним документ, нажав кнопку Записать (не Провести и закрыть).

В приложении в списке заказов покупателя значок данного заказа должен выводиться без галочки, обозначающей, что документ проведен.

Теперь узнаем guid созданного документа, введя запрос:

GET ПрефиксURL/Document_ЗаказПокупателя?$format=json&$orderby=Date desc&$top=1&$select=Ref_Key,Number,Date,Posted

Здесь мы сортируем сведения о документах по убыванию даты (параметр $orderby=Date desc), запрашиваем вывод сведений только об одном документе (параметр $top=1) и просим вывести только значения реквизитов Ref_Key, Number, Date и Posted.

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#Document_ЗаказПокупателя",
  "value": [
    {
      "Ref_Key": "f3f4dc08-4553-11ed-8d7b-005056892602",
      "Number": "АСФР-000112",
      "Date": "2022-10-06T11:50:38",
      "Posted": false
    }
  ]
}

Как видно, последний заказ покупателя имеет ключ f3f4dc08-4553-11ed-8d7b-005056892602, и документ не проведен («Posted»: false).

Проведем этот документ, применив к нему метод Post():

POST ПрефиксURL/Document_ЗаказПокупателя(guid'f3f4dc08-4553-11ed-8d7b-005056892602')/Post()

Ответ на запрос будет содержать HTTP-код состояния 200 OK и пустое тело ответа.

Проверим свойства документа. Это можно сделать с помощью приведенного выше GET-запроса. Увидим, что документ проведен («Posted»: true). Также можно обновить в приложении список заказов покупателей и увидеть, что значок заказа содержит галочку, обозначающую, что документ проведен.

При желании можно отменить проведение документа, применив к нему метод Unpost():

POST ПрефиксURL/Document_ЗаказПокупателя(guid'f3f4dc08-4553-11ed-8d7b-005056892602')/Unpost()

Следует иметь в виду, что приложение может, исходя из своей бизнес-логики, отказать в проведении или отмене проведения документа. В этом случае на OData-запрос будет выдан ответ с HTTP-кодом состояния 500. Причину ошибки можно узнать, попробовав провести или отменить проведение документа интерактивно в приложении:

6.5.2. Срез первых для периодического регистра сведений

Покажем применение метода SliceFirst для вывода курса валюты на указанную дату. Формат вызова этого метода: SliceFirst(Period=дата, Condition=’строка-условия‘).

Курсы валют хранятся в периодическом регистре сведений КурсыВалют. Чтобы найти курс валюты USD (доллара США), введем запрос:

GET ПрефиксURL/InformationRegister_КурсыВалют/SliceFirst(Period=datetime'2022-09-30T00:00:00', Condition='Валюта/Description eq 'USD')?$format=json&$expand=Валюта&$select=Курс,Period

Здесь в ответе на OData-запрос раскрывается вложенный объект Валюта и накладывается условие, что значение реквизита Description этого объекта равно USD. Параметр $select=Курс,Period означает, что в ответе нужно вывести только значения реквизитов Курс и Period.

Должен быть выдан примерно такой ответ:

{
  "odata.metadata": "https://1cfresh.com:443/a/sbm_demo/1962515/odata/standard.odata/$metadata#InformationRegister_КурсыВалют",
  "value": [
    {
      "Курс": 57.413,
      "Period": "2022-09-30T00:00:00"
    }
  ]
}

Таким образом, значение курса валюты USD на 30 сентября 2022 г. — 57.413.

---

См. также:

Почему это важно

Давайте на минутку представим, что у нас есть информационные базы на платформе «1С:Предприятие 8», с данными которой нам нужно регулярно работать. Но, к сожалению, у нас нет возможности вносить какие-либо свои правки в их конфигурацию. Возможно это базовые конфигурации (при наличии полноценной платформы); или бесплатная «1С:УНФ для Украины. Микро»; или из-за преимуществ автоматического обновления не хотим снимать поддержку; или обслуживающая компания назвала стоимость своих услуг, которая не получила одобрения у руководства, а собственного «программиста 1С» нет…

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

1. Доступ в базу через семейство COM-объектов (V83.ComConnector и более ранние). Ограничение: платформа должна быть установлена на Windows.
2. Непосредственный доступ в таблицы базы данных. Вот пример для СУБД. Вот пример для файловой базы. Ограничение: запрет непосредственного доступа к данным в лицензионном соглашении; нестабильность полученного доступа; изменение данных может привести к нарушению логической целостности базы.
3. Начиная с версии платформы 8.3.5 появилась возможность предоставить доступ к данным через автоматический REST-интерфейс на основе протокола OData v.3.0. Ограничение: необходимо установить веб-сервер и модуль расширения веб-сервера из поставки платформы.
4. Начиная с версии платформы 8.3.6 появился механизм расширений, который позволяет «пристегнуть» новую функциональность без внесения изменений в основную конфигурацию. В числе новой функциональности есть интересные нам WEB- и HTTP-сервисы. Начиная с версии платформы 8.3.11 стала доступной возможность расширения структуры таблиц  базы данных (добавление новых реквизитов для хранения служебных данных в целях интеграции). Ограничение: необходимо наличие программиста, который разработает расширение и будет следить за его работоспособностью при обновлениях; для сервисов необходимо установить веб-сервер и модуль расширения веб-сервера из поставки платформы.
5. Можно отказаться от «мгновенного доступа» и тогда можем использовать запуск внешних обработок с помощью параметра командной строки /Execute. В таком сценарии можно сделать регулярный запуск по расписанию некоторой обработки, которая будет проверять внешний ресурс на наличие инструкций к выполнению и помещать туда результаты своей работы. Так же можно самостоятельно запускать клиентское приложение 1С на отработку своих команд, если есть доступ к ОС, в которой находится база. Ограничение: необходимо наличие программиста, который создаст обработку; наличие временного лага в реакции системы на значение промежутка между запусками в планировщике или на время старта клиентского приложения.

Таким образом среди 5 вариантов самым быстрым и самым легким для администратора способом является автоматический доступ через протокол oData. Этот же вариант является кроссплатформенным.

А еще вариант с протоколом oData менее затратен с точки зрения разработки связки с базой 1С. Дело в том, что компания Microsoft усиленно его продвигает. Помимо выпуска OData SDK для разработки под .NET, AJAX, PHP, Java, JavaScript, WebOS и Objective-C, эта компания внедрила данный протокол в свои популярные продукты: Excel, PowerPoint, SharePoint, MsSQL и других. Таким образом вам не нужно создавать свою версию CommerceML и заниматься разбором XML и JSON текстов как на вашей стороне так и на стороне базы 1С, как если бы вы реализовывали свои собственные WEB- и HTTP-сервисы. При использовании OData у вас уже сразу будут готовые библиотеки для получения или модификации данных для применения в вашей внешней системе, в то время как на стороне базы 1С все будет происходит автоматически.

Для тех, кто заинтересовался темой, прошу перейти на официальный сайт протокола — www.odata.org. Еще раз обращаю внимание, что не смотря на то, что актуальная версия протокола уже 4.0 и она была стандартизирована консорциумом OASIS еще 17 марта 2014 года, но в платформе «1С:Предприятие 8» по прежнему используется протокол более ранней версии 3.0. Кстати, не забудьте заглянуть в раздел экосистемы протокола и полюбоваться на упоминание нашей 1C:Enterprise, которая идет первой в списке :))

---

Необходимые настройки

Как я уже упоминал, у вас должен быть веб-сервер. Начиная с версии 8.4 в составе серверной части платформы уже будет свой собственный веб-сервер, но пока нам нужно пользоваться сторонними — IIS или Apache. Как все настроить хорошо описано в желтой книжечке для администратора. Но если вы любите картинки и чужой опыт, то вот надергал в поиске: пошаговая инструкция по установке Apache на Windows, установка Apache на Linux и конечно же IIS для чайников 🙂 За полноту и актуальность предоставленных данных в указанных статьях не ручаюсь и вообще не знаком с авторами. Если возникнут проблемы, то читайте Руководство Администратора от вашей версии платформы — там есть все, что вам пригодится. 

После того, как у вас уже установлен веб-сервер и он уже не падает при запуске из-за проблем с расширением доступа к 1С (давайте угадаю — вы поставили 32-разрядный Apache и 64-разрядную платформу), осталось совсем чуть-чуть. В конфигураторе заходим в меню «Администрирование» и нажимаем на команду «Публикация на веб-сервере…». В появившемся окошке необходимо указать следующие важные моменты:

• Название вашей базы в поле «Имя», по которой веб-сервер будет предоставлять к ней доступ (если не хотите проблем, то не пишите на кириллице);
• Укажите веб-сервер, который установлен на данном компьютере (если у вас установлено целых два веб-сервера, то в выпадающем списке будет выбор);
• Путь к каталогу публикации, к которому должен быть доступ у вашего выбранного веб-сервера;
• И самое главное — галочка «Публиковать стандартный интерфейс OData»!

После нажатия на кнопку «Опубликовать» по указанному в настройке пути будет создан файл default.vrd (XML-файл, который содержит данные, которые вы сделали в настройках публикации), а в конфиге веб-сервера будет добавлена запись о вашей публикации с тем именем, что вы указали. После публикации веб-сервер стоит перегрузить.

Несколько замечаний по выполнению публикации. Если у вас к публикации несколько баз, то для каждой из них должен быть свой каталог. Сразу подумайте о пользователе, которым собираетесь получать доступ к базе — у него должны быть нужные роли и имя латинскими буквами без спецсимволов (если вам в будущем охота воевать с кодировками, то можете сделать имя на русском с пробелами). Если вы работаете на Windows и у вас включен UAC, то перед публикацией конфигуратор следуют запускать от имени администратора. Если вы работаете на Linux — держитесь, мы в вас верим! 🙂

Вот как выглядит рабочий default.vrd с публикацией интерфейса OData:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/DemoTrdBase"
ib="File=&quot;D:WORKBaseDemoTrdBase&quot;;"
enable="false">
<standardOdata enable="true"
reuseSessions="autouse"
sessionMaxAge="20"
poolSize="10"
poolTimeout="5"/>
</point>

Как видно из файла публикации — веб-серверу абсолютно все равно, где физически находится информационная база, путь к ней прописывается точно так же, как вы его прописываете в списке баз начального окна. Главное, что бы на одном компьютере с веб-сервером было установлено расширение доступа и местонахождение базы было по сети физически доступно для службы веб-сервера с правами на изменение. Так же возможны проблемы с получением лицензии и нужно будет покопаться в файле nethasp.ini, но это все стандартные процедуры и для обычной установки платформы.

После того, как вы выполнили публикацию и перезапустили сервер, можем проверить результаты в браузере. Для этого нужно указать имя веб-сервера, далее имя базы из публикации, далее путь /odata/standard.odata/ . У вас должны запросить пароль и вы увидите, что-то похожее на это:

Что бы продемонстрировать возможности рассматриваемой в статье технологии, я взял конфигурацию «»Управление торговлей (базовая)», редакция 10.3″, в которой установлен режим совместимости «Версия 8.2.13» и потому все метаданные через REST-интерфейс доступны сразу, а вызов функции УстановитьСоставСтандартногоИнтерфейсаOData() для управления доступностью состава запрещен.

Если  же у вас имеется доработанная торговля 10.3, которой вы установили режим совместимости «Версия 8.3.5» или выше, или если у вас есть более современные конфигурации, то все метаданные по умолчанию будут скрыты и вам нужно будет воспользоваться специальной обработкой для указания видимости требуемых данных. Что бы не тратить время на создание своей обработки, можете воспользоваться моей работой, которая годится как для обычного так и для управляемого интерфейсов (см. вложения).

---

А что же дальше?

Думаю, что можно вас поздравить — у вас все настроено и работает! Какие же следующие шаги? Все зависит от того, зачем вам нужно было организовывать доступ к базе — для обмена информацией с корпоративным сайтом, для работы мобильного приложения, для связки с корпоративным ПО…

Если требуется сделать на сайте что-то типа кабинета пользователя с предоставлением истории взаиморасчетов, действующих цен с учетом персональных скидок, ввода заказа и прочими плюшками, то к нашим услугам есть несколько готовых библиотек на официальном сайте. Есть даже целый фреймворк OpenUI5 от компании SAP, который на базе данных получаемых по протоколу OData позволяет создать полноценное бизнес-приложение. В общем, раздолье для грамотного JS-программиста.

Допустим, что мы не грамотные JS-программисты, но какой-то списочек повесить на сайт хотим. Я открыл статью с перечнем самых популярных на сегодняшний день библиотек создания таблиц и нашел в нем простенькую библиотечку jsGrid как раз для нашего случая. Изучаем их сайт, берем пример их кода по использованию OData и вставляем туда путь к нашим данным.

Что бы совсем быть ленивым и ничего не программировать для нашего примера, мне нужно запросить полноценную табличку без необходимости по ссылкам догружать строковые представления. В типовой УТ10.3 на этот счет выбор не очень богатый и потому я возьму справочник Контрагенты.

Теперь самое интересное. А как же сформировать строку запроса на чтение нужных нам данных? Это просто! Смотрим по нашему пути к корню OData (для меня это http://localhost/DemoTrdBase/odata/standard.odata/) как правильно называется этот справочник — Catalog_Контрагенты. Далее открыв в новом окне адрес http://localhost/DemoTrdBase/odata/standard.odata/Catalog_Контрагенты мы увидим содержимое всего справочника в формате XML. Но для нашего примера нужен JSON и потому к строке нужно добавить параметр: $format=json — получится http://localhost/DemoTrdBase/odata/standard.odata/Catalog_Контрагенты?$format=json. Так, группы нам не интересны и давайте их уберем с помощью параметра фильтрации: $filter=IsFolder eq false — получится http://localhost/DemoTrdBase/odata/standard.odata/Catalog_Контрагенты?$format=json&$filter=IsFolder eq false. Блок параметров, как вы уже заметили начинается символом «?», а сами параметры между собой соединяются символом «&». Полный список доступных параметров и функций смотрите в документации по платформе.

Полученный файл положим в каталог, который настроен корневым в вашем веб-сервере. Это необходимо, что бы «домены» странички и запрашиваемых данных совпадали, иначе получите бесконечный индикатор обновления и ошибку в логах: «No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access. The response had HTTP status code 401.«

Буквально несколько минут затраченного времени и у нас уже приличная табличка, которая даже автоматически размечена на странички. Немного неуклюже смотрится только запрос аутентификации и, что бы не вводить каждый раз логин и пароль, я их прописал сразу в строке доступа. Конечный файлик получился довольно простой и каждый сможет его с легкостью повторить, но на всякий случай я его тоже размещу во вложения.

---

А совсем без программирования?

Сайты, мобильные приложения, шина сообщений и прочие слова для любого айтишника звучат круто, но не находят отклика в сердцах высоких начальников. Их главный рабочий инструмент Excel, к которому они пылают иррациональной любовью даже при наличии мощной подсистемы отчетности из их баз 1С. И в этот момент мы вспоминаем, что именно компания Microsoft придумала стандарт OData и внедрила его в свои программы начиная с Office 2010. В офисных программах мы можем как просто просматривать таблицы с данными, так и воспользоваться механизмами запросов для получения более интересной информации за один раз без необходимости соединять таблицы с разных листов.

К примеру, нас интересуют должники. В УТ10 мы их можем получить из виртуальной таблицы остатков регистра накопления ВзаиморасчетыСКонтрагентами, наложив фильтр что бы сумма долга была больше нуля (иначе это авансы). Задавать дату не буду, так как меня интересуют актуальные данные. Для моей базы это будет следующая ссылка: http://localhost/DemoTrdBase/odata/standard.odata/AccumulationRegister_ВзаиморасчетыСКонтрагентами/Balance?$filter=СуммаУпрBalance gt 0

Просмотрев результат, мы можем заметить, что у нас нет представлений для контрагентов, а только ключи для таблицы справочника контрагентов. Следовательно будем запрашивать и эти вспомогательные данные. Для этого воспользуемся ссылкой без фильтров:  http://localhost/DemoTrdBase/odata/standard.odata/Catalog_Контрагенты

А теперь простая последовательность шагов:

1. Открываем Excel (у меня версия 2023; если у вас 2010 или 2013, то меню может немного отличаться)
2. Переходим по навигационному пути: «Данные» / «Создать запрос» / «Из других источников» / «Из канала ODATA».
3. Указываем нашу ссылку на регистр взаиморасчетов
4. На форме авторизации выберем третий вариант «Базовый» и укажем логин/пароль. Нажимаем «Подключение».
5. В открывшемся окне редактора запроса вместо имени «Запрос1» дадим что-то более для нас интересное — «Взаиморасчеты»
6. В центре окна редактора запроса видим колонку «Список», где в каждой строке слово «Record». Мы можем или воспользоваться контекстной командой «В таблицу» или нажать соответствующую кнопку в меню «Преобразование» редактора. На возникший вопрос ответьте «Ок».
7. Теперь колонка называется «Column1» и рядом с ней появилась кнопочка со стрелками в разные стороны. Нажмите на нее. С сервера подтянется описание существующих колонок. Снимите все галочки и оставьте их только на колонках «Контрагент_Key» и «СуммаУпрBalance». Нажмите на «Ок» и появится таблица из двух выбранных колонок с нужными нам данными.
8. За пределами нашего внимания остались такие измерения как организация, договор и сделка, но они все равно были запрошены. В результате у нас сейчас есть строки контрагентов с разными суммами. Их можно свернуть с помощью группировки. Для этого или из меню или из контекста вызывайте команду «Группировать по». В группировочных полях оставьте только контрагента, а поле с суммой удалите. Назовите новую колонку «Долг», в операции выберите «Сумма», а в столбце укажите поле нашей суммы. Нажмите на «Ок» и в результате получим немного меньше записей.
9. Теперь нам нужно расшифровать контрагентов. Для этого в левой панели «Запросы», где уже есть текущий запрос «Взаиморасчеты», вызовите контекстное меню и выберите «Новый запрос» / «Другие источники» / «Канал ODATA». В появившемся окошке укажем путь к справочнику контрагентов. Далее снова указываем логин/пароль авторизации, в предпросмотре нажимаем «Ок» и зададим новому запросу имя «Контрагенты».
10. Вернемся к запросу «Взаиморасчеты» (клик по названию на панели запросов).
11. Теперь выполняем соединение наших двух запросов. Для этого в основном меню редактора вызовите команду «Комбинировать» / «Объединить запросы». В окне конструктора объединения будет наша таблица взаиморасчетов. В центре в выпадающем окне выберите запрос «Контрагенты». Вид соединения остается тот, который по умолчанию (левое внешнее). Далее кликами выбираем колонки для условия объединения. Соглашаемся со всем что нам далее предлагают. 
12. После объединения мы получили новую колонку «Контрагенты» со знакомой кнопкой с разнонаправленными стрелочками. Кликаем по этой кнопке и выбираем интересующие нас колонки. Для интереса выберем «НаименованиеПолное» и «Parent» (группа). Колонка «Parent» так же предлагает нам раскрыться — выберем в ней поле «Description» (обычное наименование справочника).
13. Сделаем красиво. Первую колонку с ключем контрагента можем удалить. Колонку группы так и назовем «Группа», колонке с именем контрагента дадим название «Контрагенты», а колонку долга перекинем в конец получаемой таблицы.
14. Теперь можем нажать на главную кнопку редактора — «Закрыть и загрузить».
15. Далее можно использовать загруженную таблицу как данные для сводной таблицы или сводной диаграммы. Или при создании этих новых объектов указываем в качестве источника данных наш запрос «Взаиморасчеты».

Но, как говорится, лучше один раз увидеть, чем сто раз услышать. Я постарался записать эту же последовательность действий на видео. И сразу предупреждаю, что у вас при повторе будет немного не так — будет запрошена авторизация, о чем я выше упомянул. Просто на момент записи видео, Excel уже запомнил мои логин и пароль.

---

Итоги

Надеюсь, что моя статья была полезной. Я сообщил о существовании и преимуществах новой технологии платформы. Так же подробно разъяснил настройку доступа в информационную базу по протоколу OData и привел несколько примеров практического использования.

Что бы не было предубеждений, что применять доступ по OData можно исключительно для управляемого интерфейса на последних версиях платформы, я в качестве учебного примера выбрал демо-базу конфигурации «Управление торговлей (базовая), ред 10.3» в режиме совместимости 8.2. Даже на базе данных такой конфигурации, всего несколькими кликами мышки можно получить в книге Excel актуальные данные по долгам и точно так же просто можно было бы получить актуальные остатки на складах, данные по продажам и прочую полезную информацию. 

P.S. Продолжение данной статьи, в котором рассмотрены операции создания и изменения данных, опубликовано по адресу infostart.ru/public/719982