Сегодня поговорим и о самой распространенной ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС».
Коллеги, я являюсь счастливым автоматизатором: сначала я разрабатывал бюджетирование в 1С:ERP2 и 1С:КА2, а теперь его внедряю. В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.
Сегодня поговорим и о самой распространенной на мой взгляд ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС». В базе это выглядит так:
Т.е каждому элементу справочника «статьи ДДС» мы прямо сопоставляем статью бюджета движения денежных средств:
Далее в правилах получения фактических данных каждой статьи бюджетов мы закономерно видим такую конструкцию:
Т.е в каждой статье бюджетов автоматизаторы в правиле получения фактических данных прописывали отбор по соответствующей статье ДДС. Во-первых, это очень трудоемко. Во-вторых, это приведет к неприятным последствиям в будущем, которые мы сейчас посмотрим. Есть и в-третьих – так мы лишаем нашего заказчика возможности самостоятельно редактировать бюджеты.
В данной модели при добавлении статьи ДДС нужно вводить новую статью бюджетов, настраивать отбор и модифицировать виды бюджетов. Т.е невозможно добавить статью ДДС в бюджеты без специалиста по автоматизации.
Теперь немного технических подробностей: разберем как получаются фактические данные в подсистеме «Бюджетирование». В зависимости от версии конфигурации и применяемого решения (КА или ERP) могут сработать следующие схемы:
1. Получение факта для каждой статьи отдельной компоновкой и выгрузка в сводную таблицу значений. Тут всем очевидно, что выполнение СКД в цикле – ничего хорошего не сулит. Особенно с ростом базы данных и количества статей бюджетов
2. Компоновка всех необходимы правил в одну СКД. При этом на основании уникальных отборов будут сформированы однотипные запросы, но с разными параметрами отборов, и объединены в рамках набор с типом «Объединение» одной СКД. Получится большая компоновка с кучей наборов в «Объединении». На практике так же выполняться будет неприятно.
Если вы указываете отбор для статьи бюджетов – то такая статья создаст новый источник, т.е новый набор в рамках набора «объединения», либо выполнится отдельной компоновки в зависимости от версии применяемого решения. При этом, если несколько статей бюджетов имеют одинаковый отбор в правилах фактических данных – то запрос скорее всего будет объединен. Для оптимального получения фактических данных лучше делать статьи бюджетов максимально укрупненными. Для приведенного выше примера оптимальная настройка выглядит так:
Таким образом, для этого примера, мы более чем в 2 раза сократили количество запросов для получения фактических данных, а соответственно более чем в 2 раза оптимизировали формирование бюджетных отчетов.
В такой модели, при правильной настройке фактических данных, мы получим систему бюджетирования, в которой пользователи самостоятельно могут добавлять «Статьи ДДС» в бюджетах. И в план-фактных отчетах такие добавленные статьи будут отображаться без изменения видов бюджетов, т.е автоматически. Как правильно настроить фактические данные для статей бюджетов мы рассмотрим в следующей статье.
Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим, а самые интересные проблемы разберем подробно в последующих статьях.
ИМХО — главная сложность в перенавороченном механизме получения данных, строго последовательно.
Для этого механизма, где как ни старайся будут тяжелые запросы в цикле, приходится дорабатывать и оптимизировать код.
Не сложно же было написать параллельные вычисления! В моем примере один из отчетов собирал данные 8-12 часов, пока не провели оптимизацию кода. Ускорили до 10 минут.
Ну а добавить статью в бюджет можно и без автоматизаторов, не велика сложность. Наши пользователи освоили с первой попытки.
«Не знаешь как — спроси меня» (С)
(1) можете пример такого бюджет привести? С замером производительности.
(2)
1
В заголовке статьи указано, что Вы являлись разработчиком, а теперь внедряете. Я готов поработать совместно, если это окажет влияние на подсистему в будущих релизах и принесет бонусы заказчику.
Ради спортивного интереса — не готов.
Замеры могу предоставить только по ускоренной версии. Полагаю, что выгрузит в xml настройки тоже получится договориться.
(3) я писал в статье, что могу разобрать интересные случаи в последующих статьях для сообщества. Учтет это вендор или нет я прогнозировать не берусь.
Что касается формирования 12 часов — то я полагаю что скорее дело в неверной настройке, а не в коде. Перенастроить виды бюджетов как правило быстрее чем переписывать код подсистемы. Если вид бюджета не переписывался — то могу посмотреть на типовой как его можно было бы ускорить.
(4) Полагаю, не имеет смысла. Конкретная задача решена.
Расскажите, зачем там 2 алгоритма формирования «РассчитатьФактПоВидуБюджетаАльтернативный» и «РассчитатьФактПоВидуБюджета»? В моем случае результат в данных одинаковый, а у альтернативного варианта — производительность на порядок ниже. Да и в релизе только этот вариант используется.
Технические различия понятны по комментариям. На практике — зачем?
И молчание 🙁
Добрый день.
Я в отличии от Вас являюсь не автоматизатором, а пользователем 1С:ERP2, в связи с этим вопрос.
Мне тоже показалось подход 1-в-1 используемый моим коллегой очень трудоемким, и я ввел другой вид бюджета
с укрупненными статьями, и подробной разбивкой по аналитике. Вопрос в том, влечет-ли это какие-нибудь ограничения
при использовании бюджета для лимитирования в казначействе? Контроль суммы возможен только по статье бюджета,
или по аналитике тоже?
(5) Альтернативный механизм разрабатывался после моего ухода в апреле 2016 из 1С. В официальных публикациях нововведений на partners я не нашел связанных материалов. Посмотрел код и мой вывод: в альтернативном механизме все запросы к факту объединены в 1 СКД, что теоретически должно дать выигрыш в производительности. Однако применяется механизм СхемаЗапроса — по моим замерам далеко не быстрый механизм. Что в свою очередь ставит под вопрос выигрыш в производительности.
(6) Я с вами! 🙂 Много работы по текущим проектам — поэтому отвечаю не оперативно. Но отвечу обязательно!
Контроль суммы возможен до аналитики. Уровень контроля настраивается в правилах лимита. Например, на статье бюджета 2 уровня аналитики: статья ДДС и доп.аналитика. Можно настроить что бы контроль был только до уровня статьи ДДС, а доп.аналитика использовалась только участниками процесса бюджетирования для план-факт анализа. Во вложении — пример настройки лимитов ДС, где выделено как установить нужный уровень аналитики. Лимиты ДС настраиваются в модели бюджетирования. Модели бюджетирования находятся в пункте меню «Бюджетирование и планирование» -> «Настройки и справочники» -> «Модели бюджетирования».
(8) Там с этим механизмом дополнительная куча колонок в результирующей таблице получается. Этот алгоритм в несколько раз увеличивает длительность выполнения запроса.
(11) дополнительные колонки могут существенно увеличить время выполнения только в случае если эти колонки включены в индекс таблицы значений и исть массовое добавление/удаление строк, либо на старой платформе — изменение значений этих колонок. Индексации таблицы факта я не нашел. Поэтому склоняюсь к варианту что заседление дает СхемаЗапроса.
Спасибо. все понятно.
+ Полезная статья. Уважаемые, не мог бы кто-нибудь скинуть рабочую СКД на получения факта из статьи бюджета, почему-то не взлетает никак, спасибо.
(14) Уточните: правила факта или правила исполнения бюджета? Какая именно ошибка?
(15) (15) Сценарий — Фактические данные, В СКД простейший запрос в собственный регистр сведений на получение данных:
ВыручкаПоДМС.Период КАК Период,
ВыручкаПоДМС.Организация КАК Организация,
ВыручкаПоДМС.Подразделение КАК Подразделение,
ВыручкаПоДМС.Выручка КАК СуммаРегл,
ВыручкаПоДМС.Выручка КАК СуммаУпр,
ВыручкаПоДМС.Выручка КАК СуммаВВалюте,
«Валюта» КАК Валюта,
«Инкассация» КАК ИсточникДанных
ИЗ
РегистрСведений.ВыручкаПоДМС КАК ВыручкаПоДМС
ГДЕ
ВыручкаПоДМС.Период МЕЖДУ &НачалоПериода И &КонецПериода
Показать
В результате работы правил результат выдает:
Но вот в самом отчете бюджета пустота…
(15) Сценарий Фактические данные, запрос простейший:
ВыручкаПоДМС.Период КАК Период,
ВыручкаПоДМС.Организация КАК Организация,
ВыручкаПоДМС.Подразделение КАК Подразделение,
ВыручкаПоДМС.Выручка КАК СуммаРегл,
ВыручкаПоДМС.Выручка КАК СуммаУпр,
ВыручкаПоДМС.Выручка КАК СуммаВВалюте,
«Валюта» КАК Валюта,
«Инкассация» КАК ИсточникДанных
ИЗ
РегистрСведений.ВыручкаПоДМС КАК ВыручкаПоДМС
ГДЕ
ВыручкаПоДМС.Период МЕЖДУ &НачалоПериода И &КонецПериода
В результатах работы правил результат есть, но в самом ничего не показывает
На первый взгляд в СКД все верно. Единственное — проверьте, указаны ли типы для полей СКД для организации и подразделения.
Пришлите скрин настройки вида бюджета и настроек отчета при формировании. Может ошибка не в СКД.
(18) Я так же пробовал схемы входящие в состав конфигурации, тоже не взлетело. Не могу понять этот феномен.
В настройках бюджета «месяц» был лишним, завелось!
(20) А если убрать флаг ограничения на условие «Период» — с периодом «месяц» заработает?
Добрый день! А можно ссылочку на эту статью? Тоже воюю с правильным получением факта, но ничего не выходит….
Подскажите, я так понимаю, факт получается только с помощью произвольных запросов? По данным Опер. учета или Регл. учета брать его не получится?
Что делать, если структура ЦФО не совпадает ни с управленческой структурой предприятия, ни с бухгалтерской ?
Пилить свое ? Битфинанс ? Или можно как-то по типовому извратится ?
(22) Статья тут:
Для БДДС удобнее брать произвольным запросом объединение по всем регистрам ДвиженияДенежныеСредства<РазделДвижения>
Но если БДДС на отдельные разделы, то и по хоз.операциям вполне можно собрать. Т.е универсального рецепта нет, главное не допустить ошибку, которую я описывал в статье.
(23)
Пилить свое ? Битфинанс ? Или можно как-то по
Вполне решается типовыми средствами:
1. Добавляете доп.реквизит на справочник «Структура предприятия» — в этот доп.реквизит заполняете соответствующее ЦФО. В правилах факта указываете мэппинг аналитики ЦФО к доп.реквизиту ЦФО
2. Если структура ЦФО с управленческой структурой соотносится как многие ко многим, т.е в одном упр.подразделении может быть несколько ЦФО — то применяйте модернизированный вариант 1: доп.реквизит на документ. При включении хранимого факта (в ERP) доп.реквизиты регистраторов становятся доступными и можно настроить мэппинг аналитики к доп.реквизитам регистраторов.
(25)
Так какой тип доп реквизита делать то ? Строку ? Так-то, по хорошему нормальный справочник нужен, дабы его могли ответственные пользователи редактировать, смотреть, и т.д. Или запилить справочник, включить его в состав доп реквизитов ?
(24)
Спасибо, пойду штудировать статью.
Попробовала сделать и произвольным запросом, но пока без объединения, взяла простой запрос по РН Денежные средства (безналичные), однако, как и прежде в факт попадают данные по Заявкам на расходование ДС, по которым еще не проведено Списание безналичных ДС… Запнулась на этой ошибке и никак не могу ее понять и устранить…
(26)
А чем справочник доп.значений не подходит?
(28)
тем, что в нем кроме самого значения ничего не сохранить.
Хотелось бы отдельно взятую сущность, которую можно было бы потом более широко использовать, чем просто выбирать значения.
Но в целом, я идею понял, спасибо за ответ.
(25)
Подскажите, пожалуйста, в этом случае добавляем доп. реквизит в экзмепляр бюджета и во все документы факта, верно?
(25) А как настроить связь аналитики с этим доп. реквизитом?
(31)
В правилах получения факта настраиваете заполнение аналитики из доп.реквизита.
Коллеги, добрый день.
А как быть с бюджетами, где строго регламентирована структура (300 строк), регламентированы коды статей.
Я не вижу в таком варианте не делать настройки иначе как статья бюджета = статья затрат. Более того, мне не везде статей затрат хватает, приходится по договорам бегать чтобы верно статью определить при сборе факта.
(33)
300 строк — высока вероятность проблем с производительностью. Лучше все таки подумать как выйти из положения с помощью доп.реквизитов на статьях затрат. Но если совсем не получается — используйте хранимый факт, что бы решить проблему с производительностью.
(10) Вопрос начинающего.
Позволяет ли встроенный функционал КА2.4 обеспечить лимитирование только по некоторой аналитике , указываемой пользователем интерактивно , например , в дополнительном реквизите документа » Заявка на расходование ДС» ?
можно ли обойтись в таком случае без дополнительного реквизита ?
(35) приведите пример, что бы стало понятнее
(36) КА 2.4 ,
«Заявки на расходование ДС» составляют инициаторы ( ~ 100 чел) из разных подразделений организаций. Для каждого подразделения должен быть составлен некоторый бюджет в разрезе понятных для инициаторов статей.
Предполагается
связать справочник типовой конфигурации «Статьи бюджета» один в один с элементами условного справочника с названием «СтатьиПонятныеИнициаторам». Далее , в «Заявку на расходование ДС» добавить ДополнительныРеквизит с условным типом «СтатьиПонятныеИнициаторам».
Ну, и вопрос :
— как связать «статьи бюджета» со «»СтатьиПонятныеИнициаторам» ?
Дополнительно :
что такое «механизм «хранимого» факта» и как его включить в конфигурации ( на ИТС встретил только упоминание о нем )
(37)
— как связать «статьи бюджета» со «»СтатьиПонятныеИнициаторам» ?
Дополнительно :
что такое «механизм «хранимого» факта» и как его включить в конфигурации ( на ИТС встретил только упоминание о нем )
Связывать статьи бюджета 1:1 со статьями «понятными» инициаторам — не лучшее решение. Статьи ДДС — понятны инициаторам? Можно ли статьи ДДС привести в понятный инициаторам вид?
Если отвечать на вопрос «можно ли связать» — ответ можно. Вариантов много, все упирается в имеющуюся в фактических данных аналитику. Т.е откуда в факт.данных будете брать «СтатьиПонятныеИнициаторам».
Хранимый факт — галка в правилах получения факта.
(38) Угу.
И 1:1 — плохо.
И лучше сделать понятными «Статьи ДДС», чем изобретать справочник «СтатьиПонятныеИнициаторам» .
И неоткуда брать факт.
Спасибо. Пойду на новый круг уговоров .
Я не выдумал этот пример.
Почитал Ваши статьи . Ну прям , хорошо.
Чем крупнее специалист , тем проще , яснее он излагает.
(34) Сергей, благодарю за Ваши полезные статьи.
Может подскажете, куда копать? вот если ситуация, как у aser1c (отношение статей ДДС к альтернативным N:N — бухгалтерские и управленческие), но надо еще по этим доп. реквизитам и Исполнение контролировать? 🙂 Т.е. в правиле для исполнения — нет галки для хранения факта (все «на лету»). Реально ли как то решить по аналитике доп.реквизита документа? реально ли хотя бы решить произвольным запросом?
(41)
Обращение к доп.реквизитам документов возможно только в хранимых правилах. Иначе такой запрос по всем документам будет очень долго выполняться. Можно попробовать опереться на какую либо аналитику (сделки, подразделения) или сочетания (сделки + статьи ДДС и т.д.). Произвольным запросом задача решается, но опять же у меня есть обоснованные подозрения, что выполняться такой запрос будет очень долго. Что бы точнее подсказать опишите мне в личку что это за аналитика по которой нужно контролировать, тогда смогу более точный совет дать.
(33)
(33)могу подсказать как сделать, если еще актуально, сам мучился с этим, сделал в итоге
(45) да, буду рад совету
(46) стояла задача сделать Бюджет расходов и доходов, соответственно должны выводиться все статьи расходов с их аналитикой (у каждой статьи разная), по типу как работает отчет «Доходы и расходы» в типовой конфе. Так как у Статей бюджета все 6 аналитик, то пришлось подстраивать учет под это, т.е. у нас нет на статьях расходов более 6 вариантов аналитик (в принципе достаточно для учета, главное убедить пользователей). Справочник Статей расходов имеет около 350 статей, с определенной структурой, т.е. куча папок с разной степенью вложенности и выводить надо именно так в отчете. Я заводил Статью бюджета для каждой группы статей (папки), настраивал получение фактических данных с отбором Статей расходов «в группе» или «в группе из списка», у Статей бюджета у меня заполнены все 6 аналитик, как раз, чтобы выводить все возможные варианты Статей расходов, в итоге получилось около 25 статей бюджета с правильно настроенными фактическими данными, все остальное в структуре отчета можно решить через создание групп и формул по группе и прочих нефинансовых показателей, плюс у меня должна быть разбивка по подразделениям, его я в аналитику не добавлял, чтобы сэкономить место, а указал в Модели, подразделения выводил в колонках, кстати сразу скажу косяк или не косяк 1С но, если выводить Подразделения в строках как группировку (в данном случае Подразделение это измерение), то итоги по этой группировке не СЧИТАЮТСЯ (ОЧЕНЬ НЕ УДОБНО), если группировка многоуровневая, поэтому пришлось в колонки ставить. Все делал на конфигурации 1С:Комплексная автоматизация 2 (2.4.6.175), с ERP похожа. Производительность отчета стала в разы лучше (чем если делать 1 в 1, выводился около 5 минут), полученный отчет с расходами, доходами, выручкой, себестоимостью и прочих фин результатов выводится за несколько секунд. БДДС делал так же, там намного проще, так как нет кучи аналитик, основная проблема всех что нужно выводить много «ТИПОВ» анатик у статей.
(47) спасибо, вполне вариант
Большое спасибо Сергей за статью, очень ценная информация! И спасибо что делитесь своим опытом!
Также как у некоторых здесь, похожая проблема, есть БДДС с регламентированной структурой и кодами статей. Возможно не в таких масштабах проблема, статей не 300, а 80 (по крайней мере пока что). Что ждать от быстродействия? Быстродействие коснется только формирования бюджетных отчетов?
У Вас в статье очень удобно подобран пример, где легко напрашивается объединение статей ддс по смыслу для создания для них статьи бюджета. На практике что-то так не получается к сожалению…
Я правильно понимаю, если структура строго регламентированная, у нас есть 2 выхода, или 1 статья бюджета для 1 статьи ддс, или 1 статья бюджета для групп статей, по которым разбита структура БДДС? И что делать если группы с разной вложенностью? и достаточно различаются по смыслу?
Мой предшественник, который настраивал бюджет пошел в другую сторону)))
Создал только 2 статьи бюджета ( поступление ДС и расход ДС) и настроил у них аналитику на статьи ДДС
(49)
Тут сложно однозначно сказать — нужно тестировать на конкретном оборудовании. Но особенно нужно проверить как выполняется контроль лимитов заявок на расходование денежных средств.
(49)
Я правильно понимаю, если структура строго регламентированная, у нас есть 2 выхода, или 1 статья бюджета для 1 статьи ддс, или 1 статья бюджета для групп статей, по которым разбита структура БДДС? И что делать если группы с разной вложенностью? и достаточно различаются по смыслу?
С помощью сложной таблицы Вы можете сделать любую структуру, какой бы регламентированной она не была. Технически вы можете даже одну статью бюджета с аналитикой «Статьи ДДС» развернуть в нужную структуру. Поэтому прямой связи между количеством статей бюджетов и структурой отчета нет.
В общем случае, я бы рекомендовал следующий набор статей бюджетов:
+ Поступления по операционной деятельности
— Расходы по операционной деятельности
+ Поступления по финансовой деятельности
— Расходы по финансовой деятельности
+ Поступления по инвестиционной деятельности
— Расходы по инвестиционной деятельности
Это соответствует классическим разделам БДДС и такую структуру легко и удобно настраивать.
(49)
Создал только 2 статьи бюджета ( поступление ДС и расход ДС) и настроил у них аналитику на статьи ДДС
Тут сложно прокомментировать не зная конкретную структуру ваших данных. Обращу только внимание, что при правильном подборе аналитики можно построить практически любую структуру бюджета, т.к структура бюджета не зависит от статей бюджетов.
Так же обращаю Ваше внимание, что на Infostart Event 2019 я буду вести мастер-класс по практическим аспектам автоматизации бюджетирования: мы разберем эти и другие аспекты, посмотрим на практике как автоматизируются различные кейсы бюджетирования. Приходите, будет интересно)
Добрый день. Спасибо за статью. Только начинаю разбираться в принципах бюджетирования в ERP 2.4. Подобная информация так сказать «из первых уст» очень ценна.
Рассматриваю возможность применения ERP для наших бюджетных форм.
Можете подсказать, как настроить вид бюджета, где в таблице в колонках указаны месяцы, в конце нужно еще по кварталам и по году вывести итоги?
Большое спасибо за ответы, очень помогли.
Сразу не ответила, думала в процессе вопросы появятся, но вроде как обошлась.
(51) в колонки таблицы нужно перетащить год, потом прямо в год тащите квартал, а потом в квартал перетаскиваете месяц. Получается древовидная структура как бы
(51)
(51)
Можно месяца и кварталы поместить на одном уровне, т.е так:
Колонки
— Год
— — Месяц
— — Группа (в настройках ставим «не отображать»)
— — — Квартал
— — — Формула сумма по группе
Тогда получите итоги по месяцам, кварталам и общий итог по году.
Или как коллега в (53) советует — сделать дерево, но тогда месяца будут «вложены» в кварталы.
(54) + тут еще группы с итогами хорошо бы добавить 🙂 согласны?
(51) а хотя если данные за квартал и за год нужны в конце, то лучше не древовидной, а последовательно в колонки вывести. Попробовала, так нормально получается
(56) если нужны будут группы, суммы по кварталу и году так выведутся. Я группы делала, чтобы еще дополнительно выводить процент выполнения бюджета и отклонение
(57) и еще не забудьте внутрь периода сценарий кинуть и настроить. Совсем забыла про него упомянуть. В скрине для план факта. Если что-то одно нужно, то одно и добавляете или план, или факт
Спасибо за статью!
А как то можно получать фактические данные, но использовать их для плановых сценариев? Потому что произвольным запросом можно получить данные только для правил фактического или исполнения бюджета. А в экземпляре бюджета наоборот фактические и исполнение бюджета нельзя выбрать в качестве сценария, а только плановый сценарий. Некоторые данные для плана можно взять из регистров, а не вводить руками, но непонятно как это сделать. Именно чтобы сравнивать план полученный запросом и факт из регламентированного или оперативного учета.
(60) Для этого в правилах заполнения статьи бюджетов в экземпляре бюджетов ставите «Сценарий определяется в дополнительном отборе». Такая настройка позволит «переложить» данные из фактических данных (в т.ч. прошлого периода) в любой плановый сценарий. Порядок открытия настроечной формы указал в приложении.
(61) Да, спасибо!!! Так сделал.
Единственное что не пойму, это получается можно сделать только в сложных таблицах?
Я просто получаю данные с аналитикой по контрагенту. А в сложной таблицы при попытке добавить аналитику контрагенты, программа ругается, что:
Ошибка в ячейке [Поступления от реализации товаров, работ услуг.; Месяц]: запрещен ввод на уровне группировок
(62) Решить можно 2-мя вариантами:
1. Можно использовать простую таблицу — там заполнение настраивается аналогично, только нужно кликнуть по элементу «Статья бюджетов»
2. В сложной таблице в группировках выбрать суммирующую функцию по строкам. Т.е статью «Поступления от реализации товаров, работ услуг» выбираете на нижнем уровне группировок, а в промежуточных группировках делаете: «СУММА(<ссылка на вашу ячейку>)»
…
(50)
+ Поступления по операционной деятельности
— Расходы по операционной деятельности
+ Поступления по финансовой деятельности
— Расходы по финансовой деятельности
+ Поступления по инвестиционной деятельности
— Расходы по инвестиционной деятельности
Добрый день, Сергей,
правильно ли я понимаю, что создав для самого верхнего уровня папок статьи, далее вниз по уровням отчета (еще 4 шт) достаточно будет вложенно группировать аналитику (статьи ДДС или расходов) по сумме?
Добрый день!
Сергей, пожалуйста, подскажите. База ERP 2.4.6
В описании справочника «Аналитики статей бюджета» есть такой комментарий.
Важно: Не рекомендуется настраивать конфликтующие аналитики (пересекаются с общими измерениями — организация, подразделение и т.п.) для статей и показателей.
В этом случае настроенные правила заполнения аналитик будут конфликтовать с отборами по измерениям.
Для таких настроек и ситуаций, когда на статье нужны две аналитики одного типа (например, номенклатура выпуска и материал), необходимо создать новый вид аналитик с нужным типом и использовать в настройках его.
Тип аналитики может быть определен через общий дополнительный реквизит или сведение. В этом случае планирование и получение фактических данных будет выполнено в разрезе значений дополнительных реквизитов или сведений.
Споткнулись на, казалось бы, простом моменте. Нужен экземпляр бюджета для ввода плана по перемещениям — между двумя организациями в разрезе групп аналитического учета. Вид бюджета делается в разрезе организаций, добавляем вторую аналитику через дополнительный реквизит организации, тип дополнительного реквизита указан ссылка на справочник организации. В произвольных правилах получения факта указана ссылка на доп. реквизит. Отчет результат работы правил показывает всё корректно.
При попытке получение факта в экземпляре бюджета через указание в ячейке сценария фактические данные — пусто. Аналогичная пустота в отчете, но если нажать на расшифровку — данные показывает по правилам.
Если аналитику/правила переделать в разрезе складов всё работает корректно.
Есть ли какие то тонкие моменты для статье с разрезами аналитик по двум организациям?
(66) Добрый день. Раз показывает при расшифровке, но не показывает в таблице то могу порекомендовать попробовать «хранимый факт». Если не поможет — то без базы сложно сказать в чем может быть дело.
(65) Не очень понял, что такое «группировка аналитики по сумме». Но идея в общем случае верная — чем меньше статей и показателей с однородными правилами получения фактических данных — тем быстрее работают отчеты в подсистеме бюджетирования.
(67) Спасибо за ответ, наименование «ИсточникДанных» в настройках источника данных отличал, просмотрел)
Попробую допилить, чтобы запрос парсился и автоматом наименование вставало в поле.