По моему проверять остатки только в процедуре при записи не Гут. Есть куча ситуаций, когда остатки надо проверять именно при проведении.
Ситуации которые сразу пришли в голову:
1. Выписка счетов с бронированием того товара, который есть на текущий момент на складе.
2. При использовании серого учета, накладная проводится только по упр. плану счетов, если офиц. товара не хватает, она все равно проводится - делаем движения (что надо купить) и т.д.

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

Z1 писал(а) 10. Декабря 2008 :: 08:58:

Перечитал еще раз. Есть мнение, что мы друг друга не поняли.
При заходе в процедуру ПриЗаписи() конечно же нет еще транзакции, она открывается при записи документа.

По поводу УРБД - всем переферийным базам выделяем свои склады с которыми они работают, проблему с минусами почти решает.

По поводу проверки остатков в процедуре приЗаписи() - однозначно транзакцию по времени сократит.
Огромный минус в таком варианте - это нервы работников и программистов (я в основном жалею себя), документ на 100 строк - чего-то не хватает - он не записывается, по тому, что нет остатка. Яду выплеснут... Карма страдает

Время есть, можно пообсуждать

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

Теперь дальше, ты предлагаешь считать записанный документ правильным и всем записанным документам должно хватать товара (если я правильно понял). Но как определять свободный остаток при работе задним числом или в случаях, когда единовременно имеется несколько записанных правильных документов, но они еще не проведены? Брать остатки из регистра и суммировать с итогами по табличным частям документов? Или в твоей концепции не должно быть в базе вообще никогда записанных и непроведенных документов?

В динамике:
0. Нажали кнопку Провести (#Записать #Провести);
1. Запись документа;
1.1. Попали в ПриЗаписи();
1.2. Проверили свободный остаток (при помощи пользовательской блокировки) - хватает;
1.3. Вышли из ПриЗаписи();
1.4. Открывается неявная транзакция;
1.5. Записывается документ;
1.6. Фиксируется неявная транзакция;
2. Проведение документа;
2.1. Открывается неявная транзакция;
2.2. Попали в ОбработкаПроведения();
2.3. Выполнили движения регистров на основании данных табличной части документа;
2.4. Вышли из ОбработкаПроведения();
2.5. Фиксируется неявная транзакция;

Для твоей концепции узким местом будет огромный промежуток времени между 1.6 и 2.1:
- документ записался, транзакция зафиксировалась, все блокировки сняты (здесь закончился п. 1.6);
- здесь попадаем в промежуток времени, когда другие пользователи (при интенсивной работе) могут вклиниться (т.е. между 1.6 и 2.1) со своими проверками в ПриЗаписи();
- начался п. 2.1 ...
- ...
- ...

Про "дорогие транзакции": в нашей работе (1с) они редко, когда являются дорогими. Объемы изменяемых данных при записи/проведении документов незначительные. В случае отката транзакции все не очень страшно. А вот когда нужно откатить транзакцию с таблицы в 40 с лишним лямов строк, то вот это "дорогая транзакция"  

spock писал(а) 11. Декабря 2008 :: 06:29:

У нас 20 складов и значит для моей конфигурации это будет хорошо

Опять же если где то разрешено работать задним числом с документами меняющие складские остатки то и изменение приходных накладных ( в приходе уменьшили количество со 100
до 10 ) может привести к минусам остатков - все ли поверяют такую ситуацию ?

Z1 писал(а) 11. Декабря 2008 :: 06:53:

COMMIT TRAN