есть документ счет и документ оплата, к счету может быть прикреплено несколько оплат
(если счет оплачивается частями).
При проведении оплаты двигаются кой-какие регистры которые начесляют % от оплаты счета менеджеру продаж, этот % должен начесляться
только 1 раз если счет закрыт на 100%.
Значит я сделал так:

если дог.проц>=100 тогда //дог это счет
//двигаем регистры
конецесли;

Но если у счета несколько оплат и кто-то вдруг захочет перепровести не последнюю оплату а первую или вторую (если счет разбит на 3 оплаты)
то получится что МП начислятся двойные проценты.
знач поставил доп. условие:

если дог.проц>=100 тогда
если дог.оплМП<=датадок тогда //оплМП тип дата
//двигаем регистры
дог.оплМП=датадок;
дог.записать();
конецесли;
конецесли;

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

Знач написал я все это добавил еще перед началом условия
сообщить("датадок="+строка(датадок)+" дог.оплМП="+строка(дог.оплМП));

и после
сообщить("дог.оплМП="+строка(дог.оплМП));

и пробую проводить, провожу последнюю оплату, все нормально в оплМП записалась дата оплаты, даже при открытии
счета написал сообщить(дог.оплМП); дата вывелась правильная, провожу предыдушую оплату, по идеи движение в регистре быть не должно, но не тут-то было
выводит мне дог.оплМП= .. почему???? если я опять провиду последнюю оплату то выводит нормально
мне дог.оплМП=дата предыдушей оплаты и проводит, если вновьпервую оплату опять дог.оплМП= .. вообще не понимаю почему так.
и еще вопросик если обе оплаты пришли в один день, одна утром другая вечером, то условие сработает?
ну например в дог.оплМП дата вечерней оплаты и проводим утренею, условие вернет true или false
время учитывается?

Заголовок классный

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

Т.е. код живет своей жизнью. Это интересно

Все так загадочно, как то, каким-то волшебством :DDDD
Автору бы стоило освоить отладчик для ознакомления с 1С :)

(5) а что он мне бы показал? он бы показал что в дог.оплМП пусто, тоже самое я и через сообщить() узнал. А вот почему так, не понятно.
(4) другого объяснения я не вижу )))

такс, с мистикой разобрался, оказалось в хедере в процедуре приотменепроведения стояло обнуление этого реквизита.
А по этому вопросу подскажите:
"если обе оплаты пришли в один день, одна утром другая вечером, то условие сработает?
ну например в дог.оплМП дата вечерней оплаты и проводим утренею, условие вернет true или false
время учитывается?"

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

P/S А что самому слабо на базе проверить

(2) это тренд на Мисте:
Непонятное поведение кода при отладке

Осень пришла - началось бешенство кода.

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

(10)не поможет©

(8) я спрашиваю не просто так, может в датадок содержится время создание документа.

Код ведет себя непонятно. Может он живой?
А где жизнь заводится?
Значит код - ...

(0) по отрывкам ничего не понятно.
Но обычно это делается оборотным регистром. Куда пишутся продажи/проценты/или еще чего.
Плюс представление о последовательности документов, чтобы избежать "Но если у счета несколько оплат и кто-то вдруг захочет перепровести не последнюю оплату а первую или вторую (если счет разбит на 3 оплаты) то получится что МП начислятся двойные проценты. ". И эта фраза говорит как минимум о непонимании процессов.

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

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

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

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

А в чем вопрос у ТС? Кто-нибудь понял?
Относительно владения великим и могучим - можно не писать.

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

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

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

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

В общем и целом - начисление бонуса вынести в отдельный документ. Полуавтоматический.

Всю ветку не читал (лениво).

Возвраты - учитываем?

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

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

(23) там работает сферический манагер в вакууме:) безвозвратный:)