Имя: Пароль:
1C
1С v8
Методики контроля остатков при проведении (управляемые блокировки)
,
0 Gorr
 
31.01.20
11:23
Управляемые блокировки. Итак, есть две технологии:

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. фиксация транзакции.

При этом, преимущество второго метода над первым - как минимум сокращение времени транзакции за счет отсутствия расчета суммы списания в случае нехватки
1 Жан Пердежон
 
31.01.20
13:12
Почему нельзя, мешает кто-то?
2 Жан Пердежон
 
31.01.20
13:16
Сумма тут к блокировкам / контролю остатков отношения не имеет вообще никакого. Вопрос скорее методологии.
3 RomanYS
 
31.01.20
13:19
(2) Расчет суммы требует времени и удлиняет время блокировки. А идея как раз сократить это время
4 H A D G E H O G s
 
31.01.20
13:23
(3) Только если эти суммы беруться откуда -то из другого места. Иначе - ничего не удлиняет.
5 RomanYS
 
31.01.20
13:27
(4) "Расчет" вроде подразумевает, что этих сумм нет готовых.

(0) >> 4. расчет с установкой сумм того же набора (запрос)
Как правило суммовой учет идет в других регистрах.
6 Gorr
 
31.01.20
15:26
(5) в моем случае регистр тот же.
С ОУ не работал, но просто оставались сомнения, когда попросили сделать. Всем спасибо.
7 ptiz
 
31.01.20
15:32
(0) Второй вариант: сначала запись (с вытекающей из этого установкой блокировок), а потом получение сумм - не дает никакого выигрыша в скорости по сравнению с установкой блокировок сразу.
8 fisher
 
31.01.20
17:55
(0) Почему нельзя? Можно, если сумма лежит там же где и количество.
Но выигрыш будет не за счет отсутствия расчета суммы - быструю проверку количества несложно сделать и по первому варианту.
Мне вообще сложно сказать, какой мы получаем выигрыш по времени блокировки между первым и вторым вариантом. Не похоже, что большой. Скорее просто получаем выигрыш в удобстве наложения управляемой блокировки и в удобстве проверки остатков.
9 pechkin
 
31.01.20
17:57
так у тебя же 2 записи будут.
одна явно лишняя
10 H A D G E H O G s
 
31.01.20
17:57
(8) Во 2-ом варианте - контроль оперативных остатков.
11 H A D G E H O G s
 
31.01.20
17:57
(8) В 1-ом - на дату документа.
12 fisher
 
31.01.20
18:02
(10) Что мешает его сделать в первом? Блокируешь, читаешь опер-остатки, прикидываешь их к табличной части (времени фактически не займет). Фактически тоже самое. Проигрыш номинальный.
13 fisher
 
31.01.20
18:15
В пессимистическом случае вариант с предварительной блокировкой отработает даже быстрее, так как в общее время блокировки не войдет время записи. Но усложнять ради этого алгоритм проведения - овчинка выделки не стоит.
14 pechkin
 
31.01.20
18:17
(13) почему это не войдет?
15 fisher
 
31.01.20
18:20
(14) Дык потому что записи не будет :) Залочили, глянули на остатки - опа, остатков не хватит. Все, в регистр ничего не пишем, сразу откатываемся.
16 Gorr
 
31.01.20
18:37
(10, 11) имхо, это зависит от первого параметра таблицы отстатков (неопределено либо граница по моменту), от варианта не зависит никак.

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

Как думаете, может голосование откроем? "фиксации VS откаты" ?
17 fisher
 
31.01.20
18:38
(16) Конечно на фиксацию. Что за странный вопрос? Оптимизироваться должно то, что работает 99% времени, а не 1%.
18 Сияющий в темноте
 
31.01.20
18:44
оптимизация имеет смысл,если на каждую строку с товаром отдельную транзакцию,тогда будет высокая параллельность и простота блокировки,но 1с не умеет так штатно.
и потом,что делать с предыдущими строками,если что-тотв середине отррцательно.
в других системах вполне списывается только то,что есть и показывается пользователю чего не хватает.
19 fisher
 
31.01.20
18:46
Недавно было интересное обсуждение по схожей тематике. Почему после записи можно делать только ОПЕРАТИВНЫЙ контроль остатков. В противном случае при конкурентном расчете на момент времени возможна ситуация, когда первее проведется документ, которому будет назначено более позднее время (и результатом будет уход "в минуса"). И более того, при любом конкурентном проведении новых документов с расчетами на момент времени документа возможна такая ситуация, если документы по-разному тупили в ПередЗаписью.
20 H A D G E H O G s
 
31.01.20
19:27
(18) Неимоверная глупость
21 Garykom
 
гуру
31.01.20
20:14
Кто мешает сделать запрос перед транзакцией и если остатков хватает то снова провести и после снова сделать запрос остатков и сверить что начальные до и конечные после бьются с нашими что проводили и никто не влез в транзакцию?
22 Garykom
 
гуру
31.01.20
20:14
(21) *и если остатков хватает то провести и
23 fisher
 
03.02.20
10:18
(21) А в чем смысл двойного запроса к остаткам? Раннее падение, если остатков не хватает? Так это та самая оптимизация 1% случаев. А в 99% случаев эта проверка просто увеличит время проведения.
24 Cyberhawk
 
03.02.20
10:32
(0) "Почему при использовании 2го метода нельзя выполнить проведение так же и по сумме?" // Потому что для этого тебе придется либо дважды писать в регистр, либо заблокировать запись в него до собственно записи, что нивелирует новый подход
25 Cyberhawk
 
03.02.20
10:33
Если расчет сумм не зависит от состояния базы на момент проведения, то конечно пиши сразу.
Только он всегда зависит - не говоря о партиях - даже при какой-нибудь средневзвещенной / среднескользящей.