создать новую тему раскрыть все
 
Как я уже говорил, сейчас я занимаюсь переносом данных программы из собственного формата в SQLite. Это очень удобный момент для того, чтобы предусмотреть в структуре данных какие-то дальнейшие ее доработки. И одна из таких доработок, которую мне хотелось бы сделать, это реализовать неоднократно пробегавшие в хотелках сплиты. А еще лучше, сделать что-то, что будет полезнее сплитов.
 
Свои идеи на эту тему я уже писал в форуме, но, наверное, имеет смысл их повторить.
 
Сплит, в том виде, как он реализован в большинстве других программ, это просто возможность разбить расходную операцию на некоторое количество "подопераций". Классический пример: чек из магазина разбивается на маленькие покупки - пиво и водка отдельно от хлеба и молока. Ну или по конкретным товарным позициям. Традиционный сплит не позволяет скомбинировать вместе две операции, скажем, операцию перевода и операцию расхода, что могло бы быть полезным, например, для автоматического удержания комиссии (расход) при снятии наличных через банкомат (перевод).
 
Поэтому я предпочел бы реализовывать не сплиты, а так называемые "составные операции". Составная операция, это группа объединенных вместе обычных операций, в том числе операций разного типа, приходные, расходные, переводы и даже операции остатка.
 
Пока я думаю применить к составным операциям следующие правила:
 
1. Все операции, входящие в составную операцию должны иметь одну и ту же дату (и время, если включен режим) выполнения.
 
2. Повторяющаяся операция может быть либо обычной операцией, либо составной. Невозможно будет установить режим повторения для операции, которая является частью составной операции.
 
3. Иерархия внутри составной операции не предусматривается. То есть, не будет ограничений на количество операций входящих в составную, но внутри составной операции будет линейный список обычных операций. Никаких папок внутри составной операции и подпапок.
 
Я понимаю, что приведенные выше "правила" по сути являются ограничениями. Поэтому у меня появился вопрос:
 
Сможет ли кто-нибудь привести пример, в котором приведенные выше правила (ограничения) будут сильно мешать?
 
Спасибо.
 
Всецело поддерживаю. Правила кажутся вполне разумными, однако есть еще кое-что, требующее внимания: общий итог составной операции в общем случае может быть не равен сумме ее составляющих, т.е. в главной форме ввода составной операции должно быть отдельное поле итога. С одной стороны, это позволит оперативно контролировать ошибки ввода, а с другой даст возможность автоматически разносить всякие скидки и комиссии по позициям подчиненной формы: для этого стоит предусмотреть отдельную кнопку или всплывающее предупреждение для несовпадающих итогов.
 
...дело тонкое, я предпочел бы вообще не делать специальный диалог для составных операций. По моей задумке, любую обычную операцию можно будет превратить в составную, если в контекстном меню для этой операции выбрать пункт "Добавить подоперацию" (ну или что-то в этом духе). В ответ на это появится обычный диалог добавления операции, в котором будет заблокировано поле даты (напоминаю: дата одна для всех вложенных операций). После того, как этот диалог будет заполнен и будет нажата кнопка "ОК", в списке операций произойдет изменение: прежняя операция превратится в папочку, в которой помимо прежней проводки будет добавлена еще одна, новая операция.
 
Аналогично, если составная операция содержит всего две вложенные операции и пользователь удаляет одну из них, то составная операция превращается в самую обычную.
 
И еще, я не совсем понял, как именно Вы предлагали сделать поля итогов, но я собирался для составных операций проставлять в списке операций суммарное изменение остатка по выбранному в фильтрах счету.
 
... однако грех не использовать появляющиеся возможности для решения типовых задач. Самый очевидный пример со скидками: у нас есть список позиций чека (счета, накладной и т.п), каждая позиция имеет номинальную цену, однако итоговая сумма документа включает скидку, которую сейчас приходится учитывать в виде дохода, что идеологически выглядит довольно противоречиво. Гораздо уместнее разнести эту скидку пропорционально по позициям, что можно будет реализовать в программе с появлением групповых операций. Аналогично сделано в Quicken, Money, 1С Деньги и т.п., при этом в каких-то из этих программ скидка и итоги хранятся отдельно, а где-то таких полей нет и хранятся уже рассчитанные с учетом скидки цены.
 
Если хотя бы одна из под-операций удовлетворяет условиям фильтра, то составная операция будет выводиться целиком? (включая под-операции не удовлетворяющие фильтру)
 
...только те составляющие, которые попадают под условия фильтра.
 
При этом, если в составной операции окажется всего одна составляющая, удовлетворяющая условиям фильтра, то показываться она будет как самая обычная операция.
 
и все?
а если надо что бы счет (дебет или кредит) тоже был один для всех?
а если графа "примечание" одинакова?
 
надо в диалог добавления операции добавить чекбокс "составная". где-нибудь сверху диалога.
после его активации что бы напротив каждой графы становились активными пустые чекбоксы и крыжить что нужно повторять.
в базу добавить артикул составной операции вместо папки, которую надо разворачивать. артикул может состоять из двух частей: порядковый номер (нарастающим итогом) составной операции и общая сумма составной операции.
в диалог добавления операции добавить графы "сумма составной операции" и "неразнесенное сальдо составной операции", которые тоже станут активны после проставления галочки в чекбоксе "составная операция".
сторнирование может выглядеть примерно так:
открываем нужную операцию, меняем в ней "сумму составной операции", автоматически изменяется сумма неразнесенная (будет с минусом), ставим эту сумму в поле "сумма", получаем дубль с противоположным знаком и жмем "ввод".
артикулы тоже надо будет редактировать при этом у всех связанных операций в части итоговой суммы.
 
Пожалуйста, в составной операции можно будет сделать один на всех счет. Или один из счетов. Никто не заставляет делать так, чтобы счета были разные. Ограничение состоит в том, что нельзя будет у частей составной операции сделать разные даты.
 
А с добавлениями в диалог операции я осторожно поступил бы: он и так перегружен.
свернуть/развернуть ветвь изменение даты [Daniil 01/07/2014 01:51] # написать ответ
 
1) а если надо будет редактировать составную операцию?
возврат одной позиции по чеку - вчера купил, сегодня вернул. даты разные. чек старый. расход и исправление не одно и тоже - напрашивается сторно с другой датой.
 
2) в диалоге операции, что бы его не перегружать, и не перегружать интерфейс самой программы, можно сделать вкладку для составных операций. нажал "добавить", а потом выбор вкладки "одиночная" / "составная". по дефолту "одиночная".
 
3) вопрос по сортировке операций возник:
если выбрать сортировку по дате, то как будут сортироваться операции с одной датой? время будет разное? если так, то начал в 23:59 вводить и ........ закончил ввод уже на следующий день. даты должны быть разные.
сорри, получилось уже 2 вопроса в одном. ))))
 
 
1. Ну и редактируйте, редактирование запрещено не будет. Сторно, это очень плохая практика. Я не планирую ее реализовывать. Если нужны еще пояснения (хотя их уже было очень много), это лучше сделать в новой ветке форума.
 
2. Чтобы не перегружать диалог операции, его можно просто оставить как есть. Well
 
3. Я не совсем верно выразился. Общей будет не дата операции, а общим будет момент времени, в который операция была создана. Если включен учет времени, то соответственно, общим будет время.
 
Вообще, можно считать так: составная операция, это одна или несколько операций, которые произошли одновременно. В один и тот же момент времени.
 
Пример: то же самое набившее оскомину снятие денег в банкомате. Снимаем деньги и одновременно платим комиссию.
 
кроме того, сторно есть частный случай "отрицательного расхода", применений которому немало помимо сторнирования.
 
Я не планирую ее реализовывать.

В таком случае учет в программе не может быть полным.
 
 
 
1) сторно придумано давно. применяется на практике многими. было ранее прописано в законах (не знаю как сейчас).
в шапке сайта написано: "AC на все случаи жизни".
так что пользователи если хотят или должны по закону применять сторно, должны иметь возможность это сделать. это их дело и нет предмета для спора. каждый строчит как хочет.
2) если разработчик говорит "не хочу", несмотря на то, что пишет про "все случаи жизни" и вводит таким образом пользователей в заблуждение, то ...... хозяин барин. упорство совершенно непонятно - не нравится сторно, не используй в своем личном учете, но оставь другим возможность для "полета фантазии".
остается только сказать - большое спасибо и за то что есть. программа работает и денег не просит.
 
зы
если бороться авторитарно с плохой практикой, то лучше избавиться от одинарной записи.
 
Не смешивай задачи - если необходим ребут сервера для применения каких-то изменений, то не нужно "за одно" накатывать обновления.
 
Проясните, пожалуйста, принес я чек из супермаркета на 5 т.р. в нем аккумулятор за 2т.р., водка (попросил сосед купить) на 1т.р. и остальное продукты.
Возможно ли будет создать такую конструкцию:
1. Операция расхода (продукты) на 5 т.р.
2. Выбрать "Добавить подоперацию" Операция перевода (на счет "долг") 1 т.р.
3. Выбрать "Добавить подоперацию" Операция расхода (Авто) 2 т.р.
4. При этом операция 1 автоматически уменьшится на 2+1 т.р.
Если да, то отличная реализация сплита. Специально включил Время операции в базе, чтобы группировать операции.
 
...связано неписанное правило администраторов с составными операциями. Если это предупреждение, что не нужно вводить новые возможности вместе с изменением хранилища данных, то я не говорил, что эти возможности сделаю вот прямо сразу же в ближайшей версии. Однако, сейчас я могу проектировать хранилище данных с учетом такой доработки и это будет означать, что мне будет проще сделать это в дальнейшем. Ну, посмотрим в общем.
 
Теперь о конкретном Вашем примере.
 
Да, именно так все и планировалось. С той лишь разницей, что пункт 4 я не планировал делать. В том числе потому, что составные операции, по моей задумке, совсем не привязываются к счету. И вполне возможно будет во втором пункте Вашего примера добавить операцию перевода между двумя другими, совсем "посторонними" счетами.
 
составной операции? В сухом остатке только операции сгруппированные по времени?
Хотелось бы большегоTo wink
 
...возможности откорректировать сумму составной операции? Ну, теоретически, это можно сделать... Просто я пока на эту тему не думал.
свернуть/развернуть ветвь Вы простите, [Meinfin 06/06/2014 19:31] # написать ответ
 
может я не до конца понял задумку, но для "составной операции" о которой вы говорите, даже структуру БД менять не нужно, достаточно добавить признак группировки.
Я правда не пойму как это может упростить ввод операций или улучшить аналитику или для чего это может пригодиться.
свернуть/развернуть ветвь он имеет ввиду [куверти3 07/06/2014 00:23] # написать ответ
 
расшифровка дешифровки шифровки:
в GNUcash в сплите можно разносить под операции на отдельные счета.
имеет смысл это сделать и в абилити.
 
приведу пример:
 
покупка топлива на заправке (общий сплит):1000 р.
заправка бензином 92 по 30.40 - 32.23 л.=980 р. (счет-топливо в автомобиль)
покупка багета (счет - еда) =20 р.
счет=виртуальный, бонусная карта +15 баллов (рублей).
 
...будто я что-то не понимаю.
 
Ну да, я и собирался никак не ограничивать виды операций и счета.
 
Собственно, все ограничения были описаны в корне ветки. Еще раз:
 
1. Составная операция не допускает вложенных других составных операций. Никакой иерархии в составных операциях.
 
2. Все вложенные операции имеют общую дату и время исполнения.
 
3. Из предыдущего пункта вытекает, что повторение можно будет задавать либо для обычной операции (не входящей в составную), либо целиком для составной операции.
 
Ну а дальше, как хотите, можете сделать в одной составной операции:
а) Расход со счета "Наличные"
б) Приход на счет "Наличные"
в) Расход со счета "Долги"
г) Перевод со счета "Депозит" на счет "Кредитная карта".
 
Никаких ограничений, только дата у них будет одна, общая. И все.
 
Будет ли это сложной доработкой представления или простой, вопрос был не в этом, вопрос был: не слишком ли сильные ограничения изложены в пунктах 1, 2 и 3. И если ограничения слишком сильные, то просьба была привести пример, когда указанные ограничения будут мешать.
свернуть/развернуть ветвь робкая попытка возразить [куверти3 07/06/2014 13:32] # написать ответ
 
даже скорее добавить.
Вот есть такая операция - начисление кэшбэка по кредитке.
У банков обычно она проходит после окончания льготного периода, т.к. условие - оплатить минимальный платеж по карте без задержек.
Оно, конечно, можно и отдельной операцией провести, но ведь народ логично захочет этот кэшбэк завести в сплит. Тогда пусть исполнение будет по одной дате, но оставить возможность бюджетной даты.
 
Для себя я не вижу ограничений в объединении по дате и возможности задать повтор на сплит целиком.
Скажу больше, при снятии этих ограничений вообще развалиться любой смысл сплита в описанной реализации.
Но не сочтите за труд, объясните пожалуйста еще раз какие преимущества даст мне такой сплит? Я нашел только одно - визуальная группировка идентичных по дате операций. И то, мы говорим сейчас не о интерфейсе!
Я правильно понял, что сейчас не идет речь о реализации "главной" операции сплита, в которой будет указана общая сумма сплита, автоматическое выделение процентов, автоматическое уменьшение остатка "главной" операции при добавлении подопераций и пр.?
 
Потому что традиционный "сплит", это просто чеки разбить. Составная операция, это немного большее.
 
Насчет преимуществ:
 
1. Да, Вы правы, самое первое преимущество, это визуальная группировка операций. В принципе, без этого можно было бы и обойтись.
 
2. На базе составных операций я планировал в будущем сделать шаблоны. Вот в шаблонах будет возможность вычислять суммы, брать проценты от введенной суммы, сохранять формулы и все такое.
 
Есть еще задумки насчет доработки импорта операций в связи с введением составных операций, но это уже совсем другая история.
 
...устанавливать индивидуально для каждой из операций, входящих в составную. Общая будет только дата выполнения, но не бюджетная.
 
простите что пытаюсь свалить все в кучу, но если не ошибаюсь, одним моментов невозможности введения операции с "-" была как раз структура БД. Может еще раз вернуться к обсуждению?
 
Даже несмотря на то, что сам несколько раз сталкивался с описанными ситуациями. И уж точно не хотелось бы возвращаться к этой теме в этой ветке форума, мне хотелось бы оставить ее для составных операций. Well