Переход на платформу 8.3.12 для Бухгалтерии 3.0: разбор критических ошибок и особенностей лицензирования

← На главную

С выходом новых редакций конфигурации «Бухгалтерия предприятия» (начиная с версии 3.0.65.69) компания 1С установила жесткое требование к версии технологической платформы — не ниже 8.3.12.1529. Это обновление вызывает множество вопросов у технических специалистов, так как переход на ветку 8.3.12 сопряжен с изменением механизмов защиты, логики лицензирования и работы внутренних механизмов базы данных. В этой статье мы подробно проанализируем ситуацию, разберем основные «сюрпризы», с которыми сталкиваются пользователи, и выясним, как минимизировать риски при обновлении.

Причины жесткого требования новой платформы

Разберем, почему нельзя просто изменить режим совместимости и остаться на привычной 8.3.10. Новые релизы БП 3.0 активно используют функционал, который физически отсутствует в старых версиях платформы. К ним относятся расширенные механизмы История данных, новые методы работы с расширениями конфигурации и оптимизированные механизмы формирования отчетности. Попытка обмануть систему приведет к тому, что при первом же обращении к общему модулю, использующему новые методы встроенного языка, система выдаст критическую ошибку Метод объекта не обнаружен.

Критическая ошибка: удаление истории данных при ТИИ

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

Система обращается к таблице DataHistoryVersions.
Вследствие внутреннего бага платформы, корректные записи распознаются как ошибочные.
Происходит массовое удаление данных. В логах это выглядит так: Проверка таблицы DataHistoryVersions: удалено XXXXXX записей.

Рекомендация: Если вы уже перешли на билд 1529, воздержитесь от запуска ТИИ до обновления на более стабильный релиз (например, 8.3.12.1685 или 8.3.12.1924). Всегда делайте резервную копию в формате .dt перед любыми манипуляциями с базой.

Особенности лицензирования и программные ключи

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

Веб-клиент и расход лицензий. В платформе 8.3.12 изменилась логика работы через браузер. Теперь каждый открытый сеанс (новая вкладка) потребляет отдельную программную лицензию. Если пользователь открыл три вкладки с одной базой, из пула будет забрано 3 лицензии. Это критично для компаний с ограниченным количеством ключей.
Обновление Windows 10. Пользователи отмечают, что при крупных обновлениях операционной системы программные лицензии могут «слетать», требуя повторной активации с использованием резервного пин-кода.
Аппаратные ключи (HASP). На текущий момент аппаратные лицензии показывают себя наиболее стабильно. Ошибки типа «Ключ защиты не обнаружен» на 12-й платформе возникают реже, чем проблемы с привязкой программных лицензий к железу.

Ошибка «Нарушение целостности системы»

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

Для устранения этой проблемы выполним следующие шаги:

Проверим наличие и удалим файлы vusb.sys и mshasp.sys.
Очистим ветки реестра, связанные с драйверами HASP, которые остались от старых патчей.
Используем официальные утилиты от 1С для очистки системы от следов нелицензионного ПО.

Проблемы с расширениями и отладкой

Посмотрим на технические нюансы работы программиста в новой среде. В релизах 8.3.12.1595 и 8.3.12.1616 были замечены следующие баги:

Отладчик: У некоторых специалистов под отладчиком перестают выводиться Таблицы значений, что крайне затрудняет поиск ошибок в сложном коде.
Расширения: Если расширение содержит затянутые в него регистры накопления или бухгалтерии, это может приводить к падению рабочего процесса rphost.exe.

Для исправления ситуации с расширениями при переходе с 10-й платформы на 12-ю, рекомендуется выполнить процедуру пересборки:


// Примерный алгоритм действий:
1. Выгрузить расширение в файл .cfe
2. Удалить расширение из информационной базы
3. Обновить конфигурацию базы данных
4. Загрузить расширение обратно и проверить режим совместимости

Интерфейс и обычные формы

Проанализируем влияние обновления на старые конфигурации (ЗУП 2.5, БП 2.0), которые запускаются на новой платформе. В версии 8.3.12.1529 обнаружен баг 10192893: некорректное отображение стандартных картинок в обычных формах (кнопки командной панели, иконки надписей). Если ваша работа тесно связана с обычными формами, стоит принудительно запускать такие базы на предыдущих версиях платформы (8.3.10), если это позволяет функционал конфигурации.

Выводы и рекомендации по выбору релиза

Разберем финальный вопрос: на какой же релиз переходить? Сообщество экспертов сходится во мнении, что билд 8.3.12.1529 является «проходным» и содержит слишком много детских болезней.

Наш план действий:

Если текущая отчетность в Бухгалтерии 3.0 не требует срочного обновления (нет изменений в формах, которые есть только в 3.0.65), лучше остаться на 8.3.10.
Если переход неизбежен, рассмотрите возможность установки более поздних и стабильных сборок ветки 8.3.12 (например, 8.3.12.1924), где исправлены ошибки ТИИ и рендеринга интерфейса.
Для высоконагруженных систем на Linux в связке с PostgreSQL будьте готовы к возможным утечкам памяти в процессе rphost, что лечится регулярным перезапуском службы или переходом на ветку 8.3.14/15.

Таким образом, переход на 8.3.12 — это не просто формальное обновление, а серьезный технический этап, требующий предварительного аудита лицензий и тщательного тестирования расширений на копиях баз.