Задача следующая. Есть ежемесячные планы. Необходим контроль наличия по месяцам, при этом в рамках периода остаток лимита за предыдущие периоды увеличивает лимит текущего. Например, в январе "осталось" 100 руб. В феврале план - 200 руб. Это значит, что в феврале можно потребить 300 руб. В марте осталось 400 руб. В апреле план - 500 руб. Т.к. квартал новый - то в апреле можно потребить только месячнынй лимит - 500 руб

Возникла вот какая идея
Что если создать 12 регистров - на каждый месяц
FMAVC_ENTRY_FILTER
фильтр по бюджету
реализовать так, что бюджет во 2-ом месяце квартала равен сумме бюджетов первого и второго месяца, в 3-ем месяце квартала - сумме бюджетов 1,2,3 месяцев квартала

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

Вроде теоретически должно соответствовать требованиям постановки

Интересно мнение сообщества

Для Вашей задачи не нужно делать 12 пользовательских регистров на каждый месяц, хватает одной пары 9I/9H на год. Создается версия скажем 1 для годового бюджета с помесячной разбивкой, в версию 0 переносятся каждый месяц из версии 1 планы, на версии 0 автоматом лимиты учитываются с учетом остатков прошлых месяцев.
Если нужны отчеты по годовому плану используете версию 1. Если нужен АКН по текущем месяцу + остатки лимитов по предыдущим месяцам с начала года используем версию 0.

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

точнее если нужнен АКН по кварталам, то и нужно наверно по 4 пары регистров КН и создавать.

горизонт создания ТАП - до 2-х месяцев, следовательно, лимиты на уже должны быть в этот момент на текущем и 2-х последующих месяцах. Планы уже есть в начале года. Как в этом случае будет работать Ваш вариант? Как осуществлять "накопительный" итог для планов в рамках месяца? В Вашем случае нельзя разве будет в январе, скажем, съесть весь лимит квартала?

Если планы нужно контролировать и АКН нужен на квартал, то из версии 1 в версию 0, нужно копировать план сразу за 3 месяца, тогда и горизонт создания в первый месяц квартала нормально на квартальный лимит проверяется, если же нужно после первого месяца продолжать ТАП-ы с горизонтом в 2 месяца бить, то нужно по хорошему организовывать пользовательские регистры на каждый квартал, а не месяц.
В моем варианте проще когда приходит нужный месяц, то его переносят из версии 1 в версию 0 и по этому месяцу разрешается расходовать ТАП-ами бюджет. Если у Вас ситуация посложней, то придется наверно и пользовательские поквартальные регистры создавать, но никак не месячные, а затем остатки предыдущего квартала как Вы писали считать доступными для текущего.

Не понимаю, как все же получится контролировать бюджет во второй, например, месяц, с учетом остатка первого... Пример. Текущий квартал, загрузили планы на январь, февраль, март. Предположим, 100, 80, 120. Сегодня (02.01) делаю ТАП с датой платежа 03.01 на 40 руб. Проверяет лимит только в 100. Если сегодня делаю ТАП с датой платежа в феврале, то у меня должен быть доступ на лимит 100 + 80 - 40. Предположим, сделали на февраль ТАП на сумму 70. Все в лимите. Если сейчас попробовать сделать ТАП с датой платежа в январе на сумму 10 руб, то лимит должен быть превышен, т.к., несмотря на то, что в январе есть лимит, он уже съеден февральским ТАПом. Опять же, в марте доступный лимит = 100 + 80 + 120 - 40 - 10...
Мне кажется, что одним регистром на квартал здесь не обойтись...

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

Вариант 1. Помесячный контроль. 12 пар пользовательских регистров.
План: январь 100, февраль 80, март 120.
i. 03.01 -40 руб, остаток лимита января 100 - 40 = 60 руб
ii. ТАП в феврале -70 руб, остаток лимита февраля 80 - 70 = 10 руб
iii. ТАП января -10 руб, остаток лимита января 100 - 40 - 10 = 50 руб
Бюджет должен расходоваться не от даты ввода документа, а от даты проводки документа (ТАП-а,аванса, платеже и т.п.)

Вариант 2. Поквартальны контроль. 4 пары пользовательских регистров.
План: 1-ый квартал 100+80+120= 300 руб
i. 03.01 -40 руб, остаток лимита 1-го квартала 300 - 40 = 260 руб
ii. ТАП в феврале -70 руб, остаток лимита февраля 300 - 40 - 70 = 190 руб
iii. ТАП января -10 руб, остаток лимита 1-го квартала 100 - 40 - 70 - 10 = 180 руб
Контролируется сумма за квартал без учета бюджетов каждого месяца

Вариант 3. Годовой с помесячной выгрузкой плана и с нарастающим итогом. 1-а стандартная пара регистров 9I|9H на весь год.
Если бы Вам остаток бюджета 1-го квартала можно было использовать во 2-ом и т.д., то я бы рекомендовал использовать бы именно его.
31.12.2010 план: загружаем в 0-ую версию только план января и февраля, для того чтобы контролировать ТАПы с 2-х месячным горизонтом 100+80
i. 03.01 -40 руб, остаток лимита 1-го квартала 180 - 40 = 140 руб
ii. ТАП в феврале -70 руб, остаток лимита февраля 180 - 40 - 70 = 70 руб
iii. ТАП января -10 руб, остаток лимита 1-го квартала 180 - 40 - 70 - 10 = 60 руб
31.01.2011 план: Загружаем план и марта, чтобы контролировать еще на 2 месяца ТАП-ы: 60 руб + 120 = 180
и т.д.

Т.к. Вам нельзя чтобы квартальные остатки переходили с текущего в следующий, то советую использовать вариант 2, но с переносом из 1-ой версии в 0-ую в начале квартала только плана 2-х месяцев (января, февраля), по окончанию 1-го месяца дозагрузить март, по окончанию февраля дозагрузить апрель, но АКН по апрелю уже контролировать по 2-ой паре пользовательских регистров.

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

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

Предложенный мной вариант с 12 регистрами и отражением факта в рамках квартала нарастающим итогом и факта в регистре платежа и последующих регистрах квартала проверил - работает

>>Бюджет должен расходоваться не от даты ввода документа, а от даты проводки документа (ТАП-а,аванса, платеже и т.п.)
у нас от даты оплаты. 100 профиль

Насчет мудрите, писал по поводу вот этой части примера:

Мне совершено не понятно как ТАП c датой платежа в феврале должен съедать январский лимит??? Вы же сами написали что Ваш 100-ый профиль работает по дате оплаты. Или Вы под датой оплаты понимаете дату ввода документа ТАП-а, ТП, исходящего платежа?

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

Я так понимаю из-за того что нельзя чтобы в январе съелся бюджет февраля, когда мы план и января и февраля деблокировали?

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

to ImpCons

спасибо за диалог! С удовольствием разъяснил бы дату платежа, но щас у нас старт, времени даже на сапфорум почти нет

Еще раз - спасибо!

Ок, у нас тоже с 11 января начнется - писать времени так же не будет!

Удачного старта!

Я очень извиняюсь, что поздно встрял в диалог.
1. Каким стандартным инструментом Вы массово переносите с 1 версии в 0 ?
2. Вы хорошо сказали "на версии 0 автоматом лимиты учитываются с учетом остатков прошлых месяцев". В 1 версии, я так понимаю, я не увижу Факт. Чтобы увидеть картину "План/Факт", мне нужно смотреть 0 версию. Я увижу, что анализ План/Факт по каждому месяцу не соответствует действительности. Вероятно правильней было бы физически переносить остатки плановых сумм из одного месяца в следующий, тем самым обнулять план предыдущего месяца?

1. FMCYLOAD
2. Каким образом план/факт не соответствует в 0-ой версии дествительности? План помесячный как грузится из версии 1-ой версии в 0-вую каждый месяц так помесячно там отлично в 0-ой версии и будет отображаться, факт за каждый месяц так же правильно в 0-ой отражается. То что факт скажем февраля больше чем план февраля, в чем проблема, если в политике компании прописано что остаток бюджета января может использоваться в феврале - не вижу скрытого смысла именно эти остатки нести с января в февраль, - как все было изначально делалось, так в системе и отразится.

Добрый вечер, спасибо за ответ.

1. Я имел ввиду не генерацию Бюджетных данных в версию 0 из Плановых данных версии 1. Я имел ввиду копирование Бюджетных данных из версии 1 в Бюджетные данные версии 0. Ведь процесс планирования закончен и все суммы на год утверждены. С помощью FMCYLOAD я сгенерирую Бюджетные данные в 1 версию на год. А потом, как Вы предложили, каждый месяц копировать Бюджетные данные с 1 в 0 версию.

2.
Если в политике компании прописано, что остаток бюджета января может быть использован в феврале, то как правило тем самым подразумевается, что неиспользованный бюджет января должен перейти в февраль и иметь возможность быть использованным. Технически он(январский остаток) может быть использован в феврале, только в отчетах План/Факт он останется в колонке "Бюджет января", а Факт февраля превысит Бюджет февраля. Тем самым отчетность План/Факт помесячно будет не корректной.

Понял, у меня просто первая версия заполняется именно плановыми данными через FMPLCPD на год (Утвержденный бюджет замораживается в отдельную 9-ую версию FMCYFREEZE) а первую версию я закрываю статусами от изменений и из нее я уже помесячно переношу в 0-ую FMCYLOAD. Если у Вас первая версия заполнена имено бюджетными данными, то переносите помесячно в 0-ую транзакцией FMMPTRAN.


А Вы не задумывались почему стандартный отчет FMRP_RW_BUDCON - "Обзор расхода бюджета" только в годовой расшивке? По хорошему постановка которую мы обсуждаем - это план/факт отчетность с нарастающим итогом - т.е. все отчеты нужно делать не помесячно: январь, февраль, март и т.д., а в январе: с января по январь, в феврале: с января по февраль, в марте: с января по март, и т.д.
У кого то из моих Заказчиков и по старому (до внедрения FM) они так отчетность собирали - ничего в этом случае переделывать мне не приходилось кроме шапки отчета (период указать). Но перетаскивать из января в февраль остаток января чтобы в плане февраля показался и этот остаток, только для того чтобы показать в помесячной разбивке, немного страно . Я бы попытался убедить заказчика что первоначальный помесячный план и показ отчетности с нарастающим итогом более точно отражает его политику планирования чем переносы остатков по бюджету с предыдущего месяца в текущий.