создать новую тему раскрыть все
 
Считаю, что в программу необходимо добавить сущность «лимит».
Лимит – это индикатор дохода/расхода устанавливаемый на период времени и на счет/реквизит в валюте учета.
Лимит можно устанавливать на:
1. Счет;
2. Классификатор введенный в программе (Статья, агент, проект и т.д.).
Одновременно, один лимит может устанавливаться только на счет, только на статью, только на агента и т.д. Одновременно на один счет, статью и т.д. может существовать несколько лимитов.
 
Для ведения классификатора необходимо создание дополнительного экрана (закладки/страницы).
Экран представляется в табличной форме (по типу закладки «Операции»). Таблица «Лимиты» содержит следующие столбцы:
1. Статус лимита (активирован/деактивирован);
2. Дата начала действия лимита (в формате dd.mm.yyyy, возможно нужно будет и указание времени, но не готов сказать, лучше вернуться к этому вопросу после реализации первой версии «Лимитов»);
3. Дата окончания действия лимита (в формате dd.mm.yyyy);
4. Вид лимита – следующий текст «счет», «статья», «агент», «проект» и т.д. по названиям классификатора;
5. Значение вида лимита – конкретное «название счета», «название статьи», «название агента»;
6. Валюта лимита – обозначение валюты из справочника валюты (USD, RUR, EUR);
7. Лимит (плановое значение) – сумма в валюте лимита (в формате Х ХХХ.ХХ), может принимать положительное, отрицательное и нулевое значения (при нулевом значении, лимит используется для подсчета затрат по счету/классификатору, без сравнения с планом);
8. Фактическое исполнение (рассчитано на основании операций из базы) – сумма в валюте лимита (в формате Х ХХХ.ХХ);
9. Процент выполнения – отношение «Значения фактического исполнения» к «Лимиту» выраженное в процентах в формате ХХ.ХХ% (при нулевом значении процент выполнение не считается).
 
Таблица «Лимиты» должна позволять отфильтровать лимиты за период (дата начала, дата окончания). В случае если одна из частей лимита попадает в интервал, то лимит должен отображаться в таблице. При старте программы значения даты конца и даты начала инициализируются в текущее значение времени.
 
В диалоге ввода лимита должны присутствовать поля, содержащиеся в таблице «Лимиты» (кроме фактического исполнения и процента выполнения).
 
Типы лимитов - доходный или расходный.
Одновременно лимит может быть только доходным или только расходным. Может устанавливаться по знаку при значении лимита - «+» - доходный лимит, «-» - расходный.
 
Состояние лимита – актированный, деактивированный.
Одновременно лимит может быть только активированным или только деактивированным. Активированный лимит – это тот лимит, по которому происходит сбор информации. В случае если лимит переводит в деактивированное значение, то фактическое значение лимита «сбрасывается». В случае активации лимита, он обновляет фактическое значение лимита (проводит пересчет по операциям из базы).
 
Логика работы ввода лимита должна содержать следующий момент, после создания/редактирования лимита (нажатия кнопки «Ok»), программа должна подсчитать фактическое исполнение (по введенным операциям) и вычислить процент выполнения.
 
Учитывая то, что изменения в фактическое исполнение лимита вносятся при вводе/редактировании операций, то логика обработки операции (после нажатия кнопки «Ok») должна содержать следующую логику:
 
Программа перебирает все активированные лимиты, если лимит содержит один из реквизитов текущей операции (счет, статья, агент, проект, и т.д. введенным классификаторам) или лимит содержит родительское значение одного из реквизитов текущей операции, то программа сравнивает валюту лимита, если она совпадает с валютой операции, то программа уменьшает/увеличивает фактическое исполнение по лимиту.
 
В случае, если валюта операции и валюта лимита не совпадает, то программа проводит конвертацию по курсам валют и уменьшает/увеличивает фактическое исполнение по лимиту.
 
После отражения фактического исполнения лимита, программа сравнивает его с плановым значением, в случае если происходит превышение установленного лимита, то программа «выставляет флаг».
 
После обработки текущего лимита, программа продолжает обработку всех оставшихся активированных, но пока не обработанных лимитов.
 
После обработки всех активированных лимитов программа проводит проверку «выставленного флага», если он «поднят», то программа уведомляет пользователя о том, что «Один или более лимитов превышены». Уведомление может выдаваться в статусной строке (допустим красным цветом) или информационным сообщением (MessageBox), вариант со статусной строкой предпочтительнее.
 
При переходе на закладку «Лимиты», превышающие лимиты выделяются (например, помечаются цветом).
 
При запуске ввода/ редактирования операции значение «выставленного флага» устанавливается в значение «опущен».
 
Пример работы с лимитами:
Имеется следующий план счетов:
«Все статьи расхода»
     «Продукты»
          «Молочные»
               «Молоко»
               «Кефир»
 
Существуют следующие лимиты:
10.03.2005г. – 20.03.2005г., статья, «Продукты», RUR,  -100, 0
15.03.2005г. – 25.03.2005г., статья, «Продукты», RUR,  -150, 0
12.03.2005г. – 30.03.2005г., статья, «Кефир», RUR,  -20, 0
В приведенной таблице видно, что фактическое исполнение у всех лимитов равняется нулю
 
При проведении расходной операции 14.03.2005г. по статье «Кефир» на сумму 30 RUR таблица лимитов примет следующий вид:
10.03.2005г. – 20.03.2005г., статья, «Продукты», RUR,  -100, -30
15.03.2005г. – 25.03.2005г., статья, «Продукты», RUR,  -150, 0
12.03.2005г. – 30.03.2005г., статья, «Кефир», RUR,  -20, -30
Последняя строка будет выделена (например, цветом) из-за превышения лимита.
 
Для удобства ввода/редактирования лимитов должны быть реализованы следующие возможности:
1. Групповое изменение реквизитов лимита (дата начала, дата конца, валюта и т.п.);
2. Групповое дублирование введенных лимитов.
3. Выгрузка/загрузка в Excel введенных лимитов.
 
Для анализа фактических значений лимитов, должен быть реализован следующий механизм: при двойном клике по лимиту, программа переходит на закладку операций и устанавливает значения фильтров в значения лимита (даты, значение счета или значение классификатора). В этой теме предлагаю не обсуждать реализацию перехода на закладку операций, она должна быть подобной переходу по двойному клику со страницы счетов.
 
Настройки программы должны позволять скрыть закладку «Лимиты», для тех пользователей кто не готов начать планироваться.
 
После реализации описанного способа ведения лимитов можно будет говорить о первом этапе реализации бюджетирования в программе.
 
Вроде бы основные моменты все изложил, если будут вопросы по тексту, то готов дать комментарии.
 
В диалоге создания лимита должна присутствовать опция "Учитывать переводы".
 
И соответственно после ввода операции перевода, алгоритм проверки лимитов должен, кроме реквизитов лимита, анализировать наличие установленной опции.
 
Подверг пересмотру предложенный мной формат экрана "Лимиты" и диалога ввода/редактирования лимита и пришел к выводу о том, что существует более оптимальный способ реализации.
 
Поля "Вид лимита" и "Значение вида лимита" нужно поменять на блок полей "Реквизиты" как в диалоге ввода/редактирования операции, чтобы можно было выбирать не один классификатор, а все одновременно.
 
К полям "Статус лимита", "Дата начала действия лимита", "Дата окончания действия лимита", "Валюта лимита", "Лимит (плановое значение)" необходимо будет добавить поле "Комментарий" и возможно выпадающий список для определения типа лимита (доходный/расходный).
 
При реализации блока "Реквизиты" в диалоге ввода лимитов (и последующей обработке в экране "Лимиты"), будет возможно не только отслеживать расходы по статье по все агентам, но и по конкретному агенту.
 
Описанная функциональность необходима для реализации контроля исполнения бюджета.
 
В целом процесс ведения финансов вижу следующим образом:
1. Планирование доходов - приход средств на счета;
2. Планирование текущих* и целевых* расходов.
3. На основании сравнения доходов и введенных расходов, определение доступного остатка средств.
4. Планирование инвестиционных* расходов (на основании доступного остатка средств).
5. Формирование лимитов на основе доходов, текущих, целевых, инвестиционных расходов.
6. Ввод лимитов в Cash
7. Отслеживание исполнения бюджетов на основе установленных лимитов.
8. Анализ исполнения установленных лимитов.
 
Самое сложное во всей этой схеме - это отслеживание установленных лимитов, т.к. нужно постоянно сверяться с бюджетом. Реализацию этой задачи может взять на себя Cash.
 
На первом этапе реализацию действий с 1 по 5 вижу в Excel.
 

* Под текущими, целевыми и инвестиционными расходами я подразумеваю следующее:
Текущие расходы – это те расходы, от которых сложно или проблематично отказаться, типичный пример это «Продукты», «Коммунальные расходы».
Целевые расходы - это те расходы, от приобретения которых может быть обложено на некоторое время, типичный пример это «Одежда», «Обувь».
Инвестиционные расходы - это те расходы, от приобретения которых можно отказаться, типичный пример это «Акции», «Облигации», «Драгоценные металлы».
 
Если это реализовать, то АС станет очень полезным (незаменимым) инструментом в работе валютного дилера, брокера, инвестора и т.д, и т.д. Это мое частное мнение.
свернуть/развернуть ветвь Честно говоря,... [Denis ® 26/01/2005 10:23] # написать ответ
 
... не думал, что механизм лимитов может понадобиться описанным вами категориям, т.к. задумывал, прежде всего, для ведения личных финансов, но если он им тоже пригодится, то тоже неплохо.
 
...мне хотелось бы сказать "Спасибо" за столь детальное изложение вашего видения бюджета. Я представляю, сколько времени заняло даже написание этого текста, уважаю ваш труд и снимаю шляпу (в знак уважения).
 
Копию этого текста я получил на e-mail, но раз он вынесен на публичное обсуждение, то и отвечать буду тоже здесь, в форуме сайта.
 
Итак, бюджет. Что есть бюджет? Имхо, бюджет есть финансовый план по доходам/расходам/накоплениям/инвестициям на некоторый период времени. Мало того, в реальной работе, как я понимаю, планов может быть несколько. Скажем, сейчас я веду свой бюджет (пока) в Excel-e и у меня есть несколько бюджетов: по одному на каждый месяц года и объединяются они в один, единый бюджет на год. Мне кажется, что так немного удобнее, нежели чем задавать период времени для каждого лимита, ведь всё у нас происходит с заранее заданной периодичностью. Возможно, это будет не месяц и не год, но всё равно, периоды, имхо, априори известны.
 
Кроме того, в вашем изложении я не заметил такого, на мой взгляд, важного понятия как "источник финансирования". Ведь бывают планы расходов, которые зависят от того, будут ли получены доходы или нет. Например: "я планирую поездку на курорт, если вот эта сделка принесёт мне минимум $1000".
 
А в остальном, собственно, возражений особых нет.
свернуть/развернуть ветвь признаюсь... [Explore® 26/01/2005 11:06] # написать ответ
 
меня в равной степени поразила и детальность изложения точки зрения некоторая ее неоднозначность...
 
специально дождался ответа Сергея и поддержу его в полной мере...
 
в своих выкладках Denis несколько перемешивает понятия называя "лимит" и сущностью и индикатором одновременно...
 
ИМХО сущностью (объектом учета) можно назвать именно бюджет а не лимит... лимит именно индикатор<измеряемое свойство> (например бюджета)
 
что касается введения бюджетов - на этом форуме и в рамках этой дискусии обсуждения по этому вопросу уже велись неоднократно...
 
предложил бы рассмотривать изложенные Denis`ом концепции применительно к бюджетам
свернуть/развернуть ветвь О сущностях и бюджетах [Denis ® 27/01/2005 17:34] # написать ответ
 
Называя "лимит", как сущность, я подразумевал объект базы данных (entity), а не объект учета.
 
В понятие "лимит" я закладывал понятие  измеряемого свойства, индикатора.
 
Думаю ответ на вопрос о связи лимитов и бюджетов можно найти в моем сообщении "Описание составления бюджета"
свернуть/развернуть ветвь Текст вынес... [Denis ® 26/01/2005 12:07] # написать ответ
 
... для публичного обсуждения, ожидая, что к нему подключатся Explorer, Ed, Женя, Бенджамин и другие, чтобы обсудить все "тонкие" моменты, до реализации указанной функциональности в программе.
 
немного путанно изложено и не совсем корректно с точки зрения методик учета...
 
27.01.05 01:14:22 О бюджете и источниках финансирования (1/2)
 
совершенно соглашусь с Сергеем, счета никак не могут рассматриваться как источники финансирования, ни с какой точки зрения...
 
предположим, что в контексте беседы под источниками финансирования мы подразумеваем определенные источники поступления денежных средств,
поскольку любые "поступления" в терминах программы могут быть описаны только в фиксированом денежном выражении
(.....тут была длинная ремарка по ссудам кредитам процентным ставкам акциям облигациям и проч. - вымарал нафиК.....)
далее "источники поступлений"
 
1) источники поступлений могут быть:
 
внутренние, внешние
гарантированные, не гарантированные
краткосрочные, долгострочные
 
(еще одна длинная ремарка про <блин тоже вымарано - > и проч. вымарана нафиК...)
 
короче счета источником финансирования никак не являются и не могут являться...
исходя из этого отвергаю все последующие выводы и предположения, как построеные на неверных посылках...
приношу извинения но оставлю без комментария - иначе зафлудим весь топиГ.
 
27.01.2005 г. 01:16:03 О бюджете и источниках финансирования (2/2)
 
К определению Denis`а:
Под бюджетом понимаю, роспись денежных доходов и расходов на определенный период.
добавлю планируемых
 
2) имеем в виду, что бюджеты могут быть разными (по назначению, по способам формирования и по (вымарано нафиК)...
 
3) короче под бюджетированием подразумеваем планирование <в некоей регламенированой форме и в рамках некоторых регламентированных процедур> различных доходов, поступлений...n и расходов, убытков, ущербов...n на некотором временном отрезке...
 
4) под бюджетом понимаем результат бюджетирования
 
в целом с тезой топика согласен, за исключением...
 
в текущей версии реализация бюджетирования может быть и возможна но мы не можем получить результат под названием бюджет и использовать его... тогда какой смысл?
 
"насчет цикличности" вопрос очень интересный, но автоматически создавать бюджет мне кажется мало реальным. Вообще есть такое понятие, как автоматический бюджет, но он не предполагает серьезного анализа... по сути просто используется бюджет предыдущего бюджетного периода.
 
REM> если в программе будет реализован (хм...) планировщик, то что-то в таком духе можно сделать - создав периодические операции, или назначив базовой операции дохода/расхода периодичность (классно было-бы если она - периодичность - могла быть нелинейной) но пока еще не реализована функциональность повторяющихся операций говорить об этом рано...
 
в принципе, работа с периодическими операциями может как раз и создать базу для имплементации в программу функций бюджетирования...
 
27.01.2005 г. 02:25:15 Описание составления бюджета (1/3)
27.01.2005 г. 10:49:44 О резервах
 
для пояснения моего видения бюджетирования, поясню, что я под ним поразумеваю именно финансовое планирование, как любое планирование оно начинается с оценки и осмысления различных пресупозиций и последующих логических заключений Well))
 
-определение бюджетного периода БДР
REM>(на период меньше года ИМХО нет смысла париться)
-выявление насущных потребностей
-выявление реальных возможностей
-анализ планируемых затрат
-анализ планируемых доходов
REM>(и те и другие по различным категориям <вымарано нафик&gtTo wink
-планирование бюджета доходов/расходов на бюджетный период
-анализ и оптимизация по датам
-поиск доп. источников финансирования
-поиск возможностей для инвестиций
-составление планов счетов и распределение бюджета по статьям
 
далее исполнение бюжета, корректировки, поправки, дополнения и проч...
 
бюджет 2003 у меня сошелся на 5+ ($1`500`000-00 вообще-то)
 
в общем статью оцениваю как излишне запутанную, изобилующую несущественными деталями. Изложенные подходы не вполне методически верными, и несколько непоследовательными...
 
понятия "резерв" как объекта учета для меня не существует - это неэффективные, замороженные деньги. нужно искать источники финансирования на аварийные случаи - взять в долг или в кредит например, сейчас такие инструменты есть...
 
умочал о еще одной особенности ведения бюджета - я всегда придерживаюсь консервативной модели...
свернуть/развернуть ветвь О продолжении разговора [Denis ® 28/01/2005 10:39] # написать ответ
 
Насколько я понял, описанная мной функциональность в реализации не нуждается.
 
Предлагаю закрыть обсуждения.
 
Приношу извинения за отнятое время.
 
в программе для учета любых финансов, в том числе домашних или личных - отличная идея и правильный ход...
 
речь идет о том, чтобы сделать это правильно
свернуть/развернуть ветвь Прения, однако... [Ed 28/01/2005 13:00] # написать ответ
 
Все это очень напоминает мне нашу верховную раду - когда нет желания что-делать, начинается обсуждение методик учета, неправильного понимания терминов и особенностей использования сущностей. Но это так, к слову.
Лимит - еще не сам бюджет, а лишь инструмент контроля. Поэтому мне кажется, что это будет не первый этап бюджетирования, а последний Well Но требования к лимитам (с дополнениями Сергея!) - именно то. Добавлю только, что и самих бюджетов может быть несколько. Стандартный набор - оптимистический, пессимистический ну и то, что посредине (не что плохое Well ). Соответственно и лимиты будут разные.
Что мы хотим от бюджета? Видеть, что по этой статье перебор, а по той – недобор. Ну и что? Может, от этого мы станем богаче? Поэтому нужен результирующий показатель. Это может быть прибыль. Но может и не быть. Нужно дать  возможность расчета любого показателя, который пользователь сочтет нужным использовать. Этим сохраним и гибкость программы.
И конечно же согласен с Сергеем, что сейчас еще не время обсуждать, КАК контролировать и к чему привязывать лимиты, так как не ясно, на основе чего будет формироваться сам бюджет Well
Самый простой вариант сделать бюджет (на любой период) - взять факт прошлого аналогичного периода, подставить новые даты и поставить метку "план". В итоге получаем приходы с расходами, информацию по контрагентам и все остальное. Получаем, естественно, только суммарные итоги по контрагентам, статьям, направлениям. Поэтому, если не будет возражений, предлагаю обсуждение начать с этого и думать, что с этим дальше будет происходить.
А Сергей должен будет сказать нам, когда он сможет приступить к реализации всего того, что мы ему тут насоветуем Well Пока, я так понимаю, он занят немного другим Well А то попусту воздух сотрясать как-то не хочется.
свернуть/развернуть ветвь RE: [Explore® 28/01/2005 17:15] # написать ответ
 
RE: Самый простой вариант сделать бюджет (на любой период) - взять факт прошлого аналогичного периода,
...
в принципе это и есть то, что называется автоматическим бюджетированием или автоматический бюджет или бюджет по результатам предыдущего периода
свернуть/развернуть ветвь 2 Ed [Explore® 28/01/2005 18:07] # написать ответ
 
я не спорю ниочем, мне, вообще то, есть чем заняться и, в отличии от депутатов Рады, я не получаю ни денег, ни иных дивидентов за свои выступления в этом форуме. Well))
 
по-сути я просто откликнулся на приглашение Denis`а к дискусии... поясню, коротенечко свою позицию, в знак личного уважения... Well))
 
если серьезно...
 
дело не в правильности или неправильности понимания терминов, если двое, или более, участников дискуссии употребляют одни и те-же термины одинаково неправильно, но подразумевают один смысл - так и слава Богу, дискуссия состоится и будет плодотворной...
 
мне кажется, и я имею хороший практический опыт, чтобы утверждать это упрямо, что приступая к программной реализации того или иного алгоритма учета <фактов хозяйственной деятельности>, нужно очень точно определять термины как объекты и формализовать отношения программируемых объектов.
 
это залог эффективной разработки программы, как процесса, и залог адекватности результата работы требованиям пользователей программы.
 
конечно можно и не заморачиваться и забить на такие мелочи Well))
 
но это так, к слову... вообще-то мы говорим примерно об одном и том-же. Просто я как старый патефон постоянно долдоню: танцуйте от печки и учите матчасть
 
субуго ИМХО
 
смайл
 
Начну с источников финансирования. Понятие источник финансирования я не вводил, потому что они уже в текущий момент существуют - это счета. Ведь именно с них происходит списание средств при покупках, и именно на них происходит приход денежных средств.
 
Пополнением источников финансирования (счетов) являются доходы.
 
Получается ситуация "я планирую поездку на курорт, если вот эта сделка принесёт мне минимум $1000" в бюджете в терминах программы разбивается следующие действия:
1. Планируем операцию прихода, по определенному счету (с выключенной опцией "Операция выполнена"), на который эти средства ожидаются быть полученными в определенное время.
 
В реквизитах операции можно указать от какой операции (агента, проекта и т.д. в соответствии с введенными классификаторами) мы ожидаем поступление средств .
 
2. Планируем операцию расхода (также, с выключенной опцией "Операция выполнена"), по счету, с которого ожидается оплатить приобретение в определенное время.
 
В реквизитах операции можно указать на какую операцию (агента, проект и т.д. в соответствии с введенными классификаторами) мы ожидаем потратить полученные средства.
 
3. В случае если приходный и расходный счета не совпадают, по создается планируемая операция перевода.
 
Причем по запланированным операциям возможно автоматическое создание лимитов, реализацию этого вижу следующим образом:
1. После создания планируемых операций приходов и расходов, запускается диалог создания лимитов.
2. В диалоге создания лимитов указываются начало и окончание лимитов, выбираются интересующие классификаторы и глубина аналитики по классификаторам.
3. Далее программа проводит анализ введенных планируемых операций и на основе консолидированных сумм по указанным классификаторам формирует лимиты.
 
Под бюджетом понимаю, роспись денежных доходов и расходов на определенный период.
 
Получается, уже в текущей версии реализация бюджета возможна, правда она не так удобна для ввода плановых значений, но ввод бюджета ВОЗМОЖЕН. Одним из ограничений текущей реализации является то, что одновременно на один и тот же период времени возможен только один вариант бюджета.
 
Насчет цикличности - встает вопрос о возможности программы создавать планируемые операции на основе анализа предыдущих операций.
 
Я не думаю, что счета можно считать источником финансирования. Счёт, в нотации AbilityCash не содержит ограничений по суммам, он может принимать и отрицательные значения. Мне казалось, что источник финансирования, это соответствующий неким критериям приход, поступление денежных средств, но никак не счёт.
 
Впрочем, я понимаю, что это терминологический вопрос и его можно было бы не затрагивать, если бы... Если бы не факт, что большинство споров вызвано как раз расхождениями в терминологии.
 
------------------------
 
Второй важный момент, на котором я хотел бы остановиться, имхо, состоит в том, что сейчас нужно обсуждать что должна уметь делать программа. А не как она это должна делать. Возможности программы - да, с удовольствием. Конкретные алгоритмы - нет, считаю, что это рано.
 
Относительно источников финансирования, попытался объяснить свою точку зрения в трех сообщениях расположенных ниже - "Описание составления бюджета"
 
Относительно обсуждения ЧТО, а не КАК, соглашусь. Слишком быстро я перешел от функциональных требований и технического задания к техническому проекту.
 
То, что для меня уже естественно другим может быть непонятно.
 
Для пояснения моего видения бюджетирования, приведу описание того, как я составляю бюджет (в Excel):
1. Первым делом переношу из Cash остатки счетов, т.е. указываю на какой статье, какие суммы присутствуют.
 
2. Планирую приход на период:
2.1. Оцениваю размер поступлений на месяц по всем приходным статьям (зарплата, выплаты процентов по депозитам, отдачу долгов, привлечение заемных средств и т.д.).
2.2. Указываю, на какие счета ожидаю поступление средств.
 
3. На основе общей суммы прихода планирую, показатели рентабельности (бюджетирование сверху), т.е. определяю, сколько могу потратить а, сколько могу пусть в инвестиции (под инвестициями также подразумевается, сколько хочу отложить).
 
4. Планирую текущие и целевые расходы (бюджетирование снизу)
4.1. Определяю, что нужно купить (по максимуму)
4.2. Определяю примерную цену приобретений (определяю лимиты)
4.3. Определяю, источники финансирования – с какого счета будет оплачиваться покупка.
4.4. Суммирую все расходы с группировкой по счетам.
 
5. Проверяю соответствие допустимых расходов и планируемых показателей (общей суммой).
5.1. В случае, если планируемые расходы соответствуют разрешенным показателям, то перехожу к следующему пункту, если не соответствуют, то перехожу к следующему подпункту.
5.2. В случае, если планируемые расходы не соответствуют разрешенным показателям, провожу следующие действия:
5.2.1. Пытаюсь уменьшить планируемые расходы за счет «удаления» (переноса на следующий месяц) целевых расходов.
5.2.2. В случае невозможности удаления целевых расходов (либо их отсутствия), провожу увеличение разрешенных показателей, за счет понижения количества откладываемых средств, планирования взятия денег из «заначки», привлечения заемных средств. Эти действия производятся с корректировкой прихода.
 
После пятого шага у нас есть планируемые приходы, привязанные к счетам и планируемые расходы, обеспеченные необходимыми средствами и также привязанные к счетам (источникам финансирования). Общая сумма расходов, обеспечена общей суммой приходов но, скорее всего по одним счетам ожидается больший приход, чем нужно, а по другим счета ожидается больший расход, чем на нем есть. Для устранения этого дисбаланса нужно  провести «выравнивание».
 
6. Далее рассматриваю каждый счет, смотрю остаток на счете, и какой размер расхода ожидается. Разница между этими значениями говорит о том, сколько средств необходимо на счет внести.
 
7. В случае если приходы превышают запланированные расходы, т.е. получился остаток свободных средств, то в соответствии с инвестиционной стратегией определяю их назначение.
 
8. Далее приступаю к исполнению запланированного, постоянно сверяясь с установленными бюджетом лимитами.
свернуть/развернуть ветвь О резервах [Denis ® 27/01/2005 10:49] # написать ответ
 
Умолчал о еще одной особенности ведения бюджета - о резервах.
 
Дело в том, что хорошо составленный бюджет может разрушить самая малость, например зубная боль. В результате этого придется срочно перераспределять средства, либо уменьшать инвестиционные затраты, чтобы оплатить незапланированный визит к врачу. Чтобы этого не происходило, использую механизм резервирования.
 
Выделяю у себя четыре уровня резервов:
1. Оперативный резерв – составляет порядка 10% от общего объема затрат на месяц. Может быть направлен абсолютно на любые затраты. И он очень быстро доступен (хранится в виде средств на банковской карте).
 
2. Тактический резерв – составляет порядка месячного размера расходов. Может быть направлен только на неотложные нужды (срочный визит к доктору, восстановление вышедших из строя необходимых вещей). Хранится в виде банковского депозита в любом удобном банке.
 
3. Стратегический резерв – составляет порядка 6-8 месячных размеров расходов. Может быть направлен только на форс-мажор (потеря работы, срочная хирургическая операция). Хранится в надежном банке на депозите, доступ к которому разрешен жене (на основе оформленной доверенности).
 
4. Страхование – страхование жизни на сумму от 40 до 100 месячных размеров расходов.
 
Благодаря этому комплексу защиты можно не бояться неожиданностей.
свернуть/развернуть ветвь Дополнение к пункту 4 [Denis ® 27/01/2005 11:00] # написать ответ
 
В течение текущего месяца возникающие потребности (как правило целевые расходы) ввожу в Cash в виде планируемых затрат на следующий месяц.
 
Поэтому, когда приходит время формирования бюджета список необходимых покупок у меня уже есть.
 
Встретил неплохую реализацию бюджетирования в программе "Family 2007 PersonalFinance"
 
Пример создания бюджета можно посмотреть в видео-уроке.
 
Каким мог бы быть в самом простом случае бюджетный модуль?
1. Некоторая бюджетная программа AbilityBudget (или подмодуль AbilityCash) читает из файла AbilityCash структуру статей, позволяет напротив каждой поставить две цифры - для дохода и расхода. Например, статья "зарплата" - доход в 10 000 рублей, расход в 0.
2. Эти данные сохраняются в отдельный файл например, "Stogovs_2008_01.budg" в каталог \bugdet\. В этот же файл пишется также и период, на который действует бюджет (по умолчанию предлагается текущий месяц, но может быть введен любой интервал- меньше месяца, больше года, не обязательно совпадающий с первыми числами месяца)
3. Анализ исполнения бюджета. Программа читает указанный бюджет, определяет период, читает из файла AceMoney все платежи за этот период, агрегирует по статьям, получая две (доходная и расходная) цифры, сравнивает их с бюджетными (показывает отклонения отдельным столбцом, маркирует цветами).
Можно также рассчитывать и показывать остатки на начало периода, на конец периода.
4. Типовая операция с бюджетом - корректировка бюджета. Поскольку мы работаем с файлами на жестком диске, мы можем сделать копию файла "Stogovs_2008_01_final_corrected.budg" и, открыв его в программе, поправить пару циферок.
5. Ещё одна типичная ситуация: создание подбюджета. Данная операция нужна тем, кто планирует весь год, а потом создает 12 бюджетов на каждый месяц. Программа должна уметь взять любой файл бюджета и нарезать его на 12 файлов, распределив равными кусками лимиты. (Возможен также вариант создания редактора, в котором можно будет указать правила разреза для каждой статьи или даже ручками разбить статьи - но его вид нужно хорошо обдумать)
Для тех, кто планирует месяцы, а потом хочет увидеть весь год - программа должна уметь делать обратную операцию - по указанным n последовательным кускам произвести суммирование статей.
6. Можно хранить бюджеты не файлами, а внутри файла данных AceMoney, в каждом из вариантов полно как положительных сторон, так и отрицательных.
7. Деревья статей бюджета в файле бюджета и файле данных могут не совпадать. Обработка этих ситуаций проста, нужно о ней просто не забывать при программировании.
свернуть/развернуть ветвь что-то [куверти 11/01/2008 17:30] # написать ответ
 
намудрено и все программы в кучу свалены не пойми чего...