1с бюджетирование ошибка в ячейке запрещен ввод на уровне группировок
Обновлено: 04.07.2024
Если для конфигурации 1С:Предприятия установлен режим автоматических блокировок, то уровень изоляции транзакции выбирается СУБД. В случае с MS SQL, это будет Repeatable read или Serializable уровни, то есть изоляция данных близка к максимальной. Это решает проблемы с корректностью данных, но может приводить к появлению блокировок на уровне СУБД при интенсивной работе пользователей. Поэтому, в 1С:Предприятии есть свой функционал работы с блокировками, который активизируется включением режима управляемых блокировок. В этом случае уровень изоляции транзакций для MS SQL будет Read commited. Платформа сама будет изолировать данные, не полагаясь на СУБД.
Включение режима управляемых блокировок происходит в свойствах конфигурации:
Также, режим блокировок может быть установлен для конкретных объектов конфигурации:
В случае, если для конфигурации в целом установлен Автоматический режим блокировок, то все транзакции по всем регистрам будут работать именно в автоматическом режиме, безотносительно того режима, что выставлен для объекта конфигурации. Если Управляемый - то аналогично, все транзакции будут в управляемом. Если же для конфигурации выставлен режим Автоматический и управляемый, то режим для каждого объекта будет определяться его настройками.
Для режима Автоматический и управляемый есть один момент. Транзакция, единая для пользователя может представлять собой несколько транзакций с точки зрения платформы. Например, интерактивное проведение документа по регистру делает две транзакции - запись самого документа, и внутри этой транзакции запись набора строк по регистру. В зависимости от режима управления блокировками для самого документа и двигаемого им регистра, возможны четыре ситуации:
- Режим документа Автоматический, режим регистра Автоматический -> запись по регистру в автоматическом режиме
- Режим документа Управляемый, режим регистра Управляемый-> запись по регистру в управляемом режиме
- Режим документа Автоматический, режим регистра Управляемый -> запись по регистру в автоматическом режиме
- Режим документа Управляемый, режим регистра Автоматический -> исключительная ситуация (ошибка)
Вопрос 06.59 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен автоматический режим управления транзакционными блокировками, а у регистра управляемый (в свойствах конфигурации используется вариант "Автоматический и управляемый"), то такое проведение приведет:
- к возникновению ошибочной ситуации
- вся транзакция будет выполнена в автоматическом режиме
- вся транзакция будет выполнена в управляемом режиме
Правильный ответ второй, определяем по первой транзакции, если автоматическая, то все автоматически.
Вопрос 06.60 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен управляемый режим управления транзакционными блокировками, а у регистра автоматический (в свойствах конфигурации используется вариант "Автоматический и управляемый"), то такое проведение приведет:
- к возникновению ошибочной ситуации
- вся транзакция будет выполнена в автоматическом режиме
- вся транзакция будет выполнена в управляемом режиме
Правильный ответ первый, определяем по первой транзакции, если управляемая, то ошибка.
Вопрос 06.61 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен автоматический режим управления транзакционными блокировками, а у регистра управляемый (в свойствах конфигурации используется вариант "Управляемый"), то такое проведение приведет:
Коллеги, я являюсь счастливым автоматизатором: сначала я разрабатывал бюджетирование в 1С:ERP2 и 1С:КА2, а теперь его внедряю. В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.
Сегодня поговорим и о самой распространенной на мой взгляд ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС». В базе это выглядит так:
Т.е каждому элементу справочника «статьи ДДС» мы прямо сопоставляем статью бюджета движения денежных средств:
Далее в правилах получения фактических данных каждой статьи бюджетов мы закономерно видим такую конструкцию:
Т.е в каждой статье бюджетов автоматизаторы в правиле получения фактических данных прописывали отбор по соответствующей статье ДДС. Во-первых, это очень трудоемко. Во-вторых, это приведет к неприятным последствиям в будущем, которые мы сейчас посмотрим. Есть и в-третьих – так мы лишаем нашего заказчика возможности самостоятельно редактировать бюджеты.
В данной модели при добавлении статьи ДДС нужно вводить новую статью бюджетов, настраивать отбор и модифицировать виды бюджетов. Т.е невозможно добавить статью ДДС в бюджеты без специалиста по автоматизации.
Теперь немного технических подробностей: разберем как получаются фактические данные в подсистеме «Бюджетирование». В зависимости от версии конфигурации и применяемого решения (КА или ERP) могут сработать следующие схемы:
1. Получение факта для каждой статьи отдельной компоновкой и выгрузка в сводную таблицу значений. Тут всем очевидно, что выполнение СКД в цикле – ничего хорошего не сулит. Особенно с ростом базы данных и количества статей бюджетов
2. Компоновка всех необходимы правил в одну СКД. При этом на основании уникальных отборов будут сформированы однотипные запросы, но с разными параметрами отборов, и объединены в рамках набор с типом «Объединение» одной СКД. Получится большая компоновка с кучей наборов в «Объединении». На практике так же выполняться будет неприятно.
Если вы указываете отбор для статьи бюджетов – то такая статья создаст новый источник, т.е новый набор в рамках набора «объединения», либо выполнится отдельной компоновки в зависимости от версии применяемого решения. При этом, если несколько статей бюджетов имеют одинаковый отбор в правилах фактических данных – то запрос скорее всего будет объединен. Для оптимального получения фактических данных лучше делать статьи бюджетов максимально укрупненными. Для приведенного выше примера оптимальная настройка выглядит так:
Таким образом, для этого примера, мы более чем в 2 раза сократили количество запросов для получения фактических данных, а соответственно более чем в 2 раза оптимизировали формирование бюджетных отчетов.
В такой модели, при правильной настройке фактических данных, мы получим систему бюджетирования, в которой пользователи самостоятельно могут добавлять «Статьи ДДС» в бюджетах. И в план-фактных отчетах такие добавленные статьи будут отображаться без изменения видов бюджетов, т.е автоматически. Как правильно настроить фактические данные для статей бюджетов мы рассмотрим в следующей статье.
Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим, а самые интересные проблемы разберем подробно в последующих статьях.
Данные в подсистему бюджетирования могут быть получены из подсистемы планирования, а могут быть введены вручную. Впоследствии эти данные могут быть отображены в отчетности.
И для ручного внесения данных, и для настройки отчетности, используется механизм Видов бюджетов.
Для настройки вида бюджета, необходимо зайти в меню Бюджетирование и планирование -> Настройки и справочники -> Виды бюджетов, и завести новую позицию. В новой форме бюджета, можно настроить его структуру, определить аналитику, а также указать, будет ли он использоваться только как отчет, или еще и дня ввода данных:
- Только одну таблицу
- По одной таблице каждого вида
- Произвольное количество таблиц каждого вида
Проверено. Верный ответ - третий, ограничений на таблицы нет. Создадим в одном бюджете разные таблицы (причем таблицу одного вида - дважды):
Система на это не ругается, и можно свободно построить отчет:
Вопрос 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С:ERP2 и 1С:КА2, а теперь его внедряю. В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.
Сегодня поговорим и о самой распространенной на мой взгляд ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС». В базе это выглядит так:
Т.е каждому элементу справочника «статьи ДДС» мы прямо сопоставляем статью бюджета движения денежных средств:
Далее в правилах получения фактических данных каждой статьи бюджетов мы закономерно видим такую конструкцию:
Т.е в каждой статье бюджетов автоматизаторы в правиле получения фактических данных прописывали отбор по соответствующей статье ДДС. Во-первых, это очень трудоемко. Во-вторых, это приведет к неприятным последствиям в будущем, которые мы сейчас посмотрим. Есть и в-третьих – так мы лишаем нашего заказчика возможности самостоятельно редактировать бюджеты.
В данной модели при добавлении статьи ДДС нужно вводить новую статью бюджетов, настраивать отбор и модифицировать виды бюджетов. Т.е невозможно добавить статью ДДС в бюджеты без специалиста по автоматизации.
Теперь немного технических подробностей: разберем как получаются фактические данные в подсистеме «Бюджетирование». В зависимости от версии конфигурации и применяемого решения (КА или ERP) могут сработать следующие схемы:
1. Получение факта для каждой статьи отдельной компоновкой и выгрузка в сводную таблицу значений. Тут всем очевидно, что выполнение СКД в цикле – ничего хорошего не сулит. Особенно с ростом базы данных и количества статей бюджетов
2. Компоновка всех необходимы правил в одну СКД. При этом на основании уникальных отборов будут сформированы однотипные запросы, но с разными параметрами отборов, и объединены в рамках набор с типом «Объединение» одной СКД. Получится большая компоновка с кучей наборов в «Объединении». На практике так же выполняться будет неприятно.
Если вы указываете отбор для статьи бюджетов – то такая статья создаст новый источник, т.е новый набор в рамках набора «объединения», либо выполнится отдельной компоновки в зависимости от версии применяемого решения. При этом, если несколько статей бюджетов имеют одинаковый отбор в правилах фактических данных – то запрос скорее всего будет объединен. Для оптимального получения фактических данных лучше делать статьи бюджетов максимально укрупненными. Для приведенного выше примера оптимальная настройка выглядит так:
Таким образом, для этого примера, мы более чем в 2 раза сократили количество запросов для получения фактических данных, а соответственно более чем в 2 раза оптимизировали формирование бюджетных отчетов.
В такой модели, при правильной настройке фактических данных, мы получим систему бюджетирования, в которой пользователи самостоятельно могут добавлять «Статьи ДДС» в бюджетах. И в план-фактных отчетах такие добавленные статьи будут отображаться без изменения видов бюджетов, т.е автоматически. Как правильно настроить фактические данные для статей бюджетов мы рассмотрим в следующей статье.
Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим, а самые интересные проблемы разберем подробно в последующих статьях.
Читайте также: