Правильные справочники

[mazzy]

Цитата:

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

ЕК ключ который генерируется вне системы => вне нашего контроля (типа наименование, или ИНН или что-то еще). Т.е. имеет бизнес-значение.

Э-э-э... А если внутри, то бизнес-значения не имеет?

Цитата:

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

Я предлагаю по-крайней мере, донести до них эту информацию.

А... да, почему бы не сделать это?

Цитата:

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

Мне кажется все равно - надо понимать что делаешь. Но лучше будет среда, которая будет облегчать распространенные вещи делать эффективно.

Что такое "распространненные вещи"?
И где они распространены?
Здесь я пытался понять почему же проклятые буржуи используют код, а не наименование.
http://axapta.mazzy.ru/lib/autonumber/

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

Цитата:

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

Я уже предложил см. Правильные справочники

Может быть, может быть...

Цитата:

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

Даже если на него ссылается миллион записей?

Да. Это разовая процедура. Требуется раз в полстолетия.
А ты предлагаешь делать join каждый раз?

Цитата:

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

Причем алгоритм составления таких названий - не просто конкатенация: в зависимости от значений одних группировочных признаков другие могли не попадать в название или кодироваться иначе.

Составной код - еще больший отстой нежели никому не понятное число.
Поскольку: нарушается нормализация первой формы.

Цитата:

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

На это все накладывалась еще одна особенность, связанная с тем, что для одной номенклатуры необходимо поддерживать три различных названия: бухгалтерское, управленческое для AX, схожее с тем, что пишут поставщики в своих документах, и управленческое для 1С, к которому привыкли все кладовщики и другого понимать они не хотят.

ВО!
Максим, будешь создавать 3 EDT или просить добавить в EDT массив наименований?

Цитата:

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

отказались от иерархического справочника номенклатуры в пользу плоской таблицы с фильтрами и сортировкой по любому группировочному признаку;

ВАХ! Целиком и полностью поддерживаю!
http://axapta.mazzy.ru/lib/tree/
http://axapta.mazzy.ru/lib/tree2/
http://axapta.mazzy.ru/lib/tree3/
а также: http://forum.mazzy.ru/index.php?showtopic=1275

Цитата:

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

в ряд форм, таких как PurchQuickQuote/SalesQuickQuote, для поиска и фильтрации были выведены эти группировочные признаки номенклатуры, в другие формы просто через display-методы выведены соответствующие управленческие названия.

Целиком и полностью поддерживаю
Особенно согласен с формулировкой "ряд форм".
Немножко смущает, что нет формулировки "ряд отчетов".

[gl00mie]

Цитата:

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

Составной код - еще больший отстой нежели никому не понятное число. Поскольку: нарушается нормализация первой формы.

В моем случае речь шла не о коде, а именно о названии - более-менее внятном и порой весьма длинном. Использовать его в качестве кода никто и не собирался...

Цитата:

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

http://axapta.mazzy.ru/lib/tree/
http://axapta.mazzy.ru/lib/tree2/
http://axapta.mazzy.ru/lib/tree3/
а также: http://forum.mazzy.ru/index.php?showtopic=1275

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

Цитата:

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

Немножко смущает, что нет формулировки "ряд отчетов".

Ну это как бы подразумевалось просто здесь разговор в основном именно о формах, как я понимаю.

[belugin]

Цитата:

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

Погляди на интернет магазины, посмотри на другие системы (кстати, а как это делается в BAAN?)

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

[belugin]

Цитата:

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

Э-э-э... А если внутри, то бизнес-значения не имеет?

Ну ИК может иметь, а СК - нет.

Цитата:

Что такое "распространненные вещи"?
И где они распространены?
Здесь я пытался понять почему же проклятые буржуи используют код, а не наименование.

Лично в моей практике часто приходится делать наименования. Мне например, трудно представить, чтобы кого-то удовлетворил EmplID

Цитата:

А ты предлагаешь делать join каждый раз?

Про джоин я уже ответил, что он необязательный.

Цитата:

Максим, будешь создавать 3 EDT или просить добавить в EDT массив наименований?

Ну... всегоя можно найти особый случай

[oip]

Цитата:

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

Мне например, трудно представить, чтобы кого-то удовлетворил EmplID

У нас всех удовлетворяет, ибо ЕмплАйди у нас вида "АбрамоваСМ".

Вот с номенклатурами - да, беда.

[belugin]

Цитата:

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

У нас всех удовлетворяет, ибо ЕмплАйди у нас вида "АбрамоваСМ".

А если она замуж выйдет?

[mazzy]

Цитата:

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

Лично в моей практике часто приходится делать наименования. Мне например, трудно представить, чтобы кого-то удовлетворил EmplID

Кого-то не устраивает табельный номер?

Про Абрамову уже говорили.
Если она замуж выйдет, то стандартная процедура RenamePrimaryKey для изменения КОДА

[belugin]

Цитата:

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

Кого-то не устраивает табельный номер?

Ну, обычно люди еще хотят ФИО рядом видеть...

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

display EmplName emplName()
{
     return (select firstOnly EmplName from EmplTable 
             where EmplTable.EmplID == this.EmplID).EmplName;
}

никто не пишет?

[mazzy]

Цитата:

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

Вообще, получается, что я один такой несчастный

Почему ты так решил?
Это постоянная тема.
См. например ссылку на обсуждение Абстрактного классификатора и поищи обсуждения по ключевому слову лукап/lookup


Анекдот:
Жена (Ж) звонит на мобильный мужу (М).
(Ж) - дорогой, будь осторожен, по радио сообщили, что какой-то идиот едет по встречной полосе
(М) - да их тут сотни!

[Zepp]

Цитата:

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

Про Абрамову уже говорили.
Если она замуж выйдет, то стандартная процедура RenamePrimaryKey для изменения КОДА

К сожалению изменить EmplId через "Паспорт записи" недостаточно (AX 3.0 SP4 EE). При создании строки в EmplTable создается строка в таблице RHRMVirtualNetworkTable, при этом ключевому полю hrmVirtualNetworkId присваивается значение поля EmplId. При изменении кода в EmplId, код в hrmVirtualNetworkId останется прежним - в результате нельзя будет создать нового сотрудника в EmplTable с прежним кодом.