[abilitycash] |dervish.| Остаток 06416.06417
AbilityCashList #3288 (подписчиков: 39)
Рискну вставить свои 5 копеек :)
Мне кажется, основная проблема этой дискуссии в недопонимании <u>причин</u> обозначенного
в теме предложения.
Идея ведь совсем не в том, чтобы изобрести новый бухучет. А просто в том, чтобы
несколько упростить работу с программой.
На том же самом примере с кабаком и такси.
Утром проснувшись пересчитал деньги в кошельке и внес в AC операцию за 26.02.2006
10:00 с типом <u>остаток</u> и соотв. значением. Деньги в кошельке - это объективная
реальность. И после ввода этого остатака программа эту реальность адекватно отражает.
Уже хорошо. (При этом я, как минимум, немного сэкономил на простоте ввода: вместо
выражения типа <предыдущий остаток> - <текущий остаток> я просто
ввел значение остатка на данный момент - посчитать разность программа может и
сама.)
Далее. Если на следующий день (через неделю, через месяц) я вспомнил, что возвращался
из кабака на такси (и для меня, например, важно это уточнение), я просто введу
операцию расхода за 26.02.2006 03:00 с суммой, потраченной на такси. И все! Остаток
на момент времени 26.02.2006 10:00 останется неизменным! Именно тем, который
я тогда насчитал в кошельке. Соответственно, все последующие операции не "поедут".
Без наличия же типа операций "остаток" мне придется, как минимум, еще
отыскать ту операцию "кабак" и откорректировать ее сумму на соответствующую
величину. Т.е. приложить дополнительные усилия, которых вполне можно было бы
избежать.
Т.е., другими словами, в отличие от прихода/расхода/перевода, которые фиксируют
сумму операции и на ее основании вычисляют текущее значение баланса, операция
типа "остаток" наоборот фиксирует именно значение баланса и на его
основании вычисляет сумму операции.
Очевидно также, к операции "остаток" неприменимы классификаторы. У
нее не может быть статьи или агента.
А в будущем, для анализа можно было бы сделать фильтр для поиска операций "остаток"
с суммой получившейся больше заданного порога. Но это к слову. :)
