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


То, что идет в стандартной поставке не на какие уши не натянешь
Зачем мне "Обзор расхода бюджета" в годовой расшивке, если у клиента в политике прописано помесячно?
Клент имеет право на всё


Позвольте не согласиться! Результат всего, что делается в модуле - это отчетность. Если она не корректная, то грош цена всему функционалу.



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

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

Внимательно посмотрите FMCYLOAD - все таки именно им можно перетащить в бюджетные данные не только из планов, но и из другой версии бюджета, именно для этого есть и опции в базе расчета:
- Все операции и виды бюджета
- Определенные операции и виды бюджета

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

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

))))
Здесь понятие "скорее всего" не пройдет )
Но все же, спасибо за советы )

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

Добрый вечер, уважаемый ImpCons
Подскажите, пожалуйста, как работает схема с пользовательскими регистрами?
1) Создаю 13 версий: YEAR, M01, M02, M03, M04, M05, M06, M07, M08, M09, M10, M11, M12.
2) Создаю 12 пользовательских регистров: P1, P2, P3, P4, P5, P6, P7, P8, P9, PA, PB, PC.
3) Определяю параметры настройки фильтра для назначеных средств: присваиваю регистру 9H версию YEAR, регистру P1=>M01,....PC=>M12.
4) Присваиваю профили допусков и стратегию д/объектов контроля наличия для пользовательских регистров.
5) Выбираю горизонт проверки для пользовательских регистров
6) Специфицирую активацию контроля наличия для пользовательских регистров
7) Делаю FMBB на сумму 120 в версию YEAR на весь год
Делаю FMBB на сумму 10 в версию M01
9) Делаю FMBB на сумму 10 в версию M02

Делаю FI-проводку, в которой указываю релевантную финпозицию.
Каким образом будет выбираться пользовательский регистр в момент проводки в зависимости от даты проводки FI_документа ?

Заранее спасибо!

К сожалению ничем помочь не могу, все мои проекты выполнялись по схеме годовой бюджет с помесячной разбивкой в 1-ой версии, перенос ежемесячного плана/бюджета в 0-ую версию и АКН по 0-ой версии. Везде контроль за переиспользованием был все таки годовой, а не квартальный например и остатки прошлых месяцев можно было использовать в текущем, а бюджет с будущих месяцев не давал есться АКН, потому что не был перенесен в 0-ую версию. И объясняя бюджетникам схему в 3-х компаниях, где я внедрял ни у одного не возникло нестыковок при построении такой моей схеме.
С помесячными регистрами пару довольно подробных разборов есть на форуме. В одном из них dante14 подробно все описал - по моему факт нужно через BADI собирать, и даже пример кода BADI был выложен .
Но как я выше описывал - с моей точки зрения, Ваша схема не требует 12 пользовательских регистров в отличии от ситуации NhjirbyRfanfy, где как минимум, поквартальные пользовательские регистры нужны, Вам просто нужно в голове мою схему уложить и тогда своим бюджетникам Вы ее без проблем разложите.

Спасибо
Нашел BADI FMAVC_ENTRY_FILTER.
Буду разбираться.

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

Если уже перенесли лимиты за апрель, да, при проводке за март будут потребляться общие лимиты перенесенные в 0-ую версию. Никак эту проблему не решали - если лимитов хватало, то проводили за март. Корректировку лимитов делал/делаю по 0-ой версии FMBB процессами не ENTER (SUPL, RETURN) для того чтобы можно было отделить в 0-ой версии первоначально утвержденный бюджет (заведен ENTER) от корректировок лимитов, проводимых при наступлении планового периода (проводимых supl, return, transfer (send, recieve) и т.п.).

т.е. если это корректировка бюджета, то она присутствует только в 0 версии, причем операциями supl, return, transfer (send, recieve), и при этом контроль производят вручную? чтобы последующие месяцы не захватить. Утвержденный бюджет ежемесячно операцией enter вводить... немного "залезу" в другую тему: бюджетный период использовать не получится для отчетов, так как нужно использовать неиспользованные лимиты прошлых месяцев, и чтобы отобразить отчеты по периодам придется писать их на абапе

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

Да корректировки нужно делать в 0-ой версии и именно этими процессами. Контроль за чем осуществлять вручную? Если за изменениями лимитов - то что именно контролировать? Раз пользователь изменяет лимиты, то значит имеет на это основания, если не имеет, то его найдут и накажут .
Я уже не помню в какой по счету теме пишу, в том числе и в этой писал, в предлагаемом мной варианте, утвержденный бюджет переносится из 1-ой версии в 0-ую помесячно, а первая версия, да вводится с процессом Enter. У меня на последних 3-х проектов например загружается в 1-ую версию из BI.

Спасибо за пояснения, значит если меняют утвержденный бюджет, то в этом случае контролируют сами себя. Спрашиваю, потому что наших пользователей нужно везде контролировать обычно и такой вопрос опять: при ежемесячной загрузке плана бюджета и использовании версий для контроля деблокированный бюджет можно вообще не настраивать? для чего его можно использовать.
Насчет отчетов, наверное в другую тему viewtopic.php?f=47&t=82108. Нужен план-фактный анализ бюджета по месяцам. Можно ли обойтись без бюджетных периодов. Для плана я создала показатель, и он отображает данные за весь год, а не по месяцам.

Если меняют утвержденный бюджет, то да сами себя контролируют - можно посоветовать им в текст документа ввода бюджета вводить основание для корректировки (приказ, служебная записка, протокол бюджетного комитета и т.п.). В самом документе всегда можно посмотреть кто его вводил/последний корректировал - так что кто "накосячил" всегда можно быстро найти.
При загрузке помесячно и необходимости реализации возможности использования остатков лимитов предыдущих месяцев с самого начала года, бюджетные периоды не нужно использовать. Бюджетные периоды нужно использовать, когда нельзя потреблять остатки неиспользованных лимитов предыдущих периодов. Например, мы в текущих проектах используем бюджетные периоды для кварталов, т.к. неиспользованные лимиты с предыдущего квартала не должны автоматически потребляться в текущем, внутри же квартала так же перегружаем лимиты из одной версии в другую ежемесячно, т.к. внутри квартала неиспользованные лимиты предыдущих месяцев должны быть доступны в текущем месяцы того же квартала.
Суть деблокирования бюджета а моем понимании в том что отдельно по фондам давать доступность лимитов к потреблению, если же доступность лимитов отдается сразу по всем фондам, то достаточно схемы перекидки в версию которая контролируется в АКН текущего контролируемого периода.
Отчетов по помесячному плану, факту, план/факту стандартных нет - так что нужно разрабатывать. Бюджетные периоды не для отчетности - а больше для АКН, хотя наверно в стандартных report writer-овских отчетов для построения отчетности помесячно или поквартально, с помощью бюджетных периодов, отчетность наверно можно реализовать, а в АКН когда нужно не вести контроль в разрезе бюджетных периодов, но у меня не было еще необходимости такую схему реализовывать только для использования стандартной отчетности - сейчас на проектах в основном отчетность на разработках, т.к. она должна быть регламентированного вида для подачи в вышестоящие департаменты.

Вариант с версиями, как оказалось, нам не подойдет. Контроль нужен и до и после загрузки бюджета, и вести бюджет в 0 версии. Бюджетные периоды использовать допустим не будем для АКН. Есть ли возможность их отключить в контроле? В поле группы операций нет бюджетного периода: Система управления бюджетом (BCS) - Контроль наличия - Обработка профилей допустимых отклонений. Или это связано с тем, что БП мы не активировали.

Т.е. фонды также строго разобьют потребление бюджета аналогично БП, соответственно и нам для схемы накопительного итога не подойдет? Остается воспользоваться АБАПом?:) подобный контроль уже писали раньше, думали с BCS можно как то по другому выкрутиться.

И опять же, мы можем активировать БП для использования в отчетах, но не использовать их в АКН? Насчет активации БП: в активации контировок нет БП, однако транзакция на создание БП FMBPD открывается, мы что то не установили, или дело в настройках