← На главную

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

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

Суть проблемы ложных изменений справочной информации

Давайте проанализируем ситуацию, с которой сталкиваются многие разработчики и администраторы 1С. Изначально, проблема проявляется в виде различий, которые конфигуратор показывает при сравнении/объединении конфигурации поставщика с нашей доработанной конфигурацией. Например, в текстовом поле HTML мы видим:

Было: [*] Цены и скидки Настройка правил ценообразования Показать

В конфигурации поставки: [*] Цены и скидки Настройка правил ценообразования Показать

Визуально тексты идентичны, но система фиксирует изменение. Часто это связано с внутренними метаданными или служебными тегами, которые платформа 1С добавляет или изменяет при сохранении HTML-полей. Одним из ярких примеров таких изменений является упоминание версии MSHTML, например, MSHTML 11.00.9600.18212 или MSHTML 11.00.9600.17963 (Сообщение 1). Даже если мы вручную пытаемся "исправить" это значение, оно может возвращаться к предыдущему или другому значению после сохранения, что указывает на глубокую внутреннюю причину проблемы.

Ключевой момент: проблема заключается не в видимом изменении содержимого, а в том, что "система фиксирует изменения из-за тега, хотя на деле их нет!" (Сообщение 15). Разработчики 1С неоднократно указывали, что это "не баг платформы, а известная особенность Internet Explorer" или "не документировано" и относится к "особенностям, а не ошибкам" (Сообщения 4, 8, 10).

В более сложных сценариях, особенно при работе с хранилищем конфигураций, проблема может проявляться как долгие сравнения (до часа вместо привычных 20 секунд) и различия в служебном файле ConfigDumpInfo (файл версий), даже для объектов, фактически не менявшихся и находящихся на поддержке (Сообщение 21).

Решение 1: Обновление платформы и переход на WebKit

Одним из наиболее значимых изменений, которое кардинально повлияло на работу с HTML-документами в 1С и решило многие связанные с этим проблемы, стал переход платформы от использования устаревшего Microsoft Internet Explorer к более современному движку WebKit. Мы рассмотрим подробнее этот переход и его влияние.

Понимание перехода на WebKit и его влияние

С платформы 8.3.14, и более конкретно, начиная с версии 8.3.14.1373 от 15.11.2018 и далее (например, 8.3.14.1565), система 1С:Предприятие для отображения HTML-документов в клиентских приложениях на операционных системах Windows, Linux, Mac и Android перешла с использования библиотеки Microsoft Internet Explorer на библиотеку WebKit. В веб-клиенте для аналогичных целей используется iframe (Сообщение 2).

Этот переход привел к следующим существенным изменениям, которые напрямую влияют на процесс сравнения и объединения и решают проблему ложных различий:

1. Изменение типа свойства ПолеHTMLДокумента.Документ: Ранее это свойство имело тип COMОбъект и взаимодействовало со специфичными для Internet Explorer возможностями. Теперь его тип изменился на ВнешнийОбъект. Это означает, что внутренняя структура, которую 1С использует для хранения и интерпретации HTML-содержимого, стала другой, что устранило зависимость от MSHTML-тегов, приводивших к ложным изменениям.
2. Изменение DOM-модели: Объектная модель документа (DOM), доступная при обращении к свойству ПолеHTMLДокумента.Документ, изменилась. Код, который ранее взаимодействовал с HTML-страницами через специфичные для Microsoft Internet Explorer возможности, например, для вызова JavaScript-кода часто использовался метод eval через parentWindow, теперь требует доработки. В WebKit прямой доступ к методам JavaScript возможен через DefaultView. Мы рекомендуем провести анализ использования элемента формы ПолеHTMLДокумента в ваших доработанных конфигурациях и, при необходимости, адаптировать реализацию под новую DOM-модель и принципы работы WebKit.

Более новые версии платформы, такие как 8.3.26, используют современную версию WebKit, аналогичную используемой в iPhone 15 Pro, в то время как в 8.3.23 использовалась более старая версия WebKit (WebKit 1) до её обновления.

Эффективность обновления платформы

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

• Пользователи отмечали положительные результаты уже на бета-версии 8.3.14: "Результат положительный в плане устранения различий справочной информации. После сравнения/объединения с конфигурацией поставщика, различия отсутствуют." (Сообщение 3).
• Переход на платформу 8.3.18.1208 с режимом совместимости 8.3.14 был описан как "полет отличный, больше никаких непонятных сравнений, все галки на своем месте!" (Сообщение 27).

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

Однако, следует отметить, что проблема может возникать вновь или иметь схожие проявления даже на более новых платформах, как это было замечено на 8.3.18.1363 (Сообщение 28) и 8.3.24.1467 (Сообщение 29). Это указывает на то, что, хотя переход на WebKit решил основную проблему MSHTML-тегов, могут существовать другие внутренние метаданные или идентификаторы, которые платформа продолжает учитывать при сравнении. Наблюдается также, что на разных версиях платформы количество ложных различий может варьироваться: "на 24 просто вагон справочная информация торчит а вот на 22 релизе единицы" (Сообщение 31).

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

Решение 2: Алгоритм обновления для сложных конфигураций и большого количества объектов

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

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

Мы проанализируем алгоритм, предложенный участниками сообщества 1С, который подтвердил свою работоспособность в условиях доработанных конфигураций (Сообщения 17, 24). Этот алгоритм позволяет "очистить" конфигурацию от ложных изменений и затем корректно перенести свои доработки.

1. Сохраняем текущую конфигурацию: Перед началом любых манипуляций с обновлением, мы обязательно сохраняем нашу текущую, доработанную конфигурацию в файл формата .cf. Это наша точка восстановления и источник наших доработок. Мы можем назвать его, например, "МояКонфигурация_Текущая.cf".
2. Сохраняем конфигурацию поставщика: Нам также потребуется чистая конфигурация поставщика, соответствующая той версии, на которую мы планируем обновляться. Мы сохраняем её в отдельный файл .cf, например, "КонфигурацияПоставщика_НоваяВерсия.cf".
3. Снимаем конфигурацию с поддержки: В нашей текущей информационной базе мы временно снимаем конфигурацию с поддержки поставщика. Это действие предоставляет нам полную свободу для внесения изменений, которые потребуются на следующих шагах.
4. Загружаем конфигурацию поставщика в Конфигуратор: Мы загружаем конфигурацию из файла "КонфигурацияПоставщика_НоваяВерсия.cf" (полученного на шаге 2) в нашу информационную базу. Критически важно: на этом шаге мы НЕ обновляем конфигурацию базы данных! Мы работаем только с конфигурацией, загруженной в Конфигуратор, без применения её к данным. Это действие "очищает" нашу конфигурацию от всех изменений, включая ложные, и приводит её к состоянию чистой конфигурации поставщика.
5. Включаем возможность редактирования: В Конфигураторе, после загрузки конфигурации поставщика, мы включаем возможность редактирования для всех объектов. Это гарантирует, что мы сможем вносить необходимые изменения.
6. Сравниваем и объединяем свои модификации: Теперь мы выполняем операцию сравнения и объединения. Мы сравниваем нашу текущую, но уже "очищенную" конфигурацию (которая сейчас соответствует конфигурации поставщика из шага 4) с нашим файлом "МояКонфигурация_Текущая.cf" (который мы сохранили на шаге 1). На этом этапе система обнаружит только наши реальные доработки, а ложные изменения справочной информации будут проигнорированы, так как в обеих сравниваемых конфигурациях (после шага 4) они будут отсутствовать или иметь одинаковые актуальные значения. Мы переносим свои доработки, внимательно разрешая конфликты.
7. Обновляем конфигурацию базы данных: После успешного сравнения и объединения, когда все наши доработки перенесены, а ложные изменения справочной информации устранены, мы обновляем конфигурацию базы данных. При правильном выполнении предыдущих шагов, предупреждений об измененных объектах, которые не должны были меняться, быть не должно.

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

Мы должны учитывать следующие моменты при использовании этого алгоритма:

• Конфигурации, подключенные к хранилищу: Этот алгоритм может быть сложен или даже невозможен для применения к конфигурациям, которые подключены к хранилищу. Работа с хранилищем подразумевает другой подход к обновлению и объединению изменений, обычно через механизмы хранилища. Для таких случаев, как указано в сообщении 21, может потребоваться выгрузка конфигурации из хранилища, применение алгоритма в отдельной базе, а затем обратная загрузка изменений, что не всегда практично и может быть сопряжено с дополнительными сложностями.
• Повторное применение: Как отмечается в сообщении 18, этот подход "будет работать, пока конфа поставщика снова не поменяется". При каждом следующем обновлении конфигурации поставщика, возможно, потребуется снова выполнять эти "танцы с бубном", если проблема вновь проявится.
• Файл ConfigDumpInfo: В случае с хранилищем, даже если объекты не менялись, различие в файле ConfigDumpInfo (служебный файл версий, который содержит информацию о формате выгрузки и версиях объектов) может приводить к долгим сравнениям и фиксации изменений (Сообщение 21). Этот алгоритм может помочь устранить различия в содержимом объектов, но не всегда влияет на служебные метаданные ConfigDumpInfo напрямую.

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

Дополнительные рекомендации и общие подходы

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

1. Актуализация платформы: Всегда стремимся использовать наиболее актуальную и стабильную версию платформы 1С:Предприятие. Как мы выяснили, новые версии платформы, особенно начиная с 8.3.14, решают многие проблемы, связанные с HTML-рендерингом и сравнением, благодаря переходу на WebKit. Это фундаментальный шаг, который позволяет избежать многих трудностей.
2. Совместимость версий платформы и конфигурации: Важно следить за режимом совместимости конфигурации и используемой платформой. Иногда проблема ложных сравнений может исчезнуть при установке режима совместимости, соответствующего текущей платформе (например, режим совместимости 8.3.14 на платформе 8.3.18). Рекомендуем устанавливать максимально возможный режим совместимости, соответствующий текущей рабочей платформе.
3. Анализ изменений в ПолеHTMLДокумента: Если в вашей конфигурации есть собственный код, который программно взаимодействует с HTML-документами через ПолеHTMLДокумента (например, для динамического изменения содержимого или вызова JavaScript-функций), нам необходимо тщательно проверить его на предмет совместимости с движком WebKit. Код, специфичный для Internet Explorer, может не работать корректно и требовать переработки под новую DOM-модель.
4. Работа с хранилищем конфигураций: При использовании хранилища конфигураций критически важно поддерживать согласованные версии платформы у всех разработчиков. Использование разных версий платформы с одним хранилищем может привести к непредсказуемым проблемам и ошибкам при сравнении, объединении и фиксации изменений. Для анализа изменений в хранилище используем функцию "Выборочное сравнение с объектом хранилища", которая может помочь сфокусироваться на нужных свойствах объекта.
5. Обращение в техническую поддержку 1С: Если все вышеперечисленные шаги не приводят к желаемому результату, или если мы сталкиваемся с новыми, необъяснимыми различиями (как в сообщениях 28, 29, где проблемы слияния проявлялись даже в 8.3.24), обязательно обращаемся в техническую поддержку 1С. Предоставляем им максимально подробную информацию о версии платформы, конфигурации и, если возможно, шагах для воспроизведения проблемы. Настойчивость в этом вопросе может привести к решению или фиксации проблем в будущих релизах.
6. Резервное копирование: Перед любыми операциями по обновлению, сравнениям или объединениям конфигураций всегда делаем полные резервные копии информационной базы. Это золотое правило позволяет избежать потери данных и оперативно вернуться к рабочему состоянию в случае непредвиденных проблем.
7. Фокус на существенных изменениях: При сравнении/объединении, если мы знаем, что справочная информация визуально не менялась, но система продолжает фиксировать различия в служебных тегах, мы можем игнорировать эти изменения, если они не влияют на функциональность и работоспособность системы. Хотя это и не решает проблему на системном уровне, но позволяет продолжить процесс обновления, не застревая на ложных конфликтах.

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