Номерная серия длиннее 20 символов - баг в коде

[Максимка]

Возникла необходимость сделать длину номеров документов больше 20 символов. Изменил длину у EDT Num и NumberSequenceFormat - номер все равно обрезается до 20 символов. Начал искать в коде. В классе NumberSeq в методах numInsertFormatLetters() и numInsertFormatInternal() объявлены внутренние переменные с типом str 20.
Справедливо вплоть до Ax 2009.

[BOAL]

Ого, сначала не понял... думал режется на ЕДТ вставки...
А это жестоко зашито в код

[glibs]

А зачем, можно поинтересоваться?

В номерной серии максимальный возможный номер — примерно 2.5 миллиарда. это 10 символов. Можно еще 10 букв влепить. У вас в номере документа букв много или вы что-то с цифрами сделали? Если букв — можно префиксовать в вашем прикладном коде.

В общем, я бы на месте МС не засчитал это за багу. Технически — м.б. Архитектурно — вряд ли.

Ну и если речь таки идет о коде, а не просто о номере документа, то слишком длинные коды вредны для производительности.

[Максимка]

Цитата:

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

А зачем, можно поинтересоваться?

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

[S.Kuskov]

Цитата:

Сообщение от Максимка

У нас используется для нумерации закупок, префиксом является код поставщика

И что, данный префикс где-то потом откусывается? используется в отчётах? Ужас
Microsof, конечно, хорош, но вы ещё лучше

[glibs]

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

[lev]

Цитата:

Сообщение от Максимка

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

А можно узнать причины выбора такой нумерации?

[Максимка]

Цитата:

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

А можно узнать причины выбора такой нумерации?

Причина мне неизвестна, длина EDT Num была увеличена на этапе внедрения, но шаблон номеров оставался равным 20 символов. После увеличения длины шаблона, я обнаружил указанный баг.

[kashperuk]

На самом деле даже в стандартной функциональности довольно легко можно превысить 20-символьный предел. Если взглянуть на "Номерные группы" для серийников и партий. В этот номер можно включить несколько "сущностей", каждая из которых по 10 символов. И даже в руководстве каком-то написано, что если таки необходимо, чтобы все эти номера были включены, то нужно будет увеличить размер номерной серии. Что не является возможным из-за указанного бага, насколько я понял...

[glibs]

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

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

[kashperuk]

Oops. Ты, конечно, прав, аццкий сатана

[Kabardian]

Цитата:

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

В общем, я бы на месте МС не засчитал это за багу. Технически — м.б. Архитектурно — вряд ли.

Glibs, почему вам так сложно признать, что это баг? И какая разница, как именно ошиблись в Майкрософте, технически или архитектурно?

[Bober]

Цитата:

Сообщение от S.Kuskov

И что, данный префикс где-то потом откусывается? используется в отчётах? Ужас
Microsof, конечно, хорош, но вы ещё лучше

S.Kuskov, Вам то что за дело до потребностей этого заказчика? Потребовалось - значит , надо ! Уверен, что подобное решение принималось не за 5 минут в курилке, а обдумывалось со стороны разных подразделений заказчика. По крайней мере, не видел ни одного места, где бы это не происходило именно так.

Если в документации к Аксапте написано что макс.длина номерной серии 20 знаков - это не баг. Если не написано - значит баг.

[kashperuk]

Ну, это явно бага.
Но, glibs прав, что еще никто не будет фиксить.

[glibs]

Цитата:

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

...
почему вам так сложно признать, что это баг?
...

Мне не сложно . Это бага, конечно. Грубое нарушение разработчиком ВР.

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

[S.Kuskov]

Цитата:

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

Если в документации к Аксапте написано что макс.длина номерной серии 20 знаков - это не баг. Если не написано - значит баг.

Это баг в любом случае. Если предположить, что была цель - ограничить длину номерной серии, то делать это нужно было уж точно не таким способом.

Цитата:

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

S.Kuskov, Вам то что за дело до потребностей этого заказчика? Потребовалось - значит , надо.

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

[Bober]

Цитата:

Сообщение от S.Kuskov

А может действительно в таком подходе и нет ничего криминального, может знающие люди поделятся, ради каких преимуществ стоит пойти на такой шаг?

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

[glibs]

Чтобы не сажать производительность, можно было бы сделать...

Если это нужно только для печати — можно рассчитывать display-методом.

Если для поиска — на худой конец продублировать поле, но оно уже не будет в качестве ключевого использоваться в целом ряде таблиц. Хотя можно искать по двум полям, а объединенный номер считать display-методом (убив двух зайцев).

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