1с бюджетирование ошибка в ячейке запрещен ввод на уровне группировок
Правильный ответ третий. На итоги требование уникальности не распространяется.
Вопрос 07.22 экзамена 1С:Профессионал по платформе. Флаг "Первые 5 записей" на закладке "Дополнительно" конструктора запросов позволяет:
- Вывести в отчет первые 5 записей. Записи будут отобраны без учета правил упорядочивания, настроенных в конструкторе запросов
- Вывести в отчет первые 5 записей. Записи будут отобраны с учетом правил упорядочивания, настроенных в конструкторе запросов
Правильный ответ второй, порядок будет учтен.
Вопрос 07.23 экзамена 1С:Профессионал по платформе. Флаг "Для изменения" (в режиме автоматических транзакционных блокировок) на закладке "Дополнительно" конструктора запросов позволяет:
- Заблокировать на изменение данные указанных таблиц-источников при выполнении запроса (вне транзакции)
- Заблокировать на чтение данные указанных таблиц-источников в запросе (как вне, так и в рамках транзакции)
- Заблокировать данные указанных таблиц-источников на чтение (в рамках транзакции)
- Верны ответы 1 и 2
Правильный ответ третий. Блокировка снимается после завершения отрабатывающей транзакции.
Вопрос 07.24 экзамена 1С:Профессионал по платформе. При установке флага "Для изменения" (в режиме автоматических транзакционных блокировок) на закладке "Дополнительно" конструктора запросов происходят блокировки:
- На уровне таблиц базы данных
- На уровне записей таблиц базы данных
- В варианте файл-сервер - на уровне таблиц базы данных
- В варианте клиент-сервер - на уровне записей таблиц базы данных
- Верны ответы 3 и 4
Вопрос 07.25 экзамена 1С:Профессионал по платформе. При установке флага "Для изменения" (в режиме автоматических транзакционных блокировок) на закладке "Дополнительно" конструктора запросов будут блокироваться данные:
- Всех таблиц-источников в запросе
- Только виртуальных таблиц-источников в запросе
- Если список "Таблицы для изменения" - пуст, то всех таблиц, задействованных в запросе, иначе - только таблиц, указанных в списке
Правильный ответ третий, разбор в посте.
Вопрос 07.47 экзамена 1С:Профессионал по платформе. При попытке выполнить запрос с текстом "Выбрать * Из Справочник.Номенклатура", в случае если на записи справочника были определены ограничения на чтение (в соответствующей роли) произойдет следующее:
Здравствуйте! В 1С:ERP Управление предприятием 2 (2.1.3.169) на платформе 8.3 (8.3.7.1917) захотел я разобраться в блоке бюджетирования.
Там есть справочник Статьи бюджетов, а в нём правила получения фактических данных. Эти данные можно получить универсально через СКД запросик. Вот мой запрос:
В консоле запросов код отрабатывает правильно, результаты есть!
А для дальнейшей работы в справочнике надо нажать кнопку проверки "Результат работы правил" и тут - ни одной строки результата.
Куда копать или что почитать про универсальные получения данных из пользовательского режима?
Помогите плиз мне тоже.
Осваиваю получение факта через произвольные данные. Не отрабатывает ни один запрос который я ему даю.
Вот пример запроса:
ВЫБРАТЬ
ДвиженияДенежныхСредствОбороты.Подразделение,
ДвиженияДенежныхСредствОбороты.ПериодНеделя,
ДвиженияДенежныхСредствОбороты.ПериодДекада,
ДвиженияДенежныхСредствОбороты.ПериодМесяц,
ДвиженияДенежныхСредствОбороты.ПериодКвартал,
ДвиженияДенежныхСредствОбороты.ПериодПолугодие,
ДвиженияДенежныхСредствОбороты.ПериодГод,
ДвиженияДенежныхСредствОбороты.СуммаРеглОборот КАК СуммаРегл
ИЗ
РегистрНакопления.ДвиженияДенежныхСредств.Обороты(, , Авто, ) КАК ДвиженияДенежныхСредствОбороты
При проверке через "Результат работы правил" всегда пишет "Совместная группировка по периодам с другими выражениями запрещена"
(4) lm-alex, в общем мне ответили 1с-ники, изменил свой запрос в соответствии с ним:
//Начало Письма
Схема должна содержать поля:
• Период данных. Поля периода должны называться: Период, ПериодДень, ПериодНеделя…
• Сумма фактического оборота (остатка). Сумма может выбираться в исходной валюте, валюте управленческого учета или в валюте регламентированного учета. Поля должны соответственно называться: СуммаВВалюте, СуммаУпр, СуммаРегл. Если выбирается сумма в исходной валюте, то в схеме должно присутствовать поле Валюта.
Схема может содержать поля:
• Аналитики (Контрагент, Номенклатура, Касса…). Для данных полей должен быть указан Тип значения (см. скриншот) [скрина во вложение не было. ]
• Количество.
Для ограничения периода выбираемых данных использовать параметры НачалоПериода и КонецПериода.
Для примера настройку схемы источников данных можно посмотреть в макетах регистра сведений ПравилаПолученияФактаПоСтатьямБюджетов.
//Конец Письма
Судя по их письму и твоему запросу с ошибкой, тебе надо поменять Роль своих периодов. У меня всего один он, но я поставил роль своего не "Период", а "Без роли". Должно помочь. У меня запрос отрабатывает верно и все суммы выдаёт.
Далее, я брал из основной таблицы регистра данные, а не из Оборотов. Но тебе надо добавить реквизит Валюта. У меня он есть.
А вот если тебе понадобится расшифровывать твои суммы по Регистраторам, то надо добавить и реквизит Регистратор. Его в Оборотах точно нет.
Вот мой, работающий запрос:
В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.
Сегодня поговорим и о самой распространенной ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС».
ИМХО - главная сложность в перенавороченном механизме получения данных, строго последовательно.
Ну а добавить статью в бюджет можно и без автоматизаторов, не велика сложность. Наши пользователи освоили с первой попытки.
"Не знаешь как - спроси меня" (С)
1
В заголовке статьи указано, что Вы являлись разработчиком, а теперь внедряете. Я готов поработать совместно, если это окажет влияние на подсистему в будущих релизах и принесет бонусы заказчику.
Ради спортивного интереса - не готов.
Замеры могу предоставить только по ускоренной версии. Полагаю, что выгрузит в xml настройки тоже получится договориться.
(3) я писал в статье, что могу разобрать интересные случаи в последующих статьях для сообщества. Учтет это вендор или нет я прогнозировать не берусь.
Что касается формирования 12 часов - то я полагаю что скорее дело в неверной настройке, а не в коде. Перенастроить виды бюджетов как правило быстрее чем переписывать код подсистемы. Если вид бюджета не переписывался - то могу посмотреть на типовой как его можно было бы ускорить.
(4) Полагаю, не имеет смысла. Конкретная задача решена.
Расскажите, зачем там 2 алгоритма формирования "РассчитатьФактПоВидуБюджетаАльтернативный" и "РассчитатьФактПоВидуБюджета"? В моем случае результат в данных одинаковый, а у альтернативного варианта - производительность на порядок ниже. Да и в релизе только этот вариант используется.
Технические различия понятны по комментариям. На практике - зачем?
(5) Альтернативный механизм разрабатывался после моего ухода в апреле 2016 из 1С. В официальных публикациях нововведений на partners я не нашел связанных материалов. Посмотрел код и мой вывод: в альтернативном механизме все запросы к факту объединены в 1 СКД, что теоретически должно дать выигрыш в производительности. Однако применяется механизм СхемаЗапроса - по моим замерам далеко не быстрый механизм. Что в свою очередь ставит под вопрос выигрыш в производительности.
(8) Там с этим механизмом дополнительная куча колонок в результирующей таблице получается. Этот алгоритм в несколько раз увеличивает длительность выполнения запроса.
(11) дополнительные колонки могут существенно увеличить время выполнения только в случае если эти колонки включены в индекс таблицы значений и исть массовое добавление/удаление строк, либо на старой платформе - изменение значений этих колонок. Индексации таблицы факта я не нашел. Поэтому склоняюсь к варианту что заседление дает СхемаЗапроса.
(6) Я с вами! :) Много работы по текущим проектам - поэтому отвечаю не оперативно. Но отвечу обязательно!
Добрый день.
Я в отличии от Вас являюсь не автоматизатором, а пользователем 1С:ERP2, в связи с этим вопрос.
Мне тоже показалось подход 1-в-1 используемый моим коллегой очень трудоемким, и я ввел другой вид бюджета
с укрупненными статьями, и подробной разбивкой по аналитике. Вопрос в том, влечет-ли это какие-нибудь ограничения
при использовании бюджета для лимитирования в казначействе? Контроль суммы возможен только по статье бюджета,
или по аналитике тоже?
Контроль суммы возможен до аналитики. Уровень контроля настраивается в правилах лимита. Например, на статье бюджета 2 уровня аналитики: статья ДДС и доп.аналитика. Можно настроить что бы контроль был только до уровня статьи ДДС, а доп.аналитика использовалась только участниками процесса бюджетирования для план-факт анализа. Во вложении - пример настройки лимитов ДС, где выделено как установить нужный уровень аналитики. Лимиты ДС настраиваются в модели бюджетирования. Модели бюджетирования находятся в пункте меню "Бюджетирование и планирование" -> "Настройки и справочники" -> "Модели бюджетирования".
(10) Вопрос начинающего.
Позволяет ли встроенный функционал КА2.4 обеспечить лимитирование только по некоторой аналитике , указываемой пользователем интерактивно , например , в дополнительном реквизите документа " Заявка на расходование ДС" ?
можно ли обойтись в таком случае без дополнительного реквизита ?
(36) КА 2.4 ,
"Заявки на расходование ДС" составляют инициаторы ( ~ 100 чел) из разных подразделений организаций. Для каждого подразделения должен быть составлен некоторый бюджет в разрезе понятных для инициаторов статей.
Предполагается
связать справочник типовой конфигурации "Статьи бюджета" один в один с элементами условного справочника с названием "СтатьиПонятныеИнициаторам". Далее , в "Заявку на расходование ДС" добавить ДополнительныРеквизит с условным типом "СтатьиПонятныеИнициаторам".
Ну, и вопрос :
- как связать "статьи бюджета" со ""СтатьиПонятныеИнициаторам" ?
Дополнительно :
что такое "механизм "хранимого" факта" и как его включить в конфигурации ( на ИТС встретил только упоминание о нем )
Ну, и вопрос :
- как связать "статьи бюджета" со ""СтатьиПонятныеИнициаторам" ?
Дополнительно :
что такое "механизм "хранимого" факта" и как его включить в конфигурации ( на ИТС встретил только упоминание о нем )
Связывать статьи бюджета 1:1 со статьями "понятными" инициаторам - не лучшее решение. Статьи ДДС - понятны инициаторам? Можно ли статьи ДДС привести в понятный инициаторам вид?
Если отвечать на вопрос "можно ли связать" - ответ можно. Вариантов много, все упирается в имеющуюся в фактических данных аналитику. Т.е откуда в факт.данных будете брать "СтатьиПонятныеИнициаторам".
Хранимый факт - галка в правилах получения факта.
(38) Угу.
И 1:1 - плохо.
И лучше сделать понятными "Статьи ДДС", чем изобретать справочник "СтатьиПонятныеИнициаторам" .
И неоткуда брать факт.
Спасибо. Пойду на новый круг уговоров .
Я не выдумал этот пример.
Почитал Ваши статьи . Ну прям , хорошо.
Чем крупнее специалист , тем проще , яснее он излагает.
(15) (15) Сценарий - Фактические данные, В СКД простейший запрос в собственный регистр сведений на получение данных:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
ВыручкаПоДМС.Период КАК Период,
ВыручкаПоДМС.Организация КАК Организация,
ВыручкаПоДМС.Подразделение КАК Подразделение,
ВыручкаПоДМС.Выручка КАК СуммаРегл,
ВыручкаПоДМС.Выручка КАК СуммаУпр,
ВыручкаПоДМС.Выручка КАК СуммаВВалюте,
"Валюта" КАК Валюта,
"Инкассация" КАК ИсточникДанных
ИЗ
РегистрСведений.ВыручкаПоДМС КАК ВыручкаПоДМС
ГДЕ
ВыручкаПоДМС.Период МЕЖДУ &НачалоПериода И &КонецПериода
На первый взгляд в СКД все верно. Единственное - проверьте, указаны ли типы для полей СКД для организации и подразделения.
Пришлите скрин настройки вида бюджета и настроек отчета при формировании. Может ошибка не в СКД.
(18) Я так же пробовал схемы входящие в состав конфигурации, тоже не взлетело. Не могу понять этот феномен.
Добрый день! А можно ссылочку на эту статью? Тоже воюю с правильным получением факта, но ничего не выходит.
Подскажите, я так понимаю, факт получается только с помощью произвольных запросов? По данным Опер. учета или Регл. учета брать его не получится?
(24)
Спасибо, пойду штудировать статью.
Попробовала сделать и произвольным запросом, но пока без объединения, взяла простой запрос по РН Денежные средства (безналичные), однако, как и прежде в факт попадают данные по Заявкам на расходование ДС, по которым еще не проведено Списание безналичных ДС. Запнулась на этой ошибке и никак не могу ее понять и устранить.
Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим
Что делать, если структура ЦФО не совпадает ни с управленческой структурой предприятия, ни с бухгалтерской ?
Пилить свое ? Битфинанс ? Или можно как-то по типовому извратится ?
структура ЦФО не совпадает ни с управленческой структурой предприятия, ни с бухгалтерской ?
Пилить свое ? Битфинанс ? Или можно как-то по
Вполне решается типовыми средствами:
1. Добавляете доп.реквизит на справочник "Структура предприятия" - в этот доп.реквизит заполняете соответствующее ЦФО. В правилах факта указываете мэппинг аналитики ЦФО к доп.реквизиту ЦФО
2. Если структура ЦФО с управленческой структурой соотносится как многие ко многим, т.е в одном упр.подразделении может быть несколько ЦФО - то применяйте модернизированный вариант 1: доп.реквизит на документ. При включении хранимого факта (в ERP) доп.реквизиты регистраторов становятся доступными и можно настроить мэппинг аналитики к доп.реквизитам регистраторов.
доп.реквизит на справочник "Структура предприятия" - в этот доп.реквизит заполняете соответствующее ЦФО. В правилах факта указываете мэппинг аналитики ЦФО к доп.реквизиту
Так какой тип доп реквизита делать то ? Строку ? Так-то, по хорошему нормальный справочник нужен, дабы его могли ответственные пользователи редактировать, смотреть, и т.д. Или запилить справочник, включить его в состав доп реквизитов ?
у ? Так-то, по хорошему нормальный справочник нужен, дабы его могли ответственные пользователи редактировать, смотреть, и т.д. Или запилить справочник, включить его
А чем справочник доп.значений не подходит?
тем, что в нем кроме самого значения ничего не сохранить.
Хотелось бы отдельно взятую сущность, которую можно было бы потом более широко использовать, чем просто выбирать значения.
Но в целом, я идею понял, спасибо за ответ.
2. Если структура ЦФО с управленческой структурой соотносится как многие ко многим, т.е в одном упр.подразделении может быть несколько ЦФО - то применяйте модернизированный вариант 1: доп.реквизит на документ. При включении хранимого факта (в ERP) доп.реквизиты регистраторов становятся доступными и можно настроить мэппинг аналитики к доп.реквизитам регистраторов.
Подскажите, пожалуйста, в этом случае добавляем доп. реквизит в экзмепляр бюджета и во все документы факта, верно?
В правилах получения факта настраиваете заполнение аналитики из доп.реквизита.
Коллеги, добрый день.
А как быть с бюджетами, где строго регламентирована структура (300 строк), регламентированы коды статей.
Я не вижу в таком варианте не делать настройки иначе как статья бюджета = статья затрат. Более того, мне не везде статей затрат хватает, приходится по договорам бегать чтобы верно статью определить при сборе факта.
300 строк - высока вероятность проблем с производительностью. Лучше все таки подумать как выйти из положения с помощью доп.реквизитов на статьях затрат. Но если совсем не получается - используйте хранимый факт, что бы решить проблему с производительностью.
(34) Сергей, благодарю за Ваши полезные статьи.
Может подскажете, куда копать? вот если ситуация, как у aser1c (отношение статей ДДС к альтернативным N:N - бухгалтерские и управленческие), но надо еще по этим доп. реквизитам и Исполнение контролировать? :) Т.е. в правиле для исполнения - нет галки для хранения факта (все "на лету"). Реально ли как то решить по аналитике доп.реквизита документа? реально ли хотя бы решить произвольным запросом?
N:N - бухгалтерские и управленческие), но надо еще по этим доп. реквизитам и Исполнение контролировать? :) Т.е. в правиле для исполнения - нет галки
Обращение к доп.реквизитам документов возможно только в хранимых правилах. Иначе такой запрос по всем документам будет очень долго выполняться. Можно попробовать опереться на какую либо аналитику (сделки, подразделения) или сочетания (сделки + статьи ДДС и т.д.). Произвольным запросом задача решается, но опять же у меня есть обоснованные подозрения, что выполняться такой запрос будет очень долго. Что бы точнее подсказать опишите мне в личку что это за аналитика по которой нужно контролировать, тогда смогу более точный совет дать.
(46) стояла задача сделать Бюджет расходов и доходов, соответственно должны выводиться все статьи расходов с их аналитикой (у каждой статьи разная), по типу как работает отчет "Доходы и расходы" в типовой конфе. Так как у Статей бюджета все 6 аналитик, то пришлось подстраивать учет под это, т.е. у нас нет на статьях расходов более 6 вариантов аналитик (в принципе достаточно для учета, главное убедить пользователей). Справочник Статей расходов имеет около 350 статей, с определенной структурой, т.е. куча папок с разной степенью вложенности и выводить надо именно так в отчете. Я заводил Статью бюджета для каждой группы статей (папки), настраивал получение фактических данных с отбором Статей расходов "в группе" или "в группе из списка", у Статей бюджета у меня заполнены все 6 аналитик, как раз, чтобы выводить все возможные варианты Статей расходов, в итоге получилось около 25 статей бюджета с правильно настроенными фактическими данными, все остальное в структуре отчета можно решить через создание групп и формул по группе и прочих нефинансовых показателей, плюс у меня должна быть разбивка по подразделениям, его я в аналитику не добавлял, чтобы сэкономить место, а указал в Модели, подразделения выводил в колонках, кстати сразу скажу косяк или не косяк 1С но, если выводить Подразделения в строках как группировку (в данном случае Подразделение это измерение), то итоги по этой группировке не СЧИТАЮТСЯ (ОЧЕНЬ НЕ УДОБНО), если группировка многоуровневая, поэтому пришлось в колонки ставить. Все делал на конфигурации 1С:Комплексная автоматизация 2 (2.4.6.175), с ERP похожа. Производительность отчета стала в разы лучше (чем если делать 1 в 1, выводился около 5 минут), полученный отчет с расходами, доходами, выручкой, себестоимостью и прочих фин результатов выводится за несколько секунд. БДДС делал так же, там намного проще, так как нет кучи аналитик, основная проблема всех что нужно выводить много "ТИПОВ" анатик у статей.
Данные в подсистему бюджетирования могут быть получены из подсистемы планирования, а могут быть введены вручную. Впоследствии эти данные могут быть отображены в отчетности.
И для ручного внесения данных, и для настройки отчетности, используется механизм Видов бюджетов.
Для настройки вида бюджета, необходимо зайти в меню Бюджетирование и планирование -> Настройки и справочники -> Виды бюджетов, и завести новую позицию. В новой форме бюджета, можно настроить его структуру, определить аналитику, а также указать, будет ли он использоваться только как отчет, или еще и дня ввода данных:
- Только одну таблицу
- По одной таблице каждого вида
- Произвольное количество таблиц каждого вида
Проверено. Верный ответ - третий, ограничений на таблицы нет. Создадим в одном бюджете разные таблицы (причем таблицу одного вида - дважды):
Вопрос 3.16 экзамена 1С:Профессионал по ERP Управление предприятием 2.0. При настройке вида бюджета с использованием типа таблицы "Показатели в колонках" статьи бюджета могут размещаться в:
- В колонках таблицы
- В строках таблицы
- В ячейках таблицы
- Варианты 1 и 2
- Варианты 1 и 2 и 3
Проверено. Верный ответ - первый. Само определение простой таблицы с показателями в колонках говорит о том, что показатели (= статьи) пойдут в колонках, а аналитика пойдет в строках:
- В колонках таблицы
- В строках таблицы
- В ячейках таблицы
- Варианты 1 и 2
- Варианты 1 и 2 и 3
- В колонках таблицы
- В строках таблицы
- В ячейках таблицы
- Варианты 1 и 2
- Варианты 1 и 2 и 3
- Выводить все значения аналитики, по которым есть остатки и обороты
- Отображать в отчете только определенные, фиксированные значения
- Использовать значение "Прочие значения" (по которому будут отображаться данные по незафиксированным в строке значениям аналитики)
- Варианты 1 и 2
- Варианты 2 и 3
- Варианты 1 и 2 и 3
- Выводить все значения аналитики, по которым есть остатки и обороты
- Отображать в отчете только определенные, фиксированные значения
- Использовать значение "Прочие значения" (по которому будут отображаться данные по незафиксированным в строке значениям аналитики)
- Варианты 1 и 2
- Варианты 2 и 3
- Варианты 1 и 2 и 3
- Вводится документ "План бюджета по сценарию"
- Вводится документ "Экземпляр бюджета"
- Плановые данные берутся из оперативного планирования (планы закупок, продаж и т.п.)
- Верны варианты 1 и 3
- Верны варианты 2 и 3
- Верны все варианты
- Статьям бюджетов
- Показателям бюджетов
- Нефинансовым показателям
- Верны варианты 1 и 2
- Верны варианты 1 и 3
- Верны все варианты
Проверено. Правильный ответ - первый. Хотя, на деле можно вводить данные по статьям и показателям. Для проверки, настроим сложную таблицу ввода бюджета:
Уже отсюда видно, что в колонке Месяц ячейки с типом данных "Нефинансовый показатель" не могут редактироваться (они белого цвета). На всякий случай, добавим напротив них в соседней колонке редактируемые поля. И проверим возможность ввода, создав экземпляр бюджета:
В ячейки со статьями и показателями, можно вбить данные; в ячейки с нефинансовыми показателями - нельзя. В колонке Удельный вес, куда была добавлена возможность вносить редактируемые значения, цифры задать можно, но в движениях документа они не отразятся.
Т.е. нефинансовые показатели вводятся строго специализированным инструментом - формами ввода нефинансовых показателей.
В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2. Сегодня поговорим и о самой распространенной ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС».
Коллеги, я являюсь счастливым автоматизатором: сначала я разрабатывал бюджетирование в 1С:ERP2 и 1С:КА2, а теперь его внедряю. В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.
Сегодня поговорим и о самой распространенной на мой взгляд ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС». В базе это выглядит так:
Т.е каждому элементу справочника «статьи ДДС» мы прямо сопоставляем статью бюджета движения денежных средств:
Далее в правилах получения фактических данных каждой статьи бюджетов мы закономерно видим такую конструкцию:
Т.е в каждой статье бюджетов автоматизаторы в правиле получения фактических данных прописывали отбор по соответствующей статье ДДС. Во-первых, это очень трудоемко. Во-вторых, это приведет к неприятным последствиям в будущем, которые мы сейчас посмотрим. Есть и в-третьих – так мы лишаем нашего заказчика возможности самостоятельно редактировать бюджеты.
В данной модели при добавлении статьи ДДС нужно вводить новую статью бюджетов, настраивать отбор и модифицировать виды бюджетов. Т.е невозможно добавить статью ДДС в бюджеты без специалиста по автоматизации.
Теперь немного технических подробностей: разберем как получаются фактические данные в подсистеме «Бюджетирование». В зависимости от версии конфигурации и применяемого решения (КА или ERP) могут сработать следующие схемы:
1. Получение факта для каждой статьи отдельной компоновкой и выгрузка в сводную таблицу значений. Тут всем очевидно, что выполнение СКД в цикле – ничего хорошего не сулит. Особенно с ростом базы данных и количества статей бюджетов
2. Компоновка всех необходимы правил в одну СКД. При этом на основании уникальных отборов будут сформированы однотипные запросы, но с разными параметрами отборов, и объединены в рамках набор с типом «Объединение» одной СКД. Получится большая компоновка с кучей наборов в «Объединении». На практике так же выполняться будет неприятно.
Если вы указываете отбор для статьи бюджетов – то такая статья создаст новый источник, т.е новый набор в рамках набора «объединения», либо выполнится отдельной компоновки в зависимости от версии применяемого решения. При этом, если несколько статей бюджетов имеют одинаковый отбор в правилах фактических данных – то запрос скорее всего будет объединен. Для оптимального получения фактических данных лучше делать статьи бюджетов максимально укрупненными. Для приведенного выше примера оптимальная настройка выглядит так:
Таким образом, для этого примера, мы более чем в 2 раза сократили количество запросов для получения фактических данных, а соответственно более чем в 2 раза оптимизировали формирование бюджетных отчетов.
В такой модели, при правильной настройке фактических данных, мы получим систему бюджетирования, в которой пользователи самостоятельно могут добавлять «Статьи ДДС» в бюджетах. И в план-фактных отчетах такие добавленные статьи будут отображаться без изменения видов бюджетов, т.е автоматически. Как правильно настроить фактические данные для статей бюджетов мы рассмотрим в следующей статье.
Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим, а самые интересные проблемы разберем подробно в последующих статьях.
Читайте также: