При администрировании и внедрении систем на платформе 1С:Предприятие часто возникает вопрос о правильном методе создания новой информационной базы. Штатный механизм предлагает установку из шаблонов, однако технически платформа позволяет создать абсолютно пустую базу и загрузить в нее файл конфигурации (.cf). Разберем подробно, какие риски несет второй подход, в чем разница между источниками развертывания и как избежать проблем на старте проекта.
Для начала давайте проанализируем, что именно содержат файлы, с которыми мы работаем. Это понимание необходимо для оценки последствий.
1. Файл конфигурации (.cf)
Этот файл содержит исключительно метаданные (структуру справочников, документов, регистров) и программный код. В нем также хранятся предопределенные элементы, созданные разработчиком в конфигураторе. Однако в нем полностью отсутствуют пользовательские данные.
2. Файл выгрузки информационной базы (.dt) внутри шаблона
Когда вы устанавливаете конфигурацию через setup.exe, в каталог шаблонов часто распаковывается именно .dt файл (хотя бывает и .cf, об этом ниже). Файл .dt — это слепок уже существующей базы. Это значит, что разработчик (будь то фирма "1С" или партнер, например, "Рарус") предварительно запустил базу, выполнил первоначальные настройки и сохранил этот результат.
Если мы решаем проигнорировать шаблон и загрузить .cf в пустую базу, мы можем столкнуться со следующими проблемами.
В шаблонах (.dt) часто уже загружены общероссийские классификаторы (ОКОФ, валюты, банки), календари и служебные справочники. При загрузке .cf эти справочники будут девственно чисты. Вам придется тратить время на поиск и загрузку этих данных вручную, иначе часть функционала (например, проверка контрагентов или расчет амортизации) не заработает сразу.
Современные конфигурации построены на базе Библиотеки Стандартных Подсистем (БСП). При первом запуске базы, созданной из .cf, система понимает, что она "пустая", и запускает механизм начального заполнения.
Рассмотрим, что происходит "под капотом":
Этот процесс может занимать от 10 до 40 минут в зависимости от мощности сервера. Если вы разворачиваете базу из .dt, этот этап уже пройден вендором, и вы экономите это время (Time-to-Value).
Кроме того, на слабых серверах или при использовании файлового варианта базы, тяжелые транзакции первоначального заполнения могут отвалиться по таймауту, оставив базу в полурабочем, "битом" состоянии.
В обсуждаемой теме упоминается поставщик "Рарус". Для отраслевых решений риск кратно возрастает. Часто такие конфигурации используют внешние компоненты защиты (СЛК, Катран). Параметры подключения к серверу лицензирования могут быть прописаны в константах базы-шаблона.
Если развернуть такую базу из .cf, настройки защиты будут пустыми. Система может либо не запуститься вовсе, либо запуститься в демо-режиме, либо требовать ввода параметров, которые обычный пользователь не знает.
Существует тонкий технический нюанс. При загрузке .cf в пустую базу платформа заново генерирует записи для предопределенных элементов в таблицах базы данных. В редких случаях (особенно если конфигурация обновлялась нештатно) уникальные идентификаторы (UUID) этих элементов могут отличаться от тех, что были бы в базе, развернутой из .dt.
Это может привести к проблемам при настройке обменов (синхронизации) с другими базами, где правила обмена "завязаны" на конкретные GUID предопределенных элементов.
Перед развертыванием базы полезно заглянуть в "манифест" поставки. Это текстовый файл с расширением .mft, который находится в каталоге шаблонов после установки дистрибутива.
Посмотрим на пример содержимого файла манифеста для конфигурации "Комплексная автоматизация":
Name=1С:Комплексная автоматизация 2
Vendor=Фирма "1С"
AppVersion=8.3
Version=2.5.15.103
[Config1]
Catalog=1С:Комплексная автоматизация 2/Комплексная автоматизация 2
Destination=1C\ARAutomation20
Source=1cv8.cf
[Config2]
Catalog=1С:Комплексная автоматизация 2/Комплексная автоматизация 2 (демо)
Destination=1C\DemoARAutomation20
Source=1cv8.dt
Обратите внимание на параметр Source:
Source=1cv8.cf — разработчик предполагает создание чистой базы именно из файла конфигурации. Это означает, что механизмы БСП гарантированно отработают корректно и заполнят всё необходимое.Source=1cv8.dt — разработчик настоятельно рекомендует использовать дамп базы. В этом случае "самодеятельность" с загрузкой .cf нежелательна.Интересный факт: начиная с определенных релизов (например, Бухгалтерия Предприятия 3.0.100+), фирма "1С" перестала включать .cf файл в полные дистрибутивы для создания новых баз, оставив только .dt. Это связано с тем, что конфигурации стали слишком сложными, и надежнее передавать пользователю уже "прогретую" и настроенную базу.
Подведем итог и сформулируем алгоритм действий для администратора.
Сценарий 1: У вас типовая конфигурация (ERP, KA, УТ)
Развертывание из .cf допустимо. Современные типовые конфигурации на БСП (Библиотека Стандартных Подсистем) умеют инициализировать себя сами. При первом запуске автоматически запустятся обработчики обновления информационной базы.
Однако будьте готовы подождать завершения начального заполнения и вручную догрузить классификаторы.
Сценарий 2: У вас отраслевое решение (Рарус, Агрософт и т.д.)
Развертывание из .cf рискованно. Мы настоятельно рекомендуем использовать штатный установщик и создавать базу из шаблона. Это убережет вас от:
Если у вас на руках только .cf файл (например, вам его прислали почтой без полного дистрибутива), выполните следующие шаги после загрузки:
Идеальный вариант: Всегда следуйте логике, заложенной вендором в файле манифеста (.mft). Если вендор поставляет .dt для чистой базы — используйте его.