Наверное, вы правы, переход по Enter в составе расхода/дохода будет довольно полезной функцией. Постараемся это реализовать.Так я-то говорю не про все контролы, а только про табличную часть - для всех остальных контролов Таб самое то, а Ентер действительно вне табличной должен действовать как "Добавить"/"Сохранить"/"ОК" . Но в табличной части сейчас Ентер действует совсем не так:
- если поле не в режиме редактирования, Ентер переводит его в режим редактирования
- если поле в режиме редактирования, Ентер подтверждает ввод и остается в этом же поле. И если его сдвинуть в правую ячейку, то как раз таки будет то, что нужно - ввел значание, ентер, ввел значение ентер - рука никуда не скачет. Закончил ввод данных в таблице - Таб (выйти за пределы таблицы), Ентер - "Сохранить".
Т.е., подчеркну, очень желательно чтобы в табличной части карточки Ентер, подтверждая ввод, переходил на следующее в строке поле (как в Экселе) (либо на новую, строку, если поля в строке кончились).
Некоторые соображение по поводу работы с программой
Модератор: Анастасия
-
- Опытный пользователь
- Сообщения: 65
- Зарегистрирован: Сб фев 16, 2008 6:50 am
- Откуда: Tomsk
- Контактная информация:
...WL0007
Сохранение истории примечаний, ввод с автопоиском по истории по первым введенным буквам.
Я примечания заполняю довольно часто, и часто они повторяются, поэтому такая история была бы полезной
WL0008
Возможность создавать счета и наименования товаров и услуг не только в самых последних подгруппах, но и более высокого уровня.
Сейчас получается так, что я не могу в группе создать подгруппу (ветку) и счет (лист) одновременно. "Листья" можно создавать только на "ветке", которая не имеет других "ветевей".
Примеры (это то, как я хотел организовать данные, но не вышло):
ЗАГЛАВНЫЕ БУКВЫ - Это группы
Смешанный регистр - это непосредственно счета либо наименования товаров и услуг.
Что касается статей, немного смущает терминология.
На мой взгляд, слово "Статья" соответствует группе определенных товаров и услуг, в то время как у вас "статья" означает уже конкретное наименование товара или услуги.
Но ведь когда говорят "Статья буджета", имею ввиду ведь "Питание" или "Питание\Молочное", например, а не "Йогурт Данон 500мл".
Есть предложение по поводу вида отчета "Доходы и расходы по статьям"
Когда выбирается группировка по "Группам статей" (в моей терминалогии по "статьям", "категориям"), то в отчете фигурируют только категории соответствующие уровню вложенности. Получается все в кучу и не очень внятный отчет.
Если бы в отчете присутствовали и родительские категории, то было бы более удобно и наглядно (особенно, если разные уровни выделять отступами или другим оформлением (размер шрифта, начертание, ...), что-то типа этого:
И, если бы отчет был интерактивным, можно было бы тут же выбирать уровень детализации, и тут же можно строить график либо всех, либо выбранной подкатегории, чтобы визуально оценить расходы/доходы
И, кстати, вы же каким-то образом определяете транзация доходная или расходная? Думаю, имеет смысл в конфигураторе отчета поставить поле, позволяющее выбрать что отражать в отчете - доходы, расходы, или все вместе. Я в КэшОрге регулярно строил графики только по дохдодам, либо только по расходам, чтобы видеть, то что нужно, и не видеть лишнюю информацию
Сохранение истории примечаний, ввод с автопоиском по истории по первым введенным буквам.
Я примечания заполняю довольно часто, и часто они повторяются, поэтому такая история была бы полезной
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
Возможность создавать счета и наименования товаров и услуг не только в самых последних подгруппах, но и более высокого уровня
Такая детализация (группа, расходы по статьям, итого по группе и т.д.) есть в отчете, когда выбрана опция "по статьям", а не по "группам статей". Что касается отчета по группам статей он обычно не такой большой, и что там "в кучу", не ясно. Приведите пример. Ваш больше походит на отчет с опцией "по статьям". Попробуйте также просто сделать несколько сохраненных отчетов с настроенным фильтром по группам, чтобы не мешать "телевизор с фруктами".Есть предложение по поводу вида отчета "Доходы и расходы по статьям"
Когда выбирается группировка по "Группам статей" (в моей терминалогии по "статьям", "категориям"), то в отчете фигурируют только категории соответствующие уровню вложенности. Получается все в кучу и не очень внятный отчет.
Если бы в отчете присутствовали и родительские категории, то было бы более удобно и наглядно (особенно, если разные уровни выделять отступами или другим оформлением (размер шрифта, начертание, ...), что-то типа этого:
В печатной форме отчета доходы и расходы разнесены по разным страницам, можно смотреть ту, которая Вам нужна. При графическом отображении отчетов Вы также можете выбрать, что отображать: доходы, расходы, баланс, то и другое и т.д. Все эти настройки в отчетах сохраняются.И, кстати, вы же каким-то образом определяете транзация доходная или расходная? Думаю, имеет смысл в конфигураторе отчета поставить поле, позволяющее выбрать что отражать в отчете - доходы, расходы, или все вместе. Я в КэшОрге регулярно строил графики только по дохдодам, либо только по расходам, чтобы видеть, то что нужно, и не видеть лишнюю информацию
-
- Опытный пользователь
- Сообщения: 65
- Зарегистрирован: Сб фев 16, 2008 6:50 am
- Откуда: Tomsk
- Контактная информация:
Если не сложно, могли бы вы в вкраце пояснить почему?Такая возможность не планируется. Мы решили остановиться именно на такой структуре.Цитата:
WL0008
Возможность создавать счета и наименования товаров и услуг не только в самых последних подгруппах, но и более высокого уровня
Я непросто так придумываю что-бы такое поменять в программе, все то, о чем я пишу, это то, на чем я реально спотыкаюсь, при использовании вашей программы. Конечно сказывается привычка работы с другой системой.
Не соглашусь, т.к. в моем примере конкретных наименований (позиций) нет. А есть только иерархия категорий ("Групп статей" в вашей номенклатуре), соответственно и опцию группировки я выбираю "Группы статей". Пример привожу. Вот что у меня получилось при следующих опциях:Такая детализация (группа, расходы по статьям, итого по группе и т.д.) есть в отчете, когда выбрана опция "по статьям", а не по "группам статей". Что касается отчета по группам статей он обычно не такой большой, и что там "в кучу", не ясно. Приведите пример. Ваш больше походит на отчет с опцией "по статьям". Попробуйте также просто сделать несколько сохраненных отчетов с настроенным фильтром по группам, чтобы не мешать "телевизор с фруктами".Цитата:
Есть предложение по поводу вида отчета "Доходы и расходы по статьям"
Когда выбирается группировка по "Группам статей" (в моей терминалогии по "статьям", "категориям"), то в отчете фигурируют только категории соответствующие уровню вложенности. Получается все в кучу и не очень внятный отчет.
Если бы в отчете присутствовали и родительские категории, то было бы более удобно и наглядно (особенно, если разные уровни выделять отступами или другим оформлением (размер шрифта, начертание, ...), что-то типа этого:
Группировка: Группы статей
Вложенность: 2
Возможно вы ведете речь о случае, когда вложенность 1. Тогда все ясно, но при больших значениях получается каша - категории отсортированы по алфавиту и, поскольку родительские категории не присутствуют, то все вперемешку.
Мой же пример (повторюсь, содержит только категории, без конкретных наименований), ИМХО, позволяет лучше увидеть картину
Код: Выделить всё
Коммунальные услуги 3000 руб
-Квартира 2000 руб
-Телефон 500 руб
-Электричество 500 руб
Питание 2000 руб
-Овощи 300 руб
-Фрукты 500 руб
-Молочное 300 руб
--Сыр 100 руб
--Молочное(без подкатегории) 200 руб
-Крупы 200 руб
-Сладости 200 руб
-Мясо 500 руб
В случае вашего варианта, у меня несколько рябит в галазах, поскольку много разделителей пустых строк (особенно, если элементов для одной группы в таблице мало, как в этом случае).
Да, вы правы. Здесь действительно я не заметил в форме с графическим отчетом возможности убирать лишнее.В печатной форме отчета доходы и расходы разнесены по разным страницам, можно смотреть ту, которая Вам нужна. При графическом отображении отчетов Вы также можете выбрать, что отображать: доходы, расходы, баланс, то и другое и т.д. Все эти настройки в отчетах сохраняются.
- Анастасия
- Разработчик
- Сообщения: 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
- Контактная информация:
По второму вопросу.
Что касается отчета по группам статей, пока выделять родительские группы не будем. Как вариант решения, который я уже предлагала, сделать несколько сохраненных отчетов вида:
- отчет по группам по питанию
- отчет по группам по связи и технике
- отчет по группам по развлечениям
и т.д.
И потом смотреть каждый отчет отдельно, чтобы не путать разнородные группы в одном отчете.
Что касается предложения по оптимизации печатной формы отчета по статьям, большое спасибо, так гораздо компактнее , обязательно переработаем.
Что касается отчета по группам статей, пока выделять родительские группы не будем. Как вариант решения, который я уже предлагала, сделать несколько сохраненных отчетов вида:
- отчет по группам по питанию
- отчет по группам по связи и технике
- отчет по группам по развлечениям
и т.д.
И потом смотреть каждый отчет отдельно, чтобы не путать разнородные группы в одном отчете.
Что касается предложения по оптимизации печатной формы отчета по статьям, большое спасибо, так гораздо компактнее , обязательно переработаем.
- Анастасия
- Разработчик
- Сообщения: 692
- Зарегистрирован: Ср ноя 21, 2007 6:56 am
- Контактная информация:
Для poa:
Мы посовещались и решили, что Ваш вклад в развитие программы заслуживает получения лицензии .
Если Вас это заинтересует, свяжитесь с нами (sales@dominsoft.ru)
Мы посовещались и решили, что Ваш вклад в развитие программы заслуживает получения лицензии .
Если Вас это заинтересует, свяжитесь с нами (sales@dominsoft.ru)
-
- Опытный пользователь
- Сообщения: 65
- Зарегистрирован: Сб фев 16, 2008 6:50 am
- Откуда: Tomsk
- Контактная информация:
Спасибо большое!
Неожиданная и поэтому еще более приятная для меня новость
У вас элемент справочника (конкретное наименование) называется "Статья". Как мне кажется, слово "Статья" (или "Категория" и, соответственно "подстатья", "подкатегория") более применимо к тому, что у вас называется "Группа статей". А элемент справочника (который у вас "Статья") можно назвать чем-нибудь типа "Наименование", "Позиция". Т.о., "Статьи" и "Подстатьи" формируют дерево (иерархию), а "Позиции", "Наименования" создают наполнение этого дерева.
На сколько я помню, когда говорят о бюджете, оперируют понятием "Статья бюджета", которое подразумевает как раз группу каких-либо товаров или услуг. Поэтому, имеющаяся в MoneyTracker терминалогимя меня несколько сбивала с толку.
Бывает так, что я не вижу необходимости точно идентифицировать расход (или есть чек, но в нем не пробито наименование, а я его уже забыл), и тогда я записывал в подкатегорию "Разное". И таких "Разных" у меня было не сколько (в "Питании", "Развлечениях", "Хозрасходах" и т.д.). В Money Tracker я тоже попробовал создать подобную схему, но не получилось из-за требования к уникальности. Пришлось мне изощряться. Например в ветке "Здоровье\Лекарства и ИМН" я создал позицию "З>ЛиИМН>Разное". Но это жутко выглядит и не удобно набирать.
В том же КэшОрге такого ограничения не было. И когда набираешь буквы, он подствляет список, где представлены все совпадения. Нужный можно выбрать. Вот как это выглядит:
Т.е. можно набрать часть слова, а нужную статью выбрать из списка. Причем подстановка при наборе работает не только по первым буквам, но осуществляется поиск введенной подстроки внутри названий. Причем в нашем случае поиск в названиях категорий вести не нужно, достаточно только в названиях "Наименований" (как я понимаю, сейчас так и реализовано у вас)
После того как выбран нужный пункт там он отражался так:
"Комм.услуги:Телефон" или "Питание:Молочное:Сыр". Т.е. подкатегории разделялись знаком ":" и была видна вся ветвь.
В нашем же случае можно было бы такую запись ввести:
"Питание\Молочное:Кефир 1%" - через знак "\" записывается иерархия, а знак ":" отделяет конкретное наименование. В отдельных случаях может получиться довольно длинно, конечно. Но очень наглядно. И, причем, если не существует такого пункта, то его можно создать на основании парсинга строки (в кэшорге, и где-то еще такая реализация есть). Конечно здесь сложнее, т.к. по хорошему нужно ввести дополнительные параметры нового элемента типа "единица измерения". Но можно показывать вопрос: "Такого элемента не существует. Хотите создать новый?" В случае утвердительного ответа появляется окно ввода нового наименования и соответствующие поля заполняются автоматически (название и категория), останется только ввести единицу измерения и другие желаемые параметры.
А если использовать односложные названия, тогда и полный "путь" не будет таким длинным и помнить его не нужно будет, т.к. нужные элементы будут отображаться в выпадающем списке по мере набора букв.
А "Питание" = Молоко(1000) + Мясо(2540) + Фрукты(2000) + Овощи(1000) + Крупы(500) + Разное(500) = 7540
И т.д.
Т.о. можно дать такое определение:
Итог для элемента уровня (N-1) равен сумме итогов элементов уровня N, находящихся у него в подчинение.
И если суммирование проводить от наиболее низких уровней к верхним, то все хорошо и логично считается.
Вот так это может выглядеть (кстати, это же и пример интерактивного отчета - можно подуровни разворачивать для детализации, и сворачивать, если не нужны. А двойной клик на категории покажет отельное окно с транзакциями, формирующими данный итог):
Кстати, здесь "Молочное [Незаданное]" это виртуальная категория - это все те "Наименования"(листья), которые принадлежат непосредственно ветви "Молочные", А "Сыр" - это уже существующая подкатегория. Т.е. тут не только крайние "Ветки" могут иметь "листья", но и "ветки" более высого уровня.
Неожиданная и поэтому еще более приятная для меня новость
Судя по всему, произошло недопонимание (все-таки есть определенный минус в общении через форум, все нюансы сложно сразу изложить ). Я ни в коей мере не хотел наделять "Группы статей" свойствами объекта "Статья" - это разные сущности. Я говорил о терминологии. На мой взгляд, не совсем корректно определены эти понятия.Если говорить совсем коротко, в программе объекты "Группа статей" и "Статья" имеют разные функции, за счет чего можно создавать удобные отчеты и просмотр данных, можно будет сделать гибкий бюджет. Вы предлагаете объект "Группа статей" наделить свойствами объекта "Статья", что сделать непросто, и на наш взгляд, даже нельзя
У вас элемент справочника (конкретное наименование) называется "Статья". Как мне кажется, слово "Статья" (или "Категория" и, соответственно "подстатья", "подкатегория") более применимо к тому, что у вас называется "Группа статей". А элемент справочника (который у вас "Статья") можно назвать чем-нибудь типа "Наименование", "Позиция". Т.о., "Статьи" и "Подстатьи" формируют дерево (иерархию), а "Позиции", "Наименования" создают наполнение этого дерева.
На сколько я помню, когда говорят о бюджете, оперируют понятием "Статья бюджета", которое подразумевает как раз группу каких-либо товаров или услуг. Поэтому, имеющаяся в MoneyTracker терминалогимя меня несколько сбивала с толку.
Тогда никокого противоречия с вашим видением бюджета (а я, в принципе, также его вижу) не будетИ этот же недостаток помешает потом созданию бюджета в том виде, в каком мы его видим. Например, мы полагаем, что можно будет задать ограничение полностью на группу Продукты (10000 рублей), и внутри на группу Мясные (2500 рублей), и на группу Фрукты (2500 рублей). Тогда программа будет контролировать как расходы по мясным и фруктовым статьям отдельно, так и будет контролировать что ВСЕ расходы на питание не превзойдут заданной суммы 10000 рублей. Если эта группа приравнивается по свойствам к статье, эта функция уже не реализуема, так как это будет просто ограничение по статье, а не как задумано, по всем вложенным в группу статьям...
Хорошо, что вы затронули эту тему, я как раз столкнулся с такой проблемой, что нельзя создавать в разных ветвях подкатегории с одинаковыми названиями. Вот почему:1. При такой организации дерева, Вам нельзя будет (впрочем, как и у нас), называть одинаково группы или статьи. Почему? Если у Вас будет структура вида:
Бывает так, что я не вижу необходимости точно идентифицировать расход (или есть чек, но в нем не пробито наименование, а я его уже забыл), и тогда я записывал в подкатегорию "Разное". И таких "Разных" у меня было не сколько (в "Питании", "Развлечениях", "Хозрасходах" и т.д.). В Money Tracker я тоже попробовал создать подобную схему, но не получилось из-за требования к уникальности. Пришлось мне изощряться. Например в ветке "Здоровье\Лекарства и ИМН" я создал позицию "З>ЛиИМН>Разное". Но это жутко выглядит и не удобно набирать.
В том же КэшОрге такого ограничения не было. И когда набираешь буквы, он подствляет список, где представлены все совпадения. Нужный можно выбрать. Вот как это выглядит:
Т.е. можно набрать часть слова, а нужную статью выбрать из списка. Причем подстановка при наборе работает не только по первым буквам, но осуществляется поиск введенной подстроки внутри названий. Причем в нашем случае поиск в названиях категорий вести не нужно, достаточно только в названиях "Наименований" (как я понимаю, сейчас так и реализовано у вас)
После того как выбран нужный пункт там он отражался так:
"Комм.услуги:Телефон" или "Питание:Молочное:Сыр". Т.е. подкатегории разделялись знаком ":" и была видна вся ветвь.
В нашем же случае можно было бы такую запись ввести:
"Питание\Молочное:Кефир 1%" - через знак "\" записывается иерархия, а знак ":" отделяет конкретное наименование. В отдельных случаях может получиться довольно длинно, конечно. Но очень наглядно. И, причем, если не существует такого пункта, то его можно создать на основании парсинга строки (в кэшорге, и где-то еще такая реализация есть). Конечно здесь сложнее, т.к. по хорошему нужно ввести дополнительные параметры нового элемента типа "единица измерения". Но можно показывать вопрос: "Такого элемента не существует. Хотите создать новый?" В случае утвердительного ответа появляется окно ввода нового наименования и соответствующие поля заполняются автоматически (название и категория), останется только ввести единицу измерения и другие желаемые параметры.
То, что я описал выше, позволяет решить эту проблему. А случай когда делают под каждный уровень свое поле ввода действительно очень ущербен и обычно его используют, если вложенность ограничена 2-3 уровнями (но даже при этом его использование не оправдано).То когда Вы начнете вводить расход "Российский", что нужно будет выбрать программе, сыр или сырок (или может что еще?)? А вся Ваша структура направлена именно на то, что название конечной статьи будет односложным, потому что все про нее (продукты, молочное, сыр) сказано "структурой папок". При односложном названии сложно придумать неповторяющиеся и "говорящие" названия. В таком случае, чтобы понять о чем речь нужно сделать, как в некоторых программах при вводе расхода несколько полей, где Вы сначала вводите "Продукты", потом в следующем поле "Молочные", потом "Сыр", а потом "Российский"... Это на наш взгляд ооочень медленно и неудобно, нужно помнить где находится нужная статья (полный путь!!!) и тратить больше времени на ввод. Когда я ввожу в МТ, например, "Зарядка для сотового телефона", я не задумываюсь, в какой группе эта статья, это дело программы, просто набираю несколько первых букв, а так придется помнить ВСЕ .
А если использовать односложные названия, тогда и полный "путь" не будет таким длинным и помнить его не нужно будет, т.к. нужные элементы будут отображаться в выпадающем списке по мере набора букв.
На самом-то деле, эти два примера, которые вы привели ничем не отличаются друг от друга кроме того, что в верхнем итог указан отдельной строкой в конце, а в нижнем итоговая сумма в той же строке, что и название категории более высокого уровня. Поэтому неясности нету.Второй недостаток, более важный чем первый. Предположим, что можно создавать расходы не только на статьи, но и на группы (в нашей терминологии).
Я хочу построить отчет по группе продукты по статьям. Сейчас все просто и логично
Группа продукты:
- молоко - 500 рублей
- мясо - 1500 рублей
- фрукты - 150 рублей
Итого по группе 2150 рублей.
У Вас это будет выглядеть так:
Группа продукты - 2300 рублей
- молоко - 500 рублей
- мясо - 1500 рублей
- фрукты - 150 рублей
Итого ????
Что такое "итого" в данном случае вообще не ясно (суммировать только внутри группы, или и статьи и саму группу).
То же самое и здесь, неясности нет: "Расходы" = "Связь" + "Дом" + "Питание" = 13540 руб.Расходы - ??? рублей
- связь - 1500 рублей
- дом - 4500 рублей
- питание - 7540 рублей
А вопрос вот какой: что за цифра должна быть в группе "Расходы". У нас там будет "итого" по всем подгруппам, входящим в нее. У Вас возможны варианты:
- только расход по этой группе
- расход по этой группе и по всем вложенным
И вся эта "непонятка" распространяется вниз на всю структуру дерева статей и накапливается (!)... Как ее разрешить?
А "Питание" = Молоко(1000) + Мясо(2540) + Фрукты(2000) + Овощи(1000) + Крупы(500) + Разное(500) = 7540
И т.д.
Т.о. можно дать такое определение:
Итог для элемента уровня (N-1) равен сумме итогов элементов уровня N, находящихся у него в подчинение.
И если суммирование проводить от наиболее низких уровней к верхним, то все хорошо и логично считается.
Вот так это может выглядеть (кстати, это же и пример интерактивного отчета - можно подуровни разворачивать для детализации, и сворачивать, если не нужны. А двойной клик на категории покажет отельное окно с транзакциями, формирующими данный итог):
Кстати, здесь "Молочное [Незаданное]" это виртуальная категория - это все те "Наименования"(листья), которые принадлежат непосредственно ветви "Молочные", А "Сыр" - это уже существующая подкатегория. Т.е. тут не только крайние "Ветки" могут иметь "листья", но и "ветки" более высого уровня.
- Анастасия
- Разработчик
- Сообщения: 692
- Зарегистрирован: Ср ноя 21, 2007 6:56 am
- Контактная информация:
Хорошо, что вы затронули эту тему, я как раз столкнулся с такой проблемой, что нельзя создавать в разных ветвях подкатегории с одинаковыми названиями. Вот почему:
Бывает так, что я не вижу необходимости точно идентифицировать расход (или есть чек, но в нем не пробито наименование, а я его уже забыл), и тогда я записывал в подкатегорию "Разное". И таких "Разных" у меня было не сколько (в "Питании", "Развлечениях", "Хозрасходах" и т.д.). В Money Tracker я тоже попробовал создать подобную схему, но не получилось из-за требования к уникальности. Пришлось мне изощряться. Например в ветке "Здоровье\Лекарства и ИМН" я создал позицию "З>ЛиИМН>Разное". Но это жутко выглядит и не удобно набирать.
Создайте в соответствующих папках статьи "Разное лекарства", "Разное продукты", "Разное развлечения" и т.п. Будете набирать "Разное ", Вам выпадут все эти варианты, выберете нужное. Так же быстро, как и в Вашем варианте.
В гриде поиск ведется по первым символам наименования, если перейти в справочник (Ctrl+Enter), там уже фокус стоит в поле поиске по любой подстроке наименоваия. Выводить полный путь к наименованию не видим смысла, может получиться очень длинно Вот Вы вводите каждый день расход "Хлеб", и все время будет выпадать жуткой ширины полоса, в которой что-то вроде "Расходы: Продукты: Хлебобулочные: Хлеб". А зачем? И так ясно, что хлеб где-то там . В том и цель была, чтобы нужно было только знать, как называется статья (наименование), а не нужно было помнить где она. Программа сама все найдет, где эта статья, поэтому и ограничение на уникальность наименований есть (как его избежать, см. выше на Вашем примере).Т.е. можно набрать часть слова, а нужную статью выбрать из списка. Причем подстановка при наборе работает не только по первым буквам, но осуществляется поиск введенной подстроки внутри названий. Причем в нашем случае поиск в названиях категорий вести не нужно, достаточно только в названиях "Наименований" (как я понимаю, сейчас так и реализовано у вас)
После того как выбран нужный пункт там он отражался так:
"Комм.услуги:Телефон" или "Питание:Молочное:Сыр". Т.е. подкатегории разделялись знаком ":" и была видна вся ветвь.
В нашем же случае можно было бы такую запись ввести:
"Питание\Молочное:Кефир 1%" - через знак "\" записывается иерархия, а знак ":" отделяет конкретное наименование. В отдельных случаях может получиться довольно длинно, конечно. Но очень наглядно. И, причем, если не существует такого пункта, то его можно создать на основании парсинга строки (в кэшорге, и где-то еще такая реализация есть). Конечно здесь сложнее, т.к. по хорошему нужно ввести дополнительные параметры нового элемента типа "единица измерения". Но можно показывать вопрос: "Такого элемента не существует. Хотите создать новый?" В случае утвердительного ответа появляется окно ввода нового наименования и соответствующие поля заполняются автоматически (название и категория), останется только ввести единицу измерения и другие желаемые параметры.
Создать новый элемент легко с помощью горячих клавиш (в справочнике Ins), в новом релизе также будет действовать клавиша Shift+F4, которая позволит прямо из карточки расхода создать новый элемент.
Вопрос тот же: а зачем Вам видеть полный путь?А если использовать односложные названия, тогда и полный "путь" не будет таким длинным и помнить его не нужно будет, т.к. нужные элементы будут отображаться в выпадающем списке по мере набора букв.
Мы это видим там: человек приходит и просто вносит в программу, что он купил: батарейку, хлеб, молоко, заколку для волос, вот такими обычными словами. А программа сама все разносит по группам в соответствии с созданным (когда-то) справочником и все красиво отображает в отчетах. Про структуру статей нужно помнить только тогда, когда создаешь и редактируешь соответствующий справочник, потом об этом забываешь и оперируешь обычными понятиями: "Хлеб", "Батарейки", а не "Расходы: Продукты: Хлебобулочные: Хлеб" или "Расходы: Техника: Расходные материалы: Батарейки"... И при этом названия статей (наименований) и групп могут быть сколь угодно длинными, как Вам удобно.
- Анастасия
- Разработчик
- Сообщения: 692
- Зарегистрирован: Ср ноя 21, 2007 6:56 am
- Контактная информация:
Думаю, подавляющее большинство не задумываются о том, что такое "статья бюджета" , поэтому у них такого конфликта терминов не происходит (да и вообще речи о бюджете пока нет ). К тому же это общепринятое в программах такого рода название: "категория" или "статья". Мы выбрали "статья". Это ведь просто условность, как назвать, лишь бы было понятно, о чем речь и достаточно коротко. Например, "наименование" очень уж длинно, а фраза "название наименования" вообще никуда не годится. Вначале мы вообще использовали слово "товары". Потом пришлось добавить "услуги". Потом выяснилось, что и этим всего не исчерпаешь , поэтому получилось "статьи".У вас элемент справочника (конкретное наименование) называется "Статья". Как мне кажется, слово "Статья" (или "Категория" и, соответственно "подстатья", "подкатегория") более применимо к тому, что у вас называется "Группа статей". А элемент справочника (который у вас "Статья") можно назвать чем-нибудь типа "Наименование", "Позиция". Т.о., "Статьи" и "Подстатьи" формируют дерево (иерархию), а "Позиции", "Наименования" создают наполнение этого дерева.
На сколько я помню, когда говорят о бюджете, оперируют понятием "Статья бюджета", которое подразумевает как раз группу каких-либо товаров или услуг. Поэтому, имеющаяся в MoneyTracker терминалогимя меня несколько сбивала с толку.
- Анастасия
- Разработчик
- Сообщения: 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 (вообще все)
Какой вариант действует? А если действует какой-то один, как получить остальные цифры (остальных двух вариантов), они ведь тоже важны?
-
- Опытный пользователь
- Сообщения: 65
- Зарегистрирован: Сб фев 16, 2008 6:50 am
- Откуда: Tomsk
- Контактная информация:
да, пожалуй.Создайте в соответствующих папках статьи "Разное лекарства", "Разное продукты", "Разное развлечения" и т.п. Будете набирать "Разное ", Вам выпадут все эти варианты, выберете нужное. Так же быстро, как и в Вашем варианте.
Даже не знаю как это объяснить. Но везде, где есть возможность (FAR Manager, Проводник, консоль, ...) я выбираю видеть полный путь. Тогда я точно знаю где я.Вопрос тот же: а зачем Вам видеть полный путь?
Сдаюсь . Да, вероятно, для подовляющего большинства людей так, как сделано у вас проще и удобней.Мы это видим там: человек приходит и просто вносит в программу, что он купил: батарейку, хлеб, молоко, заколку для волос, вот такими обычными словами. А программа сама все разносит по группам в соответствии с созданным (когда-то) справочником и все красиво отображает в отчетах. Про структуру статей нужно помнить только тогда, когда создаешь и редактируешь соответствующий справочник, потом об этом забываешь и оперируешь обычными понятиями: "Хлеб", "Батарейки", а не "Расходы: Продукты: Хлебобулочные: Хлеб" или "Расходы: Техника: Расходные материалы: Батарейки"... И при этом названия статей (наименований) и групп могут быть сколь угодно длинными, как Вам удобно.
В предыдущем своем посте в самом конце, где я приводил скриншот отчета в КэшОрге, эта ситуация описана:Нет, все-таки мы с Вами не совсем друг друга понимаем. Вы говорили (как я поняла), что на элементы любого уровня (в том числе группы) можно вносить расходы. Так вот, рассмотрим опять пример выше со структурой:
Расходы
- связь
- дом
- питание
Я создаю следующие расходы:
"Расходы" - 1000 рублей
"Расходы: связь" - 500 рублей
"Расходы: дом" - 200 рублей
"Расходы: питание" - 2000 рублей.
Что мне выведется в итоговом отчете по группе "Расходы":
1. 1000 рублей (просто расходы, записанные на эту группу)
2. 500+200+2000=2700 (все расходы уровнем ниже)
3. 1000+500+200+2000 =3700 (вообще все)
Т.е. в вашем примере (хотя, пожалуй, хранить "Позиции" в самом в "Корне" "Расходов" не очень хорошо) было бы так:Кстати, здесь "Молочное [Незаданное]" это виртуальная категория - это все те "Наименования"(листья), которые принадлежат непосредственно ветви "Молочные", А "Сыр" - это уже существующая подкатегория. Т.е. тут не только крайние "Ветки" могут иметь "листья", но и "ветки" более высого уровня.
Расходы:3700
- Расходы [Незаданное]: 1000
- Дом: 200
- Питание: 2000
- Связь: 500
Где "Расходы [Незаданное]" - это виртуальная категория в которой собраны все те позиции, котоыре принадлежат "Расходам" непосредственно.
Надеюсь, только покаДумаю, подавляющее большинство не задумываются о том, что такое "статья бюджета" , поэтому у них такого конфликта терминов не происходит (да и вообще речи о бюджете пока нет ).
Согласен. Но именно потому, что в тех программах это и есть "категория" или "статья" - у них нет справочника товаров и услуг ("Наименований").К тому же это общепринятое в программах такого рода название: "категория" или "статья". Мы выбрали "статья".
С одной стороны, вроде бы как назвать и не так важно. С другой, если есть устоявшася терминология, то возникает некоторая путанница (по крайней мере у тех, кто к этой терминологии привык ). Но если подумать, что программа ориентирована на среднестатистического пользователя, далекого от бухгалтерии, то, возможно, действительно мало кто обратит на это внимание.Это ведь просто условность, как назвать, лишь бы было понятно, о чем речь и достаточно коротко.
Да, подходящего емкого и краткого слова для "Наименования" я тоже пока не придумал.Например, "наименование" очень уж длинно, а фраза "название наименования" вообще никуда не годится. Вначале мы вообще использовали слово "товары". Потом пришлось добавить "услуги". Потом выяснилось, что и этим всего не исчерпаешь , поэтому получилось "статьи".
Если придумаю, то напишу