Перейти к содержимому





- - - - -

Домашний бюджет. Учет. И валюта?

Опубликовал: Иксилимьюз, 18 Апрель 2012 · 1 780 Просмотров

Доброго всем времени суток, и огромный привет! :)

Уже месяца два как по вечерам, ночам, выходным, на маленьком нетбуке, и в любое свободное время когда оно есть, и есть вдохновение, занимаюсь своим давним проектом. Раньше он назывался Блокнотик и DataBook. С появлением 5й версии, это будет Деловик :)

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

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

Теперь ещё ближе к делу :) Все что было сделано давно, я переработал. Доработал, и привел в рабочее состояние. Сейчас тружусь над тем чего в программе ещё не было но давно мечтал это реализовать. Это простейший домашний бухгалтерский учет. Но не такой, который начинает корректно работать после суток изучения мануалов и настройки кучи всяких непонятных штук. А так что бы сразу. Запустил,и все работает и все интуитивно понятно. Такова моя цель. И я надеюсь что это у меня получается.

Уже есть кое какие вещи. Но общая схема пока прорисована не детально. И вот по ходу пьесы у меня возникает вопрос.. Валюта. Да это хорошо и это надо. Но как и где ?
Тут же возникает в голове следующая концепция. Для начала попрошу выслушать детали того что имеется.

Имеется у нас набор счетов. Это такое абстрактное понятие. Но довольно простое. Например, основной счет. Это те деньги которые мы носим при себе, в кармане, сумке, не важно. И тратим на проезд, еду, телефон. Есть ещё к примеру счет "Копилка". Туда мы складываем деньги что бы потом купить себе вертолет. И есть счет к примеру "Базовые платежи". Это к примеру оплата за телефон, газ, воду, электричество, интернет.

Далее у нас есть такие справочники как ед. измерений, товары и услуги, компании.
В этих справочниках у нас ложится информация о магазинах и фирмах где мы оставляем свои деньги в обмен на товар. Который тоже хранится в справочниках. А ещё в нем хранятся цены на этот самый товар. Причем цены имеют историю. Можно будет через 5 лет глянуть сколько в 2012м стоила буханка хлеба :)

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

Каким образом в эту схему должен вписываться валютный учет?

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

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

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

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

П.С. Как только доделаю модуль учета бюджета, возьмусь за написание подробного пользовательского мануала с картинками. А потом с большим удовольствием подарю свое творение всем желающим :) И по ходу использования буду с радостью принимать критику, замечания и пожелания, и реализовывать это в очередных обновлениях программы :)

  • 3



было бы приятно заполучить и протестить эту прогу
    • 2
А я воще них...уя ничего не понял. Хотя через 2-3 строчки почти фсё до конца прочитал. :D

А я воще них...уя ничего не понял. Хотя через 2-3 строчки почти фсё до конца прочитал. :D


В таком случае могу предложить лишь прочесть ещё два раза, начиная со второй, а затем с третьей строки :D Шутка))
В общем ладно)) Буду делать так как написал, если возражений не появится ))) А потом увидите саму программу с хелпом, и будете выказывать пожелания :)
    • 1
что-то мне подсказывает, что вся база должна быть в одной валюте, по крайней мере физическое хранение

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

кривовато, но я думаю можно додумать

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

ну как-то так
    • 1

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


О!!! Отличная мысль! =) Большое спасибо за мысли, topcraze, обмозгую и буду отталкиваться от вашего варианта. Динамический пересчет, без физического хранения в разных валютах ) В базе все будет в базовой валюте храниться )
    • 1

база должна быть в одной валюте, по крайней мере физическое хранение

пересчёт в базовую кастомную валюту учёта стопроцент должен быть

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

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

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

для таблицы счета прикрутить доп поле - currency) кривовато, но я думаю можно додуматьну или вот в

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

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

но и планирует вперёд, т.е., например что будет если курс доллара к концу 2012 года упадёт а евро подскочет и т.д.

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

а вот автозаполнение с сети - классная идея

курсы валют прошедшие при желании тоже можно в таблице хранить, но имхо это приведет к избыточности и излишнему усложнению кода
    • 1
Спасибо и Нежильцу, за интересные предложения.

Сейчас справочник валют представляет из себя таблицу валют. Список.
У каждой валюты есть своя история. То есть зайдя в валюты мы можем добавить курс этой валюты за любое число. И соответственно при расчетах дату курса можно использовать.

Интересная мысль по поводу счетов и статей.

Как на счет такого варианта? Излагаю с точки зрения упрощения.

Оставляем счета. Думаю что скорее всего даже привязке к валюте не будет. Просто добавлю опцию "просмотр в валюте", где можно будет выбрать валюту. И динамически произвести расчет. Это такой момент.

Речь зашла о счетах, на сколько я понял, под этим имеется ввиду вид растраты? Почему бы не обозвать эту штуку "Категорией"? В итоге, имеются счета.
В данный момент операции - это документы. То есть создаю я документ расхода, выбираю к какому счету его привязать, то есть по какому счету пройдет операция. Далее, можно добавить справочник категорий для документов расхода. Это как раз может быть открытый спраочник. И если человек имеет кошку, он заведет себе категорию "Затраты на кошку", и каждый раз покупая вискас, будет в документе указывать категорию "Затраты на кошку". Затем при выводе отчетов, можно будет выбрать все операции связанные с кошкой и увидеть сколько в месяц он на неё потратил.

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

Теперь снова к валютам. В теории можно конечно тянуть курсы валют с Нац Банка. Но на сколько действительно нужно. Не то что бы не хочу этого делать, но пытаюсь понять важность. Как часто люди пользуются валютами? Лично я покупал иностранную валюту за 10 лет всего один раз когда ехал в гости к брату в Россию. А так в обиходе всегда и везде использую тнг. А если у меня появилась необходимость посчитать в другой валюте что-то я зайду и гляну курс, произведу подсчет и дальше буду все считать в тнг. Как-то так.

Это все пока мысли.. Обдумываю как лучше :) Большое спасибо за идеи, мысли :)
    • 1
Вот таким образом выглядит справочник валют.

Справочник валют 2

Справочник валют 1
    • 1

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


опять же можно создать категорию документов "Планируемая трата". Создать такие документы, и посмотреть что станет с балансом к концу месяца с учетом этих трат. Потом их можно будет легко и безболезненно удалить за ненадобностью. Посмотрели и хватит. Либо сделать ещё круче.
Завести системную категорию документа "планируемый". И затем в отображении баланса, ставить галочку "учитывать планируемые траты" и смотреть результат. затем галочку убирать и видеть баланс без учета планируемых документов.
    • 0
планируемые траты весьма удобны будут, да
только вот, XIO, не слишком ли запутано для реализации получается?
    • 0

планируемые траты весьма удобны будут, датолько вот, XIO, не слишком ли запутано для реализации получается?

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

думаю все таки сделать сегодня справочник категорий для документов. как доп. фильтр для отчетов потом.. И планируемые документы. Валюты все же буду считать динамически по запросу пользователя. А хранить все в базовой. Постараюсь это как-то максимально упростить для понимания, но и что бы оно все было :) А дальше может буду докручивать потихоньку какие-то новые фичи. По мере поступления предложений )))
    • 0

Речь зашла о счетах, на сколько я понял, под этим имеется ввиду вид растраты? Почему бы не обозвать эту штуку "Категорией"? В итоге, имеются счета. В данный момент операции - это документы. То есть создаю я документ расхода, выбираю к какому счету его привязать, то есть по какому счету пройдет операция. Далее, можно добавить справочник категорий для документов расхода. Это как раз может быть открытый спраочник. И если человек имеет кошку, он заведет себе категорию "Затраты на кошку", и каждый раз покупая вискас, будет в документе указывать категорию "Затраты на кошку". Затем при выводе отчетов, можно будет выбрать все операции связанные с кошкой и увидеть сколько в месяц он на неё потратил. Таким же образом можно и категоризовать приходные документы. Например "Основной заработок" и "потаксовал", "посидел с ребенком", "почистил компьютер соседу".



статья - это тот самый параметр по которому группируется транзакция, т.е. та же самая статья "Затраты на кошку" которая отрицательная, не мешает завести статью из этого же справочника "получение основного заработка" которая будет положительной
отличие будет только в том что в статье "затраты на кошку" будет проставлена птица "расходы" или иной простейший реквизит булево, при этом если признак "расходы"=истина то транзакция умножается на "-1", а при непроставленной птице не умножаются на "-1"
то что транзакция будет осуществлятся вводом документа - согласен, а как же иначе,
другое дело что категории документов, если использовать умножение на "-1" можно использовать иначе чем предлагаешь ты - их можно использовать для отделения транзакций плана от транзакций факта, что позволит формировать план-фактные отчёты
один единственный документ "оборот" в котором выбирается статья (которая уже со знаком "-" или "+") закрывает простейшие потребности для ввода как факта так и плана.

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

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

IIIIIIстатья IIIIIIсчёт плюс IIIIIIсчёт минус
IIIIIIполуч.осн.зараб. IIIIIIналик IIIIII х
IIIIII расходы на кошку IIIIII х IIIIII налик

то когда ты будешь получать зарплату, ты открываешь документ "оборот", выбираешь статью "получение основного заработка", проставляешь у документа категорию "фактические данные" и нажимаешь "выполнить транзакцию" и тогда автоматом двигается налик в сторону увеличения, когда делаешь оборот по вискасу то налик уменшается.
при этом ты делаешь движение конечно не по вискасу а по расходам на кошку, но чтобы у жадных и мелочных людей имелась возможность сопоставлять цены на вискас и педигрипал в документе "операция" можно добавить реквизит который будет ссылаться на справочник где будут
вискас
педигрипал
потаксовал на АИ 92
потаксовал на АИ 79
и т.д.

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

У меня сейчас по сути набор разных таблиц. То есть таблица шапочной части документа и таблица табличной частидокумента. При этом приход это одни талицы, расход другие, а ещё планирую создать таблицы такие как расход за газ, расход за свет, расход на ГСМ. Объясню почему.
В каждом из документов, есть свои специфические поля. В приходе у нас есть только сумма, и источник дохода, к примеру. У расхода у нас есть товар, магазин, количество. и авторасчитываемая сумма.
В расходе на ГСМ, у нас будет поле для хранение показателя одометра, количество залитого топлива, и подсчет расхода топлива, и напоминалка о том что скоро надо будет менять масло. К примеру. Из-за спицифика каждых операций я решил разнести это в разные таблички, что бы не было избыточной информации в одной таблице. Так о чем это я? Так, да.
Физически все операции в базе будут храниться со знаком плюс. Далее будет строиться составной запрос с помощью UNION. И таблицы относящиеся к приходу будут с плюсом, а таблицы к расходу, будут считаться как минус, и таким способом будет высчитываться баланс. То есть именно так все задумывал я изначально. Но ваш вариант конечно тоже меня кое чем заинтересовал. Спасибо большое за схему. Буду думать. Лучше хорошо подумать в самом начале чем 100 раз переделывать )) В общем посмотрим :)

п.с. Что-то мне подсказывает что вы определенно имеете дело с 1С :)
    • 1
Я бы с удовольствие вела домашний бюджет в такой проге, если что потом скидывайте, протестим!!!
    • 1
Спасибо, m@ri, скину :) Обязательно. )) В данный момент уже пишу пользовательский мануал, и по ходу его написания подправляю мелкие ошибочки и недочеты) Так что думаю что уже очень скоро смогу поделиться первой версией )) Потом по ходу дела буду её доделывать, добавлять полезные фичи и т.п. :)
    • 0

Поиск по блогу

Декабрь 2016

П В С Ч П С В
   1234
5 67891011
12131415161718
19202122232425
262728293031 

пользователей просматривает

0 пользователей, 0 неизвестных прохожих, 0 скрытых пользователей


Yahoo (1)

X

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

© 2011-2016 vse.kz. При любом использовании материалов Форума ссылка на vse.kz обязательна.