Радченко (подозреваю и не только он) рекомендует вначале провести документ, а уже после этого, в случае если РежимПроведенияДокумента.Оперативный - проверить на наличие остатков (к примеру) - и в случае нехвтаки - откатится
Почему не сделать проверку для режима проведения "Оперативный" сразу?

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

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

(0) Это - некошерный подход дзенствующих программистов к решению абстрактных задач.

(0) потому что пока ты будешь делать проверку, кто-то продаст этот товар. Помойму это же логично  ;-)

Хоть я и не программист

(5) заметно

(6) Ты предлагаешь блокировать товар до проведения транзакции при проверке?

пытаясь осмыслить полученные на сей момент ответы - склоняюсь таки к тому, что это  "Вопрос религии" :)

вот еще один религиозный вопросик, вы за 1 или за 2? :)

1.НоменклатураДокумента = Товары.Выгрузить(, "Номенклатура");
2.
"ВЫБРАТЬ
|    РеализацияТоваровНоменклатура.Номенклатура
|ПОМЕСТИТЬ НоменклатураДокумента
|ИЗ
|    Документ.РеализацияТоваров.Номенклатура КАК РеализацияТоваровНоменклатура
|ГДЕ
|    РеализацияТоваровНоменклатура.Ссылка = &Ссылка

(9) я за 1.

+9 прогнал малехо, конечно-же  
|ИЗ
|    Документ.РеализацияТоваров.Товары КАК РеализацияТоваровНоменклатура

хотя 1Сы есть 1Сы - надо тестить )

(10) да я тоже, но старый семерошник, 8-ка еще не въелась в кожу...

(12) я проверял, разница невелика. правда проверял на одном товаре в ТЧ... :)

+14 опять соврал :)
сейчас проверил (9) "без примесей" - запрос сожрал 95% времени :))

(8) пример6 остаток на складе 100, 2 юзера списывают по... ну пусть по 60 и 90 - пофиг по скольку!
ю1: смотрим остаток =100
ю2: смотрим остаток =100
ю1: пишем расход 60
ю2: пишем расход 90
ушли остатки в минус.

по новому:
ю1: списываем 60.
ю2 списываем 90.
ю1, ю2 - записываем.
ю1, ю2 - кто первый проверит остатки тот откатится.
остатки неминусовые.

Прифит!

+(16) такое на базах с кучей юзеров возникает не редко!

(15) ну лык в 1 м случае сразу из ТЧ выгребаешь, а во втором еще все ссылки на данную ТЧ из общей базы выгрести надо.

В том виде, как это записано в (9) 1 и 2 — две большие разницы.

(16) я проникся, начиная еще с (4) :)
(18) эт понятно, просто рекомендуют вездьде где надо и где нет - юзать запрос
(19) ну, не такие уж и большие. в данном случае временная таблица - тот-же список. я неправ?

(18) во 2-м случае если еще есть RLS , то может вылезти и превышение 256 таблиц в запросе на SQLе

(21) не в данном случае  - эт точно :)

(9) ничо, что в первом примере ты берешь с объекта, а во втором из данных базы? и второй пример видимо получает данные для следующего запроса, а в первом ты просто получил еще одну таблицу

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

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

(16) При правильном и своевременном наложении исключительных блокировок первая ситуация (с уходом остатков в минус) невозможна, т.к. блокировки будут наложены ПЕРЕД выполнением чтения остатков и вплоть до окончания проведения. То есть .2 не сможет проверить остатки до тех пор пока ю1 не закончит проведение.

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

(20) Неправ.
1.1 Вариант ДокументСсылка.Товары.Выгрузить() приводит к полному чтению объекта из базы
1.2 Вариант ДокументОбъект.Товары.Выгрузить() формирует список из того, что есть в ТЧ данного экземпляра объекта. К примеру, он может быть неактуальным или некорректным
2 Берет данные, которые есть в базе

(25) *  .2 = ю2

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

(28) Это к чему?
Не понял твоего высказывания.

(23) ну конечно раз ПОМЕСТИТЬ - то для следующего... кста и "Выгрузить" я тоже не просто так, тоже для запроса (другого)
(26) ваще-т, в данном, случае речь идет о интеракивном проведении

во народ разошелся. Имхо (9) можно юзать только в модуле проведения документа.

(9) Ключевой вопрос где этот код используется?

(26) ага, любое чтение всёравно будет сконвертировано в запрос, но когда указано что читать (вариант2) - запрос может быть проще (документ может быть сборкой многих таблиц(зависит от количества ТЧ))

(9) выгрузить() метод серверный, так что со стороны сервера.

(9) я за 2.

(32) в модуле проведения документа
немного конкретики, собственно концепция "СначалаПроводимПоЛюбому" - меня несколько озадачила в разрезе проведения по регистру Партии... где мне взять для такого проведения собственно "Партию" и , соответственно - Себестоимость?

(36) В модуле проведения однозначно вариант 2.

(36) достаточно чтобы документ был записан. Перед проведением документ всяко записывается. В форме же за этим надо смотреть.

(37) почему?

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

(38) подбор партий идет на этапе проведения, никак не в форме

(33) Чтение да, в запрос, а то и несколько, если считываются данные по ссылке. А вот выгрузка ТЧ у уже считанного объекта разве вызовет обращение к серверу? В общем случае.

Если готовить об обработке проведения, то список номенклатуры всё равно получается для каких-то нужд? Для подстановки в отбор по остаткам/партиям? Тогда почему Выгрузить(), а не ВыгрузитьКолонку()? Но всё равно я за вариант 2, т.к. с помощью временных таблиц и пакетного запроса можно значительно уменьшить время проведения.

(36) >> где мне взять для такого проведения собственно "Партию" и , соответственно - Себестоимость?

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

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

(16) А блокировки?

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

Escander, что за бред в (28)?

(43) фух, наконец-то, спасибо :)

(43) А там где нет партий, там покласть с прибором спишется товар в минус или не спишется. То есть новый способ проведения вообще никогда не применим на практике.

+47 просто у Радченко не рассматривается вопрос Партий, а я как-то привык к ним ...вот и леплю горбатого малехо по-своему  :)
...или я еще не дошел до раздела партий
(48) ну почему, все логично - списали в минус - получили "откат"

(49) И что в этом логичного? Например продавеца на кассе не должно парить сколько там по учёту товара числится. Перед ним ледит товар, он его продаёт. А уж не заведён приход или пересорт или ещё какая фигня, это пусть у менеджеров голова болит. Покупатель не должен стоять и ждать пока продавец разберётся почему чек не проводится.

(48) почему неприменим?

>> там где нет партий, там покласть с прибором спишется товар в минус или не спишется.

почему покласть?

Суть как раз в том и состоит, что при оперативном проведении нам себестоимость нафиг не нужна. Главное проверить есть товар в принципе или нет. А уже потом (регламентом ночью или обработкой или еще как-то) документ проводится неоперативно с расчетом себестоимости по партиям.

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

(46) чего бред? Время блокировки по новому меньше в этом профит!

(53) Аааа... Просто я не понял твоего высказывания.

Какая тогда разница, не спишется товар или уйдёт в минус? Если это потом всё равно регламентами исправляется?

кста, сейчас подумал ...такая вот временная шкала:
было 5шт товара
1-й пользователь провел свой док, списал 3 шт
2-й пользователь провел свой док, списал 4 шт
1-й начал проверять остатки - получил минус - получил ОТКАЗ :)

(56) у 2-го транзакция не завершена, так что 1 минус не получит.

(50) Ты совершенно прав. В рознице, как правило, так и есть.

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

(56) 2-ой не сможет начать проведение, пока первый не закончит проведение и проверки.

Остаток товара 1шт.
Продали 2шт.
Ситуация а) Товар не списался (новый способ проведения)
Ситуация б) Товар списался в минус
Завели приход перед продажей, перепровели продажу, товар списался.
Ну и в чём профит нового способа проведения? Только лишние блокировки, хоть и меньше, чем при проведении по партиям.

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

Так, чисто статистически. Сколько документов у вас "откатывается"? 1 из 100? 1 из 1000? Ничего критичного в этом нет, а удобнее в разы.

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

(62) кто их там считает
(63) а что тут придумаешь? разве что выбирать "подчиненные" и перепроводить, но это муторно

(64) Тут, я с тобой согласен. Что бы что то придумать надо хотя бы начать думать, а это муторно :-)

(9) Это не вопрос религии, а удобство. Смотри процедуру менеджера документа ИнициализироватьДанныеДокумента(). Там пакетным запросом подготавливаются и потом выплевываются таблицы значений, эти таблицы значений загружаются в регистры с помощью методов регистров Загрузить(). Легкость разработки существенно облегчается.

На (55)+(60) кто нить может ответить? В чем профит по сравнению со списанием в минус, если и там и там потребуются регламентные операции по исправлению?

(59) Тогда какая разница сначало проверка потом списания, или сначало списание - потом проверка, если все равно второй ждет первого? И если сначало идет проверка то иногда будет выйгрыш по времени за счет отказа в проведении

(66) нет такой :)
(67) ну профит наверное в том, что документ вообще не проводится, следовательно оперция купли-продажи не выполняется и менеджер сосет лапу :)

(69) Мне утверждали, что проводится. см. (50) и пофиг на конкретную реализацию, важна сама ситуация.

(70) там речь о рознице, там подход другой - по факту наличия товара, на базу данных - начхать ...и это правильно :)
2All: всем Спасибо! просветление в общении приходит быстрее :)

(70) там профит в другом. 99% всех документов, где всё нормально и никаких откатов и минусов не будет, там сначала списание - потом проверка однозначно быстрее, потому что меньше времени на транзакцию. И будет офигенный выигрыш.

А то, что вы обсуждаете - это всего 1%, поэтому глубоко наплевать, будет там выигрыш или проигрыш.

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

+(66) на примере.

- беру УТ11;
- добавляю новый оборотный регистр накопления с измерениями Партнер, Номенклатура и ресурсами Количество, Сумма (условный регистр);
- в процедуре ИнициализироватьДанныеДокумента() добавляю новый запрос в пакет запросов:

"////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    &Партнер КАК Партнер,
|    РеализацияТоваровУслугТовары.Номенклатура,
|    РеализацияТоваровУслугТовары.Количество,
|    РеализацияТоваровУслугТовары.Сумма
|ИЗ
|    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
|ГДЕ
|    РеализацияТоваровУслугТовары.Ссылка = &Ссылка"

- тут же несколькими строками ниже
ТаблицыДляДвижений.Вставить("ТаблицаМоиДвижения", Результат[17].Выгрузить());
- добавляю (копированием) процедуру в общем модуле ПродажиСервер

Процедура ОтразитьДвиженияПоМоемуРегистру(ДополнительныеСвойства, Движения, Отказ) Экспорт

   Таблица = ДополнительныеСвойства.ТаблицыДляДвижений.ТаблицаМоиДвижения;
   
   Если Отказ ИЛИ Таблица.Количество() = 0 Тогда
       Возврат;
   КонецЕсли;

   Движения.МойРегистр.Записывать = Истина;
   Движения.МойРегистр.Загрузить(Таблица);

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

- в процедуре обработки добавляю одну строчку
ПродажиСервер.ОтразитьДвиженияПоМоемуРегистру(ДополнительныеСвойства, Отказ);


Пять минут делов и проведение по новому регистру готово!

в процедуре обработки = в процедуре обработки проведения

(73) ну в бухгалтерии партионный учет редко используется. Вот для УТ это бы было актуально.

(74) подскажи что такое "ИнициализироватьДанныеДокумента"? СП про нее ничего не говорит, в стандартных модуляМенеджераДокумента тоже не нахожу
(76) ну не для всех Бух, для Украинской - всегда актуально было ;)

+77   платформа - 8.2.13.219

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

(78) если смотришь старые конфы (обычное приложение), то там еще по-старому делают.

(78) глобальный поиск их на раз находит ;)

(79) единственная процедура модуля менеджера документа у меня - ОбработкаПолученияДанныхВыбора(...
и "новых типовых" у меня нет, рисую нетленку по Радченко :)

(56) Про транзакции и уровни изоляции слышал когданибудь?

(68) >> Тогда какая разница сначало проверка потом списания, или сначало списание - потом проверка

Большая:

Время действия блокировок.

       первый способ:
1. Накладываем блокировки (в коде прописываются управляемые блокировки)
2. Читаем остатки
3. Проверяем нехватку
4. Формируем наборы записей
5. Записываем наборы записей (как правило, автоматически - по окончании обработки проведения).

       второй способ:
1. Формируем наборы записей
2. Записываем наборы записей (принудительно методом Записать)
3. Накладываются блокировки при записи наборов записей (система сама накладывает блокировки по нужным измерениям - ни чего прописывать в коде не надо)
4. Читаем остатки
5. Проверяем нехватку, откатываем, если не хватает.

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

Никогда не понимал людей ваяющих свои нетленки с нуля. Когда можно просто допилить торговлю или бухгалтерию. Особенно если эти нетленки повторяют функционал типовой конфы какой нить в основном.

+(84) и если в старом варианте делали так:

- обращаемся в долгом запросе к куче таблиц (долгое и нужное ж-ж-ж-ж-ж-ж-ж-ж по таблицам);
- записываем данные в регистры;

То в новом варианте так:
- быстрым запросом вытягиваем данные из документа (вжик! и данные у нас);
- записываем данные в регистры;
- проверяем, чего там напроводили.

(84) И где разница?

В 1 варианте время действия блокировок:
п.2, п.3, п.4, п.5

Во 2 варианте время действия блокировок точно такое же, но в другом порядке. Кроме "Формируем наборы записей" , но он, как правило очень быстрый.

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

По-моему, этот минус всё перевешивает.

(85) Типовые слишком перегружены функционалом. Из-за это слишком медленны.

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

В ветку призывается МуМу !

(87) >> Кроме "Формируем наборы записей" , но он, как правило очень быстрый.

Кто тебе обещал, что этот этап быстрый? Назови его фамилию и перечень клятв, какие он приносил.

(90) создать объект "НаборЗаписей" и загрузить туда готовую ТЗ - это тьфу.

(87) >> Зато имеем дополнительную нагрузку на сервер в виде записи в базу и отката транзакции в случае неудачи.

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

что опять ломать копья? почитайте Радченко, он всё по пунктам разъясняет, почему так делать лучше...

(91) А готовая ТЗ из воздуха берется?

Круто...

(94) Писатель?
"2. Читаем остатки"

(95) Вот-вот.

Во втором варианте я в запросе к остаткам укажу "ГДЕ КоличествоОстаток<0". Таким образом в большинстве случаев буду получать пустой результат запроса, а не огромную ТЗ (для случаев если большие табличные части).

(93) Писатель?  Читаем всю ветку :)

(97) читатель. и эту ветку читал и книжку....

+(98) к (97) тут всё написано и разжовано, читайте:
http://chistov.spb.ru/publ/novaja_metodika_kontrolja_otricatelnykh_ostatkov_pri_provedenii_dokumentov_v_sisteme_1s_predprijatie_8_2/5-1-0-29

1001

(98) плохо читал ибо я не раз в этой ветке упоминал о том что как раз иду "по Радченко" - это раз
у него нигде не рассматирваются 1-ый вариант из (9) - это два

(101) 1-ый вариант из (9) я не исследовал, ничего сказать не могу.а про (0) вот оно.
лпять же схема условная и использовать выгодно не всегда а в наиболее типичном документообороте..

(102) дык, об этом тоже речь  в ветке шла (клчевое слово - партия) ...так что - читатель :)

(103)... ну ладно :) пусть так :) ты победил :)

(104) фух, ну теперь и в отпуск можно :)