Дарова!

Вобщем проблема такая:
После проведения перемещения товаров, вид - товар по ордеру, его переводят в резерв, например, заказом покупателя. Далее при создании на основании перемещения Расходного ордера на товары, свободного остатка уже не хватает.

Если делать Внутренний заказ под перемещение, чтобы создавался резерв, то при проведении перемещения этот резерв снимается и проблема остается.

Что посоветуете?

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

(1) что-то мешает допилить УТ 10.3 ?

(1) Ну так свободный остаток определяется как фактический минус резерв и минус товары к передаче. У вас при перемещении по ордеру ведь возникает остаток товаров к передаче и уменьшается свободный остаток. Так что нет никакой проблемы и ничего не надо пилить даже.

(2) сначала надо разобраться, потом допиливать

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

(3) Мать, ткни в код, где это реализовано: "свободный остаток определяется как фактический минус резерв и минус товары к передаче".

В обработчике проведения заказа не нашел.

(5) возникает конкуренция, хоть товар и "к передаче" после проведения перемещения, но его почему-то могут резервировать заказами, затем в расходном ордере возникает недостача при оперативном проведении.

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

(8) спасибо, буду искать.

Кто-то кривыми руками, наверное что-до допилил...

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

(8) не понял причем здесь регистр резервов, по идее должен срабатывать контроль по регистру товары к передаче или так как написано в (3)

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

(11) по вашей проблеме: может установлена галка в настройках пользователя или учетной политике типа разрешить превышение остатков?

(12) Я решила проблему уже. Галки были нормально поставлены, просто в моем случае перемещение не должно было двигать резервы, вот штатно и не проверялось ничего кроме фактического остатка - т.е. больше, чем в наличии, переместить нельзя было, а то, что свободный остаток в минус уйдет - не важно. Короче, немного попилить пришлось.

(14) ясно, еще раз спасибо за помощь, продолжу эксперименты с отладчиком.

(11) [ Перемещению, как правило, по фигу на резервы]
в оперативном режиме не пофиг

Подитожу,
нашел участок кода контроля остатков, о котором в (3) -> в модуле Заказа покупателя см. ДвиженияПоРегистрамУпр:

НаборДвижений = Движения.ТоварыВРезервеНаСкладах;
           
// Проверка остатков при оперативном проведении.
Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
   НаборДвижений.КонтрольОстатков(ЭтотОбъект, "Товары",         СтруктураШапкиДокумента, Отказ, Заголовок);
   НаборДвижений.КонтрольОстатков(ЭтотОбъект, "ВозвратнаяТара", СтруктураШапкиДокумента, Отказ, Заголовок);
КонецЕсли;

Вижу 2 варианта решения:
1) простой для программиста, но не удобный для пользователя - запрет, неоперативного проведения.
2) не такой простой как 1) для программиста, но удобный для пользователя - контроль остатков при неоперативном проведении.

при втором варианте конфигурация может "загнуться" из-за увеличения длительности транзакции проведения -> взаимоблокировки

+ дополнительную нагрузку создаст добавление периода в таблицы остатков основного запроса из НаборДвижений.КонтрольОстатков (как известно, если у виртуальной таблицы остатов в запросе период не указан, то система получает их на самую последнюю дату возможную в 1С,а эти остатки всегда есть, их не нужно рассчитывать.)

теперь внимание :) вопрос:
как эта схема отработает на практике, если пользователей в базе не больше 100?

есть опыт описанного у кого-нибудь?