Некоторые соображение по поводу работы с программой

В этом форуме Вы можете высказать пожелания к новым версиям программы: какая функциональность должна появиться, что в программе лишнее, чего не хватает, что хочется видеть в другом ракурсе и т.д. Мы обязательно рассмотрим все Ваши предложения и советы по улучшению программы.

Модератор: Анастасия

Дмитрий
Разработчик
Разработчик
Сообщения: 1698
Зарегистрирован: Ср ноя 21, 2007 6:18 am
Контактная информация:

Сообщение Дмитрий »

Так я-то говорю не про все контролы, а только про табличную часть - для всех остальных контролов Таб самое то, а Ентер действительно вне табличной должен действовать как "Добавить"/"Сохранить"/"ОК" . Но в табличной части сейчас Ентер действует совсем не так:
- если поле не в режиме редактирования, Ентер переводит его в режим редактирования
- если поле в режиме редактирования, Ентер подтверждает ввод и остается в этом же поле. И если его сдвинуть в правую ячейку, то как раз таки будет то, что нужно - ввел значание, ентер, ввел значение ентер - рука никуда не скачет. Закончил ввод данных в таблице - Таб (выйти за пределы таблицы), Ентер - "Сохранить".
Т.е., подчеркну, очень желательно чтобы в табличной части карточки Ентер, подтверждая ввод, переходил на следующее в строке поле (как в Экселе) (либо на новую, строку, если поля в строке кончились).
Наверное, вы правы, переход по Enter в составе расхода/дохода будет довольно полезной функцией. Постараемся это реализовать.

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

О!
Отлично!
Огромное спасибо :)
Кстати, прочитал статью по поводу кредитных карт - пролучается достаточно просто и наглядно. Спасибо

Дмитрий
Разработчик
Разработчик
Сообщения: 1698
Зарегистрирован: Ср ноя 21, 2007 6:18 am
Контактная информация:

Сообщение Дмитрий »

О!
Отлично!
Огромное спасибо
Кстати, прочитал статью по поводу кредитных карт - пролучается достаточно просто и наглядно. Спасибо
В первую очередь спасибо вам за участие :) Ждите новых релизов :)

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Дмитрий, поздравляю вас с праздником!

Релизов жду с нетерпением!
Надеюсь, что они позволят облегчить мне ввод данных, потому как на данном этапе это мне дается не просто :)

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

...WL0007
Сохранение истории примечаний, ввод с автопоиском по истории по первым введенным буквам.
Я примечания заполняю довольно часто, и часто они повторяются, поэтому такая история была бы полезной


WL0008
Возможность создавать счета и наименования товаров и услуг не только в самых последних подгруппах, но и более высокого уровня.
Сейчас получается так, что я не могу в группе создать подгруппу (ветку) и счет (лист) одновременно. "Листья" можно создавать только на "ветке", которая не имеет других "ветевей".

Примеры (это то, как я хотел организовать данные, но не вышло):
ЗАГЛАВНЫЕ БУКВЫ - Это группы
Смешанный регистр - это непосредственно счета либо наименования товаров и услуг.

Код: Выделить всё

Счета:
+ПЛАСТИКОВЫЕ КАРТЫ
|+КАРТА #1 (КРЕДИТНАЯ)
||-Лимит по карте #1
||-Собственные средства на карте #1
|-Карта #2 (дебетная)

Статьи:
+ПИТАНИЕ
|+МОЛОЧНОЕ
||+СЫР
|||-Гауда
|||-Российский
||-Молоко
||-Кефир
||-Творог
||-Сметана
Что касается статей, немного смущает терминология.
На мой взгляд, слово "Статья" соответствует группе определенных товаров и услуг, в то время как у вас "статья" означает уже конкретное наименование товара или услуги.
Но ведь когда говорят "Статья буджета", имею ввиду ведь "Питание" или "Питание\Молочное", например, а не "Йогурт Данон 500мл".

Есть предложение по поводу вида отчета "Доходы и расходы по статьям"
Когда выбирается группировка по "Группам статей" (в моей терминалогии по "статьям", "категориям"), то в отчете фигурируют только категории соответствующие уровню вложенности. Получается все в кучу и не очень внятный отчет.
Если бы в отчете присутствовали и родительские категории, то было бы более удобно и наглядно (особенно, если разные уровни выделять отступами или другим оформлением (размер шрифта, начертание, ...), что-то типа этого:

Код: Выделить всё

Коммунальные услуги	3000 руб
-Квартира		2000 руб
-Телефон		500 руб
-Электричество		500 руб	
Питание 		2000 руб
-Овощи			300 руб
-Фрукты		500 руб
-Молочное		300 руб
--Сыр			100 руб
--Молочное(без подкатегории) 200 руб
-Крупы			200 руб
-Сладости		200 руб
-Мясо			500 руб
И, если бы отчет был интерактивным, можно было бы тут же выбирать уровень детализации, и тут же можно строить график либо всех, либо выбранной подкатегории, чтобы визуально оценить расходы/доходы

И, кстати, вы же каким-то образом определяете транзация доходная или расходная? Думаю, имеет смысл в конфигураторе отчета поставить поле, позволяющее выбрать что отражать в отчете - доходы, расходы, или все вместе. Я в КэшОрге регулярно строил графики только по дохдодам, либо только по расходам, чтобы видеть, то что нужно, и не видеть лишнюю информацию

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

...WL0007
Сохранение истории примечаний, ввод с автопоиском по истории по первым введенным буквам.
Я примечания заполняю довольно часто, и часто они повторяются, поэтому такая история была бы полезной
Мы подумаем над этим. Если другие пользователи также выскажут необходимость в такой функции, реализуем.
WL0008
Возможность создавать счета и наименования товаров и услуг не только в самых последних подгруппах, но и более высокого уровня
Такая возможность не планируется. Мы решили остановиться именно на такой структуре.


Есть предложение по поводу вида отчета "Доходы и расходы по статьям"
Когда выбирается группировка по "Группам статей" (в моей терминалогии по "статьям", "категориям"), то в отчете фигурируют только категории соответствующие уровню вложенности. Получается все в кучу и не очень внятный отчет.
Если бы в отчете присутствовали и родительские категории, то было бы более удобно и наглядно (особенно, если разные уровни выделять отступами или другим оформлением (размер шрифта, начертание, ...), что-то типа этого:
Такая детализация (группа, расходы по статьям, итого по группе и т.д.) есть в отчете, когда выбрана опция "по статьям", а не по "группам статей". Что касается отчета по группам статей он обычно не такой большой, и что там "в кучу", не ясно. Приведите пример. Ваш больше походит на отчет с опцией "по статьям". Попробуйте также просто сделать несколько сохраненных отчетов с настроенным фильтром по группам, чтобы не мешать "телевизор с фруктами".



И, кстати, вы же каким-то образом определяете транзация доходная или расходная? Думаю, имеет смысл в конфигураторе отчета поставить поле, позволяющее выбрать что отражать в отчете - доходы, расходы, или все вместе. Я в КэшОрге регулярно строил графики только по дохдодам, либо только по расходам, чтобы видеть, то что нужно, и не видеть лишнюю информацию
В печатной форме отчета доходы и расходы разнесены по разным страницам, можно смотреть ту, которая Вам нужна. При графическом отображении отчетов Вы также можете выбрать, что отображать: доходы, расходы, баланс, то и другое и т.д. Все эти настройки в отчетах сохраняются.

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Цитата:
WL0008
Возможность создавать счета и наименования товаров и услуг не только в самых последних подгруппах, но и более высокого уровня
Такая возможность не планируется. Мы решили остановиться именно на такой структуре.
Если не сложно, могли бы вы в вкраце пояснить почему?
Я непросто так придумываю что-бы такое поменять в программе, все то, о чем я пишу, это то, на чем я реально спотыкаюсь, при использовании вашей программы. Конечно сказывается привычка работы с другой системой.
Цитата:
Есть предложение по поводу вида отчета "Доходы и расходы по статьям"
Когда выбирается группировка по "Группам статей" (в моей терминалогии по "статьям", "категориям"), то в отчете фигурируют только категории соответствующие уровню вложенности. Получается все в кучу и не очень внятный отчет.
Если бы в отчете присутствовали и родительские категории, то было бы более удобно и наглядно (особенно, если разные уровни выделять отступами или другим оформлением (размер шрифта, начертание, ...), что-то типа этого:
Такая детализация (группа, расходы по статьям, итого по группе и т.д.) есть в отчете, когда выбрана опция "по статьям", а не по "группам статей". Что касается отчета по группам статей он обычно не такой большой, и что там "в кучу", не ясно. Приведите пример. Ваш больше походит на отчет с опцией "по статьям". Попробуйте также просто сделать несколько сохраненных отчетов с настроенным фильтром по группам, чтобы не мешать "телевизор с фруктами".
Не соглашусь, т.к. в моем примере конкретных наименований (позиций) нет. А есть только иерархия категорий ("Групп статей" в вашей номенклатуре), соответственно и опцию группировки я выбираю "Группы статей". Пример привожу. Вот что у меня получилось при следующих опциях:
Группировка: Группы статей
Вложенность: 2
Изображение

Возможно вы ведете речь о случае, когда вложенность 1. Тогда все ясно, но при больших значениях получается каша - категории отсортированы по алфавиту и, поскольку родительские категории не присутствуют, то все вперемешку.
Мой же пример (повторюсь, содержит только категории, без конкретных наименований), ИМХО, позволяет лучше увидеть картину :)

Код: Выделить всё

Коммунальные услуги   3000 руб 
-Квартира      2000 руб 
-Телефон      500 руб 
-Электричество      500 руб    
Питание       2000 руб 
-Овощи         300 руб 
-Фрукты      500 руб 
-Молочное      300 руб 
--Сыр         100 руб 
--Молочное(без подкатегории) 200 руб 
-Крупы         200 руб 
-Сладости      200 руб 
-Мясо         500 руб
ну и предложу свое видение отчета с группировкой по статьям (просто немного другое представление, из существенного - указание всех уровней до нужной вложенности типа "Питание\Молочное", а не просто "Молочное" при вложенности 2). Это, пожалуй, это дело вкуса, но может быть окажется полезным.
Изображение
В случае вашего варианта, у меня несколько рябит в галазах, поскольку много разделителей пустых строк (особенно, если элементов для одной группы в таблице мало, как в этом случае).
Изображение
В печатной форме отчета доходы и расходы разнесены по разным страницам, можно смотреть ту, которая Вам нужна. При графическом отображении отчетов Вы также можете выбрать, что отображать: доходы, расходы, баланс, то и другое и т.д. Все эти настройки в отчетах сохраняются.
Да, вы правы. Здесь действительно я не заметил в форме с графическим отчетом возможности убирать лишнее.

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

Если не сложно, могли бы вы в вкраце пояснить почему?
Я непросто так придумываю что-бы такое поменять в программе, все то, о чем я пишу, это то, на чем я реально спотыкаюсь, при использовании вашей программы. Конечно сказывается привычка работы с другой системой.
Есть два основных недостатка, касающихся ввода данных и построения отчетов.

1. При такой организации дерева, Вам нельзя будет (впрочем, как и у нас), называть одинаково группы или статьи. Почему? Если у Вас будет структура вида:

Молочные
- сыр
-- российский
-- гауда
- сырок плавленый
-- российский
-- карат

То когда Вы начнете вводить расход "Российский", что нужно будет выбрать программе, сыр или сырок (или может что еще?)? А вся Ваша структура направлена именно на то, что название конечной статьи будет односложным, потому что все про нее (продукты, молочное, сыр) сказано "структурой папок". При односложном названии сложно придумать неповторяющиеся и "говорящие" названия. В таком случае, чтобы понять о чем речь нужно сделать, как в некоторых программах при вводе расхода несколько полей, где Вы сначала вводите "Продукты", потом в следующем поле "Молочные", потом "Сыр", а потом "Российский"... Это на наш взгляд ооочень медленно и неудобно, нужно помнить где находится нужная статья (полный путь!!!) и тратить больше времени на ввод. Когда я ввожу в МТ, например, "Зарядка для сотового телефона", я не задумываюсь, в какой группе эта статья, это дело программы, просто набираю несколько первых букв, а так придется помнить ВСЕ :( .
Может, стоит создать в группе молочные кроме "Сыра Российского", "Сыра Гауды" и пр. статью "Сыр", если иногда хочется обойтись без детализации по сорту.... Надо думать. Наверняка можно составить дерево статей так, чтобы получать результаты близкие к тем, которые Вы привыкли получать.


Второй недостаток, более важный чем первый. Предположим, что можно создавать расходы не только на статьи, но и на группы (в нашей терминологии).

Я хочу построить отчет по группе продукты по статьям. Сейчас все просто и логично
Группа продукты:
- молоко - 500 рублей
- мясо - 1500 рублей
- фрукты - 150 рублей
Итого по группе 2150 рублей.

У Вас это будет выглядеть так:

Группа продукты - 2300 рублей
- молоко - 500 рублей
- мясо - 1500 рублей
- фрукты - 150 рублей
Итого ????
Что такое "итого" в данном случае вообще не ясно (суммировать только внутри группы, или и статьи и саму группу).

Дальше. А если мы строим отчет по группам статей, получается (сразу пишу в Вашем понимании):
Расходы - ??? рублей
- связь - 1500 рублей
- дом - 4500 рублей
- питание - 7540 рублей

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

И этот же недостаток помешает потом созданию бюджета в том виде, в каком мы его видим. Например, мы полагаем, что можно будет задать ограничение полностью на группу Продукты (10000 рублей), и внутри на группу Мясные (2500 рублей), и на группу Фрукты (2500 рублей). Тогда программа будет контролировать как расходы по мясным и фруктовым статьям отдельно, так и будет контролировать что ВСЕ расходы на питание не превзойдут заданной суммы 10000 рублей. Если эта группа приравнивается по свойствам к статье, эта функция уже не реализуема, так как это будет просто ограничение по статье, а не как задумано, по всем вложенным в группу статьям...

Если говорить совсем коротко, в программе объекты "Группа статей" и "Статья" имеют разные функции, за счет чего можно создавать удобные отчеты и просмотр данных, можно будет сделать гибкий бюджет. Вы предлагаете объект "Группа статей" наделить свойствами объекта "Статья", что сделать непросто, и на наш взгляд, даже нельзя ;).

Я понимаю, что это все связано с тем, что Вы использовали другую программу и привыкли к ее логике работы, но помочь в этом вопросе ничем большим не можем. Возможно, Вам стоит посмотреть еще другие программы, может в какой-то реализован более удобный подход, если это самая важная вещь для Вас.

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

По второму вопросу.

Что касается отчета по группам статей, пока выделять родительские группы не будем. Как вариант решения, который я уже предлагала, сделать несколько сохраненных отчетов вида:
- отчет по группам по питанию
- отчет по группам по связи и технике
- отчет по группам по развлечениям
и т.д.
И потом смотреть каждый отчет отдельно, чтобы не путать разнородные группы в одном отчете.

Что касается предложения по оптимизации печатной формы отчета по статьям, большое спасибо, так гораздо компактнее :D , обязательно переработаем.

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

Для poa:

Мы посовещались и решили, что Ваш вклад в развитие программы заслуживает получения лицензии :D .

Если Вас это заинтересует, свяжитесь с нами (sales@dominsoft.ru)

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Спасибо большое!
Неожиданная и поэтому еще более приятная для меня новость :)
Если говорить совсем коротко, в программе объекты "Группа статей" и "Статья" имеют разные функции, за счет чего можно создавать удобные отчеты и просмотр данных, можно будет сделать гибкий бюджет. Вы предлагаете объект "Группа статей" наделить свойствами объекта "Статья", что сделать непросто, и на наш взгляд, даже нельзя
Судя по всему, произошло недопонимание (все-таки есть определенный минус в общении через форум, все нюансы сложно сразу изложить :) ). Я ни в коей мере не хотел наделять "Группы статей" свойствами объекта "Статья" - это разные сущности. Я говорил о терминологии. На мой взгляд, не совсем корректно определены эти понятия.
У вас элемент справочника (конкретное наименование) называется "Статья". Как мне кажется, слово "Статья" (или "Категория" и, соответственно "подстатья", "подкатегория") более применимо к тому, что у вас называется "Группа статей". А элемент справочника (который у вас "Статья") можно назвать чем-нибудь типа "Наименование", "Позиция". Т.о., "Статьи" и "Подстатьи" формируют дерево (иерархию), а "Позиции", "Наименования" создают наполнение этого дерева.
На сколько я помню, когда говорят о бюджете, оперируют понятием "Статья бюджета", которое подразумевает как раз группу каких-либо товаров или услуг. Поэтому, имеющаяся в MoneyTracker терминалогимя меня несколько сбивала с толку.
И этот же недостаток помешает потом созданию бюджета в том виде, в каком мы его видим. Например, мы полагаем, что можно будет задать ограничение полностью на группу Продукты (10000 рублей), и внутри на группу Мясные (2500 рублей), и на группу Фрукты (2500 рублей). Тогда программа будет контролировать как расходы по мясным и фруктовым статьям отдельно, так и будет контролировать что ВСЕ расходы на питание не превзойдут заданной суммы 10000 рублей. Если эта группа приравнивается по свойствам к статье, эта функция уже не реализуема, так как это будет просто ограничение по статье, а не как задумано, по всем вложенным в группу статьям...
Тогда никокого противоречия с вашим видением бюджета (а я, в принципе, также его вижу) не будет :)

1. При такой организации дерева, Вам нельзя будет (впрочем, как и у нас), называть одинаково группы или статьи. Почему? Если у Вас будет структура вида:
Хорошо, что вы затронули эту тему, я как раз столкнулся с такой проблемой, что нельзя создавать в разных ветвях подкатегории с одинаковыми названиями. Вот почему:
Бывает так, что я не вижу необходимости точно идентифицировать расход (или есть чек, но в нем не пробито наименование, а я его уже забыл), и тогда я записывал в подкатегорию "Разное". И таких "Разных" у меня было не сколько (в "Питании", "Развлечениях", "Хозрасходах" и т.д.). В Money Tracker я тоже попробовал создать подобную схему, но не получилось из-за требования к уникальности. Пришлось мне изощряться. Например в ветке "Здоровье\Лекарства и ИМН" я создал позицию "З>ЛиИМН>Разное". Но это жутко выглядит и не удобно набирать.
В том же КэшОрге такого ограничения не было. И когда набираешь буквы, он подствляет список, где представлены все совпадения. Нужный можно выбрать. Вот как это выглядит:
Изображение
Т.е. можно набрать часть слова, а нужную статью выбрать из списка. Причем подстановка при наборе работает не только по первым буквам, но осуществляется поиск введенной подстроки внутри названий. Причем в нашем случае поиск в названиях категорий вести не нужно, достаточно только в названиях "Наименований" (как я понимаю, сейчас так и реализовано у вас)
После того как выбран нужный пункт там он отражался так:
"Комм.услуги:Телефон" или "Питание:Молочное:Сыр". Т.е. подкатегории разделялись знаком ":" и была видна вся ветвь.
В нашем же случае можно было бы такую запись ввести:
"Питание\Молочное:Кефир 1%" - через знак "\" записывается иерархия, а знак ":" отделяет конкретное наименование. В отдельных случаях может получиться довольно длинно, конечно. Но очень наглядно. И, причем, если не существует такого пункта, то его можно создать на основании парсинга строки (в кэшорге, и где-то еще такая реализация есть). Конечно здесь сложнее, т.к. по хорошему нужно ввести дополнительные параметры нового элемента типа "единица измерения". Но можно показывать вопрос: "Такого элемента не существует. Хотите создать новый?" В случае утвердительного ответа появляется окно ввода нового наименования и соответствующие поля заполняются автоматически (название и категория), останется только ввести единицу измерения и другие желаемые параметры.
То когда Вы начнете вводить расход "Российский", что нужно будет выбрать программе, сыр или сырок (или может что еще?)? А вся Ваша структура направлена именно на то, что название конечной статьи будет односложным, потому что все про нее (продукты, молочное, сыр) сказано "структурой папок". При односложном названии сложно придумать неповторяющиеся и "говорящие" названия. В таком случае, чтобы понять о чем речь нужно сделать, как в некоторых программах при вводе расхода несколько полей, где Вы сначала вводите "Продукты", потом в следующем поле "Молочные", потом "Сыр", а потом "Российский"... Это на наш взгляд ооочень медленно и неудобно, нужно помнить где находится нужная статья (полный путь!!!) и тратить больше времени на ввод. Когда я ввожу в МТ, например, "Зарядка для сотового телефона", я не задумываюсь, в какой группе эта статья, это дело программы, просто набираю несколько первых букв, а так придется помнить ВСЕ .
То, что я описал выше, позволяет решить эту проблему. А случай когда делают под каждный уровень свое поле ввода действительно очень ущербен и обычно его используют, если вложенность ограничена 2-3 уровнями (но даже при этом его использование не оправдано).
А если использовать односложные названия, тогда и полный "путь" не будет таким длинным и помнить его не нужно будет, т.к. нужные элементы будут отображаться в выпадающем списке по мере набора букв.
Второй недостаток, более важный чем первый. Предположим, что можно создавать расходы не только на статьи, но и на группы (в нашей терминологии).

Я хочу построить отчет по группе продукты по статьям. Сейчас все просто и логично
Группа продукты:
- молоко - 500 рублей
- мясо - 1500 рублей
- фрукты - 150 рублей
Итого по группе 2150 рублей.

У Вас это будет выглядеть так:

Группа продукты - 2300 рублей
- молоко - 500 рублей
- мясо - 1500 рублей
- фрукты - 150 рублей
Итого ????
Что такое "итого" в данном случае вообще не ясно (суммировать только внутри группы, или и статьи и саму группу).
На самом-то деле, эти два примера, которые вы привели ничем не отличаются друг от друга кроме того, что в верхнем итог указан отдельной строкой в конце, а в нижнем итоговая сумма в той же строке, что и название категории более высокого уровня. Поэтому неясности нету.
Расходы - ??? рублей
- связь - 1500 рублей
- дом - 4500 рублей
- питание - 7540 рублей

А вопрос вот какой: что за цифра должна быть в группе "Расходы". У нас там будет "итого" по всем подгруппам, входящим в нее. У Вас возможны варианты:
- только расход по этой группе
- расход по этой группе и по всем вложенным
И вся эта "непонятка" распространяется вниз на всю структуру дерева статей и накапливается (!)... Как ее разрешить?
То же самое и здесь, неясности нет: "Расходы" = "Связь" + "Дом" + "Питание" = 13540 руб.
А "Питание" = Молоко(1000) + Мясо(2540) + Фрукты(2000) + Овощи(1000) + Крупы(500) + Разное(500) = 7540
И т.д.

Т.о. можно дать такое определение:
Итог для элемента уровня (N-1) равен сумме итогов элементов уровня N, находящихся у него в подчинение.
И если суммирование проводить от наиболее низких уровней к верхним, то все хорошо и логично считается.

Вот так это может выглядеть (кстати, это же и пример интерактивного отчета - можно подуровни разворачивать для детализации, и сворачивать, если не нужны. А двойной клик на категории покажет отельное окно с транзакциями, формирующими данный итог):
Изображение
Кстати, здесь "Молочное [Незаданное]" это виртуальная категория - это все те "Наименования"(листья), которые принадлежат непосредственно ветви "Молочные", А "Сыр" - это уже существующая подкатегория. Т.е. тут не только крайние "Ветки" могут иметь "листья", но и "ветки" более высого уровня.

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

Хорошо, что вы затронули эту тему, я как раз столкнулся с такой проблемой, что нельзя создавать в разных ветвях подкатегории с одинаковыми названиями. Вот почему:
Бывает так, что я не вижу необходимости точно идентифицировать расход (или есть чек, но в нем не пробито наименование, а я его уже забыл), и тогда я записывал в подкатегорию "Разное". И таких "Разных" у меня было не сколько (в "Питании", "Развлечениях", "Хозрасходах" и т.д.). В Money Tracker я тоже попробовал создать подобную схему, но не получилось из-за требования к уникальности. Пришлось мне изощряться. Например в ветке "Здоровье\Лекарства и ИМН" я создал позицию "З>ЛиИМН>Разное". Но это жутко выглядит и не удобно набирать.

Создайте в соответствующих папках статьи "Разное лекарства", "Разное продукты", "Разное развлечения" и т.п. Будете набирать "Разное ", Вам выпадут все эти варианты, выберете нужное. Так же быстро, как и в Вашем варианте.

Т.е. можно набрать часть слова, а нужную статью выбрать из списка. Причем подстановка при наборе работает не только по первым буквам, но осуществляется поиск введенной подстроки внутри названий. Причем в нашем случае поиск в названиях категорий вести не нужно, достаточно только в названиях "Наименований" (как я понимаю, сейчас так и реализовано у вас)
После того как выбран нужный пункт там он отражался так:
"Комм.услуги:Телефон" или "Питание:Молочное:Сыр". Т.е. подкатегории разделялись знаком ":" и была видна вся ветвь.
В нашем же случае можно было бы такую запись ввести:
"Питание\Молочное:Кефир 1%" - через знак "\" записывается иерархия, а знак ":" отделяет конкретное наименование. В отдельных случаях может получиться довольно длинно, конечно. Но очень наглядно. И, причем, если не существует такого пункта, то его можно создать на основании парсинга строки (в кэшорге, и где-то еще такая реализация есть). Конечно здесь сложнее, т.к. по хорошему нужно ввести дополнительные параметры нового элемента типа "единица измерения". Но можно показывать вопрос: "Такого элемента не существует. Хотите создать новый?" В случае утвердительного ответа появляется окно ввода нового наименования и соответствующие поля заполняются автоматически (название и категория), останется только ввести единицу измерения и другие желаемые параметры.
В гриде поиск ведется по первым символам наименования, если перейти в справочник (Ctrl+Enter), там уже фокус стоит в поле поиске по любой подстроке наименоваия. Выводить полный путь к наименованию не видим смысла, может получиться очень длинно :cry: Вот Вы вводите каждый день расход "Хлеб", и все время будет выпадать жуткой ширины полоса, в которой что-то вроде "Расходы: Продукты: Хлебобулочные: Хлеб". А зачем? И так ясно, что хлеб где-то там :) . В том и цель была, чтобы нужно было только знать, как называется статья (наименование), а не нужно было помнить где она. Программа сама все найдет, где эта статья, поэтому и ограничение на уникальность наименований есть (как его избежать, см. выше на Вашем примере).

Создать новый элемент легко с помощью горячих клавиш (в справочнике Ins), в новом релизе также будет действовать клавиша Shift+F4, которая позволит прямо из карточки расхода создать новый элемент.
А если использовать односложные названия, тогда и полный "путь" не будет таким длинным и помнить его не нужно будет, т.к. нужные элементы будут отображаться в выпадающем списке по мере набора букв.
Вопрос тот же: а зачем Вам видеть полный путь?
Мы это видим там: человек приходит и просто вносит в программу, что он купил: батарейку, хлеб, молоко, заколку для волос, вот такими обычными словами. А программа сама все разносит по группам в соответствии с созданным (когда-то) справочником и все красиво отображает в отчетах. Про структуру статей нужно помнить только тогда, когда создаешь и редактируешь соответствующий справочник, потом об этом забываешь и оперируешь обычными понятиями: "Хлеб", "Батарейки", а не "Расходы: Продукты: Хлебобулочные: Хлеб" или "Расходы: Техника: Расходные материалы: Батарейки"... И при этом названия статей (наименований) и групп могут быть сколь угодно длинными, как Вам удобно.

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

У вас элемент справочника (конкретное наименование) называется "Статья". Как мне кажется, слово "Статья" (или "Категория" и, соответственно "подстатья", "подкатегория") более применимо к тому, что у вас называется "Группа статей". А элемент справочника (который у вас "Статья") можно назвать чем-нибудь типа "Наименование", "Позиция". Т.о., "Статьи" и "Подстатьи" формируют дерево (иерархию), а "Позиции", "Наименования" создают наполнение этого дерева.
На сколько я помню, когда говорят о бюджете, оперируют понятием "Статья бюджета", которое подразумевает как раз группу каких-либо товаров или услуг. Поэтому, имеющаяся в MoneyTracker терминалогимя меня несколько сбивала с толку.
Думаю, подавляющее большинство не задумываются о том, что такое "статья бюджета" :D , поэтому у них такого конфликта терминов не происходит (да и вообще речи о бюджете пока нет ;)). К тому же это общепринятое в программах такого рода название: "категория" или "статья". Мы выбрали "статья". Это ведь просто условность, как назвать, лишь бы было понятно, о чем речь и достаточно коротко. Например, "наименование" очень уж длинно, а фраза "название наименования" вообще никуда не годится. Вначале мы вообще использовали слово "товары". Потом пришлось добавить "услуги". Потом выяснилось, что и этим всего не исчерпаешь :o , поэтому получилось "статьи".

Аватара пользователя
Анастасия
Разработчик
Разработчик
Сообщения: 692
Зарегистрирован: Ср ноя 21, 2007 6:56 am
Контактная информация:

Сообщение Анастасия »

Цитата:

Расходы - ??? рублей
- связь - 1500 рублей
- дом - 4500 рублей
- питание - 7540 рублей

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



То же самое и здесь, неясности нет: "Расходы" = "Связь" + "Дом" + "Питание" = 13540 руб.
А "Питание" = Молоко(1000) + Мясо(2540) + Фрукты(2000) + Овощи(1000) + Крупы(500) + Разное(500) = 7540
И т.д.

Т.о. можно дать такое определение:
Итог для элемента уровня (N-1) равен сумме итогов элементов уровня N, находящихся у него в подчинение.
И если суммирование проводить от наиболее низких уровней к верхним, то все хорошо и логично считается.
Нет, все-таки мы с Вами не совсем друг друга понимаем. Вы говорили (как я поняла), что на элементы любого уровня (в том числе группы) можно вносить расходы. Так вот, рассмотрим опять пример выше со структурой:

Расходы
- связь
- дом
- питание

Я создаю следующие расходы:
"Расходы" - 1000 рублей
"Расходы: связь" - 500 рублей
"Расходы: дом" - 200 рублей
"Расходы: питание" - 2000 рублей.

Что мне выведется в итоговом отчете по группе "Расходы":
1. 1000 рублей (просто расходы, записанные на эту группу)
2. 500+200+2000=2700 (все расходы уровнем ниже)
3. 1000+500+200+2000 =3700 (вообще все)

Какой вариант действует? А если действует какой-то один, как получить остальные цифры (остальных двух вариантов), они ведь тоже важны?

poa
Опытный пользователь
Опытный пользователь
Сообщения: 65
Зарегистрирован: Сб фев 16, 2008 6:50 am
Откуда: Tomsk
Контактная информация:

Сообщение poa »

Создайте в соответствующих папках статьи "Разное лекарства", "Разное продукты", "Разное развлечения" и т.п. Будете набирать "Разное ", Вам выпадут все эти варианты, выберете нужное. Так же быстро, как и в Вашем варианте.
да, пожалуй.
Вопрос тот же: а зачем Вам видеть полный путь?
Даже не знаю как это объяснить. Но везде, где есть возможность (FAR Manager, Проводник, консоль, ...) я выбираю видеть полный путь. Тогда я точно знаю где я.
Мы это видим там: человек приходит и просто вносит в программу, что он купил: батарейку, хлеб, молоко, заколку для волос, вот такими обычными словами. А программа сама все разносит по группам в соответствии с созданным (когда-то) справочником и все красиво отображает в отчетах. Про структуру статей нужно помнить только тогда, когда создаешь и редактируешь соответствующий справочник, потом об этом забываешь и оперируешь обычными понятиями: "Хлеб", "Батарейки", а не "Расходы: Продукты: Хлебобулочные: Хлеб" или "Расходы: Техника: Расходные материалы: Батарейки"... И при этом названия статей (наименований) и групп могут быть сколь угодно длинными, как Вам удобно.
Сдаюсь :). Да, вероятно, для подовляющего большинства людей так, как сделано у вас проще и удобней.
Нет, все-таки мы с Вами не совсем друг друга понимаем. Вы говорили (как я поняла), что на элементы любого уровня (в том числе группы) можно вносить расходы. Так вот, рассмотрим опять пример выше со структурой:

Расходы
- связь
- дом
- питание

Я создаю следующие расходы:
"Расходы" - 1000 рублей
"Расходы: связь" - 500 рублей
"Расходы: дом" - 200 рублей
"Расходы: питание" - 2000 рублей.

Что мне выведется в итоговом отчете по группе "Расходы":
1. 1000 рублей (просто расходы, записанные на эту группу)
2. 500+200+2000=2700 (все расходы уровнем ниже)
3. 1000+500+200+2000 =3700 (вообще все)
В предыдущем своем посте в самом конце, где я приводил скриншот отчета в КэшОрге, эта ситуация описана:
Кстати, здесь "Молочное [Незаданное]" это виртуальная категория - это все те "Наименования"(листья), которые принадлежат непосредственно ветви "Молочные", А "Сыр" - это уже существующая подкатегория. Т.е. тут не только крайние "Ветки" могут иметь "листья", но и "ветки" более высого уровня.
Т.е. в вашем примере (хотя, пожалуй, хранить "Позиции" в самом в "Корне" "Расходов" не очень хорошо) было бы так:

Расходы:3700
- Расходы [Незаданное]: 1000
- Дом: 200
- Питание: 2000
- Связь: 500

Где "Расходы [Незаданное]" - это виртуальная категория в которой собраны все те позиции, котоыре принадлежат "Расходам" непосредственно.
Думаю, подавляющее большинство не задумываются о том, что такое "статья бюджета" , поэтому у них такого конфликта терминов не происходит (да и вообще речи о бюджете пока нет ).
Надеюсь, только пока :)
К тому же это общепринятое в программах такого рода название: "категория" или "статья". Мы выбрали "статья".
Согласен. Но именно потому, что в тех программах это и есть "категория" или "статья" - у них нет справочника товаров и услуг ("Наименований").
Это ведь просто условность, как назвать, лишь бы было понятно, о чем речь и достаточно коротко.
С одной стороны, вроде бы как назвать и не так важно. С другой, если есть устоявшася терминология, то возникает некоторая путанница (по крайней мере у тех, кто к этой терминологии привык :) ). Но если подумать, что программа ориентирована на среднестатистического пользователя, далекого от бухгалтерии, то, возможно, действительно мало кто обратит на это внимание.
Например, "наименование" очень уж длинно, а фраза "название наименования" вообще никуда не годится. Вначале мы вообще использовали слово "товары". Потом пришлось добавить "услуги". Потом выяснилось, что и этим всего не исчерпаешь , поэтому получилось "статьи".
Да, подходящего емкого и краткого слова для "Наименования" я тоже пока не придумал.
Если придумаю, то напишу :)

Ответить