inventItemLocationSelectLocked

[Yprit]

В классе InventUpdateTTSControl этот метод лочит запись с пустой аналитикой в таблице InventItemLocation. Насколько я понимаю, это происходит при каком-либо измненении в физическом наличии номенклатуры по комбинациям аналитики. Это же следует и из комментариев в методе "Lock on table inventItemLocation is used for serialisation of updating processes". Непонятно одно - почему лочится именно запись "по-умолчанию"? В результате если у меня разносится накладная по заказу с номенклатурой А со Склада1, а Склад2 пытается переместить эту же номенклатуру между ячейками, то он будет ждать окончания разноски заказа. Не логичнее ли будет лочить запись в InventItemLocation для конкретного склада? Но последствия такой модификации я до конца представить не могу. Хотелось бы услышать просвещенное мнение ALL.
Спасибо

[ViV]

Что-то не было ни одного ответа
А тема достаточно для нас актуальна - складов достаточно много, и блокировки по таблице InventItemLocation частенько возникают.
В чем вообще сокровенный смысл этой таблицы? Если галка "блокировать при инвентаризации" у нас не активна и нам данный бизнес-процесс не нужен - можно ли от нее как-то избавится?
Хотя вы убрать из класса InventUpdateTTSControl ?

[Nikolaich]

посмотрите содержимое этой таблицы и убедитесь в том что она у вас не используется. Если не используется - можете найти в коде блокировку и грамотно ее отключить. Убедиться в том что она неиспользуется очень просто - проверьте есть ли записи с InventDimId не равнному 'Axapta' !
Если нет таких записей - вам эта таблица не нужна

[Logger]

Цитата:

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

посмотрите содержимое этой таблицы и убедитесь в том что она у вас не используется. Если не используется - можете найти в коде блокировку и грамотно ее отключить. Убедиться в том что она неиспользуется очень просто - проверьте есть ли записи с InventDimId не равнному 'Axapta' !
Если нет таких записей - вам эта таблица не нужна

По-моему вы ошибаетесь.
Код

    if (_movementIssue.mustBeOnhandLocked(false))
        appl.inventUpdateTTSControl().inventItemLocationSelectLocked(_movementIssue.itemId());

встречается в классах
InventUpd_Reservation
InventOnhand ( а как следствие и везде где меняется статус проводки, например в InventUpd_Financial)

Он накладывает блокировку в InventItemLocation в том случае если нужно запретить списывать финансовое или физическое количество в минус.

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

Журнал приемки

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

[Logger]

У меня правда вопрос аналогичный. Возможно ли как-то избавиться от блокировок и сохранить проверку отрицательного склада. Непонятно зачем для этих целей накладывают блокировки на InventItemLocation

У нас используется партионный учет, и при резервировании не хотелось бы блокировать InventItemLocation с пустой аналитикой (фактически мы целую номенклатуру блокируем). Возможно ли это как-то обойти.

Непонятно почему разработчики Аксапты решили задачу проверки отрицательного склада блокировкой на InventItemLocation. Можно было бы попробовать блокировать InventSum только по нужной аналитике. Даже методы есть подходящие.

см.
\Classes\InventUpdateTTSControl\inventSumSelectLocked
и
\Classes\InventUpdateTTSControl\inventItemLocationSelectLocked


P.S. Ax 3.0 SP5

[Logger]

Интересно, а как с обстоит дело с блокировкой таблицы InventItemLocation в Ax 4.0 - 2009 ?
Блокировки по InventSum там оптимизировали.

[Raven Melancholic]

Цитата:

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

Интересно, а как с обстоит дело с блокировкой таблицы InventItemLocation в Ax 4.0 - 2009 ?
Блокировки по InventSum там оптимизировали.

В DAX4 такой механизм блокировки (путем блокирования InventItemLocation) уже не используется. Сам механизм резервирования здорово переписан и работает не напрямую с InventSum, а путём накапливания изменений и записью при помощи прямого доступа к базе..

[ViV]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

Спасибо.
В принципе это и интересовало.
Судя по всему этот код нужен для корректной работы системы множественных складских транзакций IMTS. А когда она выключена - он не нужен.

[Logger]

А партионный учет или какая -нить другая высокоселективная аналитика (серийные номера, ГТД) у вас используется ?
Вопрос связан с тем что по идее отключение этого кода не поможет если партии не используются. - Просто появятся блокировки на InventSum вместо InventItemLocation.

[ViV]

Цитата:

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

Спасибо.
В принципе это и интересовало.
Судя по всему этот код нужен для корректной работы системы множественных складских транзакций IMTS. А когда она выключена - он не нужен.

Опять не соглашусь. У нас IMTS включена. Особых проблем возникших при комментировании того кода не отмечено.
У нас есть и серийные номера, и партии, и ГТД. Полный набор
Другое дело что в InventItemLocation у нас только записи с InventDimId = Axapta.

[Logger]

Ну и ну...
Вот так раз.

Ну значит надо еще код поковырять
В общем судя по комментариям эти блокировки как раз для работы системы множественных складских транзакций нужны. А база данных у вас какая ? Подозреваю, MS SQL ?

[ViV]

Цитата:

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

В общем судя по комментариям эти блокировки как раз для работы системы множественных складских транзакций нужны. А база данных у вас какая ? Подозреваю, MS SQL ?

А можно привести комментарии, по которым вы сделали такой вывод?

Верно, MS SQL 2000. Ax 3.0 SP3

[Logger]

\Classes\InventUpd_Reservation\updateReserveMore

    appl.inventUpdateTTSControl().setTTSBeginLock();

    if (movement.mustBeOnhandLocked(false))
        appl.inventUpdateTTSControl().inventItemLocationSelectLocked(movement.itemId());

\Classes\InventUpdateTTSControl\inventItemLocationSelectLocked

/*
Lock on table inventItemLocation is used for serialisation of updating processes - lock is only used,
if required when instantiating class: InventOnHand (when 'lock' -flag is set to 'true')
*/

public inventItemLocation inventItemLocationSelectLocked(ItemId itemId)
{
    InventItemLocation inventItemLocation;
    ;
   ...
}

\Classes\InventUpdateTTSControl\setTTSBeginLock

/*
Begin secondary transaction (used to establish serializing lock in table InventItemLocation)
*/
public void setTTSBeginLock()
{
    InventUpdateTTSMode tmpTTSMode;
    ;
    if (!this.mustUseTTSSystem())
        return;
   ...
}

обращаю внимание на этт кусок кода

    if (!this.mustUseTTSSystem())
        return;

[Logger]

/*
Used all over to detect whether TTSSystem is active.
If method setTTSMode has not been called before first call to this method, it will default to
"Standard" which means that TTSSystem is not active. Generally method setTTSMode is called when
instantiating class hierarchy InventUpdate
*/

public boolean mustUseTTSSystem()
{
    if (TTSMode == InventUpdateTTSMode::UnDecided && appl.ttsLevel())
        TTSMode = InventUpdateTTSMode::Standard;

    if (!InventUpdateTTSControl::tTSSystemEnabled())
        return false;

    return TTSMode == InventUpdateTTSMode::TTSsystem ? true : false;
}

[ViV]

Спасибо, уточню что именно было закомментировано:
\Classes\InventUpdateTTSControl\inventItemLocationSelectLocked закомментирован полностью,

\Classes\InventUpdateTTSControl\setLockInventSumCreate до состояния:

public void setLockInventSumCreate(InventTrans inventTrans)
{
//    InventItemLocation  inventItemLocation;
//    InventDim           inventDim;
//    ;

    if (!this.mustUseTTSSystem())
        inventDim::find(inventTrans.inventDimId,true);
    else
    {
//        inventItemLocation.setConnection(this.dBConnectionLock());

//        select firstonly forupdate inventItemLocation
//            index hint ItemDimIdx
//            where inventItemLocation.ItemId         == inventTrans.ItemId   &&
//                  inventItemLocation.inventDimId    == InventDim::inventDimIdBlank();
    }
}

Все. Собственно блокировки у нас вызывал именно inventItemLocationSelectLocked.

[Logger]

Это не опечатка при копировании ?

    if (!this.mustUseTTSSystem())
        inventDim::find(inventTrans.inventDimId,true);

Зачем InventDim блокировать ?
Она же в общем случае может разным номенклатурам соответствовать.
Сюда по идее

Inventsum::find(..., true);

просится

[ViV]

Цитата:

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

Это не опечатка при копировании ?

    if (!this.mustUseTTSSystem())
        inventDim::find(inventTrans.inventDimId,true);

Зачем InventDim блокировать ?
Она же в общем случае может разным номенклатурам соответствовать.
Сюда по идее

Inventsum::find(..., true);

просится

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