Характеристики в отчете 1с
Добрый день. Прошу подсказать самый правильный и самый быстрый варианты (возможно это рне одно и то же) получения списка характеристик с всеми свойствами из регистра Значение свойств объектов. Что бы на выходе был следующий результат -
Характеристика1 | СвойствоА
Характеристика1 | СвойствоБ
Характеристика1 | СвойствоВ
Характеристика1 | СвойствоА | СвойствоБ | СвойствоВ
На данный момент я решаю это соединением по каждому свойству. 5 свойств - 5 соединений. Не уверен что это правильно - слишком медленно все работает.
(1) Это и есть максимально удобное соединение? А если например список свойств меняется? Сразу соединять все возможные свойства? У нас их в характеристике штук 15.
(6) СКД работает в памяти сервера,и не всегда быстрее, но удобнее.
И можно сделать на каждое свойство отдельную таблицу,а уже ее проиндексированную по характеристике соединять в итоговую,по идее,будет быстрее.
(9) Много задач где мне очень полезно бы иметь все свойства одной строкой. Например поиск характеристики по свойствам. Конкретно сейчас мне нужно найти характеристику, которая ПОЧТИ по всем свойствам должна совпадать с другой изначально заданной характеристикой.
ВТ_Данные подразумевается, что содержит три колонки: Характеристика = поле к чему относятся свойства; НПП = номер свойства для Св_А это 1, для Св_Б = 2 и т.д.; Поле Св = значению свойства.
Предварительно из (0) НПП необходимо создать и заполнить.
А запросе не на 1С это выглядел бы с использованием PIVOT или UNPIVOT, в зависимости в какую сторону разворачивается таблица.
По поводу НПП. Оно не нужно если известно, что СвойствоА это именно СвойствоА, а не СвойствоБ или СвойствоХ.
Т.е. на входе не две колонки, а три:
Характеристика1 | СвойствоА | ЗначениеСвойстваА
Характеристика1 | СвойствоБ | ЗначениеСвойстваБ
Характеристика1 | СвойствоВ | ЗначениеСвойстваВ
Тогда вместо НПП сразу использовать вторую колонку.
(15) На индексацию тоже тратится время и ресурсы. Зависит, что вы и как индексируете. Может у вас индексируемое поле - это страшно составной тип или тип все ссылки.
(18) Так я писал выше. Стоит задача. Найти аналог по характеристике, который содержит почти тот же набор свойств. Если бы я смог представить регистр свойств объектов в нужном мне виде, то мог бы взять необходимые свойства из первой характеристики и циклом прописать в условия. Найти характеристику где св1 = св1, св2 = св2 и т д
(16) Я не понял примера, если честно. Пока как тут советовали делаю через соединение (как вы тут код скрываете под спойлер?)
(20) Ну, примерно как-то так.
Писал на коленке, поэтому мог что-то упустить в синтаксисе, но тут главное суть.
Соединений нет, но есть объединение, что бы даже если нет ни одного свойства у номенклатуры, то в результат запроса всё равно попадал результат. И нет приведения NULL к типу значения, так как я их не знаю. Но это нужно добавить "ЕстьNULL(МАКСИМУМ(т.Марка), )".
(20) "ЛЕВОЕ СОЕДИНЕНИЕ", "ПРАВОЕ СОЕДИНЕНИЕ", и т.д. в общем случае соединение - это "УБИЙЦА" производительности запроса. Если можно обойтись без соединения, то НУЖНО обходиться без него.
Бывает такое, что соединение почти не влияет на производительность - бывает, но это когда при использовании соединения правильно используются индексы, условия соединения не сложные и т.д.
(25) А чего там полезного можно найти? То как ранее писать код при 8.0 и 8.1 считалось плохим тоном.
Сплошные Запрос.Выполнить.Выгрузить(), а далее как в 7.7 работа с ТЗ. В цикле по ТЗ_1 поиски по другой ТЗ_2? Где например, собственно ТЗ_1 свойства, а ТЗ_2 доп реквизиты (НаборыДополнительныхРеквизитовИСведений).
(30) Прошу прощения, а что плохого в " Запрос.Выполнить.Выгрузить(), а далее как в 7.7 работа с ТЗ"? Спрашиваю, так как иногда использую эти методы.
(31) Сейчас буду разбирать ваш пример. Спасибо большое за запрос
(31) Вы сначала получаете несколько строк с одной характеристикой, но заполненными свойствами. Далее вы их объединяете с справочником ХарактеристикиНоменклатуры, но в полях ставите нуллы для соответствия количества колонок. А вот последний шаг не очень понятен. Каким образом вы из 5 строк с нулами и свойствами делаете одну строку. Где происходит группировка?
(36) Спасибо за разъяснение. Еще один вопрос есть. Объект в регистре это и есть по факту характеристика. Значит объединение с справочником ХарактеристикиНоменклатуры можно в принципе выкинуть? Цель (Характеристику) я получу из объекта.
Т.е. если даже по номенклатуре не введена ни одно интересующее вас свойство в результат запроса данные по этой номенклатуре попадали.
(39) Не за что.
(33) С использованием PIVOT и UNPIVOT работает ещё в несколько раз быстрее. И текст запроса получается короче в разы. Но язык SQL внутри 1С данные конструкции не поддерживает.
(32) "Прошу прощения, а что плохого в " Запрос.Выполнить.Выгрузить(), а далее как в 7.7 работа с ТЗ" - об этом много и подробно написано в статьях на дисках ИТС самой фирмой 1С.
При сдаче на специалист по платформе - выгрузка в ТЗ и дальнейшая обработка результата является ошибкой, которая серьёзно снижает баллы на экзамене. Это указано в требованиях к экзамену на специалиста по платформе 1С.
(42) В (33) уже написали, что такой запрос с LEFT JOIN в три раза медленнее чем пример в (28) на данных, которые у автора темы.
(43) да быть не может!
если я верно понял структуру его БД
(28) типа создаются два массива
так а где ж его скорость то?
если в хараткреистиках то мы заюзали отбор а для свойств как я понимаю выливаются все (а их больше чем характеристик)
а затем объединяются и не нужные отсекаются?
или я не верно понял?
(46) Автор подтвердил в (39), что всё понял. Значит информации в ветке уже достаточно.
Удачного дня :-)
(43) Я перепутал не в три раза а больше. Конкретные цифры на тестовом примере 4.5-5 сек мой вариант с соединением и 0.3-0.4 сек вариант в объединением.
(48) В 10 раз примерно быстрее на 5-ти свойствах.
А если свойств необходимо будет не 5, а 15, то разница будет только расти, так как запрос в (28) будет в этом случае примерно тот же результат давать, что и при 5-ти свойствах, а запрос с левым соединением будет увеличивать время выполнения.
(49) Решил попробовать улучшить обработку по подбору характеристик, которую нам делал сторонний программист. Он тоже использует соединение, но оно почему-то работает очень быстро. Почему так может быть?
Запрос Объединение:
выбрать РАЗРЕШЕННЫЕ
Запрос Соединение:
(51) Потому что соединение "Внутреннее".
Если у номенклатуры не будет одного из свойств, то в результат запроса информация по данной номенклатуре не попадет.
+ Есть дополнительное условие на значение "&Значение1, &Значение2 . " - оно серьезно сужает выборку.
Другими словами эти два запроса не эквивалентны друг другу и будут в общем случае давать разный результат.
Механизм описания характеристик — это один из прикладных механизмов платформы. Он позволяет организовать хранение свойств объектов (справочников, документов и т. д.), которые еще не известны на момент разработки прикладного решения. Таким образом, например, для номенклатуры пользователь сможет самостоятельно вводить новые свойства: цвет, размер, габариты, мощность и т. д. Для каждой группы номенклатуры может быть создан свой набор свойств: для холодильников — объем морозильной камеры, число компрессоров, уровень шума; для компьютеров — объем оперативной памяти, объем жесткого диска; для одежды — размер, рост, цвет.
В дальнейшем на основе этих характеристик можно строить отчеты, анализировать объемы продаж, получать другую информацию для принятия решений.
Задача описания характеристик состоит из двух этапов: создания характеристик и хранения значений созданных характеристик. Например, чтобы указать, что конкретная модель одежды имеет 48 размер, 5 рост и черный цвет, сначала следует создать (если они еще не созданы в прикладном решении) следующие характеристики:
- размер, которая будет иметь тип значения Число;
- рост, которая будет иметь тип значения Число;
- цвет, которая будет иметь тип значения СправочникЦвета.
После того, как нужные характеристики созданы, можно уже указать их конкретные значения для выбранной номенклатуры:
- размер = 48;
- рост = 5;
- цвет = Черный.
- План видов характеристик
Планы видов характеристик используется для создания и хранения перечня характеристик, которые могут использоваться в прикладном решении. Подробнее…
Записи, хранящиеся в этом регистре, будут выглядеть следующим образом:
Описание характеристик в дереве конфигурации
Для каждого объекта конфигурации, предусматривающего использование характеристик, прямо в дереве конфигурации можно указать связь с перечнем его характеристик и с тем объектом конфигурации, в котором хранятся значения этих характеристик.
В результате все отчеты и динамические списки, в которых участвует этот объект конфигурации, будут автоматически «подхватывать» его характеристики. Это избавляет разработчика от необходимости описывать эту связь в каждом новом отчете или динамическом списке.
Умеете ли вы работать с вкладкой Характеристики конструктора запросов в СКД? Если нет, то следующий разбор вопроса для вас. Тренер на простом примере продемонстрирует, как в отчете на СКД легко добавить возможность использования дополнительных свойств объектов. При этом ни один ПВХ задействован не будет))
Вопрос
Вроде все понятно в теории, а на практике не получается вывести в отчете дополнительные сведения. Помогите мне на моем примере, пожалуйста.
Пример: есть документы, где физ. лицам производят определенные начисления. У каждого физ. лица есть свой внутренний идентификатор (ИД), который не является реквизитом справочника физ. лица. Значение ИД хранится в регистре сведений “ИД физ. лиц”. Нужно в отчет вывести данные о начислениях документов за период и отдельной колонкой этот ИД. Не понимаю, как на вкладке Характеристики конструктора запроса в СКД задать эту связь.
Ответ
Создаем пустую базу, добавляем в конфигураторе справочник Физлица и независимый непериодический регистр сведений ИдентификаторыФизлиц следующей структуры:
В пользовательском режиме создаем элемент справочника, заполняем идентификатор в регистре:
В конструкторе схемы компоновки на закладке Характеристики выполняем следующие настройки:
(нажмите, чтобы увеличить картинку)
Обратите внимание, что ни одного ПВХ в базе нет.
Настройки выполняем именно таким образом:
- В колонке Тип указываем, для какого объекта настраиваем характеристики – это справочник Физлица.
- Поскольку в базе нет объекта (таблицы), где хранится перечень используемых видов характеристик (например, ПВХ), то в качестве источника видов характеристик используем запрос. В качестве ключа и имени вида характеристики указываем строку “Идентификатор физлица”. Значит, в пользовательском режиме, когда развернем список вложенных полей для физлица, будет доступно новое поле “Идентификатор физлица”.
- Поскольку в регистре сведений ИдентификаторыФизлиц нет поля, где хранится вид характеристики, тоже используем запрос, в котором строкой пропишем имя вида характеристики – “Идентификатор физлица”.
Поле объекта – это измерение регистра сведений “Физлицо”, так как именно в нем содержится поле нужного типа (п. 1), для которого получаем значения свойства.
Поле вида – это ключ вида характеристики (строка “Идентификатор физлица”), так как в регистре нет отдельного поля для хранения вида характеристики. Здесь должно быть указано то же значение, что и в “Поле ключа”. Так связывается вид характеристики и значение характеристики.
Поле значения – это ресурс регистра сведений “ИдентификаторФизлица”, поскольку именно в нем хранится значение характеристики – сам идентификатор.
После таких настроек в отчете можно вывести вложенное поле “Идентификатор физлица”:
Необходимо реализовать использование дополнительных свойств объектов в отчетах. Произвести в конфигураторе настройки объектов метаданных для обеспечения использования дополнительных свойств экземпляров этих объектов в пользовательском режиме (в отчетах и формах).
При выполнении поставленной задачи используются объекты конфигурации, созданные в ходе изучения вариантов решения предыдущей задачи.
Пользователь может использовать характеристики, назначенные на уровне объекта метаданных, в отборах отчета, построенного на СКД, в настройках динамических списков и т.д.
Использование механизма характеристик в отчетах на СКД
При использовании ПВХ пользователь в режиме «1С:Предприятие» может настроить произвольные характеристики для различных объектов базы. Специальные механизмы для работы с характеристиками предоставляет Система компоновки данных.
В конфигураторе для конкретного отчета можно описать характеристики, которые в настройках отчета в пользовательском режиме будут использоваться как реквизиты (вложенные поля объектов). Такие «реквизиты» можно использовать для отборов, выводить в отчет, использовать для условного оформления.
Рассмотрим пример. При настройке отчета в пользовательском режиме в отборах можно использовать поля «Разрешение экрана» или «Тип SIM-карты».
Рисунок 1 – Доступность характеристик в виде вложенных полей
Однако в справочнике «Номенклатура» такие реквизиты в конфигураторе не создавались. В предыдущем разделе демонстрировалось, как организовать назначение таких характеристик при помощи ПВХ. Система компоновки данных позволяет выводить дополнительные характеристики вместе с реквизитами объектов. Причем пользователю даже не нужно знать, является ли конкретное поле реквизитом объекта или характеристикой. В настройках отчета они будут отображаться одинаково – как реквизиты объекта (в виде вложенных полей).
Подобное поведение можно реализовать при помощи расширения языка запросов для системы компоновки данных. Таким образом в отчетах на СКД можно указывать, какие виды характеристик могут быть использованы в отчете, и как значения этих характеристик получать из базы. Рассмотрим этот механизм подробнее.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
Достаточно часто возникает необходимость в добавлении объектам дополнительных реквизитов (характеристик). При этом каждый раз вносить для этого изменения в конфигурацию и проводить реструктуризацию базы данных не хочется.
В этой статье я расскажу о том, как реализовать такую возможность с помощью плана видов характеристик и регистра сведений и поделюсь парой приёмов использования этих реквизитов в отчётах и списках.
Изменения в конфигурации
Разработку конфигурации будем вести на базе платформе 1С: Предприятие 8.2 с установленным свойством “Основной режим запуска” – “Управляемое приложение”. В качестве основы для разработки подойдет любая демо-конфигурация. Добавим новый план видов характеристик “Виды характеристик”. На закладке “Основные” плана видов характеристик в поле “Тип значения характеристик” выберем необходимые типы.
В качестве одного из возможных типов значений характеристик выберем предварительно добавленный в конфигурацию справочник “Значения характеристик”, подчиненный плану видов характеристик “Виды характеристик”. Его же выберем в поле “Дополнительные значения характеристик”. Это позволит добавлять характеристики с произвольными ссылочными значениями (например, цвет или размер).
Создадим регистр сведений “Характеристики” с измерениями “Объект”, “Вид характеристики” и ресурсом “Значение”. Измерение “Объект” должно включать в себя все типы объектов для которых необходимо использовать дополнительные реквизиты. В нашем случае это будет справочник “Контрагенты”, В свойствах измерения “Объект” должны быть установлены флаги “Ведущее”, “Основной отбор” и “Запрет незаполненных”.
Это обеспечит связь объекта с записями регистра сведений. В форме элемента справочника “Контрагенты” переход к редактированию характеристик будет возможен с помощью соответствующего пункта меню “Перейти” в левой части формы.
Измерению “Вид характеристики” необходимо назначить тип “ПланВидовХарактеристикСсылка.ВидыХарактеристик”, а ресурсу “Значение” – “Характеристика.ВидыХарактеристик”.
Для обеспечения взаимосвязи значений ресурса “Значение” со значениями измерения “ВидХарактеристик” регистра “Характеристики” необходимо чтобы в свойстве “Связи параметров выбора” ресурса “Значение” было указано “Отбор.Владелец(ВидХарактеристики)”, а в свойстве “Связь по типу” – “ВидХарактеристики”
Теперь всё готово для того чтобы мы могли вводить в базу данных дополнительные реквизиты справочника “Контрагенты”.
Попробуем добавить дополнительный реквизит “Адрес”
Использование дополнительных реквизитов в отчётах и списках
После того как все необходимые изменения в конфигурации выполнены возникает вопрос о том как использовать дополнительные реквизиты для вывода и фильтрации данных в отчётах и списках.
Вариант №1
Начнём с использования характеристик в отчёте, разработанном с использованием системы компоновки данных. За основу возьмём отчёт “Ведомость взаиморасчетов”. Добавим в конфигурацию копию этого отчёта и назовём его “Ведомость взаиморасчетов (с характеристиками)”.
Оригинал отчёта нам понадобится для демонстрации второго варианта использования характеристик.
Итак, откроем набор данных “Взаиморасчеты” схемы компоновки данных нашего отчета в конструкторе запросов и перейдем на закладку “Характеристики”.
- В таблицу на вкладке “Характеристики” добавим строку.
- В поле “Тип” выберем “СправочникСсылка.Контрагенты” (это объект для которого в отчёте необходимо использовать дополнительные характеристики).
- В поле “Источник видов” выберем вариант “Запрос” (хотя в нашем случае можно ограничиться и вариантом “Таблица”).
- В колонку “Виды характеристик” внесём текст запроса, которым будут выбираться виды характеристик, используемые для справочника “Контрагенты”.
Текст запроса обязательно должен содержать три поля – ссылка на вид характеристики, наименование характеристики и тип значения характеристики. Наименования этих полей выбираются в колонках “Поле ключа”, “Поле имени” и “Поле типа значения” таблицы на закладке “Характеристики”.
- Для визуального выделения дополнительных реквизитов объекта в запросе по видам характеристик к наименованиям добавлен текст “(доп. реквизит)”.
- В колонке “Источник значений” на вкладке “Характеристики” выберем вариант “Таблица”.
- В колонке “Значения характеристик” выберем “РегистрСведений.Характеристики”,
- в колонке “Поле объекта” – наименование измерения регистра “Объект”,
- в колонке “Поле вида” – наименование измерения “ВидХарактеристики”,
- в колонке “Поле значения” – наименование ресурса “Значение”.
В тексте запроса схемы компоновки результат добавления характеристик выглядит следующим образом (в обычных запросах применение таких конструкций невозможно):
<ХАРАКТЕРИСТИКИ
ТИП ( Справочник . Контрагенты )
ВИДЫХАРАКТЕРИСТИК ( ВЫБРАТЬ
ВидыХарактеристик . Ссылка ,
ВидыХарактеристик . Наименование + » (доп. реквизит)» КАК Наименование ,
ВидыХарактеристик . ТипЗначения
ИЗ
ПланВидовХарактеристик . ВидыХарактеристик КАК ВидыХарактеристик )
ПОЛЕКЛЮЧА Ссылка
ПОЛЕИМЕНИ Наименование
ПОЛЕТИПАЗНАЧЕНИЯ ТипЗначения
ЗНАЧЕНИЯХАРАКТЕРИСТИК РегистрСведений . Характеристики
ПОЛЕОБЪЕКТА Объект
ПОЛЕВИДА ВидХарактеристики
ПОЛЕЗНАЧЕНИЯ Значение >ХАРАКТЕРИСТИКИ
Проверим работу отчёта. Для этого откроем отчёт “Ведомость взаиморасчетов (с характеристиками)”. Перейдем в пункт меню “Все действия -> Изменить вариант”. В окне настроек перейдём на закладку “Отбор” и добавим отбора по дополнительному реквизиту контрагента “Адрес”
Вариант №2
Рассмотрим более универсальный вариант работы с характеристикам объектов, благодаря которому характеристики возможно будет использовать в любых отчетах, содержащих объект-владелец характеристик, а также устанавливать отборы по значению этих характеристик в формах списков.
Перейдём на закладку “Данные” справочника “Контрагенты” и нажмём кнопку “Характеристики”.
- В открывшемся окне “Дополнительных характеристик объекта метаданных” добавим строку.
- В колонке “Виды характеристик” выберем “ПланВидовХарактеристик.ВидыХарактеристик”, в колонке “Поле ключа” – “Ссылка”.
- В колонке “Значения характеристик” выберем “РегистрСведений.Характеристики”, в колонке “Поле объекта” – “Объект”,
- в колонке “Поле вида” – “ВидХарактеристики”, в колонке “Поле значения” – “Значение”.
Сохраним конфигурацию и попробуем воспользоваться дополнительными характеристиками справочника “Контрагенты” в форме списка (в отчёте “Ведомость взаиморасчетов” использование дополнительных реквизитов будет выглядеть аналогичному тому как это было описано в Варианте №1, с той лишь разницей, что наименованию вида характеристики не будет добавляться текст “(доп. реквизит)”).
Откроем список справочника “Контрагенты”, перейдем в пункт меню “Все действия -> Настройка списка” и установим отбор по дополнительному реквизиту “Адрес”.
Стоит отметить, что при использовании Варианта №1 в отчётах с использованием СКД отключается приведенный механизм платформы и используется описанный пользователем.
Статья найдена на просторах интернета.
Большой рекламный бюджет не ведет к высокому уровню сбыта. Наоборот, высокий уровень сбыта ведет к большому рекламному бюджету.
— К. Мейсон
Читайте также: