Уважаемые разработчики,
(долго думал, как бы покорректнее написать...)
Надеялся использовать вашу программу, как наиболее разумно спроектированную. Оказалось, что показалось ... В данный момент я сижу и медитирую уже десять минут над простой задачей - как мне обозвать расход "творог", если у меня уже есть такой расход в другой ветки (и да, мне нужно две ветки, -- я покупаю творог себе и животным). И, знаете, категории и расходы "Животные / Собаки / питание собакам / творог для собак", "Питание людям / молочные / творог для людей" (мля, люди как собаки) смотрятся слегка глупо ... Я хочу писать просто Творог, вне зависимости от того, для кого он предназначен. А еще веселее запись типа "бабушка Вера / питание бабушки Веры (бо как просто Питание уже занято #$%#$%) / Молочные бабушки Веры (молочные тоже уже забиты / Творог бабушки Веры (просто творог уже собакам отдан" выглядит как записи мальчика из анекдота про море.
Так вот ... жалко мне потраченных 10 дней, однако же придется наверное искать более другую программу.
Уникальные имена статей доходов/расходов
Модератор: Анастасия
-
Анастасия
- Разработчик
- Сообщения: 692
- Зарегистрирован: Ср ноя 21, 2007 6:56 am
- Контактная информация:
В программе возможны только уникальные наименования статей доходов/расходов, это принципиальная позиция.
Вы просто сравните, что быстрее набрать при внесении расхода:
1. "Животные/Собаки/Питание собакам/Творог" и "Питание людям/Молочные/Творог"
или
2. "Творог" и "Творог для собаки"
На наш взгляд, второе гораздо быстрее, плюс не надо помнить всю последовательность папок, где находится статья. Именно поэтому статья должна иметь уникальное название, чтобы программа поняла, о чем речь.
Скажу больше, я пыталась вести учет в программе, где нужно как раз помнить всю эту цепочку вида "Животные/Собаки/Питание собакам/Творог", так в процессе работы там столько ненужных статей посоздавалось автоматически, так как сегодня, к примеру, я вношу по памяти "Животные/Собаки/Питание собакам/Творог", а завтра "Животным/Собака/Питание собакам/Творог", а послезавтра "Животные/Собаки/Питание собаке/Творог" и т.п., в итоге потом приходится лезть в справочник статей и там все это объединять. И так с кучей других статей, чем больше вложенность, тем больше или вероятность забыть, как что называлось, или просто тратить кучу времени на выбирание мышкой из справочника. Брр..
И что плохого, в конце концов, назвать творог для собаки именно так, раз уж Вы хотите учитывать его отдельно? Если не хотите учитывать отдельно, то не делайте специальные группы питания для собак, кошек, хомячков и бабушки Веры, и будет у Вас один творог на все случаи жизни:).
Вы просто сравните, что быстрее набрать при внесении расхода:
1. "Животные/Собаки/Питание собакам/Творог" и "Питание людям/Молочные/Творог"
или
2. "Творог" и "Творог для собаки"
На наш взгляд, второе гораздо быстрее, плюс не надо помнить всю последовательность папок, где находится статья. Именно поэтому статья должна иметь уникальное название, чтобы программа поняла, о чем речь.
Скажу больше, я пыталась вести учет в программе, где нужно как раз помнить всю эту цепочку вида "Животные/Собаки/Питание собакам/Творог", так в процессе работы там столько ненужных статей посоздавалось автоматически, так как сегодня, к примеру, я вношу по памяти "Животные/Собаки/Питание собакам/Творог", а завтра "Животным/Собака/Питание собакам/Творог", а послезавтра "Животные/Собаки/Питание собаке/Творог" и т.п., в итоге потом приходится лезть в справочник статей и там все это объединять. И так с кучей других статей, чем больше вложенность, тем больше или вероятность забыть, как что называлось, или просто тратить кучу времени на выбирание мышкой из справочника. Брр..
И что плохого, в конце концов, назвать творог для собаки именно так, раз уж Вы хотите учитывать его отдельно? Если не хотите учитывать отдельно, то не делайте специальные группы питания для собак, кошек, хомячков и бабушки Веры, и будет у Вас один творог на все случаи жизни:).
-
Анастасия
- Разработчик
- Сообщения: 692
- Зарегистрирован: Ср ноя 21, 2007 6:56 am
- Контактная информация:
Кстати, позднее эту задачу можно будет решить проектами (как вариант), то есть будет одна статья "Творог", но если творог купили для собаки, проставляется проект "Собака", а если для бабушки "Бабушка", и в отчетах можно будет отделять расходы по проектам.
В текущей функциональности надо или удобно настроить справочник статей расходов, или вносить расходы под разными пользователями (например, под бабушкой:)), дабы проверить потом в отчетах, сколько она съела (если такая цель стоит)...
В текущей функциональности надо или удобно настроить справочник статей расходов, или вносить расходы под разными пользователями (например, под бабушкой:)), дабы проверить потом в отчетах, сколько она съела (если такая цель стоит)...
Принципиальность хороша в моральных вопросах, а в бизнесе лучше иметь гибкость неописуемую, особенно в части удовлетворения потребностей пользователей. Видите ли, большинство людей - не программисты и у них мышление не такое, как нам бы хотелось 
Позволю себе небольшое лирическое отступление. Десять лет назад я написал (и много лет с него жил) компонент для дельфи, под названием ElTree (найдете поиском, если интересно). И с тех пор (положение обзывает) был сторонником строгих иерархий и группировок (ну совсем как Вы
. И только недавно наш коммерческий директор объяснил и показал мне идею разрезов в анализе (он показывал на OLAP) и тегов как метода формирования разрезов. Разработчики некоторых компонентов-"деревьев" лет пять назад представили такую вещь как группировка, т.е. формирование иерархий самим пользователем исходя из данных, находящихся в ячейках записей. Т.е. берется плоская таблица, а потом данные группируются по каким-то столбцам. И так оно красиво у них вышло, что я даже было подумывал в своем компоненте это сделать (собственно новые хозяева так сделали).
Так вот к чему это я ... Не нужны иерархические списки вообще. У каждого расхода должен быть набор тегов, по которым пользователь сможет проводить группировку этих расходов и строить отчеты. Т.е. хочу я проанализировать затраты на бабушку, - сгрупировал по тегу "бабушка" и анализирую. Хочу проанализировать затраты на питание, - анализирую по тегу "питание". При этом выборка тегов может реализовываться поисковыми выражениями типа "+питание -собаки", что сделает реализацию многих механизмов намного проще, чем при фиксированных привязках к справочникам. Я больше скажу. Возьмите ElXTree или ExpressQuantumGrid, привяжите его к вашим данным и получите эту группировку с фильтрацией практически без кодирования.
Позволю себе небольшое лирическое отступление. Десять лет назад я написал (и много лет с него жил) компонент для дельфи, под названием ElTree (найдете поиском, если интересно). И с тех пор (положение обзывает) был сторонником строгих иерархий и группировок (ну совсем как Вы
. И только недавно наш коммерческий директор объяснил и показал мне идею разрезов в анализе (он показывал на OLAP) и тегов как метода формирования разрезов. Разработчики некоторых компонентов-"деревьев" лет пять назад представили такую вещь как группировка, т.е. формирование иерархий самим пользователем исходя из данных, находящихся в ячейках записей. Т.е. берется плоская таблица, а потом данные группируются по каким-то столбцам. И так оно красиво у них вышло, что я даже было подумывал в своем компоненте это сделать (собственно новые хозяева так сделали). Так вот к чему это я ... Не нужны иерархические списки вообще. У каждого расхода должен быть набор тегов, по которым пользователь сможет проводить группировку этих расходов и строить отчеты. Т.е. хочу я проанализировать затраты на бабушку, - сгрупировал по тегу "бабушка" и анализирую. Хочу проанализировать затраты на питание, - анализирую по тегу "питание". При этом выборка тегов может реализовываться поисковыми выражениями типа "+питание -собаки", что сделает реализацию многих механизмов намного проще, чем при фиксированных привязках к справочникам. Я больше скажу. Возьмите ElXTree или ExpressQuantumGrid, привяжите его к вашим данным и получите эту группировку с фильтрацией практически без кодирования.