Работа с типовыми конфигурациями 1С рано или поздно приводит нас к дилемме: оставить конфигурацию «на замке» и использовать расширения или включить возможность изменения и править основную конфигурацию. Это решение влияет не только на удобство будущих обновлений, но и на сохранность данных. В сообществе специалистов часто возникают споры о том, где безопасно хранить новые реквизиты и справочники.
Давайте подробно разберем, как на самом деле работают режимы поддержки, в чем кроется опасность расширений конфигурации и как избежать превращения типовой базы в «винегрет», который невозможно обновить.
Многие пользователи и даже начинающие программисты ориентируются на иконку «замочка» в дереве конфигурации. Однако визуальное отображение не всегда дает полную картину. Давайте проанализируем техническую разницу между тремя основными состояниями поддержки.
Это самый безопасный режим. Конфигурация полностью закрыта от изменений в основной структуре метаданных. При обновлении платформа просто заменяет старые объекты на новые. Это гарантирует целостность, но исключает прямые правки кода или структуры данных. Однако, важно понимать: даже если база «на замке», в ней могут работать нетиповые алгоритмы через механизм расширений или внешних обработок.
Это «золотая середина», которая часто становится головной болью. При обновлении в этом режиме включается механизм трехстороннего сравнения:
Платформа пытается автоматически найти изменения, но часто требует ручного вмешательства программиста. Именно здесь возникают ошибки, когда при обновлении затираются важные доработки.
Связь с поставщиком полностью разорвана. Самый критичный момент здесь касается внутренних идентификаторов (UUID). При обновлении объекты больше не сопоставляются по UUID родительской конфигурации. Обновление возможно только через ручное сравнение и объединение по именам. Это делает процесс трудоемким и опасным.
С появлением механизма расширений (Extensions) возник соблазн вообще не снимать конфигурацию с поддержки, а все новые справочники, документы и реквизиты добавлять в расширение. Давайте разберем риски этого подхода, которые активно обсуждаются в профессиональной среде.
Миф о безопасности данных в расширениях
Существует мнение, что расширения абсолютно безопасны. Однако, как показывает практика и обсуждения экспертов, это не так. Рассмотрим ключевой нюанс: разница между отключением и удалением расширения.
Если вы просто снимаете галочку «Активно» у расширения, данные, которые были добавлены через это расширение (например, новые реквизиты справочников или целые регистры), остаются в базе данных. Они просто становятся невидимыми для приложения. При повторном включении расширения данные снова станут доступны. Это подтверждается документацией и опытом: при деактивации из-за ошибок обновления данные никуда не пропадают.
Однако, если вы удалите расширение из списка, платформа физически удалит соответствующие таблицы и поля из СУБД (SQL). Данные будут потеряны безвозвратно (если нет бэкапа).
Рекомендации по хранению данных:
Помимо риска потери данных, давайте рассмотрим архитектурные ограничения, которые могут повлиять на производительность и стабильность системы.
1. Монопольный режим при обновлении
Одно из преимуществ расширений — возможность динамического обновления. Но это работает только для изменения кода. Если расширение меняет структуру данных (добавляет справочники, реквизиты), обновление этого расширения на рабочей базе часто требует монопольного доступа, точно так же, как и обновление основной конфигурации. В этом случае главное преимущество нивелируется.
2. Проблема производительности
Расширения не просто «накладываются» сверху. Платформа генерирует составную конфигурацию в оперативной памяти. Чрезмерное использование аннотаций &Вместо или &После на высоконагруженных методах (например, при проведении документов или в циклах) может существенно снижать производительность системы, так как платформе приходится перехватывать вызовы и перенаправлять их.
3. Проблема «призраков» данных (UUID)
Если вы удалите реквизит в расширении, а затем создадите его заново с тем же именем, данные будут потеряны. Для СУБД это будет новый объект с новым уникальным идентификатором (UUID). Это же правило работает и для основной конфигурации при снятии с поддержки: если вы удалили объект поставщика и создали свой с таким же именем, автоматическое обновление перестанет работать корректно для этого объекта, так как 1С не сможет их сопоставить.
Часто возникает задача обратная: была сильно измененная база, нужно вернуть её к типовому виду, чтобы получать обновления автоматически. Разберем этот процесс по шагам.
Для корректного возврата на поддержку нам потребуется файл полной поставки конфигурации (расширение .cf), а не файл обновления (.cfu). Процесс выглядит так:
.cf файл той же версии, что и ваша текущая база (или более новой, если обновляетесь).Проблема «битых» ссылок после возврата
Будьте внимательны: если в пользовательском режиме были созданы документы или элементы справочников, метаданные которых вы добавили сами (нетиповые объекты), то после возврата к типовой конфигурации эти объекты метаданных исчезнут. Сами данные в базе превратятся в «Объект не найден» (так называемые битые ссылки). Их необходимо будет вычистить с помощью обработки «Удаление помеченных объектов» или специальных утилит тестирования и исправления.
Интересный момент, который стоит учитывать при диагностике «типовых» баз. Современные конфигурации (Бухгалтерия, ERP, ЗУП) умеют автоматически загружать исправления ошибок — патчи.
Технически эти патчи являются расширениями конфигурации. Это создает парадоксальную ситуацию: вы смотрите в конфигуратор, видите «замок», считаете базу полностью типовой, но поведение программы отличается от заложенного в релизе. Всегда проверяйте список установленных расширений, даже если вы сами ничего не устанавливали.
Подводя итог нашему анализу, сформулируем правила безопасной работы: