← На главную

При доработке типовых конфигураций 1С разработчики часто сталкиваются с задачей расширения структуры данных, например, добавления нового измерения или ресурса в существующий регистр сведений. Ситуация усложняется, когда версия платформы позволяет использовать новые возможности расширений (например, 8.3.18), но сама конфигурация работает в режиме совместимости с более старой версией (например, 8.3.16). В старых режимах совместимости добавление объектов или их полей в регистры сведений через расширения попросту недоступно.

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

Вариант 1: Отключение или повышение режима совместимости (Не рекомендуется)

Первое, что приходит на ум — это поднять версию режима совместимости до требуемой (например, 8.3.17 или 8.3.18), либо вовсе отключить его, чтобы получить доступ ко всем современным возможностям расширений.

Разберем, к чему это может привести на практике:

1. Непредсказуемые ошибки в типовом коде: Типовая конфигурация была написана и протестирована вендором именно под указанный режим совместимости. Методы работы с файлами, криптографией, фоновыми заданиями и программным открытием форм могут кардинально изменить свое поведение или начать выдавать ошибки.
2. Изменение логики работы платформы: В более новых режимах совместимости меняется работа механизмов индексации и оптимизатора запросов. Это может привести к сильному замедлению работы отчетов или процессов проведения документов.
3. Проблемы с мобильным клиентом: Если используется мобильное приложение, изменение режима может привести к полной неработоспособности обмена данными.

Поэтому настоятельно рекомендуем: не меняйте режим совместимости в типовых конфигурациях ради одного-двух новых реквизитов. Лучше дождитесь официального обновления конфигурации от 1С, где вендор сам повысит режим, адаптировав весь программный код.

Вариант 2: Редактирование с сохранением поддержки (Рекомендуется)

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

Рассмотрим по шагам, как это сделать:

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

Как будут происходить обновления конфигурации?

Многих пугает снятие объектов с замка из-за возможных проблем при обновлениях. Выясним, как правильно обновлять измененную таким образом систему.

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

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

После правильного объединения все типовые изменения применятся, а ваша доработка сохранится.

Альтернативные архитектурные решения (на примере Штрихкодов)

Проанализируем конкретную задачу из обсуждения: добавление поля «Назначение ШК» в регистр штрихкодов. Прежде чем снимать регистр с поддержки, стоит подумать, нет ли более изящных способов решить проблему.

Регистр сведений со штрихкодами в современных конфигурациях тесно связан с механизмами обмена с торговым оборудованием и системами обязательной маркировки (например, Честный Знак). Вторжение в структуру такого регистра может привести к конфликтам при работе с государственными системами.

Посмотрим на альтернативные варианты:

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

Подводим итоги

Если задача требует обязательного физического расширения таблицы базы данных, а режим совместимости это запрещает в расширении — смело добавляйте реквизиты в основную конфигурацию, включив правило редактирования с сохранением поддержки. Это безопаснее для данных (реквизит физически сохранится в СУБД) и гарантирует стабильность типовых механизмов (вы не сломаете платформенные вызовы старого режима совместимости). При этом всю бизнес-логику работы с этим реквизитом продолжайте выносить в расширение.