1с режим блокировки управляемый и автоматический. Управление транзакционными блокировками. Основные причины перехода на управляемые блокировки

Сегодня речь пойдет о блокировках как на уровне 1С 8.3 и 8.2, так и на уровне СУБД. Блокировка данных — обязательный элемент любой системы, количество пользователей в которой больше одного.

Ниже я распишу, как работают блокировки, и каких типов они бывают.

Блокировка — это информация о том, что ресурс системы захвачен другим пользователем. Бытует мнение, что блокировка — это ошибка. Нет, блокировка — это неизбежная мера в многопользовательской системе для разделения ресурсов.

Вред системе могут принести только избыточные («лишние») блокировки, это те блокировки, которые блокируют лишнюю информацию. Такие блокировки необходимо научиться устранять, они могут привести к неоптимальной работе системы.

Блокировки в 1С делятся условно на объектные и транзакционные.

Объектные бывают, в свою очередь, оптимистическими и пессимистическими. А транзакционные можно разделить на управляемые и автоматические.

Объектные блокировки 1С

Данный вид блокировок полностью реализован на уровне платформы 1С и никак не затрагивает СУБД.

Получите 267 видеоуроков по 1С бесплатно:

Пессимистические блокировки

Эта блокировка срабатывает, когда один пользователь что-то изменил в форме справочника, а второй пытается так же изменить объект в форме.

Оптимистические блокировки

Данная блокировка сравнивает версии объекта: если два пользователя открыли форму, и один из них изменил и записал объект, то второму при записи система выдаст ошибку, что версии объектов отличаются.

Транзакционные блокировки 1С

Механизм тразакционных блокировок 1С гораздо интереснее и более функционален, чем механизм объектных блокировок. В этом механизме активно участвуют блокировки на уровне СУБД.

Неверная работа транзакционных блокировок может привести с следующим проблемам:

• проблема потерянного изменения;
• проблема грязного чтения;
• неповторяемость чтения;
• чтение фантомов.

Подробно эти проблемы были рассмотрены в статье об .

Автоматические транзакционные блокировки 1С и СУБД

В автоматическом режиме работы за блокировки целиком и полностью отвечает СУБД. Разработчик в данном случае абсолютно не участвует в процессе. Это облегчает труд программиста 1С, однако создание информационной системы для большого количества пользователей на автоматических блокировках нежелательно (особенно для СУБД PostgreSQL, Oracle BD — при модификации данных они полностью блокируют таблицу).

Для разных СУБД в автоматическом режиме используются разные степени изоляции:

• SERIALIZABLE на всю таблицу – файловый режим 1С, Oracle;
• SERIALIZABLE на записи – MS SQL, IBM DB2 при работе с не объектными сущностями;
• REPEATABLE READ на записи – MS SQL, IBM DB2 при работе с объектными сущностями.

Управляемые режим транзакционных блокировок 1С и СУБД

В всю ответственность на себя берет разработчик прикладного решения на уровне 1С. При этом СУБД устанавливает достаточно высокий уровень изоляции для транзакций — READ COMMITED (SERIALIZABLE для файловой СУБД).

При выполнении любой операции с БД менеджер блокировок 1С анализирует возможность блокировки (захвата) ресурса. Блокировки одного и того же пользователя всегда совместимы.

Две блокировки НЕ совместимы, если: установлены разными пользователями, имеют несовместимые виды (исключительная/разделяемая) и установлены на один и тот же ресурс.

Физическая реализация блокировок в СУБД

Физически блокировки представляют собой таблицу, которая находится в БД под названием master. Сама таблица блокировок носит имя syslockinfo.

Таблица условно имеет четыре поля:

1. ИД блокирующей сессии SPID;
2. что именно заблокировано RES ID;
3. тип блокировки — S,U или X MODE (на самом деле в MS SQL их 22 типа, однако в связки с 1С используется только три);
4. состояние блокировки — может принимать значение GRANT (установлена) и WAIT (ожидает своей очереди).

Периодически приходиться разбираться в применении механизмов блокировок в тех или иных случаях для реализации различных задач. Хотя информации на эти темы достаточно много, она сильно разрознена и со временем начинает забываться тот ворох материала, который пришлось перелопатить. Приходится разбираться заново…

В итоге, появилась идея структурировать и кратко изложить суть различных режимов блокировок в 1С в целом и применительно к типовым конфигурациям. Надеюсь, это будет полезно.

И так, поехали…

Сперва напишу про уровни изоляции транзакций, кратко рассмотрю только те уровни, которые имеют отношение к данной статье.

Уровни изоляции транзакций

Read committed (чтение завершенных) - разрешено чтение данных в транзакции, изменения по которым были завершены всеми остальными транзакциями. По умолчанию используется для большинства баз данных.

Read committed Snapshot (версионирование данных) - разрешено чтение старой версии данных, изменения по которым не завершены другими транзакциями. Штатно поддерживается базами данных: Postgre SQL и Oracle . Начиная с версии платформы 1С 8.3 реализован для работы с базами данных: MSSQL .

Repeatable read (повторяемое чтение) - запрет на изменение записей в транзакции, которые уже были считаны ранее в рамках остальных транзакций.

По поводу изоляции транзакций пока все, далее хочется сказать пару слов про механизм разделения итогов в регистрах накопления.

Разделение итогов регистров накопления

Регистр накопления на уровне базы данных состоит из двух таблиц: Основная таблица и Таблица итогов. Во время записи в регистр (как по приходу так и по расходу) происходит запись данных в обе таблицы, в основную таблицу записываются непосредственно данные, в таблице итогов обновляется итоговая строка по набору измерений регистра. Соответственно, при работе параллельных транзакций запись в таблицу итогов по одному набору измерений не может быть выполнена одновременно, что понижает скорость проведения документов.

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

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

Механизмы контроля остатков в типовых конфигурациях 1С

Старая схема, далее OLD - формируется запрос к базе данных для выполнения контроля свободных остатков, в случае положительного решения, формируется движение по регистру. На данный момент применяется в Бухгалтерии 3.0 и в некоторых алгоритмах УТ 11, КА 2, ЕРП 2.

Недостатки :

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

Новая схема, далее NEW - выполняется движение по регистру, затем проверяется наличие отрицательных остатков, в случае их наличия, операция откатывается. На данный момент применяется в УТ 11, КА 2, ЕРП 2.

Преимущества:

• не нужно удалять движения документа отдельной операцией, данные перезаписываются без предварительной записи пустых наборов. Это серьезно увеличивает скорость проведения документа.
• повышена скорость выполнения запроса к остаткам, так как в большинстве случаев, запрос после проведения выдает пустой результат.
• Нет необходимости предварительной блокировки изменяемых данных.

Недостатки :

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

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

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

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

Режим автоматических блокировок

В данном случае используется описанный выше режим изоляции транзакций: Repeatable read .

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

Для исключения взаимоблокировок при проведении документов с контролем остатков - OLD применяется конструкция языка запросов «ДЛЯ ИЗМЕНЕНИЯ », позволяющая при первом чтении данных в транзакции наложить на эти данные не разделяемую блокировку на чтение, а блокировку обновления. Соответственно, в другой транзакции уже будет невозможно выполнить подобную процедуру, так как наложить на одни и те же данные две блокировки обновления из разных транзакций нельзя .

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

Примечание: В случае работы с файловой базой и с P postgre SQL , блокировка накладывается целиком на всю таблицу.

Пример:

ВЫБРАТЬ ОстаткиТоваров.Номенклатура, ОстаткиТоваров.КоличествоОстаток КАК Количество ИЗ РегистрНакопления.ОстаткиТоваров.Остатки КАК ОстаткиТоваров ДЛЯ ИЗМЕНЕНИЯ

Использовать режим контроля остатков - NEW совместно с автоматическим режимом блокировок имеет смысл только для регистров без разделения итогов, в этом случае, никаких дополнительных действий делать не нужно. При использовании регистров с разделением итогов может возникнуть d ea dlock на чтении данных, если запись в регистр производилась одновременно, и каким-то образом решить данную проблему не получится.

Режим управляемых блокировок

В данном случае, применяется режимы изоляции транзакций: Read committed и Read committed Snapshot .

OLD - разделяемая блокировка снимается после прочтения данных об остатках, поэтому, чтобы исключить возможность возникновения отрицательных остатков, необходимо выполнить блокировку необходимых записей в регистре явно до формирования запроса на получение остатков. Собственно, в этом и состоит принцип управляемого режима блокировок.

Пример:

БлокировкаДанных = Новый БлокировкаДанных; ЭлементБлокировки = БлокировкаДанных.Добавить("РегистрНакопления.ТоварыНаСкладах.НаборЗаписей"); ЭлементБлокировки.УстановитьЗначение("Склад", Склад); ЭлементБлокировки.УстановитьЗначение("Номенклатура", Номенклатура); ЭлементБлокировкиДанных.Режим = РежимБлокировкиДанных.Исключительный; БлокировкаДанных.Заблокировать();

Использование режима контроля остатков NEW :

В случае использования регистров без разделения итогов дополнительные блокировки к наложенными базой данных не нужны, СУБД сама заблокирует необходимые данные (в данном случае записи в таблице итогов регистра накопления).

В случае использования регистров накопления с разделением итогов (по умолчанию к конфигураторе создаются регистры именно с данным флагом) можно получить следующие негативные ситуации:

• Без режима версионирования (MS SQL и 1С 8.2) - получим взаимоблокировку при попытке чтения данных, если запись в двух транзакциях была выполнена одновременно. При записи данных блокировка не будет возникать, так как используются разные строки СУБД (разделение итогов)
• С режимом версионирования Snapshot (postgresql, oracle или 1С 8.3) - блокировка возникать не будет, но будут появляться отрицательные остатки, так как контроль будет выполнен без учета всех не завершенных транзакций.

Для исключения подобной ситуации необходимо перед записью в регистр установить флаг набора записей: БЛОКИРОВАТЬ ДЛЯ ИЗМЕНЕНИЯ . Данная конструкция дает команду при записи накладывать исключительную блокировку на записи таблицы остатков регистра без учета разделителя итогов, по своей сути, она просто напросто временно отключает разделение итогов для регистра накопления.

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

Пример:

НаборЗаписей. БлокироватьДляИзменения = Истина;

Надеюсь, данная статья была полезной, и после ее прочтения создается более целостное понимание работы платформы 1С при различных режимах блокировок, используя разные механизмы контроля остатков.

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

Отдельное огромное спасибо, если отметите статью звездочкой, так как не что так не мотивирует на написание новых статей, как Ваше одобрение J

Для внедренцев, которые работают с типовыми или собственными конфигурациями – и тех, кто готовится к Аттестации на 1С:Специалист по платформе.

В статье мы разберем:

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

Время на прочтение – 20 минут.

Итак, две методики контроля остатков в 1С:Предприятии 8.3

Давайте начнем с того, что обозначения “старая методика” и “новая методика” достаточно условны. В самом деле, если “новая методика” используется с 2010 года – она уже не очень новая:)

Однако, мы еще раз вынуждены на этом остановиться, потому что различать эти подходы нужно и это имеет критическое значение .

“Старая методика” – это подход к контролю остатков, который использовался со времен «1С:Предприятие 8.0».

C 2010 года, с развитием платформы и добавлением новых возможностей с «1С:Предприятие 8.2» – применяется “новая методика” (однако – не везде ).

В чем разница?

Принципиальная разница – в моменте контроля остатков:

• В “старой” методике остатки контролируются ДО записи движений в регистры.
  Сначала проверяем остатки, если остатков “не хватает” (будут возникать отрицательные остатки) – проводить документ не будем
• В “новой” методике – контроль происходит ПОСЛЕ записи движений, то есть постфактум.
  Если после проведения образовались отрицательные остатки – нужно «откатить» транзакцию, то есть отменить проведение документа.

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

Ok, значит, старая методика ушла в прошлое и это удел УТ 10.3?

Нет, это не совсем так.

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

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

Поэтому новая методика может успешно применяться в случае, если данные по количеству и себестоимости хранятся в отдельных регистрах.

Например, вот так:

Однако встречаются конфигурации, где и количество, и стоимость учитываются на одном регистре. И вот здесь-то обоснованно остается работать старая методика контроля остатков !

Вот пример одного регистра и для количества, и для себестоимости:

А что насчет типовых конфигураций? Там ведь только новая методика, верно?

Не всегда!

Вот, например, в «1C:Управление торговлей 11.3» есть 2 регистра:

При проведении документов отгрузки регистр «Себестоимость товаров» не заполняется вообще. Данные в этот регистр попадают только при выполнении регламентных операций по закрытию месяца.

В УТ 11 используется новая методика , так как все данные для проведения документов можно получить, не обращаясь к контролируемым регистрам.

Что касается «1C:Бухгалтерии», то там и количество, и себестоимость хранятся в одном регистре бухгалтерии, на соответствующих счетах БУ.

Поэтому в БП 3.0 используется старая методика .

Обратите внимание, что количественный и стоимостной учет в УТ 11 ведутся с разной аналитикой. Например, себестоимость дополнительно ведется в разрезе организации, подразделения, менеджера, виды деятельности НДС и так далее.

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

Про оперативное проведение документов

В этом простом вопросе часто встречаются заблуждения.

Иногда считают, что оперативное проведение – это контроль остатков по новой методике. Это не так, от слова «совсем».

Оперативное проведение можно анализировать при контроле остатков, но не обязательно.

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

Настраивается оно с помощью специального свойства документа:

Что значит «регистрировать здесь и сейчас»? Платформа для оперативно проводимых документов выполняет ряд действий:

• Документам, проводимым сегодня, присваивается текущее время
• Если два документа проводятся одновременно, каждый будет иметь свое время (то есть система разнесет документы по разным секундам)
• Документы нельзя будет провести будущей датой.

Но главное другое – система передает признак оперативности проведения документа в обработку проведения:

Для оперативно проводимых документов можно не указывать параметр в запросе, будут получаться актуальные остатки на 31.12.3999 год:

Актуальные остатки хранятся в системе и получаются максимально быстро (остатки на другие даты в большинстве случаев получаются расчетным путем).

Таким образом оперативное проведение можно принять и для старой, и для новой методики контроля остатков .

Интересный факт.

В УТ 11 документам, списывающим номенклатуру, запрещено проводиться оперативно. Например, это документы «Реализация товаров и услуг», «Сборка товаров», «Перемещение товаров», «Внутреннее потребление товаров» и другие.

Почему так сделано?

В системе контроль остатков всегда выполняется на актуальный момент времени (параметр Период в запросе не задается). А отсутствие оперативного проведения позволяет вводить документы будущим числом, такая задача часто требуется клиентам.

Контроль остатков по новой методике – без блокировок

Коротко рассмотрим алгоритм контроля остатков при проведении документа «Реализация товаров и услуг» на модельной конфигурации.

Есть два регистра:

• Свободные остатки – для количественного учета
• Себестоимость товаров – для учета себестоимости

Для контроля остатков товаров достаточно работы с регистром «Свободные остатки».

Код обработки проведения будет выглядеть таким образом:

Запрос = Новый Запрос;

#Область Область1
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
#КонецОбласти

#Область Область2
Запрос.Текст =
"ВЫБРАТЬ

|ПОМЕСТИТЬ ТоварыДокумента
|ИЗ
|ГДЕ
|
|СГРУППИРОВАТЬ ПО
|
|ИНДЕКСИРОВАТЬ ПО
| Номенклатура
|;

|ВЫБРАТЬ
| &Дата КАК Период,
| ЗНАЧЕНИЕ(ВидДвиженияНакопления.Расход) КАК ВидДвижения,
| ТоварыДокумента.Количество КАК Количество
|ИЗ
";
Запрос.УстановитьПараметр("Дата", Дата);
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
Движения.Записать();
#КонецОбласти

#Область Область5
Запрос.Текст =
"ВЫБРАТЬ
| -СвободныеОстаткиОстатки.КоличествоОстаток КАК Дефицит
|ИЗ
| ТоварыДокумента КАК ТоварыДокумента
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.СвободныеОстатки.Остатки(
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| ТоварыДокумента.Номенклатура КАК Номенклатура
| ИЗ
| ТоварыДокумента КАК ТоварыДокумента)) КАК СвободныеОстаткиОстатки
| ПО ТоварыДокумента.Номенклатура = СвободныеОстаткиОстатки.Номенклатура
|ГДЕ
| СвободныеОстаткиОстатки.КоличествоОстаток < 0";
#КонецОбласти

#Область Область6
МоментКонтроляОстатков =
?(Режим = РежимПроведенияДокумента.Оперативный,
Неопределено,
Новый Граница(МоментВремени(), ВидГраницы.Включая));
Запрос.УстановитьПараметр("МоментВремени", МоментКонтроляОстатков);
РезультатЗапроса = Запрос.Выполнить();
#КонецОбласти

#Область Область7
Если НЕ РезультатЗапроса.Пустой() Тогда
Отказ = Истина;
ВыборкаОшибки = РезультатЗапроса.Выбрать();
Пока ВыборкаОшибки.Следующий() Цикл
Сообщение.Текст = "Недостаточно товара в количестве: "+ВыборкаОшибки.Дефицит;
Сообщение.Поле = "Товары["+(ВыборкаОшибки.НомерСтроки-1)+"].Количество";
Сообщение.Сообщить();
КонецЦикла;
КонецЕсли;
#КонецОбласти

#Область Область8
Если Отказ Тогда
Возврат;
КонецЕсли;
#КонецОбласти

КонецПроцедуры

Рассмотрим ключевые точки алгоритма контроля остатков.

1. Инициализация менеджера временных таблиц

Менеджер будет необходим, чтобы созданная в запросе временная таблица была доступна и в следующих запросах.

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

2. Запрос, группирующий данные табличной части

В запросе выбираются сгруппированные данные табличной части.

Обратите внимание, что выбирается и номер строки документа – он потребуется для контекстной привязки сообщения об ошибке. Для номера строки используется агрегатная функция МИНИМУМ() – то есть сообщение будет привязано к первой строке, где встречается указанная номенклатура.

В первом запросе пакета создается временная таблица. Во втором запросе выбираются данные временной таблицы и добавляются 2 поля, необходимые для каждой записи регистра – Период и ВидДвижения.

Плюсы такого подхода:

• Не нужно выполнять предварительную очистку, то есть использовать метод Очистить()
• Не нужно организовывать цикл по выборке или табличной части.

Кстати, подобный подход используется в типовых конфигурациях, в частности, в УТ 11 и БП 3.0.

4. Запись движений в БД

Запись можно было бы выполнить одной командой (вместо двух) – Движения.СвободныеОстатки.Записать().

И в нашем случае, когда записывается один регистр, разницы не будет никакой.

Но более универсальным является такой подход:

• Вначале установить флаг Записывать у необходимых наборов записей регистров
• Затем вызывать метод Записать() коллекции Движения, который записывает в БД все наборы с установленным флагом Записывать

После выполнения команды «Движения.Записать()» флаг Записывать у всех наборов сбросится в Ложь.

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

В типовых решениях используется подобная схема для записи движений. Почему?

Метод Записать() коллекции Движения записывает наборы записей в одинаковой последовательности даже для разных документов.

Запись же движений вручную может привести к проблемам.

Приведем пример.

Если в документе «Реализация» выполнить запись так:

Движения.СвободныеОстатки.Записать();
...
Движения.СебестоимостьТоваров.Записать();

А в документе «Перемещение товаров» изменить порядок:

Движения. СебестоимостьТоваров.Записать();
...
Движения. СвободныеОстатки.Записать();

То это может привести к взаимоблокировке документов на пересекающихся наборах номенклатуры.

Приведенный подход записи движений можно использовать, если указано соответствующее значение записи движений в свойствах документа:

5. Запрос, получающий отрицательные остатки

В запросе выбираются отрицательные остатки по номенклатуре из документа.

Отрицательный остаток – это и есть нехватка (дефицит) товара.

Соединение с товарами из документа выполняется только для получения номера строки.

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

6. Определение момента времени для контроля остатков

Вот здесь нам пригодилось оперативное проведение.

Если документ проводится оперативно, то момент для получения остатков – Неопределено, что означает получение актуальных остатков.

Если это неоперативное проведение, то мы получаем момент времени «после» документа – чтобы учесть только что сделанные движения.

Напомним, что получение актуальных остатков – быстрая операция по сравнению с получением остатков на произвольным момент времени.

Именно в этом и заключается выигрыш оперативно проводимых документов.

7. Если запрос не пустой, значит, образовались отрицательные остатки

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

Вот так будет выглядеть диагностическое сообщение:

8. Если есть ошибки, то возвращаемся из обработчика события

Если была хоть одна ошибка – выходим из процедуры.

Поскольку нет смысла продолжать проведение, транзакция всё равно не будет зафиксирована (а дальше у нас будет разработан код по списанию партий).

Реализация списания себестоимости по партиям

После того, как проверка остатков прошла успешно, можно приступать к списанию партий.

Код для списания по FIFO будет таким:

// I. Анализ смещения даты документа вперед

И НЕ ЭтотОбъект.ЭтоНовый()
И ЭтотОбъект.Проведен Тогда

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Документ.Дата КАК Дата
|ИЗ
|ГДЕ

РезультатЗапроса = Запрос.Выполнить();
ВыборкаДокумент.Следующий();

Иначе
Ложь);
КонецЕсли;

КонецПроцедуры

Процедура ПриЗаписи(Отказ)

ЭтотОбъект.ДополнительныеСвойства.Вставить("ДатаДокументаСдвинутаВперед",
ЭтотОбъект.Дата>

КонецЕсли;

КонецПроцедуры

Процедура ОбработкаПроведения(Отказ, Режим)

Запрос = Новый Запрос;

// 1. Инициализация менеджера временных таблиц
#Область Область1
...
#КонецОбласти

// 2. Запрос, группирующий данные табличной части
#Область Область2
...
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
...
#КонецОбласти

// 5. Запрос, получающий отрицательные остатки
#Область Область5
...
#КонецОбласти

// 6. Определение момента времени для контроля остатков
#Область Область6
...
#КонецОбласти

// 7. Если запрос не пустой, значит образовались отрицательные остатки
#Область Область7
...
#КонецОбласти

// 8. Если есть ошибки, то возвращаемся из обработчика события
#Область Область8
...
#КонецОбласти

// II. Подготовка наборов записей регистра "Себестоимость товаров"
#Область ОбластьII

Движения.Записать();
КонецЕсли;
Движения.СебестоимостьТоваров.Записывать = Истина;
#КонецОбласти

// III. Запрос получающий остатки партий для списания по FIFO
#Область ОбластьIII
Запрос.Текст =
"ВЫБРАТЬ
| ТоварыДокумента.Номенклатура КАК Номенклатура,
| ТоварыДокумента.НомерСтроки КАК НомерСтроки,

| Остатки.Партия КАК Партия
|ИЗ
| ТоварыДокумента КАК ТоварыДокумента
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| ИЗ

|УПОРЯДОЧИТЬ ПО
|ИТОГИ
| МАКСИМУМ(Количество),
| СУММА(КоличествоОстаток)
|ПО
| Номенклатура";
РезультатЗапроса = Запрос.Выполнить();
#КонецОбласти

// IV. Цикл по номенклатуре документа
#Область ОбластьIV

// V. Получим количество для списания
// VI. Цикл по партиям по FIFO
Пока ВыборкаПартии.Следующий() И ОсталосьСписать>0 Цикл
// VII. Проверка на нулевой остаток
Если ВыборкаПартии.КоличествоОстаток=0 Тогда
Продолжить;
КонецЕсли;
Движение.Период = Дата;

// VIII. Расчет количества и суммы для списания

// IX. Уменьшим количество для списания
КонецЦикла;
КонецЦикла;
#КонецОбласти

КонецПроцедуры

Разберем ключевые точки алгоритма списания партий по FIFO.

I. Анализ смещения даты документа вперед

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

Для анализа сдвига даты документа потребуется 2 события:

• Перед записью – для получения старой даты документа и проверки режима проведения документа
• При записи – для получения новой даты документа

Данные между событиями передаем через специальную коллекцию объекта – «ДополнительныеСвойства». Она существует пока текущая версия объекта находится в памяти, то есть доступна для всех событий при проведении.

Похожий прием используется в типовой «1С:Бухгалтерии 8». Но там используется одно событие «Перед записью».

Почему в БП не нужно задействовать «При записи»?

Всё просто – документы отгрузки в бухгалтерии не могут проводиться оперативно. А это значит, что время документа не будет принимать оперативную отметку (если документ перепроводится текущим днем), поэтому и старую и новую дату документа можно получить в событии «Перед записью».

II. Подготовка наборов записей регистра «Себестоимость товаров»

Для документа установлен режим удаления движений – “При отмене проведения”:

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

Приведем пример:

• Остаток мониторов LG на момент проведения документов – 10 шт.
• Проводится документ, который списывает 8 шт.
• В этом же документе время увеличивается на 1 минуту, перепроводим

Если не будет удаления старых движений, то система сообщит о нехватке 6 мониторов, поскольку текущие движения документа уже списали 8 из 10 имеющихся мониторов.

Примечание. Иногда встречается совет – удалять движения только при оперативном проведении.

Но это неправильно: ситуации изменения «неоперативных» документов (вчерашних и более ранних) они не учтут.

То есть проблема «нехватки 6 мониторов» (см. выше) будет в этом случае решена только для документов изменяемых сегодняшним числом.

III. Запрос, получающий остатки партий для списания по FIFO

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

На уровне итогов получается количество из документа – МАКСИМУМ(Количество) и остаток партии – СУММА(КоличествоОстаток).

Как Вы думаете, может ли количество из документа превышать суммарный остаток номенклатуры по всем партиям?

Если движения по регистрам “СвободныеОстатки” и “СебестоимостьТоваров” по количеству делаются синхронно (и приход, и расход), то такой ситуации возникнуть не может. На это мы и будем закладываться при списании партий.

IV. Цикл по номенклатуре документа

Благодаря итогам в запросе во внешнем цикле обходим номенклатуру из документа.

V. Получим количество для списания

Запомним, какое количество нужно списать. Далее это количество будет уменьшаться.

VI. Цикл по партиям по FIFO

Вложенный цикл будет содержать партии по текущей номенклатуре.

VII. Проверка на нулевой остаток

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

Поэтому принимаем решение, что такие ошибочные партии будем пропускать. При желании можно выдать диагностику пользователю.

VIII. Расчет количества и суммы для списания

Количество для списания - это минимальное значение между остатком партии и тем, что осталось списать.

Сумма рассчитывается элементарной пропорцией.

Если списывается весь остаток партии, то будет списана и вся сумма этой партии. Это математика 3-го класса церковно-приходской школы: Х*Y/X = Y:)

То есть НЕ нужно делать дополнительных проверок (иногда дают такой совет) на то, что списывается все количество. Этот совет даже имеет своё название – «проблема копеек ».

А тем, кто дает вредные советы имеет смысл заглянуть в конфигурацию «1С:Бухгалтерия 8». Там (о, ужас!) нет проверки на то, что списывается партия целиком:)

Вот скрин общего модуля «Учет товаров», метод «СписатьОстаткиТоваров»:

IX. Уменьшим количество для списания

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

Зачем нужны управляемые блокировки?

Вот мы и дошли до управляемых блокировок.

Казалось бы, представленные выше алгоритмы работают, как часы. Можете сами их потестировать (ссылки на выгрузки баз в конце статьи).

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

Приведем пример наиболее типичной проблемы при списании товара, когда 2 пользователя практически одновременно пытаются списать товар (оформить продажу):

В этом примере два пользователя почти одновременно проводят продажу товаров – документ №2 начал проводиться чуть позже документа 1.

При получении остатка система сообщает, что остаток 10 шт., и оба документа успешно проводятся. Печальный итог – на складе минус 5 мониторов LG.

Но при этом контроль остатков работает! То есть, если документ №2 будет проводиться после окончания проведения документа №1, система не проведет документ №2:

Иногда встречается заблуждение – «У меня в базе одновременно работают только 3-4 пользователя, вероятность параллельного проведения документов равна нулю, поэтому на блокировки можно не отвлекаться».

Это очень опасное рассуждение .

Даже, два пользователя могут проводить документы практически одновременно, например, если один из них выполняет групповое проведение документов.

Кроме этого, нельзя быть застрахованным от увеличения количества пользователей. Если бизнес пойдет «в гору», то нужны будут новые продажники, кладовщики, логисты и так далее. Поэтому нужно сразу создавать решения, которые будут устойчиво работать в многопользовательской среде.

Как решить проблему при параллельном проведении документов?

Решение простое – заблокировать мониторы LG в момент времени Т1, так чтобы другие транзакции не могли обратиться к остаткам по этому товару.

Тогда в момент времени Т2 система будет ждать, когда монитор LG будет разблокирован. И после этого система получит актуальный остаток товаров и будет выполнено (или не выполнено) списание товаров.

Буквально пару слов о классификации блокировок.

Существует 2 типа блокировок:

• Объектные
• Транзакционные .

Если говорить просто, то объектные блокировки не позволяют интерактивно изменить двум пользователям один объект (элемент справочника или документ).

А транзакционные блокировки позволяют программно оперировать актуальными данными при выполнении движений по регистрам.

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

Когда нужно накладывать блокировки?

Задача установки блокировок становится актуальной, как только в базе начинает работать более одного пользователя .

Блокировки нужно устанавливать в транзакциях, а когда возникают транзакции? Правильно, самый частый случай – проведение документов.

То есть блокировки нужно накладывать при проведении всех документов?

Ни в коем случае. Устанавливать блокировки «на всякий случай» точно не стоит . Ведь сами по себе блокировки снижают параллельность работы пользователей (масштабируемость системы).

Блокировки нужно накладывать на ресурсы (строки таблицы), которые читаются и изменяются в транзакциях. Например, при проведении документов.

В примере выше таким ресурсом является остаток по товару. Система должна была заблокировать остаток с момента получения данных об остатке (Т1) до окончания транзакции (Т3).

Примечание. Транзакция при проведении документа №1 начинается раньше, чем момент получения остатков. Но для простоты считаем, что Т1 – и время начала проведения документа, и момент получения остатков.

Пример, когда не нужно накладывать блокировку – проведение документа «Поступление товаров». В этом случае нет никакой конкуренции за ресурсы (остатки, …), поэтому блокировка будет вредна: она уменьшит масштабируемость системы.

Автоматические и управляемые блокировки

Здесь мы не будем вдаваться в теорию (это тема отдельной статьи), а скажем лишь, что управляемые блокировки являются более оптимальными.

Вместо теории можем привести пруф – все современные типовые конфигурации работают на управляемых блокировках.

Поэтому в нашей модельной конфигурации будет выбран соответствующий режим:

Управляемые блокировки в новой технологии контроля остатков

Блокировку будем накладывать на регистр “Свободные остатки” и только на номенклатурные позиции, встречающиеся в документе.

Причем правильный вариант наложения блокировки – как можно позднее.

В новой методике контроля остатков это нужно сделать перед записью (или в момент записи) движений в регистр “Свободные остатки”, чтобы другие транзакции не смогли изменить этот разделяемый ресурс.

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

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

Нужно просто установить свойство БлокироватьДляИзменения у набора записей регистра:

// 3.1. Блокировка остатков регистра
#Область Область3_1
Движения.СвободныеОстатки.БлокироватьДляИзменения = Истина;
#КонецОбласти

// 4. Запись движений в БД
#Область Область4
Движения.СвободныеОстатки.Записывать = Истина;
Движения.Записать();
#КонецОбласти
...

В результате 2 транзакции не смогут изменять свободные остатки по одной номенклатуре.

На самом деле при свойство БлокироватьДляИзменения не устанавливает управляемую блокировку , оно лишь выключает режим разделения итогов регистра при записи.

Но для нашей статье принципиально следующее – система установит блокировку на комбинацию записываемых в регистр данных. А детально работу свойства БлокироватьДляИзменения мы рассмотрим в отдельной статье.

Кстати, в типовой УТ 11 не так-то просто найти установку свойства БлокироватьДляИзменения для регистра “Свободные остатки”. Дело в том, что это выполняется в модуле набора записей регистра, в событии “Перед записью”.

Вот и всё, одной строкой кода была обеспечена корректная работа системы!

Важно . Мы не накладываем блокировку на регистр “Себестоимость товаров”.

Почему? Такая блокировка являлась бы излишней (а это определенная нагрузка на сервер 1С), поскольку движения в регистры “Свободные остатки” и “Себестоимость товаров” выполняются всегда синхронно, то есть последовательно друг за другом.

Поэтому, заблокировав товары из “Свободных остатков”, мы не допустим другие транзакции до этих товаров и в регистре “Себестоимость товаров”.

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

Старая методика контроля остатков

Напомним, что старая методика может применяться, если количество и стоимость учитываются в одном регистре.

Пусть это будет регистр “Себестоимость товаров”:

Тогда алгоритм проведения документа “Реализация товаров” будет выглядеть вот так:

// 1. Обработчик события "Перед записью"
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)

Если РежимЗаписи = РежимЗаписиДокумента.Проведение
И НЕ ЭтотОбъект.ЭтоНовый()
И ЭтотОбъект.Проведен Тогда

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Документ.Дата КАК Дата
|ИЗ
| Документ.РеализацияТоваровУслуг КАК Документ
|ГДЕ
| Документ.Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", ЭтотОбъект.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДокумент = РезультатЗапроса.Выбрать();
ВыборкаДокумент.Следующий();

ЭтотОбъект.ДополнительныеСвойства.Вставить("СтараяДатаДокумента", ВыборкаДокумент.Дата);

Иначе
КонецЕсли;

КонецПроцедуры

Процедура ПриЗаписи(Отказ)

Если НЕ ЭтотОбъект.ДополнительныеСвойства.Свойство("ДатаДокументаСдвинутаВперед") Тогда

ЭтотОбъект.ДополнительныеСвойства.Вставить("ДатаДокументаСдвинутаВперед",
ЭтотОбъект.Дата>ЭтотОбъект.ДополнительныеСвойства.СтараяДатаДокумента);

Сообщить(ЭтотОбъект.ДополнительныеСвойства.ДатаДокументаСдвинутаВперед);
КонецЕсли;

КонецПроцедуры

Процедура ОбработкаПроведения(Отказ, Режим)

// 2. Удаление "старых" движений документа
Если ДополнительныеСвойства.ДатаДокументаСдвинутаВперед Тогда
Движения.СебестоимостьТоваров.Записывать = Истина;
Движения.СебестоимостьТоваров.Очистить();
Движения.Записать();
КонецЕсли;

// 3. Установка флага для записи движений в конце транзакции
Движения.СебестоимостьТоваров.Записывать = Истина;

// 4. Запрос, получающий остатки по партиям на момент времени документа
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РеализацияТовары.Номенклатура КАК Номенклатура,
| СУММА(РеализацияТовары.Количество) КАК Количество,
| МИНИМУМ(РеализацияТовары.НомерСтроки) КАК НомерСтроки
|ПОМЕСТИТЬ ТоварыДокумента
|ИЗ
| Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТовары
|ГДЕ
| РеализацияТовары.Ссылка = &Ссылка
|СГРУППИРОВАТЬ ПО
| РеализацияТовары.Номенклатура
|ИНДЕКСИРОВАТЬ ПО
| Номенклатура
|;
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ТоварыДокумента.Номенклатура КАК Номенклатура,
| ТоварыДокумента.Количество КАК Количество,
| ТоварыДокумента.НомерСтроки КАК НомерСтроки,
| ЕСТЬNULL(Остатки.КоличествоОстаток, 0) КАК КоличествоОстаток,
| ЕСТЬNULL(Остатки.СуммаОстаток, 0) КАК СуммаОстаток,
| Остатки.Партия КАК Партия
|ИЗ
| ТоварыДокумента КАК ТоварыДокумента
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.СебестоимостьТоваров.Остатки(
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| Т.Номенклатура КАК Номенклатура
| ИЗ
| ТоварыДокумента КАК Т)) КАК Остатки
| ПО ТоварыДокумента.Номенклатура = Остатки.Номенклатура
|УПОРЯДОЧИТЬ ПО
| Остатки.Партия.МоментВремени
|ИТОГИ
| МАКСИМУМ(Количество),
| СУММА(КоличествоОстаток)
|ПО
| НомерСтроки";

Запрос.УстановитьПараметр("МоментВремени", МоментВремени());
Запрос.УстановитьПараметр("Ссылка", Ссылка);

РезультатЗапроса = Запрос.Выполнить();

ВыборкаНоменклатура = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);

// 5. Цикл по номенклатуре - проверяем достаточность количества для списания
Пока ВыборкаНоменклатура.Следующий() Цикл

ДефицитНоменклатуры = ВыборкаНоменклатура.Количество - ВыборкаНоменклатура.КоличествоОстаток;

Если ДефицитНоменклатуры>0 Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Недостаточно товара в количестве: "+ДефицитНоменклатуры;
Сообщение.Поле = "Товары["+(ВыборкаНоменклатура.НомерСтроки-1)+"].Количество";
Сообщение.УстановитьДанные(ЭтотОбъект);
Сообщение.Сообщить();
Отказ = Истина;
КонецЕсли;

Если Отказ Тогда
Продолжить;
КонецЕсли;

// 6. Получим количество для списания
ОсталосьСписать = ВыборкаНоменклатура.Количество;
ВыборкаПартии = ВыборкаНоменклатура.Выбрать();

// 7. Цикл по партиям
Пока ВыборкаПартии.Следующий() И ОсталосьСписать>0 Цикл

Движение = Движения.СебестоимостьТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Номенклатура = ВыборкаПартии.Номенклатура;
Движение.Партия = ВыборкаПартии.Партия;
// 9. Расчет количества для списания
Движение.Количество = Мин(ОсталосьСписать, ВыборкаПартии.КоличествоОстаток);
// 10. Расчет суммы списания
Движение.Сумма = Движение.Количество*
ВыборкаПартии.СуммаОстаток/ВыборкаПартии.КоличествоОстаток;

// 11. Уменьшим количество для списания
ОсталосьСписать = ОсталосьСписать - Движение.Количество;

КонецЦикла;
КонецЦикла;

Механизм транзакционных блокировок используется для конкурентного доступа пользователей к СУБД.
Транзакция - эта некая неразрывная операция, в ходе которой меняется состояние базы. Это минимальный квант изменений: нельзя сделать пол-транзакции; если транзакция не завершилась, то база откатится в начальное состояние.
Поскольку транзакция захватывает массив данных, возникает нюанс по доступу к этому массиву: например, одна транзакция меняет данные, а другая пробует их прочитать. Результат чтения может быть некорректным, т.к. не включит последних изменений. Поэтому, на уровне СУБД работает изоляция транзакций. Возможны следующие уровни изоляции:

• Read uncommited - пока одна транзакция меняет массив, другая не может его менять, но может читать. Низший уровень изоляции.
• Read commited - пока одна транзакция меняет массив, другая не может его ни менять, ни читать
• Repeatable read - пока одна транзакция читает массив, другая не может его менять, но может прочесть
• Serialaizable - пока одна транзакция читает массив, другая не может его ни менять, ни читать. Все операции последовательны. Максимальный уровень изоляции.

Если для конфигурации 1С:Предприятия установлен режим автоматических блокировок , то уровень изоляции транзакции выбирается СУБД. В случае с MS SQL, это будет Repeatable read или Serializable уровни, то есть изоляция данных близка к максимальной. Это решает проблемы с корректностью данных, но может приводить к появлению блокировок на уровне СУБД при интенсивной работе пользователей. Поэтому, в 1С:Предприятии есть свой функционал работы с блокировками, который активизируется включением режима управляемых блокировок. В этом случае уровень изоляции транзакций для MS SQL будет Read commited. Платформа сама будет изолировать данные, не полагаясь на СУБД.

Включение режима управляемых блокировок происходит в свойствах конфигурации:

Также, режим блокировок может быть установлен для конкретных объектов конфигурации:

В случае, если для конфигурации в целом установлен Автоматический режим блокировок, то все транзакции по всем регистрам будут работать именно в автоматическом режиме, безотносительно того режима, что выставлен для объекта конфигурации. Если Управляемый - то аналогично, все транзакции будут в управляемом. Если же для конфигурации выставлен режим Автоматический и управляемый, то режим для каждого объекта будет определяться его настройками.

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

1. Режим документа Автоматический, режим регистра Автоматический ->
2. Режим документа Управляемый, режим регистра Управляемый-> запись по регистру в управляемом режиме
3. Режим документа Автоматический, режим регистра Управляемый -> запись по регистру в автоматическом режиме
4. Режим документа Управляемый, режим регистра Автоматический -> исключительная ситуация (ошибка)

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

Правильный ответ второй, определяем по первой транзакции, если автоматическая, то все автоматически.

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

1. к возникновению ошибочной ситуации
2. вся транзакция будет выполнена в автоматическом режиме
3. вся транзакция будет выполнена в управляемом режиме

Правильный ответ первый, определяем по первой транзакции, если управляемая, то ошибка.

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

1. к возникновению ошибочной ситуации
2. вся транзакция будет выполнена в автоматическом режиме
3. вся транзакция будет выполнена в управляемом режиме

Ускорить 1С нажатием нескольких кнопок 2. Управляемые блокировки. September 4th, 2011

Если прочитать методику перевода конфигурации на управляемые блокировки от 1С - можно там найти много всего интересного и пугающего. На самом деле всё просто: В свойствах конфигурации меняете режим блокировки данных - "Управляемый". Всё. Могу вас поздравить - вы только что перешли на управляемые блокировки. На самом деле всё несколько сложнее - но не на много.

Для начала небольшой теоретический экскурс - зачем нужны блокировки: У кого есть доступ конечно можно прочитать здесь: http://kb.1c.ru/articleView.jsp?id=30 1С озаботились написать достаточно доступную статью про блокировки данных. У кого же доступа нет в двух словах опишу для чего нужны блокировки:

Пример 1. Если после включения управляемых блокировок ничего не делать, и при этом начать параллельно проводить 2 документа (один из них ведь всё равно на долю секунды раньше), то получим приблизительно следующую картину:

Теперь постараемся исправить ситуацию - в коде проведения документа пропишем установку эксклюзивной управляемой блокировки непосредственно перед чтением остатков:

Ну теперь, когда разобрались зачем блокировки нужны остаётся только установить управляемые блокировки там где это нужно: а именно - только там где производится контроль остатков. Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки? Можете их просто не устанавливать, или прописать и закомментировать до лучших времён. Если же у вас производится контроль остатков то как правило это 3-4 регистра, ну максимум 10-ок. Контроль можно подвесить как в общие процедуры и функции, так и в модули набора записей РН. Код предельно простой, открываем синтаксис помошник - смотрим:

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

Собственно всё сразу понятно - блокируем "товары на складх", 1 измерение становим в явном виде, значения 2-х других возьмём из источника данных - ТЧ документа.

Те кто читал книжки по 8.2 наверное помнят о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. Задвались вопросом зачем это? А вот эту же табличку перерисуем так что контоль остатков и блокировка будут после записи движений:

Зная для чего блокировки нужны можно действительно ими управлять исходя из бизнес задач которые вы решаете. СУБД разрабатываются исходя из предположения обеспечения максисальной защиты данных. В случае если вы, к примеру, осуществляете банковские транзакции блокировки должны быть везде и на максимальном уровне. Лучше заблокировать лишние записи, чем допустить противоречивость данных.

В случае же если вы продаёте булочки или шариковые ручки, на вряд ли вам нужно столь много блокировок. Браком и пересортом по человеческой вине вы теряете в сотни раз больше, чем могли бы в случае одновременного проведения двумя пользователеями двух одинаковых докуметов отгрузки.

Для варьирования между такими разными задачами в СУБД придумали уровни изоляции. Устанавливая уровень изоляции транзакций можно сказать СУБД какие блокировки накладывать в разных случаях (при записи и при чтении в транзакции) в разных случаях накладываются S (можно читать нельзя писать) или X (нельзя ни читать ни писать) блокировки.

Так в автоматическом режиме у вас почти всегда будет уровень изоляции SERIALIZABLE, который будет накладывать X блокировки где нужно и где не нужно, что будет существенно портить вам жизнь

А в управляемом у вас будет READ COMMITED, который будет накладывать и тут же снимать S блокировку при чтении, и X только при записи. Самый хитрый уровень. Быстро накладываемая S блокировка как раз позволяет проверить не наложена ли где на эти данные X блокировка, что и обеспечивает чтение только согласованных данных, как принято для данного уровня изоляции, а в случае если вы прочитали и выполнили действя, рекоммендованные в предыдущей статье, то не будет даже S блокировки при чтении, таким образом на уровне СУБД будет блокироваться только запись во время записи - что правильно и необходимо для сограсованности данных.

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