fields

Строка fields — какие поля источника попадут в запрос, к какому источнику относится строка и какие записи разбор теряет.

Строка fields: перечисляет поля источника данных, которые попадут в запрос. Она относится к источнику, объявленному строкой выше.

Назначение#

Поля определяют список выборки запроса: что именно Studio прочитает из объекта конфигурации. На вкладке Intent → «Данные» выбранные поля видны флажками в карточке источника.

Синтаксис#

<имя> = <Вид>.<ИмяОбъекта>
  fields: <Поле1>, <Поле2>, /* <временно убранное поле>, */ <Поле3>

Все поля пишутся в одной строке через запятую.

Элементы#

Пример#

spec1c {
  report contracts
    title:  "Договоры и изменения"
    target: ordinary

  data {
    contracts = Справочник.КлиентскиеДоговора
      fields: Ссылка, Код, /* ВидДоговора, */ ДатаДоговора

    amendments = РегистрСведений.ДокументыИзменяющиеУсловияДоговора
      fields: Договор, Период

    rows = contracts
      |> left_join amendments on amendments.Договор == contracts.Ссылка
  }
}

У источника contracts в модели будут поля Ссылка, Код, ДатаДоговора; ВидДоговора закомментировано.

Что принимает разбор#

• Строка относится к последнему источнику, объявленному выше в блоке data. Строка fields: до первого источника или вне блока data пропускается.
• Пустые элементы (A, , B,) отбрасываются.
• Если у источника две строки fields:, действует последняя.
• Продолжение списка на следующей строке не распознаётся: поля со второй строки теряются.
• Точка с запятой не разделяет поля: A; B станет одним полем с именем A; B.
• Текст поля сохраняется как есть: Владелец.Наименование или Код КАК К разбор примет, но в запросе получится неверный псевдоним (см. ниже).

Что попадает в модель#

Для каждого источника — список выбранных полей в порядке записи. Он виден на вкладке Intent → «Данные». При «Применить без сборки» список полей заменяется вместе со всеми источниками (см. data).

Что проверяется#

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

Что генерируется в BSL#

Каждое поле становится строкой выборки <Таблица>.<Поле> КАК <Поле>; сначала поля основного источника, затем присоединённых. Фрагмент живой сборки:

	"ВЫБРАТЬ
	|	КлиентскиеДоговора.Ссылка КАК Ссылка,
	|	КлиентскиеДоговора.Код КАК Код,
	|	КлиентскиеДоговора.ДатаДоговора КАК ДатаДоговора,
	|	ДокументыИзменяющиеУсловияДоговора.Договор КАК Договор,
	|	ДокументыИзменяющиеУсловияДоговора.Период КАК Период
	|ИЗ

При target: managed для каждого поля также генерируется заполнение параметра области макета (живая сборка):

		ОбластьСтрокаМакет.Параметры.Ссылка = Выборка.Ссылка;
		ОбластьСтрокаМакет.Параметры.Код = Выборка.Код;

По исходному коду генератора (живой сборкой не проверялось):

• если одно и то же имя поля есть у двух источников, в выборку попадает только поле первого источника;
• если ни у одного источника нет полей, выбирается Ссылка основного источника;
• поле Владелец.Наименование превратится в … КАК Владелец.Наименование — такой псевдоним в 1С недопустим.

Работа в 1С#

В 1С запросы не выполнялись. Запрос выполнится, если все поля существуют у своих объектов. При target: managed у макета должны быть параметры с теми же именами — в новом файле макета нет (layout и format).

Ограничения#

• Только одна строка на источник, без переноса.
• Нет переименования полей (КАК) и полей через точку.
• Поля источников четырёх видов (регистр бухгалтерии, перечисление, обработка, отчёт) не распознаются и могут переписать поля соседнего источника.
• Одинаковые имена полей у разных источников не различаются.

Полный список — Ограничения реализации.

Связанные конструкции#

• data — объявление источников.
• Соединения: left_join, inner_join, right_join — соединения: поля присоединённого источника идут после полей основного.
• Соответствие конструкций и BSL — соответствие конструкций и кода.

Сверено с продуктом: 27.10.2026