При работе с конфигурациями 1С, особенно в процессе обновления или миграции (например, с редакции 2.0 на 3.0), программисты часто сталкиваются с раздражающей ситуацией: отчет о сравнении и объединении показывает изменения в макетах, которые фактически не редактировались. Сообщение выглядит примерно так: "Различаются признаки модифицированности; Основная конфигурация - Модифицируется, Конфигурация поставщика - не модифицируется". При этом визуальное сравнение самих табличных документов не выявляет никакой разницы в тексте, формулах или оформлении ячеек.
В этой статье мы подробно разберем, почему платформа 1С помечает объекты как измененные, когда визуальных отличий нет, и как привести конфигурацию в порядок, чтобы видеть только реальные доработки.
Проанализируем ситуацию: макет в 1С (объект типа ТабличныйДокумент) — это не просто набор строк и колонок. Это сложный объект, который сохраняется в информационной базе в виде бинарных данных или XML-структуры (в зависимости от версии платформы и способа хранения). Существует несколько скрытых факторов, которые заставляют платформу считать макет "измененным":
MXL хранят в себе информацию о настройках печати, актуальных на момент последнего сохранения. Сюда относится имя принтера, установленного в системе по умолчанию, специфические поля, масштаб и даже версия драйвера. Если разработчик фирмы "1С" сохранил макет с настройками принтера "HP LaserJet", а вы открыли и сохранили его в системе, где стоит "Canon" или "Microsoft Print to PDF", бинарный слепок объекта изменится.Версия 8.2.16) напрямую влияет на то, как объекты сериализуются (записываются) в базу данных. При сравнении конфигураций с разными режимами совместимости или на разных версиях платформы (даже если релиз конфигурации один и тот же), алгоритм хеширования данных может выдавать разные результаты.Рассмотрим по шагам, как можно избавиться от ложных признаков модифицированности, чтобы отчет о сравнении показывал только реальные изменения.
Если вы уверены, что ваша конфигурация должна полностью соответствовать типовой (конфигурации поставщика) по части макетов, самый эффективный способ — это полная загрузка файла .cf.
Важно: этот метод затрет все ваши уникальные доработки, поэтому используйте его только в том случае, если база должна стать полностью типовой, или если вы предварительно сохранили свои изменения.
1cv8.cf нужного релиза.Этот метод гарантированно очищает таблицу Config в базе данных SQL, удаляя все старые метки и несоответствия форматов.
Если полная загрузка невозможна из-за большого количества доработок в других объектах, попробуем исправить конкретные макеты. Выясним, не виноваты ли в этом настройки принтера.
Однако, как показывает практика, этот метод помогает редко, так как само сохранение макета в вашем окружении может снова прописать данные вашего текущего принтера в бинарный код макета.
Проанализируем ситуацию на более глубоком уровне. Платформа позволяет выгружать файлы конфигурации в формат XML. Это дает нам возможность увидеть реальную разницу в текстовом виде.
Часто вы увидите разницу в одну строку, например:
<version>2.11</version> против <version>2.13</version>
Или наличие блока настроек печати:
<printerName>HP LaserJet 1020</printerName>
<fields>
<left>10</left>
</fields>
Если разница только в этом, можно скопировать содержимое XML из типовой конфигурации в вашу и загрузить конфигурацию обратно из файлов. Это "хирургический" способ очистки объекта.
Иногда признак модифицированности "залипает" в локальном кэше конфигуратора. Вы объединили объекты, сохранили, но отчет продолжает показывать различия. В этом случае стоит выполнить очистку кэша:
%AppData%\1C\1cv8\).Посмотрим на ситуацию со стороны стратегии обновления. Если ваша задача — поднять конфигурацию Бухгалтерия предприятия 2.0 до актуальной версии 3.0, то борьба с признаками модифицированности в макетах редакции 2.0 часто лишена практического смысла.
Переход на редакцию 3.0 — это фактически полная замена старой конфигурации на новую. Большинство объектов редакции 2.0 (включая макеты печатных форм) при обновлении на 3.0 будут либо удалены, либо заменены на новые версии, работающие на управляемых формах. Все "фантомные" изменения макетов из старой базы исчезнут сами собой в процессе трансформации структуры данных.
Рекомендация: если при сравнении вы видите, что визуальных отличий в макетах нет, и они не содержат ваших уникальных правок (логотипов, измененных формулировок), просто игнорируйте эти различия или примите их из конфигурации поставщика один раз. Не тратьте ресурсы на достижение "идеальной чистоты" сравнения в переходной базе, так как это не повлияет на работоспособность итоговой системы на редакции 3.0.
Подведем итог. Признак модифицированности в макетах 1С часто является следствием технического "шума": разницы в версиях форматов, настроек принтеров или режимов совместимости. Использование методов загрузки .cf или анализа XML позволяет решить проблему, но при глобальных обновлениях конфигурации этим зачастую можно пренебречь.