создать новую тему раскрыть все
 
Тут в соседней ветке форума разгорелось обсуждение операций фиксирования остатка после того, как я выразил желание убрать этот вид операций из программы. Наверное следует пояснить, почему именно мне так не нравятся эти операции.
 
Собственно, претензий у меня всего две:
 
1. Двойственность операции фиксирования остатка.
 
Одна и та же операция может выступать как операция прихода (если "входящий" остаток ниже "исходящего") и как операция расхода ("входящий" остаток больше "исходящего"). Причем поведение операции может изменяться исключительно от внешних обстоятельств ("входящий" остаток). Меня это огорчает потому, что для операции фиксирования остатка невозможно назначить статью расхода (она может оказаться операцией прихода) и статью прихода назначить тоже нельзя. В итоге получается, что для такой операции нужно либо предусматривать два набора классификаторов, либо не предусматривать ввод классификаторов вообще (что я и сделал в этой реализации). Я же считаю нормальным и правильным, когда все, совершенно все операции имеют назначенные статьи прихода или расхода. Это позволяет мне иметь полную и правильную картину по структуре доходов и расходов. А операция фиксирования остатка генерирует "дырку" без назначенной статьи. Потому я ее и не использую в своем учете.
 
Есть одна мысль, как можно восстановить целостность данных, обеспечив аналогичную функциональность. Для этого можно сделать так, чтобы при вводе операции прихода или расхода можно было выбирать, что именно вводится: сумма операции или остаток после нее. Если вводится сумма операции, то программа ведет себя точно так же, как и сейчас: вычисляет остаток после этой операции. Если же вводится остаток, то программа будет вычислять сумму операции.
 
Скажем, текущий остаток по счету составляет 1000 рублей. Я хочу ввести операцию расхода (Р) так, чтоб остаток после ее выполнения составил 800 рублей. Ввожу такую операцию расхода, программа рассчитывает сумму расхода (200 рублей) и вводит такую операцию. Если я вспомню, куда потратил эти двести рублей, я смогу ввести новую операцию на 200 рублей, но поскольку я уже фиксировал остаток в 800 рублей в операции (Р), то она превратится в операцию расхода с нулевой суммой.
 
Другими словами, операция расхода с фиксированным остатком всегда остается операцией расхода, но сама вычисляет сумму операции при этом, однако, она никогда не сможет увеличить остаток по счету.
 
Нынешняя операция фиксирования остатка в этом случае просто заменяется двумя операциями, одной операцией расхода с фиксированным остатком и одной операцией прихода с фиксированным остатком. В зависимости от входящего остатка, либо одна либо вторая операция будет активизироваться. А у неактивной операции сумма операции будет просто равна нулю. И у всех операций будет возможность ввести все статьи прихода и расхода, не будет недооформленных операций.
 
Это будет работать, но, во-первых, это очень сложно объяснить, а значит, скорее всего эта идея плоха. А во-вторых, даже такое решение не снимает вторую проблему с фиксированными операциями:
 
2. Трудности в реализации операций фиксирования остатка в реляционных базах данных.
 
Давайте посмотрим, что должна сделать программа, если мы добавляем в массив операций, скажем, операцию расхода. А должно быть вот что: программа должна обновить все остатки по операциям, начиная с даты добавляемой операции. При добавлении операции расхода, база данных будет обновляться примерно так: UPDATE SET [остаток] = [остаток] - [сумма добавляемого расхода] WHERE [дата операции после добавляемой].
 
Но в тот момент, когда программа начинает поддерживать операции фиксирования остатка, предложение WHERE должно быть переписано и должно обновлять все операции с датой после даты вводимой операции и до первой встреченной операции фиксирования остатка. А после этого еще нужно будет и операцию фиксирования остатка пересчитать.
 
Вот почему мне не нравятся операции фиксирования остатка.
 
при вводе два окна: "ввод суммы" и "ввод с-до после суммы".
при "вводе с-до после суммы" программа формирует проводку на сумму, которую автоматически рассчитает. в результате в учете появится обычная запись, только расчет данных при вводе будет облегчен.
кому надо учитывать счетчики будут довольны.
 
в операции "перевод" тоже надо добавить подобный выбор. для тех кто извращается с двойной записью))))))) у них тоже есть счетчики)))))
ммммм........ вот у меня хотелка........ двойная запись ..... два сальдо...... надо еще и выбор сальдо делать.))))))))))))))
вобщем мысли вслух тады)))))))))))
или брать автоматически с-до по счету прихода, счетчик же дает постоянный "приход".
или .... болт забить.... последнее даже лучше)))))
 
воооот....... а еще есть с-до по количеству..... с ним хорошо бы тоже так же вот поманипулировать. ввел "с-до после суммы" или "с-до после количества" (получил количество с +/-), указал цену = получил проводку (приход/расход).
 
проверять нет-ли операции фиксированного остатка в последующих датах? Конечно замедление работы программы может быть. Или операцию назвать как-то по другому, что бы не тянуло ее на одном счете вместе с доходом-расходом использовать..
 
...несомненно, при каждом добавлении (или изменении) операций нужно проверять и корректировать остатки до операции фиксации остатка. В общем, радостного мало.
 
Трудно в понимании, трудно в реализации.
 
Была бы какая-нибудь "умная" вкладка, в которой можно было бы задавать переменные из имеющихся данных, выбирать что с чем складывать, умножать, вычитать, делить, и как обозвать результат.
Доп возможность просто нравится
 
свернуть/развернуть ветвь А можно так [Darkstar 04/02/2013 10:49] # написать ответ
 
Создать по-умолчанию в классификаторе 2 статьи: корректировка баланса - расход, корректировка баланса - приход. В зависимости от знака корректировки, автоматом относить сумму на одну из этих статей.
 
Пожалуйста, не убирайте фиксирование остатка! Это реально очень удобная операция. У нас ведь не бухгалтерская программа! Вы же сами говорили, что те, кому нравится строгость и двойная запись - велкам в 1С.
 
...какое-то решение, чтоб оставить фиксирование остатка. Не обещаю, что эта операция останется в нынешнем виде, но я постараюсь сделать нужную функциональность.
 
WellWellWellVery we!
свернуть/развернуть ветвь по поводу остатка [куверти3 10/02/2013 01:32] # написать ответ
 
Допустим, один человек из семьи понимает как, в какой программе следить за бюджетом. Вот он, допустим, попал в больницу на рубеже месяца. Конечно, удобнее, по возобновлению учёта с новой даты, внести остатки, затем восполнить пробелы, по возможности.
свернуть/развернуть ветвь ура! [krupp 19/02/2013 18:53] # написать ответ
 
ведь это одна из уникальностей Вашей программы.
 
Я вношу сперва остаток, а потом вспоминаю доходы и траты) По мере вспоминания, моя операция остатка бывае то положительной, то отрицательной.
Если все не вспомнить, то в отчетах неопределенность напрягает конешно. Меня бы устроила возможность в операции остатка указывать статтьи конкретные, куда заносить (определять) неопределенные приход или расход.