|
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) там работает сферический манагер в вакууме:) безвозвратный:)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |