← На главную

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

Выбор стратегии переноса реквизитов: Дополнительные реквизиты БСП или собственные объекты метаданных?

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

Механизм «Дополнительные реквизиты и сведения» в 1С 8.3 разработан для того, чтобы пользователи могли самостоятельно добавлять дополнительную информацию к элементам справочников и документов без привлечения программистов и без изменения конфигурации. Это позволяет избежать проблем с обновлениями программы и сохранить конфигурацию на поддержке. Дополнительные реквизиты являются частью объекта и могут отображаться на его форме, а дополнительные сведения хранятся в регистре сведений и доступны по команде из элемента.

Преимущества использования дополнительных реквизитов:

1. Сохранение типовой конфигурации: Основное и самое важное преимущество — конфигурация остается типовой, что существенно упрощает процесс обновлений.
2. Гибкость для пользователей: Бизнес-пользователи могут сами добавлять и управлять полями, не требуя участия программистов.
3. Готовая интеграция: Многие механизмы БСП и внешние системы (например, Битрикс) изначально хорошо работают с дополнительными реквизитами.

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

Создание собственных объектов метаданных (справочников, реквизитов) в конфигурации или расширении:

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

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

Производительность запросов при работе с дополнительными реквизитами

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

Механизм хранения дополнительных реквизитов:

1. Дополнительные реквизиты хранятся в специальных табличных частях самого объекта-владельца (например, справочника Номенклатура) или в отдельном регистре сведений.
2. Дополнительные сведения, в отличие от реквизитов, всегда хранятся в отдельном регистре сведений.

Несмотря на то что данные хранятся в отдельных таблицах, механизм БСП спроектирован для эффективной работы с ними. Запросы к этим данным оптимизированы. В целом, система «Дополнительные реквизиты» является мощным функционалом, который во многих случаях позволяет отказаться от снятия конфигурации с поддержки или внесения ненужных изменений.

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

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

Реализация табличных частей со множественным выбором

Предположим, у нас есть справочник «Марка авто», и в карточке номенклатуры необходимо указать несколько марок, подходящих для данной запчасти. Стандартные дополнительные реквизиты в 1С не предназначены для создания табличных частей или для множественного выбора сложных типов данных, таких как ссылки на справочники, по умолчанию. Тип значения «Дополнительное значение» позволяет выбрать одно значение из предопределенного списка, что не подходит для множественного выбора.

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

1. Создание подчиненного регистра сведений:

   Одним из вариантов является создание отдельного регистра сведений (возможно, в расширении или основной конфигурации), где:

   • В измерениях будут храниться ссылка на объект-владелец (например, Номенклатура) и ссылка на элемент справочника «Марка авто».
   • В ресурсах могут храниться дополнительные параметры, если необходимо.

   Такой подход позволит хранить произвольное количество значений для одной номенклатуры. Однако, это усложнит запросы, так как потребуется дополнительное объединение с регистром сведений. На форму номенклатуры такую табличную часть можно будет вывести программно, используя данные из этого регистра.

2. Программное создание табличной части на форме через расширение:

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

3. Использование специализированных разработок или типа «Массив»:

   Для реализации «множественного реквизита» можно рассмотреть вариант создания дополнительного реквизита с типом Массив. Это позволяет хранить набор значений для одного элемента данных. Физически каждый такой реквизит порождает отдельную таблицу в базе данных, которая связывается с основной таблицей по полю «Контейнер». Однако, работа с таким типом в пользовательском интерфейсе и при отборах может быть неочевидной и потребует доработок. Существуют специализированные разработки, которые позволяют указать произвольное количество значений и отображать их как список. При этом в комментарии к такому допреквизиту может быть указано «Множественный», чтобы расширение его распознало.

В любом случае, если требуется сложная структура данных с подчинением или множественным выбором, как в случае справочника «Марка авто», нам придется создавать этот справочник в конфигурации (или расширении), а не полагаться исключительно на механизм дополнительных реквизитов БСП.

Интеграция с Битриксом и выгрузка реквизитов

Вопрос интеграции с Битриксом крайне важен, особенно при планировании нетипового обмена и наличии сложных условий по выгрузке товара. Ранее мы выяснили, что Битрикс отлично работает с дополнительными реквизитами 1С.

Основные аспекты интеграции с Битрикс:

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

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

Работа с расширениями конфигурации: риски и особенности

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

Преимущества расширений:

1. Сохранение поддержки: Конфигурация остается на поддержке, что упрощает и удешевляет обновления.
2. Изолированные изменения: Все доработки находятся в отдельном слое, что снижает риск конфликтов с типовым кодом.
3. Модульность: Расширения можно включать/отключать, что удобно для тестирования и управления функциональностью.

Риски и ограничения расширений:

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

Учитывая, что вы планируете использовать расширения только для кода и заимствования форм, важно понимать нюансы работы с формами.

Эффективная работа с формами в расширениях

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

Рекомендации по работе с формами в расширениях:

1. Избегайте прямого заимствования и изменения форм:

   Лучше всего не заимствовать и не изменять заимствованную форму напрямую. Если вам нужно добавить на типовую форму элементы (например, поле для дополнительного реквизита или табличную часть), делайте это программно.

2. Программное добавление элементов и реквизитов на форму:

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

   Например, для программного изменения состава реквизитов управляемой формы на сервере, вы можете использовать методы:

   Скопировать код

   
   &НаСервере
   Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
       // Добавляем реквизит на форму
       МассивРеквизитов = Новый Массив;
       МассивРеквизитов.Добавить(Новый РеквизитФормы("МойНовыйРеквизит", Новый ОписаниеТипов("Строка"), "Объект"));
       ИзменитьРеквизиты(МассивРеквизитов);
   
       // Теперь добавляем элемент управления на форму, который будет связан с этим реквизитом
       Элементы.Добавить("МойНовыйЭлемент", Тип("ПолеФормы"), Элементы.ГруппаВажныхРеквизитов);
       ЭлементФормы = Элементы.МойНовыйЭлемент;
       ЭлементФормы.Вид = ВидПоляФормы.ПолеВвода;
       ЭлементФормы.ПутьКДанным = "МойНовыйРеквизит";
       // ... Дополнительные настройки элемента
   КонецПроцедуры
   

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

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

Общие рекомендации по миграции и доработке

В нашем случае, когда речь идет о переходе на УНФ 3.0 с большим объемом нетиповых данных из УТ 10.3 (авторазбор, 55 тыс. номенклатурных позиций с характеристиками и множеством реквизитов), мы рекомендуем комбинированный подход:

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

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

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