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