Конкретизируйте. Имеете в виду, по написанному в вольной форме комментарию определить ее категорию? Не проще ли тогда вместо написанния длинного текста просто выбрать руками нужную категорию в выпадающем списке?
Не по комментарию. По мерчанту. Если трата была в супермаркете, то с вероятностью в 90% это категория "бакалея". В тех редких случаях, когда это не "бакалея", можно исправить категорию вручную. Конечно, придется сделать какой-то начальный список категорий по мерчантам, но потом раз в какой-то период можно делать выборку по всем транзакциями, и строить пары "мерчант-категория" и так постоянно улучшать автоматическое определение категории. Но это уже вам должно быть виднее, как делать.
Это, без сомнения, основной недостаток ДФ. Мы работаем в этом направлении, пробуем разные варианты. Но наши банки пока не видят необходимости предоставлять возможность интеграции со своими биллингами.
Имелось ввиду, что почти все украинские банки позволяют экспортировать выписку по карточному счету в файл. Сделайте возможность импортирования таких файлов (хотя бы для 5 наиболее крупных) и это уже будет круто.
Сводный баланс увидеть можно. Можно в отчетках "Остатки", можно настроить виджеты, для отображения остатков по выборкам счетов.
Вам не кажется, что это должно присутствовать там сразу? По логике, это ваша базовая функциональность, все ведь хотят видеть сводный баланс. Для тех, кто его не хочет видеть виджет может быть удаляемым.
Не вижу необходимости. Обоснуйте.
Человек может держать деньги наличными в бумажнике, на счету в банке, на пластике и еще рядом способов, причем одновременно. Расходовать он их может тоже различным способом: мелкие суммы наличными, средние суммы с пластика, крупные или регулярные суммы банковскими переводами. Очень распространенный сценарий.
Удобно видеть расходные и доходные счета сгруппированными по иерархическому принципу вроде (названия придумал от балды):
- Доходы: ХХХХХ грн.
- Наличные
- З\п наличными в конверте: ХХХХ грн.
- Выиграл в карты: ХХ грн.
- З\п наличными в конверте: ХХХХ грн.
- Безналичные
- З\п на пластик: ХХХгрн.
- Проценты по депозиту: ХХ грн.
- Наличные
- Расходы: ХХХХ грн.
- Жилье:
- Коммунальные
- Проценты по кредиту
- Еда: ХХХ грн.
- Одежда: ХХХ грн.
- Авто: ХХХ грн.
- Проценты по кредиту на iPhone: XXXгрн.
- Коммунальные
Валютные остатки при подсчете эквивалента в основной валюте конвертируются по нал. курсу обмена валют в Украине на соответствующую дату. А в пересчете в основную валюту аккаунта, непосредственно, валютных операций смысла также не вижу. Кстати, если основная валюта аккаунта НЕ грвина, конвертация НЕ гривны в НЕ гривну производится по наличному крос-курсу
Соответствующая дата - это дата создания транзакции или дата месячного отчета? Было бы хорошо видеть, что, допустим, в 21 февраля килограмм гвоздей стоил 1.20 в долларовом эквиваленте, а 23 уже уже пришлось покупать за 1.40, хотя оба раза платили гривной. Ну и в интерфейсе совершенно неочевидно, на какую дату взят курс.
В той части, где речь идет про учет - вы правы. От вас требуется внесение операций. Мы работаем в направлении мобильных приложений - но это по сути тот же ручной ввод
Снизьте количество ручного ввода до минимума, хотя бы импортом тех проклятых csv, уже великое дело будет. Это основной момент, по которому подобными сервисами не хочется пользоваться в принципе (а не какие-то там конспирологические психозы по поводу налоговой).
А вот что касается суммирования чисел в колонках - с точки зрени я математики, любой агрегированный отчет так можно охарактеризовать. Но ДФ позволяют делать достаточно многосторонний анализ финансовой истории. Если есть желание - я могу описать аналитические возможности ДФ на реальных примерах.
Лучше статью на finance.ua про это напишите.
