Казначей проводит заявку на оплату, а система блокирует ее – превышен лимит по статье затрат. Через минуту выясняется: лимит на самом деле не превышен, просто данные разошлись после обновления. Такая ситуация возникает, когда контроль лимитов в «1С» переносят на новую версию без проверки остатков. Разберем, что меняется при переходе с версии 2.4 на 2.5, и как перенести правила без риска для текущих платежей.
Материал будет полезен финансовым директорам, сотрудникам казначейства и отделов бюджетирования, использующим «1С:ERP» или «1С:КА». Учтите важный технический нюанс: прямое обновление с редакции 2.4 до 2.6 невозможно, поэтому переход на версию 2.5 станет обязательным промежуточным шагом.
Что такое контроль лимитов и зачем в системе две версии алгоритма
Контроль лимитов в «1С:ERP» проверяет заявки на расход денег перед оплатой: хватает ли лимита по статье, подразделению или проекту. Если лимит превышен, система блокирует проведение документа или требует дополнительного согласования – в зависимости от настроенных правил.
С версии 2.5.18 доступен новый алгоритм расчета – Контроль лимитов 2.5. Он не просто ускоряет проверку: изменена сама логика хранения данных о лимитах.
| Понятие / документ | Что это означает для казначейства |
|---|---|
| Регистр «Лимиты по данным бюджетирования» | Отдельное хранилище плановых сумм лимитов, резервов по заявкам и фактического потребления – используется при каждой проверке заявки |
| Отчет «Лимиты по бюджетированию» | Показывает текущий остаток лимита по каждой аналитике – главный инструмент проверки корректности после перехода |
| Заявка на расходование ДС | Документ, который проходит проверку лимита в момент проведения |
| Вариант контроля лимитов по данным бюджетирования - «Контроль лимитов 2.4» и «Контроль лимитов 2.5» | Переключатель алгоритма в настройках бюджетирования – включается администратором базы |
Версия 2.5 хранит плановые суммы, резервы и фактическое потребление в отдельном регистре. Раньше система пересчитывала эти данные каждый раз при проверке. Теперь она берет готовые цифры из регистра – это и дает ускорение при обработке заявок.
Кто отвечает за контроль лимитов и кого затронет переход
-
Казначейство – проводит заявки на расход денег и первым видит последствия некорректного переноса лимитов.
-
Финансовый директор – утверждает бюджетные модели, на основе которых строится контроль расходов.
-
Администратор базы «1С» – технически переключает алгоритм и заполняет регистр лимитов при переходе.
-
Руководители подразделений – оформляют заявки на расход и первыми замечают, если лимит заблокировал платеж без реальной причины.
Небольшие компании иногда считают, что тема их не касается: «у нас лимиты настроены просто, по паре статей». Объем настроек не отменяет перехода – если в базе включена версия 2.4, отказ от нее в редакции 2.6 коснется всех, независимо от сложности правил.
Что изменилось в логике алгоритма 2.5
Новый алгоритм не просто быстрее – он по-другому обрабатывает граничные случаи, которые раньше вызывали путаницу.
-
Суммы сверх лимита теперь тоже расходуют лимит. В версии 2.4 превышение просто списывалось без контроля. В версии 2.5 сумма списывается, но лимит при этом используется – это меняет остаток для следующих заявок.
-
Платежные документы без заявок учитываются в лимите. Если платеж проведен напрямую, минуя заявку на расходование, версия 2.5 все равно учитывает эту сумму в использовании лимита.
-
Итоговая сумма считается по аналитикам платежного документа. Если аналитика платежа отличается от аналитики в заявке, система сторнирует использование по заявке и добавляет его по факту платежа.
-
Расчет хранится в отдельном регистре, а не пересчитывается на каждой проверке. Это и объясняет разницу в скорости между двумя версиями при большом объеме заявок.
Порядок перехода: что рекомендует сама фирма «1С»
Разработчик прямо указывает последовательность действий, и отступать от нее не стоит:
-
Создайте копию рабочей базы. Никаких изменений алгоритма в рабочей системе – только на копии.
-
Измените алгоритм контроля на копии. Переключатель находится в разделе «НСИ и администрирование» → «Настройка НСИ и разделов» → «Бюджетирование и планирование» → «Вариант контроля лимитов по данным бюджетирования».
-
Проверьте корректность остатков в отчете «Лимиты по бюджетированию». Сравните цифры до и после переключения – расхождения нужно разобрать до переноса в рабочую базу.
-
Только после проверки переводите рабочую базу на новый алгоритм.
Важная деталь: при включении версии 2.5 система сама предлагает заполнить регистр «Лимиты по данным бюджетирования» и обработать правила получения факта в фоновом режиме. Это заполнение проходит без контроля лимитов – то есть на этом шаге заявки не блокируются, что снижает риск случайной остановки платежей во время самого перехода.
Таблица ключевых отличий: версия 2.4 и версия 2.5
| Параметр | Версия 2.4 | Версия 2.5 |
|---|---|---|
| Хранение данных о лимитах | Пересчет при каждой проверке | Отдельный регистр с готовыми суммами лимитов, резервов и потребления |
| Учет сумм сверх лимита | Списываются без использования лимита | Списываются, но лимит при этом используется |
| Платежи без заявок | Не учитывались в использовании лимита | Учитываются в использовании лимита |
| Расхождение аналитик платежа и заявки | Не обрабатывалось отдельно | Сумма сторнируется по заявке и добавляется по факту платежа |
| Скорость проверки при большом объеме заявок | Ниже – за счет пересчета на каждой операции | Выше – за счет хранения готовых данных |
| Заполнение при первом включении | – | Происходит в фоновом режиме, без блокировки заявок |
Из таблицы понятно: версия 2.5 закрывает конкретные пробелы в контроле, которые раньше пропускали часть расходов мимо лимита – платежи без заявок, суммы сверх лимита.
Что перестанет работать, если остаться на старой версии
-
Проведение заявок по старым правилам станет невозможным после отказа от поддержки версии 2.4 в редакции 2.6.
-
Использование текущего алгоритма для новых расходных статей прекратится – новые правила лимитирования придется настраивать уже по логике версии 2.5.
-
Точность контроля останется на уровне версии 2.4 – платежи без заявок и превышения лимита продолжат проходить мимо контроля до момента перехода.
Это не повод для тревоги, а причина спланировать переход заранее – через копию базы, а не через рабочую систему в разгар отчетного периода.
Главные ошибки при миграции на новую версию
| Ошибка | Последствие | Как исправить |
|---|---|---|
| Переключили алгоритм прямо в рабочей базе | Заявки блокируются без понятной причины, казначейство теряет время на разбор | Менять алгоритм только на копии базы, согласно рекомендации «1С» |
| Не сравнили отчет «Лимиты по бюджетированию» до и после | Расхождения в остатках обнаруживаются только при блокировке реального платежа | Сравнить отчет построчно на копии базы перед переносом в прод |
| Не учли, что суммы сверх лимита теперь расходуют лимит | Остаток лимита оказывается меньше ожидаемого, платежи блокируются неожиданно | Пересчитать плановые остатки с учетом новой логики до перехода |
| Забыли про платежи без заявок | Часть исторических платежей начинает влиять на текущий остаток лимита | Проверить, как обрабатываются прямые платежи без заявок в вашей модели |
| Перешли в разгар месяца с открытыми заявками | Часть заявок обрабатывается по старой логике, часть – по новой | Планировать переход на границе отчетного периода |
| Не предупредили сотрудников, оформляющих заявки | Рост числа обращений «почему заблокировано» в первые дни после перехода | Провести короткий инструктаж перед переходом в рабочую базу |
| Не проверили правила лимитирования по каждой статье отдельно | Отдельные статьи бюджета остаются без корректного контроля | Пройтись по всем настроенным правилам лимитирования вручную |
Пошаговая инструкция перехода
-
Выгрузите и сверьте текущие правила лимитов. Зафиксируйте, какие статьи, подразделения и проекты сейчас контролируются.
-
Создайте копию базы и переключите алгоритм на ней. Следуйте прямой рекомендации разработчика – не трогайте рабочую систему на этом шаге.
-
Сравните отчет «Лимиты по бюджетированию» до и после. Любое расхождение разбирайте до переноса изменений в рабочую базу.
-
Протестируйте на реальных заявках минимум один расчетный период. Проведите несколько заявок с разными сценариями – включая суммы сверх лимита и платежи без заявок.
-
Переведите рабочую базу. Заполнение регистра лимитов пройдет в фоновом режиме без блокировки текущих заявок.
С чего начать прямо сейчас: откройте раздел «НСИ и администрирование» → «Настройка НСИ и разделов» → «Бюджетирование и планирование» и проверьте, какая функциональная опция сейчас включена – «Контроль лимитов 2.4» или «Контроль лимитов 2.5».
Слово эксперта
«Главная ошибка, которую мы видим при переходе на новый алгоритм – компании недооценивают изменение логики учета сумм сверх лимита. В версии 2.4 такие суммы просто проходили мимо контроля, а в версии 2.5 они начинают расходовать лимит. Если не пересчитать плановые остатки заранее, казначейство сталкивается с неожиданными блокировками платежей уже в первую неделю после перехода».
– Миненко Анастасия, ведущий аналитик по бюджетированию и казначейству «1С:ERP» в ГЭНДАЛЬФ
Нужна помощь с переходом на контроль лимитов 2.5?
Мы поможем перейти без блокировки текущих платежей:
-
выгрузим и сверим текущие правила контроля лимитов по всем статьям и подразделениям;
-
перенесем алгоритм на копии базы согласно рекомендации разработчика;
-
сравним отчет «Лимиты по бюджетированию» до и после переключения;
-
протестируем реальные заявки минимум за один расчетный период;
-
сопроводим первое закрытие периода на новом алгоритме.
Более 15 лет проектная команда ГЭНДАЛЬФ сопровождает технические миграции клиентов на новые версии платформы «1С» и конфигурации – включая настройку бюджетного контроля и казначейства.
Оставить заявкуЧасто задаваемые вопросы
Само заполнение регистра лимитов при включении версии 2.5 происходит в фоновом режиме, без контроля – значит, оно не блокирует заявки в процессе перехода. Но если плановые остатки не пересчитаны с учетом новой логики, отдельные платежи могут заблокироваться уже после перехода из-за изменившегося остатка лимита.
Основной инструмент – отчет «Лимиты по бюджетированию». Сравните его показания на копии базы до переключения алгоритма и после – расхождения по конкретным статьям укажут, что нужно пересчитать перед переносом в рабочую систему.
Уже утвержденные и проведенные заявки сохраняют свою историю. При переходе стоит обратить внимание на заявки в статусе «на согласовании» – их разумно завершить до переключения алгоритма, чтобы не разбираться с расчетом лимита по двум разным логикам одновременно.
Да, это одно из ключевых изменений версии 2.5: платежи, проведенные напрямую без формирования заявки на расходование, теперь тоже учитываются в использовании лимита. В версии 2.4 такие суммы контроль не затрагивал.
Формально можно оставаться на версии 2.4, пока она поддерживается в вашем релизе. Но как только компания примет решение переходить на редакцию 2.6, версия 2.5 станет обязательной – поэтому разумнее протестировать переход заранее, на копии базы, без спешки.
 1.png){kind=icon}
.png){kind=icon}