Как выбирать данные в типовых конфигурациях, если в регистрах вместо нормальных измерений Номенклатура или Подразделение разработчики использовали КлючиАналитики…
Два видео, 42 минуты на изучение “под ключ”.
Когда заходишь в регистр типовой конфигурации и в измерении ожидаешь увидеть нормальный справочник (Номенклатуру или Подразделение, например), но вместо него там какая-то АналитикаУчета… – это и есть КлючиАналитики.
Например, в УТ 11 есть регистр накопления ВыручкаИСебестоимостьПродаж – но никакого измерения Номенклатура в нем нет, зато есть АналитикаУчетаНоменклатуры. Или вот еще – АналитикаУчетаПартнеров.
Что это вообще такое? Где про это написано? Как с этим работать?
Даже с выборкой данных о продажах по номенклатуре придется повозиться, хотя, казалось бы, это простейшая задача.
Использование ключей в типовых конфигурациях – многолетняя и массовая практика.
Поэтому любому разработчику, работающему с типовыми конфигурациями, нужно обязательно понимать, что такое ключи аналитики, как хранятся данные, как выбирать данные из базы.
Разберемся с ключами аналитики в сегодняшнем видео
В видео мы рассмотрим подробно, что такое ключи аналитики, почему появилось такое решение. Отметим, что впервые оно появилось в 1С:УПП для учета запасов и затрат при использовании РАУЗ (расширенной аналитики учета затрат). Рассмотрим, как составлять запросы к регистру УчетЗатрат.
Так как УПП – это уже конфигурация прошлого поколения, разберем также использование ключей аналитики в современном флагманском решении 1С:ERP. Причем все рассмотренное можно будет смело применять и в 1C:Комплексной автоматизации 2, и в 1С:Управление торговлей 11.
Кроме того, покажем, как запросами извлекать данные из базы, рассмотрим, как написаны типовые отчеты.
Часть 1: что такое ключи аналитики, как появились и для чего используются
Содержание:
- Что такое ключи аналитики, история появления этого механизма
- Почему в современных конфигурациях используются ключи аналитики
- Как технически реализована работа с ключами аналитики
- Как использовать ключи аналитики в запросах.
Длительность видео – 24 минуты.
Часть 2: Как ключи аналитики применяются в современных конфигурациях
В современных типовых решениях при работе с ключами аналитики есть ряд отличий, о которых важно знать. Об этом – в видео:
- Чем использование ключей аналитики в современных конфигурациях 1C:ERP 2, КА 2, УТ 11 отличается от использования в 1С:УПП.
- Как ключи аналитики используются в программном коде, запросах и отчетах.
- Рассмотрим практический пример с использованием ключей аналитики в запросе.
Длительность видео – 17 минут.
На этом курсе Вы изучите все, что требуется знать каждому разработчику:
- Полный синтаксис текста запросов – поля, операторы, функции, выражения, группировка и сортировка, итоги и т.д.
- Работу с несколькими источниками / таблицами – соединения, объединения, вложенные запросы
- Временные таблицы, пакетные запросы
- Виртуальные таблицы – для регистров сведений, накоплений, расчетов и бухгалтерии
- Методы и приемы написания и оптимизации запросов
- А также много практических примеров и кейсов.
- 56 учебных часов
- 42 практических задания
- 4 месяца поддержки и ответов на вопросы
- Пожизненный доступ к материалам курса
Василий, здравствуйте.
Если после проведения процедуры удаления дублей контрагентов и партнёров “полетели” ключи аналитики и в документ “Сверка взаиморасчётов” попадают некорректные документы, как можно исправить ключи?
Добрый день!
В конфигурациях УТ, КА, ERP Контрагенты и Партнеры – это разные справочники, поэтому дубли нужно удалять в каждом из справочников отдельно. И в случае, когда партнеры и контрагенты в конкретной базе ведутся раздельно, и в случае, когда эта настройка выключена.
Далее – в форме списка справочника КлючиАналитикиУчетаПоПартнерам есть команда ЗаменитьДубли. Может оказаться полезной.
Также очень важно наличие резервной копии базы до удаления дублей. С ней можно будет сверяться, сравнивать движения. Может помочь получение идентификаторов элементов справочника, чтобы сравнивать, какой элемент справочника использовался в исходной базе, а какой – в обработанной. Наименования ключей похожи (особенно для дублирующихся контрагентов), искать и сравнивать по идентификаторам может оказаться удобнее.
Далее – методический вопрос. Что делать со взаиморасчетами после замены дублей? На одном контрагенте может числиться долг, а на его дубле – аванс. Как поступать в таком случае? Перепроводить все документы после замены дублей? А если часть из них – в закрытом периоде? Тут нужно обсуждать конкретные решения с заказчиком. Может, для разных групп дублей нужно будет выполнять разные действия.
Также замену дублей можно совместить с переходом на новую базу/редакцию/конфигурацию. Заодно и порядок в справочниках навести. Переносим справочники, в них заменяем дубли, пока ключей аналитики в новой базе еще нет, вводим остатки по взаиморасчетам, потом проводим документы, когда дублей уже нет.
1. Подскажите, почему в примере УПП соединение левое?
Получается, может быть случай, когда в регистре накопления есть данные, а в в рег. сведений данных по ключам нет.
2. Можете пояснить на примере, что значит дублирование при использовании РИБ и каким образом наличие аналитик в справочнике и регистре решает эту задачу?
Добрый день!
1. Да, такая ситуация может быть. Но она некорректная с точки зрения целостности данных.
Если есть ключ аналитики, но для него нет данных в регистре сведений, то при использовании левого соединения будут выведены все данные из левой таблицы (из регистра накопления). Да, будут получено значение типа NULL вместо номенклатуры, но общая сумма или количество из регистра накопления будут выведены правильно. Если бы использовали внутреннее соединение, то сумма или количество для такого “битого” ключа потерялись.
2. Предположим, что в РИБ есть 2 узла (главный и периферийный). Это отдельные базы, поэтому в них независимо друг от друга могут быть созданы ключи аналитики для одного и того же набора полей (номенклатура, характеристика, серия и т.д.).
Ключи аналитики – это элементы справочника, у них есть уникальные идентификаторы. Идентификаторы в двух базах будут назначены различные.
После обмена получится, что в справочнике с ключами есть два элемента (один – из текущей базы, второй – из другой базы) с разными идентификаторами, но в регистр сведений АналитикаУчетаНоменклатуры может быть записан только один из них (т.к. измерениями являются Номенклатура, Характеристика, Серия и т.д., а они одинаковы для двух ключей). Это некорректная ситуация с точки зрения целостности данных, поэтому при загрузке данных выполняется замена дублей. Чтобы определить, какие ключи относятся к одному и тому же набору полей (номенклатура, характеристика, серия и т.д.), и были добавлены реквизиты в справочник ключей аналитики. Без них не получится выполнить такую замену дублей.
Здравствуйте Василий!
Интересная консоль запросов используется ~ c 16 минуты первого видео.
Не подскажите, где такую взять?
Добрый день!
Это консоль запросов из подсистемы Инструменты разработчика.
в последнем видео непонятно зачем для получения номенклатуры соединяться с РС АналитикаУчетаНоменклатуры когда из измерения РН уже можно через точку от ключааналитики получить Номенклатуру и это и будет “неявное” соединение со справочником (на стороне СУБД). Это вопрос производительности только ?
Добрый день!
Здесь можно выделить 2 аспекта:
1. С методической точки зрения правильнее было бы получать данные из регистра, ведь при проведении поиск ключа аналитики выполняется именно по наличию записи в регистре. Т.е. записи в регистре первичны, по ним ищется ключ.
2. С точки зрения производительности при получении данных (например, в отчетах) чаще всего используется получение данных из справочника, вообще не обращаясь к регистру сведений. Т.е. здесь предполагается, что данные в регистре и в справочнике совпадают, а проще получить данные из справочника (см. комментарий ниже про индексы).
В общем случае нужно проанализировать планы запросов для всех вариантов получения данных, принять решение, какой вариант выбрать.
Добрый день.
Достаточно давно работаю с РАУЗом в УПП и не могу ответить для себя на вопрос, почему в регистрах ключей ссылка это ресурс? Ведь логичней для связи 1:1 сделать ссылку измерением, а сами аналитики вынести как раз в ресурсы.
Добрый день!
При проведении документа производится поиск ключа в регистре сведений по значениям всех аналитик. Нужно обеспечить, чтобы по всем значениям аналитики был найден только один ключ аналитики. Это можно реализовать, если значения аналитик будут измерениями регистра. Если же элемент справочника будет измерением регистра, а значения аналитик будут ресурсами, то по одному и тому же набору значений аналитик можно найти несколько ключей (т.к. платформа контролирует уникальность в разрезе измерений, а не ресурсов).
Кроме этого предполагаю, что такая архитектура связана с оптимизацией производительности.
В независимом регистре сведений есть кластерный индекс, включающий все измерения в том порядке, в котором они заданы в конфигураторе. Вот этот индекс и задействуется. А индекса по всем ресурсам для регистра сведений нет.
Добрый день!
Спасибо за видеообзор интересной темы. Всё же остаётся вопрос: если в современных конфигурациях разработчики решили добавить измерения в том числе и в справочник и теперь появилась возможность соединяться как с РС, так и со справочником “ключи аналитики”. Какие есть достоинства и недостатки соединения с каждым из используемых объектов? С каким из объектов соединяться предпочтительнее, в каких ситуациях? И зачем вообще нужен РС, может быть справочника достаточно (а им и удобнее пользоваться)?
Добрый день!
При проведении документа по указанным в документе значениям (номенклатуре, характеристике и т.д.) производится поиск в регистре сведений АналитикаУчетаНоменклатуры. Если подходящей записи в регистре нет, создается элемент справочника КлючиАналитикиУчетаНоменклатуры, заполняются реквизиты этого элемента значениями из документа, эти же значения записываются в регистр. Т.е. в регистре и в элементе справочника должны храниться одинаковые значения.
Пример такого поведения – метод ИнициализироватьКлючиАналитикиУчетаНоменклатуры в модуле менеджера документа ВводОстатков.
Также в модуле объекта плана обмена Полный (это план обмена с установленной галочкой РИБ) есть метод ПослеЗагрузкиДанных, в котором есть следующий код:
Справочники.КлючиАналитикиУчетаПоПартнерам.ЗаменитьДублиКлючейАналитики();
Справочники.КлючиАналитикиУчетаПартий.ЗаменитьДублиКлючейАналитики();
...
В этих процедурах сравниваются значения одноименных полей справочника и регистра сведений. Таким образом, справочник и регистр нужны для поиска дублей после загрузки из узла РИБ.
При получении данных (например, в отчетах) чаще всего используется получение данных из справочника, вообще не обращаясь к регистру сведений. Т.е. здесь предполагается, что данные в регистре и в справочнике совпадают, а проще получить данные из справочника (см. комментарий ниже про индексы). Хотя с методической точки зрения правильнее было бы получать данные из регистра, ведь при проведении поиск ключа аналитики выполняется именно по наличию записи в регистре.
Спасибо за видеообзор. Но всё же если подвести итог. То получается РС нужен только для поиска дублей после загрузки из узла РИБ (если Вы им пользуетесь), а если нет то можно обойтись лишь справочниками? Я правильно понимаю?
И тогда почему почему при проектировании УПП разработчики всё же решили хранить измерения в РС всё равно используя справочники как коннектор?
Добрый день!
1. Да, правильно. Первоначально в справочнике не было реквизитов. Затем в справочник реквизиты были добавлены для замены дублей ключей аналитики при загрузке из РИБ.
2. Нашел вот такой слайд от 1С – ответ на вопрос, почему используется справочник и регистр, а не только справочник. Это связано с производительностью при поиске ключа аналитики:
Поэтому при проведении документа по указанным в документе значениям (номенклатуре, характеристике и т.д.) производится поиск в регистре сведений.
Благодарю за ответ!
Это был пример как оборотный регистр, если будем использовать регистр накопления с видом остатки и вытащим вертуальный регистр остатки и обороты, то у нас не поплывут остатки начальный остаток и конечный?
Добрый день!
Нет, поскольку измерением регистра накопления является ключ аналитики. А в регистре остатки хранятся именно в разрезе измерений.
Оптимальнее соединение делать все таки не с регистром, а со справочником. Т.к. в регистре хоть и есть индексирование ресурса, но это индекс некластеризованный, поэтому будет лишняя операция key lookup. В справочнике же индекс по ссылке кластеризованный.
Добрый день!
Спасибо за комментарий!
В программном коде типовой конфигурации встречаются разные варианты таких запросов.
На мой скромный взгляд, видео получилось не полным, т.к. непонятно, что же есть такое ключи аналитики, с точки зрения расчета себестоимости. Нужно было упомянуть граф затрат и систему линейных уравнений, а так младшие коллеги по сути мало что поняли…
Добрый день!
Это отдельная большая и интересная тема – расчет себестоимости, графы, СЛУ. И ее не получилось бы уместить в такой короткий хронометраж.
Но в рамках получения данных из базы с помощью запросов этого касаться не будем, т.к. для этого предварительно нужно еще большой пласт информации разобрать. А поскольку получение данных из ERP, УТ, КА – более распространенная задача, чем работа с самим механизмом расчета себестоимости, из этой огромной темы разобрали только ту небольшую часть, которая касается устройства ключей аналитики и хранения данных в базе.