← На главную

Обновление нетиповых конфигураций «1С:Предприятие» — процесс, требующий от разработчика предельной концентрации внимания. Особенно сложным и ответственным шагом является переход между редакциями, например, перевод старой «Бухгалтерии предприятия» редакции 2.0 (работающей на обычных формах) на современную редакцию 3.0 (на управляемых формах). На этом пути программисты часто сталкиваются с неочевидными техническими препятствиями. Одно из наиболее распространенных и неприятных — системное сообщение «Файл не содержит доступных обновлений».

При этом визуально все требования платформы соблюдены: конфигурация находится на поддержке с возможностью изменения, релиз основной конфигурации и конфигурации поставщика в окне «Настройка поддержки» полностью совпадают, а дистрибутив обновления (файл формата cfu) скачан именно для перехода между редакциями (например, переходный дистрибутив с версии 2.0.66.77 на 3.0.70.33).

В этой статье мы подробно разберем, почему Конфигуратор отказывается видеть файл обновления, какие скрытые механизмы платформы 1С здесь задействованы, проанализируем риски популярных «кустарных» методов решения и рассмотрим по шагам максимально безопасный, профессиональный алгоритм восстановления конфигурации поставщика.

Выясняем глубинную причину ошибки: почему «не видятся» обновления

Ошибка «Файл не содержит доступных обновлений» при ручном выборе файла обновления чаще всего указывает на рассинхронизацию или повреждение метаданных конфигурации поставщика внутри базы данных. Для того чтобы понять, как это происходит, вспомним архитектуру хранения метаданных в любой информационной базе 1С, находящейся на поддержке. Внутри одного файла 1CD (или в таблицах SQL-базы) одновременно сосуществуют три конфигурации:

1. Основная конфигурация — это та конфигурация, с которой работает разработчик в Конфигураторе. В нее вносятся изменения, добавляются новые реквизиты, документы и программный код.
2. Конфигурация базы данных — это «рабочая» конфигурация, под управлением которой пользователи работают в режиме «1С:Предприятие». Она обновляется из основной конфигурации при нажатии клавиши F7 (или синей бочки).
3. Конфигурация поставщика — это эталонная, неизмененная конфигурация от фирмы 1С, которая зашита внутрь вашей базы. Именно с ней платформа сравнивает основную конфигурацию при обновлении, чтобы понять, какие объекты были изменены пользователем, а какие остались типовыми.

Когда вы пытаетесь применить файл обновления cfu, платформа выполняет жесткую проверку. Она считывает внутренний уникальный идентификатор (GUID) и номер версии именно из конфигурации поставщика, хранящейся внутри базы, и сопоставляет их с требованиями, записанными в файле обновления. Если эти данные не совпадают хотя бы на один символ или GUID метаданных «съехал», платформа выдает ошибку, сообщая, что доступных обновлений нет.

Такой сбой метаданных поставщика происходит по нескольким причинам:

• «Кривое» обновление в прошлом: Кто-то из предыдущих разработчиков мог обновить основную конфигурацию через обычное сравнение/объединение с файлом cf, забыв корректно обновить саму конфигурацию поставщика. В результате в окне «О программе» и в окне «Настройка поддержки» отображаются нужные цифры релиза, но внутренние идентификаторы (GUID) метаданных поставщика не соответствуют эталону.
• Прерывание процесса записи: Если в прошлом обновление было прервано (аварийное завершение работы Конфигуратора, отключение питания компьютера, сбой СУБД или сети), конфигурация поставщика могла записаться в базу данных с ошибками.
• Ручное редактирование номера версии: Иногда недобросовестные специалисты просто вручную меняют номер версии в свойствах конфигурации, чтобы программа «думала», что она обновлена, не проводя при этом реального обновления метаданных поставщика.

Анализ рискованного метода решения (из сообщения №47 форума)

На форумах часто встречается решение, которое помогло автору темы в сообщении №47. Давайте проанализируем его шаги:

1. Из основной базы сохраняется конфигурация в файл (получается cf основной конфигурации с доработками).
2. Из чистой, типовой базы того же релиза сохраняется чистый cf конфигурации поставщика.
3. В основную базу загружается этот чистый cf поставщика через команду «Загрузить конфигурацию из файла».
4. Затем выполняется сравнение и объединение с файлом из шага 1 (с доработками), где проставляются все галочки для возврата измененных объектов.

Внимание! Это крайне опасный метод в рабочей базе! Рассмотрим подробнее, почему так делать категорически не рекомендуется. Команда «Загрузить конфигурацию из файла» полностью уничтожает старую структуру метаданных основной конфигурации и заменяет ее новой. При последующем сравнении и объединении со своими доработками есть огромный риск того, что добавленные ранее уникальные объекты (реквизиты, справочники, регистры) получат новые внутренние идентификаторы (GUID).

Для платформы это будет выглядеть так, будто вы удалили старые объекты и создали новые с такими же именами. При первом же обновлении конфигурации базы данных (нажатии кнопки F7) платформа выполнит реструктуризацию таблиц: она безвозвратно удалит старые колонки с данными из таблиц SQL или файла 1CD и создаст новые пустые колонки. В результате вы получите внешне рабочую базу, но с полностью стертыми данными в доработанных реквизитах и объектах. Также часто после такой процедуры «сбиваются» предопределенные элементы справочников, что приводит к лавине ошибок в программном коде при попытке обращения к ним.

Безопасный профессиональный метод восстановления конфигурации поставщика

Для решения этой проблемы в профессиональной среде используется гораздо более безопасный метод. Его суть заключается в том, чтобы заново пересоздать связь с конфигурацией поставщика, вообще не затрагивая структуру и метаданные основной конфигурации. Это полностью исключает риск потери данных в доработанных реквизитах и объектах. Рассмотрим этот алгоритм по шагам.

Шаг 1. Подготовка эталонного файла конфигурации

Нам понадобится полный дистрибутив (файл с расширением cf, а не cfu) точно того же релиза, который сейчас установлен в вашей базе. В рассматриваемом случае это Бухгалтерия предприятия 2.0.66.77. Этот файл можно получить несколькими путями:

• Скачать полный дистрибутив этого релиза с официального сайта поддержки пользователей 1С.
• Развернуть чистую демо-базу или пустую базу этого же релиза из шаблонов и сохранить конфигурацию в файл через меню Конфигурация -> Сохранить конфигурацию в файл....

Шаг 2. Снятие конфигурации с поддержки

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

1. Откроем нашу рабочую базу в режиме Конфигуратор (предварительно обязательно сделав резервную копию базы!).
2. Перейдем в меню Конфигурация -> Поддержка -> Настройка поддержки....
3. В открывшемся окне нажмем кнопку «Снять с поддержки» и подтвердим действие.
4. Закроем окно настройки поддержки. Наша основная конфигурация со всеми доработками осталась абсолютно нетронутой, но теперь она официально считается полностью измененной и снятой с поддержки.

Шаг 3. Фиктивное сравнение и объединение для постановки на поддержку

Теперь мы свяжем нашу базу с чистым файлом поставщика, не меняя при этом ни единой строчки нашего кода и ни одного нашего реквизита. Это самый важный этап:

1. Перейдем в меню Конфигурация -> Сравнить, объединить с конфигурацией из файла....
2. Укажем путь к сохраненному на Шаге 1 эталонному файлу 2.0.66.77.cf.
3. Платформа проанализирует файлы и выведет окно с вопросом: «Добавить конфигурацию из файла в список конфигураций поставщика?» (или в некоторых версиях: «Поставить конфигурацию на поддержку?»). Обязательно нажимаем Да.
4. Перед нами откроется стандартное окно сравнения и объединения конфигураций. Внимание! Нам нужно снять абсолютно все флажки (галочки) со всех объектов в дереве! Для этого нажимаем на самую верхнюю галочку у корня дерева конфигурации, чтобы она снялась со всех подчиненных элементов. В колонке объединения не должно остаться ни одной активной галочки. Мы делаем это для того, чтобы платформа просто сопоставила объекты и прописала связи поддержки, но физически не заменяла наши доработанные объекты эталонными.
5. Нажимаем кнопку Выполнить внизу окна.
6. Платформа предложит настроить правила поддержки для объектов. Для всех объектов устанавливаем правило: «Объект поставщика редактируется с сохранением поддержки» (это позволит нам в дальнейшем вносить изменения).
7. Нажимаем ОК и дожидаемся окончания процесса.

После завершения процесса мы увидим, что кнопка «Настройка поддержки» снова стала активной, а конфигурация поставщика внутри нашей базы обновилась до корректного, эталонного состояния. При этом ни один доработанный объект базы данных не пострадал и не изменился. Теперь выполним сохранение конфигурации и обновление базы данных, нажав клавишу F7.

Особенности перехода с редакции 2.0 на 3.0

После того как конфигурация поставщика успешно восстановлена безопасным методом, можно приступать к самому переходу на редакцию 3.0. При этом важно учитывать несколько специфических нюансов, характерных именно для этого перехода.

Использование правильного дистрибутива обновления

Для перехода с редакции 2.0 на 3.0 обычный файл обновления cfu не подойдет. На сайте обновлений 1С для каждого релиза ветки 3.0 публикуется два вида дистрибутивов:

• Дистрибутив обычного обновления (предназначен для перехода с предыдущих релизов ветки 3.0, например, с 3.0.69 на 3.0.70).
• Дистрибутив обновления для перехода с редакции 2.0 (в названии его архива или внутри служебных файлов часто присутствует постфикс _20, например, 1cv8_20.cfu).

Убедимся, что скачан и распакован именно дистрибутив для перехода с редакции 2.0. Платформа 1С сверяет совместимость версий по специальному служебному файлу UpdateInfo.txt, который идет в комплекте поставки. Рассмотрим ситуацию, упомянутую в сообщении №23 форума: иногда разработчики фирмы 1С допускают ошибки при сборке релизов и некорректно именуют служебный файл (например, называют его UpdateInfo_20.txt вместо UpdateInfo.txt). Если при ручном обновлении платформа все равно не видит файл cfu, попробуем переименовать этот файл в каталоге шаблонов, убрав постфикс.

Очистка серверного кэша при клиент-серверном варианте работы

Если ваша база работает в клиент-серверном варианте (под управлением MS SQL Server, PostgreSQL и т.д.), обычная очистка локального кэша на компьютере разработчика может не дать результатов. Кэш метаданных активно кэшируется самим сервером приложений «1С:Предприятие». В этом случае для применения корректной конфигурации поставщика необходимо выполнить следующие действия:

1. Остановить службу сервера приложений 1С («Agent 1C:Enterprise Connector» или аналогичную службу вашего релиза платформы).
2. Очистить содержимое папки reg_1541 (за исключением файлов лицензий и настроек кластера), где хранятся временные файлы сеансов и кэша баз данных.
3. Запустить службу сервера приложений заново.

После проведения этих процедур и восстановления конфигурации поставщика по нашей инструкции, процесс обновления через меню Конфигурация -> Поддержка -> Обновить конфигурацию успешно определит ваш файл cfu, и переход на новую редакцию 1С:Бухгалтерии 3.0 пройдет в штатном режиме.