Какие проблемы могут возникнуть при переходе с платформы 1С 8.3.12 на 8.3.16 и как их решить?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Переход на новую версию платформы 1С:Предприятие — это всегда ответственный шаг, особенно если речь идет о переходе со старых стабильных релизов (таких как 8.3.12) на более современные (например, 8.3.16) с одновременным отключением режима совместимости. В такой ситуации разработчик сталкивается с кумулятивным эффектом изменений, накопленных за несколько версий платформы (8.3.13, 8.3.14, 8.3.15 и 8.3.16).

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

Проблема 1: Исключение при формировании отчетов СКД (изменение состава доступных свойств)

Один из самых массовых сбоев, который обнаруживается сразу после запуска базы на платформе 8.3.16 без режима совместимости, — это падение типовых и самописных отчетов при попытке их формирования. При обращении к неиспользуемым свойствам объектов Системы компоновки данных (СКД), находящихся в пользовательских настройках, генерируется критическое исключение.

Платформа блокирует обращение к следующим свойствам:

  1. Свойство ПредставлениеПользовательскойНастройки для объектов ОтборКомпоновкиДанных, ВыбранныеПоляКомпоновкиДанных, УсловноеОформлениеКомпоновкиДанных.
  2. Свойства ПредставлениеПользовательскойНастройки, Представление, ЛевоеЗначение, Применение, Родитель для объекта ЭлементОтбораКомпоновкиДанных.

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

Рассмотрим пример программного обхода этой ошибки в общем модуле ОтчетыСервер (на примере интеграции в УТ 11.4):


// В общем модуле ОтчетыСервер находим инициализацию соответствия синхронизируемых свойств:
СинхронизируемыеСвойства = Новый Соответствие;
СинхронизируемыеСвойства.Вставить(Тип("ЭлементОтбораКомпоновкиДанных"), "ЛевоеЗначение, Представление");
СинхронизируемыеСвойства.Вставить(Тип("ЭлементУсловногоОформленияКомпоновкиДанных"), "Представление");

#Вставка
// Для новых платформ без режима совместимости заменяем старые свойства на Неопределено
СинхронизируемыеСвойства = Новый Соответствие;
СинхронизируемыеСвойства.Вставить(Тип("ЭлементОтбораКомпоновкиДанных"), Неопределено);
СинхронизируемыеСвойства.Вставить(Тип("ЭлементУсловногоОформленияКомпоновкиДанных"), Неопределено);
#КонецВставки

Такая простая доработка позволяет мгновенно восстановить работоспособность механизмов компоновки данных и исключить аварийное завершение работы отчетов.

Проблема 2: Новое поведение отборов СКД в запросах с объединениями (ОБЪЕДИНИТЬ ВСЕ)

Еще одно серьезное изменение касается оптимизации выполнения запросов СКД. Начиная с версии 8.3.13, логика наложения пользовательских отборов на запросы, содержащие операторы ОБЪЕДИНИТЬ или ОБЪЕДИНИТЬ ВСЕ, кардинально изменилась.

Рассмотрим, как это работает на практике. Допустим, у нас есть следующий запрос в наборе данных СКД:


ВЫБРАТЬ
    Документ1.Ссылка КАК Документ,
    Документ1.Контрагент КАК Контрагент
ИЗ
    Документ.РеализацияТоваровУслуг КАК Документ1

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    Документ2.Ссылка,
    NULL // Поле "Контрагент" отсутствует во второй таблице
ИЗ
    Документ.ИнвентаризацияТоваров КАК Документ2

В старых версиях платформы (до 8.3.13), если пользователь устанавливал отбор по полю Контрагент, платформа накладывала это условие только на первую часть объединения, где данное поле реально существует. Вторая часть объединения просто игнорировалась отбором.

В режиме без совместимости на платформе 8.3.16 поведение иное: отбор обязательно добавляется во все части объединения, если его удалось поместить хотя бы в одну из них. При этом в тех частях объединения, где поле отсутствует, система автоматически подставляет выражение NULL.

В результате условие для второй таблицы преобразуется в выражение вида NULL = &ПараметрОтбора. Проанализируем последствия: поскольку любое сравнение с NULL (кроме специального оператора ЕСТЬ NULL) возвращает ложь, строки из второй таблицы будут полностью отсечены. Это может привести к неожиданному для пользователя результату отчета. При проектировании сложных схем компоновки с объединениями теперь обязательно нужно заменять отсутствующие поля дефолтными значениями, совместимыми по типу с условием отбора, либо явным образом настраивать параметры отборов.

Проблема 3: Переход на кроссплатформенный графический движок Cairo

Начиная с версии 8.3.16, платформа полностью перешла на использование библиотеки Cairo для отрисовки графики и шрифтов в тонком и толстом клиентах под Windows, Linux и macOS. Это может преподнести неприятные визуальные сюрпризы:

  1. «Поплывшая» верстка форм: Элементы управления, которые ранее располагались плотно друг к другу, могут начать перекрываться или отображаться со сдвигом. Шрифты могут казаться более тонкими, размытыми или, наоборот, избыточно жирными.
  2. Проблемы с печатными формами: Высота строк в табличных документах при формировании печатных форм может незначительно измениться (на 1-2 пикселя), что приведет к преждевременному переносу страниц при печати документов.

Рекомендуется провести выборочный визуальный аудит наиболее часто используемых печатных форм и интерфейсных панелей под управлением новой платформы.

Проблема 4: Переход на движок WebKit вместо Internet Explorer

В платформе 8.3.14 произошел долгожданный, но болезненный отказ от использования встроенного MS Internet Explorer для отображения полей HTML-документов на формах. Вместо него теперь используется современный движок WebKit.

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

Проблема 5: Переименование типа УправляемаяФорма

При отключении режима совместимости с версии 8.3.13 системный тип УправляемаяФорма переименовывается в ФормаКлиентскогоПриложения. Если в ваших общих модулях или обработках содержится проверка типов вида:


Если ТипЗнч(ТекущаяФорма) = Тип("УправляемаяФорма") Тогда
    // Код обработки формы
КонецЕсли;

То на платформе 8.3.16 этот код вернет Ложь, что может привести к обходу важной бизнес-логики. Обязательно выполните глобальный поиск по всей конфигурации по строке "УправляемаяФорма" и замените её на "ФормаКлиентскогоПриложения".

Проблема 6: Индекс полнотекстового поиска (ППС)

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

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

Проблема 7: Ошибки реструктуризации базы данных при первом запуске

При первом обновлении конфигурации базы данных с отключением режима совместимости СУБД выполняет масштабную реструктуризацию таблиц (изменяются типы хранения некоторых метаданных, оптимизируются индексы). На крупных базах данных под управлением MS SQL Server или PostgreSQL может возникнуть ошибка:

«Для одного ссылочного кода существует более одной таблицы в базе данных (DataHistoryLatestVersions...)»

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

  1. Временно отключите механизм истории данных для всей конфигурации.
  2. Проведите полное тестирование и исправление (ТиИ) базы данных со всеми включенными флагами проверки логической и физической целостности.
  3. При возникновении неустранимых ошибок выполните выгрузку информационной базы в файл .dt, после чего загрузите его в новую чистую базу данных СУБД.

Подводя итог, переход с 8.3.12 на 8.3.16 — это отличная возможность повысить производительность системы и начать использовать новые возможности платформы, однако он требует тщательного предварительного тестирования на копии базы данных, исправления кода работы с HTML-полями и обязательной адаптации общих модулей работы с отчетами СКД.

← На главную