Как правильно отредактировать Dimensions

[yuh]

[AX 4.0; SQL2000]
Подскажите, что можно сделать в такой ситуации:
При настройке системы были неверно заполнены справочники Dimensions (Cost Center и Department перепутаны местами). После этого некоторые из Dimensions были задействованы в карточках клиентов и поставщиков а также проведены в документах покупки/продажи.
Когда проблема обнаружилась, было принято решение справочники поправить. Для этого нужно всего лишь добавить новые значения, а старые удалить. Но как оказалось, кнопка "Удалить" не доступна в форме "Dimensions"!
Отсюда вопрос: как можно удалить значение из этой формы? Или хотя бы спрятать от пользователей те значения, которые в будущем больше не понадобятся?

[EVGL]

Удалить - никак. Спрятать - там есть галка типа "Заблокировать".

[mnt_dx]

А что вы хотите сделать с Аналитиками в проведенных документах?
Самая простая блокировка для пользователя - в Главная книга > Аналитика поставить маркер Закрыто. С этой аналитикой пользователь не проведет документы, но сможет отчеты строить.
Также можно в Главная книга > Настройка > Аналитика настроить допустимые наборы значений аналитики.

[yuh]

Цитата:

Сообщение от mnt_dx

А что вы хотите сделать с Аналитиками в проведенных документах?

Конечно, идеально было бы Аналитики поправить в соответствии с новыми настройками. Но я догадываюсь, что это скорее всего невозможно (и вообще, менять что-то в законченных проводках - табу!)...
Поэтому второй вариант - оставить существующие записи как есть, но зато гарантировать правильность всех будущих проводок.
Запрет на проводку документов с определенной Аналитикой (галочка "Closed") - возможное решение. Правда мне кажется что в этом случае мы слишком поздно бъем пользователя по шаловливым ручкам. Было бы элегантнее не допустить выбора этой Аналитики с самого начала.
Можно такого добиться только настройками, не прибегая к программированию?

[VikiN]

Цитата:

Сообщение от yuh

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

Можно настроить Безопастность на уровне записи для закрытых аналитик.

[SRF]

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

Возможно потребуется пересчитать сальдо по ГК - Главная книга\Периодические операции\Пересчитать сальдо по ГК, чтобы работали ОСВ по ГК

[EVGL]

См. выше - настроить наборы аналитики.

[yuh]

Спасибо! Ушел читать первоисточники...

[Sada]

Не нравится лично мне переименовывание паспортом записи... Где нить может не отработать...

[Dark Light]

Цитата:

Сообщение от Sada

Не нравится лично мне переименовывание паспортом записи... Где нить может не отработать...

Если структура данных корректная и перекрестные ссылки обновлены, то никаких проблем быть не должно. Можно перед переименованием для надежности запустить Сервис/Средства разработки/Перекрестные ссылки/Периодические операции/Обновить с галками Обновить модель данных и Обновить иерархию типов.

[gl00mie]

Цитата:

Сообщение от VikiN

Можно настроить Безопастность на уровне записи для закрытых аналитик.

Для фин.аналитик в общем случае - нельзя, тем более в 2009-й.

Цитата:

Сообщение от Sada

Не нравится лично мне переименовывание паспортом записи... Где нить может не отработать...

Может - если иерархия типов кривая либо если для храниения фин.аналитики использовать поле с "левым" типом, в остальном проблемы - только с производительностью переименования.

Цитата:

Сообщение от Dark Light

Если структура данных корректная и перекрестные ссылки обновлены

Из моего скромного опыта, для переименования ПК не нужны перекрестные ссылки.

[VikiN]

[QUOTE=gl00mie;273187]Для фин.аналитик в общем случае - нельзя, тем более в 2009-й.
Вопрос был можно ли сделать недоступным выбор закрытых аналитик без программирования.
Для этого для всех групп прав, в которых есть доступ на таблицу Dimension настраивается контроль доступа на уровне записи. Где для поля номер Аналитики прописывается следующий критерий (DimensionCode==0)&&(Closed==0). В данном случае это для аналитики Подразделение.

[gl00mie]

Цитата:

Сообщение от VikiN

Цитата:

Сообщение от gl00mie

Для фин.аналитик в общем случае - нельзя, тем более в 2009-й.

Вопрос был можно ли сделать недоступным выбор закрытых аналитик без программирования. Для этого для всех групп прав, в которых есть доступ на таблицу Dimension настраивается контроль доступа на уровне записи. Где для поля номер Аналитики прописывается следующий критерий (DimensionCode==0)&&(Closed==0). В данном случае это для аналитики Подразделение.

Вы как-то по-своему понимаете постановку задачи "сделать недоступным выбор закрытых аналитик" Для начала небольшое уточнение: RLS не работает для связанных таблиц - без программирования, опять же. А теперь рассмотрим такой пример: я - пользователь, занимающийся созданием заказов на продажу, или складских журналов, или журналов ГК, у меня RLS'ом убрали закрытые аналитики из lookup'ов и из формы фин.аналитик, но что при этом помешает мне руками указать в шапке/строке заказа на продажу или журнала код закрытой аналитики? Абсолютно ничего. А что помешает скопировать шапку или строки давно созданного заказа или журнала, который я использую как шаблон и в котором прописаны закрытые аналитики, и создать новый заказ/журнал с закрытыми аналитиками, после чего оприходовать/разнести его? Опять ничего. А ещё есть разного рода импорты, интеграции и прочая...
В моём понимании "сделать недоступным выбор закрытых аналитик" значит в первую очередь сделать недоступным создание новых проводок с этими аналитиками, что реализуется проверками на разносках, т.е. на уровне бизнес-логики. А уже во вторую или третью очередь это - сокрытие аналитик в пользовательском интерфейсе и предупреждения при указании их в справочниках и журналах как мера на уровне презентационной логики по предотвращению пользовательских ошибок и обращений в поддержку с запросами "а у меня не разносится..."

PS. С наступающим всех... :-)

[RVS]

Цитата:

Сообщение от Sada

Не нравится лично мне переименовывание паспортом записи... Где нить может не отработать...

Паспорт записи - это ТОЛЬКО для ОЧЕНЬ ГРАМОТНЫХ людей.

И при этом - ОЧЕНЬ осторожно.

PS: CAPS западает. Мои извинения...

ЗЗЫ: Проблема понятна и решаема. Только - опять же - АККУРАТНО

[driller]

Цитата:

Сообщение от gl00mie

Может - если иерархия типов кривая либо если для храниения фин.аналитики использовать поле с "левым" типом, в остальном проблемы - только с производительностью переименования.

Цитата:

Сообщение от Dark Light

Не совсем понял. Если сделана иерархия, то сделана она, видимо, путем ссылки дочернего элемента на родительский по RecId или Типу-Коду аналитики. В этом случае при переименовании кода родительского элемента дочерний элемент не потеряет на него ссылки.

Тоже не совсем понял, так что прилагаю картинки.

Есть иерархия в DAX 4.0 одного из Питерских вендоров.


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


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


gl00mie, Dark Light как делали так что стандартными средствами иерархия обновлялась?

[Dark Light]

Цитата:

Сообщение от driller

gl00mie, Dark Light как делали так что стандартными средствами иерархия обновлялась?

Тут иерархия сделана некоряво. Подразделение 05_07 имеет ссылку на подразделение 05_. Таким образом, если мы переименуем подразделение 05_ в 99_, то во все подразделения, которые были дочерними у 05_ (ParentId == 05_) станут дочерними у 99_.

С точки зрения пользователя это будет не совсем правильно: "как это подразделение 05_07 может быть дочерним от 99_?" Но с точки зрения системы всё верно - связи не нарушены.

Если же хочется, чтобы все дочерние подразделения также сменили ИДшники на 99_*, то да - придется программировать (пробежаться по всем потомкам и сделать renamePrimaryKey).

[driller]

К примеру не отработает если на dimensions, сделана иерархия, по кнопке переименование родительского элемента, дочерние конечно не переименуются, программировать такие места нужно отдельно.

[Dark Light]

Цитата:

Сообщение от driller

К примеру не отработает если на dimensions, сделана иерархия, по кнопке переименование родительского элемента, дочерние конечно не переименуются, программировать такие места нужно отдельно.

Не совсем понял. Если сделана иерархия, то сделана она, видимо, путем ссылки дочернего элемента на родительский по RecId или Типу-Коду аналитики. В этом случае при переименовании кода родительского элемента дочерний элемент не потеряет на него ссылки.

Если же иерархия делается по типу: один элемент имеет код 00, а второй - 00.01, а третий 00.01.01, значит иерархия такая 00 <- 00.01 <- 00.01.01. Тогда это просто коряво.

Цитата:

Сообщение от gl00mie

Из моего скромного опыта, для переименования ПК не нужны перекрестные ссылки.

Проверил - действительно не нужны. Интересно, откуда тогда берется информация о связях?

[sukhanchik]

Цитата:

Сообщение от Dark Light

Интересно, откуда тогда берется информация о связях?

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

[Dark Light]

Цитата:

Сообщение от sukhanchik

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

Это понятно. Просто мне казалось, что каждый раз собирать все эти данные с нуля очень долго. Думал, есть промежуточная таблица. Ну раз так, видимо, как раз этим и объясняется скорость выполнения данной операции.