1с бюджетирование ошибка в ячейке запрещен ввод на уровне группировок

Обновлено: 04.07.2024

Если для конфигурации 1С:Предприятия установлен режим автоматических блокировок, то уровень изоляции транзакции выбирается СУБД. В случае с MS SQL, это будет Repeatable read или Serializable уровни, то есть изоляция данных близка к максимальной. Это решает проблемы с корректностью данных, но может приводить к появлению блокировок на уровне СУБД при интенсивной работе пользователей. Поэтому, в 1С:Предприятии есть свой функционал работы с блокировками, который активизируется включением режима управляемых блокировок. В этом случае уровень изоляции транзакций для MS SQL будет Read commited. Платформа сама будет изолировать данные, не полагаясь на СУБД.

Включение режима управляемых блокировок происходит в свойствах конфигурации:

Также, режим блокировок может быть установлен для конкретных объектов конфигурации:

В случае, если для конфигурации в целом установлен Автоматический режим блокировок, то все транзакции по всем регистрам будут работать именно в автоматическом режиме, безотносительно того режима, что выставлен для объекта конфигурации. Если Управляемый - то аналогично, все транзакции будут в управляемом. Если же для конфигурации выставлен режим Автоматический и управляемый, то режим для каждого объекта будет определяться его настройками.

Для режима Автоматический и управляемый есть один момент. Транзакция, единая для пользователя может представлять собой несколько транзакций с точки зрения платформы. Например, интерактивное проведение документа по регистру делает две транзакции - запись самого документа, и внутри этой транзакции запись набора строк по регистру. В зависимости от режима управления блокировками для самого документа и двигаемого им регистра, возможны четыре ситуации:

  1. Режим документа Автоматический, режим регистра Автоматический -> запись по регистру в автоматическом режиме
  2. Режим документа Управляемый, режим регистра Управляемый-> запись по регистру в управляемом режиме
  3. Режим документа Автоматический, режим регистра Управляемый -> запись по регистру в автоматическом режиме
  4. Режим документа Управляемый, режим регистра Автоматический -> исключительная ситуация (ошибка)

Вопрос 06.59 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен автоматический режим управления транзакционными блокировками, а у регистра управляемый (в свойствах конфигурации используется вариант "Автоматический и управляемый"), то такое проведение приведет:

  1. к возникновению ошибочной ситуации
  2. вся транзакция будет выполнена в автоматическом режиме
  3. вся транзакция будет выполнена в управляемом режиме

Правильный ответ второй, определяем по первой транзакции, если автоматическая, то все автоматически.

Вопрос 06.60 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен управляемый режим управления транзакционными блокировками, а у регистра автоматический (в свойствах конфигурации используется вариант "Автоматический и управляемый"), то такое проведение приведет:

  1. к возникновению ошибочной ситуации
  2. вся транзакция будет выполнена в автоматическом режиме
  3. вся транзакция будет выполнена в управляемом режиме

Правильный ответ первый, определяем по первой транзакции, если управляемая, то ошибка.

Вопрос 06.61 экзамена 1С:Профессионал по платформе. При проведении документа по какому-либо регистру в случае если у документа установлен автоматический режим управления транзакционными блокировками, а у регистра управляемый (в свойствах конфигурации используется вариант "Управляемый"), то такое проведение приведет:

Коллеги, я являюсь счастливым автоматизатором: сначала я разрабатывал бюджетирование в 1С:ERP2 и 1С:КА2, а теперь его внедряю. В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.

Сегодня поговорим и о самой распространенной на мой взгляд ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС». В базе это выглядит так:


Т.е каждому элементу справочника «статьи ДДС» мы прямо сопоставляем статью бюджета движения денежных средств:


Далее в правилах получения фактических данных каждой статьи бюджетов мы закономерно видим такую конструкцию:


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

В данной модели при добавлении статьи ДДС нужно вводить новую статью бюджетов, настраивать отбор и модифицировать виды бюджетов. Т.е невозможно добавить статью ДДС в бюджеты без специалиста по автоматизации.

Теперь немного технических подробностей: разберем как получаются фактические данные в подсистеме «Бюджетирование». В зависимости от версии конфигурации и применяемого решения (КА или ERP) могут сработать следующие схемы:

1. Получение факта для каждой статьи отдельной компоновкой и выгрузка в сводную таблицу значений. Тут всем очевидно, что выполнение СКД в цикле – ничего хорошего не сулит. Особенно с ростом базы данных и количества статей бюджетов

2. Компоновка всех необходимы правил в одну СКД. При этом на основании уникальных отборов будут сформированы однотипные запросы, но с разными параметрами отборов, и объединены в рамках набор с типом «Объединение» одной СКД. Получится большая компоновка с кучей наборов в «Объединении». На практике так же выполняться будет неприятно.

Если вы указываете отбор для статьи бюджетов – то такая статья создаст новый источник, т.е новый набор в рамках набора «объединения», либо выполнится отдельной компоновки в зависимости от версии применяемого решения. При этом, если несколько статей бюджетов имеют одинаковый отбор в правилах фактических данных – то запрос скорее всего будет объединен. Для оптимального получения фактических данных лучше делать статьи бюджетов максимально укрупненными. Для приведенного выше примера оптимальная настройка выглядит так:


Таким образом, для этого примера, мы более чем в 2 раза сократили количество запросов для получения фактических данных, а соответственно более чем в 2 раза оптимизировали формирование бюджетных отчетов.

В такой модели, при правильной настройке фактических данных, мы получим систему бюджетирования, в которой пользователи самостоятельно могут добавлять «Статьи ДДС» в бюджетах. И в план-фактных отчетах такие добавленные статьи будут отображаться без изменения видов бюджетов, т.е автоматически. Как правильно настроить фактические данные для статей бюджетов мы рассмотрим в следующей статье.

Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим, а самые интересные проблемы разберем подробно в последующих статьях.

Данные в подсистему бюджетирования могут быть получены из подсистемы планирования, а могут быть введены вручную. Впоследствии эти данные могут быть отображены в отчетности.
И для ручного внесения данных, и для настройки отчетности, используется механизм Видов бюджетов.
Для настройки вида бюджета, необходимо зайти в меню Бюджетирование и планирование -> Настройки и справочники -> Виды бюджетов, и завести новую позицию. В новой форме бюджета, можно настроить его структуру, определить аналитику, а также указать, будет ли он использоваться только как отчет, или еще и дня ввода данных:


  1. Только одну таблицу
  2. По одной таблице каждого вида
  3. Произвольное количество таблиц каждого вида

Проверено. Верный ответ - третий, ограничений на таблицы нет. Создадим в одном бюджете разные таблицы (причем таблицу одного вида - дважды):


Система на это не ругается, и можно свободно построить отчет:


Вопрос 3.16 экзамена 1С:Профессионал по ERP Управление предприятием 2.0. При настройке вида бюджета с использованием типа таблицы "Показатели в колонках" статьи бюджета могут размещаться в:

  1. В колонках таблицы
  2. В строках таблицы
  3. В ячейках таблицы
  4. Варианты 1 и 2
  5. Варианты 1 и 2 и 3

Проверено. Верный ответ - первый. Само определение простой таблицы с показателями в колонках говорит о том, что показатели (= статьи) пойдут в колонках, а аналитика пойдет в строках:



Она отобразится в бюджете вот так, со статьями в колонках:


  1. В колонках таблицы
  2. В строках таблицы
  3. В ячейках таблицы
  4. Варианты 1 и 2
  5. Варианты 1 и 2 и 3



  1. В колонках таблицы
  2. В строках таблицы
  3. В ячейках таблицы
  4. Варианты 1 и 2
  5. Варианты 1 и 2 и 3



  1. Выводить все значения аналитики, по которым есть остатки и обороты
  2. Отображать в отчете только определенные, фиксированные значения
  3. Использовать значение "Прочие значения" (по которому будут отображаться данные по незафиксированным в строке значениям аналитики)
  4. Варианты 1 и 2
  5. Варианты 2 и 3
  6. Варианты 1 и 2 и 3


  1. Выводить все значения аналитики, по которым есть остатки и обороты
  2. Отображать в отчете только определенные, фиксированные значения
  3. Использовать значение "Прочие значения" (по которому будут отображаться данные по незафиксированным в строке значениям аналитики)
  4. Варианты 1 и 2
  5. Варианты 2 и 3
  6. Варианты 1 и 2 и 3


  1. Вводится документ "План бюджета по сценарию"
  2. Вводится документ "Экземпляр бюджета"
  3. Плановые данные берутся из оперативного планирования (планы закупок, продаж и т.п.)
  4. Верны варианты 1 и 3
  5. Верны варианты 2 и 3
  6. Верны все варианты


  1. Статьям бюджетов
  2. Показателям бюджетов
  3. Нефинансовым показателям
  4. Верны варианты 1 и 2
  5. Верны варианты 1 и 3
  6. Верны все варианты

Проверено. Правильный ответ - первый. Хотя, на деле можно вводить данные по статьям и показателям. Для проверки, настроим сложную таблицу ввода бюджета:



Уже отсюда видно, что в колонке Месяц ячейки с типом данных "Нефинансовый показатель" не могут редактироваться (они белого цвета). На всякий случай, добавим напротив них в соседней колонке редактируемые поля. И проверим возможность ввода, создав экземпляр бюджета:


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


Коллеги, я являюсь счастливым автоматизатором: сначала я разрабатывал бюджетирование в 1С:ERP2 и 1С:КА2, а теперь его внедряю. В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2.

Сегодня поговорим и о самой распространенной на мой взгляд ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС». В базе это выглядит так:


Т.е каждому элементу справочника «статьи ДДС» мы прямо сопоставляем статью бюджета движения денежных средств:


Далее в правилах получения фактических данных каждой статьи бюджетов мы закономерно видим такую конструкцию:


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

В данной модели при добавлении статьи ДДС нужно вводить новую статью бюджетов, настраивать отбор и модифицировать виды бюджетов. Т.е невозможно добавить статью ДДС в бюджеты без специалиста по автоматизации.

Теперь немного технических подробностей: разберем как получаются фактические данные в подсистеме «Бюджетирование». В зависимости от версии конфигурации и применяемого решения (КА или ERP) могут сработать следующие схемы:

1. Получение факта для каждой статьи отдельной компоновкой и выгрузка в сводную таблицу значений. Тут всем очевидно, что выполнение СКД в цикле – ничего хорошего не сулит. Особенно с ростом базы данных и количества статей бюджетов

2. Компоновка всех необходимы правил в одну СКД. При этом на основании уникальных отборов будут сформированы однотипные запросы, но с разными параметрами отборов, и объединены в рамках набор с типом «Объединение» одной СКД. Получится большая компоновка с кучей наборов в «Объединении». На практике так же выполняться будет неприятно.

Если вы указываете отбор для статьи бюджетов – то такая статья создаст новый источник, т.е новый набор в рамках набора «объединения», либо выполнится отдельной компоновки в зависимости от версии применяемого решения. При этом, если несколько статей бюджетов имеют одинаковый отбор в правилах фактических данных – то запрос скорее всего будет объединен. Для оптимального получения фактических данных лучше делать статьи бюджетов максимально укрупненными. Для приведенного выше примера оптимальная настройка выглядит так:


Таким образом, для этого примера, мы более чем в 2 раза сократили количество запросов для получения фактических данных, а соответственно более чем в 2 раза оптимизировали формирование бюджетных отчетов.

В такой модели, при правильной настройке фактических данных, мы получим систему бюджетирования, в которой пользователи самостоятельно могут добавлять «Статьи ДДС» в бюджетах. И в план-фактных отчетах такие добавленные статьи будут отображаться без изменения видов бюджетов, т.е автоматически. Как правильно настроить фактические данные для статей бюджетов мы рассмотрим в следующей статье.

Также пишите в комментариях, какие темы по подсистеме «Бюджетирование» ERP 2 интересны Вам, с какими непонятными ситуациями сталкивались – рассмотрим, а самые интересные проблемы разберем подробно в последующих статьях.

Читайте также: