Управляемые блокировки. Итак, есть две технологии:

I Классика
1. Тразакцию отрываем
2. Блокировка (блокировка данных),
3. запрашиваем,
4. расчитываем
5. если хватает по расчетам, записываем
6. фиксация транзакции.

II 8.2 и выше
1. Транакцию отрываем
2. запись с блокировкой по количеству (ЗаписыватьДляИзменения)
3. контроль отрицательных остатков (запрос)
4. если нет мирусов, Фиксация транзакции.
При этом 2й метод предполагает отложенное допроведение по сумме.

Что мне непонятно. Почему при использовании 2го метода нельзя выполнить проведение так же и по сумме?

Например:
II 8.2 и выше
1. транзакцию открываем,
2. запись с блокировкой по количеству (БлокироватьДляИзменения)
3. контроль отрицательных остатков (запрос). Если минус, отмена транакции
4. расчет с установкой сумм того же набора (запрос)
5. запись набора
6. фиксация транзакции.

При этом, преимущество второго метода над первым - как минимум сокращение времени транзакции за счет отсутствия расчета суммы списания в случае нехватки

Почему нельзя, мешает кто-то?

Сумма тут к блокировкам / контролю остатков отношения не имеет вообще никакого. Вопрос скорее методологии.

(2) Расчет суммы требует времени и удлиняет время блокировки. А идея как раз сократить это время

(3) Только если эти суммы беруться откуда -то из другого места. Иначе - ничего не удлиняет.

(4) "Расчет" вроде подразумевает, что этих сумм нет готовых.

(0) >> 4. расчет с установкой сумм того же набора (запрос)
Как правило суммовой учет идет в других регистрах.

(5) в моем случае регистр тот же.
С ОУ не работал, но просто оставались сомнения, когда попросили сделать. Всем спасибо.

(0) Второй вариант: сначала запись (с вытекающей из этого установкой блокировок), а потом получение сумм - не дает никакого выигрыша в скорости по сравнению с установкой блокировок сразу.

(0) Почему нельзя? Можно, если сумма лежит там же где и количество.
Но выигрыш будет не за счет отсутствия расчета суммы - быструю проверку количества несложно сделать и по первому варианту.
Мне вообще сложно сказать, какой мы получаем выигрыш по времени блокировки между первым и вторым вариантом. Не похоже, что большой. Скорее просто получаем выигрыш в удобстве наложения управляемой блокировки и в удобстве проверки остатков.

так у тебя же 2 записи будут.
одна явно лишняя

(8) Во 2-ом варианте - контроль оперативных остатков.

(8) В 1-ом - на дату документа.

(10) Что мешает его сделать в первом? Блокируешь, читаешь опер-остатки, прикидываешь их к табличной части (времени фактически не займет). Фактически тоже самое. Проигрыш номинальный.

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

(13) почему это не войдет?

(14) Дык потому что записи не будет :) Залочили, глянули на остатки - опа, остатков не хватит. Все, в регистр ничего не пишем, сразу откатываемся.

(10, 11) имхо, это зависит от первого параметра таблицы отстатков (неопределено либо граница по моменту), от варианта не зависит никак.

(15) Звучит разумно, а как думаете уважаемые коллеги, база должна проектироваться на фиксацию транзакций или на откаты?
Я так думаю в 98% случаев или выше все таки фиксации. Вообще, это я к выходным спросил на "подумать".

Как думаете, может голосование откроем? "фиксации VS откаты" ?

(16) Конечно на фиксацию. Что за странный вопрос? Оптимизироваться должно то, что работает 99% времени, а не 1%.

оптимизация имеет смысл,если на каждую строку с товаром отдельную транзакцию,тогда будет высокая параллельность и простота блокировки,но 1с не умеет так штатно.
и потом,что делать с предыдущими строками,если что-тотв середине отррцательно.
в других системах вполне списывается только то,что есть и показывается пользователю чего не хватает.

Недавно было интересное обсуждение по схожей тематике. Почему после записи можно делать только ОПЕРАТИВНЫЙ контроль остатков. В противном случае при конкурентном расчете на момент времени возможна ситуация, когда первее проведется документ, которому будет назначено более позднее время (и результатом будет уход "в минуса"). И более того, при любом конкурентном проведении новых документов с расчетами на момент времени документа возможна такая ситуация, если документы по-разному тупили в ПередЗаписью.

(18) Неимоверная глупость

Кто мешает сделать запрос перед транзакцией и если остатков хватает то снова провести и после снова сделать запрос остатков и сверить что начальные до и конечные после бьются с нашими что проводили и никто не влез в транзакцию?

(21) *и если остатков хватает то провести и

(21) А в чем смысл двойного запроса к остаткам? Раннее падение, если остатков не хватает? Так это та самая оптимизация 1% случаев. А в 99% случаев эта проверка просто увеличит время проведения.

(0) "Почему при использовании 2го метода нельзя выполнить проведение так же и по сумме?" // Потому что для этого тебе придется либо дважды писать в регистр, либо заблокировать запись в него до собственно записи, что нивелирует новый подход

Если расчет сумм не зависит от состояния базы на момент проведения, то конечно пиши сразу.
Только он всегда зависит - не говоря о партиях - даже при какой-нибудь средневзвещенной / среднескользящей.