Механизм АналитикаУчётаНоменклатуры является краеугольным камнем аналитического учёта товаров и услуг в современных типовых конфигурациях 1С, таких как «Управление торговлей 11» (УТ 11), «Комплексная автоматизация 2» (КА 2) и «ERP Управление предприятием 2» (ERP 2). Этот механизм разработан для того, чтобы значительно детализировать информацию о номенклатуре, позволяя нам эффективно отслеживать её движение, контролировать остатки на складах и фиксировать изменения цен. Часто при первом знакомстве с этим механизмом возникают вопросы о его структуре, назначении связанных объектов и методах получения данных. Давайте вместе разберем все аспекты этого сложного, но очень мощного инструмента, включая выравнивание складских остатков.
Суть механизма АналитикаУчётаНоменклатуры заключается в подходе к хранению и агрегации аналитических разрезов. Представим, что у нас есть номенклатура, которая может иметь характеристики (например, цвет, размер), серии (партии производства или год выпуска) и назначения (целевое использование или проект). Если бы мы для каждого из этих параметров создавали отдельное измерение в регистре накопления (например, Номенклатура, Характеристика, Серия, Назначение и так далее), то количество измерений в регистрах учета стало бы очень большим. Это привело бы к усложнению структуры базы данных, увеличению её объема и замедлению работы системы из-за больших составных индексов.
Разработчики 1С решили эту проблему элегантным способом: вместо множества отдельных измерений, они объединили все эти параметры в одно агрегированное измерение – АналитикаУчётаНоменклатуры. Это измерение в регистрах накопления, таких как Выручка и себестоимость продаж (где полезен анализ списания запасов без закрытия месяца), является ссылкой — для такой задачи подойдёт расчет себестоимости при проведении в УТ 11 и КА 2. Но на что оно ссылается?
Мы видим, что измерение АналитикаУчётаНоменклатуры ссылается на специальный справочник – КлючиАналитикиУчётаНоменклатуры. В элементах этого справочника, в свою очередь, хранятся реквизиты, описывающие все детали составного ключа: Номенклатура, Характеристика, Серия, Назначение и любые другие аналитические разрезы, которые требуются для конкретной номенклатуры. Таким образом, каждый элемент справочника КлючиАналитикиУчётаНоменклатуры представляет собой уникальную комбинацию конкретных значений аналитического учета — для исправления некорректных записей в этой структуре есть обработка исправления ошибок ключей аналитики в ERP, КА, УТ.
Давайте рассмотрим, как это работает на практике:
КлючиАналитикиУчётаНоменклатуры, который соответствует этой комбинации.АналитикаУчётаНоменклатуры регистра накопления.Этот подход позволяет значительно оптимизировать количество измерений в регистрах учета, делая их структуру более компактной и гибкой. Мы можем добавлять новые аналитические разрезы в справочник КлючиАналитикиУчётаНоменклатуры, не меняя структуру регистров накопления.
Возникает логичный вопрос: если у нас уже есть справочник КлючиАналитикиУчётаНоменклатуры, который хранит все необходимые комбинации аналитик, зачем нам ещё и регистр сведений с похожим названием – АналитикаУчётаНоменклатуры – и, казалось бы, с теми же полями, что и у справочника? Этот вопрос был одним из ключевых моментов вашего замешательства, и его решение кроется в глубокой оптимизации производительности.
Давайте проанализируем ситуацию:
Представьте, что при проведении каждого документа, затрагивающего номенклатуру, системе нужно определить, существует ли уже конкретная комбинация аналитик (Номенклатура, Характеристика, Серия и т.д.) в справочнике КлючиАналитикиУчётаНоменклатуры. Если бы для этого поиска использовался только сам справочник, запрос выглядел бы примерно так:
ВЫБРАТЬ
КлючиАналитикиУчетаНоменклатуры.Ссылка
ИЗ
Справочник.КлючиАналитикиУчетаНоменклатуры КАК КлючиАналитикиУчетаНоменклатуры
ГДЕ
КлючиАналитикиУчетаНоменклатуры.Номенклатура = &Номенклатура
И КлючиАналитикиУчетаНоменклатуры.Характеристика = &Характеристика
И КлючиАналитикиУчетаНоменклатуры.Серия = &Серия
// ... и так далее для всех реквизитов
Такой запрос, выполняемый непосредственно по справочнику, не всегда будет оптимальным. Почему? Потому что кластерный индекс справочника обычно строится по его основному полю – Ссылка (или Код/Наименование, в зависимости от настроек), но не по всей комбинации его реквизитов. Если справочник содержит миллионы элементов, поиск по его реквизитам без специализированного индекса будет медленным, так как системе придётся сканировать большое количество записей.
Именно здесь на сцену выходит Регистр сведений АналитикаУчётаНоменклатуры. Его основное назначение – кардинальная оптимизация поиска и контроля уникальности ключей аналитики.
АналитикаУчётаНоменклатуры включает в себя все его измерения – то есть, Номенклатура, Характеристика, Серия и т.д. Кластерный индекс физически упорядочивает записи таблицы по значениям своих полей. Это означает, что данные в базе данных расположены таким образом, что поиск по всем измерениям регистра сведений будет выполняться значительно быстрее, чем по реквизитам справочника без подобного составного индекса. Запрос к регистру сведений по искомым измерениям (Номенклатура, Характеристика, Серия) мгновенно попадает в нужный блок данных, что критически важно для производительности.
КлючиАналитикиУчётаНоменклатуры. Когда системе нужно найти существующий ключ аналитики по определённому набору параметров, она сначала обращается к регистру сведений. Запрос к регистру сведений по набору измерений выполняется очень быстро, и если запись найдена, регистр возвращает ссылку на соответствующий элемент справочника КлючиАналитикиУчётаНоменклатуры. Если запись не найдена, это означает, что такой комбинации аналитик ещё нет в базе данных.
КлючиАналитикиУчётаНоменклатуры. Одновременно с этим, в регистр сведений АналитикаУчётаНоменклатуры добавляется новая запись, которая связывает все измерения с этим новым элементом справочника. Таким образом, регистр сведений поддерживает актуальность данных и обеспечивает, что каждая уникальная комбинация аналитик имеет свой «ключ» для быстрого доступа.
Поскольку поиск ключей аналитики происходит при проведении почти всех документов учета товарно-материальных ценностей (ТМЦ), такая оптимизация является не просто желательной, а критически важной для обеспечения высокой производительности системы. Если бы такой регистр сведений отсутствовал, а поиск выполнялся исключительно по справочнику, работа типовых конфигураций на крупных базах данных была бы неприемлемо медленной.
После того как мы разобрались со структурой и назначением АналитикиУчётаНоменклатуры, следующим важным шагом становится понимание, как эффективно извлекать из неё данные. Вы совершенно справедливо задались вопросом о том, как лучше получать детализированные данные – через «раскрытие измерения» в виртуальной таблице или через явное «соединение со справочником».
Начнём с того, что оба подхода, по сути, могут привести к одному и тому же результату на уровне данных. Однако с точки зрения удобства написания запроса, его читаемости и, что важно, внутренней оптимизации платформой 1С, существуют определённые предпочтения.
Этот способ является наиболее рекомендуемым и часто используется разработчиками 1С в типовых отчётах. Когда мы обращаемся к виртуальной таблице регистра накопления (например, ВыручкаИСебестоимостьПродаж.ОстаткиИОбороты), платформа 1С предоставляет нам возможность «раскрыть» измерения, которые ссылаются на другие объекты, и получить доступ к их реквизитам напрямую, используя точечную нотацию.
Давайте посмотрим на концептуальный пример:
ВЫБРАТЬ
ВыручкаИСебестоимостьПродажОстаткиИОбороты.АналитикаУчетаНоменклатуры.Номенклатура КАК Номенклатура,
ВыручкаИСебестоимостьПродажОстаткиИОбороты.АналитикаУчетаНоменклатуры.Характеристика КАК Характеристика,
ВыручкаИСебестоимостьПродажОстаткиИОбороты.КоличествоОстаток КАК Количество,
ВыручкаИСебестоимостьПродажОстаткиИОбороты.СтоимостьОстаток КАК Стоимость
ИЗ
РегистрНакопления.ВыручкаИСебестоимостьПродаж.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, , , ) КАК ВыручкаИСебестоимостьПродажОстаткиИОбороты
ГДЕ
ВыручкаИСебестоимостьПродажОстаткиИОбороты.АналитикаУчетаНоменклатуры.Номенклатура = &КонкретнаяНоменклатура
В этом запросе мы обращаемся к АналитикаУчетаНоменклатуры.Номенклатура и АналитикаУчетаНоменклатуры.Характеристика. Платформа 1С самостоятельно выполняет неявное соединение с таблицей справочника КлючиАналитикиУчётаНоменклатуры и выбирает нужные реквизиты. Этот метод удобен для написания и чтения запросов на языке 1С, так как он делает запрос более компактным и понятным.
Второй подход заключается в том, чтобы явно выполнить соединение регистра накопления со справочником КлючиАналитикиУчётаНоменклатуры. Этот метод также является рабочим и может быть полезен в более сложных запросах, когда требуется дополнительная фильтрация или получение данных из самого справочника, которые не являются составными реквизитами ключа аналитики.
Концептуальный пример запроса с явным соединением:
ВЫБРАТЬ
КлючиАналитики.Номенклатура КАК Номенклатура,
КлючиАналитики.Характеристика КАК Характеристика,
ВыручкаИСебестоимостьПродажОстаткиИОбороты.КоличествоОстаток КАК Количество,
ВыручкаИСебестоимостьПродажОстаткиИОбороты.СтоимостьОстаток КАК Стоимость
ИЗ
РегистрНакопления.ВыручкаИСебестоимостьПродаж.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, , , ) КАК ВыручкаИСебестоимостьПродажОстаткиИОбороты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.КлючиАналитикиУчетаНоменклатуры КАК КлючиАналитики
ПО ВыручкаИСебестоимостьПродажОстаткиИОбороты.АналитикаУчетаНоменклатуры = КлючиАналитики.Ссылка
ГДЕ
КлючиАналитики.Номенклатура = &КонкретнаяНоменклатура
Ваш опыт, описанный в сообщении 9, когда вы получили разное количество строк (300 и 700) при разных подходах к запросу, является очень важным и указывает на потенциальные подводные камни. Утверждение, что «для системы – разницы нет. На уровне SQL запрос будет одинаков» (сообщение 6), верно в идеализированном случае, когда запросы абсолютно эквивалентны по своей логике и условиям. Однако на практике, небольшие различия в построении запросов могут приводить к совершенно разным результатам.
Давайте проанализируем, почему это могло произойти, и какие рекомендации можно дать:
АналитикаУчетаНоменклатуры.Номенклатура), платформа 1С преобразует этот запрос в SQL, создавая внутреннее соединение с таблицей справочника. Чаще всего платформа делает это очень эффективно. Однако, если мы используем сложные условия в секции ГДЕ, которые затрагивают реквизиты, полученные через «точку», иногда это может приводить к неоптимальной работе запросов или неявным внутренним соединениям, которые отсекают записи, где ссылка на справочник не заполнена (хотя в случае АналитикаУчетаНоменклатуры, как измерения регистра накопления, она всегда должна быть заполнена).
ВыручкаИСебестоимостьПродаж.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, , , )). Виртуальные таблицы формируются динамически на основе реальных таблиц базы данных в момент выполнения запроса. Они содержат только ту информацию, которая необходима для конкретной операции. Передача условий отбора в параметры позволяет платформе максимально отфильтровать данные ещё до того, как они будут загружены в память или обработаны. Если же мы будем применять сложные условия в секции ГДЕ после формирования виртуальной таблицы, это может привести к тому, что сначала будет выбрано много лишних данных, а уже потом они будут отфильтрованы, что замедлит выполнение запроса.
ГДЕ. Разница в количестве строк (300 против 700) в ваших тестах, скорее всего, связана с тем, что в ваших «скриншотах» (как вы упомянули) запросы содержали разные условия отбора или по-разному обрабатывали отсутствующие значения. Например, если при явном соединении использовалось ЛЕВОЕ СОЕДИНЕНИЕ, а в другом случае неявное соединение через точку (которое часто равносильно ВНУТРЕННЕМУ СОЕДИНЕНИЮ), это могло привести к разному числу строк, если были записи с незаполненными или несуществующими ссылками. Всегда внимательно проверяйте условия ГДЕ и тип соединения.
КлючиАналитикиУчётаНоменклатуры из измерения АналитикаУчётаНоменклатуры регистра накопления, используйте точечную нотацию (АналитикаУчетаНоменклатуры.Номенклатура). Этот подход более читаем и обычно хорошо оптимизируется платформой 1С.
Номенклатуре или Характеристике, старайтесь передавать эти условия в параметры виртуальной таблицы регистра, если она это позволяет. Например, для ОстаткиИОбороты можно передать отбор по конкретной аналитике или по Номенклатуре, если это предусмотрено в параметрах виртуальной таблицы.
Помните, что для системы – то есть для SQL-сервера – конечный запрос всегда будет выглядеть как соединение таблиц. Разница лишь в том, как платформа 1С преобразует ваш запрос на языке 1С в этот SQL-запрос. И эта разница может быть существенной с точки зрения эффективности.
Механизм АналитикаУчётаНоменклатуры является мощным и гибким инструментом для детализированного учета номенклатуры в 1С. Мы выяснили, что его ключевой элемент – справочник КлючиАналитикиУчётаНоменклатуры – хранит уникальные комбинации аналитик, а Регистр сведений АналитикаУчётаНоменклатуры служит для сверхбыстрого поиска этих ключей и контроля их уникальности благодаря оптимизированным кластерным индексам. Мы также рассмотрели два основных подхода к запросу данных из регистров с этим измерением: раскрытие через точку и явное соединение. Рекомендуем отдавать предпочтение раскрытию через точку для удобства и читаемости, а также всегда стараться передавать условия отбора в параметры виртуальных таблиц для максимальной производительности.