Valery - у нас как раз был случай зажатия мгновенной себестоимости финансвыми аналитиками. Разносили журнал списаний в котором было тысяч 5-7 строк с серийными номерами в финансовой аналитике. Как показал натурный эксперимент - рассчет мгновенной себестоимости занимал процентов 50 от общего времени разноски. Которое было не приемлимым совсем.
Так что рассчет себестоимости списания на больших объемах - это как раз серьезная проблема, которую так просто не обойти.
Кстати - мне кажется что слухи о тормознутости закрытия склада сильно преувеличены
Во первых после того как в 3.0SP2 сделали многопользовательское закрытие склада - производительность закрытия растет почти линейно с увеличением числа рабочих станций закрывающих склад.
Во вторых - как показали эксперименты - после 20-30 итераций,которые даже при большом объеме движений проходят на 2-5 часов, обычно остаются только те номенклатуры, по которым в данных есть какая-то кривизна. Ну например - сторнировали журнал перемещений (особенно - если несколько раз), а маркировку проводок не расставили. Или просто сторнировали складские движения без маркировки или установки лота возврата. Ну или наконец списали что-то до того как оно пришло. (Кстати это и без галочки отрицательный склад может быть).
В общем - методика такая - ставишь закрывать склад, потом после 20-30 итераций прерываешь и смотришь какие номенклатуры в списке закрытия остались. Откатываешь закрытие, разбираешься с этими номенклатурами (сторнируешь, добиваешься отсутствия отрицательных остатков, маркировки проставляешь и т.д). Потом снова закрываешь.
Еще помогает методика - поставить сначала коррекцию пропускной способности в маленькое число (в 5 копеек скажем), а после того как прошло какое-то разумное число итераций - поставить туда с соседней рабочей станции рубль или 5.
При этом та номенклатура, по которой данные нормальные, закроется с точностью в 5 копеек, а та по которые данные кривые (и она в 20-30-40 итераций не закрылась) закроется с погрешностью 5 рублей. В некоторых случаях это выгоднее чем долгое разбирательство и наведение порядка в данных.
Так что если пытатся с каждым закрытием склада осознанно разбираться, а не просто сидеть и ждать когда оно до миллионной итерации дойдет - то все не так уж плохо выглядит.