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

[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 в запрос. Идея думаю, понятна, если кому надо могу выложить код.) В общем случае, конечно, сложнее: придётся делать через кверю или макрос, но тоже реализуемо, имхо...