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

Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
               |    ВзаиморасчетыСКонтрагентамиОстатки.СуммаУпрОстаток КАК Сумма
               |ИЗ
               |    РегистрНакопления.ВзаиморасчетыСКонтрагентами.Остатки(&МоментВремени, Контрагент = &Контрагент) КАК ВзаиморасчетыСКонтрагентамиОстатки";

Запрос.УстановитьПараметр("Контрагент",        Контрагент);
Запрос.УстановитьПараметр("МоментВремени",    Новый Граница(МоментВремени(), ВидГраницы.Включая));
Выборка = Запрос.Выполнить().Выбрать();

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

Если ты сам их записал в ОбработкаПроведения "Движения.ВзаиморасчетыСКонтрагентами.Записать()"
, но перед запросом, то  будут.

А еще можно сделать так:
Движение = Движения.ВзаиморасчетыСКонтрагентами.Добавить();
Движение.Период = Дата + 1;

То тогда не попадет.

Не из-за того-ли, что в свойствах документа выставлено: "Запись движений: Записывать модифицированные"?

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

(1) для текущей записи - это не влияет

(1) "сама идея проверки бестолковая по сути" // Во всех современных типовых контроль отрицательных остатков там, где для этого не требуется что-то читать из контролируемого регистра, сделан именно так - записали движения, сделали запрос - а не минус ли стал? - если стал то откат транзакции, иначе коммит

(4) В явном виде это как раз то, что в свойствах документа "Записывать выбранные"?

(7) Нет конечно. Явно - это вызов метода Записать() у "зависимого" набора (который в коллекции движений документа) или у независимого набора

Всем спасибо!

(6) Из-за лени разработчиков. Кошернее заранее проверить.

(10) Чем кошернее?

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

(12) Ты просто описал как это происходит, но не ответил на вопрос

(12) зависит от того насколько часто получаем отказ.
если очень часто то лучше в начале. если нет то в конце

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

(13) Из описания не следует, что кошернее выполнить проверку перед формированием этого чемодана движений, чтобы понять, что он на фиг не нужен будет?

(16) Нет конечно

(16) там по теории вероятностей сделано. По теории вероятностей 99% всё нормально будет, а 1% отказ. Поэтому если сразу записать, то в 99% случаев в 2 раза выигрыш в скорости.

(8) Молодец!

(18) Возможно. С этой точки зрения я не рассматривал вопрос :(

вот кратко расписано преимущество "новой" методики проведения перед "старой":
https://курсы-по-1с.рф/articles/2017-02-12-two-methods-for-inventory-check/

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

(21) Мутно написано. Явно не очевидны некие "преимущества". Два раза перечитал специально. Что есть "все необходимые данные для проведения лежат в документе"? Сальдо взаиморасчетов "в самом документе"? Или данные о просроченных долгах? А свободные остатки "в самом документе", или "требуется расчет"?

(22) Простой пример - списание по партиям или распределение взаиморачетов по документам: этих данных в документе нет, распределение происходит динамически во время проведения и поэтому требует блокирования регистр, откуда достаются эти данные, до конца транзакции (надеюсь не надо объяснять зачем). Тогда тут подойдет старая методика контроля - раз регистр уже и так заблокирован до конца транзакции, то чтение из него надежное и поэтому проконтролировать тоже можно сразу заранее.
Другое дело, когда просто пишешь в регистр без необходимости надежного чтения из него - в этом случае регистр блокируется только ближе к концу транзакции, когда в него идет запись и последующий контроль отрицалова.

Преимущество - повышение параллельности работы из-за отсутствия преждевременного блокирования регистра в транзакции проведения: этот момент смещается ближе к ее концу (к моменту начина от Движения.Записать() и до ее конца)

(23) Т.е.применительно к реальным учетным системам практически всегда "старая схема" предпочтительнее? За исключение документов, проводимых "как есть"?

Или это задел под "отложенное проведение", когда всяческие распределения где-то в фоне втихаря выполняются? Тогда есть некая логика.

(25) Ты как вчера родился прям. Да это та же история как с планами счетов в бухгалтерии - общий план счетов БУ и НУ это круто! - раздельные планы счетов для БУ и НУ это потрясающее ноу-хау! - общий план счетов БУ и НУ это круто! - ...

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

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

(28) Баальшие сомнения в целесообразности таких вывертов.
Если остатков хватает, то и первый вариант - чтение/запись и второй - запись/чтение отработают всегда
А вот если их не хватает, то первый вариант только считает данные но не запишет их, а второй запишет/считает

Маркетологи и ленивые прогеры 1С  (((

(29) Новая схема - она не про то, что там работает или не работает и даже не про то, что в случае нехватки будет "холостая" запись. Она про сокращение длительности блокировки путем сдвиг момента блокировки ближе к концу транзакции.

(29) там фишка в том, что первый сначала очищает регистр, потом проверка, а потом пишет. Поэтому запись 2 раза и 2 блокировки.

(25) без отложенного проведения 1с ка умирает почти сразу

(+28) кто сдавал или готовится к сдаче по 1С Специалист по платформе, то это обязательное требование
и задача такая точно будет

(30, 31) Тогда уж проще вынести момент расчета до попадания в ОбработкаПроведения, а в ней только писать данные. Ну или не писать ;)

(34) тогда на момент ОбработкаПроведения данные уже протухнут при параллельной работе

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