Ключ может быть произвольного типа 1с

Обновлено: 08.01.2025

Формат JSON легко читается. Пример текстового файла в формате JSON:

"ОсновнойПоставщик" : "c8d578e9-9f33-11eb-80ad-364b50b7ef2d"

Как правило JSON используется для обмена данными в веб-приложениях. Однако его можно применять и для обмена данными между двумя базами 1С.

JSON может включать в себя следующие элементы:

• Объект
• Строка
• Число
• Литералы: true, false, null
• Массив

Объект

Значением может быть любой тип:

• Другой JSON-объект
• Массив
• Строка
• Число
• Литералы: true, false, null

В данном примере три ключа:

• ЭтоКлюч
• ЭтоТожеКлюч
• ЭтоВложенныйОбъект

Строка и число

Литералы

В качестве литералов могут использоваться:

Массив

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

ЗаписатьJSON

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

1. Создать программный объект ЗаписьJSON
2. Вызвать у него метод ОткрытьФайл, передав параметром путь к файлу, куда будут записаны данные в формате JSON
3. С помощью метода глобального контекста ЗаписатьJSON выполнить сериализацию. Параметрами нужно передать созданный объект ЗаписьJSON и сами данные
4. Закрыть ЗаписьJSON методом Закрыть

Соответствие между типами 1С и типами JSON:

Тип 1С	Тип JSON
Строка	Строка
Число	Число
Булево	true или false
Дата	Строка
Неопределено	null
Массив	JSON-массив
Фиксированный массив	JSON-массив
Структура	JSON-объект
Фиксированная структура	JSON-объект
Соответствие	JSON-объект
Фиксированное соответствие	JSON-объект

Ключ соответствия и фиксированного соответствия может быть только строковым.

ПараметрыЗаписиJSON = Новый ПараметрыЗаписиJSON ( ПереносСтрокJSON . Авто , Символы . Таб ) ; Запись . ОткрытьФайл ( "F:\test.json" , , , ПараметрыЗаписиJSON ) ; ФиксСтруктура = Новый ФиксированнаяСтруктура ( Структура ) ; ФиксСоответствие = Новый ФиксированноеСоответствие ( Соответствие ) ;

В результате файл будет содержать следующие данные:

В коде была использована строка:

ПараметрыЗаписиJSON = Новый ПараметрыЗаписиJSON ( ПереносСтрокJSON . Авто , Символы . Таб ) ;

Здесь указывается, что при записи JSON нужно использовать перенос строк (первый параметр) и символ табуляции как отступ для каждого элемента JSON (второй параметр). Это нужно чтобы файл с JSON был более читаемым. Если указать первым параметром ПереносСтрокJSON.Нет, то JSON будет записан в одну строку.

Запись массива как JSON-объект

По умолчанию массив сериализуется в JSON-массив. Но в метод ЗаписатьJSON третьим параметром можно передать настройки сериализации JSON, где указать, что массивы нужно записывать как объекты. Ключом будет индекс элемента массива.

ПараметрыЗаписиJSON = Новый ПараметрыЗаписиJSON ( ПереносСтрокJSON . Авто , Символы . Таб ) ; Запись . ОткрытьФайл ( "F:\test.json" , , , ПараметрыЗаписиJSON ) ; Настройки . СериализовыватьМассивыКакОбъекты = Истина;

Сериализация таблицы значений в JSON

Таблица значений является одной из часто используемых коллекций в 1С, но для нее нет автоматической сериализации в JSON. Для сериализации можно преобразовать таблицу в массив структур, а массив сериализовать в JSON:

ПараметрыЗаписиJSON = Новый ПараметрыЗаписиJSON ( ПереносСтрокJSON . Авто , Символы . Таб ) ; Запись . ОткрытьФайл ( "F:\test.json" , , , ПараметрыЗаписиJSON ) ;

ПрочитатьJSON

Для чтения JSON файла используется программный объект ЧтениеJSON и метод ПрочитатьJSON:

1. Создается программный объект ЧтениеJSON
2. Методом ОткрытьФайл выполняется открытие файла с JSON
3. Методом глобального контекста ПрочитатьJSON выполняется десериализация JSON
4. Объект ЧтениеJSON закрывается методом Закрыть

Десериализация из JSON в типы 1С выполняется по следующим правилам:

Тип JSON	Тип 1С
Число	Число
Строка	Строка
true	Истина
false	Ложь
null	Неопределено
JSON-объект	Структура или соответствие
JSON-массив	Массив

В результате в переменной Данные будет структура со следующим содержимым:

Чтение JSON в соответствие

Сейчас все JSON-объекты были прочитаны в структуру. Даже те, которые изначально были сериализованы из соответствия. Однако, в отличии от структуры, в ключах JSON-объектов могут быть пробелы или другие символы, которые нельзя использовать в ключах структуры. Например, если бы соответствие было записано так:

Чтобы прочитать такой JSON нужно в метод ПрочитатьJSON передать вторым параметром Истина. Тогда чтение всех JSON-объектов будет выполнено в соответствие:

В результате в переменной Данные будет соответствие со следующим содержимым:

Сериализация даты в JSON

Формат даты

При сериализации в JSON дата записывается как строка. При чтении тоже будет прочитана как строка, что не совсем удобно. Чтобы свойство с датой было прочитано как дата нужно в методе ПрочитатьJSON третьим параметром указать список имен свойств, которые должны быть прочитаны как дата. А четвертым параметром указать формат даты, в котором дата была записана в JSON. По умолчанию платформа 1С пишет дату в JSON в формате ISO.

//через запятую нужно перечислить список имен свойств, которые будут прочитаны как дата Данные = ПрочитатьJSON ( ЧтениеJSON , , ИменаСвойствСДатой , ФорматДатыJSON . ISO ) ;

В результате свойство Дата будет прочитано как дата:

Платформа 1С может записывать дату в JSON в трех форматах:

Формат ISO используется по умолчанию. Для записи в формате JavaScript или Microsoft нужно явно указать это. При этом форматы JavaScript и Microsoft могут быть записаны только в варианте даты UTC (универсальная дата).

Например, запись в формате JavaScript:

ПараметрыЗаписиJSON = Новый ПараметрыЗаписиJSON ( ПереносСтрокJSON . Авто , Символы . Таб ) ; Запись . ОткрытьФайл ( "F:\test.json" , , , ПараметрыЗаписиJSON ) ; Данные . Вставить ( "СвойствоСДатой" , Дата ( 2021 , 6 , 3 , 15 , 0 , 0 ) ) ; //в настройках нужно указать формат даты и вариант записи даты НастройкиСериализацииJSON = Новый НастройкиСериализацииJSON ; НастройкиСериализацииJSON . ФорматСериализацииДаты = ФорматДатыJSON . JavaScript ; НастройкиСериализацииJSON . ВариантЗаписиДаты = ВариантЗаписиДатыJSON . УниверсальнаяДата ; ЗаписатьJSON ( Запись , Данные , НастройкиСериализацииJSON ) ;

При чтении также нужно указать формат JavaScript:

//через запятую нужно перечислить список имен свойств, которые будут прочитаны как дата Данные = ПрочитатьJSON ( ЧтениеJSON , , ИменаСвойствСДатой , ФорматДатыJSON . JavaScript ) ;

Для записи в формате Microsoft нужно указать ФорматСериализацииДаты = Microsoft:

НастройкиСериализацииJSON . ФорматСериализацииДаты = ФорматДатыJSON . Microsoft ;

И то же самое при чтении JSON:

Данные = ПрочитатьJSON ( ЧтениеJSON , , ИменаСвойствСДатой , ФорматДатыJSON . Microsoft ) ;

Для формата ISO дату можно записать в трех вариантах:

• Локальная дата (без часового пояса)
• Локальная дата со смещением (относительно UTC)
• UTC (универсальная дата)

НастройкиСериализацииJSON = Новый НастройкиСериализацииJSON ; НастройкиСериализацииJSON . ФорматСериализацииДаты = ФорматДатыJSON . ISO ; НастройкиСериализацииJSON . ВариантЗаписиДаты = ВариантЗаписиДатыJSON . ЛокальнаяДата ;

Локальная дата со смещением:

НастройкиСериализацииJSON = Новый НастройкиСериализацииJSON ; НастройкиСериализацииJSON . ФорматСериализацииДаты = ФорматДатыJSON . ISO ; НастройкиСериализацииJSON . ВариантЗаписиДаты = ВариантЗаписиДатыJSON . ЛокальнаяДатаСоСмещением ; НастройкиСериализацииJSON = Новый НастройкиСериализацииJSON ; НастройкиСериализацииJSON . ФорматСериализацииДаты = ФорматДатыJSON . ISO ; НастройкиСериализацииJSON . ВариантЗаписиДаты = ВариантЗаписиДатыJSON . УниверсальнаяДата ;

ПрочитатьДатуJSON

Другой способ чтения даты из JSON это использование метода ПрочитатьДатуJSON. Сначала читаем JSON методом ПрочитатьJSON, а свойства с типом дата дополнительно читаем методом ПрочитатьДатуJSON. Первым параметром передается строковое представление даты, вторым формат даты. Результатом выполнения функции будет значение с типом дата:

Дата = ПрочитатьДатуJSON ( Формат ( Данные . СвойствоСДатой , "ЧГ=0" ) , ФорматДатыJSON . ISO ) ;

Функции преобразования и восстановления

Функция преобразования

Для возможности выгрузки данных прикладных типов 1С можно использовать функцию преобразования. Данная функция указывается в методе ЗаписатьJSON четвертым параметром. Она должна быть экспортной. Пятым параметром указывается где находится данная функция (если в этом же модуле, то нужно указать ЭтотОбъект). Шестым параметром можно указать произвольные дополнительные данные, которые будут переданы в функцию преобразования. Данная функция будет вызвана для тех типов, которые по умолчанию не сериализуются в JSON. Функция вызывается для всех свойств, включая вложенные свойства, а также для элементов массива.

Например, выгрузим контрагента, у которого в реквизите ДатаРегистрации содержится дата, в реквизите ОсновнойДоговор ссылка на справочник Договоры, а в табличной части список контактных лиц. Причем одно контактное лицо указано строкой, а второе ссылкой на справочник Контактные лица:

Конструктор запроса 1С - это один из инструментов разработки, который позволяет:

1. составить текст запроса на языке запросов исключительно визуальными средствами;
2. отредактировать текст имеющегося запроса.

Программный код обычный конструктор не создает.

Конструктор запроса с обработкой результата - это один из инструментов разработки, который позволяет:

1. сформировать текст нового запроса;
2. сформировать программный код, содержащий создание объекта встроенного языка "Запрос", текста запроса, получение и обработку результата выполнения запроса (фрагмент программного кода, который исполняет запрос и выводит его результаты в табличный документ или диаграмму - отсюда );
3. отредактировать текст имеющегося запроса.

Конструктор запросов может использоваться:

• разработчиком - в конфигураторе (необходимо знание языка запросов);
• пользователем - в режиме 1С:Предприятие (как обработка "Консоль запросов").

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

Вызов конструктора текста запроса 1С:

1. контекстным меню (правой кнопкой мыши) в нужном месте программного кода;
2. с помощью команды "Конструктор запроса. " меню "Текст".

Результатом работы конструктора будет являться синтаксически правильный текст запроса.

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

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

Текст запроса может содержать описание предопределенных данных конфигурации:

1. значения системных перечислений (из определенного перечня);
2. предопределенных данных (справочники, перечисления, планы видов характеристик, планов счетов, планов видов расчета);
3. пустые ссылки;
4. значения точек маршрута бизнес процессов.

Вкладки конструктора запроса 1С

На этой вкладке указывается источник данных и поля, которые необходимо выводить в отчет (по сути описываются конструкции ВЫБРАТЬ … ИЗ).

В качестве источников данных могут служить:

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

В контекстном меню виртуальных таблиц можно задать параметры этих таблиц.

На закладке "Таблицы и поля" конструктора запросов задают:

1. источники данных запросов, в качестве которых могут выступать реальные и виртуальные таблицы;
2. набор полей из таблиц - источников данных запроса;
3. поля в виде произвольного выражения.

Закладка "Связи" становится доступна сразу после добавления двух таблиц.

На закладке "Связи" конструктора запросов можно определить соединение таблиц-источников данных и связи между ними.

Язык запросов предоставляет широкие возможности по построчному соединению нескольких таблиц.

Соединение таблиц может быть:

• безусловным ;
• условным (или по ключу ), то есть по заданному условию связи:
  1. полным - все записи обеих таблиц; для тех, которым не нашлось соответствия, запрос возвращает NULL;
  2. левым/правым - все записи из соответственно левой/правой таблицы (из противоположной только те, которым есть соответствие), для не найденных запрос возвращает NULL. Примечание : консоль запросов всегда преобразует правое соединение в левое, меняя таблицы местами (в случае, если запрос написать вручную, и потом открыть конструктором);
  3. внутренним - только совпадающие записи обеих таблиц.

В случае безусловного соединения, в конструкторе запросов достаточно определить выбираемые таблицы, не указывая, по каким полям они будут связаны (то есть не заполняя закладку Связи).

На практике чаще встречаются задачи соединения по определенному полю двух таблиц.

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

Флажок "Все", устанавливаемый у таблицы, выбранной на закладке "Связи" конструктора запросов означает что в результат запроса надо включить все записи этой таблицы.

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

На данной вкладке система позволяет группировать и суммировать нужные поля результата таблицы. Описывается использование конструкций СГРУППИРОВАТЬ ПО, СУММА, МИНИМУМ, СРЕДНЕЕ, МАКСИМУМ, КОЛИЧЕСТВО, КОЛИЧЕСТВО РАЗЛИЧНЫХ.

При описании группировки в тексте запроса все поля должны делиться:

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

Вложенные таблицы не попадают ни в группируемые, ни в агрегируемые поля.

Количество записей в результате запроса можно узнать с помощью агрегатной функции КОЛИЧЕСТВО(*).

Отвечает за все условия, накладываемые на получаемые данные, т.е. за всё, что идёт в тексте запроса после конструкции ГДЕ.

Вкладка "Дополнительно" включает важные параметры.

Группировка "Выборка записей":

• Первые — параметр, возвращающий в запрос только N записей (оператор ПЕРВЫЕ ); позволяет вывести в отчет первые N записей, которые будут отобраны с учетом правил упорядочивания, настроенных в конструкторе запросов;
• Без повторяющихся — обеспечивает уникальность полученных записей (оператор РАЗЛИЧНЫЕ) и позволяет исключить из результирующей таблицы запроса одинаковые строки (данная операция распространяется только на детальные записи );
• Разрешенные — позволяет выбирать только те записи, которые позволяет выбрать система с учетом настройки RLS (конструкция РАЗРЕШЕННЫЕ).

Группировка "Тип запроса":

• определяет тип запроса:
  1. Выборка данных;
  2. Создание временной таблицы;
  3. Уничтожение временной таблицы.

Флаг "Блокировать получаемые данные для последующего изменения":

1. позволяет включить возможность установки блокировки данных, которая обеспечивает сохранность данных от момента их чтения до изменения (актуально только для "Автоматического режима блокировок", конструкция ДЛЯ ИЗМЕНЕНИЯ); позволяет заблокировать данные указанных таблиц-источников на чтение (в рамках транзакции).
2. в режиме автоматических транзакционных блокировок) происходят блокировки:
   • в варианте файл-сервер - на уровне таблиц базы данных;
   • в варианте клиент-сервер - на уровне записей таблиц базы данных.
3. Если список "Таблицы для изменения" - пуст, то будут блокироваться данные всех таблиц, задействованных в запросе, иначе - только таблиц, указанных в списке.

Конструктор запросов 1с позволяет создавать объединения запросов. При их помощи можно последовательно выводить в результат данные, полученные из нескольких запросов, не используя при этом связи. Единственной условие для объединения — одинаковый набор полей в каждом отдельном запросе.

На этой закладке устанавливается возможность объединения разных таблиц и псевдонимы (конструкция КАК).

В левой части указываются таблицы, если установить флаги напротив таблицы, будут использоваться конструкции ОБЪЕДИНИТЬ, иначе — ОБЪЕДИНИТЬ ВСЕ (отличия двух способов тут ).

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

Особенности использования закладки "Объединения/Псевдонимы" конструктора запросов:

1. На закладке "Объединения/Псевдонимы" конструктора запросов можно:
   • Задать список запросов (в результирующую выборку попадут записи всех указанных запросов).
   • Задать имена полей результирующей таблицы.
2. При создании запросов, участвующих в объединении , с помощью конструктора запросов, он сам добавит в каждый запрос необходимое количество недостающих полей со значением NULL. Настроить соответствие добавленных конструктором полей и полей результата запроса можно на закладке "Объединения/Псевдонимы".
3. Настройки, сделанные в разделе "Объединения/Псевдонимы" конструктора запросов, отразятся на информации, отображаемой в других разделах конструктора, следующим образом:
   • Если заданы псевдонимы полей результирующей таблицы, то новые названия появляются на закладке "Порядок" в списке полей.
   • При объединении запросов на ряде закладок (в том числе "Таблицы и поля") появляется возможность переключения между объединяемыми запросами.
4. При объединении двух запросов на закладке "Объединения/Псевдонимы" конструктора запросов условие связи между запросами задать нельзя: в случае объединения связь всегда безусловна.

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

1. на закладке "Порядок";
2. на закладке "Объединения/Псевдонимы".

Таблица, полученная в результате запроса, может быть отсортирована по алфавиту по нужному полю:

1. по полю, присутствующему в запросе;
2. по любому полю таблицы-источника (кроме случаев объединенных запросов).

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

Указывается порядок сортировки значений (УПОРЯДОЧИТЬ ПО) — по убыванию (УБЫВ) или возрастанию (ВОЗР).

Флаг "Автоупорядочивание" (в запросе — АВТОУПОРЯДОЧИВАНИЕ):

• если установлен, то система будет сортировать данные (по умолчанию система 1С 8.3 выводит данные в «хаотичном» порядке).

Если на закладке "Порядок" конструктора запросов не заданы настройки, то установка флага "Автозаполнение" обусловит следующее:

1. записи в результирующей таблице запроса будут упорядочены по полям сортировки по умолчанию для таблиц-источников данных;
2. если заданы настройки на станицах "Группировка" или "Итоги", то порядок записей в результирующей таблице запроса будет определяться этими настройками.

В случае установки флага "Автоупорядочивание" на закладке "Порядок" конструктора запросов записи в результирующей таблице запроса (если эта таблица уже упорядочена по полю, хранящему ссылку на иерархический справочник) будут упорядочены по значению основного представления для этого поля. Т.е. если справочник отсортирован по ссылке (= наименованию), но основное его представление - код, то после включения автоупорядочивания сортировка изменится на сортировку по коду.

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

В ней указывается:

1. Поле, по которому группируем, и тип его итогов:
   • Элементы - итоги только по конечным элементам;
   • Элементы и иерархия - итоги по папкам и по конечным элементам;
   • Только иерахия - итоги только по папкам.
2. Флаг "Общие итоги" - суммирование всех полученных запросом строк;
3. Итоговое поле - по которому собственно и считаем итоги.

Таким образом, при использовании секции "ИТОГИ . ПО" количество записей в результате запроса увеличится (по сравнению с их количеством без секции "ИТОГИ . ПО").

Результатом запроса с итогами будет дерево значений:

На этой вкладке можно создавать новые пакеты запросов, а также использовать её для навигации.

В тексте запроса пакеты разделяются символом «;» (точка с запятой).

Особенности использования конструктора запросов 1С

1. При сохранении текста запроса, открытого повторно с помощью конструктора запроса, без внесения в этот текст изменений, из первоначального текста будут удалены только комментарии.
2. Для создания в конструкторе запросов вложенного запроса необходимо:
   1. открыть закладку "Таблицы и поля";
   2. в командной панели над деревом "Таблицы" нажать кнопку "Добавить" или выбрать одноименный пункт контекстного меню.
   Рисунок "Создание в конструкторе запросов вложенного запроса"

   
   

   1. открыть закладку "Таблицы и поля";
   2. в командной панели над деревом " Поля " нажать кнопку "Добавить" или выбрать одноименный пункт контекстного меню.

   Укажем в конструкторе одно суммируемое поле:По остальным полям будет произведена группировка в тексте запроса:

   3 Значения каких реальных полей таблицы документа определяют его хронологическую позицию среди других документов?
   5.1 Значения свойств "Дата" и "Ссылка"
   5.2 Достаточно значения свойства "Дата"
   5.3 Значения свойств "Дата" и "Время"
   5.4 Достаточно значения свойства "Номер"
   5.5 Достаточно значения свойства "Ссылка"
   5.6 Значения свойств "Дата" и "Номер"

   4 Какой метод документа обеспечивает вызов события проведения документа?
   6.1 Записать(РежимЗаписиДокумента.Проведение), где Записать - метод объекта документа
   6.2 Провести(), где Провести - метод объекта документа
   6.3 Записать(РежимЗаписиДокумента.Проведение), где Записать - метод формы доку-мента
   6.4 Провести(), где Провести - метод формы документа

   5 Использование конструктора запросов позволяет:
   2.1 Сформировать текст нового запроса
   2.2 Сформировать программный код, содержащий создание объекта встроенного языка Запрос, текста запроса и получение результата выполнения запроса
   2.3 Отредактировать текст имеющегося запроса
   2.4 Верны ответы 1 и 3
   2.5 Все вышеперечисленное

   6 На закладке "Таблицы и поля" конструктора запросов задают:
   10.1 Источники данных запросов, в качестве которых могут выступать реальные и виртуальные таблицы
   10.2 Набор полей из таблиц - источников данных запроса.
   10.3 Поля в виде произвольного выражения
   10.4 Верны ответы 1 и 2
   10.5 Верно все вышеперечисленное

   7 Вложенный запрос может использоваться:
   18.1 В качестве таблицы-источника данных
   18.2 В качестве операнда операций сравнения "В" или "НЕ В" при задании параметров виртуальной таблицы
   18.3 В качестве операнда операций сравнения "В" или "НЕ В" при задании конструкции языка запросов "ГДЕ"
   18.4 Верны ответы 1, 2 и 3

   9 В процедуре, которая будет вызываться при подключении к базе данных через СОМ, нельзя использовать:
   10.1 ДокОбъект=Док.СоздатьДокумент()
   10.2 Форма.Открыть();
   10.3 Запрос=Новый Запрос;
   10.4 Нет правильного ответа

   10 Основным назначением регистров накопления является:
   2.1 Накопление в разрезе измерений произвольной информации
   2.2 Накопление числовой информации в разрезе измерений с последующей возможностью получения остатка на определенный момент времени.
   2.3 Накопление числовой информации в разрезе измерений с последующей возможностью получения оборотов за определенный период.
   2.4 Верны ответы 1, 2 и 3
   2.5 Верны ответы 2 и 3

   11 Для получения информации об остатках накопленных средств в конфигурации можно использовать:
   6.1 Регистры накопления с видом «Остатки»
   6.2 Регистры накопления с видом «Обороты»
   6.3 Верны ответы 1 и 2

   12 Новые виды характеристик можно вводить:
   8.1 Только в режиме конфигуратора
   8.2 Только в режиме 1С:Предприятие
   8.3 В режиме конфигуратора или в режиме "1С:Предприятие

   13 Информация, хранящаяся в регистре накопления:
   17.1 Всегда привязана к оси времени
   17.2 Не привязана к оси времени
   17.3 Привязана к оси времени если установлен режим записи - "Подчинение регистратору"
   17.4 Привязка регистра накопления к оси времени определяется пользователем в режиме 1С:Предприятие

   14 Уникальность записей в таблице движений регистра накопления определяется:
   24.1 Полем "Ссылка"
   24.2 Комбинацией значений измерений регистра
   24.3 Полем "Период" и комбинацией значений измерений регистра
   24.4 Полями "Регистратор" и "Номер строки"
   24.5 Полями "Период", "Регистратор" и "Номер строки"

   15 Предопределённый элемент справочника.
   29.1 не удаляется в режиме 1С:Предприятия, расширяет возможности программного оперирования со справочником.
   29.2 содержит предопределённые свойства, изменить которые может только администратор.
   29.3 пользователь может создать в режиме 1С:Предприятие, но корректировать не сможет.

   16 Объект конфигурации Перечисление…
   46.1 прикладной объект, значения которого задаются в Конфигураторе.
   46.2 может хранить различные типы значений.
   46.3 для него может быть заданы форма списка и выбора.
   46.4 верны все указанные ответы.
   46.5 верны ответы 1 и 3

   17 Для каких объектов конфигурации возможен ввод предопределенных значений?
   49.1 Справочники.
   49.2 Документы.
   49.3 Планы видов характеристик, планы счетов, планы видов расчета.
   49.4 Все вышеперечисленные.
   49.5 Справочники, планы видов характеристик, планы счетов, планы видов расчета.

   18 Каким может быть тип данных ресурса у регистра сведений?
   56.1 Один из примитивных типов данных
   56.2 Только ссылочные типы
   56.3 Хранилище значений
   56.4 Составной тип данных
   56.5 Верны все перечисленные ответы
   56.6 Верны ответы 1 и 2

   19 В системе компоновки данных можно использовать следующие наборы данных:
   60.1 набор данных - запрос
   60.2 набор данных - объект
   60.3 набор данных - объединение
   60.4 верны ответы 1,2
   60.5 верны ответы 1,3
   60.6 верны ответы 1,2,3

   20 Как могут быть связаны между собой регламентные и фоновые задания?
   68.1 Регламентное задание может породить фоновое задание.
   68.2 Регламентное задание в обязательном порядке порождает фоновое задание.
   68.4 Фоновое задание в обязательном порядке порождает регламентное задание.
   68.5 Нет никакой взаимосвязи.

   21 Основной реквизит формы.
   4.1 не может присутствовать у общих форм
   4.2 обязательно присутствует у всех форм, входящих в список "Формы" объекта
   4.3 может присутствовать или отсутствовать у любых форм
   4.4 присутствует только у основных форм

   22 Чтобы создать двухпозиционный переключатель необходимо:
   27.1 Создать в форме элемент управления "Переключатель". В окне свойств задать свойство "Количество позиций" равным "2".
   27.2 Создать в форме два элемента управления "Переключатель". Для одного из них в окне свойств установить флаг "Первый в группе". Для каждого из переключателей задать выбираемое значение
   27.3 Создать в форме два элемента управления "Переключатель". Для одного из них в окне свойств установить флаг "Первый в группе". Для каждого из переключателей задать выбираемое значение. Проверить, чтобы для остальных переключателей порядок обхода был непрерывным вслед за первым в группе
   27.4 Верны ответы 1 и 3

   23 Какой вид может иметь иерархия справочника?
   4.1 Иерархия групп
   4.2 Иерархия элементов
   4.3 Иерархия групп и элементов
   4.4 Верны ответы 1 и 3
   4.5 Верны ответы 2 и 3
   4.6 Верны все указанные ответы

   24 Можно ли в один элемент управления "Поле ввода" вводить значения разных типов?
   72.1 Нельзя
   72.2 Можно, если для него задан составной тип значения
   72.3 Можно, если для него задан составной тип значения, а также свойство "Выбирать тип"

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

   Ситуация изменилась в релизе 8.3.14, где платформа стала поддерживать разные варианты ключей при работе с ДС, в т.ч. для произвольных запросов без основной таблицы. Это хорошо описано в Зазеркалье и на других ресурсах. Мы получили удобный инструмент решения коллизий дублирования ключевых полей, оптимизацию, прозрачность и управляемость (хотя бы фактом кэширования). Поведение системы в целом осталось тем же - контроль реальной уникальности ключа, каким бы он ни был, поддержка возможностей ДС, клиент-серверное взаимодействие и т.д., и при этом интерактивное добавление, удаление, открытие; т.е. то, что раньше было возможно лишь при наличии основной таблицы.

   Тем не менее, есть нюансы поведения ДС при отсутствии основной таблицы и, тем более, с разными видами ключей.

   Не весь функционал ДС с основной таблицей унаследован для ДС с произвольными запросами, даже для случаев, когда, казалось бы, построение ключа и поведение системы ровно то же. Так, "Уведомление не влияет на динамические списки, у которых не задана основная таблица" (с) СП, т.е. мы не можем рассчитывать на обновление ДС и очистку кэша форм выбора при вызове "ОповеститьОбИзменении" и при работе аналогичных стандартных команд. Приходится делать вручную, как и ранее.

   Аналогично, "ОповеститьОбАктивизации", даже будучи вызван с корректным аргументом, эффекта не возымеет, поэтому для синхронизации ДС на произвольных запросах, даже с видом ключа "Авто", тоже всё вручную. Ряд релизов при связке справочников по владельцу средствами ДС без основной таблицы вообще аварийно завершался при чтении первой же порции данных.

   Также, неработоспособен параметр формы "ТекущаяСтрока". Он автодобавляется при указании ДС, с любым видом ключа, как основного реквизита формы (что видно в подсказке при наборе кода), и поддерживает все возможные содержания при видах ключей, и передаётся, и читается программно, но свою основную задачу - позиционирование, особенно при открытии - не выполняет, игнорируется.

   Есть особенности в поведении произвольных запросов с разными ключами, рассмотрим их на примере общеизвестных функций получения СКД и настроек ДС (например,

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

   Если указана основная таблица, то вид ключа "Авто", а поля ключа - пустой фиксированный массив. Вроде бы всё по умолчанию. Но при этом возможна ситуация, когда поле "Ссылка" есть в Наборе, в доступных к выбору и выбранных полях настройки СКД по умолчанию, и в Выбор текущей настройки СКД, но даже при плоской детализации структуры (взятой по умолчанию) его нет в результатной выборке-таблице. Во всех прочих вариантах ключей эффект не наблюдается, поле есть. От флага "ИспользоватьВсегда" этот эффект не зависит.

   Если для произвольного запроса указана основная таблица, ПоляКлюча не то что бы недоступны, а именно "не используются" (с) СП. Замечено, что поведение при обращении к полям ключа может разниться для толстого и тонкого клиентов.

   Вообще, "ПоляКлюча" согласно СП это "СписокПолей" (для ВводПоСтроке и ПоляКлюча внешних источников), но, в отличие от указанного в СП, т.е., цитирую, "В качестве полей ввода по строке могут выступать такие предопределенные реквизиты, как "Код", "Наименование", "Дата", "Номер" и реквизиты объектов, имеющие примитивный тип данных, для которых свойство объекта метаданных "Индексировать" принимает значение "Индексирование" или "Индексировать с доп. упорядочиванием"." - тут выбор доступных к указанию как поля ввода явно больше - и не только примитивные типы и предопределённые значения. Программно это подтверждается, поэтому и внимания к типизации полей СКД надо больше. Особенно, как всегда, аккуратнее с определяемыми типами, характеристиками, хранилищами, неогр.строками итд.

   Даёт на выбор в значениях ключа всё, все поля выборки запроса, кроме "ВерсияДанных".
   ПоляКлюча - фиксированный массив строк (всегда строго один элемент), где строки это имена полей (опять же, не следует применять разыменования от полей выборки "первого уровня", даже если конструктор ДС это скушал)
   ТекущаяСтрока - текущее значение поля нужного типа.

   Даёт на выбор вообще всё, любые поля. Явных ограничений ни по типам, ни по составу, ни по разыменованию нет. Но, полагаю, с разыменованиями тоже не следует связываться - опять же, любое поле "через точку" как неявное соединение с другими таблицами негативно скажется на производительности.
   ПоляКлюча - фиксированный массив (возможны N элементов), каждый из элементов это строка с именем поля ключа.
   ТекущаяСтрока - КлючСтрокиДинамическогоСписка - коллекция из "КлючИЗначение", причём значения - нужных типов и, если был многотипный, значение уже строго одного типа, типа реального наполнения.

   Выбор настройки ПолеКлюча недоступен, в т.ч. программно; платформа нумерует строки выборки сама. Причём, как показали замеры, это делается на клиенте.
   ПоляКлюча - пустой фикированный массив.
   ТекущаяСтрока - число (нумерация с 1), причём это не свойство строки как объекта данных, это свойство текущей позиции исключительно при текущем сеансе показе (вывода порции данных на экран), т.е. сортировка по колонке и прочие манипуляции на идентификации не сказываются - всегда идёт по натуральному ряду, и под неким номером каждый раз могут оказываться разные строки выборки.

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

   Если ДС сгруппирован, т.е. Группировки применены, то "ТекущаяСтрока" возвращает значение типа "СтрокаГруппировкиДинамическогоСписка", и её Ключ - значение ТекущиеДанные[ТекущаяКолонока] того поля группировки, где стоит активный курсор.

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

   Во всех режимах одинаково полные возможности Отбора, Порядка, Условного оформления. В режиме "НомерСтроки" отсутствует возможность Группировок; при этом возвращаемый ПолучитьОграниченияИспользованияВГруппировке() массив пуст.

   Поведение самой СКД также имеет особенности. Для набора (типа "Набор запроса") стоит автозаполнение, но его Поля пусты, и поля Выбор и ДоступныеДляВыбора пусты; пусто и в СКД.НастройкиПоУмолчанию, и в основном варианте настройки. Актуальны и приоритетны именно исполняемые настройки: в Выборе пусто, а в Доступных для выбора - все нужные поля есть и корректно объявлены. Даже для вида ключа "Номер строки" в "ДоступныеПоляГруппировок" есть все поля выборки; в структуре запись детальной группировки (без групп.полей), в её выбранных - все поля выборки.

   Если у ДС указаны в конфигураторе настройки, все они ровно так и отображается (отбор, порядок, группировка как структура), но искать их следует именно в исполняемых настройках, а не в НастройкиПоУмолчанию.

   Получение ограничений использования (в отборе, в сортировке, в группировках) совершенно ничем не отличается от "Авто" и интереса не представляет.

   Механизм автозаполнения доступных полей, механизм свойства "ПолучениеПредставленийДляНевидимыхПолей" (и соответственно кэш представлений ссылок формы) работают для всех случаев строго так же, как для обычных с основной таблицей.

   И собственно функция, реализующая демонстрационную задачу

   Получение текущих данных на сервере для разных видов ключей

   Важно: при программной работе со свойствами ДС интерпретатор платформы не проверяет правильность и взаимную связность настроек (это делает только интерфейс настройки ДС), т.е. например "ВидКлюча" не "Авто", и принудительно указывается свойство "ОсновнаяТаблица"; конфликт может вылезти только при исполнении - при первом обращении ДС к данным БД. В лучшем случае это будет ругательный MsgBox, в худшем - захват всей таблицы, которая основная, и повисание сеанса. Следует быть внимательным, а на релизах ниже 8.3.15 вообще лучше не трогать в коде эти свойства.

   Открытым остаётся вопрос о порции считывания. При установленном флаге "Динамическое считывание данных" (доступном только при указанной основной таблице произвольного запроса, т.е. только в режиме "Авто") платформа читает от 45 до 70 записей таблицы (насколько я понял, в зависимости от постраничной разбивки читаемых таблиц СУБД). А вот различается ли размер порции при других видах ключей и кэшируются ли они промежуточно по внутренним ID либо перестраиваются и перечитываются каждый раз - тема отдельного исследования. Заявленный размер порции в 1000 записей на практике соблюдается не всегда, поэтому, по-хорошему, изучить бы надо и степень горячести запроса/прогретости кэша, и способ (курсор или через темпы), и тот же пейджинг, и всё это в связке с принципом построения итогового внутреннего хеш-ключа. Словом, простор для исследований.
   

   Читайте также:

     
   • Как сделать эффект пудры в фотошопе
     
   • Как обрабатывать фуд фото в фотошопе
     
   • Расчет зарплаты в эксель фиксированная плюс разный процент в зависимости от
     
   • 1с закрепить окно программно
     
   • Visual studio чем заменить