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

[gl00mie]

Цитата:

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

Вопрос про ЕК такой: что вы делаете когда он меняется? Например был клиент "Светик" а стал "Мотылек"? Или изменилось структура групп номенклатуры вместо
ПЛ0001 (Группа "плюшевые игрушки", изделие 0001 "Медвежонок "Миша"")
МЛ0001 (Группа "плюшевые игрушки для младшего возраста", , изделие 0001 "Медвежонок "Миша"")
переименовываете первичный ключ, даже если он участвует в InventTrans и иногда его надо сопоставлять с распечатанными год назад документами?

Была схожая задача, связанная с миграцией данных по номенклатуре из 1С и необходимостью поддерживать связь с 1С по кодам номенклатуры для выгрузки данных в бухгалтерию. В 1С у номенклатуры был код из одних цифр (от 00001 до 20000, к примеру) и название, в котором было по историческим причинам «зашифровано» 4-5 нечетко формализованных группировочных признаков номенклатуры. Причем алгоритм составления таких названий - не просто конкатенация: в зависимости от значений одних группировочных признаков другие могли не попадать в название или кодироваться иначе. На это все накладывалась еще одна особенность, связанная с тем, что для одной номенклатуры необходимо поддерживать три различных названия: бухгалтерское, управленческое для AX, схожее с тем, что пишут поставщики в своих документах, и управленческое для 1С, к которому привыкли все кладовщики и другого понимать они не хотят. Причем алгоритм формирования управленческих названий разный для каждого из нескольких направлений деятельности и связанной с ними номенклатуры (хотя группировочные признаки одни и те же). Так вот, решение было выбрано такое:

• для номенклатур используются те же цифровые ничего не значащие коды, что и в 1С, и эти коды никодга не меняются для номенклатуры. В любом случае, коды ПЛ0001 или МЛ0001 imho ничуть не лучше просто 00001, который не обязан меняться вместе со структурой групп;
• отказались от иерархического справочника номенклатуры в пользу плоской таблицы с фильтрами и сортировкой по любому группировочному признаку;
• реализованы методы на InventTable, которые умееют генерить все нужные названия по разным алгоритмам в зависимости от значений группировочных признаков номенклатуры (на каждый группировочный признак есть отдельная таблица с несколькими полями, участвующими в формировании различных названий);
• сгенеренные названия сохраняются в InventTxt, причем бухгалтерское - с кодом текущего используемого языка (русского), а управленческие - с дополнительно заведенными в LanguageTable кодами userDefined-"языков" по одному на каждый вид управленческих названий;
• в ряд форм, таких как PurchQuickQuote/SalesQuickQuote, для поиска и фильтрации были выведены эти группировочные признаки номенклатуры, в другие формы просто через display-методы выведены соответствующие управленческие названия.

Цитата:

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

По факту многие (и я сам в том числе) пишут вот такие дисплей методы:

display InventName inventName()
{
      return InventTable::find(this.ItemID).Name;
}

Был создан вспомогательный класс, который, во-первых, отвечает за обновление названий (дергается из InventTable при изменении кодов группировочных признаков и из таблиц самих признаков при изменении записей в них), а во-вторых, вызываясь из display-методов на нужных таблицах (SalesLine/PurchLine, к примеру), по itemId и languageId возвращает нужное управленческое название из InventTxt, что работает довольно быстро с учетом настроек кэширования для этой таблицы.
Да, еще приходилось в заголовках форм выводить управленческие названия вместо TitleField2...

[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 с прежним кодом.