Инструкция: структура фида Обмен с сайтами 

Где находится код

Основная логика формирования фида:

• src/HTTPServices/RestApi/Ext/Module.bsl, обработчик feedsGET.
• src/CommonModules/RestAPI_Методы/Ext/Module.bsl, область feeds.
• src/ExchangePlans/Дев_ОбменССайтомОнлайн/Templates/СхемаВыгрузкиДанных/Ext/Template.xml, макет СКД СхемаВыгрузкиДанных.
• src/ExchangePlans/Дев_ОбменССайтомОнлайн.xml, план обмена и табличная часть ДополнительныеРеквизитыСведения.

Ключевые процедуры и функции:

• ПолучитьДанные_ОбменССайтомОнлайн(Запрос) - проверяет name, token, вызывает формирование данных и возвращает HTTP-ответ.
• ВыполнитьФормированиеДанных_ОбменССайтомОнлайн(УзелОбмена) - собирает итоговую JSON-структуру.
• ПодготовитьДанныеДляВыгрузки_ОбменССайтомОнлайн(Параметры) - получает данные через СКД и дополнительные пакетные запросы.
• ДобавитьЗапросыВПакет(ТекстЗапроса, Параметры) - добавляет к основному СКД-запросу выборки цен, скидок, доп. свойств, файлов и итогового дерева.
• ПолучитьСтруктуру_Район, ПолучитьСтруктуру_Объект, ПолучитьСтруктуру_Секция, ПолучитьСтруктуру_ОН, ПолучитьСтруктуру_Балкон, ПолучитьСтруктуру_Цены, ПолучитьСтруктуру_Скидка, ПолучитьСтруктуру_Свойства - задают состав JSON-объектов.

Endpoint

HTTP-сервис: RestApi.

URL-шаблон: /feeds/{ИмяМетода}.

Метод: GET.

Для получения фида используется:

GET /feeds/feeds?name=<НаименованиеУзлаОбмена>
token: <ТокенУзлаОбмена>

Параметры:

Ответ всегда оборачивается через СтрокаОтвета:

{
  "data": {},
  "success": true,
  "err_msg": ""
}

При ошибках:

Дальше в документе описана структура внутри data.

Общая структура JSON

{
  "data": {
    "complexes": [
      {
        "id": "...",
        "name": "...",
        "company": "...",
        "city": "...",
        "images": ["..."],
        "buildings": [
          {
            "id": "...",
            "name": "...",
            "address": "...",
            "floor_cnt": 0,
            "commissioning_period": "2026-12-31T00:00:00",
            "construction_completion": "2026-09-30T00:00:00",
            "sections": [
              {
                "id": "...",
                "name": "Секция 2",
                "flats": [
                  {
                    "id": "...",
                    "name": "...",
                    "section": "...",
                    "building": "...",
                    "complexe": "...",
                    "prices": [],
                    "discounts": [],
                    "additional_properties": []
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  },
  "success": true,
  "err_msg": ""
}

Иерархия:

1. complexes[] - районы строительства.
2. complexes[].buildings[] - объекты строительства внутри района.
3. complexes[].buildings[].sections[] - секции объекта строительства.
4. complexes[].buildings[].sections[].flats[] - лоты / объекты недвижимости.

Как выбираются данные

Основной набор данных строится через СКД СхемаВыгрузкиДанных плана обмена Дев_ОбменССайтомОнлайн.

В начале выборки создается временная таблица Районы из табличной части узла обмена:

ПланОбмена.Дев_ОбменССайтомОнлайн.Районы

То есть в фид попадают только районы, указанные в настройке конкретного узла обмена.

Основной источник лотов:

РегистрСведений.УПДК_ПараметрыНедвижимости

Сверху к нему подтягиваются:

• статусы из РегистрСведений.УПДК_Недвижимость.СрезПоследних;
• данные аренды из РегистрСведений.АренднаяНедвижимость.СрезПоследних;
• этапы строительства из РегистрСведений.УПДК_ЭтапыСтроительстваОбъектов.СрезПоследних;
• цены из РегистрСведений.УПДК_ФактическиеЦеныНедвижимости;
• собственник из РегистрСведений.УПДК_СобственникиОбъектовНедвижимости.СрезПоследних;
• признак снятия с продаж из РегистрСведений.СнятыеКвартирыСПродаж.СрезПоследних.

Дополнительные пакетные запросы после СКД получают:

• доп. свойства из табличной части узла обмена ДополнительныеРеквизитыСведения и значений объекта недвижимости;
• присоединенные файлы объектов недвижимости;
• присоединенные файлы районов строительства;
• скидки/наценки;
• связанные объекты;
• все фактические цены по объекту недвижимости;
• итоговое дерево Район -> Объект -> Секция -> ОбъектНедвижимости.

complexes[]: район строительства

Источник уровня: СтрокаРайон из итогового дерева ДеревоДанных.

buildings[]: объект строительства / корпус

Источник уровня: СтрокаОбъект из итогового дерева.

Разница commissioning_period и construction_completion

commissioning_period = реквизит объекта строительства СрокВводаВЭксплуатацию.

construction_completion = реквизит объекта строительства СрокОкончанияСтроительства.

По смыслу это разные даты:

• construction_completion - когда строительство должно быть завершено;
• commissioning_period - когда объект должен быть введен в эксплуатацию.

Для сайта нельзя считать эти поля взаимозаменяемыми. Если сайтам нужен квартал/срок сдачи именно по окончанию строительства, нужно брать construction_completion. Если нужен ввод в эксплуатацию - commissioning_period.

Отдельно: в другом описательном API в коде встречается поле construction_completion_date, но в данном фиде используется именно construction_completion.

sections[]: секция

Источник уровня: СтрокаСекция из итогового дерева.

Отдельного поля с номером секции в текущей структуре нет. Сейчас сайт может получить номер только из name, например из строки Секция 2. Это хрупко: если наименование станет 2 секция, Блок А, Секция 2А, парсинг на сайте сломается.

Рекомендация: добавить в ПолучитьСтруктуру_Секция() отдельное поле, например number, и заполнять его из отдельного реквизита секции, если такой реквизит есть в справочнике секций. Если отдельного реквизита нет, лучше добавить его в 1С, а не парсить номер из наименования.

flats[]: объект недвижимости / лот

Источник уровня: СтрокаОН из итогового дерева.

Balconies[]

Источник: табличная часть объекта недвижимости Балконы.

prices[]

Источник: РегистрСведений.УПДК_ФактическиеЦеныНедвижимости.

В массив попадают все цены по объекту недвижимости, где вид цены не помечен на удаление.

Важно по корневым полям price и cost лота: они заполняются не первой ценой из массива, а только той строкой, где ФактическаяЦена.ВидЦены = УПДК_ЦенообразованиеПовтИсп.ПолучитьОсновнойВидЦены(). Если такого вида цены нет среди фактических цен, корневые price и cost останутся пустыми, но массив prices[] может быть заполнен.

discounts[]

Источник: РегистрСведений.УПДК_ФактическиеСкидкиНаценки.СрезПоследних(&Дата, ).

Дополнительные условия:

• берется последний проведенный документ УПДК_РасчетФактическихСкидокНаценок;
• не выгружаются скидки/наценки с признаком СкидкаНаценка.НеВыгружатьНаСайт;
• блок работает, если включена константа ИспользоватьУправляемыеСкидкиНаценки.

additional_properties[]

Это не резерв “на будущее”. Массив реально заполняется текущим кодом.

Логика такая:

1. В узле плана обмена Дев_ОбменССайтомОнлайн есть табличная часть ДополнительныеРеквизитыСведения с синонимом Дополнительные свойства.
2. В этой табличной части выбираются свойства из плана видов характеристик ДополнительныеРеквизитыИСведения.
3. При формировании фида код берет только те свойства, которые указаны в этом узле обмена.
4. Значения берутся из двух источников: - Справочник.УПДК_ОбъектыНедвижимости.ДополнительныеРеквизиты, если свойство является дополнительным реквизитом; - РегистрСведений.ДополнительныеСведения, если свойство является дополнительным сведением.
5. В фид попадает строковое представление значения: Строка(ОписаниеСвойства.Значение).

Структура элемента:

Пример:

{
  "additional_properties": [
    {
      "type": "Число",
      "id": "...",
      "name": "Площадь террасы",
      "value": "12,5"
    },
    {
      "type": "Булево",
      "id": "...",
      "name": "Терраса",
      "value": "Да"
    }
  ]
}

Следствие для сайтовиков: состав additional_properties[] не фиксированный в коде. Он зависит от настройки конкретного узла обмена. Если в узел добавили свойство Погреб, Теплый балкон, Номер парковки, Площадь террасы и у лота есть значение, оно попадет в этот массив. Если свойство не добавлено в узел обмена, оно не выгрузится, даже если заполнено в карточке объекта недвижимости.

Важные нюансы контракта

1. complexe написано с буквой e на конце. Это текущее имя поля в фиде. Если сайт ожидает complex, потребуется отдельное изменение контракта.
2. Balconies начинается с заглавной буквы. Это текущее имя поля в фиде.
3. В sections[] нет отдельного номера секции. Есть только id и name.
4. additional_properties[] динамический и зависит от настройки узла обмена.
5. Часть числовых значений может сериализоваться как число, а часть как строка, потому что в коде местами используется XMLСтрока(...) или Строка(...).
6. Даты commissioning_period и construction_completion сериализуются через ЗаписатьДатуJSON(..., ФорматДатыJSON.ISO).
7. description, address, images и часть файлов ограничиваются ПОДСТРОКА(..., 1, 1000) в запросах.

1. commissioning_period и construction_completion: в чем разница?

commissioning_period - срок ввода объекта строительства в эксплуатацию, источник ОбъектСтроительства.СрокВводаВЭксплуатацию.

construction_completion - срок окончания строительства, источник ОбъектСтроительства.СрокОкончанияСтроительства.

Если сайт определяет “квартал сдачи корпуса”, нужно согласовать бизнес-смысл: ввод в эксплуатацию или окончание строительства. По названию “срок сдачи/окончание строительства” чаще подходит construction_completion, но текущие сайты уже могут использовать commissioning_period, поэтому менять интерпретацию без миграции нельзя.

2. Можно ли получать номер секции отдельным полем?

В текущем фиде отдельного поля номера секции нет. Есть только:

{
  "id": "...",
  "name": "Секция 2",
  "flats": []
}

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

{
  "id": "...",
  "name": "Секция 2",
  "number": "2",
  "flats": []
}

Источник должен быть отдельным реквизитом секции. Если такого реквизита нет, его лучше добавить в 1С. Парсинг из наименования лучше не использовать как постоянное решение.

3. Что может попадать в additional_properties у лота?

В additional_properties попадают только свойства, настроенные в конкретном узле обмена в табличной части Дополнительные свойства (ДополнительныеРеквизитыСведения). Значения берутся из дополнительных реквизитов/сведений объекта недвижимости.

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