Форум Не помещается описание

Вместо предисловия:
 
>> Должна ли корневая операция иметь собственную сумму или сумма корневой операции автоматически равна сумме вложенных операций?
 
А должен счет иметь баланс на основе его операций, или у него он от операций не зависит?
 
На данном этапе, этапе проектировки, самое главное -- не ошибиться с дизайном, архитектурой этих операций. Такие ошибки дорого стоят. Стоит допустить оплошность, возможность использовать операции неэффективно, как тут же ее как раз и начнут так использовать. Потом начинается "месиво" из информации, которую трудно контролировать. Потом начинаются предложения ввести новую ф-ию в программу, чтобы помочь контрлировать "месиво". И программа превращается из инструмента в набор функций. Все прелесть Cash в том, что в ней сейчас сочетается как отличный дизайн архитектуры программы, так и дизайн интерфейса (который не может быть хорошим, если архитектура приложения имеет ошибки). Повоторюсь -- на данном этапе важно выбрать хороший дизайн (не интерфейс! дизайн архитектуры программы!), чтобы в будущем не расплачиваться за ошибки. Продолжение следует...
 
Dervish: Однажды я наступил на грабли дизайна внутренностей программы, не совсем удачно реализовав работу с файлом базы данных. Может быть потому и пропадает желание снова садиться в ту же самую лужу. Поэтому, собственно, никаких возражений, будем считать ваше сообщение, Артём, аксиомой.

Исходя из вышенаписанного, объясню, почему я дал такой ответ на первый вопрос авторского поста. Детализация операций -- возможность объеденить несколько операций в одну, чтобы много места не занимали, когда эта группа логически едина!!! Это важный момент. Детализировать одну операцию, в которой каждый член не связан с главным -- большая ошибка (например операция "Расходы за день", куда входят продукты, батарейки, попеременно оплата интернета и коммунальных услуг). Зато есть смысл детализировать логически связанные операции, такие как "Покупка еды", куда входят "Черный хлеб", "Огурцы", "Водка". Заметьте, сама главная, "родительская" операция не несет никакой нагрузки. Она служит обобщением всех покупок, логическим единением. Без нее операции покупок хлеба, водки, огурцов не имели бы такого значения, какое они получают, будучи вместе. Порзнь, можно было бы сказать, что хлеб -- на обед, водка -- в подарок, огурцы -- жене. А вместе, они дают точную характеристику главной операции -- "ужин алкоголика". Здесь родительская и дочерние операции тесно взаимосвязаны, и каждая привносит новый смысл. Я говорю о смысле потому, что он -- основа дизайна. Если нет четкого понимания, кому, зачем и как нужна какая-либо ф-ия, то дизайн будет слабым и следующий щаг -- "месиво". А если есть самое главное -- понимание этих вещей, то и дизайн можно развивать в нужном ключе.
Продолжение следует....
 
Dervish: читаю дальше...

Покурили, теперь можно продолжать...
Вы знаете, что в Cash уже есть логическая "объединялка" операций -- Статьи? И агенты. И проекты. Благо, все они иерархические. Они уже говорят, что операция не "сама по себе", а уже входит в какую-то подгруппу, имеет родственные связи с другими операциями из другой подгруппы. Но эти категории слишком общие -- именно поэтому поступают предложения сделать разбиение более конкретным, на уровне самих операций, а не всего денежного потока. Итак, необходимо разбить и операции. Почему нужно, чтобы операции были родственными также и по статьям (агентам, проектам)? Для обеспечения единения со всем потоком. Представьте поток, реку. Это весь денежный поток. Но она образуется из притоков, ручейков. Какой-то ручеек узкий, какой-то широкий. В свою очередь каждый ручеек образуется из более мелких и т.д. Иногда приходит "тетка" и выливает ведро помоев в реку. Это тоже приток, только единоразовый (или нечастый, если "тетка" решила время от времени выливать ведро в реку). Это и есть стройное дерево статей, например расходов (постоянные ручейки -- наши регулярный выплаты, "тетка" с ведром -- нерегулярные, например штрафы ГИБДД).
 
Dervish: Тоже покурю и продолжу чтение...

При необходимости анализировать, мы подходим к каждому ручейку и меряем его вклад в общее дело (в реку). Со статьями (агентами, проектами) так же. А теперь представьте, что вложенные операции имеют разные статьи с родительской. Это не только нарушает принцип логического единства, описанного в первом разделе, такие операции не входят органично в денежный поток. Хотя поток и может быть проанализирован старым способом, эти операции не несут нагрузки информационной нагрузки, позволяющей уточнить свойства основного потока. А теперь, если операции имеют дочерние статьи (агенты, проекты). Например, операция -- "тетка" вылила ведро. Статья "Ведро "тетки"". А дети статьи -- "зловония", "вонючести", "цветастости". А дети операции -- сколько всего этого было в данном ведре, и чего не было в нем вообще. Причем не теряется связь с основным потоком -- все эти дети вписываются в дерево статей и составляют единое целое.
Продолжение следует...
 
Dervish: Любопытная аллегория. Но сомнения пока остаются.

А что если в одной родительской операции НУ ДОЛЖНЫ БЫТЬ дети разных статей?
Скорее всего, проблема -- в грамотной проектировке дерева статей. Это не так просто как кажется. Хорошо то, что такой дизайн поможет больше уделять времени составлению дерева статей, если человек хочет удобнопользоваться вложенными операциями. Иначе, люди имеют тенденцию к разгильдяйскому отношению по поводу дерева статей, превращая его в чуть более упорядоченный плоский список. Встретившись с проблемой, человек сразу интуитивно (!) начнет перерабатывать дерево. В результате у него будет не только удобная возможность детализировать операции, но лучшая аналитика и отчетность. Но будут и те, кто напишет в форум "А почему так?" и их будет много. Но тут будет выбор -- сделать правильно, или сделать "для всех", что приведет к "месиву" не только у тех, кто не хочет перерабатывать статьи, но и у тех, кто переработал бы, но у него нету стимула. Остается выбрать наименьшее зло.
 
Dervish: Почему-то вспомнился пост уважаемого Эксплорера, что "Не надо меня учить и заставлять". В общем, лично я его понимаю и не являюсь сторонником надуманных ограничений. По мне, чем меньше ограничений, тем лучше.
 
А я хочу детализировать только некоторые части, поэтому надо, чтобы сумма "родительской" была больше сумм "дочерних"
Пожалуйста -- создайте вложенную операцию со статьей родительской и впишите разницу. Пример из первого раздела, только в операции "Покупка еды", дочерняя запись только "Водка", а вторя дочерняя -- сумма огурцов и хлеба. Причем всегда видно, сколько потратили на "водку", а сколько на остальное.
 
Dervish: Ну вот, значит, я буду обязан всегда вводить лишнюю операцию? Тратить своё время, придумывать название статей (для излишка)... И, кроме того, выслушивать сообщения программы, если суммы вдруг не совпадут?
 
А почему именно группировка по статьям? А не по агентам, проектам?
Самый сложный вопрос. Статьи, конечно, лучше. Но! Если мыслить ширше, то возможность детализировать по агентам и/или проектам тоже важна. Оставляю вопрос открытым.
 
Dervish: А этот вопрос совсем прост, ведь группировка по статье совсем не исключает группировку по агенту. Даже, я бы сказал, наоборот.
 
Продолжение следует...

А теперь, пара слов в конце. Я не графоман.
Просто вопрос давно "зрел", и скоро потребует конкретного ответа. И очень не хочется, чтобы ответ был неправильным. Я не отрицаю других мнений, просто этот опус -- мое общее мнение по данному вопросу, куда вошли теоретические и практические размышления. Введение предназначено для очерчивания рамок -- что можно, а что нельзя. Это самый верхний слой и позволяет широкую трактовку. Если вы не согласны в корне с этим, отвечайте руганью на этот пост. Слоем ниже, одна из возможных трактовок -- "логическое единство", или первый раздел. Это всего лишь трактовка, одна из возможных, еще более сужающая рамки. Если вы думаете, что сама идея логического единства -- дурь, то отвечайте на него. Это говорит о том, что с предыдущим постом (введением) вы согласны. Раздел второй -- лично мой вывод, следующий из логического единства. Если вывод вам кажется неверным, или финал пути, по которому я вывел идею таких операций к финишной прямой вам кажется неправильным, предложите вашу трактовку в рамках "логического единства". (пост разбит на две части не из идейных соображений, а токмо волею сервера, не пускающего большие посты). Последний раздел -- это продолжение третьего, практически объясняющие мои размышления.
 
Если вам понравилась идея, мне будет приятно получить "Правильно говорит товарищ".
 
Прошу у всех прощения за больше посты. Как написать обо всем об этом в двух словах -- я не знаю. Если вы считаете, что я дурной графоман -- отвечайте матом на этот пост. (упс! матом не надо, Dervish символами забъет ругательства).
 
Dervish: Лично я не стал бы говорить, что идея логического единства - дурь. В общем, это достаточно привлекательная идея, но лично меня смущает только одно: поскольку я сам не люблю, когда на меня накладывают какие-то ограничения, то мне и не хотелось бы выступать в роли лица, которое накладывает ограничения на других. А "твёрдое претворение в жизнь" идеи логического единства есть ни что иное, как накладывание ограничений на пользователей программы.
 
С другой стороны, если предоставить полную свободу действий, то не совсем понятно, что же делать с анализом данных, как его потом выполнять. Куда ни кинь - всюду клин.
 
А, может быть, правильно сказал уважаемый де Багер, что лучше эту задачку пока отложить?

Моё мнение:
1. Должна иметь собственную сумму.
2. Нет.
3. Нет. (неуверенно
4. Нет (уверенно)
5. Учитывая ответы на 1-й и 2-й вопросы, мне кажется пользы от простой группировки не будет и непонятно зачем тогда вообще что-то менять…
 
Теперь поясню. Как я уже писал выше, я рассматриваю детализацию операций со следующей позиции: Я пришёл в магазин и сделал много разнообразных покупок. Пришёл домой, достал кассовый чек, длинною 50 см. и начал вводить операции.
Сейчас, либо вводишь одну операцию на всю сумму, либо вводишь все 50 см. В первом случае нет точности анализа, во втором — долго и все операции занимают много места на экране. Второй случай не смертелен, но не очень удобен. Может я не хочу заводить отдельные статьи на редкие покупки или не хочу детализировать покупки стомостью менее 10 руб., но в то же время хочу знать сколько у меня уходит на пиво, водку, сигареты и таблетки для печени… Вот тут-то, детализация и нужна: кассовый чек (вся покупка в одном магазине) на 500 руб. — это корневая операция, а вложенные в неё только то что я хочу выделить — а) пиво 100 руб., статья — снятие деперессии; б) водка — 100 руб., поднятие настроения; в) таблетки — 50 руб., лечение после поднятия настроения; г) хлеб — 5 руб., питание. Итоговая сумма вложенных операций корневой не равна, статьи разные, а анализирую я только указанные статьи и ничего другого.
Вот для этого и нужна детализация покупок. Тогда можно и смотреть на какого агента сколько тратится, так как в корневую операцию введена вся сумма покупки, и статьи которые необходимо держать под контролем тоже содержат достоверную информацию. Тогда и в окне операций хочешь посмотреть детально где, когда и что покупал раскрыл корневую операцию, не хочешь не смотришь, но примерно можно оценить сколько и где потратил в день или неделю, не пролистывая по несколько экранов.
 
Dervish: Вначале пояснение к сообщению Артёма.
 
Допустим вы вводите общий чек для всех покупок, которые вы сделали в супермаркете. Тогда, действительно, корневая операции будет иметь сумму всего чека и относиться к статье "Продукты питания", а дальше, когда вы будете детализировать покупки, вы, например, потраченную на водку сумму отнесёте к статье "Спиртные напитки", которая является подстатьёй упомянутых уже "Продуктов питания". Тогда в последующем, в графиках, это будет очень наглядно отображено.
 
Совсем другой вопрос, что делать, если в общую сумму чека входит, например, туалетная бумага, которая так же куплена в супермаркете. К продуктам питания её, увы, отнести не получится, значит, что с ней делать? Если настаивать на идее логической целостности, то что? Артём, как переработать дерево статей, чтобы туалетная бумага всё-таки вошла в продукты питания?
 
В общем, имхо, идея детализации полезна в двух случаях: для более наглядного представления данных в таблице операций и для более полного и точного анализа введённых данных. Не клеится как-то...

На самом деле предложенный вариант почти в точности мой
Ключевая фраза: "... среди них ищет операции с общим "родителем" в статьях прихода/расхода..."
Насколько я понимаю, это та же группировка по статьям, но в моем случае (подрузамевалось, я не указывал прямо) что пользователь сам укажет, какие операции добавлять как дочки; в данном случае программа сама решает какие операции сгруппировать вместе, но основная особенность -- родитель будет та операция, у которой статья находится выше всех по дереву статей. Т.е. та же группировка по статьям, только в групиировку включаются не те операции, которые мы укажем, а те, у которых одинаковая дата.
 
Я правильно понял?
 
Dervish: Когда "программа сама решает", это самодеятельность. Причём, в худшем смысле этого слова. Imho, конечно же.