В системах учета ЕРП, КА, УТ есть агрегированные наборы аналитик в разных разделах учета. Так называемые ключи аналитик учета.
Это сделано для того, чтобы уменьшить количество измерений в регистрах накопления. По сути, ключ аналитики, это элемент отдельного справочника, который содержит уникальный набор некоторого количества аналитик учета. Соответственно, для указания данного ключа необходимо только одно измерение регистра. Это позволяет оптимизировать количество измерений регистров учета.
В конфигурациях типа ЕРП реализовано четыре таких набора аналитик:
- Ключи аналитик учета по партнерам,
- Ключи аналитик учета номенклатуры,
- Ключи аналитик учета партий,
- Ключи аналитик учета наборов.
Разберем один такой набор аналитик, который является самым проблемным – Ключи аналитики учета по партнерам.
Элементы данного справочника указываются в качестве измерения для всех регистров, по которым ведутся расчеты с контрагентами. Основные такие регистры для режима ведения взаиморасчетов online, который является единственно возможным для начала ведения учета в текущих версиях ЕРП, КА:
- Расчеты с клиентами
- Расчеты с клиентами по срокам
- Плановый оплаты клиентов
- Расчеты с поставщиками
- Расчеты с поставщиками по срокам
- Плановые оплаты поставщикам
Замечание: Старый режим учета расчетов ofline на данный момент оставлен для сохранения обратной совместимости, для компаний, которые еще не успели перейти на новый режим. В скором времени он будет полностью удален.
Идея такого решения на мой взгляд хорошая, резко сокращается количество необходимых измерений в регистрах. Однако появляются дополнительные сложности, о которых я хочу написать в этой статье.
Сложности, связанные с использованием ключей аналитик
Во-первых. Справочник ключей будет содержать заведомо бОльшее количество записей, чем справочники с каждой отдельной аналитикой. Потенциально, он может содержать количество записей равное произведению количеств всех входящих в него аналитик. На практике, такого, по понятным причинам, не может произойти. Не может существовать записей с одним контрагентом и всеми договорами системы. Но, тем не менее, количество ключей может быть существенным.
Во-вторых. Необходимо следить за образованием дублей в данном справочнике (элементов с одинаковыми наборами всех аналитик). Если такие дубли будут появляться взаиморасчеты не будет закрываться по регистрам учета. И это несмотря на то, что дублей по основным аналитикам: организация, партнер, контрагент, договор, направление – в системе не будет.
По этим причинам, возможно еще по каким-то мне не ведомым, разработчики наряду со справочниками ключей аналитик создали еще и непериодические независимые регистры сведений с аналогичным набором измерений. Регистры эти содержат всего один ресурс тип которого является сам этот ключ аналитики.
Для рассматриваемого нами справочника ключей регистр называется: Аналитика учета по партнерам. Данный регистр призван решить описанные мной выше проблемы.
Решает ли дополнительный регистр сведений вышеописанные проблемы?
Да, решает. Но с некоторыми оговорками.
Первое: появляется возможность быстрого поиска ключа по набору измерений. При условии, что мы попадаем в кластерный индекс регистра сведений.
Напоминаю. Непериодический независимый регистр сведений содержит по умолчанию кластерный индекс со всеми измерениями данного регистра. Измерения в индексе заданы в порядке из следования в конфигураторе. Это одно из его существенных отличий регистра сведений от справочника, который имеет кластерный индекс только по ссылке. А если индексировать отдельные поля справочника, это все равно не создаст индекса содержащего все поля справочника. Будут созданы отдельные индексы для каждого индексируемого поля.
Для регистра, который мы рассматриваем, набор измерений будет следующий: Партнер, организация, Контрагент, Договор, Направление деятельности.
Соответственно, если строить запрос и при отборе указать следующие поля:
- Партнер,
- Партнер и организация,
- Партнер, организация и контрагент
Мы сможем быстро найти ключ аналитики используя кластерный индекс регистра сведений.
А если при отборе будет указано:
- Организация,
- Контрагент,
- Договор
Поиск будет выполнен по не кластерному индексу, так как для данного регистра создаются отдельные не кластерные индексы для каждого измерения. Затем дополнительно будет выполнен поиск по ключу в кластерном индексе (Key Lookup). Это тоже приемлемо, но медленнее первого варианта.
А вот если при отборе будет указано:
- Организация и контрагент,
- Контрагент и договор,
- Организация, контрагент и договор
При таком варианте запроса, поиска только по индексу не получиться. Оптимизатор SQL, конечно, выберет какой-либо, на его усмотрение, самый оптимальный индекс. Но, в любом случае, будет присутствовать перебор некоторого количество записей. Значительного преимущества в поиске при наличии регистра сведений в данном случае не будет.
Стоит также заметить, что существенную разницу можно заметить только на достаточно большом объеме данных. Да и вообще выше описано, так сказать, стандартное поведение оптимизатора SQL. По факту он вполне может выбрать и другой вариант в какой-то конкретной ситуации. Или же вообще наплевать на индексы и выполнить перебор записей. При относительно не большом количестве записей чаще всего он поступает именно так.
Еще нужно учитывать накладные расходы, связанные с использованием дополнительного регистра сведений с ПЯТЬЮ дополнительными не кластерными индексами (по каждому измерению). Количество индексов влияет на скорость записи в этот регистр, также на размер самой базы данных. Хотя, в сравнении с общим объемом ЕРП или КА это конечно крохи )).
Второе: описанная мною проблема, также частично решается использованием дополнительного регистра сведений. Система технически не позволит создать дубли с одинаковыми измерениями в регистре. Это вроде бы должно решить проблему дублей.
Однако на практике, часто это вызывает еще больше проблем.
Необходимо дополнительно контролировать, что для каждого ключа аналитики (элемента справочника) в системе существует запись в регистре сведений. И эта запись содержит именно те значения измерений, которые указаны в самом ключе.
Например:
Если записи в регистре сведений не будет, система не будет вести себя корректно. Отчеты будут выдавать не верную информацию. Более того, при проведении документа с этим же набором измерений, будет создан дополнительный ключ (дубль существующего) и запись в регистре со ссылкой на новый ключ. Это достаточно частая проблема, и если Вы проверите свою систему, то я уверен практически на 100%, найдете какое-то количество таких ключей. Решается данная проблема очень просто – перезаписью самого ключа.
Еще одна проблема заключается в том, что если значения измерений записи регистра сведений отличаются от полей самого ключа, то система также будет работать некорректно. Это более редкая ситуация и исправить ее не так просто. Интерактивно можно внести изменения только в запись регистра. Исправить реквизиты самого ключа стандартными средствами нельзя. Однако исправлять необходимо именно сам ключ, так как в проверках при создании нового ключа, в отчетах и прочих механизмах анализируются именно данные из регистра сведений. В данному случае можно прибегнуть к любому средству для непосредственного редактирования объектов системы, например Infostart Toolkit – инструмент, в котором сделано то, что давно просят от 1С.
Если Вы работаете с ЕРП или КА, без каких-либо средств прямого редактирования объектов и регистров системы Вам не обойтись )).
Исправление описанных выше несоответствий дополнительно дает гарантию, что на один ключ аналитики учета ссылается только одна запись регистра сведений.
Есть еще одна ошибка, которая может произойти. Партнер, выбранный в ключе аналитики, может не совпадать с партнером, выбранным в договоре. В общем-то, это даже не совсем ошибка, она обычно происходит, когда договор переносится от одного партнера к другому. Вполне логично, что перед данной операцией не должно быть или должны быть закрыты все расчеты по паре аналитик первый партнер и договор. Но на практике это обычно не так и вновь возникают проблемы с закрытием расчетов. Дополнительный регистр сведений в этом случае только усугубляет ситуацию, так как необходимо вносить исправления и в него тоже, потом контролировать соответствие, проверять наличие дублей и все описанное выше.
Замечу также, что ошибки такого рода очень сложно диагностируются консультантами или аналитиками, так как они скрыты во внутренних механизмах системы. Поэтому я рекомендую выполнять профилактические действия, которые сами по себе не сложные, но позволяют избежать большого количества сложно исправимых ошибок в будущем.
Какие можно выполнять профилактические мероприятия с ключами аналитик?
Необходимо периодически выполнять схлопывание дублей по ключам аналитики. Это выполняется с помощью стандартного функционала ЕРП, да и вообще любой конфигурации на базе БСП,
Необходимо выявлять ключи аналитики, для которых нет записей в регистре сведений или измерения регистра сведений расходятся с полями самого ключа. Для этого можно использовать произвольный запрос, например представленный ниже:
ВЫБРАТЬ
КлючиАналитикиУчетаПоПартнерам.Ссылка КАК Аналитика,
КлючиАналитикиУчетаПоПартнерам.Партнер КАК Партнер,
АналитикаУчетаПоПартнерам.КлючАналитики ЕСТЬ NULL КАК ОтсутствиеВРегистре,
АналитикаУчетаПоПартнерам.Партнер <> КлючиАналитикиУчетаПоПартнерам.Партнер КАК РазличиеПартнера,
АналитикаУчетаПоПартнерам.Организация <> КлючиАналитикиУчетаПоПартнерам.Организация КАК РазличиеОрганизации,
АналитикаУчетаПоПартнерам.Контрагент <> КлючиАналитикиУчетаПоПартнерам.Контрагент КАК РазличиеКонтрагента,
АналитикаУчетаПоПартнерам.Договор <> КлючиАналитикиУчетаПоПартнерам.Договор КАК РазличиеДоговора,
АналитикаУчетаПоПартнерам.НаправлениеДеятельности <> КлючиАналитикиУчетаПоПартнерам.НаправлениеДеятельности КАК РазличиеНаправления
ИЗ
Справочник.КлючиАналитикиУчетаПоПартнерам КАК КлючиАналитикиУчетаПоПартнерам
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.АналитикаУчетаПоПартнерам КАК АналитикаУчетаПоПартнерам
ПО (АналитикаУчетаПоПартнерам.КлючАналитики = КлючиАналитикиУчетаПоПартнерам.Ссылка)
ГДЕ
(АналитикаУчетаПоПартнерам.КлючАналитики ЕСТЬ NULL
ИЛИ АналитикаУчетаПоПартнерам.Партнер <> КлючиАналитикиУчетаПоПартнерам.Партнер
ИЛИ АналитикаУчетаПоПартнерам.Организация <> КлючиАналитикиУчетаПоПартнерам.Организация
ИЛИ АналитикаУчетаПоПартнерам.Контрагент <> КлючиАналитикиУчетаПоПартнерам.Контрагент
ИЛИ АналитикаУчетаПоПартнерам.Договор <> КлючиАналитикиУчетаПоПартнерам.Договор
ИЛИ АналитикаУчетаПоПартнерам.НаправлениеДеятельности <> КлючиАналитикиУчетаПоПартнерам.НаправлениеДеятельности)
Запрос показывает проблемные записи. Если их возникает не много, можно их исправлять вручную, способом, который описан выше. Если ошибок большое количество, можно написать не сложную обработку для их исправления и выполнять ее автоматически с определенным расписанием.
Такие не сложные профилактические мероприятия позволяют решить большое количество учетных проблем в системе.
Что с остальными ключами аналитик учета?
Второй по количеству возникающих проблем набор ключей аналитик - Ключи аналитики учета номенклатуры.
В принципе, все описанное выше справедливо и для этой пары справочник – регистр сведений. Также рекомендуется схлопывать дубли, проверять наличие записей в регистре сведений и соответствие измерений регистра и реквизитов самого ключа.
С оставшимися двумя наборами ключей аналитик на практике проблем возникает меньше или вообще не возникает. В любом случае, если в вашей компании они будут, Вы уже знаете, что делать!
Спасибо за внимание. Пишите в комментариях, с каким проблемами с ключами аналитик учета столкнулись Вы и как вышли из положения.
Другие мои статьи из серии «Механизмы учета в типовых конфигурациях УТ 11, КА 2, ЕРП 2»
