Тут в соседней ветке форума разгорелось обсуждение операций фиксирования остатка после того, как я выразил желание убрать этот вид операций из программы. Наверное следует пояснить, почему именно мне так не нравятся эти операции.
 
Собственно, претензий у меня всего две:
 
1. Двойственность операции фиксирования остатка.
 
Одна и та же операция может выступать как операция прихода (если "входящий" остаток ниже "исходящего") и как операция расхода ("входящий" остаток больше "исходящего"). Причем поведение операции может изменяться исключительно от внешних обстоятельств ("входящий" остаток). Меня это огорчает потому, что для операции фиксирования остатка невозможно назначить статью расхода (она может оказаться операцией прихода) и статью прихода назначить тоже нельзя. В итоге получается, что для такой операции нужно либо предусматривать два набора классификаторов, либо не предусматривать ввод классификаторов вообще (что я и сделал в этой реализации). Я же считаю нормальным и правильным, когда все, совершенно все операции имеют назначенные статьи прихода или расхода. Это позволяет мне иметь полную и правильную картину по структуре доходов и расходов. А операция фиксирования остатка генерирует "дырку" без назначенной статьи. Потому я ее и не использую в своем учете.
 
Есть одна мысль, как можно восстановить целостность данных, обеспечив аналогичную функциональность. Для этого можно сделать так, чтобы при вводе операции прихода или расхода можно было выбирать, что именно вводится: сумма операции или остаток после нее. Если вводится сумма операции, то программа ведет себя точно так же, как и сейчас: вычисляет остаток после этой операции. Если же вводится остаток, то программа будет вычислять сумму операции.
 
Скажем, текущий остаток по счету составляет 1000 рублей. Я хочу ввести операцию расхода (Р) так, чтоб остаток после ее выполнения составил 800 рублей. Ввожу такую операцию расхода, программа рассчитывает сумму расхода (200 рублей) и вводит такую операцию. Если я вспомню, куда потратил эти двести рублей, я смогу ввести новую операцию на 200 рублей, но поскольку я уже фиксировал остаток в 800 рублей в операции (Р), то она превратится в операцию расхода с нулевой суммой.
 
Другими словами, операция расхода с фиксированным остатком всегда остается операцией расхода, но сама вычисляет сумму операции при этом, однако, она никогда не сможет увеличить остаток по счету.
 
Нынешняя операция фиксирования остатка в этом случае просто заменяется двумя операциями, одной операцией расхода с фиксированным остатком и одной операцией прихода с фиксированным остатком. В зависимости от входящего остатка, либо одна либо вторая операция будет активизироваться. А у неактивной операции сумма операции будет просто равна нулю. И у всех операций будет возможность ввести все статьи прихода и расхода, не будет недооформленных операций.
 
Это будет работать, но, во-первых, это очень сложно объяснить, а значит, скорее всего эта идея плоха. А во-вторых, даже такое решение не снимает вторую проблему с фиксированными операциями:
 
2. Трудности в реализации операций фиксирования остатка в реляционных базах данных.
 
Давайте посмотрим, что должна сделать программа, если мы добавляем в массив операций, скажем, операцию расхода. А должно быть вот что: программа должна обновить все остатки по операциям, начиная с даты добавляемой операции. При добавлении операции расхода, база данных будет обновляться примерно так: UPDATE SET [остаток] = [остаток] - [сумма добавляемого расхода] WHERE [дата операции после добавляемой].
 
Но в тот момент, когда программа начинает поддерживать операции фиксирования остатка, предложение WHERE должно быть переписано и должно обновлять все операции с датой после даты вводимой операции и до первой встреченной операции фиксирования остатка. А после этого еще нужно будет и операцию фиксирования остатка пересчитать.
 
Вот почему мне не нравятся операции фиксирования остатка.