carnationможет кто делал что-то подобное - поделитесь пожалуйста опытом...

AbilityCash вам определенно поможет

carnationсуществующую базу дописать нужно

carnationединственная?

нет конечно я не предполагал и не предлагал таких подходов

Simonпотом посмотреть в интернете что такое бюджет

ой, да перестаньте Вы, ради Бога будьте проще и люди к Вам потянутся :)


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

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

даты событиям назначаются один-к-одному, т.е. все эти регулярные повторяющиеся и проч Recurrencies отмечены не как интервалы или периоды, а как единичные записи...

договор аренды на пять лет и оплата поквартально? значит в таблице заранее генерируются 20 записей об оплатах аренды по этому договору, Помесячно? Значит генерируются 60 записей... даговор на год и оплата помесячно? соответственно 12 записей


а форма выбора периодов и повторений только для того, чтобы сгененрировать эти 20 записей и расставить в них даты из таблицы_календаря

Simonэто не планирование расходов - это планирование движения

честно говоря, я не совсем понял - из чего вы сделали такой вывод...

мне показалось, что как раз и идет речь о планировании расходов...


ЗЫ

перечитал вопрос... нет, мне не показалось

ЗЫЫ

я знаю чем отличается БДР от БДДС

carnationспособ, предложенный Visitor

Я, вероятно. просто не довел идею :) често говоря ничего сложного

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

каждый понедельник на 10 лет вперед значит, что это будет 520 записей о событии происходящем в понедельник. Если для порождающего события ЖЦ короче - 5 лет, например, то это будет, соответственно, 260 записей.

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

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

стремительно растущий объем данных отчасти компенсируется остутствием стремительно растущего объема вычислений и оправдывается, например, возможностью интеграции с другими приложениями. например заставить Аутлук высчитывать наступление ваших событий по тем периодам, что вы указали в БД, довольно хлопотно. Я такие события просто генерирую в календарь Аутлука они сразу все есть.

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

--------

при этом вы вносите данные в БД (алгоритм работы пользователя с интерфейсом) точно так, как делаете отметки в календаре

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

точно так-же упрощается и выдача/настройка уведомлений о наступлении события, поскольку все события уже внесены в БД как записи, вы можете просто написать запрос к таблице - " показать все события в ближайшие последующие пять дней"

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

ну... в общем... вольному-воля, спасенному-рай, каждый волен сам выбирать-придумывать...

carnationа вот если генерировать эти записи по мере необходимости

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

в общем - откройте аутлук, экспортируйте все задачи (если они у вас есть) в Access например или в Excel и посмотрите как эту задачу решает майкрософт

vizierи усе.

нет не усе...

vizier Visitor vizierи усе.

нет не усе...
Шикарный аргумент :)

удачных выходных :)