Перенос доработок 1С на новую конфигурацию: методика ревизии без документации

Перенос доработок 1С на новую конфигурацию без документации делается через ревизию: сначала собираются все места, где могут жить доработки, затем каждая доработка вычленяется по ключевым словам (имена реквизитов, процедур, элементов форм), описывается в реестре, оценивается на актуальность и только потом переносится. Ключевой приём — удалять уже описанные доработки из рабочей копии конфигурации и повторять поиск, пока он не станет пустым. Так ни одна связанная правка не потеряется.

Методика выработана на переходах вроде 1С:Документооборот 2.1 → 3.0 и подходит для УПП → ERP, ERP → ERP УХ и любых переездов на схожую конфигурацию. Её же удобно использовать просто для инвентаризации: составить список доработок и вычистить устаревшие.

Когда нужна такая методика

Она оправдана, если:

• аналитики и разработчики знают доработки частично или не знают совсем;
• документации нет, ТЗ потеряны или неполны;
• на проекте сменилось несколько команд;
• после перехода нельзя допустить, чтобы «что-то тихо перестало работать».

Если все доработки задокументированы и их автор рядом — методика избыточна, достаточно реестра.

Шаг 1. Соберите все источники доработок

Доработки живут не только в конфигурации. Полный список:

1. Основная конфигурация — изменённые и добавленные объекты.
2. Расширения конфигурации.
3. Дополнительные отчёты и обработки из справочника подсистемы БСП.
4. Внешние отчёты и обработки, которые открывают через «Файл — Открыть». Их ищут у пользователей на дисках и в общих папках.
5. Код в данных — тексты, которые хранятся в реквизитах (обычно строки неограниченной длины) и выполняются через Выполнить или Вычислить: формулы, правила, обработчики событий.
6. Интеграции — правила обмена, веб- и HTTP-сервисы, файловые обмены. У смежной системы — те же источники, и их тоже надо проверить.

Не исключайте источники из поиска, даже если уверены, что «там ничего нет» или «это я сам делал». Пропущенный источник — это доработка, которая всплывёт после переезда в виде ошибки.

Шаг 2. Подготовьте рабочее окружение

• Пустая база с текущей конфигурацией — в ней вы будете удалять уже описанные доработки.
• Актуальная копия рабочей базы — для проверки поведения и отладки, когда из кода непонятно, что делает доработка.
• Папка с выгрузками — дополнительные и внешние обработки, код из данных (можно в один текстовый файл).
• Выгрузка конфигурации в файлы — для поиска сторонними средствами по всем источникам сразу.

Выгрузить конфигурацию можно в пакетном режиме конфигуратора:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\Bases\Revizia" /N "Администратор" /P "" /DumpConfigToFiles "D:\Revizia\cf"

После этого поиск по ключевому слову сразу по всем источникам — одна команда (здесь пример для Git Bash или Linux):

grep -rniI --include="*.bsl" --include="*.xml" --include="*.txt" "ЯвляетсяСтратегическимПартнером" /d/Revizia/

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

Шаг 3. Цикл вычленения доработки

1. Запустите сравнение с конфигурацией поставщика и выберите изменение для разбора. Удобно начинать с новых реквизитов ключевых объектов — это самые заметные доработки, от них тянутся остальные.
2. Выпишите ключевые слова: имя реквизита, объекта, процедуры, переменной, элемента формы.
3. Удалите найденное из рабочей копии.
4. Сделайте глобальный поиск по ключевым словам по всем источникам.
5. Найденные места добавьте в реестр, новые имена — в ключевые слова, код удалите. Повторяйте шаги 3–5, пока поиск не станет пустым.
6. Перезапустите сравнение с конфигурацией поставщика — после удалений оно устарело.

Важная деталь: удаление — не формальность. Оно гарантирует, что при следующем сравнении вы увидите только неописанные доработки, а повторный поиск найдёт «хвосты», которые ссылаются на удалённое.

Пример

Сравнение показывает, что у справочника Контрагенты добавлен булев реквизит ЯвляетсяСтратегическимПартнером. Удаляем его и ищем по имени. В форме документа РасходнаяНакладная, в процедуре управления видимостью, находится код с комментарием автора и номером задачи: если контрагент — стратегический партнёр, показывается табличная часть ДополнительныйКонтрольСделкиПоСтратегическимПартнерам.

Добавляем в ключевые слова имя табличной части, удаляем код и саму табличную часть, ищем снова. Находится обработчик в модуле менеджера, который рассылает оповещения сотрудникам из этой табличной части при проведении. Ещё один круг — и поиск пустой. Доработка вычленена полностью.

Шаг 4. Реестр доработок

Реестр можно вести в таблице с такими колонками (состав меняйте под проект):

Для примера выше запись выглядит так: «Для контрагентов — стратегических партнёров в расходной накладной заполняется список сотрудников, которым приходит оповещение о проведении документа». Источники информации — комментарии в коде, история хранилища конфигурации, копия базы и отладка.

Шаг 5. Оценка актуальности

Перед переносом каждую доработку проверяют:

• Используется ли она. Простой запрос к копии рабочей базы часто отвечает на вопрос лучше любого интервью:

ВЫБРАТЬ
	КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Строки.Ссылка) КАК Документов,
	МАКСИМУМ(Строки.Ссылка.Дата) КАК ПоследнийДокумент
ИЗ
	Документ.РасходнаяНакладная.ДополнительныйКонтрольСделкиПоСтратегическимПартнерам КАК Строки

Если табличная часть не заполнялась два года — доработка, скорее всего, мертва.

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

Шаг 6. Перенос

Переносите доработки по одной и сразу тестируйте. Учтите:

• Конфигурации разные. Названия объектов, модулей и типовых процедур могут отличаться; иногда доработку проще написать заново, чем адаптировать.
• Используйте расширения. Всё, что можно сделать расширением, делайте расширением — новая типовая конфигурация останется на поддержке. Подробнее о подходе — в расширениях 1С.
• Рефакторинг по пути. Перенос — удобный момент привести код к стандартам: ЭтотОбъект вместо ЭтаФорма, функции БСП вместо самописных аналогов, понятные имена, комментарии с номером задачи.
• Тестовые сценарии. Для каждой перенесённой доработки — короткий сценарий проверки. Он пригодится и при следующих обновлениях.

Типичные ошибки

• Начать перенос до инвентаризации. Часть доработок обнаруживается после запуска — уже на рабочих данных.
• Искать только в конфигурации. Внешние обработки и код в данных теряются чаще всего.
• Переносить всё «как было». В новой конфигурации половина доработок может оказаться не нужна или реализована типово.
• Не фиксировать решения. Через полгода никто не вспомнит, почему доработку не перенесли.
• Вносить перенесённое в основную конфигурацию. Новая система сразу снимается с поддержки, и выгода от переезда пропадает при первом обновлении.

Хорошая ревизия доработок окупается дважды: при переезде — меньшим числом ошибок, после — документацией, которой раньше не было.

Переход на новую конфигурацию и инвентаризацию доработок я провожу в рамках аудита 1С и обновления 1С, в том числе при переходе на 1С:Документооборот 3.0.

Итог

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