Требуется помощь с разработкой приложения для учета личных финансов

Возможно, вам нужно объединиться с hobbit.

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

Не силён в бухгалтерской терминологии, но лучше сделать новую сущность, например «Кошелёк», который может содержать несколько счетов.

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

Очень странная идея: один счет это одна валюта. Иначе проблемы будут вида «Почему в рублях на этом счету меньше денег, а в долларах ни чего не изменилось?»

А вот если не перезагружать все, а прицельно изменять – кажется что это потребует весьма глубокого анализа.

Вот для этого существуют типовые проекты.

Ну иерархическая система счетов – не что-то новое, в gnucash тоже одни счета могут содержать другие, так что не вижу тут проблем. В отличие от новых терминов, которые могут сильнее сбивать с толку.

Чем ваша мультивалютность отличается от той, что уже есть в gnucash, где вы создаёте счёт типа placeholder, и внутри него подсчета по отдельным валютам?

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

Это не то что самому не справится, это уровень легкой задачи - хобби.

Очень странная идея: один счет это одна валюта. Иначе проблемы будут вида «Почему в рублях на этом счету меньше денег, а в долларах ни чего не изменилось?»

Ну в принципе и сейчас например в некоторых банках есть мультивалютные счета/вклады. Конечно, наверное внутри там заведены отдельные счета, но с точки зрения пользователей вроде все понятно: вот у тебя столько-то рублей, столько-то долларов. Тратишь рубли – рублей становится меньше, а долларов остается столько же.

Основная суть идеи – чтобы не приходилось руками на каждую валюту заводить свой набор счетов. Например мне больше нравится вести учет не в какой-то одной «базовой» валюте, а с равноправными валютами. То есть допустим трачу рубли на еду – записываю в Расходы:Еда:RUB, трачу грузинские лари – в Расходы:Еда:GEL. Но когда есть много категорий расходов (а может и доходов), дублировать все на каждую новую валюту – запарно. Если потом нужно привести все к одной валюте – надо посмотреть курс за соответствующую дату.

Можно посмотреть на эту идею чуть-чуть по-другому: пользователь создает не конечный счет а родительский, и к этому родительскому счету автоматически создаются дочерние счета во всех валютах

А можно поподробнее, какие есть типовые проекты и как они мне могли бы помочь с реализацией моих идей? Или имеешь в виду, что я мог бы не изобретать велосипед и пользоваться готовым gnucash?

Тем что в gnucash требуется руками заводить все подсчета

Пытался (chatgpt, gemini). Может конечно не те инструменты использовал или как-то не так, но пока не очень вышло. Исправляет одно – ломает другое.

А еще интерфейсом транзакций: пока что предполагается показывать в одной таблице транзакции (сплиты) сделанные в разных валютах, и баланс отображать в валюте сплита (потому что баланс в остальных валютах не изменился) – это примерно показано на картинке с интерфейсом по ссылке на требования в теме.

Если честно, не знаю насколько это будет удобно на практике, но вдруг да. Хотя фильтр по валюте конечно тоже хочется иметь.

Пытался сделать что-то с помощь PyQt и LLM

Познакомившись с ИИ агентом я почуствовал в себе силы в программировании. Какую программу написать?

• Вы нашли друг друга
  • Какую программу написать?

jura12

И живёте в одном городе, это судьба!

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

Ну интерфейс можешь попробовать переделать. А в одном счёте держать несколько валют я бы не стал.

Я потихоньку пилю свой велосипед.

Инструментарий: С++, Qt, SQLite.

Лицензия: GPLv2+.

Концепция:

• упрощённая модель данных доход+расход+перенос (вместо транзакций и двойного учёта), я верю, что это позволит максимально упростить дурной ввод данных, самая известная программа, построенная по этой модели – это проприетарная «Домашняя бухгалтерия» П.Козловского, ещё был старый GTK-проект Home Finances от ЛОРовца St_Junker, к сожалению, о его существовании я узнал совсем недавно и не в курсе, насколько он доведён до ума;
• поддержка максимально простого ввода с клавиатуры, всё на хоткеях (возможность работы с мышью, разумеется, сохраняется);
• импорт отовсюду, откуда только можно, в том числе (для России) из файлов JSON от приложения «Проверка чеков» ФНС, если накопить базу псевдонимов, это очень сильно автоматизирует ввод расходов;
• мультивалютность – примерно такая же, как в уже упомянутой «Домашней бухгалтерии».

Проект всё ещё неработоспособен, но уже (к сожалению или счастью) достиг такой стадии, когда его вряд ли целесообразно сливать с чьим-то ещё. Импорт из «Домашней бухгалтерии» уже работает. :) Если ТС будет параллельно пилить свой проект – ничего страшного, это ведь хорошо, когда у людей есть выбор. Если потестирует мой – я буду рад, но это точно не прямо сейчас.

Гитхаб

А GnuCash, как и большинство других подобных программ вроде KMyMoney, на мой взгляд, скорее для небольшого ИП или самозанятого, чем для личных финансов.

То есть допустим трачу рубли на еду – записываю в Расходы:Еда:RUB, трачу грузинские лари – в Расходы:Еда:GEL

Тратишь наличными? Тогда наверно ничего сложного завести счет(в программе для бухгалтерии, я имею в виду). У тебя же не так много валют?

Если картой, то надо в валюте карты/счета в любом случае, иначе, как выше написали, проблемы с конвертацией.

я сам не до конца понимаю как оно должно работать (в плане архитектуры).

Это главное. Сначала придумывается концепция как оно должно работать а потом можно приступать к реализации.

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

Я в бухгалтерии не силен. Считаю свои деньги в экселе. А если надо статистику - то смотрю в банковском приложении.

Могу с помощью ИИ после реализации своих хотелок включиться в ваш проект после полного понимания концепции. Мне все равно что делать. Лишь бы мое имя было в титрах ).

Еще. Заведите todo. Список того что надо сделать. Это лучше чем все держать в голове.

Ты имеешь в виду если не писать с нуля свой велосипед, а пытаться допилить gnucash под мои нужны? Ну в принципе как вариант конечно можно рассмотреть, хотя мне кажется что это уже костыли будут.

Только не понял, почему не получится? В принципе, технических препятствий для этого не вижу.

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

Кажется ты не так понял. Разные подсчета в одной валюте не нужны. Есть «брокерский счет», и на нем (либо непосредственно, либо на отдельных счетах) будут разные акции/валюты/прочие инструменты:

• 1000 рублей
• 3 акции сбербанка
• 5 акций сбербанка привилегированных
• 10 ОФЗ выпуска XXX

то есть каждая ценная бумага – как отдельная валюта (и на нее отдельный подсчет при необходимости). На первой фазе программа ничего не знает про курс акций сбера к рублям и баланс так и будет отображаться: 1000 RUB + 3 SBER + 4 SBERP + … Если надо все сконвертировать в рубли – это уже вторая фаза – с курсами/ценами и отчетами

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

• Есть ли какой-то механизм убедиться, что ничего не потерялось? Просто сверяться с банковскими выписками? А если траты шли через наличку?
• Допустим я что-то покупаю не для себя, а для кого-то другого, и мне потом эти деньги должны вернуть. А еще тот человек может что-то купить для меня и зачесть эту сумму. У меня в таком случае создается счет для этого человека на котором учитывается сколько он мне/я ему должен. А без двойного учета это возможно?

Ну как оно должно работать с точки зрения пользователя мне плюс-минус понятно. Сложности именно с архитектурой: какие сделать слои, классы, как они будут друг с другом взаимодействовать и вот это все. Единственное, что пока сомневаюсь все таки на тему того, должно ли это быть десктопное приложение или веб.

Целевая аудитория – я. Ну и те, у кого схожие со мной взгляды на бухгалтерию и/или много валют. Возможно получится оттяпать какую-то часть аудитории gnucash и подобных программ. Вполне возможно, что программу можно будет применять не только для личных финансов, но и для малого бизнеса, но я понятия не имею какие там есть специфические требования, поэтому не могу заранее сказать насколько она подойдет.

Основные киллер-фичи на первом этапе – мультивалютность в таком виде которого больше ни у кого нет и более удобный ввод разделенных транзакций.

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

Я вообще тоже не бухгалтер, но годы работы в gnucash дают понимание того как оно должно работать.

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

А список того что нужно сделать есть, уже на 10 страниц.

Да и плюс, двойную запись же проще должно быть реализовать, разве нет? Одно дело, когда надо в программе отдельно прорабатывать доходы, расходы, счета (активы), кредиты, долги и т.д., а другое дело когда просто создать сущность «счет», сделать иерархическую структуру и возможность переводить деньги с одного счета на другой, а дальше пользователь уже сам решит, какие счета ему нужны и с какой целью он будет их использовать.

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

Если тратить картой – можно расходы тоже записывать в валюте карты, но можно и сделать конвертацию – я этот момент бы оставил на усмотрение пользователя.

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

Кстати, а в GnuCash есть какой-то механизм отделения «своих» счетов от «чужих»? В частности, в суммарные доходы и суммарные расходы, когда делаешь отчёт, очевидно, надо помещать только свои счета.

По первому пункту я опять-таки не вижу разницу между двойным учётом и моделью Д-Р-П, если деньги шли через наличку. Записывать отдельно, сколько ушло с налички, а потом сопоставлять с чеками?

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

В GnuСash у счетов есть такое поле как тип:

• Asset
• Liability
• Income
• Expense
• Trading
• Bank
• Cash
• Credit card

и еще несколько. И вот в отчете по доходам/расходам он берет именно те счета, которые Income/Expense.

Но мне такая модель не особо нравится, потому что:

1. один и тот же счет может быть то активом то обязательством. Или доходом/расходом совмещёно.
2. не очень понятно, на что конкретно будет влиять, обозначишь ты счет как актив или наличные например. В чем между ними техническая разница?

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

По первому пункту я опять-таки не вижу разницу между двойным учётом и моделью Д-Р-П, если деньги шли через наличку. Записывать отдельно, сколько ушло с налички, а потом сопоставлять с чеками?

А если чек не дали а записать забыл? Понятно что двойная запись не гарантирует что все вспомнишь, но по крайней мере, так ты увидишь, что должно быть столько-то а по факту в кошельке лежит другая сумма, увидишь сумму расхождения и будешь думать, куда потратил/откуда взял.

А еще, можно поподробнее про «перенос», что это такое?

И все же, не проще ли использовать двойную запись?

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

Ну так периодические проверки можно делать. Сколько должно получиться по программе и сколько на самом деле.

А еще, можно поподробнее про «перенос», что это такое?

Перенос. :) между своими счетами, между наличкой и разными картами, например.

И все же, не проще ли использовать двойную запись?

С моей точки зрения – не проще. Программы на основе двойной записи это такой «конструктор». Да, он универсальный, с его помощью можно описать всё, что угодно, но вот большинство повседневных записей будут слишком громоздкими, на мой взгляд.

Я-то как раз для себя писал программу для домашней бухгалтерии.

3 новых странах с 3 разными валютами, потратил там денег наличкой на разные категории расходов и потом задолбался создавать новые счета.

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

Пожалуй следует добавить, что система проверок, которую я планирую, чем-то близка к двойной записи. Но это не двойная запись в классическом понимании, где обязательно требуется счёт с приходом, счёт с расходом, и всё делается через Add Transaction.

Идея с мультивалютностью заключается в том, чтобы отвязать счета от валют: то есть валюта будет указываться в каждом сплите (части транзакции, изменяющей сумму на одном счете). Таким образом на каждом счете смогут одновременно существовать несколько балансов в разных валютах. Это удобно тем, что когда у пользователя много используемых валют, ему не придется дублировать все свои счета под все валюты. Сделал один счет «наличные», и туда можно записывать и рубли, и доллары, и евро и все что угодно. Или другой пример: сделать один счет «брокерский», и на него записать «акции XXXX», «акции YYYY» и т.д. (каждый вид ценных бумаг как отдельная валюта)

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

Assets:Cash  100 EUR @@ 10200 RUB      <- счет откуда (сумма)
Assets:Cash                            <- счет куда (тут можно указать явно сумму, но не обязательно)

или

Assets:Broker 1  100 AAPL @ 21394.83 RUB    <- тут используется курс  
Assets:Bank Card                            <- сюда упадут сконверченные рубли

Что еще прикольно, что он запоминает у себя внутри курс и потом использует, если тебе например хочется посмотреть все счета в рублях

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

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

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

Считаю писать надо на Java. Это и Android, и Web и Desktop.