Электроник писал(а) 08. Июня 2010 :: 13:18:Дело не во времени проведения, и двигать позицию документа тоже нельзя, т.к. он может быть двух-трехнедельной давности.
Пример. Менеджер набил Заявку для клиента, товар зарезервировался. Через некоторое время (напр., неделя) клиент звонит и говорит: "А добавьте-ка мне вот того-то еще 100 штучек". Менеджер смотрит на остатки и видит необходимое кол-во, увеличивает кол-во в Заявке и пытается провести. А ему облом, т.к. на момент Заявки столько не было, а через, допустим, 3 дня товар пришел или другой клиент отказался от него. Заявку перенести на текущую дату - тоже риск, т.к. другого товара из списка может не хватить. Вот в чем проблема. И вот почему я хочу делать резерв разными датами.
Что то я не понимаю
новый звонок новая заявка. За неделю могут и цены вырасти
с чего ради продавать по заниженным ценам.
Все пихать в один документ плохо с точки зрения 1с
Перепроведение документа происходит так
1.Открываем транзакцию
2.Блокируем монопольно всю таблицу _1sjourn ( до конца транзакции )
(так же блокируются все чего коснуться запросы )
3.Отменяем все текущие движения документа из rg
удаляем все движения документа из ra
4.Выполняем модуль проведения
для каждого движения
изменяем rg и добавляем новую строку в ra.
5.Фиксируем транзакцию
Т.е. чем больше строк тем больше время проведения ( а это критический ресурс ) причем зависимость явно не линейная а хуже.
Так что с точки зрения производительности два
документа на 70 и 30 строк лучше чем один на 100 строк.
Если изменения касаются только одного документа а это так как даты разные то два документа всегда лучше чем один.
PS Да и твой случай вполне реализуем (обычным регистром остатков) смотри остатки не на документ а на TA и все тоже получится ( только в каких ценах считать проблема, если резервы живут ограниченное время тоже проблема да и производительность ухудшится )