Отложенные операции

Автоматическе изменения Сергей 19/07/2002 22:36 #

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

Dervish: Нет, умирать нам ещё рановато, так что, будьте здоровы!

А предложение интересное, видимо, оно будет сделано. Спасибо.

Да вот и еще по поводу отложенных платежей... Explorer 22/07/2002 21:10 #

Может быть мысль пока сыровата, но на будущее...

Просто условно...

Предположим есть проект >> Покупка квартиры в Дельта Кредит.
Есть определенный график платежей >> помесячно, поквартально, как деньги будут...
Вызываем календарь на год (два, три) и наглядно расставляем платежи с суммами, датами, пересчетом процентов и проч.
Т.Е. вот это именно и будет "проект"... Даже так: "ПРОЕКТ" в полном смысле этого слова. он может корректироваться подгоняться пересчитываться и проч.

Может рановато пока или вообще никчему... Но вот например упомянутый GSO не позволяет ставить Эвенсы (задачи или события) как хочешь (нет там "поквартально" или каждые 62 дня) и уже это скукоживает определенно.

Вопрос...

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

Почему сейчас мы работаем "черезсчетово" а не "черезпроетово"... Ну хоть капельку.
У "Сущности" "Проект" могут быть совершенно иные "качества" чем у "Сущности" "агент"...
Пока это почти одно и тоже...

Dervish: Сложно. Надо обдумать. Пока не знаю.

Просто условно... де Багер 22/07/2002 23:07 #

А ларчик просто открывался.
Изменить требуется только одно - отображение (проводка, учёт) отложенных операций. Т.е. если в фильтре даты указан следующий век - то ЗАПЛАНИРОВАННЫЕ операции (операции по которым выданы платёжные обязательств) должны отображаться, суммироваться и т.д.
Это в свою очередь приблизит к бюджету (планированию, анализу).
А проэкт останется как есть, но можно будет создать отдельный целевой счёт, как кстати и происходит в банке.
P.S.
"Есть определенный график платежей ........ как деньги будут..."
График это график, а как деньги будут - это про пиво

.

Dervish: Надо подумать... Пока не готов ничего сказать в ответ.

И еще по поводу отложенных платежей... де Багер 29/07/2002 02:03 #

Вот чего я ещё не понял.
Ведь в Графиках - Остатках по счетам существует отображение отложенных операций до конца установленного фильтра. Почему-же в операциях отображаются только следующие операции (ближайшие по времени). Причём без предполагаемых результатов предполагаемых операций. В чём разница?

Dervish: Подождите, разве в списке операций не показываются невыполненные операции?

Кроме того, на графике остатков остатки по невыполненным операциям показывается отдельной линией. Где показывать планируемые остатки? В отдельной колонке? Не слишком ли много будет колонок?

Поддерживаю вопрос! Женя 29/07/2002 10:55 #

Действительно, на графиках должны найти отражение все операции, которые определяются параметрами "Повторение".

Dervish: Насколько я понял, вопрос стоял не про графики. Вы, видимо, имеете ввиду диаграмму доходов и расходов?

ненене, именно графики Женя 29/07/2002 16:23 #

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

Dervish: А разве они сейчас не находят (отражение)?

Прошу прощения! Женя 30/07/2002 11:55 #

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

Удачи!

Dervish: Стирать ничего не буду, это неправильно и некрасиво.

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

Впрочем, есть ещё уйма других недоделок, которые нужно устранить.

отложенные платежи де Багер 29/07/2002 22:00 #

Отображаются конечно, НО ТОЛЬКО очередные, а не все (это раз), и рядом нет предполагаемого (он же ещё не реальный) результата (это два). И именно для задачи "...а что у меня на счету будет, когда придёт время оплачивать телефон? (в случае отсутсвия денег на счету, телефон отключается на третий день)" приходится переключаться на график остатков (опять таки - ПЛАНИРУЕМЫХ. Давайте называть всё своими именами). Так почему бы, эти же суммы не показывать на счетах, возможно другим цветом, и ни в коем случае не отдельной колонкой.
И кстати не отдельной линией, а линией другого цвета (это про графики). Так что аналогия полная. График более нагляден для анализа периода, а запланированная операция имеет смысл - запланированное изменение РЕЗУЛЬТИРУЮЩЕЙ суммы. Так почему-бы не показать?
И ещё. (извиняюсь, я только что с планёрки - так бардак в изложении это оттуда. Слова не успевают за кипящим разумом)
В чём смысл вот такого действия. Через два дня (будущее время) я заплатил ( свершившийся факт, по флажку операция выполнена) за квартиру, деньгами которые поступили на счёт (снова по флажку) завтра???? Это уже машина времени получается.
С уважением....
Ещё раз извиняюсь за стиль изложения...

Dervish: В принципе это можно реализовать. Я пока не обещаю, подумаю, ладно?

Отложенные операции - последний штрих? (часть первая) де Багер 09/08/2002 03:06 #

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

Начали!
а) "0" - у отложенных (повторяющихся) операций нет времени, каждая след. исполняется (предлагается) в 00.00.00.
Это не правильно. У банка, например, транзакция проходит в 9.00 и 14.00. Это важно, и ни каких толкований не может быть. У операции ЕСТЬ время. Не надо его выдумывать.

б) "0" - при удалении отложенной операции должен быть вопрос "только эту? или всю не исполненную (позднюю) СЕРИЮ"
в) "0" - я могу изменить дату/время одиночной операции из серии (или всей серии - см. предыдущий "0")
г) "0" - не исполнение (оно опциональное - ПОМНИМ!) одной операции из серии не влияет на план операций.
д) "0" - если дата операции больше текущей, нельзя активизировать флажок "выполнена".(Извиняюсь - реализовано).
е) "0" - в любое время, позже планового, я могу провести операцию руками (Вася пришёл за деньгами только сегодня).

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

Что же касательно реализации вашего списка пожеланий, то, в принципе, возражений особых нет, надо только оценить, насколько это будет затратно в смысле сложности программирования. А этого я пока сделать не могу.

Я пронумеровал ваши пожелания, чтобы ссылаться на них. Начали!

а, б) возражений нет.

в) изменить дату/время всей серии можно уже сейчас. Равно как и ближайшей операции в серии. А вот изменять дату/время второй операции, третьей и так далее, это, боюсь, просто нереально по соображениям вышеоглашённой принципиальной оговорки.

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

д, е) честно говоря, не совсем понял.

И ещё одно. В майкрософтовских планировщиках (Outlook, Schedule) тоже реализован механизм повторений. Правда, не операций, а задач. Так вот, он реализован именно так, как у меня серии операций - одной строкой на всю серию. Я заимствовал подход к повторению у них, поскольку посчитал, что это правильно.

принципы и не принципы де Багер 13/08/2002 00:12 #

.....Добрый день.
Многого я не понимаю по жизни...
Вот например: если человек декларирующий свою приверженность к опциональности (свободе выбора) сообщает, что есть вопросы принципиальные..... Как то не вяжется.
Хотя конечно, есть ещё и клуб пофигистов в этом мире.

Теперь серьёзно.
Я не собираюсь Вас отговаривать от хранения повторяющихся операций, в базе, одной записью. Это реализация, она дело автора, и дай ему (т.е. Вам) Бог здоровья.
Вопрос в том как я буду работать с этими данными, что я буду видеть и т.д.
Другими словами - отложенные операции должны отображаться в соответствии с выставленным фильтром даты (которого у майкрософтовских планировщиков нет). А уж сколько там строк в базе - не моё дело.
Кроме того, как я и писал раньше, Вы же обрабатываете ВСЕ операции при построении графика. Почему же при построении списка операций Вы меняете логику?

Dervish: Может быть, я так сделал только лишь потому, что так было проще в реализации: не надо было заморачиваться насчёт disabled-строчек в списке операций. А они должны быть disabled для тех операций, которые идут в серии, начиная со второй. Потому что над ними нельзя совершать никаких действий.

Хотя, можно сделать так, чтобы и действия над ними можно было совершать, но это будет тогда очень нетривиально в реализации.

Про "нетривиальность в реализации" де Багер 15/08/2002 20:16 #

Вот она - плата за принципиальность.
В порядке обсуждения :
1. вариант первый - даём серии индекс (меняем формат базы), и храним КАЖДУЮ операцию (логика в том, что они все равнозначные, а отложенные или серийные, может даже сверхобязательные и т.д. неважно. Они все ОПЕРАЦИИ)
2. При генерации ОТОБРАЖЕНИЯ пишем в объект (трудно говорить куда, не зная реализации) некоторую бульку. И уже по ней генерируем мессадж - типа "НЕЛЬЗЯ МЕНЯТЬ" (всё равно изменения не сохранятся - негде!!!). Правда это грабли функциональности, и следом будет вопрос - ПОЧЕМУ?
3. Если делать как Вы пишете - т.е. при сушествуюшем порядке давать возможность менять след. запись - то мы придём к пункту №1 - ежеоперационное хранение.

Конечно Вам решать, но пока хотелось бы видеть хотя-бы отображение ВСЕХ операций в соответствии с фильтром. А дальше будем поглядеть.

Заранее спасибо. Ждёмссс....

Dervish: Вы серьёзно считаете, что беспринципность, это хорошо? Впрочем, вопрос риторический, я предлагаю прекратить обсуждение общефилософских тем.

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

Кажется, у меня появилась некоторая идея, можно реализовать всё то, о чём вы говорите. А идея такова: пусть в базе хранится одна строчка, а показываются, действительно все экземпляры операции, которые будут сгенерированы в серии. И всякий раз, если пользователь попробует изменить какую-то операцию из серии, ему просто будет выдаваться вопрос: "Изменить всю серию или только эту операцию?". Если он отвечает, что всю, тогда изменяется единственная строчка в базе. Если же он отвечает, что только эту, то Cash "развернёт" серию в последовательность обычных (невыполненных) операций, а остаток серии останется одной строчкой.

Годится?

некоторая идея де Багер 16/08/2002 20:11 #

Ну почему-же "некоторая"?
Вполне рабочее решение. Двумя руками "За". Готов нажимать за Вас клавиши.
Успехов!

Dervish: Почему-то вспомнился анекдот: - Мне тут программа сказала Press Any Key, а я никак не могу найти на клавиатуре этот Any Key.

А вообще я рад, что мы нашли на мой взгляд неплохое решение.

пункт в) г) де Багер 13/08/2002 00:25 #

По дате второй операции - согласен, пусть будет как есть. Принципы - дело святое. Вернёмся при обсуждении бюджета/прогноза.

по пункту г) поясняю.
Серия запланирована как автоматическая (или с напоминанием). Перед наступлением времени, я могу снять исполнение операции (для дальнейшей коррекции), но серия продолжится.

д) В серийных операциях реализованно. Осталось сделать только в одиночных отложенных операциях. Буквально: указывая дату больше текушей я заявляю о том что операция
1) отложенная
2) не выполненная
зачем же мне ещё и флажок снимать?

Dervish: Сколько кликов займёт удаление первой операции из серии сейчас:
1. Выполнить операцию (один клик левой кнопкой мыши). Даже выбирать её перед этим не нужно.
2. Ещё один клик на кнопке "Удалить". Или, если она вдруг планируется к исполнению позже, то просто клик на чекбоксе.

Что мы экономим? Один клик? Получится ли?

Про (д): то есть, речь идёт о том, чтобы автоматически устанавливать/снимать флажок "выполнено" при изменении даты вводимой операции? Я верно понял?
А как быть, если мы правим существующую операцию, а не вводим новую?

Опс!! (часть вторая, не поместившаяся) де Багер 09/08/2002 03:07 #

"1" - Автоматическое исполнение (опционально). (Я вообще сторонник опциональности ВСЕГО. т.е. "будет ТАК, если Я НЕ смогу сделать по другому").

Вопрос по поводу частоты проверки условия исполнения. М.б. варианты:
1. один раз при входе в программу (ваше время не пришло, приходите завтра)
2. по таймеру - это нагрузит систему. В свою очередь таймер м.б. общим (каждые 5 минут проверять (больше делать нечего!!) пора/не пора, а если пора, то кому?), или же каждое отложенное событие на СЕГОДНЯ будет посылать системе уведомление (кажется я навязываю реализацию!?).

"2" - Периодичность.
Плановая операция "один раз в месяц", не может быть назначена на 20.??.??, и в то же время первый раз проведена 15.??.??.
У меня не может, но мир так ОГРОМЕН!!!!

Dervish: Я тоже сторонник опциональности. И вседозволенности. В полной мере проявить это в первой версии Cash не получилось только по собственной глупости: я посчитал, что если это удобно мне, значит, это будет удобно всем. Плохая позиция, будем исправлять ошибки.

Таймер не нагрузит систему. Никоим образом. Просто работая с программными монстрами, сделанными крайне неэффективно, мы привыкли недооценивать скорости процессоров. А между тем, даже старенький 386-й процессор очень и очень шустр. Но это, увы, проявляется только тогда, когда для выполнения простейшей операции 2 + 2 не приходится инициализировать кучу библиотек. Так что, за это не беспокойтесь.

Про назначение операции на определённое число каждого месяца: я мне казалось, что это возможно.

Проверьте ещё раз диалог операций (поддиалог "повторение"). Там самый верхний радиобаттон за это отвечает. Или я что-то неверно понял?

повторяющиеся операции де Багер 03/09/2002 22:42 #

Вот ещё о чём забыл попросить.
Если можно, хотелось бы существующий значёк повторения рисовать только для операций с признаком "выполнять всегда".
А для тех, у которых число повторений известно - вместо него указывать: операция/из_всего (в банковских бумажных отчётах пишут следующим образом - 3/5). Очень информативно.
Этот вопрос уже возникал (не вспомню где) и помнится решения тогда не было найдено.
Может поищем??? Очень хочется.

Dervish: Согласен, что это будет информативнее и нагляднее. Для меня очевидно, что графикой такие вещи делать бессмысленно и бесполезно, так что остаётся вариант: прямо так и писать "3/5". Может быть, в какой-то отдельной колонке. Не знаю, надо подумать.

Может быть, будут предложения?

Форум Отложенные операции