InventUpdate classes - общий вопрос по дизайну

[Ievgenii]

Вопрос о дизайне InventUpd* классов (правда не совсем конкретный). Возможно вы сталкивались с ситуацией когда существуюший дизайн вам не позволял сделать определенные кастомизации и вам приходилось как то с этим бороться (can't customize by design, have to workaround). Интересно было бы узнать.

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

Заранее огромное!!! спасибо за любые ответы

[Wamr]

"может какие-то куски логики вам кажутся ненужной, неправильной и так далее"

Лично меня, всегда раздражал перекрестный стек вызовов InventUpd - InventMov, когда из проверки InventUpd вызывается проверка InventMov, которая вызывает проверку InventUpd, которая вызывает проверку InventMov. (относится к Ax3, в Ax5 не смотрел)

[Yprit]

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

[Ievgenii]

Цитата:

перекрестный стек вызовов InventUpd - InventMov

Спасибо - интересное наблюдение.

Цитата:

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

Спасибо - проблема ясна.

[fed]

Ну я бы сказал, что в стандартной поставке не хватает хорошего tutorial по созданию собственных складских документов, которой также стоило бы расписать в тренинге Development IV.
По архитектуре - особых замечаний нет, всегда хватало стандартной (ну может новые методы в inventMovement добавлял, когда новые поля в inventTrans заводил).

[lev]

о, нконец то появилась тема в которой могу высказать своё "фе" на тему документации архитектуры классов InventUpd и InventMovement.
Я не могу понять, почему такие фундаментальные классы ни в какой документации не описаны?! (что они делают, зачем нужен тот или иной метод и т.д и т.п)
Приходится урывками искать информацию в интернете, у знакомых и прочих областях (например у своего горького опыта )
В итоге получается: хочешь сделать доработку по всем правилам (Best Practices), и следуя всем канонам стандартной архитектуры... Ищешь доки, как сделать? доков нет... Начинаешь копать примеры, вроде разбираешься что как работает, делаешь доработку... И потом при тестировании начинают всплывать всякие мелочи\подводные камни, которых попросту и не заметиш при первом приближении... Естественно чем больше опыта у программиста, тем глубже его знания... А как тогда, простите, корректно кодировать новичкам???
Фуух, вроде все сказал

[EVGL]

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

[Logger]

Цитата:

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

"может какие-то куски логики вам кажутся ненужной, неправильной и так далее"

Лично меня, всегда раздражал перекрестный стек вызовов InventUpd - InventMov, когда из проверки InventUpd вызывается проверка InventMov, которая вызывает проверку InventUpd, которая вызывает проверку InventMov. (относится к Ax3, в Ax5 не смотрел)

Особенно весело это смотрится когда InventMovement живет на клиенте. Ворох клиент-серверных вызовов.

[fed]

Цитата:

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

Особенно весело это смотрится когда InventMovement живет на клиенте. Ворох клиент-серверных вызовов.

Ну как бы при нормальной разноске - он не должен жить на клиенте. Просто у inventMovement стоит RunOn:called from из за того, что иногда он вызывается не для разноски, а для того чтобы какая-нибудь форма (типа формы "В наличии") могла получить некоторые параметры складского документа, не залезая напрямую в исходную таблицу. Если inventMovement создается из кода разноски, скажем - PurchFormLetter_invoice, то он должен унаследовать execution tier от вызывающего класса. Который, в нормальных условиях, будет выполняться на сервере.
Я думаю, у вас там что-то в логике разноски изменено, из за чего базовый класс разноски вызывается на клиенте, что и порождает чехарду...

[Logger]

Да, есть такое дело.

[Ievgenii]

Цитата:

Я не могу понять, почему такие фундаментальные классы ни в какой документации не описаны?!

Цитата:

в стандартной поставке не хватает хорошего tutorial по созданию собственных складских документов, которой также стоило бы расписать в тренинге Development IV.

Согласен. Постараемся исправить. Посмотрим что получиться.

Буквально сегодня рисовал свой InventUpd_* класс (добавлял дополнительный статус проводки для ax2009)
В принципе, там всё просто, но для новичка наверное не помешали бы комменты в коде или хотя бы описание переменных, объявленых в класс декларейшн.

[Raven Melancholic]

AX2009 напомнил про одну деталь. Правда она не напрямую затрагивает InventUpd*, но связана с этими классами.
В перечислениях статусов прихода и расхода значения идут подряд не хватает "дырок", позволяющих вводить свои промежуточные статусы (например, ушло от поставщика и находится в пути). А так как во многих местах идет сравнение, то вводить новые статусы проблематично - приходится во многие места добавлять к условиям > (или >=) еще и || Что-то там

[Logger]

Цитата:

Сообщение от Raven Melancholic

AX2009 напомнил про одну деталь. Правда она не напрямую затрагивает InventUpd*, но связана с этими классами.
В перечислениях статусов прихода и расхода значения идут подряд не хватает "дырок", позволяющих вводить свои промежуточные статусы (например, ушло от поставщика и находится в пути). А так как во многих местах идет сравнение, то вводить новые статусы проблематично - приходится во многие места добавлять к условиям > (или >=) еще и || Что-то там

Да, точно!

Мне кажется, в стандартном коде некорректно поставлены условия на эти статусы в виде ">" или "<"
Изначально правильнее было бы перечисления вводить.

[fed]

Я когда-то тоже жалел, что статусы не были пронумерованы с шагом, скажем, 10 и приходиться вводить подстатусы в другом поле. Но вот только вопрос: Допустим вы между Ordered и Arrived завели статусы InTransitForeign, InCustomWarehouse,InTransitDomestic. Что вы будете делать со всей логикой (а ее довольно много), которая местами пляшет не от сравнения статусов по < или >, а работает исключительно по равенству статуса константе ?
Я, в какой-то момент, решил что подстатусы заводить все-таки правильнее, и отсутствие промежуточных статусов - это не design flaw, а осмысленное решение..

[sukhanchik]

Цитата:

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

Я когда-то тоже жалел, что статусы не были пронумерованы с шагом, скажем, 10 и приходиться вводить подстатусы в другом поле.
...
Что вы будете делать со всей логикой (а ее довольно много), которая местами пляшет не от сравнения статусов по < или >, а работает исключительно по равенству статуса константе ?
Я, в какой-то момент, решил что подстатусы заводить все-таки правильнее, и отсутствие промежуточных статусов - это не design flaw, а осмысленное решение..

Тут надо определиться. Либо надо ВЕЗДЕ делать сравнение по < > и тогда делать "дырки" в статусах, либо ВЕЗДЕ перечислять их и отказаться от < >. Я (мое личное мнение) за то, чтобы отказаться от < >, т.к. внутреннее числовое значение енума спрятано от пользователя/программиста. А если уж кто вводит новй статус - пусть 10 раз подумает в скольких местах это аукнется. Ту же новую складскую аналитику прописываем в N-цати местах - научились. Так и тут - научимся коль припрет

[S.Kuskov]

Цитата:

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

внутреннее числовое значение енума спрятано от пользователя/программиста

Это почему же? Программисту вполне доступна информарция о числовых значениях enum'а. А если включить свойство UseEnumValue, то и пользователь будет иметь представление, если не о самих значениях, то хотябы о порядке их следования.

Т.е. в моём представлении, если UseEnumValue = NoYes::Yes, то enum представляет собой не просто множество доступных значений, а именно упорядоченное множество. И в таком случае логично повсеместно использовать операции < >.

[sukhanchik]

Цитата:

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

Это почему же? Программисту вполне доступна информарция о числовых значениях enum'а.

Не согласен. Пользуемся штатными средствами:
1. Обозреватель таблиц
2. Обычные формы, где используется енум
3. Отладчик.

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

[S.Kuskov]

Согласен, что сравнивать значение enum'а непосредственно с числовым значением некорректно, но с другим значением этого же enum'а... почему нет? Я бы даже предложил сделать операции инкремента и декремента для таких упорядоченных enum'ов, которые бы переводили бы его в следующее или предыдущее состояние.

P.S.: Cоздавая relation'ы на таблицах с использованием enum приходится использовать их числовые значения.

[sukhanchik]

Цитата:

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

Согласен, что сравнивать значение enum'а непосредственно с числовым значением некорректно, но с другим значением этого же enum'а... почему нет? Я бы даже предложил сделать операции инкремента и декремента для таких упорядоченных enum'ов, которые бы переводили бы его в следующее или предыдущее состояние.

Вот... а в этом случае на уровне АОТа Enum-ы следовало бы разбить на 2 вида: Упорядоченные, для которых доступны операции инкремента/декремента и в которых программист не управляет значениями в БД, но зато сам может вставить промежуточный статус. Сейчас это не получится сделать, т.к. между двумя последовательными целыми числами новое число не вставишь. Хотя параметр UseEnumValue казалось бы мог решить сию проблему.

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

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

Цитата:

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

P.S.: Cоздавая relation'ы на таблицах с использованием enum приходится использовать их числовые значения.

Увы, это так - но я бы назвал это скорее недостатком ядра, т.к. уже успел еще на 3.0 столкнуться с тем, что MS менял id значения енумов, в результате чего в собственных доработках приходилось раскапывать все эти места и править