Всем привет. Тема к новой методике проверки остатков:
1. На складе А числится Товар1 в кол-ве 1шт.
2. Два сеанса одновременно проводят оперативно расходную накладную Товара1 со склада А в кол-ве 1 шт каждый документ..
3. Когда и первый и в второй сеанс одновременно попадают в процедуру "ОбработкаПроведения", оба документа отражены на оси времени и имеют МоментВремени. Предположим, что МоментВремени() накладной сеанса Номер1 < МоментВремени() накладной сеанса Номер2, т.е. на оси времени Накладная1 находится перед Накладной2.
4. В обработке проведения Накладная2 исполнение кода первее доходит до записи движений и до их блокировки.
В итоге получается, что хоть Накладная2 находится "после" Накладной1, в обработке проведения Накладная2 установит блокировку и остатки будут. А после этого, когда в ОбработкеПроведения начнется запись движений Накладной1, то получение остатков на границу МоментаВремени() не "получит" движения, сформированные Накладной2. Заимеем минус....

Если при оперативном проведении устанавливать получение остатков на МоментВремени, есть вероятность "отгрузить" в минус.
Получается, при оперативном проведении ВСЕГДА надо проверять остатки без указания периода.

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

(37) В смысле, теоретический? Сугубо практический. Но в типовых с этим все нормально, да. Можно не бояться :)

(36) На сертификации Белоусов разъясняет, какие могут быть проблемы, если при оперативном проведении не указать МоментВремени:
А вдруг есть документы будущим числом? Значит, получения актуальных остатков не максимально достоверное, и мы учтем движения документов, проведенные будущим числом...


При этом, как fisher подтвердил, нигде нет акцента, что при указании МоментаВремени одновременное оперативное проведение документов может привести к тому, что при наличии "временного лага" размещенные на оси времени документы по факту в обработке проведения в другом порядке начнут блокировать регистры...

Блокировку перед чтением контролируемого остатка ставят

(37) Да даже если бы и ошибка была в типовых, на нее напороться весьма проблематично. "Тяжелые" документы вообще обычно неспособны нормально распараллелиться по проведению в реальных конфах. А уж чтобы совпало одномоментное проведение с расхождением по времени проведения - такое только на высоконагруженных базах реально, коих тоже немного.

(38) Ну да. Я не претендую на роль революционера -)
то, что работает в типовых, это прекрасно... А в своих доработках/разработках теперь нужно учитывать и это...

(0) заходи, когда сможешь подтвердить эти выкладки экспериментально

(43) Дык (8) же.

(4) Ты все перепутал: управляемая ждет по таймауту, заданному в параметрах инфобазы, а объектная сразу выдает отлуп

(39) белоусов объясняет что в новой методике нужно момент времени брать?

(40) По "новой" методике - не ставят. Как раз чтобы уменьшить количество блокировок. Просто откатываемся если по итогу ушли в минус.

(47) если нужно партии списать , то нужно ставить

(46) конечно.
https://www.youtube.com/watch?v=XOoGQ9UfeI0&feature=emb_logo

скорее всего тс не понимает различия контроля остатков и списания партий

(44) это росказни, а не эксперимент. Чтоб стать экспериментом, там должны быть версии всего, должен быть опубликован весь код. Мало ли что там у него у обработках проведения. Да и было ли это на самом деле или это был умозрительный эксперимент - не понятно

(51) Мне просто лень повторять эксперимент. Потому что звучит абсолютно логично в моей картине знаний. То есть у меня фактически нет сомнений.
А у кого есть - повторить эксперимент самому с нуля 15 минут с перекурами.

(50) Ну вы проверьте мои доводы не отладкой в голове, а создайте простейшую конфигурацию с новой методикой контроля остатков в расходной накладной, и по п.(8)
Я это сделал, и увидел.

(53) для партий нужно брать на момент времени, а остаки проверять на текущую дату

тогда все будет ОК

(40) Чей сеанс первый блокировку установит? Строго в соответствии с последовательностью размещения документов на оси времени?

(50) Причем здесь списание партий? Это совершенно отдельная тема.

(47) Но он-то хочет на момент времени получать остаток. Надежно в этом случае без сдвига момента блокировки до начала чтения этого остатка - никак.
Кстати, а зачем ТС на момент времени получать остаток, что за отсылка к документам, введенным будущим числом? Хочешь чтоб работал принцип "после нас хоть потоп"?

(58) Отсылка потому, что нигде не акцентируется проблема эта.. Она ведь есть? Есть. Но он ней ни слова не слышал.
А вот проблему с будущим числом почему-то озвучивают на экзамене -(
Но на самом деле проблема с будущим числом нивелирует, если заранее предполагается отсутствие таких документов... Как говорят выше - при оперативном проведении передавать Неопределено в параметр Период вирт. таблицы остатков.

(56) Нет, соответствия конечно же нет - чей код быстрее исполнится тот быстрее и поставит.
Собственно, ты сам наверное уже догадался, что (40) не спасает в сценарии, когда ты читаешь остаток на момент времени.

В старой методике тоже же не было получения остатка на момент времени (для контроля отрицалова)?

Кстати, веселуха наверное будет, если в базе есть документ будущим числом со сторно-движениями)

(61) в старой методике задним числом просто ничего не контролировалось

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

(60) Да.

(63) Интересует конечно же только "оперативная" старая методика

(64) "какие есть проблемы передачи МоментаВремени() при оперативном проведении"
Главное, на аттестации сильно не умничать, а то могут снизить бал. А так вроде допустимо обоими способами делать.

(58) ТС просто поделился неочевидной особенностью новой методики контроля остатков - почему нельзя выполнять контрольное чтение остатков на момент времени.
Мне вообще очень нравится миста в этом плане. Любой пост с неочевидной инфой вместо "спасибы" превращается в длиннющий тред, где ТС пытается объяснить каждому встречному-поперечному что он не дибил. И все равно по итогу будет ходить как оплеванный :)

(64) Да вообще не понятно с какой стати нужно брать остатки на МоментВремени, а не Текущие?

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

(68) Ну кроме (27) , другого резона нет особо.

(70) Ну так общий подход к контролю остатков в "новом проведении" и должен учесть ситуацию такую.

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

(72) Да, а при списании "сегодня" берем актуальные остатки.

(27) Нельзя оперативно проводимый документ провести будущим числом. Если только сильно постараться - тогда сам себе враг. И при оперативном проведении получать остатки на момент времени - грубая ошибка.

(74) Оперативно нельзя.
Можно программно провести документ Неоперативно и установить будущую дату.

Флаг "Оперативное проведение" в "Разрешить" не повлияет на это.

(74) Очень грубая, теперь дополнительное ко всему я еще один довод к этому получил..

(74) "при оперативном проведении получать остатки на момент времени - грубая ошибка" // Хм, как твои слова согласуются с (49)? :)

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

а вот если приход завтр, но в след месяце - тут уже косячек-с

(77) Под этим видео кстате интересный коммент есть, и Белоусов ответил на него популярно)

(80) Так получается что раньше Белоусов выдавал получение без момента времени как недостоверный, а на самом деле все наоборот - недостоверный с моментом времени как раз

Т.е. Белоусов как раз топит за режим "после нас хоть потоп"

(74) Только что проверил, можно программо и оперативно проводить с будущей датой... О как.

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

(83) Еще можно в корректировку записей регистров залезть и чего-нибудь там записать.

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

(83) вот только будущая дата держится до конца обработчика события ПередЗаписью() как будущая, а в ПриЗаписи уже текущая станет... (оперативная)
Если передавать РежимПроведенияДокумент.Неоперативный, то и дата останется будущая..

короче Белоусов просто придумал способ валить на экзамене

(83) Да, программно что угодно можно - хоть движения к удаленному документу прикрутить, или к несуществующему. ССЗБ.

(86) Да. Накладная1  имеет время 12:00:00, Накладная2 имеет время 12:00:01.. Положение на оси времени очевидно. Оба проводятся оперативно.

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

(90) ну это может выдуманная в голове у меня ситуация, а в реальности такого нет.....

(90) Ок, твой мысленный эксперимент значит расширяем не до моментов времени из одной секунды, а до двух документов в разных секундах

+(92) Возвращаюсь к провозглашению (84), это уходит в печать (в мозг) :)

(91) в реальности типовые не выполняют проверки на момент времени.

Но опять-таки в типовых контроль на момент времени используется только в неоперативном режиме проведения вроде

(95) в "новых" типовых такого нет

(91) Вполне реальный вариант. ИМХО, в видео (49) неправильно трактуются требования к экзамену, слишком буквально.

У Белоусова нет никакой ошибки.
В (49) не используется новая методика контроля остатков. Там старая методика.
Белоусов предварительно устанавливает исключительную блокировку в начале проведения.
Он же там дальше и себестоимость одновременно считает. Расчет себестоимости невозможно выполнить корректно без предварительной блокировки и совместить с контролем остатков по новой методике.

По методике 1С оперативного проведения документов Накладная1 должна получить новую отметку времени и дата этой накладной станет позже даты Накладной2.
https://its.1c.ru/db/metod8dev#content:2746:hdoc

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

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

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

(102) Даа. Все понятно... Акцент для сертификации немаловажный

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

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

В новых типовых вообще кажись хитро делается - пишутся только изменения и контроль остатков по новой методике (если используется) выполняется тоже только по измененным записям.

(98) "Белоусов предварительно устанавливает исключительную блокировку в начале проведения" // Это не гарантирует, что контроль появления отрицательных остатков сработает если ты остатки читаешь с ограничением на дату / момент времени документа, а не на конец времен

(106) Здесь такая задача и не решается. Проверяются минуса на момент документа. Если хочешь контролировать принципиальное отсутствие отрицательных остатков когда бы то ни было - то проверка на конец времен при проведении это тоже полумера. Тогда нужно и при отмене поступлений минуса проверять и т.п. И далеко не всегда этот цирк нужен. Хотя я еще на 7.7 встречал упоминания самописок, где народ накручивал и хвастался подобными и даже более сложными системами, частично снимавшими необходимость в восстановлении последовательности при соблюдении ряда специфических ограничений.
В новой схеме контроля остатков проверка на конец времен - это скорее побочный эффект, а не самоцель.

Самоцель новой схемы контроля остатков - уменьшение количества блокировок.

(107) "В новой схеме контроля остатков проверка на конец времен" // Так и в старой тоже на конец времен

вооще то в старой схеме остатки при неопреативном проведении вообще не контролировались

(107) "Если хочешь контролировать принципиальное отсутствие отрицательных остатков когда бы то ни было" // Такой задачи не стояло - стоит задача проконтролировать хотя бы на дату самого документа, и чтением на момент времени / на дату документа она надежно не решается, в отличие от чтения на конец времен. Такие дела.

(110) Что-то ты повторяешь (63). В ответ могу повторить (65) :)

Ничего не понял. Ну и ладно. Мне работать надо :)

(0) а что мешает написать ?(РежимПроведения = РежимПроведенияДокумента.Оперативный, Неопределено, МоментВремени);
и гарантированно избежать возможных проблем, получая всегда актуальные остатки при оперативном проведении. тем более это и работает еще быстрее чем расчет остатков на дату(моментВремени).

(113) Ну смотри: хотим чтоб на момент каждого документа продажи гарантированно не было отрицательных остатков - чтоб нельзя было продать один оставшийся товар двум разным клиентам. Сделали получение остатков в модуле проведения на момент времени документа.
И в результате имеем две успешно проведенных реализации - одна временем 12:00:00, другая 12:00:05, например.
Не справился механизм.

(115) ну так тут ввод задним числом

(0) Классный вопрос. Тут, ты очевидно, пришел к пониманию регистрации документа в границе последовательности. Т.е. в твоем примере, когда накладная 2 провелась, затем также провелась и накладная 1, и ты увидел минус - то...То дальше, должен быть какой-то джоб, который восстановит границу последовательности до актуального значения и перепроведет в хронологической последовательности сначала накладную 1, затем 2. На второй - ты получишь ошибку об не хватке товара.

(116) Не было никакого ввода задним числом: в документе от 12:00:00 нажали кнопку "Провести и закрыть" в 12:00:00, а в документе от 12:00:05 нажали кнопку "Провести и закрыть" в 12:00:05

(118) а как тогда получилось что оба провелись?

(119) ну пусть будет так, что оба документа сначала записали, а потом провели не в хронологической последовательности. Сначала старший, потом младший. Если контроль на момент времени - оба проведутся в такой последовательности. Просто ТС искусственно такую ситуацию создал на моменте новых документов, притормозил ранний документ точкой останова.

(119) То что в 12:00:00 отправили проводиться что-то там 8 секунд считал в ПередЗаписью, а тот, что отправили проводиться в 12:00:05 - провелся за секунду

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

(121) А, ты про паузу до начала обработки проведения? Хм...

(123) Да :)

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

"При записи нового документа в форме если свойство АвтоВремя имеет значение отличное от НеИспользовать, и не используется оперативное проведение, и время документа пустое (0:00:00), то выполняется автоматическая установка времени на основании значения свойства АвтоВремя. Действие расширения формы в этом случае аналогично вызову метода УстановитьВремя() с вариантом выбранном в свойстве АвтоВремя  и с использованием журналов документа.
Расширение формы так же предоставляет команды для установки времени документа в начало дня, конец дня, перед предыдущим и за последующим документом."

По дефолту используется автовремя "Текущее или последним"

(120) Почти. Я не записывал их предварительно. Оба документа были "новые" и одновременно проводились, только документ, которому время присвоилось 12:00:00 я притормозил на ОбработкеПроведения.
Документ, которому присвоилось время 12:00:01 завершил работу без остановки..

Как итог: после продолжения отладки в документе с моментом времени 12:00:00 не видим движений документа на 12:00:01 в том случае, если мы остатким берем на момент документа...
Да, последовательность восстановит... Но это будет уже ПОСЛЕ случившегося, а операционная работа "идет" прям щас...

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

Перепроверил. Таки да. Если используется автовремя, то оно присваивается уже после "ПередЗаписью". В "ПередЗаписью" еще по нулям.
Т.е. с временной осью все нормально выходит.

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

+(131) И вот тот документ, которому присвоилось 12:00:00, чо-то там тупил много секунд. В это время тот, которому присвоилось 12:00:05, быстренько провелся и отхавал одну последнюю штуку. А потом и более ранний документ еще раз ее отхавал. Ненадежно, однако.

+(132) Ненадежно, однако, читать остатки на момент времени / дату документа.

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

(131) Похоже, что ты прав. В этой ситуации будет "уход в минуса". Что автоматически означает, что никакой оперативный расчет (типа расчета себестоимости) на момент документа ненадежен в конкурентном окружении. Ибо возможна ситуация когда второй документ несмотря на более позднее начало транзакции может провестись раньше первого и в этом случае последующее проведение первого документа будет классическим изменением "задним числом". Выходит, что все такого рода расчеты (подразумевающие хронологическую последовательность проведения документов) надежны только в условно монопольном режиме. Ужас.
(134) Невозможность параллельного проведения документов - это в 7.7 так было. На восьмерке это даже на автоблокировках было возможно, не говоря уже про блокировки управляемые.

Есть выход. Фигачить блокировки сразу в ПриЗаписи :)