Дополнительные реквизиты vs. реальные реквизиты объекта
Всем добрый день!
До недавнего времени (так уж получилось) в своей работе не использовал инструмент дополнительных реквизитов и сведений.
Все потребности в изменениях такого рода проходили через согласование с отделом ИТ, и если принимали решение, что новый реквизит нужен - вносились изменения в конфигурацию, добавлялся реквизит, обновлялась база.
На очередном проекте столкнулся с базой, где доп. реквизиты - просто как справочник какой-то) Никакого контроля нет, пользователи используют их на свое усмотрение. Соответственно куча мусора и бардак. Это обстоятельство вынудило познакомиться с этим механизмом более подробно. Оказалось, с точки зрения работы, механизм довольно удобный. Создал элемент в справочнике, выбрал тип и всё, новый реквизит в карточке. В отчетах СКД доступен, с отборах доступен. Вроде всё ок. Но все же реквизит-то синтетический, соответственно функции работы с ним ограничены.
Поэтому решил взвесить все плюсы и минусы. Для удобства различия назову реальный реквизит - "обычный реквизит", а доп. реквизит - "дополнительный реквизит".
Итак, что я хочу отметить.
1. Трудозатраты на создание. Создать доп. реквизит легче, бесспорно - создали и тут же можем использовать. В режиме конфигурирования это может быть очень трудоемко - ведь обновление базы при изменении может длиться часами.
2. Контроль . По контролю доп. реквизит изначально проигрывает, т.к. в конфигуратор пользователи не полезут как ни крути. А вот доступ к доп. реквизитам открыт. Конечно можно заморочиться и настроить права. Но этим нужно заниматься, тому же если пользователи уже попробовали что это такое, то просто так обрезать права может быть проблематично, будут сопротивляться.
3. Доступность.
3.1. в СКД. Если пользоваться только штатными механизмами в пользовательском режиме всё красиво. В режиме конфигурирования - нет, доп. реквизиты недоступны напрямую.Но если например захотеть воспользоваться доп. реквизитом в запросе - то фиг. Т.е. можно конечно соединениями фильтровать табличную часть, извращаться как-то, но это уже минусы. Ведь гораздо проще обратиться к реальному реквизиту.
3.2. в запросах. Если в режиме пользователя в СКД эта проблема уходит (доп. реквизиты доступны как и обычные), то в запросах (консоли запросов) она остается. Аналогично, обратиться к реквизиту можно только косвенно.
3.3. программное обращение. При кодировании конечно же классический реквизит лучше. Что проще, чем обратиться через точку по имени? Доп. реквизит нужно искать, проверять, вводить переменную и т.д.
4. Обмены. На мой взгляд, доп. реквизиты усложняют правила обмена и добавляют всякие нюансы, с которыми придется считаться. Например, если мы хотим добавить в товар некий признак и по нему фильтровать выгрузку. Делаем - добавляем реквизит (навскидку, называем "Хороший"), при выгрузке пишем Отказ = НЕ Источник.Хороший. Всё. Если это будет доп. реквизит - задача усложняется. С другой стороны - после добавления доп. реквизита не нужно обновлять структуру конфигурации.
В общем, у меня сложилось впечатление, что доп. реквизиты удобно использовать в небольших ненагруженных базах, в компаниях с небольшим штатом. Если же ИТ-структура компании "выше среднего", есть штатные программисты и за базой ухаживают, тогда классические реквизиты более предпочтительны. Возможно мои взгляды устарели. Хотелось бы узнать у кого какое мнение по этому вопросу. И может быть есть другие аргументы в чью-либо пользу?
До недавнего времени (так уж получилось) в своей работе не использовал инструмент дополнительных реквизитов и сведений.
Все потребности в изменениях такого рода проходили через согласование с отделом ИТ, и если принимали решение, что новый реквизит нужен - вносились изменения в конфигурацию, добавлялся реквизит, обновлялась база.
На очередном проекте столкнулся с базой, где доп. реквизиты - просто как справочник какой-то) Никакого контроля нет, пользователи используют их на свое усмотрение. Соответственно куча мусора и бардак. Это обстоятельство вынудило познакомиться с этим механизмом более подробно. Оказалось, с точки зрения работы, механизм довольно удобный. Создал элемент в справочнике, выбрал тип и всё, новый реквизит в карточке. В отчетах СКД доступен, с отборах доступен. Вроде всё ок. Но все же реквизит-то синтетический, соответственно функции работы с ним ограничены.
Поэтому решил взвесить все плюсы и минусы. Для удобства различия назову реальный реквизит - "обычный реквизит", а доп. реквизит - "дополнительный реквизит".
Итак, что я хочу отметить.
1. Трудозатраты на создание. Создать доп. реквизит легче, бесспорно - создали и тут же можем использовать. В режиме конфигурирования это может быть очень трудоемко - ведь обновление базы при изменении может длиться часами.
2. Контроль . По контролю доп. реквизит изначально проигрывает, т.к. в конфигуратор пользователи не полезут как ни крути. А вот доступ к доп. реквизитам открыт. Конечно можно заморочиться и настроить права. Но этим нужно заниматься, тому же если пользователи уже попробовали что это такое, то просто так обрезать права может быть проблематично, будут сопротивляться.
3. Доступность.
3.1. в СКД. Если пользоваться только штатными механизмами в пользовательском режиме всё красиво. В режиме конфигурирования - нет, доп. реквизиты недоступны напрямую.Но если например захотеть воспользоваться доп. реквизитом в запросе - то фиг. Т.е. можно конечно соединениями фильтровать табличную часть, извращаться как-то, но это уже минусы. Ведь гораздо проще обратиться к реальному реквизиту.
3.2. в запросах. Если в режиме пользователя в СКД эта проблема уходит (доп. реквизиты доступны как и обычные), то в запросах (консоли запросов) она остается. Аналогично, обратиться к реквизиту можно только косвенно.
3.3. программное обращение. При кодировании конечно же классический реквизит лучше. Что проще, чем обратиться через точку по имени? Доп. реквизит нужно искать, проверять, вводить переменную и т.д.
4. Обмены. На мой взгляд, доп. реквизиты усложняют правила обмена и добавляют всякие нюансы, с которыми придется считаться. Например, если мы хотим добавить в товар некий признак и по нему фильтровать выгрузку. Делаем - добавляем реквизит (навскидку, называем "Хороший"), при выгрузке пишем Отказ = НЕ Источник.Хороший. Всё. Если это будет доп. реквизит - задача усложняется. С другой стороны - после добавления доп. реквизита не нужно обновлять структуру конфигурации.
В общем, у меня сложилось впечатление, что доп. реквизиты удобно использовать в небольших ненагруженных базах, в компаниях с небольшим штатом. Если же ИТ-структура компании "выше среднего", есть штатные программисты и за базой ухаживают, тогда классические реквизиты более предпочтительны. Возможно мои взгляды устарели. Хотелось бы узнать у кого какое мнение по этому вопросу. И может быть есть другие аргументы в чью-либо пользу?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Кто как думает, при обмене БУ 7.70 и УТ 11.4, что лучше применять: дополнительные реквизиты или через расширение добавлять реквизиты?
Реальная ситуация: В справочнике Номенклатура в БУ 7.70 есть реквизиты "Коллекция", "КодWildberries" и другие. Рассмотрим только эти два.
Для "КодWildberries" - у УТ 11.4 понятно что использовать - Доп.реквизит с типом "Строка" и длиной около 13 символов. (Т.к. у каждой записи справочника Номенклатура значение уникально)
А вот для реквизита "Коллекция" решили в УТ 11.4 у Доп.реквизита использовать тип "Дополнительное значение". (Т.к. у нескольких записей справочника Номенклатура может совпадать значение этого реквизита).
1) Как оно сейчас работает при обмене:
В ПКО_Номенклатура, в обработчике ПриВыгрузке
И в этом же ПКО, в обработчике ПриЗагрузке
Получаю строковое значение реквизита.
Далее запросом получаю ссылку на ПВХ
Ищу в Справочник.ЗначенияСвойствОбъектов есть ли уже такое значение в УТ 11.4.
Если его нет - тогда делается запись.
Уже в самом справочнике Номенклатура, в его табличной части ДополнительныеРеквизиты проверка на существование строки с таким ПВХ. Перезапись или создание новой строки.
2) Создать в расширении справочник "Коллекции...", достаточно будет только Наименование.
Использовать стандартный механизм поиска объекта в КД 2.0 по полям поиска.
На форме элемента Номенклатуры нужно будет программно настроить отображение этого реквизита.
И так вот, какой вариант будет быстрее работать?
Реальная ситуация: В справочнике Номенклатура в БУ 7.70 есть реквизиты "Коллекция", "КодWildberries" и другие. Рассмотрим только эти два.
Для "КодWildberries" - у УТ 11.4 понятно что использовать - Доп.реквизит с типом "Строка" и длиной около 13 символов. (Т.к. у каждой записи справочника Номенклатура значение уникально)
А вот для реквизита "Коллекция" решили в УТ 11.4 у Доп.реквизита использовать тип "Дополнительное значение". (Т.к. у нескольких записей справочника Номенклатура может совпадать значение этого реквизита).
1) Как оно сейчас работает при обмене:
В ПКО_Номенклатура, в обработчике ПриВыгрузке
| Код |
|---|
ДополнительныеРеквизиты = СоздатьУзел("ДополнительныеРеквизиты");
УстановитьАтрибут(ДополнительныеРеквизиты, "Коллекция", СокрП(Источник.НомерКоллекции));
ДобавитьПодчиненный(Приемник, ДополнительныеРеквизиты);Показать полностью |
И в этом же ПКО, в обработчике ПриЗагрузке
Получаю строковое значение реквизита.
| Код |
|---|
Пока ФайлОбмена.Прочитать() Цикл
ИмяУзла = ФайлОбмена.ЛокальноеИмя;
ТипУзла = ФайлОбмена.ТипУзла;
Если ИмяУзла = "ДополнительныеРеквизиты" И (ТипУзла = одТипУзлаXML_НачалоЭлемента) Тогда
Коллекция = одАтрибут(ФайлОбмена, одТипСтрока, "Коллекция");Показать полностью |
Далее запросом получаю ссылку на ПВХ
| Код |
|---|
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| Свойства.Ссылка
|ИЗ
| ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения КАК Свойства
|ГДЕ
| Свойства.Имя = &Имя";
Запрос.УстановитьПараметр("Имя", СвойствоОбъекта_Имя);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
СвойствоОбъекта = Выборка.Ссылка;
КонецЦикла;Показать полностью |
Ищу в Справочник.ЗначенияСвойствОбъектов есть ли уже такое значение в УТ 11.4.
| Код |
|---|
Если СвойствоОбъекта <> Неопределено Тогда
// Свойство было найдено
// Проверка на наличие значения в "Дополнительных значениях" свойства
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЗначенияСвойствОбъектов.Ссылка КАК Ссылка,
| ЗначенияСвойствОбъектов.Наименование КАК Наименование
|ИЗ
| Справочник.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
|ГДЕ
| ЗначенияСвойствОбъектов.Владелец = &Владелец";
Запрос.УстановитьПараметр("Владелец", СвойствоОбъекта);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
НайденоЗначениеСвойстваОбъекта = Ложь;
Пока Выборка.Следующий() Цикл
Если Выборка.Наименование = ТекущийДополнительныйРеквизит.Значение Тогда
ЗначениеСвойстваОбъекта = Выборка.Ссылка;
НайденоЗначениеСвойстваОбъекта = Истина;
Прервать;
КонецЕсли;
КонецЦикла;Показать полностью |
Если его нет - тогда делается запись.
| Код |
|---|
Если НЕ НайденоЗначениеСвойстваОбъекта Тогда
// Создаём новое "Дополнительное значение" свойства
ЗначениеСвойстваОбъекта = Справочники.ЗначенияСвойствОбъектов.СоздатьЭлемент();
ЗначениеСвойстваОбъекта.Владелец = СвойствоОбъекта;
ЗначениеСвойстваОбъекта.Наименование = ТекущийДополнительныйРеквизит.Значение;
ЗначениеСвойстваОбъекта.Записать();
КонецЕсли;Показать полностью |
Уже в самом справочнике Номенклатура, в его табличной части ДополнительныеРеквизиты проверка на существование строки с таким ПВХ. Перезапись или создание новой строки.
| Код |
|---|
// Проверка на заполненность Справочник.Номенклатура.ДополнительныеРеквизиты
// свойством объекта
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| НоменклатураДополнительныеРеквизиты.Значение КАК Значение
|ИЗ
| Справочник.Номенклатура.ДополнительныеРеквизиты КАК НоменклатураДополнительныеРеквизиты
|ГДЕ
| НоменклатураДополнительныеРеквизиты.Ссылка = &Объект
| И НоменклатураДополнительныеРеквизиты.Свойство = &СвойствоОбъекта";
Запрос.УстановитьПараметр("Объект", Объект.Ссылка);
Запрос.УстановитьПараметр("СвойствоОбъекта", СвойствоОбъекта);
РезультатЗапроса = Запрос.Выполнить();
Если РезультатЗапроса.Пустой() Тогда
// Добавляем новую строку в Номенклатура.ДополнительныеРеквизиты
НоваяСтрока_НоменклатураДополнительныеРеквизиты = Объект.ДополнительныеРеквизиты.Добавить();
НоваяСтрока_НоменклатураДополнительныеРеквизиты.Свойство = СвойствоОбъекта;
НоваяСтрока_НоменклатураДополнительныеРеквизиты.Значение = ЗначениеСвойстваОбъекта;
НоваяСтрока_НоменклатураДополнительныеРеквизиты.ТекстоваяСтрока = ТекущийДополнительныйРеквизит.Значение;
Иначе
// Есть уже какое-то значение с этим свойством
ПараметрыОтбора = Новый Структура;
ПараметрыОтбора.Вставить("Свойство", СвойствоОбъекта);
НайденныеСтроки = Объект.ДополнительныеРеквизиты.НайтиСтроки(ПараметрыОтбора);
Если НайденныеСтроки.Количество() = 1 Тогда
НайденныеСтроки[0].Значение = ЗначениеСвойстваОбъекта;
КонецЕсли;
КонецЕсли;
Иначе // СвойствоОбъекта = Неопределено
ТекстСообщения = НСтр("ru = 'Не найден дополнительный реквизит Номенклатура_%1_%2, объект: %3.'");
ТекстСообщения = СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(ТекстСообщения, ДополнительныеРеквизиты.ВидНоменклатуры, ТекущийДополнительныйРеквизит.Ключ, Строка(Объект.Ссылка));
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения);
КонецЕсли; // СвойствоОбъекта <> Неопределено ТогдаПоказать полностью |
2) Создать в расширении справочник "Коллекции...", достаточно будет только Наименование.
Использовать стандартный механизм поиска объекта в КД 2.0 по полям поиска.
На форме элемента Номенклатуры нужно будет программно настроить отображение этого реквизита.
И так вот, какой вариант будет быстрее работать?
Добавлю 5 копеек:
Плюсы доп. реквизитов - не нужно модифицировать форму объекта и форму списка.
Минусы - как обращаться к свойству? По наименованию? Но 1С однажды уже подложило свинью, переобозвав свойства в Бухгалтерии 3.0 с "Мой реквизит (Контрагент)" на "Мой реквизит (Контрагенты)". После этого я стал заносить свойства в константы, но это получается та же модификация конфигурации с дополнительным геморроем.
Плюсы доп. реквизитов - не нужно модифицировать форму объекта и форму списка.
Минусы - как обращаться к свойству? По наименованию? Но 1С однажды уже подложило свинью, переобозвав свойства в Бухгалтерии 3.0 с "Мой реквизит (Контрагент)" на "Мой реквизит (Контрагенты)". После этого я стал заносить свойства в константы, но это получается та же модификация конфигурации с дополнительным геморроем.
Вот пример из практики, к чему может привести бесконтрольное использование доп. реквизитов.
Есть связка УТ - Розница. В УТ "продвинутые" юзеры понаделали кучу доп. реквизитов. Всё это по умолчанию мигрировало в Розницу.
Теперь имеем ситуацию: в базе Розницы таблица доп. реквизитов самая большая, занимает более 10% от всего объема БД (больше, чем весь регистр Продажи)!
Но самое интересное, что в базе Розницы доп. реквизитами вообще не пользуются (в системе они отключены).
Есть связка УТ - Розница. В УТ "продвинутые" юзеры понаделали кучу доп. реквизитов. Всё это по умолчанию мигрировало в Розницу.
Теперь имеем ситуацию: в базе Розницы таблица доп. реквизитов самая большая, занимает более 10% от всего объема БД (больше, чем весь регистр Продажи)!
Но самое интересное, что в базе Розницы доп. реквизитами вообще не пользуются (в системе они отключены).
(7) Во-первых, обмен штатный. Поэтому в некорректных настройках обмена обвиняй 1С .
Во-вторых, представь сколько пользователи наделали реквизитов, чтобы таблица так распухла.
Я не говорю, что это нельзя исправить, настроить и оптимизировать. Говорю, во что это может вырасти, если пользоваться по назначению, но без контроля и технического разумения.
Во-вторых, представь сколько пользователи наделали реквизитов, чтобы таблица так распухла.
Я не говорю, что это нельзя исправить, настроить и оптимизировать. Говорю, во что это может вырасти, если пользоваться по назначению, но без контроля и технического разумения.
Мое мнение - все зависит от задачи , если нужно реквизит только для отражения той или иной информации - то бесспорно лучше использовать доп. реквизит и не калечить базу доработкой. Опять же доп. реквизиты удобнее использовать при обменен с внешними системами (например у нас есть обработка по загрузке данных из системы управления гостиницы Fidelio , так вот для избежания задвоений информации по номенклатуре и ранее загруженным документам используются доп. реквизиты в документах и справочниках)
Если же от значения реквизита зависит поведение программы то тогда лучше делать как реквизит объекта. В этом случае конфигурация будет не типовой , и обращение к данному реквизиту будет проще чем обращаться к доп.реквизитам.
Так же вижу не существенный минус в доп.реквизитах для документов - нельзя на конкретный документ повесить конкретный доп.реквизит. но это по сути мелочь и чисто субъективная
Если же от значения реквизита зависит поведение программы то тогда лучше делать как реквизит объекта. В этом случае конфигурация будет не типовой , и обращение к данному реквизиту будет проще чем обращаться к доп.реквизитам.
Так же вижу не существенный минус в доп.реквизитах для документов - нельзя на конкретный документ повесить конкретный доп.реквизит. но это по сути мелочь и чисто субъективная
Да какие тут могут быть мнения и аргументы?
Зашитие метаданных в данные - это костыли. И если "подстреленному" (конфе, скованной ограничениями) они помогают эффективнее передвигаться , то "здоровый" (конфа, дорабатываемая без ограничений) о них только спотыкаться будет.
Зашитие метаданных в данные - это костыли. И если "подстреленному" (конфе, скованной ограничениями) они помогают эффективнее передвигаться , то "здоровый" (конфа, дорабатываемая без ограничений) о них только спотыкаться будет.
Добавлю от себя. В Последних версиях библиотеки стандартных подсистем используемой во всех новейших конфигурациях 1С (УТ 11, ЕРП, КА2, УХ и прочих) решена проблема с добавлением реквизитов в типовые формы объектов без их изменения. Для этого совершенно не требуется изменять эти формы. всё делается через переопределяемый модуль обработок событий формы (МодификацияКонфигурацииПерепределяемый) вызов которого встроен по все обработчики серверных событий всех типовых форм конфигурации.
На мой взгляд Это последний гвоздь в крышку гроба дополнительных реквизитов.
На мой взгляд Это последний гвоздь в крышку гроба дополнительных реквизитов.
Еще минус доп реквизитов. Как вы будете переносить настроенные доп реквизиты из базы разработчика в реальную рабочую пустую базу для начала работы. Или например если требуется создать новую рабочую базу пустую на какой-то новой организации.
На мой взгляд использовать доп реквизиты имеет смысл только в том случае если организация не имеет штатного программиста, не планирует доработки конфигурации и хочет полностью автоматически получать обновления конфигурации. Другими словами когда бюджет внедрение очень маленький.
(17) Например, применяя функцию ЗначениеСвойства(Объект, Свойство) из общего модуля УправлениеСвойствами.
Часто применяю во внешних печатных формах, где в документе или справочнике добавляются пару доп.реквизитов или доп.сведений, которые нужно отображать в выводимом ТабличномДокументе.
Часто применяю во внешних печатных формах, где в документе или справочнике добавляются пару доп.реквизитов или доп.сведений, которые нужно отображать в выводимом ТабличномДокументе.
Мое мнение - для регулярно обновляемых конфигураций, полностью типовых, лучше доп. реквизит (ПВХ). Причина - обновления.
Для не типовой и обновляемой нужно сделать механизмы программного автопрописывания по указанным правилам в формы реквизитов с префиксами и дальнейшие обновления тоже будут проще. На этом же этапе выяснить у заказчика готов ли он за это платить. Если не готов - ПВХ. Готов - можно объяснять про быстродействие, оптимизацию, скорость дальнейшей разработки...
Для не типовой и обновляемой нужно сделать механизмы программного автопрописывания по указанным правилам в формы реквизитов с префиксами и дальнейшие обновления тоже будут проще. На этом же этапе выяснить у заказчика готов ли он за это платить. Если не готов - ПВХ. Готов - можно объяснять про быстродействие, оптимизацию, скорость дальнейшей разработки...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот