Ключи аналитик учета в ЕРП, КА, УТ

08.11.23

Разработка - Механизмы типовых конфигураций

Разбираемся, зачем в системе ЕРП созданы справочники: ключи аналитик учета, зачем созданы аналогичные по набору измерений регистры сведений. Какие проблемы они решают, какие создают новые и что с этим делать.

В системах учета ЕРП, КА, УТ есть агрегированные наборы аналитик в разных разделах учета. Так называемые ключи аналитик учета.

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

В конфигурациях типа ЕРП реализовано четыре таких набора аналитик:

  • Ключи аналитик учета по партнерам,
  • Ключи аналитик учета номенклатуры,
  • Ключи аналитик учета партий,
  • Ключи аналитик учета наборов.

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

 

Аналитика учета по партнерам

 

Элементы данного справочника указываются в качестве измерения для всех регистров, по которым ведутся расчеты с контрагентами. Основные такие регистры для режима ведения взаиморасчетов online, который является единственно возможным для начала ведения учета в текущих версиях ЕРП, КА:

  • Расчеты с клиентами
  • Расчеты с клиентами по срокам
  • Плановый оплаты клиентов
  • Расчеты с поставщиками
  • Расчеты с поставщиками по срокам
  • Плановые оплаты поставщикам

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

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

 

Сложности, связанные с использованием ключей аналитик

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

Во-вторых. Необходимо следить за образованием дублей в данном справочнике (элементов с одинаковыми наборами всех аналитик). Если такие дубли будут появляться взаиморасчеты не будет закрываться по регистрам учета. И это несмотря на то, что дублей по основным аналитикам: организация, партнер, контрагент, договор, направление – в системе не будет.

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

Для рассматриваемого нами справочника ключей регистр называется: Аналитика учета по партнерам. Данный регистр призван решить описанные мной выше проблемы.

 

Решает ли дополнительный регистр сведений вышеописанные проблемы?

Да, решает. Но с некоторыми оговорками.

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

Напоминаю. Непериодический независимый регистр сведений содержит по умолчанию кластерный индекс со всеми измерениями данного регистра. Измерения в индексе заданы в порядке из следования в конфигураторе. Это одно из его существенных отличий регистра сведений от справочника, который имеет кластерный индекс только по ссылке. А если индексировать отдельные поля справочника, это все равно не создаст индекса содержащего все поля справочника. Будут созданы отдельные индексы для каждого индексируемого поля.

Для регистра, который мы рассматриваем, набор измерений будет следующий: Партнер, организация, Контрагент, Договор, Направление деятельности.

Соответственно, если строить запрос и при отборе указать следующие поля:

  • Партнер,
  • Партнер и организация,
  • Партнер, организация и контрагент  

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

А если при отборе будет указано:

  • Организация,
  • Контрагент,
  • Договор

Поиск будет выполнен по не кластерному индексу, так как для данного регистра создаются отдельные не кластерные индексы для каждого измерения. Затем дополнительно будет выполнен поиск по ключу в кластерном индексе (Key Lookup). Это тоже приемлемо, но медленнее первого варианта.

А вот если при отборе будет указано:

  • Организация и контрагент,
  • Контрагент и договор,
  • Организация, контрагент и договор

При таком варианте запроса, поиска только по индексу не получиться. Оптимизатор SQL, конечно, выберет какой-либо, на его усмотрение, самый оптимальный индекс. Но, в любом случае, будет присутствовать перебор некоторого количество записей. Значительного преимущества в поиске при наличии регистра сведений в данном случае не будет.

Стоит также заметить, что существенную разницу можно заметить только на достаточно большом объеме данных. Да и вообще выше описано, так сказать, стандартное поведение оптимизатора SQL. По факту он вполне может выбрать и другой вариант в какой-то конкретной ситуации. Или же вообще наплевать на индексы и выполнить перебор записей. При относительно не большом количестве записей чаще всего он поступает именно так.

Еще нужно учитывать накладные расходы, связанные с использованием дополнительного регистра сведений с ПЯТЬЮ дополнительными не кластерными индексами (по каждому измерению). Количество индексов влияет на скорость записи в этот регистр, также на размер самой базы данных. Хотя, в сравнении с общим объемом ЕРП или КА это конечно крохи )).

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

Однако на практике, часто это вызывает еще больше проблем.

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

Например:

Если записи в регистре сведений не будет, система не будет вести себя корректно. Отчеты будут выдавать не верную информацию. Более того, при проведении документа с этим же набором измерений, будет создан дополнительный ключ (дубль существующего) и запись в регистре со ссылкой на новый ключ. Это достаточно частая проблема, и если Вы проверите свою систему, то я уверен практически на 100%, найдете какое-то количество таких ключей. Решается данная проблема очень просто – перезаписью самого ключа.

Еще одна проблема заключается в том, что если значения измерений записи регистра сведений отличаются от полей самого ключа, то система также будет работать некорректно. Это более редкая ситуация и исправить ее не так просто. Интерактивно можно внести изменения только в запись регистра. Исправить реквизиты самого ключа стандартными средствами нельзя. Однако исправлять необходимо именно сам ключ, так как в проверках при создании нового ключа, в отчетах и прочих механизмах анализируются именно данные из регистра сведений. В данному случае можно прибегнуть к любому средству для непосредственного редактирования объектов системы, например Infostart Toolkit – инструмент, в котором сделано то, что давно просят от 1С.

Если Вы работаете с ЕРП или КА, без каких-либо средств прямого редактирования объектов и регистров системы Вам не обойтись )).

Исправление описанных выше несоответствий дополнительно дает гарантию, что на один ключ аналитики учета ссылается только одна запись регистра сведений.

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

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

 

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

Необходимо периодически выполнять схлопывание дублей по ключам аналитики. Это выполняется с помощью стандартного функционала ЕРП, да и вообще любой конфигурации на базе БСП,

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

ВЫБРАТЬ
    КлючиАналитикиУчетаПоПартнерам.Ссылка КАК Аналитика,
    КлючиАналитикиУчетаПоПартнерам.Партнер КАК Партнер,
    АналитикаУчетаПоПартнерам.КлючАналитики ЕСТЬ NULL КАК ОтсутствиеВРегистре,
    АналитикаУчетаПоПартнерам.Партнер <> КлючиАналитикиУчетаПоПартнерам.Партнер КАК РазличиеПартнера,
    АналитикаУчетаПоПартнерам.Организация <> КлючиАналитикиУчетаПоПартнерам.Организация КАК РазличиеОрганизации,
    АналитикаУчетаПоПартнерам.Контрагент <> КлючиАналитикиУчетаПоПартнерам.Контрагент КАК РазличиеКонтрагента,
    АналитикаУчетаПоПартнерам.Договор <> КлючиАналитикиУчетаПоПартнерам.Договор КАК РазличиеДоговора,
    АналитикаУчетаПоПартнерам.НаправлениеДеятельности <> КлючиАналитикиУчетаПоПартнерам.НаправлениеДеятельности КАК РазличиеНаправления
ИЗ
    Справочник.КлючиАналитикиУчетаПоПартнерам КАК КлючиАналитикиУчетаПоПартнерам
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.АналитикаУчетаПоПартнерам КАК АналитикаУчетаПоПартнерам
        ПО (АналитикаУчетаПоПартнерам.КлючАналитики = КлючиАналитикиУчетаПоПартнерам.Ссылка)
ГДЕ
    (АналитикаУчетаПоПартнерам.КлючАналитики ЕСТЬ NULL
     ИЛИ АналитикаУчетаПоПартнерам.Партнер <> КлючиАналитикиУчетаПоПартнерам.Партнер
     ИЛИ АналитикаУчетаПоПартнерам.Организация <> КлючиАналитикиУчетаПоПартнерам.Организация
     ИЛИ АналитикаУчетаПоПартнерам.Контрагент <> КлючиАналитикиУчетаПоПартнерам.Контрагент
     ИЛИ АналитикаУчетаПоПартнерам.Договор <> КлючиАналитикиУчетаПоПартнерам.Договор
     ИЛИ АналитикаУчетаПоПартнерам.НаправлениеДеятельности <> КлючиАналитикиУчетаПоПартнерам.НаправлениеДеятельности)

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

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

 

Что с остальными ключами аналитик учета?

Второй по количеству возникающих проблем набор ключей аналитик - Ключи аналитики учета номенклатуры.

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

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

Спасибо за внимание. Пишите в комментариях, с каким проблемами с ключами аналитик учета столкнулись Вы и как вышли из положения.

 

Другие мои статьи из серии «Механизмы учета в типовых конфигурациях УТ 11, КА 2, ЕРП 2»

  1. Учет товаров по сериям
  2. Контроль отрицательных остатков
  3. Партионный учет товаров в конфигурациях УТ, КА, ЕРП
  4. Механизмы расчета резервов
  5. Учет по направлениям деятельности

Ключи аналитик учета аналитика учета по партнерам номенклатуре

См. также

СКД Механизмы типовых конфигураций Запросы Программист Платформа 1С v8.3 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

Работая с типовыми отчетами в конфигурациях «Зарплата и управление персоналом, редакция 3», «Зарплата и кадры государственного учреждения, редакция 3» и подобных, в схемах компоновки данных можно встретить конструкции запросов, которые обращаются к некоторым виртуальным таблицам.

20.08.2024    1947    PROSTO-1C    0    

18

Механизмы типовых конфигураций Программист Платформа 1С v8.3 1С:Комплексная автоматизация 2.х Россия Бесплатно (free)

Эта ошибка была обнаружена мной в типовой конфигурации 1С:Комплексная автоматизация 2 (2.5.16.115), БСП версия 3.1.9.302. Возникает она после того, как вы добавляете в расширение бизнес-процесс или задачу, выполняете обновление идентификаторов метаданных расширений, но ошибка при записи любого элемента справочника "Профили групп доступа" всё равно остаётся.

01.07.2024    1983    Vidz    0    

11

Механизмы типовых конфигураций Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

24.06.2024    1198    olja-ljaaa    0    

3

Механизмы типовых конфигураций Ценообразование, анализ цен Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Россия Абонемент ($m)

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

1 стартмани

11.04.2024    1156    tango    5    

3

Механизмы типовых конфигураций Программист Платформа 1С v8.3 1С:Управление торговлей 11 Россия Абонемент ($m)

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

10 стартмани

11.04.2024    926    tango    5    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ilkaev_log2021 08.11.23 21:08 Сейчас в теме
К указанному шаблону отнес бы Справочник.ОбъектыРасчетов в версиях от 2.5.
ids79; &rew; +2 Ответить
2. kalyaka 1112 08.11.23 21:37 Сейчас в теме
Вроде по логике количество измерений в регистре ключа аналитики должно совпадать с количеством полей в самом справочнике ключа, однако это не так. Например, в ERP ключ аналитики учета номенклатуры помимо измерений регистра содержит еще список вполне себе измерений: Партнер, Контрагент, Договор, Организация и т.д. Но ведь несовпадение количества измерений приведет к неоднозначности.
В чем здесь секрет?
6. ids79 8558 09.11.23 11:27 Сейчас в теме
(2)Ну, тут все просто. Первое, для обеспечения уникальности ключа достаточно только тех измерений, которые есть в регистре. И, второе, необходим быстрый поиск ключей только для полей, которые опять же есть регистре.
8. kalyaka 1112 09.11.23 11:37 Сейчас в теме
(6) Тут противоречие. Если нужно создать ключ аналитики с другой организацией Организация 2, но уже есть такой же ключ аналитики для Организация 1, то получается уже два ключа аналитики с одинаковым набором базовых измерений из регистра?
9. kalyaka 1112 09.11.23 11:39 Сейчас в теме
(6) Такое наверное возможно, если дополнительные реквизиты зависимые от измерений в регистре. На это расчет?
10. ids79 8558 09.11.23 12:35 Сейчас в теме
(9)Да, такого не может быть. В этом случае Место хранение (составной тип) тоже будет разное.
3. &rew 52 09.11.23 07:37 Сейчас в теме
Теперь даже процесс анализа, почему аванс не закрылся по 60 или 62 счету выливается в целую детективную историю.
1. Ключи аналитики (а могут быть дубли не в чистом виде, а например с незаполненным и заполненным партнером)
2. Объекты расчетов
3. Дубли в чистом виде (как ни странно - самый простой вариант)
4. Записи регистра сведений Аналитика учета ...

Касаемо Номенклатуры (себестоимости) меняем Объекты расчетов на Виды запасов (опосредованно - вид деятельности НДС)
Плюс номер ГТД (Прослеживаемость)

Это я еще про партии не начал, а том ой как всё сложнее. (ERP)
rise; ids79; EvgeniyOlxovskiy; +3 Ответить
4. KVIKS 427 09.11.23 11:07 Сейчас в теме
А еще если пометить на удаление элемент справочника ключа, то в итоге создастся дубль, не помеченный на удаление. и все цифры в отчетах начинают задваиваться. В моей практике клиент через настройки отчета добрался до ключей аналитики, выбрал в список фильтра список, а потом, вместо того чтобы очистить список, нырнул в справочник и с шифтом пометил их на удаление (думал так фильтр снимет). В итоге после этих действий сначала в отчете были нули (ключи то помечены на удаление), потом перепровел документы (создались куча дублей) и все цифры задвоились.
rise; TerveRus; ids79; +3 Ответить
11. ids79 8558 09.11.23 12:39 Сейчас в теме
(4)Да, спасибо за комментарий. Забыл написать про эту особенность. Если ключ аналитики помечен на удаление, он игнорируется системой. Это и плохо и хорошо одновременно. Плохо - необходимо следить, чтобы не помечались на удаление рабочие ключи (о чем Вы и пишите). Хорошо - можно пометить на удаление ключ и он гарантировано не будет использоваться в новых документах. Если, допустим, его нельзя удалить из базы полностью.
5. RocKeR_13 1369 09.11.23 11:13 Сейчас в теме
Ждем, когда кто-то доберется до чудесного регистра сведений "Распределение запасов" и связанного с ним регистра накопления "Запасы и потребности" (ранее - "Распределение запасов (движения)").
user1659197; AlexandrN; +2 Ответить
7. ids79 8558 09.11.23 11:30 Сейчас в теме
(5)Да, интересная тема. Все думаю написать про нее.
Oxygraphis; shu_vol; AlexandrN; Evgenij1990; RocKeR_13; +5 Ответить
12. user1636469 09.11.23 15:40 Сейчас в теме
13. qwinter 683 09.11.23 15:41 Сейчас в теме
(5) А что там описывать? Вроде все прозрачно. Регистр сведений (создан просто для ускорения запросов) и несет в себе конечный итог регистра накопления в нескольких вариациях.
14. RocKeR_13 1369 09.11.23 16:40 Сейчас в теме
(13) если бы все было так просто, то не существовало бы отдельной обработки "Исправление ошибок в регистре сведений "Распределение запасов")) Больше интересны в принципе правила заполнения как регистра накопления "Запасы и потребности", так и самого РС. Сможете описать - думаю, соберете много благодарностей. У самого руки никак не дойдут до построения целостной картины.По мне, так проблем со свободными остатками было меньше во времена одноименного РН.
shu_vol; AlexandrN; +2 Ответить
19. qwinter 683 10.11.23 11:27 Сейчас в теме
(14) Кривые руки где угодно могут напортачить. Все проблемы там из за редактирования документов задним числом. Принцип заполнения РН элементарный: пишем приходы с плюсом, расходы с минусом, данные по заказам клиентам и поставщикам соответственно в заказано и поступит с плюсом, при поступлении и реализации с минусом, данные по резервам тоже в соответствующие поля, регламентное задание распределяет приходы на обеспечиваемые товары по фифо и ставит в резерв. В РС пишутся итоговые обороты РН, прям буквально (можете заглянуть в общий модуль "РаспределениеЗапасов" в процедуру "ОбновлениеИБПоТовару" и поразиться сложности запросов :) ), по каждом варианту состояния распределения запасов пономенклатурно делается запрос по всему РН и записывается в РС.
15. milanse 38 09.11.23 20:26 Сейчас в теме
Все же не понял зачем нужен регистр ? Для быстрого поиска аналитики при проведении документов ? В отчётах он не используется и все тянется через точку из аналитик ?

Прост использую у себя аналогичную схему. Здорово помогает оптимизировать размер базы.

Ну и не понятно откуда все же появляются дубли и расхождения справочника с регистром ? Неаккуратно используются транзакции или что ?
16. CheBurator 2684 09.11.23 22:04 Сейчас в теме
"режим ведения взаиморасчетов online"
как старый клюшечник - поржал ;-) прошло 20 лет практически, вернулись к варианту который до этого 20 лет работал в 7.7 ;-)
18. ids79 8558 10.11.23 10:23 Сейчас в теме
(16)На самом деле в режиме online часть расчетов уже опять перевели в offline. Так что это замкнутый круг )).
17. Cmapnep 19 10.11.23 09:47 Сейчас в теме
Вот этой обработкой решаем все проблемы с ключами
https://infostart.ru/marketplace/569128/
Платная, но рабочая!
sttt; ids79; +2 Ответить
24. user892471 12 29.02.24 10:54 Сейчас в теме
(17) Добрый день, а с ключами аналитики учета номенклатуры, которые ссылаются на расчет себестоимости побороли ошибку? (Если пересчитать себестоимость ошибка уйдет, а как быть если период закрыт)
25. Cmapnep 19 29.02.24 11:36 Сейчас в теме
(24) Добрый день. С такими ошибками не сталкивался - не могу ничего подсказать
20. naf2000 12.11.23 10:09 Сейчас в теме
Получатся регистр сведений требуется чтобы обойти ограничение платформы - создать уникальный составной индекс на справочнике не получится. Вот и приходится фактически дублировать данные.
21. ids79 8558 12.11.23 11:46 Сейчас в теме
(20)В общема-то да, получается так. Если конечно нет еще каких-то причин, которых мы не видим.
22. sea123 15 12.12.23 12:02 Сейчас в теме
насколько я помню, РАУЗ и прочие прелестные регистры были и в УПП 1.3, так что кактусу этому скоро будет лет 15. В свое время это преподносилось как РАДИКАЛЬНОЕ средство для ускорения расчетов по сравнению с партионным.
23. mitia.mackarevich 75 17.01.24 17:31 Сейчас в теме
Практически в каждом таком справочнике. Еще - Заменить дубли ключей аналитики. Вот и профилактика.
Оставьте свое сообщение