DynamicsAxSCM: Back ported features from Dynamics AX 2012 to Dynamics AX 2009

[Ievgenii]

Спасибо за отзывы. Интересно!

Цитата:

5000 (кажется такой порог сейчас в SQL Server 2005/2008),

Порог там вроде 50.000-70.000, но это конечно ничего не меняет.

Цитата:

начнется эскалация блокировок с записей на страницы и кучу невинных пользователей заблокируют нахрен.

Хм, тут наши ПМы очень хотят понять что имено будет блокироваться, как долго и почему это так критически. Пожалуйста опишите более детально. Спасибо!

История у этой фичи такая, что она ускоряет IC чуть не в 3 раз для наших TAP AX 2012 и Dynamics AX 2009 пользователей (которые с ней работают сегодня). То есть, ее перенесли на прошлую версию иммено потому что она конкретно ускоряет IC. Более того, это первый раз мы получаем негативный отзыв о фичи за 2 года..

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

Цитата:

Возможное решение проблемы - переписать этот класс на обновление по одной номенклатуре,

По разным причинам (не предмет обсуждения) эта фича так и реализована в Dynamics AX 2012 .

Цитата:

Кроме того, мне не нравиться что эти складские проводки закрываются вообще без создания записей в inventSettlement. Почему-то для закрытых проводок по услугам, такие записи создаются, а для нефинансовых переносов - нет...

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

[fed]

Про полезность фичи, никто не спорит. Но как-то отрыв inventTrans от inventSettlement несколько смущает.В прочем на фоне того что натворили в DAX2012, это не самая большая проблема совместимости.
Эскалация блокировок (если верить MSDN), случается если "A single Transact-SQL statement acquires at least 5,000 locks on a single nonpartitioned table or index."
Теперь представь картину:
1. У нас есть 10 групп складской аналитики
2. По каждой группе система одним update'ом помечает нефинансовые переносы закрытыми. Есть большие шансы что часть этих updateов будет обновлять более 5000 записей и блокировки будут эскалированы до уровня страниц.
3. Я, конечно, не до самого конца понимаю, как как эскалация блокировок работает, но рискну предположить что по кластерному индексу окажутся заблокированы записи с соседними inventTransId, которые (вполне возможно) не имеют отношения к текущему закрытию и вообще еще в статусе Ordered/onOrder.
4. Как результат, либо закрытие будет ждать пользователей, которые заблокировали записи, не имеющие отношения к закрытию, либо наоборот - пользователи будут ждать закрытия.
5. Поскольку блокировки будут создаваться не все сразу, в порциями по одному созданию (и ожиданию) блокировок на одну группу складских аналитик, шансы на создание дидлока или, по крайней мере, дерева блокировок, резко возрастают.

То есть - идея состоит не в том чтобы от механизма отказаться, в просто в том чтобы постараться не генерировать update-statement, которые обновляют слишком много складских проводок в одной операции...

[fed]

Цитата:

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

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

В качестве конструктивного предложения: Может для приходов закрытых без использования inventSettlement, устанавливать какую-то новую птичку в inventTrans ? Чтобы можно было бы легко подкурочить всякие самописные отчеты на неиспользование таких проводок...

[fed]

Цитата:

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

В качестве конструктивного предложения: Может для приходов закрытых без использования inventSettlement, устанавливать какую-то новую птичку в inventTrans ? Чтобы можно было бы легко подкурочить всякие самописные отчеты на неиспользование таких проводок...

Оказывается галочка-то уже есть. Называется NonFinancialTransferInventClosingRecId и содержит ссылку на inventClosing.recId, по которой данная запись была закрыта. Осталось в этот же механизм услуги засунуть, и все более или менее логично получится...

[Ievgenii]

Ясно. Посмотрим что можно сделать.

[Logger]

Цитата:

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

Ясно. Посмотрим что можно сделать.

Кстати, а по поводу этого
пересчет себестоимости в журналах переноса?

ПМ-ы ничего нового не решили ?
Переносы и заполненные лоты возврата в будущем продолжат себестоимости разных аналитик перемешивать ? (по-моему, так это просто дыра в архитектуре - пока она не вылечена - нет смысла говорить о LIFO, FIFO при расчете себестоимости)