Цифровой рубль в 1С после 1 сентября: казначейство есть, кассы нет

1. Кому и что обязали

Дата одна, а законов два, и их постоянно путают. 282-ФЗ от 04.08.2026 «О цифровых валютах и цифровых правах» регулирует криптовалюту и на учёт в 1С почти не влияет: платить криптой внутри страны по-прежнему нельзя. Нас интересует 248-ФЗ от 23.07.2025: он вводит обязанность торговли принимать цифровой рубль (ЦР) и универсальный платёжный код (УПК) от НСПК.

Исключения: торговая точка с выручкой до 5 млн руб. в год и места без доступа к интернету. Ответственность идёт через закон о защите прав потребителей и ч. 4 ст. 14.8 КоАП: должностные лица 15–30 тыс. руб., юрлица 30–50 тыс. руб. Контролирует Роспотребнадзор, ожидаемый механизм проверок: контрольная закупка и жалоба покупателя.

Важная деталь про сроки. 24 августа Банк России выпустил информационное письмо: до 01.03.2027 к операторам по переводу денежных средств не будут применяться меры за неиспользование УПК. Адресат письма только банки. Обязанность магазина от готовности банка не зависит, послабление на торговлю не распространяется.

Тарифы платформы для бизнеса: до 31.12.2026 нули по всем операциям, с 01.01.2027 за приём оплаты (C2B) 0,3%, но не более 1500 руб. за перевод. Для сравнения, QR через СБП обходится от 0,4%, терминальный эквайринг 1,5–3%.

2. Что 1С успела к дате: официальный статус

Самый надёжный источник по типовым не форумы, а мониторинг законодательства на v8.1c.ru (карточка «Осуществление расчетов ЦР и внедрении универсального платежного кода»). Состояние на 4 сентября 2026:

Рис. 1. Релизы по 248-ФЗ относительно даты вступления: БП, УТ и ERP успели, Розница и УНФ вышли после 1 сентября, отдельное РМК не планируется

Две вещи бросаются в глаза. Розничные конфигурации выходят после даты вступления закона в силу, а отдельное РМК фирма 1С закрывать не собирается вовсе. То есть у части клиентов на 1 сентября касса физически не умела предложить ЦР, и никакой релиз это не исправит.

3. УТ 11.5.27.79: что внутри

Я выгрузил конфигурацию в XML (около 51 тысячи файлов) и прошёл поиском по «ЦифровогоРубля» и «ЦифровойРубль» по всем веткам метаданных. Картина оказалась неоднородной.

3.1. Казначейский контур: сделано добротно

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

Ключевой модуль ОбменСБанкамиЦифровойРубль разбирает выписку платформы Банка России. В нём зашиты реквизиты платформы и коды операций:

Функция БИКПлатформыЦифровогоРубля() Экспорт
	Возврат "044595002";
КонецФункции

Функция НомерСчетаПлатформыЦифровогоРубля() Экспорт
	Возврат "30000810945950000002";
КонецФункции

// Перевод от клиента-ФЛ клиенту-ЮЛ: розничная выручка
Функция ОперацияC2B() Экспорт
	Возврат "CTOB";
КонецФункции

Вывод: поступление от покупателя из выписки платформы УТ прочитать умеет. Осталось найти, откуда это поступление берётся на кассе.

3.2. Кассовый контур: пусто

Рис. 2. Упоминания цифрового рубля по веткам метаданных: казначейский контур заполнен, кассовый пуст полностью

Ноль в Documents означает ноль в ЧекККМ, ОперацияПоПлатежнойКарте, ОтчетБанкаПоОперациямЭквайринга и ПоступлениеБезналичныхДенежныхСредств. Ноль в Enums означает, что нового способа оплаты не появилось. Для честности: в 11.5.22.182 ЦР встречался в документах пятнадцать раз, но это были запросы печатных форм («если счёт цифровой, печатать идентификатор кошелька»), которые к 11.5.27.79 вынесли в общие модули печати.

Сравнение перечислений оплат между двумя релизами, между которыми пять месяцев:

Перечисление открывали, положили туда СБП и закрыли. Ни цифрового рубля, ни универсального кода НСПК, через который ЦР единственно и принимается. По комментариям коллег, в 11.5.27.81 в настройках терминала появился УПК, но способ оплаты «цифровой рубль» и сверка с кошельком там по-прежнему не просматриваются.

3.3. ФФД: тег есть, но он необязательный

С 1 сентября 2025 в формате фискальных данных есть блок тегов 1234–1238. Тег 1236 «Признак способа оплаты безналичными» по замыслу ОФД должен разделять эквайринг, СБП и ЦР. Признак обязательности у блока «3», порядок заполнения ФНС не утвердила, в описании ФНС цифровой рубль не упомянут. В конфигурации этих тегов нет: единственное совпадение по «1234» в модулях менеджера оборудования это строка "0123456789" в разборе символов. Итог: в чеке оплата ЦР ложится в «безналичными» (тег 1081) рядом с картой и СБП и ничем от них не отличается.

4. Почему это не «не успели»

В модуле ДенежныеСредстваСерверЛокализация лежит процедура с говорящим именем:

Процедура ПроверитьДоговорНаВозможностьКорреспонденцииСоСчетомЦифровогоРубля(
	ДоговорОбъект, Отказ) Экспорт

	// ... сообщение пользователю:
	// "Расчетный счет не может корреспондировать со счетом цифрового рубля.
	//  Укажите другой счет"

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

Вызывается из трёх мест: договоры эквайринга, договоры кредитов и депозитов, договоры контрагентов. Первый пункт ключевой. Договор эквайринга не имеет права ссылаться на кошелёк ЦР, и это явная проверка с текстом ошибки, а не побочный эффект.

Теперь вспомним, как УТ разносит безналичную розничную выручку. Цепочка одна:

ЧекККМ → ОперацияПоПлатежнойКарте → ОтчетБанкаПоОперациямЭквайринга → ПоступлениеБезналичныхДенежныхСредств

В центре цепочки реквизит ДоговорЭквайринга: терминал, комиссия, сверка транзакций, подключение СБП. Розничная выручка проходит только через договор эквайринга, а договор эквайринга не может указывать на кошелёк. Значит, по замыслу 1С цифровой рубль это не эквайринговая выручка, а отдельный денежный поток, который приходит с платформы Банка России сам по себе, минуя эквайера и расчётный счёт.

Рис. 3. Две цепочки розничной выручки и граница между ними, которую держит типовая проверка корреспонденции

Что получает учётная система: на кошельке приход, который выписка платформы прочитать умеет; в кассе чек, в котором эта оплата неотличима от карты; штатного моста между ними нет и, судя по запрету корреспонденции, не планируется.

4.1. Дефект в подарок

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

Запрос.УстановитьПараметр("КорреспонденцияСоСчетомЦифровогоРубля",
	?(ЗначениеЗаполнено(КорреспонденцияСоСчетомЦифровогоРубля),
		КорреспонденцияСоСчетомЦифровогоРубля, Неопределено));

СчетЦифровогоРубля это булево. ЗначениеЗаполнено(Ложь) возвращает Ложь, параметр становится Неопределено, условие в запросе вырождается в истину, фильтр выключается. Правило работает при записи договора и не работает при автоподборе счёта. Оговорка: это чтение кода, на стенде я не проверял, подставится ли кошелёк туда, где ждали расчётный счёт. Но код одинаков в обоих справочниках и обоих релизах.

5. БП 3.0.205: что там для бухгалтерии

В Бухгалтерии история длиннее: счёт 53 «Счет цифрового рубля» появился ещё в 3.0.148, загрузка выписки по кошельку из XML в 3.0.164, выгрузка распоряжений в банк в 3.0.191. Релиз 3.0.205 закрывает 248-ФЗ формально. Что стоит знать внедренцу:

• Кошелёк заводится как отдельный тип «Кошелек цифрового рубля» в справочнике банковских счетов, а не как «Банковский счет». Самая частая ошибка пользователей.

• Выписка по кошельку грузится из XML-файла, который клиент руками скачивает в ЛК банка. Только для юрлиц, ИП не поддержаны. Прямого обмена с платформой в типовой нет.

• Основание для проводок не банковская выписка, а «Извещение об исполнении распоряжения» платформы. При переводе 51 -> 53 вид операции «Перевод на другой счет организации», иначе получите расход вместо перемещения.

• Вариант учёта (53, субсчёт к 55 или аналитика на 51) фиксируется в учётной политике до первой операции.

Обмен УТ -> БП по EnterpriseData поступление на кошелёк передаёт, но связи с чеком ККМ там не будет по той же причине: её нет в источнике.

6. Что делать внедренцу: схема моста

Дальше не про «поставить галочку», а про архитектуру доработки, которая сводит кассу с кошельком так, чтобы сверка не разъезжалась. Схему описываю по живому проекту: в августе я настраивал её для среднего клиента, региональной розничной сети с выручкой около 400 млн руб. в год, 14 магазинов, УТ 11.5 на нетиповой базе плюс БП 3.0 у аутсорсинговой бухгалтерии, эквайринг и счёт ЦР в Сбербанке. Всё сделано расширением, типовая не снята с поддержки, обновление на 11.5.27.81 прошло без конфликтов.

Рис. 4. Мост на расширении: регистр связи ЦР_ПлатежиКассы — единственное место, где сходятся чек, заказ банка и операция платформы

6.1. Точка входа: оплата на кассе

УПК формирует банк по его API, а не 1С. Поэтому в РМК нужен новый вид оплаты (в расширении можно расширить ВидОплатыНаТерминале или завести собственный признак в договоре эквайринга). Сценарий: касса создаёт заказ у банка, получает payload УПК, показывает QR покупателю, затем ждёт статус.

// Расширение. Общий модуль ЦРКасса (условное имя)
Функция СоздатьПлатежУПК(Чек, НастройкиТерминала) Экспорт

	Ответ = ЦРОбменБанком.ВызватьМетод(НастройкиТерминала, "order/create",
		Новый Структура("orderId, amount, qrType", Чек.Номер,
			Чек.СуммаДокумента, "UNIVERSAL_QR"));

	// сохраняем orderId и payload в РС ЦРПлатежиКассы (см. 6.2)
	Возврат Ответ;

КонецФункции

У клиента на это ушло больше всего времени не из-за кода, а из-за банка: тестовый контур API под УПК Сбер выдал через восемь рабочих дней после заявки, и первые две недели ответы приходили с qrType для СБП вместо универсального кода. Закладывайте в план запас на согласования.

Идентификатор оплаты банк возвращает в двух видах: в callback-уведомлении и в ответе на запрос статуса. У Сбера оплата ЦР приходит с paymentWay = "NSPK_DIGITAL_RUB", у Альфа-Банка со значением "DIGITAL_RUB". Это тот самый признак, по которому в 1С мы отличаем ЦР от СБП, потому что в чеке его не будет.

6.2. Хранилище связи

Регистр сведений ЦРПлатежиКассы с измерениями: Чек (ДокументСсылка.ЧекККМ), ИдентификаторЗаказаБанка, ИдентификаторОперацииПлатформы. Ресурсы: Сумма, СпособОплаты (СБП / ЦР / Карта по данным банка), Статус, ДатаПодтверждения. Именно этот регистр потом связывает три сущности, которые в типовой живут порознь.

6.3. Callback и опрос статуса

HTTP-сервис в расширении принимает уведомление банка, валидирует подпись, находит запись регистра по orderId и проставляет способ оплаты и статус. Обязателен и фоновый опрос статусов по незакрытым записям: callback-сервер есть не у всех клиентов, а уведомление может не дойти. Идемпотентность по идентификатору операции, иначе при повторе получите двойное подтверждение. У клиента callback-сервер поднимали на публикации 1С за nginx с ограничением по IP банка; для магазинов, где база работает через RDP без внешнего адреса, оставили только фоновый опрос раз в 30 секунд, и этого оказалось достаточно.

6.4. Фискализация

Чек пробивается штатно, как «безналичными». Если драйвер ККТ уже поддерживает тег 1236 (АТОЛ с версии 11, ШТРИХ-М через Центр обновлений, Эвотор через ЛК), заполняем его из ответа банка. Если нет, оставляем 1081 и не ждём от ОФД разделения: наш признак живёт в регистре из 6.2. Обязательность тега 1236 ещё придёт, закладывайте место под него сейчас.

6.5. Разнесение выручки

Здесь два варианта, и выбирать надо вместе с бухгалтером клиента.

• Отдельный поток. Не трогаем ОтчетБанкаПоОперациямЭквайринга. Поступление на кошелёк грузим из выписки платформы (типовой ОбменСБанкамиЦифровойРубль, операция CTOB) и связываем с чеками через регистр 6.2 по идентификатору операции. Соответствует замыслу 1С, не спорит с запретом корреспонденции.

• Псевдоэквайринг. Заводим технический договор эквайринга «Цифровой рубль», банковский счёт в нём обычный транзитный, и включаем ЦР в стандартную цепочку. Быстрее для клиента, у которого вся сверка построена на отчёте банка, но на выписке платформы придётся делать корректирующее поступление. Годится как временное решение.

Клиент выбрал отдельный поток: у бухгалтерии уже стоял счёт 53 в БП, а смешивать кошелёк с эквайрингом на сверке главбух отказалась сразу. Перенос в БП идёт штатным EnterpriseData, признак ЦР по чекам уезжает дополнительным свойством документа.

6.6. Сверка

Отчёт на СКД по трём источникам: чеки ККМ с признаком ЦР из регистра, поступления на кошелёк из выписки платформы (по идентификатору операции), подтверждённые статусы банка. Расхождения трёх типов: чек есть, приход не пришёл (задержка платформы или возврат); приход есть, чека нет (оплата по статическому УПК мимо кассы); суммы не бьются (частичный возврат). Возврат покупателю в ЦР проходит мгновенно на кошелёк, это надо учитывать при закрытии смены. На тестовом прогоне у клиента отчёт поймал ровно тот случай, ради которого всё делалось: оплату по статическому УПК на стойке информации мимо кассы, которую кассир потом пробил как наличные.

6.7. Работа в базе клиента: что именно менялось

База нетиповая: РМК уже был правлен предыдущим подрядчиком, поэтому первым делом сняли копию, подняли хранилище под расширение и проверили, какие объекты типовой уже захвачены в основной конфигурации. Всё новое ушло в расширение ЦР_Касса (имена объектов ниже условные, у себя называйте по стандарту клиента).

В РМК заимствована форма рабочего места кассира, добавлена команда «Цифровой рубль / УПК» рядом с оплатой картой. Обработчик через директиву &После, чтобы не переписывать типовой код оплаты:

&НаКлиенте
Процедура ЦР_ОплатитьУПК(Команда)

	Результат = ЦР_КассаВызовСервера.СоздатьПлатежУПК(Объект.Ссылка, ТекущийТерминал);

	Если Не Результат.Успех Тогда
		ПоказатьПредупреждение(, Результат.Ошибка);
		Возврат;
	КонецЕсли;

	Параметры = Новый Структура("QR, OrderId, Сумма",
		Результат.Payload, Результат.OrderId, Объект.СуммаДокумента);

	// форма ждёт статус (callback или опрос) и по успеху вызывает типовое проведение чека
	ОткрытьФорму("Обработка.ЦР_ОжиданиеОплаты.Форма", Параметры, ЭтотОбъект);

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

В справочник банковских счетов организаций внесены кошельки: у клиента два юрлица, значит два кошелька, потому что платформа даёт одной компании ровно один. Магазины привязаны к кошельку через организацию, ничего в справочнике магазинов менять не пришлось. В существующие чеки ничего не переписывали: регистр связи заполняется только новыми оплатами, а для сверки с 1 сентября загрузили выписки платформы за пилотный период.

Тестирование шло на копии базы с тестовым контуром банка: оплата, отмена до подтверждения, полный и частичный возврат, потерянный callback (сервис выключали руками и смотрели, добирает ли опрос), повторный callback по одному orderId. Потом два магазина неделю на боевом контуре, затем остальные двенадцать. После выхода 11.5.27.81 расширение проверили на конфликты: один конфликт в заимствованной форме РМК, поправили за час, других не было.

6.8. Что вошло в проект и сколько это заняло

Чтобы было понятно, какого объёма работа стоит за словом «мост», состав по этому клиенту:

Итого около трёх недель календарных, из них чистой разработки половина, остальное ожидание банка и согласования с бухгалтерией. Сопровождение после запуска отдельным договором: смена релизов 1С, изменения API банка, обязательность тега 1236, когда ФНС её введёт.

Эту же схему собираю под другие связки: Альфа-Банк (там OAuth2 и признак DIGITAL_RUB вместо NSPK_DIGITAL_RUB), Т-Банк, ПСБ, ВТБ; конфигурации УТ 11, Розница 2.3 / 3.0, ERP, КА, УНФ и БП 3.0. Опыт похожий: любая интеграция 1С с внешней системой по REST или SOAP держится на одних и тех же трёх вещах — идемпотентность на приёме, регистр связи вместо переписывания типовых документов, и фоновый опрос как страховка от пропавшего callback. Ровно по этой схеме идут интеграции 1С с ФРДО (передача сведений о договорах и документах об образовании), кабинетом Минтруда (взаимодействие по 296-ФЗ и связанным реестрам), СМЭВ и другими государственными системами: те же требования к подписи запроса, статусной модели и сверке, только протокол и формат сообщений другие.

7. Чек-лист клиенту перед запуском

• Проверить, подпадает ли компания: выручка 2025, банк на 01.01.2026, порог 5 млн на точку, наличие интернета в точке.

• Открыть счёт ЦР в банке заранее: по опыту коллег с «Клерка» заявка от 27 августа превратилась в рабочий счёт только к обеду 1 сентября, с зависшей на часы проверкой из-за наплыва заявок и выпуском сертификатов ключей.

• Обновить прошивку ККТ и убедиться, что в драйвере появился признак способа расчёта.

• Обновить конфигурацию: БП до 3.0.205, УТ до 11.5.27.81, Розницу до релиза с 248-ФЗ.

• Закрепить в учётной политике вариант учёта ЦР.

• Договориться с банком об API для УПК и callback, получить тестовый контур.

• Внедрить мост касса -> кошелёк, прогнать сценарии оплата, возврат, частичный возврат, потерянный callback.

8. Итог

Фирма 1С закрыла казначейство и обмен с банком и сознательно не стала вписывать цифровой рубль в эквайринговую цепочку кассы. Пока приём бесплатен, а СБП стоит почти столько же, экономической причины перестраивать РМК у рынка нет, и это, видимо, объясняет спокойствие всех участников. Но обязанность у магазина возникла 1 сентября, штраф работает через права потребителя, и придёт этот вопрос к внедренцам: сначала на нетиповые конфигурации и старые релизы, потом ко всем, у кого сверка розницы завязана на отчёт банка.

Проверено 28 августа 2026 на выгрузке «Управление торговлей» 11.5.27.79 (сравнение с 11.5.22.182), релизный план по данным v8.1c.ru от 4 сентября 2026. Оценки по кассовому контуру 11.5.27.81 и Розницы 3.0 предварительные, до появления релизов.