Методика оперативного проведения и управляемые блокировки
Разработка - Механизмы платформы 1С
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Введение.
Несмотря на то, что у меня уже есть статья, посвященная механизму оперативного проведения, очень часто, нет не так, очень-очень-очень часто спрашивают, что это такое.
Я подумал и решил написать ну очень-очень-очень подробную статью про методику оперативного проведения и управляемые блокировки. А без управляемых блокировок, собственно, методику использовать бессмысленно.
При написании статьи демопример я вводил на платформе 8.3.3.641. Всю задачу создавал на пустой базе.
Постановка задачи.
Необходимо автоматизировать две операции: покупка и продажа товаров. При продаже товаров необходимо контролировать наличие товаров в остатках предприятия и рассчитывать себестоимость списания товаров по методу FIFO.
Начнем...
Структура метаданных:
- Справочник: Товары
- Документы: Приходная и Расходная с табличными частями "Список товаров" (товар, количество, сумма).
- Регистры:
- ОстаткиТоваров, в регистре одно измерение: Товар, и один ресурс: Количество. Назначение регистра - быстрое принятие решения, можно ли проводить документ.
- СтоимостьТоваров, в регистре два измерения: Товар, Партия, и два ресурса: Количество, Стоимость. Назначение регистра: хранение информации о стоимости остатков товаров в разрезе партий.
Описывать проведение документа "Приходная" не буду, там все очевидно, все можно конструктором сделать.
В расходной опишем проведение по регистру ОстаткиТоваров...
Методика оперативного проведения.
Под термином "Методика оперативного проведения" я понимаю следующее: при проведении документа, вместо того, чтобы, сформировать запрос и понять хватает ли товаров или нет, мы сначала сформируем движения, а затем уже проверим, не ушли ли мы в минус? Подробнее с плюсами и минусами этой технологии можно познакомиться в моей прошлой статье.
Опишем формирование движений в документе "Расходная":
Процедура ОбработкаПроведения(Отказ, Режим)
//1
Движения.ОстаткиТоваров.Записывать = Истина;
//2
Движения.ОстаткиТоваров.Очистить();
Для каждого Стр Из СписокТоваров Цикл
Движение = Движения.ОстаткиТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Товар = Стр.Товар;
Движение.Количество = Стр.Количество;
КонецЦикла;
//3
КонецПроцедуры
Прокомментируем текст модуля:
1. Устанавливаем маркер необходимости записи движений. Это необходимо делать в том случае, если у документа установлено свойство "Записывать выбранные".

Что дает нам это свойство?
Интересную фишку, раньше мы могли принудительно записать движения документа (наборы данных), но при окончании транзакции проведения наборы данных записывались еще раз. Теперь мы вольны в выборе, что и когда нужно записывать. Маркер записи автоматически снимается при записи набора, тем самым, при окончании транзакции проведения, набор записей еще раз записываться не будет. К чему это приведет? Правильно, к уменьшению блокировок таблиц и к сокращению времени транзакций при проведении.
2. Очищаем движения. Зачем? Все дело в еще одном новом свойстве документов "Удалять движения".

При установленном свойстве "Удалять автоматически" в самом начале транзакции проведения система автоматически записывает пустые наборы записей в регистры, тем самым очищая старые движения. Это физически происходит, запись, со всеми вытекающими транзакциями и блокировками.
Для облегчения нагрузки на таблицы баз данных теперь есть возможность не очищать автоматом старые движения...
И тут обычно я слышу: "Так и всегда можно было "Не очищать автоматически"! Ага, можно было, но в каждом документе приходилось описывать очистку каждого набора записей при отмене проведения... Удобно...
Короче, 1С пошла на поводу у здравого смысла и сделала новое свойство "Удалять автоматически при отмене проведения", Это гарантирует нам, что все движения документа будут очищены в том случае если у документа отработает событие "ОтменаПроведения".
Теперь вопрос, а зачем мы в модуле написали "Очистить()", тут все дело в том, что теперь у нас движения автоматом не очищаются... НО! При работе с управляемыми формами копия объекта БД может не загрузить старые движения, к примеру, зависит это и от свойства данных формы "Использовать всегда".

К примеру, в зависимости от этого свойства, движения документа будут прочитаны (если галка стоит) при открытии формы или нет. А если даже галка не установлена, и в форме отображаются движения, то движения будут прочитаны при открытии формы.
В обычных формах движения будут однозначно прочитаны при открытии формы.
А если движения прочитаны, то наборы записей в свойстве документа "Движения" не пустые, и добавление при проведении новых движений, как правило приводит к дублям движений.
Так вот, чтобы не зависеть от обстоятельств, мы на всякий случай удаляем то, что возможно может находиться в коллекции движений по регистру ОстаткиТоваров. Обращаю внимание, что запись данных в базу тут не производится, просто в памяти очищается набор записей.
Кстати, если свойство конфигурации "Основной режим запуска" будет установлено в значение "Обычное приложение", то такую строку "Движения.ИмяРегистра.Очистить()" будет писать и сам конструктор формирования движений.

3. Итак, движения сформировали, самое время их записать. Тут есть два варианта. либо Движения.Записать(); либо Движения.ОстаткиТоваров.Записать(); В чем разница и что выбрать?
Начнем с последнего: Движения.ОстаткиТоваров.Записать(); Этот способ безусловно запишет данные в регистр накопления. Но при этом флаг "Записывать" у набора записей снят не будет. Но это ерунда, главное тут то, что при большом количестве наборов записей у документа нам придется самостоятельно контролировать что в каком порядке в базу пишется, это может (да что там "может", точно скажется) негативно сказаться на проблеме взаимных блокировок (DeadLock), когда одна транзакция заблокирует таблицу А и будет ждать освобождения таблицы Б, а другая транзакция будет вести себя строго наоборот.
теперь посмотрим как работает метод Движения.Записать(); Метод записывает только те движения документа у которых установлен флаг "Записывать", при этом флаг в итоге снимается, что не приводит к повторной записи движений по окончании транзакции проведения. И главное, Движения.Записать(); всегда записывают движения в том порядке в котором таблицы указаны в дереве метаданных, что на порядок уменьшает шансы взаимных блокировок, ведь все транзакции в одинаковом порядке блокируют таблицы.
Теперь надеюсь очевидно, выбираем метод Движения.Записать();
Запишем движения и проверим остатки в регистре.
//3
Движения.Записать();
Запрос = Новый Запрос;
//4
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = "ВЫБРАТЬ
| Док.Товар КАК Товар,
| СУММА(Док.Количество) КАК Количество
|ПОМЕСТИТЬ ДокТЧ
|ИЗ
| Документ.Расходная.СписокТоваров КАК Док
|ГДЕ
| Док.Ссылка = &Ссылка
|
|СГРУППИРОВАТЬ ПО
| Док.Товар
|
|ИНДЕКСИРОВАТЬ ПО
| Товар
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| Остатки.Товар.Представление КАК ТоварПредставление,
| Остатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки(
| &ТочкаИтогов,
| Товар В
| (ВЫБРАТЬ
| ДокТЧ.Товар
| ИЗ
| ДокТЧ КАК ДокТЧ)) КАК Остатки
|ГДЕ
| Остатки.КоличествоОстаток < 0
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ДокТЧ.Товар
|ИЗ
| ДокТЧ КАК ДокТЧ";
Запрос.УстановитьПараметр("Ссылка", Ссылка);
//5
Запрос.УстановитьПараметр("ТочкаИтогов", Новый Граница(МоментВремени(), ВидГраницы.Включая));
ПакетРезультатов = Запрос.ВыполнитьПакет();
РезультатЗапроса = ПакетРезультатов[1];
Если НЕ РезультатЗапроса.Пустой() Тогда
//6
Отказ = Истина;
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Мало товара " + Выборка.ТоварПредставление + " нужно еще " + (-Выборка.КоличествоОстаток);
Сообщение.Сообщить();
КонецЦикла;
КонецЕсли;
Если Отказ Тогда
Возврат;
КонецЕсли;
Комментарии к модулю:
4. Привязываем к запросу менеджер временных таблиц. Это позволит использовать временные таблицы позже для проведения по регистру с партиями товаров.
В запросе выбираем из табличной части документа товары и количество, группируем все и индексируем по полю Товар. Это, в общем случае, благоприятно скажется на быстродействии запроса.
5. ТочкаИтогов, здесь мы используем объект Граница. Так как передав в запрос просто "МоментВремени()" мы получили бы остатки на начало проведения документа, то есть не включили бы в расчет итогов только что сформированные движения документа. А нам нужно понять, что произошло с итогами после проведения документа.
В целом все.
Мы используем новую методику проведения документа. Сначала записали данные в регистр, а потом через кэш транзакции смотрим не ушли ли мы в минус. Если ушли - транзакцию отказываем.
Но это далеко не все. Назревает вопрос о "грязном чтении".
Грязное чтение.
Что это такое?
Я не буду вдаваться в теорию (в отличии от вас, вам я советую в теорию копнуть, лишним не будет), поясню на примере:
Проводим две расходных. И в одной и в другой продаем 5 ложек. А в остатках всего 6. Так получилось, что продавать ложки мы умудрились в один и тот-же момент времени. Что произойдет?
Первая накладная сформирует движения и начнет читать запрос по остаткам через кэш собственной транзакции, что, собственно, будет делать и вторая накладная. Но ложек-то всего 6, а в сумме две накладные продадут 10... Потому-что не знают о том, что данные в таблицах уже не актуальны...
Что делать?
Надо заблокировать данные от параллельного чтения.
В нашем примере это сделать очень просто. У набора записей есть свойство "БлокироватьДляИзменения". Это, как и свойство "Записывать", лишь маркер указывающий, что необходимо установить блокировку на те записи, которые были сформированы в наборе записей.
Когда устанавливать свойство "БлокироватьДляИзменения"? Не важно, главное до самой записи данных.
Когда произойдет блокировка записей? В момент записи данных.
Что означает эта блокировка?
Никто параллельно с нами читать данные из регистра по тем товарам, движения по которым были сформированы, не сможет.
Когда блокировка будет снята?
При окончании транзакции в которой она началась, в нашем примере, при завершении проведения документа.
Установим блокировку:
//2
Движения.ОстаткиТоваров.Очистить();
Для каждого Стр Из СписокТоваров Цикл
Движение = Движения.ОстаткиТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Товар = Стр.Товар;
Движение.Количество = Стр.Количество;
КонецЦикла;
//7 Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;
//3
Движения.Записать();
Казалось бы все, а давайте проверим какие свойства нужно установить у объектов, для того, чтобы такая блокировка не просто работала, а еще и блокировала только те записи по которым были сформированы движения...
А. Свойство конфигурации "Режим управления блокировкой данных в транзакции" - если, "Управляемый", то все хорошо.
Если "Автоматический", то системе глубоко фиолетово на то что мы с вами написали. В нашем частном случае, блокировка в режиме "Автоматический" не будет установлена.
Если "и то и другое" то важно проверить настройки объектов. Помните, что вид транзакции наследуется всеми вложенными транзакциями. То есть если документ записывается в автоматической транзакции, а движения делает по регистрам с управляемой... То система немного расстроится и вывалится с ошибкой.
Б. Так как блокируем мы не весь регистр, за что нам отдельное спасибо, а только те данные по которым мы сформировали движения, за что спасибо ребятам из 1С, то важно установить свойство регистра "Разрешить разделение итогов".

Если разделение итогов не будет включено и в режиме пользователя, то в большей части случаев блокировка будет наложена на весь регистр с его таблицами.
Вот теперь точно с регистром "ОстаткиТоваров" все. Займемся себестоимостью.
Партионное списание.
При списании партий из регистра "СтоимостьТоваров" использовать методику оперативного проведения мы не можем. Почему? А для того, чтобы списать партии нужно узнать какие конкретно, то есть нам нужно сначала прочитать данные из регистра, а потом уже формировать движения.
Если Отказ Тогда
Возврат;
КонецЕсли;
//7
Запрос.Текст = "ВЫБРАТЬ
| ДокТЧ.Товар КАК Товар,
| ДокТЧ.Количество КАК Количество,
| СтоимостьТоваров.Партия,
| СтоимостьТоваров.КоличествоОстаток,
| СтоимостьТоваров.СтоимостьОстаток
|ИЗ
| ДокТЧ КАК ДокТЧ
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.СтоимостьТоваров.Остатки(
| &ТочкаИтоговДляСебестоимости,
| Товар В
| (ВЫБРАТЬ
| ДокТЧ.Товар
| ИЗ
| ДокТЧ КАК ДокТЧ)) КАК СтоимостьТоваров
| ПО ДокТЧ.Товар = СтоимостьТоваров.Товар
|
|УПОРЯДОЧИТЬ ПО
| СтоимостьТоваров.Партия.МоментВремени
|ИТОГИ
| МИНИМУМ(Количество)
|ПО
| Товар";
//8
Запрос.УстановитьПараметр("ТочкаИтоговДляСебестоимости", МоментВремени());
//9
Движения.СтоимостьТоваров.Очистить();
//10
РезультатЗапроса = Запрос.Выполнить();
ВыборкаТовар = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);
Пока ВыборкаТовар.Следующий() Цикл
ОсталосьСписать = ВыборкаТовар.Количество;
ВыборкаПартия = ВыборкаТовар.Выбрать();
Пока ВыборкаПартия.Следующий() И ОсталосьСписать <> 0 Цикл
Списать = МИН(ОсталосьСписать, ВыборкаПартия.КоличествоОстаток);
Движение = Движения.СтоимостьТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Товар = ВыборкаПартия.Товар;
Движение.Партия = ВыборкаПартия.Партия;
Движение.Количество = Списать;
Движение.Стоимость = Списать / ВыборкаПартия.КоличествоОстаток * ВыборкаПартия.СтоимостьОстаток;
ОсталосьСписать = ОсталосьСписать - Списать;
КонецЦикла;
КонецЦикла;
//11
Движения.СтоимостьТоваров.Записывать = Истина;
Комментарии к модулю:
7. После проверки будем ли мы проводить документ, описываем новый текст запроса. Новый объект запрос создавать нет смысла, будем использовать уже существующий, кроме всего к нему уже подключен менеджер временных таблиц в котором содержится проиндексированная таблица ДокТЧ.
8. Устанавливаем МоментВремени() как точку расчета итогов таблицы остатков. Как было описано выше, по умолчанию эта точка (то бишь старые движения, которые мог бы сформировать этот документ) в расчет итогов не попадут. Но тут есть одна хитрость к которой мы вернемся немного позже.
9. На всякий случай очистим движения документа, вдруг они были прочитаны.
10. Опишем списание по партиям.
11. Установим маркер необходимости записи данных по регистру "СтоимостьТоваров".
Когда транзакция проведения будет завершена система самостоятельно запишет движения в базу.
Почти все, остались блокировки.
Управляемые блокировки.
По регистру "СтоимостьТоваров" воспользоваться флагом "БлокироватьДляИзменения" нам не удастся. Почему? Да потому-что блокировка с этим флагом происходит в момент записи данных набора записей, а нам блокировку нужно установить еще перед запросом, дабы не допустить параллельного чтения данных.
По этому, для установки блокировки будем использовать объект "БлокировкаДанных".
Объект "БлокировкаДанных" представляет таблицу, каждая строка которой описывает что и где нужно заблокировать.
Если Отказ Тогда
Возврат;
КонецЕсли;
//12
Блокировка = Новый БлокировкаДанных;
//13
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.СтоимостьТоваров");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
//14
ЭлементБлокировки.ИсточникДанных = ПакетРезультатов[2];
//15
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Товар", "Товар");
Блокировка.Заблокировать();
//7
Запрос.Текст = "ВЫБРАТЬ
Перед нашим вторым текстом запроса опишем блокировку.
12. Создаем объект.
13. Добавляем в объект новую строку с описанием блокируемой таблицы.
14. Для того чтобы не блокировать весь регистр, установим фильтр по товарам, данные о том по каким товарам необходимо заблокировать таблицы хранятся у нас в результате первого запроса, из пакета результатов достаем последний. Можно было и саму табличную часть документа привязать к источнику данных, но тогда система еще раз строила бы запрос к табличной части документа, а так мы все данные уже получили, сгруппировали.
15. Так как в результате запроса поле содержащее список с товарами может называться не так как поле в регистре, описываем соответствие.
Установили блокировку. Теперь параллельно с нами никто не прочитает остатки по указанным товарам из регистра "СтоимостьТоваров". Обращаю внимание, так как мы не знаем заранее какие партии будут выбраны запросом, то фильтр по ним установить мы не можем и блокируем все партии. Чем меньше фильтров описано, тем больше данных блокируется.
И вот тут казалось бы все, а нет.
Проблема оперативного проведения.
Если сейчас попробовать провести документ оперативно 2 раза, указывая последние товары в регистре, то система вылетит с ошибкой. Почему?
При оперативном проведении, несмотря на то, что, мы указали в параметре второго запроса "МоментВремени()" и он вроде бы не должен включить старые движения документа, система рассчитает остатки на оперативную отметку времени, то есть старые движения будут включены в расчет итогов. Да, да... Вот такая "фишка".
Что делать? Отследим оперативное проведение и очистим старые движения.
Перед описание второго запроса вставим такой код:
//16
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.СтоимостьТоваров.Очистить();
//17
Движения.СтоимостьТоваров.БлокироватьДляИзменения = Истина;
Движения.СтоимостьТоваров.Записать();
КонецЕсли;
//7
Запрос.Текст = "ВЫБРАТЬ
16. Проверяем оперативно ли проводится документ.
17. Устанавливаем свойство "БлокироватьДляИзменения". Это позволит заблокировать от чтения те данные которые сейчас будут удалены из регистра, вдруг транзакция будет отменена, не хотим чтобы кто-либо вместе с нами работал с этими данными.
Подобное действие не помешает и при смене даты или времени документа, а не только при оперативном проведении.
Вот теперь все. Полный текст модуля документа "Расходная":
Процедура ОбработкаПроведения(Отказ, Режим)
//1
Движения.ОстаткиТоваров.Записывать = Истина;
//2
Движения.ОстаткиТоваров.Очистить();
Для каждого Стр Из СписокТоваров Цикл
Движение = Движения.ОстаткиТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Товар = Стр.Товар;
Движение.Количество = Стр.Количество;
КонецЦикла;
//7
Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;
//3
Движения.Записать();
Запрос = Новый Запрос;
//4
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = "ВЫБРАТЬ
| Док.Товар КАК Товар,
| СУММА(Док.Количество) КАК Количество
|ПОМЕСТИТЬ ДокТЧ
|ИЗ
| Документ.Расходная.СписокТоваров КАК Док
|ГДЕ
| Док.Ссылка = &Ссылка
|
|СГРУППИРОВАТЬ ПО
| Док.Товар
|
|ИНДЕКСИРОВАТЬ ПО
| Товар
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| Остатки.Товар.Представление КАК ТоварПредставление,
| Остатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки(
| &ТочкаИтогов,
| Товар В
| (ВЫБРАТЬ
| ДокТЧ.Товар
| ИЗ
| ДокТЧ КАК ДокТЧ)) КАК Остатки
|ГДЕ
| Остатки.КоличествоОстаток < 0
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ДокТЧ.Товар
|ИЗ
| ДокТЧ КАК ДокТЧ";
Запрос.УстановитьПараметр("Ссылка", Ссылка);
//5
Запрос.УстановитьПараметр("ТочкаИтогов", Новый Граница(МоментВремени(), ВидГраницы.Включая));
ПакетРезультатов = Запрос.ВыполнитьПакет();
РезультатЗапроса = ПакетРезультатов[1];
Если НЕ РезультатЗапроса.Пустой() Тогда
//6
Отказ = Истина;
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Мало товара " + Выборка.ТоварПредставление + " нужно еще " + (-Выборка.КоличествоОстаток);
Сообщение.Сообщить();
КонецЦикла;
КонецЕсли;
Если Отказ Тогда
Возврат;
КонецЕсли;
//12
Блокировка = Новый БлокировкаДанных;
//13
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.СтоимостьТоваров");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
//14
ЭлементБлокировки.ИсточникДанных = ПакетРезультатов[2];
//15
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Товар", "Товар");
Блокировка.Заблокировать();
//16
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.СтоимостьТоваров.Очистить();
//17
Движения.СтоимостьТоваров.БлокироватьДляИзменения = Истина;
движения.СтоимостьТоваров.Записать();
КонецЕсли;
//7
Запрос.Текст = "ВЫБРАТЬ
| ДокТЧ.Товар КАК Товар,
| ДокТЧ.Количество КАК Количество,
| СтоимостьТоваров.Партия,
| СтоимостьТоваров.КоличествоОстаток,
| СтоимостьТоваров.СтоимостьОстаток
|ИЗ
| ДокТЧ КАК ДокТЧ
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.СтоимостьТоваров.Остатки(
| &ТочкаИтоговДляСебестоимости,
| Товар В
| (ВЫБРАТЬ
| ДокТЧ.Товар
| ИЗ
| ДокТЧ КАК ДокТЧ)) КАК СтоимостьТоваров
| ПО ДокТЧ.Товар = СтоимостьТоваров.Товар
|
|УПОРЯДОЧИТЬ ПО
| СтоимостьТоваров.Партия.МоментВремени
|ИТОГИ
| МИНИМУМ(Количество)
|ПО
| Товар";
//8
Запрос.УстановитьПараметр("ТочкаИтоговДляСебестоимости", МоментВремени());
//9
Движения.СтоимостьТоваров.Очистить();
//10
РезультатЗапроса = Запрос.Выполнить();
ВыборкаТовар = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам);
Пока ВыборкаТовар.Следующий() Цикл
ОсталосьСписать = ВыборкаТовар.Количество;
ВыборкаПартия = ВыборкаТовар.Выбрать();
Пока ВыборкаПартия.Следующий() И ОсталосьСписать <> 0 Цикл
Списать = МИН(ОсталосьСписать, ВыборкаПартия.КоличествоОстаток);
Движение = Движения.СтоимостьТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Товар = ВыборкаПартия.Товар;
Движение.Партия = ВыборкаПартия.Партия;
Движение.Количество = Списать;
Движение.Стоимость = Списать / ВыборкаПартия.КоличествоОстаток * ВыборкаПартия.СтоимостьОстаток;
КонецЦикла;
КонецЦикла;
//11
Движения.СтоимостьТоваров.Записывать = Истина;
КонецПроцедуры
Надеюсь после этой статьи большая часть вопросов о "новой" методике проведения и о том почему нельзя повсеместно писать "БлокироватьДляИзменения = Истина" будут закрыты.
Актуальная версия статьи располагается тут.
Контакты автора на сайте chistov.pro
Готовое решение
ККТ-ОНЛАЙН 54-ФЗ: Обработка для работы онлайн касс АТОЛ, ШТРИХ, VIKI PRINT и т.д. МАРКИРОВКА (Разрешит. режим) + ЭКВАЙРИНГ + БЕСПЛАТНЫЙ ДЕМО
Универсальная обработка для фискальных регистраторов! Подключайте любые ККТ, включая Веб сервер АТОЛ, без обновления 1С и работайте с несколькими кассами одновременно. Тестовый доступ — бесплатно!
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Механизмы платформы 1С Разработчик Бесплатно (free)
Разберем 15 мифов о работе платформы «1С:Предприятие 8» – как распространенных, так и малоизвестных. Начнем с классики: «Код, написанный в одну строку, работает быстрее, чем многострочный». Так ли это на самом деле?
16.07.2025 45588 TitanLuchs 109
Работа с интерфейсом WEB-интеграция Механизмы платформы 1С Бесплатно (free)
Веб-интерфейсы повышают качество внешнего вида приложений 1С, предсказуемы с точки зрения верстки, позволяют организовать удобные и высокопроизводительные рабочие места для пользователей. Расскажем об особенностях разработки веб-интерфейсов на React внутри 1С, двустороннем взаимодействии 1С и JavaScript, а также сборке веб-приложения в одностраничный файл.
19.06.2025 18620 zeegin 15
Механизмы платформы 1С Работа с интерфейсом Разработчик Стажер 1С:Предприятие 8 Бесплатно (free)
Про ООП в 1С и о том, как сделать свой код более кратким и выразительным при помощи использования текучего интерфейса (fluent interface).
03.02.2025 25981 bayselonarrend 127
Механизмы платформы 1С Разработчик 1С:Предприятие 8 Бесплатно (free)
В этой статье подробно рассматривается работа с JSON в XDTO в 1С:Предприятие. Вы узнаете, как сериализовать и десериализовать объекты XDTO в JSON, интегрировать 1С с веб-сервисами и API, а также корректно обрабатывать данные при обмене. Разбираются особенности работы с коллекциями, использование функций восстановления и частые ошибки при работе с JSON и XDTO.
30.01.2025 33211 user2122906 10
Механизмы платформы 1С Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 8 Бесплатно (free)
Этот материал познакомит вас с механизмом XDTO (XML Data Transfer Objects) в 1С и научит эффективно использовать его возможности. Мы разберёмся, как работать с XML-схемами, создавать модели данных, манипулировать объектами XDTO, а также сериализовать и десериализовать их в XML. Вы узнаете, как использовать XDTO для интеграции с внешними системами, избегать типичных ошибок и оптимизировать код. К концу вы будете уверенно применять XDTO для решения сложных задач обмена данными и автоматизации процессов.
17.01.2025 55614 user2122906 13
Механизмы платформы 1С WEB-интеграция Разработчик 1С:Предприятие 8 Бесплатно (free)
В платформе 8.3.27 появилась возможность использовать WebSocket-клиент. Давайте посмотрим, как это все устроено и чем оно нам полезно.
14.01.2025 46726 dsdred 110
Механизмы платформы 1С Разработчик 1С:Предприятие 8 Бесплатно (free)
Особенности "Знач" и разбор документации к нему.
10.01.2025 26409 VAAngelov 60
Механизмы платформы 1С Разработчик Стажер 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Эта небольшая статья - некоторого рода шпаргалка по файловым потокам: как и зачем с ними работать, какие преимущества это дает.
23.06.2024 40404 bayselonarrend 24
Откуда информация, что запросы модуля документа читают из кеша? Я поставил эксперимент, запустив одновременно две процедуры проведения из-под разных юзеров. Сначала до, а потом после записи набора регистра у меня стояла функция задержки для синхронизации юзеров. В обоих случаях один юзер провел документ, а второму выдалось сообщение о нехватке товара. Экспериментировал в файловом варианте.
//1
Движения.ОстаткиТоваров.Записывать = Истина;
//2
Движения.ОстаткиТоваров.Очистить();
Для каждого Стр Из СписокТоваров Цикл
Движение = Движения.ОстаткиТоваров.ДобавитьРасход();
Движение.Период = Дата;
Движение.Товар = Стр.Товар;
Движение.Количество = Стр.Количество;
КонецЦикла;
//7
//Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;
//Пока НЕ КаталогСуществует() Цикл
// Пауза(1);
//КонецЦикла;
//3
Движения.Записать();
Пока НЕ КаталогСуществует() Цикл
Пауза(1);
КонецЦикла;
Запрос = Новый Запрос;
//4
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = "ВЫБРАТЬ
| Док.Товар КАК Товар,
| СУММА(Док.Количество) КАК Количество
|ПОМЕСТИТЬ ДокТЧ
|ИЗ
| Документ.РасходнаяНакладная.СписокТоваров КАК Док
|ГДЕ
| Док.Ссылка = &Ссылка
|
|СГРУППИРОВАТЬ ПО
| Док.Товар
|
|ИНДЕКСИРОВАТЬ ПО
| Товар
|;
|
|//////////////////////////////////////////////////////////// ////////////////////
|ВЫБРАТЬ
| Остатки.Товар.Представление КАК ТоварПредставление,
| Остатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки(
| &ТочкаИтогов,
| Товар В
| (ВЫБРАТЬ
| ДокТЧ.Товар
| ИЗ
| ДокТЧ КАК ДокТЧ)) КАК Остатки
|ГДЕ
| Остатки.КоличествоОстаток < 0
|;
|
|//////////////////////////////////////////////////////////// ////////////////////
|ВЫБРАТЬ
| ДокТЧ.Товар
|ИЗ
| ДокТЧ КАК ДокТЧ";
Запрос.УстановитьПараметр("Ссылка", Ссылка);
//5
Запрос.УстановитьПараметр("ТочкаИтогов", Новый Граница(МоментВремени(), ВидГраницы.Включая));
ПакетРезультатов = Запрос.ВыполнитьПакет();
РезультатЗапроса = ПакетРезультатов[1];
Если НЕ РезультатЗапроса.Пустой() Тогда
//6
Отказ = Истина;
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Мало товара " + Выборка.ТоварПредставление + " нужно еще " + (-Выборка.КоличествоОстаток);
Сообщение.Сообщить();
КонецЦикла;
КонецЕсли;
Если Отказ Тогда
Возврат;
КонецЕсли; ПоказатьЕще хотел уточнить один момент для себя. Насколько я понимаю даже если бы мы накладывали для регистра ОстаткиТоваров блокировку через объект "БлокировкаДанных", то всерано пришлось бы использовать "БлокироватьДляИзменения" т.к. для регистра включено разделение итогов ?
Спасибо.
Все же кажется правдоподобным что
//3
Движения.Записать();
Блокирует до конца транзакции без "Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина" только по разделителю итогов а т.к. чтение выполняется без разделителя то для исключения взаимоблокировки и добавляют "Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина" но только если ВКЛЮЧЕН разделитель итогов это и имеет смысл. Иначе же если разделитель итогов ВЫКЛЮЧЕН - сама запись в регистр накладывает исключительную блокировку до конца транзакции.
Также здесь
Если "и то и другое" то важно проверить настройки объектов. Помните, что вид транзакции наследуется всеми вложенными транзакциями. То есть если документ записывается в автоматической транзакции, а движения делает по регистрам с управляемой... То система немного расстроится и вывалится с ошибкой.
кажется все наоборот. Если существующая транзакция автоматическая то начинаемая тоже. А вот если сначала управляемая а потом автоматическая - ошибка.
"Иначе же если разделитель итогов ВЫКЛЮЧЕН - сама запись в регистр накладывает исключительную блокировку до конца транзакции. " об этом было указано в статье.
По "новой методике" можно включать разделение у оборотных регистров накопления и отключать его у регистров накопления остатков (по которым делаем контроль остатков после записи). И при таком подходе вообще не нужно думать про "БлокироватьДляИзменения". Потому что получается бред - сначала мы разрещаем разделение, а потом программно через БлокироватьДляИзменения его по сути запрещаем. Ну и в чем тут глубокий смысл ?
А по поводу записи, теоретически можно писать параллельно в оборотные регистры накопления, а вот в регистры остатков при "новой" методике контроля остатков параллельно писать нельзя, поэтому и придумали "БлокироватьДляИзменения". Если почитаете форум разработчиков 1С, то там это достаточно подробно расписано. Т.е. фактически для тех регистров, по которым остатки проверяются после записи проще отключить возможность разделения итогов чтобы не заморачиваться с "БлокироватьДляИзменения". С другой стороны запись в такой регистр не всегда сопровождается последующим чтением (контролем остатка), но при этом надо точно понимать когда нужно блокировать, а когда нет. Так что в идеальном варианте "БлокироватьДляИзменения" нужное свойство, но где вы видели идеальные конфигурации ?
Не правильнее ли будет для контроля остатков получать данные не из табличной части документа, а уже из таблицы регистра? Я вижу несколько причин обращаться сразу к регистру:
1. В табличной части не готовые данные - требуется как минимум пересчитать количество из единиц в документе в единицы хранения остатков
2. Это более универсально - по одному регистру движения формируются разными документами, у которых названия табличных частей, реквизитов и т.д. могут быть разными, а если брать данные из регистра, то текст запроса будет одинаков для всех документов
Не думаю, что по скорости чтения данных из регистра будут какие-то проблемы, ведь регистратор, по которому устанавливается отбор для чтения данных, всегда входит в индекс регистра.
Если я ерунду говорю, сильно не пинайте, лучше объясните, в чем я не прав :)
Спасибо
|ВЫБРАТЬ
| Остатки.Товар.Представление КАК ТоварПредставление,
| Остатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки(
Мы берем данные из регистра. Все остальное, для оптимизации расчета временной таблицы.
Во втором запросе без данных ТЧ документа не обойтись.
Запрос.МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос.Текст = "ВЫБРАТЬ
| Док.Товар КАК Товар,
| СУММА(Док.Количество) КАК Количество
|ПОМЕСТИТЬ ДокТЧ
|ИЗ
| РегистрНакопления.ОстаткиТоваров КАК Док
|ГДЕ
| Док.Регистратор = &Ссылка
|
|СГРУППИРОВАТЬ ПО
| Док.Товар
|
|ИНДЕКСИРОВАТЬ ПО
| Товар
|;
|
|//////////////////////////////////////////////////////////// ////////////////////
|ВЫБРАТЬ
| Остатки.Товар.Представление КАК ТоварПредставление,
| Остатки.КоличествоОстаток
|ИЗ
| РегистрНакопления.ОстаткиТоваров.Остатки(
| &ТочкаИтогов,
| Товар В
| (ВЫБРАТЬ
| ДокТЧ.Товар
| ИЗ
| ДокТЧ КАК ДокТЧ)) КАК Остатки
|ГДЕ
| Остатки.КоличествоОстаток < 0
|;
|
|//////////////////////////////////////////////////////////// ////////////////////
|ВЫБРАТЬ
| ДокТЧ.Товар
|ИЗ
| ДокТЧ КАК ДокТЧ";
ПоказатьТем не менее, считаю, что в угоду универсальности кода можно использовать чтение данных из регистра, а не из ТЧ.
Как правило регистров, по которым нужен контроль остатков не много, а документов, формирующих движения по ним - достаточно большое количество. Поэтому для каждого документа прописывать контроль муторно (надо учитывать, например, что у них может быть разный состав табличных частей и реквизитов), а так можно для контроля по конкретному регистру создать универсальную процедуру для любых видов регистраторов.
Само собой, что это может сказываться на производительности при большом количестве контролируемых регистров и серьезном документообороте, но думаю, такой подход имеет право на существование.
Перед выполнением запроса вообще-то запись движений происходит ;)
ИНДЕКСИРОВАТЬ ПО ТОВАР ТоварЯ знаю, этот кусок кода я скопировал из статьи Павла
| РегистрНакопления.ОстаткиТоваров.Остатки(
| &ТочкаИтогов,
| Товар В
| (ВЫБРАТЬ
| ДокТЧ.Товар
| ИЗ
| ДокТЧ КАК ДокТЧ)) КАК Остатки |ИЗ
| СписанныеТоварыРегистр КАК СписанныеТовары
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(&Дат, ) КАК ПартииТоваровНаСкладах
| ПО СписанныеТовары.Склад = ПартииТоваровНаСкладах.Склад И СписанныеТовары.Номенклатура = ПартииТоваровНаСкладах.Номенклатура По поводу других СУБД ничего сказать не могу по этому поводу.
По вашей переписке - имхо вы оба уходите в частности, есть список "ограничений" и "условий" при которых алгоритмы работают, даже банальное количество строк в обсуждаемых таблицах могут поменять "подход" к алгоритму...
Делить Вам нечего: Павел рассказывает про массовый подход, а вы (88) про частный - как бы не корректно под общий знаменатель это все делать...
На истину в последней инстанции не претендую :-) Просто поделился опытом.
Меня больше интересует ответ на (84).
1) так я сам испрашиваю. Просто неоднократно видел вот такую конструкцию.
МоментВремени = ?(Режим = РежимПроведенияДокумента.Неоперативный, МоментВремени(), '00010101'));
И это казалось логичным :) вы же в данном случае не использовали данную конструкцию, вот я и уточнил а нужна ли она.
2) То есть при партионном учете, на экзамене специалист, требуется делать именно так, как в вашей статье? Просто, на самом деле, смотрел десятки решенных билетов от разных людей и они все делали на одном регистре. Хотя мне вариант на двух тоже кажется более правильным.
Просто неоднократно видел вот такую конструкцию.
МоментВремени = ?(Режим = РежимПроведенияДокумента.Неоперативный, МоментВремени(), '00010101'));Лучше написать так:
Просто неоднократно видел вот такую конструкцию.
МоментВремени = ?(Режим = РежимПроведенияДокумента.Неоперативный, МоментВремени(), Неопределено));
Хотя не проверял, возможно эти выражения равнозначны.
Здесь такой момент. Установка параметров виртуальных таблиц в Неопределено равносильна тому, что мы его не указываем. Это, если можно так выразится по отношению к параметрам виртуальных таблиц, параметр по умолчанию. В этом случае в случае оперативного проведения вычисляются итоги на последнюю возможную дату.... с годом 3999 и указанным в справке днем и месяцем :)
Какие преимущества это дает? В случае если мы всегда будем указывать МоментВремени() , то в любом случае система будет вычислять остатки на этот момент времени. Хотя возможно есть какой-то аналог точки актуальности и если МоментВремени() оказывается больше нее то это равнозначно тому что параметр не указывается. Но я во всяком случае нигде не встречал такой информации.
Сам всегда предпочитаю писать
МоментВремени = ?(Режим = РежимПроведенияДокумента.Неоперативный, МоментВремени(), Неопределено));
Это простое выражение и гарантированно дает нужный результат.
Я собственно и спросил, почему GROOVY не использовал такую возможность.
Ведь по логике, при оперативном проведении мы записываем пустой набор и мы вполне можем получать остатки из таблицы актуальных итогов, а не на момент времени. Так указывалось много где, к примеру
Я не эксперт и возможно есть какая-то причина ) именно поэтому и интересуюсь
К примеру в этой статье , да и вообще много где.
1) А разве не нужно при оперативном проведении получать актуальные итоги, а не на момент времени? Как вообще работает этот процесс получения актуальных итогов? Обязательно ли их получать на пустую дату?
2) Вопрос немного не в тему, но может быть подскажете. По экзамену специалист на платформу. Решенная вами задача почти копия задачи 1.1 из сборника. Так вот, решить задачу можно и используя старую методику проведения, на одном регистре. Как всё таки правильно делать на экзамене? Использовать 2 регистра и новую методику, или 1 регистр и старую? Я спрашивал на вашем форуме, там предпочитают 1 регистр.
Спасибо :)
>> но при окончании транзакции проведения наборы данных записывались еще раз
Это точная информация? У документа два свойства: "Записывать выбранные" и "Записывать модифицированные". Если мы один раз принудительно записали набор движений, то свойство модифицированности у него пропадет и при окончании обработки проведения повторной записи не будет.
Сейчас уже не могу ручаться на 100%, но помню что проверял этот момент и повторной записи не происходило. Связал тогда это с тем, что свойство "Модифицированность" у уже записанных движений = Ложь.
По этому как минимум один плюс новой схемы можно вычеркнуть.
Это так, однако после выполнения
Движения.Записать();для каждого набора записей из этой коллекции Модифицированность() = Ложь.
Таким образом по окончании обработки проведения если мы записали движения вручную и у документа установлено свойство "Записывать модифицированные" запись произведена не будет.
В статье это отмечено, но несколько в другом контексте, при записи пустого набора записей
//16
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.СтоимостьТоваров.Очистить();
//17
Движения.СтоимостьТоваров.БлокироватьДляИзменения = Истина;
Движения.СтоимостьТоваров.Записать();
КонецЕсли; Извиняюсь за дублирование информации, но не раз на форумах встречал вопросы связанные с этим и именно этот момент ставил вызывал у людей затруднение и это кажется важным.
0) Используем 1С 8.3 - база MS SQL в режиме версионника (это важно), а не блокировщика. Для других СУБД вроде как и в 8.2 используется версионирование, но на практике ничего не могу сказать по ним - не пробовал.
1) Движения автоматически не удаляем при перепроведении (иначе сразу в начале проведения получим блокировку).
2) Движения явно в коде не пишем - записываются автоматически системой при записи самого документа (иначе получим деадлоки из-за разного порядка записи в регистры).
3) В регистрах накопления и бухгалтерии убираем возможность разделения итогов (иначе получим конфликт разделяемой и неразделяемой блокировки при контроле остатка).
4) Блокировки явно в коде не устанавливаем (устанавливаются платформой автоматически при записи движений в регистры).
5) Контроль остатков делаем после записи движений регистров (ну собственно "новая" методика :-)).
Почему именно так нужно объяснять подробнее по каждому пункту, но таким образом исключаются деадлоки на уровне СУБД и минимизируется время блокировки на уровне сервера приложений только на время записи движений в регистры.
Такой подход реально работает! Параллельность работы максимально возможная!
P.S.: Хуже всего конечно с регистром бухгалтерии т.к. там плохо разделяются блокировки, но это компенсируется тем что блокировка накладывается только на время записи в регистр, а не на все время проведения документа.
Это не повод не пользоваться тем подходом который я описал, но идеала по параллельности работы таким образом для MS SQL не достигнем :-(
Правильным подходом является отсутствие явной записи регистров для исключения взаимоблокировки регистров при разном порядке записи. Правильно ?
Более того, я сам преподавал, и очень хорошо помню как время от времени во всех курсах меняется "политика партии". Делайте так... А почему - а потому что так "методически верно"...
Проходит некоторое время, и на тех же курсах ТАК КАК РАНЬШЕ ДЕЛАТЬ НЕ ПРАВИЛЬНО, теперь политика партии ТАКАЯ...
И так по кругу...
получилось ли у меня ответить на вопрос?
но если уж совсем честно подходит к этому вопросу, вызвать взаимную блокировку могут все перечисленные методики, включая последнюю, но вероятность их существенно ниже чем в исходной методике
пс: сомнительные для меня, стоит ли заморачиваться если пользователей работает не более 15 ? я думаю нет.. у них даже транзакционных блокировок не возникает даже на автоматическом режиме + файловая бд )
когда вернетесь к проблеме, соберите статистику например бесплатным и будет понятно (оно/не оно) :)
ps: за ссылку спасибо, пригодится
Ну а новую методику контроля остатка я применяю с 2007 года, когда еще 1С говорила что это в корне неверный подход :-)
P.S.: Основная проблема масштабируемости 1С - длинные транзакции при проведении. Думаю что многим это и так понятно, но по опыту многие это не до конца понимают. Решать эту проблему можно по разному, но чаще всего приходится ее решать в уже существующих в том числе типовых конфигурациях и в связи с этим количество способов решения сильно сокращается (в некоторых случаях до нуля :-)).
Если разделение итогов не будет включено и в режиме пользователя, то в большей части случаев блокировка будет наложена на весь регистр с его таблицами.
Здесь? Т.е. если разделителя нет то несмотря на управляемые режим блочиться весь регистр???
"Свойство БлокироватьДляИзменения этот механизм отключает."
Не ну момент проведения отключает конечно :)
На момент чтения ничего еще не изменилось. Иначе прочитать бы не удалось. При управляемых блокировках в транзакции проведения уровень изоляции READ COMMITED, что само собой исключает возможность грязного чтения.
Извиняюсь, Repeatable read не решит.
Кем будет наложена блокировка на весь регистр:
- Сервером приложений (если это так то это ошибка в логике работы сервера приложений) ?
- MS SQL Server (такое вполне возможно т.к. MS SQL сам принимает решение что блокировать) ?
если лень делать "исследования", и знаете что по полю временной таблице будет соединение, то индексирование более "надежно"
все начинает играть новыми красками, когда во временную таблицу приходит миллион строк )
Это точно. Мне даже кажется, что эффект будет вполне заметен уже на 100+ строках :)
И как я уже писал качественно решить эту проблему помогает только переход на версионную СУБД.
Перевести типовую конфигурацию на "новую" методику не так уж и сложно - вполне реально (описано в (34)).
Я вместе с изучением теоретической части и практическими опытами перевел типовую УПП за 4 дня (2 дня читал мануалы и форумы, 1 день на кодинг, 1 день на тестирование). Правда контроль остатков товара по новой методике там уже был (я сделал еще раньше).
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.СтоимостьТоваров.Очистить();
//17
Движения.СтоимостьТоваров.БлокироватьДляИзменения = Истина;
Движения.СтоимостьТоваров.Записать();
КонецЕсли;
На больших наборах это может приводить к заметному торможению .
На текущей машине около минуты на 1000.
В запросе остатков просто достаточно исключить обороты по документу, если они были
Тогда в варианте без очистки платформа убедится что наборы совпадают и проведение будет практически моментальным (для больших наборов), если очистка была проведена - будет долгая запись (для больших наборов)
Но не могу пройти мимо и не добавить пару ложек дегтя, уж пардонте.
1. "... если документ записывается в автоматической транзакции, а движения делает по регистрам с управляемой... То система немного расстроится и вывалится с ошибкой."
Ничего подобного, просто все дальнейшие транзакции будут работать в автоматическом режиме и явная установка управлямой блокировки будет просто проигнорирована. А вот в обратной ситуации как раз будет ошибка.
2. "Если разделение итогов не будет включено и в режиме пользователя, то в большей части случаев блокировка будет наложена на весь регистр с его таблицами"
Блокировка будет автоматически наложена только на записываемые данные и это никак не зависит от того включено ли разделение итогов или нет.
Объясните пожалуйста, что это за случаи при которых будет блокировка на всю таблицу в управляемом режиме?
3. И на последок почему-то здесь у автора путаница с понятиями "Грязное чтение" и "Неповторяющееся чтение", при уровне изоляции "READ COMMITTED" (который используется в упр. режиме) грязное чтение не возможно. На самом деле вы говорите про проблему "Неповторяющееся чтение"
Еще раз повторюсь что смысл статьи верный и в целом все правильно, но вот такие "детали" очень портят впечатление.
1. Это я тупо ошибся. Поправлю.
2. Тут я имею в виду таблицу итогов. Параллельное чтение мы блокируем, но при разделении итогов не блокируется параллельная запись по указанным позициям. Надо подумать как это сформулировать по-другому.
3. Отдельное спасибо.
"Параллельное чтение мы блокируем, но при разделении итогов не блокируется параллельная запись по указанным позициям"
Почему же не блокируется запись?
Если ставить "БлокироватьДляИзменения = Истина" то блокируется все и чтение и запись, по факту эта команда отключает разделение итогов пока не закончится запись.
"Кто это сказал?" это говорю я ну и Нуралиев Сергей тоже это говорит :) и проведенные вчера опыты
Возможно мы с вами по разному трактуем одно и тоже понятие.
"Будут заблокированы итоги по всем комбинациям измерений удаляемых запиесй регистра. Без учета разделителя."
Повторю еще раз, именно "Без учета разделителя", т.е. разделитель не работает, он выключен пока идет запись, и параллельная запись не возможна.
Одей говорит что "БлокироватьДляИзменения" не отключает свойство "Разрешить разделение итогов" и это правда, свойство остается, но на время записи разделитель выключается, еще раз повторюсь, только на время записи!
Вот еще одна ссылка на партренский форум
Тут Нуралиев подробно отвечает на этот вопрос.
Вчера не поленился и провел опыт, он так же подтверждает что при установке БлокироватьДляИзменения в Истина параллельная запись не возможна, если поставить Ложь, все прекрасно записывается.
Да, при контроле остатков разделение итогов теряет смысл, но насчет отключить разделение совсем надо смотреть в каждом конкретном случае. Ведь наверняка возможны ситуации, когда по одному регистру делают движения разные документы, и в каких-то случаях контроль остатков по этому регистру нужен, а в каких-то нет. Например, если при приходе контролировать остатки не обязательно, то можно (и нужно) включить разделение итогов и параллельно писать в регистр по одному и тому же набору измерений.
Вобщем возможность хорошая и правильная, но при контроле остатков выигрыша в производительности она не дает.
в реальной практике надо собирать статистику работы и смотреть на конкретный контекст, так как многие "потенциальные" проблемы у многих так и останутся потенциальными и они о них не узнают
это как с айсбергом, если мы не видим подводной части, это не значит что ее нет
надеюсь что со временем методики как минимум научаться "получать обратную связь" от истории исполнения и корректировать "по какой ветке кода идти в этих условиях"...
Так ведь наличие свойства "БлокироватьДляИзменения" как раз и связано с тем чтобы препятствовать взаимоблокировкам при включенном разделении итогов. Я наивно предполагал что участникам обсуждения это и так понятно :-)
1) Оптимизируем код проведения документов - убираем "узкие места" в виде неоптимального кода;
2) Не удаляем существующие движения документа при перепроведении, т.к. это сразу же наложит блокировки в самом начале транзакции и они будут наложены до самого конца транзакции.
3) Не накладываем явно блокировки в коде - они не нужны, т.к. система сама заблокирует регистры при записи наборов.
4) Не записываем явно движения в коде - это может вызвать взаимоблокировки и преждевременное наложение блокировок, т.к. система сама запишет регистры в самом конце транзакции при проведении.
5) Используем "новую" схему контроля остатка.
6) Отключаем возможность разделение итогов по регистрам остатков и плана счетов чтобы предотвратить возможные взаимоблокировки. "Параллельность" записи мы повышаем уменьшением времени блокировки регистра.
7) Используем версионную СУБД (MS SQL в режиме блокировщика сам накладывает блокировки, которые нам не нужны и все наши труды по оптимизации уходят "в трубу").
Enjoy and Relax ;-)
P.S.: Подход реально опробован на базе УПП (~80 Гб, ~100 пользователей) - результат более чем положительный!
Но если вам что-то смущает, можно написать примерно так:
Движения.СтоимостьТоваров.Очистить();
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
// записать пустой набор надо только в случае сдвига даты даты документа вперед
Движения.СтоимостьТоваров.БлокироватьДляИзменения = Истина;
движения.СтоимостьТоваров.Записать();
КонецЕсли;
Я ничего не напутал?
У меня нет цели кому то что то тут доказывать - я себе уже все доказал :-) Что будут стоить тысячи слов если вот оно стоит и работает ? Если есть вопросы - спрашивайте.
Готовы ли вы сделать выбор ?
Каждый из пунктов по отдельности не дает практически ничего - что то улучшается но значимого эффекта не дает.
P.S.: По поводу нового - приходится повторяться... :-) Новую методику контроля остатков я предлагал еще в 2007 году (не претендую на авторство, но ветка по этому поводу на партнерском форуме 1С есть). Но тогда видимо мир еще не был готов :-)
Вопрос к автору. Ради интереса запустил глобальный поиск слово "БлокироватьДляИзменения" (явная установка блокировка на чтение) в УНФ ред.1.4, нет такого слово в конфигурации.
И что-то думать, либо разработчики считают, что можно для небольшой фирмой контролировать остатки без особой методики блокировок или разработчики считают, что и всё и так платформа нормально блокирует и никакого «грязное» чтение нет?
Про саму УНФ ничего сказать не могу - не "ковырял" :-)
Если убрать
// 3
Движения.Записать()
тогда можно провести второй документ по непересекающимся комбинациям измерений (если переписать момоент времени в параметре запроса как граница от МоментВремени() , исключая). Но если дату проведенного документа подвинуть вперед на день, тогда не хватает остатков, т к движения от ранее проведенного документа будут учитываться.
Собственно вопрос, есть ли рабочий вариант под SQL?
Вот такой код не работает (работает по вышепривеенной схеме).
Движения.ОстаткиТоваров.Очистить();
Движения.Взаиморасчеты.Очистить();
Движения.ОстаткиТоваров.Записывать = Истина;
Движения.Взаиморасчеты.Записывать = Истина;
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ОстаткиТоваров");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = Товары;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура", "Номенклатура");
ЭлементБлокировки.УстановитьЗначение("Склад", Склад);
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.Взаиморасчеты");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение("Контрагент", Контрагент);
Блокировка.Заблокировать();
Движения.Записать(); // удаление старых движений ранее проведенного документа
ВидСписания = РегистрыСведений.УчПолитика.ПолучитьПоследнее(Дата).ВидСписания;
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| РасходнаяТовары.Номенклатура КАК Номенклатура,
| СУММА(РасходнаяТовары.Количество) КАК ТребКоличество,
| СУММА(РасходнаяТовары.Сумма) КАК Сумма
|ПОМЕСТИТЬ ВТ_Потребность
|ИЗ
| Документ.Расходная.Товары КАК РасходнаяТовары
|ГДЕ
| РасходнаяТовары.Ссылка = &Ссылка
|
|СГРУППИРОВАТЬ ПО
| РасходнаяТовары.Номенклатура
|
|ИНДЕКСИРОВАТЬ ПО
| Номенклатура
|;
|
| X
|ВЫБРАТЬ
| ВТ_Потребность.Номенклатура КАК Номенклатура,
| ПРЕДСТАВЛЕНИЕ(ВТ_Потребность.Номенклатура) КАК ТоварПредставление,
| ВТ_Потребность.ТребКоличество КАК ТребКоличество,
| ВТ_Потребность.Сумма КАК СуммаПродажи,
| ОстаткиТоваровОстатки.Партия КАК Партия,
| ЕСТЬNULL(ОстаткиТоваровОстатки.КоличествоОстаток, 0) КАК КолвоЕсть,
| ЕСТЬNULL(ОстаткиТоваровОстатки.СуммаОстаток, 0) КАК СуммаОстаток
|ИЗ
| ВТ_Потребность КАК ВТ_Потребность
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиТоваров.Остатки(
| &МоментВремени,
| Номенклатура В
| (ВЫБРАТЬ
| Т.Номенклатура
| ИЗ
| ВТ_Потребность КАК Т)
| И Склад = &Склад) КАК ОстаткиТоваровОстатки
| ПО ВТ_Потребность.Номенклатура = ОстаткиТоваровОстатки.Номенклатура
|
|УПОРЯДОЧИТЬ ПО
| Номенклатура,
| Партия " + ?(ВидСписания = Перечисления.ВидыСписанияТМЦ.ЛИФО, "Убыв", "") + "
|ИТОГИ
| МИНИМУМ(ТребКоличество),
| СУММА(КолвоЕсть), МИНИМУМ(СуммаПродажи)
|ПО
| Номенклатура";
Запрос.УстановитьПараметр("Склад", Склад);
Запрос.УстановитьПараметр("Ссылка", Ссылка);
Запрос.УстановитьПараметр("МоментВремени", ?(РежимПроведения = РежимПроведенияДокумента.Оперативный, Неопределено, МоментВремени()));
РЗ = Запрос.Выполнить();
ОбщаяСуммаПродажи = 0;
Выборка = РЗ.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам, "Номенклатура");
Пока Выборка.Следующий() Цикл
Если Выборка.ТребКоличество > Выборка.КолвоЕсть Тогда
Сообщить("Не хватает " + Выборка.ТоварПредставление + ". Есть " + Выборка.КолвоЕсть + ", нужно " + Выборка.ТребКоличество + ".");
Отказ = Истина;
Продолжить;
КонецЕсли;
ОбщаяСуммаПродажи = ОбщаяСуммаПродажи + Выборка.СуммаПродажи;
НеобходимоСписать = Выборка.ТребКоличество;
ВыборкаДетали = Выборка.Выбрать();
Пока ВыборкаДетали.Следующий() Цикл
Движение = Движения.ОстаткиТоваров.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
Движение.Период = Дата;
Движение.Номенклатура = ВыборкаДетали.Номенклатура;
Движение.Склад = Склад;
Движение.Партия = ВыборкаДетали.Партия;
Движение.Количество = Мин(ВыборкаДетали.КолвоЕсть, НеобходимоСписать);
Если Движение.Количество = ВыборкаДетали.КолвоЕсть Тогда
Движение.Сумма = ВыборкаДетали.СуммаОстаток;
Иначе
Движение.Сумма = ?(ВыборкаДетали.КолвоЕсть <> 0, ВыборкаДетали.СуммаОстаток * Движение.Количество / ВыборкаДетали.КолвоЕсть, 0);
КонецЕсли;
НеобходимоСписать = НеобходимоСписать - Движение.Количество;
Если НеобходимоСписать = 0 Тогда
Прервать;
КонецЕсли;
КонецЦикла;
КонецЦикла;
Запрос.Текст =
"ВЫБРАТЬ
| ВзаиморасчетыОбороты.СуммаПриход КАК Сумма
|ИЗ
| РегистрНакопления.Взаиморасчеты.Обороты(&НачПериода, &КонПериода, , Контрагент = &Контрагент) КАК ВзаиморасчетыОбороты";
Запрос.УстановитьПараметр("НачПериода", НачалоМесяца(ДобавитьМесяц(Дата, -1)));
Запрос.УстановитьПараметр("КонПериода", Новый Граница(КонецМесяца(ДобавитьМесяц(Дата, -1)), ВидГраницы.Включая));
Запрос.УстановитьПараметр("Контрагент", Контрагент);
Результат = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = Результат.Выбрать();
ПроцентСкидки = 0;
Если ВыборкаДетальныеЗаписи.Следующий() Тогда
СуммаЗакупкиПредМесяц = ВыборкаДетальныеЗаписи.Сумма;
Если СуммаЗакупкиПредМесяц >= 10000 Тогда
ПроцентСкидки = 15;
ИначеЕсли СуммаЗакупкиПредМесяц >= 5000 Тогда
ПроцентСкидки = 10;
ИначеЕсли СуммаЗакупкиПредМесяц >= 3000 Тогда
ПроцентСкидки = 5;
ИначеЕсли СуммаЗакупкиПредМесяц >= 1000 Тогда
ПроцентСкидки = 2;
КонецЕсли;
КонецЕсли;
Движение = Движения.Взаиморасчеты.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
Движение.Период = Дата;
Движение.Контрагент = Контрагент;
Движение.Сумма = ОбщаяСуммаПродажи;
Если ПроцентСкидки <> 0 Тогда
Движение = Движения.Взаиморасчеты.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
Движение.Период = Дата;
Движение.Контрагент = Контрагент;
Движение.Сумма = (-1) * ОбщаяСуммаПродажи * ПроцентСкидки/100;
КонецЕсли;
Движения.ОстаткиТоваров.Записывать = Истина;
Движения.Взаиморасчеты.Записывать = Истина;
ПоказатьПричем добавление в //3 строк
Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;
Движения.Взаиморасчеты.БлокироватьДляИзменения = Истина;
ситуацию не меняет. SQL 2005 sp4, платформа (8.2.19.68).
Все кроме
>>Отключаем возможность разделение итогов по регистрам остатков и плана счетов чтобы предотвратить возможные взаимоблокировки. "Параллельность" записи мы повышаем уменьшением времени блокировки регистра.
Это как бы ездить на велосипеде, т.к. на машине можно врезаться в столб
Еще раз скажу что одно дело теория (некая теоретическая идеальная конфигурация), а другое дело практика (приблизить реальную конфигурацию к теоретическому идеалу). На практике всегда приходится чем то жертвовать...
Тогда коллеги, которым "теория от 1С" не по вкусу, просто пройдут мимо статьи и не разведут тут диспут на тему "красное? нет, легкое".
Ведь всем и так понятно, что приведен код, который нужно применять, чтобы получить сертификат. А как показывает опыт, практика и теория далеко не родственники. И спор тут ни о чем. То, что на практике успешние программисты применяют совсем другие методы, это известно уже давно. Осознание этого приходит с опытом:)
P.S.Точно так же настоящие квалифицированные специалисты, например, Cisco, не могут сдать экзамен на сертификацию, потому что теоретическое описание и реальная эксплуатация платформ никак не связаны:)
А то что другие программеры применяют другие методы.. тоже видала.. Как-то мне даже давали "потестить" результаты некоторых. Такое ощущение, что народ отладчик не умеет включать, в режиме юзверя ошибка на ошибке.. А кода мама не горюй! Сиди и расхлебывай)))
По мне так уж лучше бы большинство умело пользоваться типовыми механизмами, нежели кодить все вверх тормашками)))
Разделение итогов включено.
Ок, возможно это неправильно - есть объяснение, почему разделение итогов нужно отключать, кроме практических наблюдений ?
PS - для неверсионника, зачем оно в версионнике - не знаю
Поправьте, если я не прав, но:
1. Записи в итогах будут плодиться только при параллельных операциях по одинаковым наборам измерений - не думаю, что существенно скажется на количестве записей в таблице итогов
2. В любом случае, итоги должны и будут пересчитаны, при этом количество записей сократится.
Откуда же в таком случае "распухание"?
Есть ли смысл использовать новую методику контроля остатков если в конфигурации установлен Автоматический режим управления блокировкой данных? И если да, то как его правильно реализовать?
Предположим что в документе и регистре накопления тоже установлен автоматический режим, режим разделения итогов в регистре включен.
Для того чтобы избавиться от избыточных блокировок, то конечно имеет смысл только при управляемых блокировках.
Для того чтобы контролировать остатки при помощи "новой методики", то тип блокировок не имеет значения :-)
Смысл в полноценном контроле на возникновение отрицательных остатков, в отличие от типового контроля остатка :-)
Да. Именно этот аргумент выдвигали разработчики платформы 1С против "новой методики контроля остатка", когда в платформе еще не было управляемых блокировок. Теперь есть управляемые блокировки, есть "новая методика контроля остатка. Что еще нужно для счастья ? Правильно! Версионная СУБД :-)
Я использовал "новую методику контроля остатков" еще на версии 8.0 в 2007 году :-) Смотря какого смысла вы хотите достичь ?
Платформа 8.2.19.80, MS SQL 2008 R2
Пробуем провести параллельно документы в автоматическом режиме по совершенно разным измерениям - ошибка блокировки.
Кто понимает - проясните, пожалуйста.
В автоматическом режиме все печально с блокировками. Переходите на управляемый режим блокировок.
Павел, вопрос позвольте по:
проверял на "тестовом стенде", неявные блокировки накладываются вне зависимости от значения БлокироватьДляИзменения. Проверял на 8.2.19.79. Хотя в документации сказано, что это свойство определяет автоустановку неявных блокировок платформой.
Не встречали ли "мат часть" на такое поведение платформы?
Книга "Профессиональная разработка в системе «1С:Предприятие 8»" редакция 2012 года
Глава 11. Учет движения средств Стр 612
Чтобы избежать изменения итогов между моментом записи и моментом
чтения остатков, еще до формирования и записи движений регистра
свойство набора записей БлокироватьДляИзменения устанавливается
в значение Истина. В этом случае в момент записи набора записей плат-
форма отключит разделитель итогов в регистре. Таким образом, другая
транзакция не сможет записать движения по тем же измерениям, что и
текущая, до окончания проведения документа. В результате после записи
движений будут получены правильные остатки из регистров.
Движение.Стоимость = Списать / ВыборкаПартия.КоличествоОстаток * ВыборкаПартия.СтоимостьОстаток;
НА
Движение.Стоимость = Списать * ВыборкаПартия.СтоимостьОстаток/ ВыборкаПартия.КоличествоОстаток;
Запрос.УстановитьПараметр("ТочкаИтогов", Новый Граница(МоментВремени(), ВидГраницы.Включая));
Зачем?
Оптимально не указывать момент расчета в данном случае вообще ну или делать это только для неоперативного проведения.
//15
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Товар", "Товар");
Блокировка.Заблокировать();
//16
Если Режим = РежимПроведенияДокумента.Оперативный Тогда
Движения.СтоимостьТоваров.Очистить();
//17
Движения.СтоимостьТоваров.БлокироватьДляИзменения = Истина;
движения.СтоимостьТоваров.Записать();
КонецЕсли; ПоказатьНа какие ещё поля мы накладываем Блокировки в 17, если эти же поля заблокированы в 15?
Рассказывайте
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 195591
Создание 25.07.13 17:47
Обновление 26.07.13 13:05
Просмотры 106668
Загрузки 47
Рейтинг
345
Комментарии 178
Код открыт Не указано
Рубрики Механизмы платформы 1С
Кому Разработчик
Тип файла Архив с данными
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)