Разработка и Конфигурация · 9 мин
Как сравнить две обработки в 1С
Способы сравнения двух внешних обработок 1С: через конфигуратор, EDT и сторонние инструменты. Проверка различий в коде, формах и макетах, типичные ошибки.
Задача сравнить две внешние обработки возникает в типовых ситуациях: поставщик прислал новую версию файла .epf, и нужно понять, что изменилось; в базе работает старая обработка, а в хранилище лежит доработанная; сотрудник внёс правки в копию, и теперь надо выловить отличия перед объединением. Во всех случаях вопрос один — найти различия в коде модулей, формах и макетах, не потеряв рабочую функциональность.
Внешняя обработка (.epf) — это бинарный контейнер, внутри которого лежат модули, формы, макеты и метаданные. Просто открыть два файла текстовым редактором и «посмотреть глазами» не получится: содержимое зашифровано внутренним форматом платформы. Поэтому сравнение делается либо штатными средствами конфигуратора, либо через выгрузку в исходные файлы, либо сторонними утилитами сравнения.
Ниже разобраны рабочие способы: от встроенного механизма «Сравнить, объединить» до выгрузки в XML и сравнения внешними diff-инструментами. Отдельно описаны проверка результата, типичные ошибки и ограничения каждого метода.
Что именно сравнивается внутри обработки
Внешняя обработка состоит из нескольких слоёв, и различия могут скрываться в любом из них. Модуль объекта и модуль формы содержат код на встроенном языке — это самая частая зона изменений. Формы хранят структуру элементов, реквизиты и обработчики событий. Макеты содержат табличные документы, схемы компоновки данных или двоичные данные.
Кроме того, у обработки есть свойства: имя, синоним, комментарий, версия (если разработчик её заполняет). Различие в версии — первый признак того, что файлы не идентичны, но полагаться только на него нельзя: поле версии заполняется вручную и часто остаётся пустым.
Практический вывод: полноценное сравнение должно охватывать модули, формы и макеты. Сравнение «по размеру файла» или по дате изменения ничего не даёт — два файла разного размера могут быть функционально идентичны, а файлы одинакового размера — содержать критичные отличия в коде.
Способ 1. Сравнение через конфигуратор
Штатный механизм платформы позволяет сравнить внешнюю обработку с конфигурацией базы или с другой обработкой. Порядок действий для сравнения двух файлов .epf: откройте первую обработку в конфигураторе через «Файл — Открыть». Затем в меню «Конфигурация» выберите пункт «Сравнить, объединить с конфигурацией из файла» и укажите второй файл обработки.
Платформа построит дерево различий: вы увидите, какие объекты (формы, макеты, модули) отличаются. Двойной щелчок по строке модуля открывает построчное сравнение текстов — добавленные строки, удалённые и изменённые подсвечиваются разными цветами. Это самый быстрый способ увидеть суть правок, если обработки имеют одинаковую внутреннюю структуру.
Ограничение метода: механизм «Сравнить, объединить» ориентирован на конфигурации, и с внешними обработками работает не во всех версиях платформы одинаково стабильно. Если вариант с прямым сравнением файлов недоступен, используйте обходной путь — создайте пустую конфигурацию, загрузите в неё структуру первой обработки, затем сравните со второй.
- 1Откройте первую обработку: Файл — Открыть — выберите .epf
- 2Выполните Конфигурация — Сравнить, объединить с конфигурацией из файла
- 3Укажите второй файл .epf и дождитесь построения дерева различий
- 4Откройте изменённые модули двойным щелчком для построчного сравнения
- 5Просмотрите отличия форм и макетов, при необходимости объедините изменения
Способ 2. Выгрузка в исходные файлы и сравнение diff-инструментом
Более надёжный и гибкий метод — выгрузить обе обработки в исходные XML-файлы и сравнить каталоги. В конфигураторе для этого используется команда «Конфигурация — Выгрузить конфигурацию в файлы» применительно к открытой обработке либо пакетный режим запуска конфигуратора с параметрами выгрузки. В результате получается дерево XML-файлов: модули выгружаются как текст внутри XML, формы и макеты — в структурированном виде.
Дальше два каталога сравниваются любым инструментом: KDiff3, WinMerge, Beyond Compare, встроенным сравнением в VS Code или Git. Такой подход показывает различия не только в коде, но и в свойствах форм, реквизитах, макетах — всё, что отличается, будет видно на уровне файлов.
Дополнительный плюс: выгруженные исходники можно положить в систему контроля версий. Тогда сравнение любых двух версий обработки в будущем сводится к стандартному git diff, а история изменений сохраняется. Это рекомендуемая практика для обработок, которые регулярно дорабатываются.
"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"C:\Bases\TestBase" /DumpExternalDataProcessorOrReportToFiles "C:\src\obrabotka1" "C:\Files\Obработка1.epf"Способ 3. Сравнение в 1C:EDT
Если разработка ведётся в 1C:Enterprise Development Tools, обработки импортируются в проекты, и сравнение выполняется штатными средствами среды: «Сравнить с — Друг с другом» для двух проектов или через локальную историю и Git. EDT хранит обработку в виде набора файлов, поэтому diff работает корректно и наглядно.
Этот вариант удобен, когда обработки уже живут в инфраструктуре EDT. Минус — на импорт и настройку проектов уходит время, поэтому для разового сравнения двух файлов проще использовать конфигуратор или выгрузку в XML.
Сравнение способов
Быстро для разовой проверки; ограничение — не всегда корректно работает с парой внешних файлов
Самый полный охват различий, подходит для Git; требует больше действий
Удобно при постоянной разработке в EDT; избыточно для разового сравнения
Как проверить результат сравнения
Найти различия — половина задачи. Вторая половина — убедиться, что вы правильно поняли характер изменений и не пропустили критичные правки. Обязательно просмотрите модуль объекта и модули всех форм: именно там сосредоточена логика. Изменения в макетах печатных форм проверяйте визуально, открыв оба макета рядом.
После объединения изменений или выбора одной из версий выполните синтаксическую проверку модуля (в конфигураторе — через меню «Текст» либо при сохранении) и запустите обработку в тестовой базе. Проверьте основной сценарий работы: формирование отчёта, проведение документов, выгрузку данных — то, ради чего обработка существует.
Контрольные точки
Проверка модулей завершается без ошибок
Ошибки компиляции после объединения — потеряны куски кода
Обработка открывается, форма отображается, основной сценарий выполняется
Ошибка при открытии формы или в середине выполнения
Отчёт/выгрузка совпадают с ожидаемыми данными на контрольном примере
Расхождения в итогах, пустые или лишние строки
Типичные ошибки и риски
Самая частая ошибка — сравнение только модулей с игнорированием форм и макетов. Изменение в форме (например, новый обязательный реквизит) ломает логику не меньше, чем правка кода. Вторая ошибка — объединение «вслепую»: принятие всех изменений из одного файла без анализа, из-за чего затираются нужные доработки из другого.
Отдельный риск — запуск непроверенной внешней обработки в рабочей базе. Обработка из внешнего источника может содержать код, изменяющий или удаляющий данные. Перед первым запуском просмотрите модули на предмет прямых запросов, удаления объектов, обращений к внешним ресурсам, и выполняйте первые испытания только на копии базы.
Часто задаваемые вопросы
Можно ли сравнить две обработки без конфигуратора?
Да, если выгрузить их в исходные файлы заранее — тогда достаточно любого diff-инструмента (WinMerge, KDiff3, Git). Сами файлы .epf текстовыми редакторами не сравниваются, так как имеют внутренний бинарный формат платформы.
Почему конфигуратор показывает, что обработки идентичны, хотя файлы разного размера?
Размер файла зависит от служебной информации и внутренней упаковки, а не только от содержимого. Если дерево сравнения пустое, значит, модули, формы и макеты совпадают, а разница в размере вызвана техническими данными контейнера.
Как сравнить обработку из базы с файлом на диске?
Если обработка подключена как дополнительная (через «Дополнительные отчеты и обработки»), сначала сохраните её на диск из справочника дополнительных обработок, затем сравните два файла .epf любым из описанных способов.
Что делать, если обработки имеют разную структуру и не сравниваются?
Разная внутренняя структура (переименованные формы, другое устройство объектов) затрудняет автоматическое сравнение. В этом случае выгрузите обе в исходные файлы и сопоставляйте модули вручную по соответствующим файлам, ориентируясь на смысл процедур и функций.
Можно ли автоматизировать сравнение при каждом обновлении от поставщика?
Да. Настройте выгрузку обработки в исходные файлы пакетной командой конфигуратора и храните их в Git. Каждая новая версия от поставщика выгружается туда же, и различия видны через стандартный git diff или git log.
Что важно запомнить
Две обработки 1С сравнивают через конфигуратор, выгрузку в исходные XML-файлы с внешним diff-инструментом или в 1C:EDT. Проверяйте модули, формы и макеты, а не размер файла. Объединение и запуск выполняйте только на копии базы после синтаксической проверки.