При сопровождении и разработке в среде 1С программисты часто сталкиваются с классической дилеммой: есть одна базовая измененная конфигурация (например, доработанная под общие нужды холдинга «1С:Бухгалтерия»), но у каждой входящей в нее организации («конторы») есть свои уникальные локальные требования. В итоге мы получаем несколько слегка различающихся конфигураций. При выходе очередного обновления от фирмы «1С» поддержка этого «зоопарка» превращается в кошмар: приходится тратить десятки часов на ручной перенос галочек в окне сравнения и объединения.
В этой статье мы подробно разберем, как решить эту проблему. Мы рассмотрим как быстрый практический способ автоматизации рутинного обновления с помощью файлов настроек сравнения .v8cfg, так и более продвинутые архитектурные подходы, которые позволят вам раз и навсегда отказаться от поддержки нескольких конфигурационных веток.
Если конфигурации уже сильно разошлись и объединить их в одну базу прямо сейчас невозможно, наиболее быстрым и рабочим решением будет использование файлов настроек сравнения и объединения. Рассмотрим этот алгоритм по шагам.
Суть метода заключается в том, чтобы один раз вручную сопоставить изменения конкретной дочерней фирмы с базовой измененной конфигурацией, зафиксировать эти настройки в специальный файл правил, а при последующих обновлениях применять этот файл автоматически.
Шаг 1. Фиксация изменений в модулях
Для того чтобы платформа стабильно определяла изменения в общих модулях и модулях форм конкретного клиента, нам нужно гарантировать, что эти изменения будут распознаны при сравнении. Автор темы нашел изящный лайфхак: при редактировании кода в модулях для конкретного клиента мы добавляем незначительное отличие (например, пробел или комментарий). Это заставит платформу вывести правило объединения для модуля. В окне сравнения и объединения мы настраиваем правила для каждого объекта.
Шаг 2. Сохранение настроек сравнения
После того как все флажки расставлены, а правила настроены (например, для уникальных реквизитов выбрано «Взять из конфигурации получателя», а для общих — «Объединять с приоритетом»), мы не выполняем объединение сразу, а переходим в меню окна сравнения и выбираем пункт «Сохранить настройки». Платформа предложит сохранить файл с расширением .v8cfg.
Этот файл в формате XML содержит детальное описание того, какие объекты метаданных и по каким правилам должны переноситься. Пример структуры такого файла выглядит следующим образом:
<Object fullNameInSecondConfiguration="Document.ДоговорКредита.Attribute.Подразделение">
<MergeRule>GetFromSecondConfiguration</MergeRule>
</Object>
Шаг 3. Применение правил при обновлении
Когда выходит новое типовое обновление от 1С:
.cf..cf-файлом базовой конфигурации..v8cfg для этой конторы.Шаг 4. Полная автоматизация через командную строку
Процесс применения сохраненных правил можно полностью автоматизировать с помощью скрипта командной строки. Платформа «1С:Предприятие» поддерживает пакетный запуск конфигуратора. Нам не нужно открывать интерфейс вручную для десятка баз. Напишем bat-файл следующего содержания:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "C:\Put_K_Baze_Clienta" /N "Администратор" /P "Пароль" /MergeCfg "C:\Base_Updated.cf" /ConfigurationComparisonRules "C:\Rules_Client1.v8cfg" /UpdateDBCfg
Разберем параметры запуска подробнее:
DESIGNER — запуск платформы в режиме конфигуратора./F — путь к файловой информационной базе клиента (для клиент-серверного варианта используйте /S)./MergeCfg — указывает путь к новому файлу конфигурации, с которым происходит объединение./ConfigurationComparisonRules — указывает путь к нашему сохраненному файлу настроек .v8cfg. Платформа применит правила сравнения автоматически в фоновом режиме./UpdateDBCfg — запускает обновление конфигурации базы данных после успешного слияния метаданных.Используя этот подход, мы можем обновить неограниченное количество баз клиентов в один клик, просто запустив скрипт поочередно для каждого узла.
Несмотря на удобство файлов .v8cfg, ведение нескольких физически разных конфигураций для дочерних фирм в долгосрочной перспективе считается антипаттерном разработки. Гораздо надежнее и проще сопровождать одну общую измененную конфигурацию для всех клиентов, в которой функционал разделен логически.
Выясним, как правильно организовать архитектуру такого решения:
Вместо физического удаления или добавления реквизитов под конкретную фирму мы добавляем все необходимые объекты метаданных в единую конфигурацию. Ограничение видимости этих объектов для пользователей разных фирм настраивается через системный механизм — Функциональные опции (ФО).
ИспользоватьУчетКредитовПоФирме1) с типом Булево.ФункциональнаяОпция, привязываем ее к созданной константе.Истина.Если для разных фирм требуется разное расположение элементов на формах, откажитесь от визуального изменения форм в конфигураторе. Перенесите эту логику в код модуля формы. Для этого задействуем обработчик события ПриСозданииНаСервере.
Посмотрим на пример кода, который динамически изменяет форму в зависимости от текущей организации:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Получаем текущую организацию из документа или настроек пользователя
ТекущаяОрганизация = Объект.Организация;
ИННОрганизации = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(ТекущаяОрганизация, "ИНН");
// Если это Фирма 1 (проверка по ИНН или константе)
Если ИННОрганизации = "7701010101" Тогда
// Динамически создаем или показываем нужную кнопку
НовыйЭлемент = Элементы.Добавить("КнопкаСпецРасчета", Тип("КнопкаФормы"), Элементы.КоманднаяПанель);
НовыйЭлемент.Заголовок = "Спец. Расчет для Фирмы 1";
НовыйЭлемент.ИмяКоманды = "ВыполнитьСпецРасчет";
КонецЕсли;
КонецПроцедуры
Такой подход гарантирует, что при обновлении типовой формы от фирмы «1С» у вас не возникнет конфликтов интерфейса. Форма останется полностью типовой, а ваши доработки применятся динамически в момент открытия формы пользователем.
Если вы хотите держать основную конфигурацию максимально близкой к типовой («на замке»), используйте механизм расширений. Для каждого клиента создается индивидуальное расширение (файл .cfe).
Многие разработчики отказываются от расширений, так как их неудобно сравнивать обычными методами в конфигураторе. Однако современные возможности платформы позволяют обойти это ограничение:
Расширение_Контора1. При обновлении основной базы само расширение не затрагивается, если структура заимствованных объектов не претерпела критических изменений.Для крупных проектов с большим количеством индивидуальных внедрений стандартом разработки является использование среды 1C:EDT (Enterprise Development Tools) в связке с системой контроля версий Git.
Рассмотрим, как организуется процесс параллельного ведения версий в этом случае:
master. В этой ветке ведутся индивидуальные доработки только для конкретной фирмы.master. Разрешаем конфликты с поставщиком только один раз.client-company1 и выполняем команду объединения веток: git merge master (или git rebase master).Использование Git полностью избавляет от необходимости вручную формировать файлы обновлений .cfu или сравнивать огромные конфигурации визуально в старом конфигураторе.
Мы проанализировали несколько методов решения проблемы обновлений нетиповых конфигураций. Выбор конкретного инструмента зависит от ресурсов и текущего состояния ваших баз:
.v8cfg (Решение 1). Это сэкономит вам до 90% времени при рутинном обновлении.