Добрый день, коллеги.
Заранее спасибо тем, у кого хватит терпения прочитать всё это.

Пишу систему бюджетирования для небольшой компании. Набил шишки на версии 1, предвижу переделку. Решил с вами посоветоваться на тему структуры БД. Возможно, вы также подскажете что-нибудь в части методологии.


Описание задачи:
Бюджет составляется на текущий год в разрезе месяцев, и включает ожидаемые расходы на 3 года вперед (последующие прогнозируемому - единой суммой). К последующим 3 годам применяется инфляция.
В течение года есть 4 отчетные вехи (включая нулевую - собственно, бюджет). На каждой из них есть N месяцев с фактическими данными, и остаток - с прогнозными. На каждой вехе происходит корректировка планируемых до конца года расходов, чтобы итоговая сумма соответствовала запланированной в начале года.
В конце года сумма, запланированная на следующий год, становится бюджетом (веха 0) следующего года и подлежит разнесению по месяцам.
Бюджет ведется постатейно. Сумма на каждый месяц определяется как [кол-во * цена] . В БД хранятся кол-во и цена, сумма вычисляется при считывании.

На данный момент это реализовано так.
Таблица статей (основная), колонки: год, веха, статья, МВЗ, [месяцы 1-12, год + 1, +2, +3]: запланированные кол-ва и цены без учета инфляции.
Остальное - справочники.
Инфляция применяется при выгрузке информации в отчет. На разных вехах коэффициент инфляции может быть разным.

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

Вторая сложность: переход года, когда единую годовую сумму нужно разнести по месяцам, да ещё и инфлировать и её, и последующие суммы. Т.е., Год Веха Статья Сумма декабрь Сумма Год+1 Сумма Год+2 Сумма Год+32016 3 Пирожки ххххх 1000 1000 10002017 0 Пирожки 1061 1061 1061
(Инфляция на вехе 2016-3 для "Год+1" = 1.061)

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

Вопросы:
Я предполагаю при создании версии 2 использовать такую структуру.

Вместо "широкой" таблицы с месяцами сделать 2 таблицы:
1. статьи затрат (включая год бюджета и веху)


2. суммы затрат в привязке к ИД статьи


, а также собирать суммы на 3 последующих года - на декабрь , что позволит в любой момент развернуть их по году.
Верный ли ход мыслей? Что можете посоветовать по организации данных?

Как лучше учитывать корректировки бюджета?

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


Также рад рекомендациям в части учебного материала.

Спасибо всем ответившим!

Дедушкаимхо, стоит пользоваться поиском
и лучше будет вот здесь Проектирование БД спрашивать.
Прошу прощения, не углядел.

mad_nazgulEugene_p1,

Забить на БД.
Использовать excel :-)

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


Уже проходили, точнее, проходим.
Адъ и ИзраИль!


mad_nazgulНасчет версий...
Посмотреть как устроен git или mercurial.

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

DirksDREugene_p1,

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

Тут ещё вот какой момент. При составлении бюджета используется формула Cost*Qty, а при внесении корректировки запросто может быть внесена сумма (например, сказали отрезать 100 тыс. - никто не будет подгонять c и q).
Потом, в отчеты на любой момент времени не требуются - достаточно состояния "на веху".

ДедушкаПисать корректировки в отдельную таблицу (со знаком +/-) на "веху" считать суммарную корректировку (если не может быть корректировок задним числом, можно даж сохранять дабы не считать каждый раз) и складывать с суммой бюджета.
Либо писать корректировки как Cost*Qty где Qty=1, а Cost=сумме корректировки (только тип операции заведите).
Разумная мысль насчёт отдельной таблицы! Я именно так и предполагал сделать, т.к. сумму корректировки не нужно инфлировать.
А вот что посоветуете делать с инфлированием?
Тут вопросы какие:
1. На разных вехах разный уровень инфляции для следующего года.
2. На последней вехе проинфлированная сумма должна стать основой бюджета следующего года (см. мою таблицу-пример)
3. Иногда руководство хочет пересчитать бюджет вехи с новым уровнем инфляции.
4. Как только формируется бюджет следующего года, бюджет предыдущего становится read only.

Разумеется, есть справочник инфляций для каждой вехи. В данный момент механизм "сумма Год+1 = CostY+1*QtyY+1*InfY+1" работает.
Суть вопроса в том, как безболезненно осуществить пункт 2.


И ещё: есть ли смысл писать только изменения каждой строки между вехами (скажем, веха 1: +100 на май 2017), и корректировки привязывать к строке? Или проще на каждой вехе делать копию строки и всех корректировок на предыдущих вехах?
Теоретически, второй вариант проще в реализации, но неэкономный в части количества данных в БД.

guest_20040621,

Дружище, вы не поверите. Компания международная, и стандарт отчетности единый. :) И им не требуется качественного предсказания, тут требуется качественное обоснование! :))

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

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

Поэтому и спрашиваю. Как оно у них устроено, я более-менее понял, теперь нужно придумать архитектуру.

guest_20040621Угу, я вижу, насколько международная. Успехов и вам, и вашей лавке.

guest_20040621,
Эта фраза должна была меня унизить?

guest_20040621,
Не вам судить о моей квалификации. А уровень вашей культуры понятен из ваших сообщений.
Проходите, не задерживайтесь.