Резервирование при переносе

[Yprit]

Столкнулся с ситуацией:
на складе есть 2 партии одной номенклатуры по 1 штуке в каждой партии
создаем журнал переноса на 2 штуки, в строках указываем только склад. Резервируем. Создаются 2 проводки прихода и 2 расхода, все корректно разбивается по партиям. Уменьшаем количество в журнал переноса до 1 штуки. Смотрим проводки - партии в проводке прихода и проводке расхода разные....

Изыскания привели меня к следующему куску кода в классе InventUpd_Estimated (методы updateDepreciateReceipt и updateDepreciateIssue):

PHP код:

 while select forupdate inventTrans
        index hint TransIdIdx
        order by statusReceipt desc,inventRefTransId,inventDimId desc 


Т.е. получается, что сопоставление проводок прихода с расходом при уменьшении резерва идет не по комбинации складских аналитик, а по очередности создания записей в InventDim? Это нормальное поведение системы? Или я не понимаю всей хитрости данной схемы?

[Yprit]

Народ, ну неужели никто на эти грабли еще не наступал? Товар же с партии на партию мухой улетает

[glibs]

У меня на вскидку в тестовой базе не воспроизвелось. Судя по всему, тут нужно особое стечение обстоятельств.

Еще теоретически можно предположить, что партию предполагали подбирать руками (для каждой партии отдельная строка журнала), а не через авторезервирование.

А вообще, судя по всему, очередная бага. Спасибо, что предупредили.

[Yprit]

Спасибо, glibs!
Ситуация, при которой это вопсроизводится (вполне жизненная, во всяком случае для нас)
1. Приходуем 5 разных партий Товара по 1 штуке в каждой партии на Склад_1
2. Создаем резерв (любым складским журналом, я делал проводкой) 2-х штук Товара на Складе_1
3. Создаем перенос 5 штук Товара со Склада_1 на Склад_2
4. Резервируем (резервируется только 3 штуки, поскольку 2 штуки у нас зарезервированы ранее)
5. Лезем в журнал из пункта 2 и снимаем резерв 2-х штук
6. Возвращаемся в перенос и снова проводим резервирование (теперь зарезервированы все 5 штук)
7. В строке переноса уменьшаем количество (ну, допустим, не 5 штук, а только 3)
8. наблюдаем эффект, когда со Склада_1 уходят Партия 1, 2 и 3, а на Склад_2 приходят Партия 3,4 и 5.
Что соответствует очередности создания записей для Товара по Складу_1 и Складу_2 в таблице InventDim

"Прячась в лого свое
Волки воют 'Ё-Моё' ...

[AvrDen]

Похоже в 4-ке эту проблему не устранили...
Столкнулся с такой ситуацией: на складе по одной ном-ре имеется кол-во 10 шт.(с номером партии П1). Пользователи создают журнал переноса по этой ном-ре с кол-ом 20 шт. В итоге у нас создаються 4 проводки(Проводки расхода - Физ.зарезервировано 10 шт с партией П1 и Заказано 10 шт без партии, Проводки прихода Заказано 10 шт. с Партией П1 и Заказано 10 шт. без партии). Далее пользователь уменьшает кол-во до 10 шт. В итоге остаються 2 проводки(Проводки расхода - Физ.зарезервировано 10 шт с партией П1, проводки прихода - Заказано 10 шт. без партии). Важный момент в том что код аналитики у аналитик с заполным номером партии у нас всегда больше чем код аналитики без номера партии...
Поэтому в методе InventUpd_Estimated\updateDepreciateReceipt

                    select forupdate inventTrans
                        index hint TransIdIdx
                        order by StatusReceipt desc, InventDimId desc
                        where inventTrans.InventTransId         == movement.transId()               &&
                              inventTrans.TransChildType        == movement.transChildType()        &&
                              inventTrans.TransChildRefId       == movement.transChildRefId()       &&
                              inventTrans.StatusIssue           == StatusIssue::None                &&
                              inventTrans.StatusReceipt         >= StatusReceipt::Ordered           &&
                              inventTrans.StatusReceipt         <= StatusReceipt::QuotationReceipt  &&
                              inventTrans.InventRefTransId      == '';

удаляеться проводка прихода с номером партии.
И в результате получаеться что товар ушел с номером партии, а пришел без номера.
Кто-нибудь подскажет как решить эту проблему?

[kashperuk]

Цитата:

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

Похоже в 4-ке эту проблему не устранили...
Столкнулся с такой ситуацией: на складе по одной ном-ре имеется кол-во 10 шт.(с номером партии П1). Пользователи создают журнал переноса по этой ном-ре с кол-ом 20 шт. В итоге у нас создаються 4 проводки(Проводки расхода - Физ.зарезервировано 10 шт с партией П1 и Заказано 10 шт без партии, Проводки прихода Заказано 10 шт. с Партией П1 и Заказано 10 шт. без партии). Далее пользователь уменьшает кол-во до 10 шт. В итоге остаються 2 проводки(Проводки расхода - Физ.зарезервировано 10 шт с партией П1, проводки прихода - Заказано 10 шт. без партии). Важный момент в том что код аналитики у аналитик с заполным номером партии у нас всегда больше чем код аналитики без номера партии...
Поэтому в методе InventUpd_Estimated\updateDepreciateReceipt

                    select forupdate inventTrans
                        index hint TransIdIdx
                        order by StatusReceipt desc, InventDimId desc
                        where inventTrans.InventTransId         == movement.transId()               &&
                              inventTrans.TransChildType        == movement.transChildType()        &&
                              inventTrans.TransChildRefId       == movement.transChildRefId()       &&
                              inventTrans.StatusIssue           == StatusIssue::None                &&
                              inventTrans.StatusReceipt         >= StatusReceipt::Ordered           &&
                              inventTrans.StatusReceipt         <= StatusReceipt::QuotationReceipt  &&
                              inventTrans.InventRefTransId      == '';

удаляеться проводка прихода с номером партии.
И в результате получаеться что товар ушел с номером партии, а пришел без номера.
Кто-нибудь подскажет как решить эту проблему?

Что-то не удалось воспроизвести это на АХ 2009, хотя вроде код здесь не менялся. До смены кол-ва все ОК, тоже 4 проводки, в двух не указана партия. А вот когда меняю кол-во, остается 2, в обоих указана партия. Что-то может забыли написать, что необходимо сделать?

[Yprit]

Цитата:

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

Что-то может забыли написать, что необходимо сделать?

AvrDem Важный момент в том что код аналитики у аналитик с заполным номером партии у нас всегда больше чем код аналитики без номера партии

Yprit Что соответствует очередности создания записей для Товара по Складу_1 и Складу_2 в таблице InventDim

[altap]

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

[Logger]

Ваня, а можешь проверить, у приходных проводок в переносе статус одинаковый был ?
По идее если одинаковый и
совпадают

inventTrans.TransChildType                              
inventTrans.TransChildRefId
inventTrans.InventRefTransId      == ''

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

Либо тебе повезло с номерами аналитик InventDimID - так что отсортировалось так что проводки с заполненной партией первыми подцепились

[Logger]

Предлагаю перед тем как воспроизводить глюк создать аналитики вот таким джобом

static void Job378(Args _args)
{
    #define.inventBatchId1("BatchID1")
    #define.inventBatchId2("BatchID2")
    #define.InventLocationIDFrom("From")
    #define.InventLocationIDTO("To")
    InventDim       InventDim;
    ;
    ttsBegin;
    InventDim.InventLocationId = #InventLocationIDFrom;
    InventDim.inventBatchId    = #inventBatchId1;
    InventDim::findOrCreate(InventDim);
    InventDim.clear();

    InventDim.InventLocationId = #InventLocationIDFrom;
    InventDim.inventBatchId    = #inventBatchId2;
    InventDim::findOrCreate(InventDim);
    InventDim.clear();

    InventDim.InventLocationId = #InventLocationIDTo;
    InventDim.inventBatchId    = #inventBatchId2;
    InventDim::findOrCreate(InventDim);
    InventDim.clear();

    InventDim.InventLocationId = #InventLocationIDTo;
    InventDim.inventBatchId    = #inventBatchId1;
    InventDim::findOrCreate(InventDim);
    InventDim.clear();
    ttsCommit;
}

затем на обе аналитики поднять остатки и попробовать пример Yprit

Должно сработать.

P.S. В данном джобе я просто заранее создаю аналитики с нужным порядком следования InventDimId, чтобы на одном складе с большему значению InventBatch соответствовало большее значение InventDimID а на другом складе наоборот.

В ax4.0 и ax5.0 может помешать тот факт что выравнивание InventDimID левое - в этом случае нужно убедиться что джоб правильно создал все. - Проблема может возникнуть, если при выделении номера аналитики - число значащих цифр увеличится. Для правого выравнивания гарантировано должно воспроизвестись.

(в общем проще свои номера InventDimId константами пробить)

[Logger]

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

[kashperuk]

Да, проблему воспроизвел. Спасибо
Интересно узнать, как боретесь?
Как-то влияет это на себестоимость? Я понимаю, что себестоимость товара из партии2 на втором складе изменяется в зависимости от себестоимости товара из партии1 со склада1. Насколько это критично?

[Vals]

Ребят, расскажите, как в ваших примерах настроена аналитика?
1. Первичная/Вторичная
2. В складских моделях фифо/лифо для резервирования
3. В параметрах резервирование заказанного
4. Процедура создания номера партии (автосоздание).

[Logger]

Цитата:

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

Да, проблему воспроизвел. Спасибо
Интересно узнать, как боретесь?
Как-то влияет это на себестоимость? Я понимаю, что себестоимость товара из партии2 на втором складе изменяется в зависимости от себестоимости товара из партии1 со склада1. Насколько это критично?

Да, конечно на себестоимость влияет. Если честно - это очень критично. Мне кажется, что из-за этого бага, вообще некорректно говорить о том что себестоимость считается в разрезе аналитик. (Еще есть баг, когда при переносах нескольких партий себестоимость усредняется по ним. Аналогично и при оформлении заказа на возврат, когда заполнениется лот возврата. - Правда это уже другой баг )

Лечили так.
У нас принят партионный учет для всех номенклатур.
Соответственно, когда в InventJournalTrans.Update() стоит вызов

        estimated = new InventUpd_Estimated(InventMovement::construct(this));
        estimated.updateNow();

        if (this.JournalType == InventJournalType::Transfer)
        {
            estimatedTransfer = new InventUpd_Estimated(InventMovement::construct(this,true));
            estimatedTransfer.updateNow();
        }

то в первом вызове

estimated.updateNow()

запоминали пары [аналитика, дельта количества]

Передавали полученную инфу во второй вызов

estimatedTransfer.updateNow();

и там уже при работе InventUpd_Estimated\updateDepreciateReceipt
учитывали эту информацию, так чтобы цеплялась нужная партия и на нужное количество.

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

P.S. Ax 3.0

[Logger]

Цитата:

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

Ребят, расскажите, как в ваших примерах настроена аналитика?
1. Первичная/Вторичная
2. В складских моделях фифо/лифо для резервирования
3. В параметрах резервирование заказанного
4. Процедура создания номера партии (автосоздание).

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

[kashperuk]

А какие еще проблемы, кроме неправильной себестоимости, возникают, если не исправить эту ошибку?

Неправильная себестоимость, насколько я понимаю, возникает только в случае, если аналитика Партия активирована как финансовая (в противном случае она все равно считается в разрезе склада). Или нет?

[Yprit]

Цитата:

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

Ребят, расскажите, как в ваших примерах настроена аналитика?
1. Первичная/Вторичная
2. В складских моделях фифо/лифо для резервирования
3. В параметрах резервирование заказанного
4. Процедура создания номера партии (автосоздание).

Ох, давно это было.... И посмотреть негде...
1. склад, партия, серийный номер (по-моему, было так)
2. Фифо
3. Выключено
4. Да

Цитата:

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

Да, проблему воспроизвел. Спасибо
Интересно узнать, как боретесь?
Как-то влияет это на себестоимость? Я понимаю, что себестоимость товара из партии2 на втором складе изменяется в зависимости от себестоимости товара из партии1 со склада1. Насколько это критично?

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

Относительно себестоимости - с переносами там вообще все довольно зыбко, во всяком случае с точки зрения партионного учета в его российском понимании. Я имею в виду знаменитое усредненине себестоимости в разрезе партий при резервирвании лотов. В самом начале внедрения мне кто-то из великих по этому поводу втолковывал... да, fed - вот здесь. В общем, с помощью этого способа (автоподстановка аналитики в строки журнала переноса, по кнопке и т.п.) и боролись в том числе.

ОФФ: посмотрел свои вопросы 2004 года - как, однако, много воды утекло :-) Спасибо вам, форумчане, гуру наши - чтоб я без вас тогда делал! Просто за руку водили :-)

[Yprit]

Цитата:

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

А какие еще проблемы, кроме неправильной себестоимости, возникают, если не исправить эту ошибку?

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

[AvrDen]

Цитата:

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

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

Да у нас сейчас такая же беда.

Исправил эту ситуацию следующим образом(может немного коряво, но работает):
При удалении расходной проводки запоминаю InventDim и InventDimParm, и передаю их в InventUpd_Estimated\updateDepreciateReceipt. В InventDim заменяю склад, на склад прихода.

[Vals]

Цитата:

Мне кажется, что ни один из этих параметров не должен влиять на воспроизводимость глюка

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

О влиянии: первичная аналитика влияет на перерезервирование, автосоздание номера партии влияет на создание новых номеров при создании новых строк и проводок (при этом влияют параметры автосоздания - в строках, проводках и т.д.).