создать новую тему раскрыть все
 
Можно ли реализовать мастер, который бы проводил анализ имеющихся операций и на основании этого предлагал создать планируемые повторяющиеся операции.
свернуть/развернуть ветвь ну, а [[пацак 22/07/2007 21:27] # написать ответ
 
зачем телеге GPRS?
 
Вы видимо хотели спросить, как определить, что нужно создать планируемую операцию. Предлагаю следующий способ:  
1. Пользователь определяет классификатор (?классификаторы), по которому будет проводиться анализ, либо выбирается классификатор, имеющий наибольшее количество элементов.
2. Мастер (wizard) начинает последовательно перебирать элементы классификатора (для простоты изложения давайте будем считать, что это "Статьи") и просматривать все операции на наличие операций с текущим классификатором, по сути, накладывать фильтр.
3. В случае если операций не найдено или найдена только одна операция, то ничего не делать.
4. В случае если найдено несколько операций по текущей статье, проводится проверка, нет ли уже такой планируемой операции.
5. Если нет, то создается планируемая операция как копия последней, при этом ее дата определяется как дата последней плюс разница между двумя последними операциями.
6. В конце анализа мастер (wizard) предлагает таблицу найденных повторений и предлагает выбрать пользователю какие из них сохранить в базе.
свернуть/развернуть ветвь Дополнение [Denis 23/07/2007 17:39] # написать ответ
 
Перед началом анализа можно, чтобы пользователь определял параметры анализа:  
- период времени, который стоит просматривать;
- счета, которые нужно анализировать;
- узел классификатора, с которого начнется анализ.
свернуть/развернуть ветвь ну, а [пацак][ 24/07/2007 01:13] # написать ответ
 
теперь мой маленький пример.
Ежемесячное начисление % на депозит.
Примитивнейшая операция. Но она выполняется банком только в рабочий день. Ну, а если Вы молдаванин, то Ваш Кеш должен знать все молдавские праздники, которые попадут на рабочие дни и, соответственно, сдвинут день начисления %-ов. Ну, а если вы хохол, то знание праздников не поможет, потому что кроме Кабинета Министров, например Киевский голова может назначить праздничный день по своему усмотрению.
Так вот, только для этой примитивной "повторяющейся операции" надо столько гавна в Кеше хранить. И зачем.
Вы можете сказать, можно % начислять каждый 30-й день. Но это же не учет будет, а профанация. Вы 1-го "начислили" себе %-ты, а они фактически будут у Вас 3-го в понедельник, например. И т.п.
 
Все намного проще, это можно отдать на откуп пользователю, есть два варианта:
1. Перед тем как сохранять операцию в базе дать возможность пользователю поменять планируемую дату и сумму операции.
2. После того как операции сохранены в базе, пользователь по ним пройдется и скорректирует даты, суммы.
 
С точки зрения удобства предпочтителен первый вариант, с точки зрения простоты реализации лучше второй.
свернуть/развернуть ветвь ну, [пацак] 24/07/2007 11:42] # написать ответ
 
~ура все это. Например, у меня депозит с возможностью пополнения и сложным процентом. Невозможно "автоматизировать" такую операцию. Ее правка обойдется дороже, чем сразу все делать ручками.
Вернее, можно автоматизировать. Но Кеш должен стать монстром, хранящим все возможные варианты и предустановки, календари и особые условия.
 
Идем по второму кругу. Перечитайте мое последнее сообщение, там сказано - предлагается, чтобы сумму и дату операции уточнял сам пользователь.
 
Задача мастера планируемых операций не в полной автоматизации "всего", а в помощи пользователю определения закономерностей, чтобы потом пользователь уточнил необходимые параметры.
свернуть/развернуть ветвь ну, [пацак] 24/07/2007 12:57] # написать ответ
 
не люблю советовать (разработчику).
Но вместо предлагаемого "мастера", куда бы полезней
былы бы фича "запоминания" формул в операциях с возможностью отображения суммы/формулы, и редактирования последней.
Это помогло бы и в повторяющихся операциях, начислении процентов на вклады, погашение кредитов, количественном учете и пр. и пр.
"Долой безумную автоматизацию, превращающую пользователя в раба процедур".
Задолбали автоматы типа, "вы позвонили в регистратуру межрайонной поликлиники северозападного округа. Если у вас геморрой, нажмите 1, запор - нажмите 2 ... или дождитесь ответа оператора ..."
свернуть/развернуть ветвь ну, [Denis ® 24/07/2007 20:32] # написать ответ
 
не любите советовать (разработчику), так не делайте этого, никто не заставляет.
 
и дату и сумму, то для этих целей вполне подойдут повторяющиеся операции.
 
Повторяющиеся операции подойдут, но для того чтобы их сформировать хотелось бы, чтобы программа помогла, провела анализ имеющихся операций и увидела закономерности.
 
алгоритм? Я вот с трудом себе представляю на основании каких данных программа может сделать выводы о периодичности подобных операций.
свернуть/развернуть ветвь ну, [пацак] 25/07/2007 14:40] # написать ответ
 
чтобы алгоритм описать, ему тоже мастер нужен
свернуть/развернуть ветвь ну, [Denis ® 26/07/2007 02:32] # написать ответ
 
когда нечего сказать, лучше промолчите, за умного, может, сойдете To wink
 
На 10 сообщений вверх описано как это возможно сделать. Если не совсем ясно описал, то скажите, готов дать необходимые уточнения.
свернуть/развернуть ветвь Прочитал [Loki 26/07/2007 11:13] # написать ответ
 
представляю какой бардак будет если натравить подобный визард на статьи.
Наверняка у всех есть такие статьи как продукты, одежда, бензин, дополнительные заработки, медицина и далее до бесконечности. Все они повторяются и прекрасно попадают под описанный вами алгоритм, но периодическими они не являются и суммы на них не совпадают.
То есть ваш фильтр вывалит все счета, где было более одной операции. Где-то у вас ошибка.
свернуть/развернуть ветвь ну, [пацак] 26/07/2007 11:36] # написать ответ
 
конечно, в голове.
свернуть/развернуть ветвь ну, [Denis 26/07/2007 12:10] # написать ответ
 
вы правы, если проблема в учете, то заниматься планированием крайне проблематично. А вот построение учетной модели как раз зависит от того, что находится в голове.
 
Ошибка решена Well
В следующем сообщении после описания - "Дополнение" написано: "Перед началом анализа можно, чтобы пользователь определял параметры анализа: ...", таким образом, анализ можно будет ограничивать, и запускать по интересующим разделам классификаторов.
 
Возможно непонимание связано с тем, что расходы в программу вводятся не как расход, а как категория (группа) расходов, если так, что действительно польза от Wizard`а будет небольшая.
 
У меня те же "Продукты" еще детализируются
1. Продукты
1.1. Молочные
1.1.1. Молоко
1.1.2. Йогурт
 
Поэтому, на таком плане счетов, мастер должен отработать корректно и найти закономерности, которыми можно пользоваться.
 
На прошлой неделе я проезжал на машине по 100 км в день, а на этой за два дня проехал 600. Так что заправляться пришлось чаще - тут ваш механизм пролетает.
Молоко я покупал раз в неделю, а вчера прошла гроза и молоко скисло - купил новое, а завтра наступила жара и я его тоже выпил...
Траты которые производятся по мере надобности - НЕ периодические. И не надо в них искать зависимостей.
Ремонт автомобиля, если он внеплановый - не периодический, медицинское обслуживание - тоже самое, покупка продуктов - ну вы поняли. Никто кроме вас не сможет определить зависимостей...
 
Если в жизни хаос и как следствие большинство операций "НЕ периодические", то действительно браться за планирование не стоит, здесь лучше разработать механизм реагирования - "тушения пожаров".
 
Я понял, что такая функциональность нужна только мне, и даже нашел способ как ее решить, выгрузка в Excel, анализ средствами VBA и последующий импорт мне помогут. Well
свернуть/развернуть ветвь ну, [пацак] 26/07/2007 15:25] # написать ответ
 
круто, наконец то на 22 посту дошло ...
 
...рассказав о формате (и кодировке) поля, задающего период повторения. Там сейчас шестнадцатиричная муть заносится, но ее можно описать.