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

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

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

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

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

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

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

и пробую проводить, провожу последнюю оплату, все нормально в оплМП записалась дата оплаты, даже при открытии
счета написал сообщить(дог.оплМП); дата вывелась правильная, провожу предыдушую оплату, по идеи движение в регистре быть не должно, но не тут-то было
выводит мне дог.оплМП= .. почему???? если я опять провиду последнюю оплату то выводит нормально
мне дог.оплМП=дата предыдушей оплаты и проводит, если вновьпервую оплату опять дог.оплМП= .. вообще не понимаю почему так.
и еще вопросик если обе оплаты пришли в один день, одна утром другая вечером, то условие сработает?
ну например в дог.оплМП дата вечерней оплаты и проводим утренею, условие вернет true или false
время учитывается?
2 Morphius
 
16.09.11
20:53
Заголовок классный
3 lucifer
 
16.09.11
20:57
(2) ну ведь действительно странный, по крайней мере для меня я не знаю почему он так себя ведет. Как буд-то бы реквезит периодический.
4 Morphius
 
16.09.11
21:00
Т.е. код живет своей жизнью. Это интересно
5 ЧеловекДуши
 
16.09.11
21:03
Все так загадочно, как то, каким-то волшебством :DDDD
Автору бы стоило освоить отладчик для ознакомления с 1С :)
6 lucifer
 
16.09.11
21:06
(5) а что он мне бы показал? он бы показал что в дог.оплМП пусто, тоже самое я и через сообщить() узнал. А вот почему так, не понятно.
(4) другого объяснения я не вижу )))
7 lucifer
 
16.09.11
21:28
такс, с мистикой разобрался, оказалось в хедере в процедуре приотменепроведения стояло обнуление этого реквизита.
А по этому вопросу подскажите:
"если обе оплаты пришли в один день, одна утром другая вечером, то условие сработает?
ну например в дог.оплМП дата вечерней оплаты и проводим утренею, условие вернет true или false
время учитывается?"
8 DigitalDolphin
 
17.09.11
01:17
(7)  lucifer ты вообще видел у даты понятие вечерняя дата и утренняя дата. Ты подозреваешь что с утра может быть одна, а вечером другая ... да похоже тут не код странный :-)

P/S А что самому слабо на базе проверить
9 МастерВопросов
 
17.09.11
05:33
(2) это тренд на Мисте:
Непонятное поведение кода при отладке

Осень пришла - началось бешенство кода.
10 1Сергей
 
17.09.11
08:11
при проверке оплаты считай полностью все поступления по договору, а хранить в договоре процент оплаты - глупость
11 Mikeware
 
17.09.11
08:20
(10)не поможет©
12 lucifer
 
17.09.11
13:10
(8) я спрашиваю не просто так, может в датадок содержится время создание документа.
13 poligraf
 
17.09.11
13:57
Код ведет себя непонятно. Может он живой?
А где жизнь заводится?
Значит код - ...

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

а все остальное было написано для понимания общей картины.
15 lucifer
 
17.09.11
14:05
(13) и оборотный регистр не пойдет, т.к. нужно выводить сальдо по начисленым бонусам МП
16 Тихий омут
 
17.09.11
17:58
имхается мне, что тебе нужно при проведении оплаты читать остатки взаиморасчетов из соответствующего регистра, и по результатам этого нехитрого действия делать вывод о необходимости начисления бонуса.
17 Kassius
 
17.09.11
18:03
А в чем вопрос у ТС? Кто-нибудь понял?
Относительно владения великим и могучим - можно не писать.
18 Cthulhu
 
17.09.11
23:45
(16): разве что на позицию документа документ (иначе, если стандартно на ТА - на каждую оплату уже закрытого взаиморасчета буде бонус накручиваться). плюс к тому - при проведении не проведенного документа оплаты взаиморасчет ещё не будет закрыт - но будет закрыть после(!) проведения. а накрутить надо при проведении этого (последнего) документа оплаты. значит надо хитрее - ещё и в модуое проведения контроль совать в самый конец проведения, и предварительно (перед контролем взаиморасчетов и расчетом бонуса) всовывать принудительную запись движений.
19 Тихий омут
 
18.09.11
09:39
(18) согласен. правда, представлял себе так - читаю остаток вр по заявке,суммирую с оплатой в валюте заявки, делаю вывод о необходимости бонуса. само собой, всё это при проведении оплаты. интересно - ты предлагаешь делать это опосредованно, читая результат текущей оплаты из регистра вр, это "методологически" правильнее, чем мой вариант?
20 Torquader
 
18.09.11
17:25
Вообще-то, логично сделать так:
При отмене любой оплаты очищать процент менеджеру, если оплата после меньше 100%.
При проведении оплаты мы анализируем все оплаты по документу, если до было меньше 100%, а после больше, то начисляем процент.
(Можно сначала искать начисленный процент, обнулять его и рассчитывать, что будет после - так как значение оплаты до где-то нужно будет сохранить).
При этом, процент должен быть "привязан" к исходному документу, который оплачиваем - так его будет проще искать в списке.
21 Cthulhu
 
18.09.11
18:41
(19),(20): ну и при движении документов оплаты туда-сюда - возможны коллизии. Например, Оплата, закрывающая взаиморасчет передвигается взад перед предыдущей оплатой - предыдущую надо перепроводить (чтобы накрутила бонус) потому что передвинутая перестанет закрывать взаиморасчет. И таких "напримеров" возможно всяких - все их надо отлавливать и отрабатывать как надо.
22 Cthulhu
 
18.09.11
18:42
В общем и целом - начисление бонуса вынести в отдельный документ. Полуавтоматический.
23 DeiMos
 
18.09.11
19:24
Всю ветку не читал (лениво).

Возвраты - учитываем?
24 Академик_
Келдыш
 
18.09.11
19:41
Сдается мне что там отчеты нужны нормальные а не куча непонятных реквизитов в базе
25 Академик_
Келдыш
 
18.09.11
19:43
Плодить расчетные реквизиты зло. За такое иногда кувалдой по пальцам бывает
26 Тихий омут
 
19.09.11
08:33
(23) там работает сферический манагер в вакууме:) безвозвратный:)
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший