Как добавить новые ставки НДС (5% и 22%) в 1С 8.3 через конфигуратор, чтобы они появились в базе и корректно работали в документах?

← На главную

Проанализируем ситуацию: вы работаете в 1С:Предприятие 8.3, конфигурация не обновляется (нет подписки/средств), а законодательство и практика учета требуют использовать новые ставки НДС (например, 5% и 22%) — для этого подойдёт автоматизация добавления ставок НДС 5%, 7% и 22%. Вы попробовали «самый очевидный» шаг — добавили значения в метаданные Перечисление.СтавкаНДС — но в режиме «1С:Предприятие» ставки не появились, и документы по-прежнему не дают выбрать нужные проценты.

Разберем по шагам, почему так происходит, что означает «желтый квадратик» в конфигураторе, где на самом деле хранятся ставки в типовых конфигурациях, и какие варианты решения реально работают без «волшебной кнопки» обновления. Для этой задачи есть обработка добавления ставок НДС в УТ 10.3.

Почему добавление значения в перечисление не гарантирует появление ставки в базе

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

  1. не добавляет автоматически элемент в справочник ставок НДС;
  2. не меняет алгоритмы расчета НДС в документах (реализация, поступление, авансы, корректировки);
  3. не обновляет форматы печатных форм/счетов-фактур/книг покупок и продаж (поможет печатная форма счета с поддержкой НДС 22%), если они «зашиты» под старые ставки;
  4. не обновляет механизмы выгрузки/обмена, если они проверяют ставки по списку допустимых значений.

Поэтому то, что «в конфигураторе ставка добавилась», еще не означает, что «в базе она появилась» и тем более что она будет участвовать в расчетах и регламентированных отчетах.

Что означает «желтый квадратик» напротив ставок и почему у ваших значений его нет

Теперь выясним причину визуального отличия. В конфигураторе «желтые метки» рядом с некоторыми элементами обычно связаны с тем, что элемент является поставляемым/предопределенным (в терминологии 1С — «предопределенные данные» или «объекты, поставляемые в составе конфигурации»). Такие элементы создаются разработчиком и на них часто опираются алгоритмы: код может обращаться к ним как к «известным» значениям.

Важно понять практический смысл:

  1. Если конфигурация рассчитывает НДС, выбирает печатные форматы или делает проверки, она может обращаться к конкретным значениям «по имени/пути» через ПредопределенноеЗначение() или через обращения вида Перечисления.СтавкаНДС.НДС20 (в зависимости от реализации).
  2. Если вы добавили новое значение «вручную», оно не становится предопределенным автоматически и не участвует в существующих проверках, пока мы не внесем изменения в логику.
  3. Поэтому отсутствие «желтого квадратика» — это не «ошибка», а признак того, что элемент не является предопределенным/поставляемым.

Вывод: визуальная метка лишь подсказывает, что часть значений была заложена разработчиком и может быть жестко привязана к алгоритмам. Ваши новые значения — «чужие» для типовой логики, пока мы ее не расширим.

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

Очень частая причина «в конфигураторе добавила, а в базе не появилось» — не доведено обновление до конца на уровне базы данных. Разберем подробнее, что нужно сделать всегда, даже если вы уверены, что «сохранили».

  1. Сделаем резервную копию информационной базы. Это обязательное правило, потому что любые изменения конфигурации могут потребовать реструктуризацию.
  2. Откроем базу в Конфигураторе.
  3. Проверим, что изменения внесены в Перечисление.СтавкаНДС именно в «Конфигурации», а не только в «Конфигурации поставщика» (если база на поддержке).
  4. Выполним команду Обновить конфигурацию базы данных (обычно клавиша F7). Это критично: без этого новые метаданные могут не попасть в рабочую конфигурацию базы.
  5. Запустим базу в режиме «1С:Предприятие» хотя бы один раз под полными правами, чтобы отработали процедуры обновления (если они есть) и чтобы мы увидели реальное поведение в пользовательском режиме.

Проверка результата: если ваша конфигурация действительно использует перечисление в интерфейсе, то новые значения должны стать доступными. Но в большинстве бухгалтерских решений ставки выбираются не из перечисления, а из справочника (или из регистра сведений/настроек), поэтому даже после корректного обновления базы изменения могут быть «невидимыми» пользователю — и это нормально.

Определим, где именно в вашей конфигурации «живут» ставки НДС

Чтобы не «дорабатывать вслепую», сначала выясним архитектуру вашей базы. В 1С ставки НДС встречаются в нескольких местах:

  1. Справочник ставок: Справочник.СтавкиНДС (часто именно он используется в документах и номенклатуре).
  2. Перечисление ставок: Перечисление.СтавкаНДС или похожее (используется как «код ставки»/вид ставки/тип ставки).
  3. Регистры сведений: например, «Ставки НДС номенклатуры», «Настройки учета НДС», «История ставок» — зависит от конфигурации.
  4. Общие модули расчета: функции, которые вычисляют сумму НДС, выделяют «НДС в том числе», определяют ставку для печати и т.д.

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

Как запустить поиск в конфигураторе и найти все места, где используется ставка НДС

Вы спрашивали: «Где именно запустить поиск, чтобы просмотреть информацию?». Разберем по шагам, как это делается правильно, чтобы увидеть реальный объем работ.

  1. Откроем конфигурацию в конфигураторе и нажмем Ctrl + Shift + F (глобальный поиск по текстам конфигурации).
  2. По очереди выполним поиск по ключевым строкам:
    1. СтавкаНДС
    2. СтавкиНДС
    3. Перечисления.СтавкаНДС
    4. Справочники.СтавкиНДС
    5. НДС22, 5%, 22% (если где-то уже упоминали новые ставки)
  3. Посмотрим результаты: нас интересуют не только модули, но и:
    1. формы документов (проверки при выборе ставки);
    2. запросы (отборы по ставкам, группировки книг продаж/покупок);
    3. движения документов (регистры НДС);
    4. общие модули (функции расчета и печати);
    5. правила обмена (если есть интеграции или выгрузка для внешних систем).

Дополнительно используем «поиск ссылок» (если он доступен для вашего действия): выделим объект метаданных (например, Перечисление.СтавкаНДС) и выполним поиск его использования в конфигурации. Тогда мы увидим, какие реквизиты и алгоритмы завязаны именно на перечисление.

Ожидаемый результат анализа: чаще всего вы обнаружите, что документы выбирают ставку не из перечисления напрямую, а через элемент справочника (или настройку), а перечисление используется как «вид» внутри элемента справочника. Это и объясняет, почему изменения «в перечислении» не дали эффекта «в документах».

Решение №1 (самое простое): добавить ставки не в перечисление, а в справочник «Ставки НДС»

Рассмотрим подробнее вариант, который часто срабатывает без программирования: если в вашей конфигурации есть справочник ставок НДС, попробуем действовать «по прикладному», а не «по метаданным».

Что делаем:

  1. В режиме «1С:Предприятие» найдем справочник ставок. Обычно он называется «Ставки НДС» и расположен в разделах учета налогов/настроек.
  2. Создадим новые элементы ставок: «5%», «22%» (а также, если конфигурация требует, расчетные варианты типа «22/122» для «НДС в том числе»).
  3. Заполним реквизиты ставки:
    1. числовое значение процента;
    2. вид ставки (если выбирается из Перечисление.СтавкаНДС или отдельного перечисления «вид ставки»);
    3. признаки «НДС включен/не включен» — если это реализовано через отдельные поля или тип ставки;
    4. период действия — если ставки ведутся «историей».
  4. Проверим, появилась ли ставка в документах реализации/поступления.

Если ставка в справочнике создается и выбирается в документах, это уже половина успеха. Но не спешим радоваться: дальше нужно проверить, что сумма НДС считается корректно и что регистры НДС принимают движения без ошибок.

Проверка на практике:

  1. Создадим тестовый документ реализации с суммой, например 10 000 без НДС, и ставкой 22% — ожидаем НДС 2 200.
  2. Создадим тестовый документ с суммой «включая НДС» (если у вас такой режим) и ставкой 22% — проверим «выделение НДС».
  3. Проведем документы и убедимся, что нет сообщений об ошибках «ставка не поддерживается».

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

Решение №2: корректно «внедряем» новые ставки в логику конфигурации (через поиск и доработки)

Это тот вариант, о котором вам и написали на форуме: «поиск покажет, сколько работы предстоит». Разберем по шагам, что именно обычно приходится дописывать, чтобы ставка была не просто «в списке», а реально работала во всех местах учета.

Наша задача состоит из трех больших частей:

  1. Данные: чтобы ставка существовала там, откуда ее выбирает пользователь (справочник/настройки/регистры).
  2. Алгоритмы: чтобы расчет суммы НДС, выделение НДС и округления работали для новых процентов.
  3. Проверки и представления: чтобы не ломались печать, выгрузки, контрольные соотношения, отборы и условия в запросах.

Дальше действуем методично.

Шаг 1. Находим «точку истины», откуда документы берут ставку

С помощью глобального поиска (Ctrl+Shift+F) находим:

  1. Реквизиты табличных частей документов типа «СтавкаНДС» и смотрим их тип:
    1. если тип ПеречислениеСсылка.СтавкаНДС — документы используют перечисление напрямую;
    2. если тип СправочникСсылка.СтавкиНДС — документы используют справочник;
    3. если тип составной или «вид ставки» — потребуется сопоставление.
  2. Формы документов: часто проверка допустимых ставок стоит именно в обработчиках формы (при изменении ставки или при проведении).
  3. Общие модули: функции типа «ПолучитьСтавкуНДС…», «РассчитатьНДС…», «СтавкаНДСДляПечати…».

По итогам этого шага у нас появляется список мест, где новые ставки надо поддержать.

Шаг 2. Добавляем новые ставки как предопределенные (если конфигурация на них завязана)

Если вы нашли в коде обращения к ставкам через ПредопределенноеЗначение() (или функции БСП для получения предопределенных элементов), это сигнал: конфигурация ожидает, что ставка будет существовать как «известный объект».

Тогда действуем так:

  1. Если ставка хранится в перечислении — добавляем значение в Перечисление.СтавкаНДС (вы это уже сделали), но дальше обновляем логику, чтобы новые значения учитывались в ветвлениях.
  2. Если ставка хранится в справочнике — добавляем (или создаем программно) элемент в Справочник.СтавкиНДС. В некоторых конфигурациях ставки поставляются как предопределенные элементы справочника — тогда просто «ручного» создания недостаточно, нужно обеспечить стабильный способ получения ссылки.

В типовых подходах для надежного получения ссылок часто используют предопределенные данные и обращаются к ним через ПредопределенноеЗначение(). Если вы внедряете новые ставки сами, удобнее сделать так, чтобы они создавались автоматически при обновлении ИБ (тогда не придется «ловить» базы, где ставки забыли завести).

Шаг 3. Добавляем автоматическое создание ставок при обновлении информационной базы

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

Ниже пример «скелета» кода. Его нужно адаптировать под реальные реквизиты вашего справочника ставок (названия полей в разных конфигурациях отличаются), но принцип останется одинаковым: найти — если нет, создать — заполнить — записать.


Процедура ОбеспечитьНаличиеСтавокНДС() Экспорт

	// Пример для случая, когда ставки НДС хранятся в справочнике "СтавкиНДС".
	// Реквизиты справочника в вашей конфигурации могут называться иначе — проверим в метаданных.

	ДобавитьСтавкуЕслиНет("НДС 5%", 5);
	ДобавитьСтавкуЕслиНет("НДС 22%", 22);

	// Если конфигурации нужны расчетные ставки "в том числе":
	// ДобавитьСтавкуЕслиНет("НДС 22/122", 22);

КонецПроцедуры

Процедура ДобавитьСтавкуЕслиНет(НаименованиеСтавки, Процент) Экспорт

	Запрос = Новый Запрос;
	Запрос.Текст =
	"ВЫБРАТЬ
	|	СтавкиНДС.Ссылка КАК Ссылка
	|ИЗ
	|	Справочник.СтавкиНДС КАК СтавкиНДС
	|ГДЕ
	|	СтавкиНДС.Наименование = &Наименование";

	Запрос.УстановитьПараметр("Наименование", НаименованиеСтавки);

	Результат = Запрос.Выполнить().Выбрать();
	Если Результат.Следующий() Тогда
		Возврат;
	КонецЕсли;

	НовыйЭлемент = Справочники.СтавкиНДС.СоздатьЭлемент();
	НовыйЭлемент.Наименование = НаименованиеСтавки;

	// ВАЖНО: названия реквизитов могут отличаться:
	// Например: "Ставка", "Процент", "Размер", "СтавкаНДСПроцент".
	// Проверим в конфигураторе и подставим реальные.
	Если НовыйЭлемент.Метаданные().Реквизиты.Найти("Процент") <> Неопределено Тогда
		НовыйЭлемент.Процент = Процент;
	КонецЕсли;

	// Если используется перечисление вида ставки:
	// НовыйЭлемент.ВидСтавкиНДС = Перечисления.СтавкаНДС.НДС5; // пример
	// Подставим реальное имя значения перечисления.

	НовыйЭлемент.Записать();

КонецПроцедуры

Что важно в этом подходе:

  1. Мы не рассчитываем, что пользователь «сам все заведет правильно».
  2. Мы делаем механизм, который одинаково работает на всех копиях базы (тест/рабочая/восстановленная).
  3. Мы получаем управляемый процесс внедрения ставок даже без официального обновления.

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

Шаг 4. Обновляем расчет НДС в документах и общих модулях

Даже если ставка появилась в выборе, расчет может «упасть» или дать неверные суммы, если где-то есть жесткие условия вроде: «если ставка 10 или 20 — считаем так, иначе — исключение». Поэтому посмотрим, где чаще всего ломается логика, и что нужно проверить.

Типовые места риска:

  1. Ветвления по значениям ставки: Если ... ИначеЕсли ... с перечислением допустимых ставок.
  2. Функции выделения НДС «в том числе», где коэффициент задан фиксированно (например, 20/120).
  3. Печатные формы, где «ставка для печати» формируется по таблице соответствий.
  4. Запросы к регистрам НДС, где отбор идет по конкретным значениям ставки.

Что делаем вместе:

  1. Глобальным поиском находим выражения с «20/120», «10/110», «18/118» и аналогичные.
  2. Добавляем поддержку новых коэффициентов (например, для «в том числе» 22% коэффициент будет 22/122).
  3. Находим функции, которые возвращают «значение ставки для выгрузки/печати», и расширяем их, чтобы они корректно отдавали «5», «22» и «22/122».

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

Шаг 5. Проверяем движения по регистрам и контрольные механизмы

Теперь посмотрим глубже: НДС — это не только расчет суммы в строке документа, но и движение в регистрах учета НДС, книги покупок/продаж, счета-фактуры, авансы. Даже если вы «не сдаете декларацию из 1С», регистры все равно могут использоваться для формирования счетов-фактур, сверок и внутреннего контроля.

Поэтому обязательно проверяем:

  1. Проведение документа с новой ставкой без ошибок.
  2. Корректное заполнение реквизитов строк (сумма без НДС, сумма НДС, сумма с НДС).
  3. Отсутствие ошибок «ставка не поддерживается» в обработчиках проведения и в подписках на события.
  4. Работу печатных форм документов реализации/счета-фактуры (хотя бы визуально по значениям ставки и суммам).

Практический лайфхак: заведем отдельного контрагента «Тест НДС», сделаем 2–3 тестовых документа, и будем ими гонять проверки после каждой доработки. Так мы быстрее поймаем место, где ставка «не пролезает».

Решение №3: использовать расширение конфигурации, чтобы не ломать типовую поддержку

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

В этом случае полезно рассмотреть расширение:

  1. Добавляем/переопределяем необходимые процедуры и функции расчета в расширении.
  2. Подключаемся к событиям (например, при проведении документов) и корректируем расчет/проверки, не меняя основной код.
  3. Если нужно — добавляем обработку «обеспечить наличие ставок» также из расширения.

Плюсы подхода:

  1. Минимально вмешиваемся в типовую конфигурацию.
  2. Проще контролировать и переносить доработки.
  3. Меньше риск повредить критические механизмы учета.

Минусы:

  1. Не все можно «переопределить» расширением, если логика жестко завязана на типовые предопределенные данные.
  2. Иногда приходится все равно менять основную конфигурацию (например, если нужные места закрыты и не расширяются).

Почему «просто добавить ставки» часто превращается в большой проект

Теперь объясним, почему на форуме вам написали, что работы много. В типовой конфигурации НДС — это целый контур: документы, счета-фактуры, книги, раздельный учет, авансы, корректировки, проверки, печать, обмены. Ставка участвует в десятках мест, и если где-то осталось условие «разрешены только старые ставки», система начнет либо блокировать ввод, либо считать неправильно.

Поэтому правильная стратегия такая:

  1. Сначала определить, где ставка хранится и откуда выбирается.
  2. Затем обеспечить наличие ставок в данных (справочник/регистр/настройки).
  3. Потом пройти по всем найденным местам использования и расширить условия/соответствия.
  4. После — протестировать типовые сценарии (реализация, поступление, аванс, возврат/корректировка, «в том числе НДС»).

Так мы не будем «тыкаться» в случайные ошибки, а системно доведем поддержку ставок до рабочего состояния.

Мини-чек-лист диагностики: почему ставки не появились в пользовательском режиме

Соберем короткий, но практичный список причин и проверок. Пройдемся по нему вместе:

  1. Не обновили конфигурацию базы данных после правок (нужно выполнить обновление конфигурации БД).
  2. Правили не ту ветку (например, смотрели «Конфигурацию», а обновляется «Конфигурация поставщика» или наоборот — при поддержке это бывает важно).
  3. Документы не используют перечисление, а берут ставки из справочника — тогда перечисление менять бессмысленно без синхронизации данных.
  4. Есть жесткие проверки в форме/проведении, которые отсекают новые значения.
  5. Ставка добавлена, но нет расчетного варианта (например, нужно не только «22%», но и «22/122»).
  6. Ставка есть, но не применяется по умолчанию (в номенклатуре/настройках учета/договорах контрагентов стоит старая ставка).

Если последовательно пройти этот чек-лист, обычно становится понятно, где именно «узкое место» в конкретной базе.

Что делать, если отчетность сдаете не из 1С, а через Контур

Выясним важный момент из обсуждения: вы сдаете отчетность через Контур, поэтому «декларация в 1С» вам не критична. Это действительно снижает требования к части регламентированных отчетов, но не отменяет потребность в корректном расчете в первичных документах.

Даже если декларация не формируется в 1С, вам обычно нужны:

  1. корректные счета-фактуры (печатные формы, реквизиты, ставка);
  2. корректные суммы НДС в реализации/поступлении;
  3. корректные проводки и регистры (чтобы учет сходился и не «плыл» НДС в оборотке).

Поэтому мы все равно ориентируемся на то, чтобы ставка работала полноценно в документах и расчетах.

Итоговая стратегия: как быстрее всего довести базу до рабочего состояния без официального обновления

Сведем все в понятный план действий, который можно выполнять по шагам, фиксируя результат после каждого шага.

  1. Сделаем резервную копию.
  2. Проверим, обновили ли конфигурацию базы данных после внесения изменений.
  3. Определим источник ставок (справочник/перечисление/регистр) через глобальный поиск.
  4. Добавим ставки в правильное место данных (обычно справочник «Ставки НДС»), при необходимости обеспечим автосоздание через код.
  5. Расширим алгоритмы расчета и проверок в документах и общих модулях, чтобы новые ставки не блокировались и считались корректно.
  6. Протестируем 2–3 типовых сценария на тестовых документах и убедимся, что проведение и суммы корректны.
  7. Зафиксируем изменения (описание доработок, список затронутых объектов), чтобы в будущем можно было восстановить логику или перенести в расширение.

Главный вывод: добавление ставок НДС «вручную через конфигуратор» — это не один объект и не одна галочка. Нам нужно совместить данные (где ставка хранится), алгоритмы (как она считается) и проверки (где она разрешена). Именно поэтому такая работа часто оценивается дорого: объем зависит от того, насколько глубоко конфигурация завязана на предопределенные ставки и типовые механизмы НДС.

Информация носит справочный характер.

← На главную