В рассмотрении

Свои, чужие счета. Объект "имущество", Привязка счетов к контрагентам. Модуль - "Отчеты"

Здравствуйте Александр!

Приобрел лицензию на вашу программу, после тестирования и изучения, примерно 20 подобных приложений. Функционал Вашей программы показался наиболее приемлемым, а архитектура, с хорошей перспективой дополнения и доработки. Достаточно гибкая возможность настроек, под конкретные нужды. Все же ряд пожеланий есть.

1. Деньги попадают в "систему" путем взятия кредита (псевдостатья "доход"), либо на статью "доходы" счета. Деньги фактически выводятся из "системы" через чеки (попадая на статью "расход" конкретного счета), выплату долгов (псевдостатья "расход"), статью "расход" счета.

Причем не важно, сколько счетов создал пользователь, программа понимает их, как принадлежащие одному пользователю, с псевдоразделением на виды (присваивание разных имен). Реального разделения нет. Поэтому операция "перевод" отражается с нулевым балансом. Ведь по сути для "системы" все равно, что со счета "Банк" переведено на счет "Кошелек" 100 руб. (-100 "Банк" на +100"Кошелек"), итог - ноль. Это не проблема, если действительно требуется учет между своими счетами.

Но если учесть, тот аспект, что в коммерческой лицензии возможна работа с категорией "Контрагенты", положение лишь с одним видом счетов, обесценивает функциональность программы. Контрагенты есть, а счетов для них, по сути нет, ведь все счета по архитектуре программы, только пользователя.

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

"Чужие" счета будут иметь свойства, такие, что при переводе средств со "своего" (пользовательского) счета, на "чужой" (контрагентский) счет, баланс перевода не будет нулевым, а будет полноценное списание и полноценное зачисление средств по одной транзакции- "перевод". Таким образом не придется делать две операции разрыва (приход по одному счету и расход по другому), как например в сегодняшней архитектуре псевдоразделения.

Также, целесообразно, при создании типов "пользовательских" и "контрагентских" счетов учесть возможность привязки счетов к контрагентам, чтобы каждый раз не указывать счет контрагента и вручную добавлять в категориях транзакции конкретного контрагента. Таким образом можно сделать связку, которая позволит осуществить транзакцию по контрагенту, а операция автоматом отразится на счете контрагента.

Если архитектура программы (по крайней мере коммерческая лицензия) имеет категорию "контрагенты" и возможно предложение по созданию нескольких типов счетов покажется вам интересным и целесообразным, то конечно само собой напрашивается введение "объекта" - "Имущество". Здесь, в предложениях, я видел, что подобное предложение уже рассматривается. Вопрос лишь в том, в каком виде это представляет тот, кто выдвигает подобное предложение. Основная идея, как я почитал, это организовать данный раздел, как в программе "Sanuel Family".

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

Лично меня же, в реализации раздела "Имущество", в первую очередь интересует (в разрезе концепции разделения счетов и привязки счетов, к контрагентам) возможность "объектного" исполнения такого раздела.

Раздел имущество, должен быть неким электронным складом, своеобразным счетом, или типом счета, в котором отсутствуют в чистом виде стать - "доход", "расход". Имущество, должно приобретаться на средства с "денежных" счетов, помещаться на склад(списание должно проходить со счета приобретения) и может быть реализовано за деньги, которые при этом можно положить на "денежный" счет (добавление в статью "доход" выбранного пользователем счета), а имущество, со "склада" списывается. Только в статье "доход" "денежного" счета указывается, что это доход от реализации имущества. Объект "имущество" должен иметь свои категории и подкатегории, для идентификации такого имущества.

Если же учитывать и пробовать создать объект "имущество" средствами сегодняшнего функционала программы, то получается, что "создав" псевдораздел "имущество" например из счета, приходится делать кучу операций - "приход", "расход", т. е. проводок вручную, чтобы учитывать в программе имущество. Программа должна полноценно, а не "кривыми путями" помогать пользователю держать в порядке учет. Это как хороший и плохой тон программирования.

И коротко о разделе – «Отчеты». Скажу прямо, очень слабо и невразумительно в программе реализованы отчеты. Даже «простенькие» килобайтные програмки имеют более выразительное исполнение отчетов. Все-таки отчет должен быть, по моему мнению, документом. Здесь, лучше всего дело обстоит у «Fast Report». Возможность делать хорошие отчеты, на листе формата А4, чтобы это выглядело как солидный документ. Ваша программа, с серьезным подходом к разработке формы отчета значительно выиграет.

С уважением, Илья.

Комментировать

Комментарии (3)

фото
1

учитывая мои потребности в учете дом.финансов, я могу согласиться с п. 3 - "Отчеты".

фото
1

Не очень понятен смысл ввода такой сущности как счет контрагента. Под описанную схему подходят обычные операции расхода/дохода с указанием контрагента. Используя фильтры и группировку можно видеть все операции отдельного контрагента, денежный поток и сальдо. Счет контрагента будет показывать только сальдо, что можно при желании вывести и без счета, хоть и не так удобно. Но это можно решить и без ввода дополнительных сущностей.

фото
1

Значит, что счет контрагента не учитывается в счетах хозяина, в итоговом балансе счетов.