Журнал переноса. Уменьшение кол-ва. Баг?

[ZVV]

Размещу тему в Функционале, хотя и программирования она тоже вероятно касается...

Топик и для информации и просто интересно как народ с этим живёт/борется.
Этот баг-фича имеет место на всех известных мне версиях с 3.0 по 2009sp1, поэтому на версии внимание не заостряется.

Ситуация следующая:
- Имеем, например, наличие на складе 1 какой-то номенклатуры 200 штук. С какими-то дополнительными аналитиками, например, партия и ГТД.
- Создаётся журнал переноса этой номенклатуры со склада 1 на склад 2 в кол-ве 300 штук, например (больше наличия на складе 1). Т.е. в самой строке журнала указываем только аналитики склада (1->2) (ну и сайт в 2009). Соответственно резервируется (и возможно комплектуется - это не сильно важно) 200 единиц на складе 1. В проводки при резервировании подтягивается остальная аналитика (и в приходные тоже). Т.е. на данный момент имеем следующую ситуацию в проводках:

Склад Партия ГТД Ст.Прихода Ст.Расхода ___ Кол-во
1 ____ П1 ___ Г1 ____________ Физ.Зарезерв. -200
1 __________________________ В заказе ____ -100
2 ____ П1 ___ Г1 Заказано _________________ 200
2 _____________ Заказано _________________ 100

- Теперь, когда пользователь должен разнести журнал и увидит, что кол-во в строке слишком большое, то естественно он захочет его уменьшить. Т.е. уменьшит кол-во в строке журнала с 300 до 200. И вот тут Аксапта делает свою багофичу, лично для меня неприятную и слабоожидаемую. На выходе получаем следующую картину:

Склад Партия ГТД Ст.Прихода Ст.Расхода ___ Кол-во
1 ____ П1 ___ Г1 ____________ Физ.Зарезерв. -200
2 ____ П1 ___ Г1 Заказано _________________ 100
2 _____________ Заказано _________________ 100

Т.е. она убирает не последнюю (4-ую) строку "Заказано", а уменьшает 3-ю строку с уже подтянутыми аналитиками из зарезервированных проводок. Конечно, в данном конкретном случае можно просто перерезервировать (если никто не успеет перехватить ), а вот если строки скомплектованы, то сложнее. В итоге обычно пользователи не обращают на это внимания и журнал разносится как есть и теряются аналитики. Потом приходится эти случаи отлавливать и корректировать аналитику...
А хотелось бы, чтоб всегда "уходила последняя строка.

Теперь, перейдём к программингу и поиску причин данного поведения. Причина проста и кроется в методе updateDepreciateReceipt() класса InventUpd_estimated. Метод, конечно, претерпевал определённые изменения от версии к версии, но суть оставалась та же. В данном случае приходная проводка "под уменьшение" искалась по сути первая попавшаяся, точнее с наибольшим кодом аналитики. (сортировка InventDimId desc в запросе). Ну и, соответсвенно, при определённом везении получался описанный выше результат. А иногда и не получался, понятное дело.

У себя с учётом специфики конкретного случая и конкретных аналитик я доработал данный алгоритм так, чтоб при обработке именно приходов по переносу смотрелись ещё аналитики и в первую очередь брались пустые. (Присоединил inventDim в запрос. Идея думаю, понятна, если кому надо могу выложить код.) В общем случае, конечно, сложнее: придётся делать через кверю или макрос, но тоже реализуемо, имхо...

[kashperuk]

Вроде как в 6ке это пофиксили. Хотя проверю еще раз

[Logger]

Кстати, уже было обсуждение этой темы
Резервирование при переносе

[Logger]

Цитата:

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

Вроде как в 6ке это пофиксили. Хотя проверю еще раз

Если не секрет, каким способом фиксили ?

[ZVV]

Цитата:

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

Кстати, уже было обсуждение этой темы
Резервирование при переносе

Ага, в самом деле...
Я пытался (не очень настойчиво) найти сначала нечто подобное на форуме, но вижу не по тем словам искал...

[miklenew]

Тоже когда то на это натыкался.
Аудит блокировок

[kashperuk]

Цитата:

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

Кстати, уже было обсуждение этой темы
Резервирование при переносе

Да, именно в этой теме вычитал про этот баг, запостил.
Пофиксили - переписали кучу классов InventUpd_,InventMov_, насколько я помню.
То есть не получиться здесь привести краткое описание того, что было сделано.

[Logger]

Цитата:

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

Да, именно в этой теме вычитал про этот баг, запостил.
Пофиксили - переписали кучу классов InventUpd_,InventMov_, насколько я помню.
То есть не получиться здесь привести краткое описание того, что было сделано.

Радует что пофиксили.
Столько крови было попорчено из-за этого

Иван, что бы мы без тебя делали...

[kashperuk]

Цитата:

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

Радует что пофиксили.
Столько крови было попорчено из-за этого

Иван, что бы мы без тебя делали...

Я думаю Майкрософт и без меня бы справился с этой задачей

[Ivanhoe]

Цитата:

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

Вроде как в 6ке это пофиксили. Хотя проверю еще раз

А для младших версий хот-фиксы запланированы? Или нужно писать запросы в поддержку?

[kashperuk]

Цитата:

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

А для младших версий хот-фиксы запланированы? Или нужно писать запросы в поддержку?

Нет.
Я работаю в команде, которая занимается разработкой след. версии.
SE организация работает независимо (ну, не совем, но скорее это мы от них зависим).

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

[Slava Chernenko]

На самом деле фикс все-таки не столь массивный - основная часть это изменение методов updateDepreciateReceipt, updateDepreciateIssue класса InventUpd_Estimated (ZVV правильно указал первопричину проблемы) + небольшое изменение InventMovement.inventDimMerged() метода.
Суть фикса в переписывании логики поиска транзакций которые могут быть удалены, принимая во внимание аналитики.

[Maximin]

А зачем inventDimMerged() трогать? Мы также решили эту проблему, но обошлись без модификации inventDimMerged.
P.S. Хорошо, что нашелся-таки человек который написал пост про решение проблемы.
Никак руки не доходили...

[Slava Chernenko]

Цитата:

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

А зачем inventDimMerged() трогать? Мы также решили эту проблему, но обошлись без модификации inventDimMerged.

inventDimMerged на базовом классе возвращал всегда значение входящего параметра.
Фикс коснулся трансфер мувментов для корректного учета изменения аналитик при трансфере.

[Maximin]

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

[kashperuk]

Цитата:

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

Нет.
Я работаю в команде, которая занимается разработкой след. версии.
SE организация работает независимо (ну, не совем, но скорее это мы от них зависим).

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

Вроде как начались обсуждения переноса фикса как минимум на АХ 2009.
Так что, если все пойдет по плану, ждите хот-фикса.
На более ранние версии, правда, врядли перенесут...

[Maximin]

Ёлки зеленые! Я почему-то думал, что речь идет о заказах на перемещение (постоянно их путаю, никак не привыкну)! У нас основные точно такие же проблемы вылезли как раз на них - там есть ТОЧНО такой же баг с уменьшением кол-ва.. Впрочем, лекарство, как я вижу, однотипное.

kashperuk:
А фиксы по исправлению подсчета себестоимости в заказах на перемещение будут? А то есть проблемы, аналогичные описанным в этой старой теме Журнал переноса - себестоимость
Имеем ситуацию, когда строка заказа на перемещение имеет несколько скл. проводок, которые, в свою очередь, имеют разные партии(физ. аналитики склад+партия, финансовая - склад). В этом случае себестоимость (даже если запустить пересчет!) по этим проводкам, будет разная. И, насколько знаю, это общая проблема.

Люди решали, знаю, путем написания патча, который при разноске заказа на перемещение тупо дробит строки, имеющие неск. партий, на несколько строк журнала. Тогда с себестоимостью всё корректно.

[Maxim Gorbunov]

Цитата:

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

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

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

[Maximin]

Специфика работы российской таможни приводит к тому, что ГТД зачастую появляется гораздо позже самого товара. Другое дело, что, IMHO, использовать ГТД лучше не стандартным способом, как складскую аналитику, а привязывать к партии. Но и с партией - бывает так же (кладовщик приходует товар по кол-ву, партии приходят на бумаге и позже), но тут я более согласен.

Цитата:

Сообщение от Maxim Gorbunov

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

[kashperuk]

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

Опишите поподробнее, проверим.