Новые взаиморасчёты в 1С:ERP и 1С:КА — дедлайн апрель 2026. Что делать прямо сейчас

В апреле 2026 фирма «1С» принудительно переведёт всех пользователей ERP, КА и УТ на новую архитектуру взаиморасчётов. В июне старый код удалят из конфигурации полностью. Откатиться назад будет невозможно. Если вы ещё не начали подготовку — начинайте сегодня. Разбираем: что меняется, как перейти без потерь и где обычно всё ломается.

Что происходит и почему это важно

Фирма «1С» с 2024 года переводит взаиморасчёты в ERP, КА и УТ на новую архитектуру. До сих пор это было добровольно — можно было включить новый режим, попробовать, откатиться. С апреля 2026 года выбора не будет.

Вот точные даты:

  • Апрель 2026 (версия 2.5.27) — принудительный переход. При обновлении старый режим отключится автоматически
  • Июнь 2026 (версия 2.5.28 / 2.6) — полное удаление старого кода из конфигурации. Точка невозврата

Переход на версию 2.6 (с новым интерфейсом платформы 8.5) невозможен без включённых онлайн-взаиморасчётов. Это блокирующее условие.

До принудительного перехода — меньше месяца. Если у вас ERP, КА или УТ и вы ещё не тестировали переход на копии базы — это нужно сделать на этой неделе. На больших базах процесс может занять дни.

Старый режим vs новый: в чём разница

Чтобы понять, зачем «1С» ломает работающую систему, нужно разобраться, что было не так со старым режимом.

Старый режим («офлайн»)

Распределение оплат по накладным происходило не в момент проведения документа, а по расписанию — фоновым регламентным заданием. Пересчёт шёл по месячным периодам. На практике это означало:

  • Менеджер проводит оплату от клиента — а в отчёте по взаиморасчётам она появляется через час, когда отработает регламентное задание
  • При закрытии месяца — взаимные блокировки (deadlock), пользователи не могут проводить документы
  • Данные по дебиторке и кредиторке — всегда «примерно актуальны», никогда не точны в реальном времени

Мы сталкивались с этим на каждом втором проекте по ERP. Главбух звонит: «Закрытие месяца зависло, менеджеры не могут проводить реализации». Причина — deadlock в регистрах взаиморасчётов. Лечится перезапуском регламентного задания, но осадок остаётся.

Новый режим («онлайн»)

Распределение оплат происходит в реальном времени — прямо при проведении документа. Сложные расчёты выносятся в фоновую обработку, но без блокировки интерфейса. Пересчёт идёт по дням, а не по месяцам — затрагиваются только изменённые даты.

Что это даёт на практике:

  • Актуальные данные в любой момент. Отчёт по дебиторке показывает реальное состояние, а не «на момент последнего пересчёта»
  • Нет deadlock при закрытии месяца. Главбух закрывает период, менеджеры продолжают работать
  • Новые аналитики: дата возникновения задолженности, дата планового погашения. Можно строить реальный прогноз денежного потока
  • Распределение по ФИФО — первая оплата закрывает первую отгрузку. Прозрачно и предсказуемо
  • Претензии стали полноценным финансовым объектом — учитываются в расчётах, а не висят «сбоку»

Звучит хорошо. Но переход — это не «нажать кнопку». Это миграция данных из одной структуры регистров в другую. И вот тут начинаются нюансы.

Что меняется технически

Для тех, кто работает с конфигуратором или управляет доработками — это ключевая информация.

Старые регистры (будут удалены):

  • РасчетыСКлиентами (регистр накопления)
  • РасчетыСПоставщиками (регистр накопления)
  • РасчетыСКлиентамиПоДокументам (регистр накопления)
  • РасчетыСПоставщикамиПоДокументам (регистр накопления)

Новые регистры (уже работают):

  • РасчетыСКлиентамиПоСрокам (регистр сведений)
  • РасчетыСПоставщикамиПоСрокам (регистр сведений)
  • ЗаданияКРаспределениюРасчетов (регистр сведений)
  • СуммаДокументовВВалютеРеглУчета (регистр сведений)

Критично: все доработки, расширения и пользовательские отчёты, которые обращаются к старым регистрам, перестанут работать после июня 2026. Регистры будут физически удалены из конфигурации.

Новые регистры — это регистры сведений (не накопления). Другая структура, другие запросы, другая логика получения данных. Переписывать придётся не формально, а по существу.

Пошаговый план перехода

Этап 1. Подготовка (сделать до апреля)

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

Этап 2. Технический переход

Процесс автоматизирован и состоит из двух фаз:

Фаза 1: система блокирует регистры заданий (пользователи временно не проводят документы), выполняет контрольную актуализацию, затем многопоточно переносит данные в новые регистры. После переноса основной массы — разблокировка, пользователи продолжают работу. Параллельно идёт перенос оставшихся данных.

Фаза 2: повторная кратковременная блокировка, доперенос изменений за время работы, переключение константы «НоваяАрхитектураВзаиморасчетов» в значение «Истина». Готово.

Количество потоков переноса регулируется константой «Количество потоков перехода на онлайн взаиморасчеты» — по умолчанию 8. На мощном сервере можно увеличить для ускорения.

Этап 3. После перехода

  1. Проверьте отчёты по взаиморасчётам — дебиторка, кредиторка, взаимозачёты
  2. При расхождениях — используйте обработку «Заполнение регистров взаиморасчётов»
  3. Обновите доработки под новые регистры
  4. Обучите сотрудников работе с новыми документами: «Взаимозачёт задолженности», «Корректировка задолженности», «Корректировка графика взаиморасчетов»

Где обычно всё ломается: реальные проблемы

Мы собрали типичные проблемы из практики и с форумов Infostart — чтобы вы знали, к чему готовиться.

Проблема 1. Гигантские базы — перенос на дни

На одном из проектов обработка перехода пыталась обработать 235 000 записей. Расчётное время — 14 дней. После трёх дней работы упала с ошибкой PostgreSQL «out of shared memory».

Решение: увеличить параметр max_locks_per_transaction в PostgreSQL, оптимизировать через параллельное выполнение. На MS SQL аналогичная проблема решается увеличением памяти для блокировок.

Правило: если в вашей базе больше 50 000 документов по взаиморасчётам за все годы — обязательно тестируйте на копии. Засеките время. Заложите запас. Не запускайте переход на продуктиве в пятницу вечером.

Проблема 2. Отрицательные остатки после перехода

После включения онлайн-режима в регистрах обнаруживаются отрицательные остатки на исторические даты. Причина — старые ручные корректировки регистров, которые в новой архитектуре обрабатываются по-другому.

Решение: обработка «Заполнение регистров взаиморасчётов» с фильтром по конкретным контрагентам. В нашей практике на базе с 3 000 контрагентов исправление заняло около двух часов.

Проблема 3. Расширения перестают работать

Самая массовая проблема. Расширения, которые дописывают логику к старым регистрам, после перехода начинают выдавать ошибки. А после июня 2026 — просто не скомпилируются.

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

Что делать: до перехода составьте полный список расширений и доработок. Для каждого проверьте: есть ли обращения к регистрам РасчетыСКлиентами, РасчетыСПоставщиками и их производным. Если есть — переписывайте под новые регистры.

Проблема 4. Некорректные авансы

В некоторых релизах (зафиксировано в 2.5.25.63) при определённых условиях система перезаписывает авансы, уводя расчёты в минус. Перезаполнение регистров помогает, но отмена проведения документа может вызвать рецидив.

Рекомендация: обновитесь до последнего релиза перед переходом. 1С активно исправляет такие ошибки в каждом обновлении.

Проблема 5. Невозможность повторного включения

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

Решение: ручное изменение константы «НоваяАрхитектураВзаиморасчетов». Но лучше не отключать после включения — если начали, доведите до конца.

Сколько времени закладывать

Зависит от размера базы и количества доработок:

  • Небольшая база (до 10 000 документов/год, нет доработок): 30‑60 минут на переход + 2‑3 часа на проверку
  • Средняя база (10‑50 тысяч документов, несколько расширений): 2‑8 часов на переход + 1‑2 дня на адаптацию доработок
  • Крупная база (50 000+ документов, много лет истории, десятки доработок): от суток до нескольких дней на переход + 1‑2 недели на адаптацию

На одном из проектов по ERP мы столкнулись с тем, что у клиента было 18 расширений, из которых 7 обращались к регистрам взаиморасчётов. Переписали за 8 рабочих дней. Сам переход данных занял 4 часа. Если бы клиент не подготовился и обновился в апреле — получил бы 4 часа простоя плюс неработающие отчёты на неопределённый срок.

Чек-лист подготовки

  1. ☐ Определите вашу версию конфигурации (ERP/КА/УТ) и релиз
  2. ☐ Создайте копию рабочей базы
  3. ☐ Обновите копию до последнего релиза
  4. ☐ Запустите переход на онлайн-взаиморасчёты на копии
  5. ☐ Засеките время перехода
  6. ☐ Проверьте отчёты по взаиморасчётам после перехода
  7. ☐ Составьте список всех расширений и доработок
  8. ☐ Проверьте каждое расширение на обращения к старым регистрам
  9. ☐ Адаптируйте доработки под новые регистры
  10. ☐ Для PostgreSQL: проверьте max_locks_per_transaction
  11. ☐ Запланируйте переход на продуктиве на время минимальной нагрузки
  12. ☐ Создайте резервную копию перед миграцией
  13. ☐ После перехода: обучите сотрудников новым документам

Что будет, если ничего не делать

Три сценария:

Сценарий 1: обновляетесь в апреле без подготовки. Переход запускается автоматически. Если база большая — простой на часы или дни. Доработки ломаются. Отчёты показывают ерунду. Бухгалтерия в панике.

Сценарий 2: не обновляетесь вообще. Остаётесь на старой версии. Через полгода — нет обновлений законодательства (а НДС 22% и другие изменения требуют актуальных релизов). Нет перехода на версию 2.6. Нет поддержки 1С. Технический долг растёт.

Сценарий 3: готовитесь заранее. Тестируете на копии. Адаптируете доработки. Переходите в удобное время. Всё работает. Бухгалтерия не знает, что что-то изменилось.

Разница между сценарием 1 и 3 — неделя подготовки. Стоимость сценария 1 для средней компании — от 100 тысяч рублей потерь на простое (не считая стресса).

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

FAQ

Принудительный переход — апрель 2026 (версия 2.5.27). Полное удаление старого кода — июнь 2026 (версия 2.5.28 / 2.6). Рекомендуем перейти до апреля, чтобы контролировать процесс.

При обновлении до 2.5.27 переход произойдёт принудительно. Без обновления — потеряете поддержку, обновления законодательства и возможность перехода на 2.6. При обновлении без подготовки — возможен простой от часов до дней.

Небольшая база — 30‑60 минут. Средняя — 2‑8 часов. Крупная (50 000+ документов) — от суток. Обязательно тестируйте на копии, чтобы знать точное время для вашей базы.

Да. Все расширения и отчёты, обращающиеся к старым регистрам (РасчетыСКлиентами и др.), перестанут работать. Их нужно переписать под новые регистры сведений до июня 2026.

1С:ERP 2 (редакция 2.5), 1С:Комплексная автоматизация 2, 1С:Управление торговлей 11, а также все отраслевые решения на их базе. 1С:Бухгалтерия не затронута.

Переход на новые взаиморасчёты — без простоя и сюрпризов

Протестируем на копии вашей базы, адаптируем доработки, проведём переход в удобное время. Вы не заметите разницы — кроме того, что отчёты стали точнее.

Ответим за 15 минут или 3 дня обслуживания бесплатно.

Подготовиться к переходу →

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

Нужна помощь с 1С?

Перезвоним за 15 минут, разберёмся в ситуации, предложим решение. Без давления.

Шаг 1 из 5

Какая задача стоит перед вами?

БО
Безопасный Офис
Обычно отвечаем за 15 мин

Здравствуйте! Чем можем помочь? Выберите удобный способ связи:

Написать в Telegram Позвонить +7 931 111-20-21