Сорри, не знаком с сутью операции "Остаток".
Можно в двух словах - для чего и как?
Может мне этого и не хватает
(кроме пакетных операций)
Да, пожалуйста.
Dervish
03/07/2009 14:16
#
Если операция прихода всегда увеличивает остаток по счету на заданную величину (прихода), а операция расхода - уменьшает остаток, то операция фиксации остатка служит именно для того, чтобы указать, что по данному счету на данный момент времени был данный остаток.
Операция фиксации остатка может быть удобна при сверке остатков по счетам. Скажем, если вы проверяете остаток по счету "Наличные", то пересчитав остаток в вашем кошельке вы можете сразу ввести в программу операцию остатка. И тут же увидеть какое расхождение, на какую сумму были не введены операции.
сенкс :) будем пробовать (-)
Odin
03/07/2009 14:43
#
Заметил глюк с этой операцией, если сначала добавить операцию остаток, нажать ок, посмотреть сумму, а потом эту операцию изменить и сделать тип "расход" то операция так и остается как "остаток"
Есть такое дело.
Dervish
03/07/2009 17:19
#
Спасибо за сообщение. Эта ошибка уже исправлена, в 217-й сборке все будет работать правильно.
А можно уточнить?
Andrey_msk
03/07/2009 20:25
#
Зачем нужна эта операция, если она автоматом корректирует приходом или расходом сумму остатка? Получается она не только информативная. Всё равно после неё нужно заводить недостающую операцию и удалять операцию фиксации остатка. Или я не понял весь глубокий смысл?
предложение
Alexey
03/07/2009 21:49
#
предлагаю сделать возможность указать статью для этой операции. обычно как: денег меньше чем есть на счете, есть статья по которой списываются неучтенные расходы... с такой операцией все гораздо проще становится, но в отчетах она появляется как расход без статьи.
вариант с приходом не рассматривается
А, собственно,...
Dervish
03/07/2009 21:54
#
...почему вариант с приходом не рассматривается? Если делать, то делать для общего случая. То есть, для операций фиксации остатка нужно будет указывать два набора классификаторов, один для варианта операции прихода, второй для варианта операции расхода.
Это будет ооочень непросто, я как-то рассматривал нынешний вариант операции остатка как компромиссный вариант для тех, кому она нужна.
Вы в точности повторяете...
Dervish
03/07/2009 21:52
#
...мою аргументацию против этой операции. Но целый ряд пользователей меня очень просили сделать ее. Говорили, что такая операция нужна "чтобы зафиксировать остаток а потом вспоминать куда потратил деньги". Вот я и сделал.
Если хотите, могу добавить настройку, которая будет прятать этот тип операции в диалоге добавления операции. Спрячете ее и будет вам счастье. Добавить настройку?
Операция "Остаток"
kubrin
03/07/2009 22:57
#
... в таком виде, мне кажется, вообще не нужна. Во-первых, нельзя отфильтовать в списке такие операции. Нельзя отнести неучтённый расход на агента, проект, место и т.д., которые могут быть известны.
Я думаю, было бы здорово в диалоге ввода операции просто иметь "галочку", которая обозначала бы, что вводится не сумма прихода расхода, а остаток, который должен в результате операции получится. Т.е. обычно автоматически рассчитывается остаток, а тут автоматически рассчитывается расход или приход. При этом полученная сумма может быть дополнительно зафиксирована (другой "галочкой"), что в интерфейсе отображается "замочком". Теперь, когда мы вводим операции задним числом, то сейчас у нас автоматом пересчитываются остатки. А вот для операций с "замочком", наоборот в этом случае пересчитывается величина прихода расхода.
Никакого специального вида операции не надо. Операция с "замочком" - это обычая операция, только фиксируется результат а не слагаемое. При вводе фиксированного остатка должны быть доступны все классификаторы. При данном подходе теряется смысл и в разделении операций на операции прихода и расхода. Если сумма положительная - это приход, если получилась отрицательная - это расход. Совершенно логично, что может получиться и нулевая сумма, о которой мы уже говорили.
Сейчас, когда сумма в кошельке не сходится с программой, я завожу операцию расхода по статье "ХЗЧ" (Хрен знает что), указывая агента и место, а потом вспоминаю, ввожу операции задним числом и правли руками расход в ХЗЧ. Не факт, что удастся свести его к нулю, но всегда можно отфильтровать операции по ХЗЧ.
Интересное предложение.
Dervish
03/07/2009 23:58
#
Но в этом случае операция расхода с галочкой "Остаток" будет подгонять остаток только в меньшую сторону, а если на счете окажется избыток денег, она работать не будет. Не смущает?
И еще...
Lexx
04/07/2009 00:28
#
У нас в армии при проверке патронов или чего-то другого проверяющими делалась контрольная запись в журнале, и она была КРАСНОГО цвета. "Остаток" по сути тоже, просто контрольная строка. Может ее сделать цветной?
Не понял...
kubrin
04/07/2009 15:03
#
... почему только в меньшую? Если будет избыток денег на счёте - значит получится операция прихода. Как я написал выше, нет смысла вообще задавать тип операции приход - расход. Есть просто операция со знаком плюс или минус.
Кстати, с точки зрения эргономики выбирать тип операции в группе Radio button-ов излишне. Было бы лучше, если фокус ввода в диалоге сразу попадал в поле сумма. Расход вводим с минусом, приход с плюсом. (Что страшного? Лимиты бюджетов вводим с минусом и ничего) Ведь в списке операций как раз нет никакого прихода и расхода, есть только одна колонка "сумма". Я думаю, нет разделения операций на приход - расход и программно. А раз нет разделения, то корриктировать сумму можно и в плюс и в минус и сводить к нулю. Для операции "перевода" лучше вообще иметь отдельный диалог, вызываемый, скажем, по Shift-Insert, чем тыкать мышкой в одном диалоге, меняя его начинку.
У операций прихода...
Dervish
04/07/2009 17:34
#
...и расхода, в общем случае, может быть разный набор классификаторов. Это означает, что для операции остатка придется вводить два комплекта классификаторов. Один для случая когда эта операция превращается, фактически, в операцию прихода, второй - расхода. В этом проблема.
Да, точно...
kubrin
05/07/2009 12:10
#
... я об этом не подумал. Вероятно, Сергей, по той причине, что я практически сразу отказался от идеи разделения классификаторов по видам операций. Например, классификатор "Статьи". Статью "зарплата" хотелось бы видеть только в операция прихода, а вот статьи "автомобиль", "бытовая техника", "детские вещи" хотелось бы видеть и в операциях прихода, и в операциях расхода, поскольку на автомобиле можно "подбомбить", а вещи продать. Заводить для этого разные статьи не логично. Поэтому, может быть целесообразней сделать разделение по видам операций, как фильтр, который можно задать отдельно для каждой статьи и, естественно, всегда иметь возможность поменять это разделение?
Заводить для этого разные статьи не логично.
Не согласен. У меня в таких случаях именно разные статьи. Может быть, немного отличающиеся названиями, например, "Проценты полученные" и "Проценты выданные".
Поэтому, может быть целесообразней сделать разделение по видам операций, как фильтр, который можно задать отдельно для каждой статьи и, естественно, всегда иметь возможность поменять это разделение?
А эту фразу я просто не понял.
Можно, конечно, ...
kubrin
06/07/2009 13:51
#
... заводить разные статьи: "вещи купленные", "вещи проданные", "Траты на автомобиль", "доходы от автомобиля"... Так и стоит сделать, если бы регулярно, что-то продавалось и бомбилось. Если же я продал раз в год старую детскую кроватку, то иметь отделяную статью дохода излишне. Короче - всё зависит от ситуации и от вкусов пользователя.
А, собственно, на что принципиально (с точки зрения алгоритмов программы) влияет "галочка" "Разделять по виду операции"? Мне кажется ни на что. Просто автоматом создаются две статьи "Все статьи расхода" и "Все статьи прихода", а корень "Статьи" скрывается. Одина предопределённая статья используется в диалоге добавления операции для расхода, другая для прихода. А дальше программе это разделение по фигу.
Про фильтр, наверно, я неудачно сформулировал. Идея взята из программы CashFly. Там есть статьи прихода и статьи расхода, но для любой статьи можно установить флажок "использовать статью и в приходе и в расходе" В результате одна и та же статья отображается и в дереве статей прихода и в дереве статей расхода. Это удобно. Пофантазируем. Есть у меня статья расхода "ЖКХ". А вдруг я однажды я сильно переплажу за электричество и в конце года Мосэнерго вернёт мне тысячу рублей? Я бы поставил галучку у статьи "ЖКХ" чтобы она отобразилась с статьях дохода и ввёл этот доход по статье "ЖКХ". Потом галочку снова убрал.
На самом деле у меня не так много статей, поэтому в существующей реализации классификаторов мне удобней не разделять статьи по видам операций вовсе. Хорошо, что такая возможность есть.
абсолютно согласен...
Олег
01/09/2009 01:42
#
в текущем варианте реализации операция остаток теряет смысл. Я был одним из тех, кто просил эту функциональность реализовать. Мне она была нужна, чтобы расчитывать операцию по одному из значений классификаторов по остаточному принципу (по тому, сколько денег осталось в бумажнике).
Сейчас же, насколько я понимаю, расход или приход по операции остаток идет в "неучтенные операции", что существенно снижает гибкость этого инструмента, а во многих случаях делает его бесполезным. Ведь часто расходы на питание, или на транспорт можно считать по остатку. А для этих расходов есть свои классификаторы.
Есть операции расхода. Есть операции прихода. В общем случае у них могут быть разный набор классификаторов. Например, для операции прихода никак нельзя указать статью расхода "Все расходы на меня".
Теперь представим себе вот такую ситуацию: в кармане 500 рублей, а в программе значится - 1000. Я ввожу операцию остатка (неважно как, галочками или отдельной операцией) в которой указываю вышеупомянутую статью расхода "Все расходы на меня". А потом вспоминаю, что неделю назад я, скажем, еще заправил автомобиль на 600 рублей. Ввожу ее задним числом и получаю что моя операция остатка превратилась в операцию прихода на сумму 100 рублей. Прихода! С расходной статьей "Все расходы на меня".
Вот такая ситуация не должна возникать в принципе. Она должна быть невозможной. Поэтому, если вы хотите, чтобы операция остатка содержала классификаторы, то в программе должно указываться два комплекта классификаторов, один для операции расхода, другой - для операции прихода.
Да и то, поработав некоторое время с операциями фиксации остатка в своей базе данных я еще больше укрепился во мнении, что операции фиксации остатка - зло. Вредное и ненужное зло. Впрочем, я отклонился от темы.
Реализовывать два комплекта классификаторов на одну операцию я не хочу, это очень серьезная переделка. Можно ли сделать так, чтобы для операции фиксации остатка вводился всего один комплект классификаторов? Один вариант я предложил: сделать так, чтобы при вводе операции фиксации остатка сразу указывалось, это операция прихода или расхода. Если, например, указывается, что это операция расхода, то она будет аккуратно корректировать сумму своей операции до тех пор, пока сумма операции будет отрицательной. Но как только действия пользователя приведут к тому, что сумма этой операции должна будет стать положительной (то есть, операция превратится в операцию прихода), то программа принудительно оставит ее нулевой. И тогда итоговый остаток от этой операции "уплывет" и станет не тем, который был введен.
В таком варианте реализации для "полноценной" фиксации остатка, чтобы он вообще не изменялся ни в какую сторону нужно будет ввести подряд две операции, одну - операцию расхода и вторую - операцию прихода. Два комплекта классификаторов. Собственно, с этого я и начинал.
...
Олег
05/09/2009 14:59
#
У меня даже и мысли не было, что могут возникнуть сложности из-за отличий наборов классификаторов для операций прихода и расхода. А ведь в этом действительно есть нерешенное противоречие.
Ваше решение с жестким указанием, будет операцией Остатока операцией прихода или расхода, мне кажется разумным.
К тому же через введение двух смежных операций Остатка (прихода и расхода) можно будет добиться функциональности Остатка, когда он сможет быть и приходом и расходом.
А в будущем можно будет эти операции связать, когда объединение операций будет реализовано.
Кстати, для меня практически актуальность данной операции пропала. После покупки коммуникатора, я взял за правило записывать все операции (в качестве заметок), по которым мне не дают чеков. Недавно вернулся из командировки. Ошибка составила всего 10 рублей.
...
Олег
05/09/2009 15:04
#
Но я по прежнему считаю, что эта операция необходима и эту фунциональности нужно оставить в программе.
Т.к. она повышает гибкость программы, уменьшает колчество исправлений в случае "вспоменнных" операций (если учет ведется по остаточному принципу... я знаю, что некоторые люди ведут его так... и я не так давно вел).
