Когда 1С расширения усложняют доработку конфигураций
Вставка
- Опубліковано 16 лип 2024
- Желтый клуб собирает деньги на новый микрофон. Поддерживайте по ссылке: www.tinkoff.ru/cf/AeY49FYUpMI
Приветствуются даже 100 руб. Спасибо.
Стрим об 1С расширениях.
В гостях Алексей Степаненко.
Расширения - классный инструмент, когда требуется и дорабатывать конфигурацию, и быстро обновлять.
Но применимость расширений ограничена. Не стоит все доработки вести только через расширения. Алексей расскажет, о чем нужно подумать, чтобы доработка конфигурации через расширения облегчала жизнь 1С разработчику.
Обсудим такие темы:
✅ Как расширение "убивает" интерактивные доработки формы.
✅ Недоработки платформы, которые затрудняют расследование проблем.
✅ "Особенности" расширений.
- и может быть что-то еще
НАВИГАЦИЯ
00:00 - Вступление
02:44 - Про сарай
05:38 - Жизненный цикл доработок
08:10 - Потеря доработок (подготовка)
18:04 - Пропадают реквизиты формы
25:00 - Не работают процедуры и функции
33:08 - Когда стоит использовать 1С расширения
38:30 - Программная доработка форм без 1С расширений
01:01:30 - Найти проблемы с процедурами сложно
01:03:27 - Проблема с порядком применения расширений
01:11:40 - Можно ли сделать одно расширение
01:13:20 - Читайте стандарты на ИТС
01:15:07 - Плохое логирование действий с расширениями
01:26:30 - Проблема с ролями
01:28:00 - Как перенести доработки из расширений
01:31:30 - Разные вопросы
ДОП. МАТЕРИАЛЫ:
Программную доработку форм спрашивать у Алексея: t.me/AlexeyStepanenko
#1срасширения
==========
Информационные площадки "Жёлтого клуба":
Телеграмм канал: t.me/yellowclub_official
Телеграм чат: t.me/yellowclub_vrn
Группа ВКонтакте: vk: 1c_36
Подписывайся на канала Желтого клуба, чтобы не пропустить интересных гостей
/ @yellow_club
![Объяснение 12 законов Вселенной и их Применение в Жизни [ЧТОБЫ ЛЕГКО ПОЛУЧАТЬ ЖЕЛАЕМОЕ]](/img/n.gif)
Да, выше сказанные проблемы есть...
Но в целом все решаемо, инструмент расширений - классный.
В своей организации используем одно расширение, все реквизиты и объекты добавляем в основную конфигурацию, в расширении только доработки.
По поводу форм в расширении: добавляем свою группу как можно ближе к корню формы и там уже располагаем все что нужно, помогает при глобальных изменениях формы при обновлениях релиза.
По поводу контроля изменения/исчезновения расширяемых методов из основной конфигурации: написан парсер файлов конфигурации. Выгружаем расширение и основную конфигурацию в файлы и анализируем. По результатам анализа можно уже вручную все поправить.
Свое программное редактирование тоже реализовано, но как объекты конфигурации (справочники). Дублирует основные настройки из конфигуратора с возможностью добавления обработчиков событий и команд.
Делали как подстраховку в случае проблем при работе с расширениями, но так и не получило широкого применения. Используем только для каких-то небольших доработок (просто вывести/скрыть реквизиты/команды без логики), в том числе для срочных случаев, когда надо "на лету" без обновления конфигурации.
Ну и сложные и критические механизмы покрываем тестами с помощью Vanessa Automation.
Таким образом обновления проходят максимально, на сколько это возможно, спокойно.
Да, 1С не дает всех инструментов для контроля внесенных доработок типовых конфигураций, но что-то можно сделать самим, что-то уже есть у сообщества.
Чисто на мой взгляд, процесс обновления релизов с расширениями стал проще, чем было раньше...
Спасибо за комментарий! Думаю многим поможет
Толково.
Покажите пальцем, где используются тесты. Таких единицы. Сам занимался таким обновлением (новые объекты\реквизиты в основной, кот в расширении). Большая часть методов перехвачено через Вместо. Приходилось каждый метод (а их не мало) проверять\мержить руками, чтоб потом не обосраться. Лично я считаю расширения (в том виде, в котором они существуют) хороши для хотфиксов или новый\дополняющий функционал, например интеграции с маркетплейсами. Т.к. через расширение юзер, не привлекая внимание санитаров (программиста), самостоятельно может обновить. Например в Озон хорошо (в последних релизах) сделали мастер обновления: Далее, далее - готово. Еще + от расширений (хотя спорный) может быть для небольших контор, у которых нет столько денег, чтобы доработки делать в основной конфе и платить программисту за обновление релиза. Почему спорный: раз обновил - норм, еще раз - норм. а потом все сломалось. Это как петля на шее, с каждым разом все туже.
Я это пишу не потому, что нравиться \ не нравиться, а из своей (и не только) практики.
Когда появились расширения - топил за их использования во всем. А выше мой опыт)
@@timurdanilenko3582 Если "таких единицы", значит тесты не использовать теперь? Или что Вы хотели этим сказать? 🙂 Инструмент есть, инструмент развивается - значит востребован. Использовать тесты или нет решает каждый сам. Имхо разработка и поддержание теста занимает меньше времени чем ручное тестирование. Говорю, как и Вы, про свой опыт.
Использование "&Вместо" - тяжело, согласен. Сейчас выгоднее использовать вместо с контролем. В любом случае при обновлении релиза нужно контролировать изменения кода/логики, если вносите коррективы в типовое поведение, без этого никак. Иначе могут быть плачевные последствия. Собственно, как и раньше приходилось контролировать внесенные в основную конфигурацию изменения.
Несомненный плюс расширений в том, что можно вынести логику, которая не связана с типовыми механизмами, отдельно. А при обновлении не тратить время на перенос этих изменений из релиза в релиз. Нужно стремиться свои доработки делать максимально изолированно.
@@So_Fluffy я ничего против тестов не имею. Только за. Вся проблема в обновлении типового, эт то, что нельзя сравнить с расширением(ями), т.е. не проведешь 3-х стороннее сравнение. Если не использовать расширение, то при обновлении сразу будет видно на что нужно обратить внимание. Сразу внести правки, ну или просто смержить. Лично я не нашел подходящего инструмента, который бы мне показал, что поменялось в типовой по отношению к расширению. Можно, конечно, забить на проверку всего и вся (как я это делал, не забивал, а проверял все и вся) кода\форм. Но, в таком случае выяснять что не так может быть очень затруднительно, когда у юзера чтонить отвалится.
Расширения хорошая штука, но не нужно забивать гвозди микроскопом. Вот
Могу сказать как делал я. Все реквизиты которые хранят данные нужно добавлять в основную конфигурацию. А код в расширение. Форму при изменении разработчиками не потеряется и данные все будут на месте. Код всегда можно поправить. Заморочки были, но потери данных - нет.
Да этот подход упрощает создание запросов и отчётов в расширениях.
ДА, все хранимые данные нельзя добавлять в расширения. Кроме того, в случае изменения 1С структуры данных объектов, либо в случае использования вызовов &Вместо После и тп - не решает задачу расширений. И приходиться переписывать за "расширяльщиками" код.
потеря данных будет только при удалении расширения, но не при отключении. В коммерческие продукты в виде расширения вполне допустимо добавлять реквизиты в расширение
Нужно помнить главное правило ВСЕГДА создавай элементы формы только программно!
Я бы с удовольствием создавал ВСЁ программно. Программа должна быть набором текстовых модулей с возможностью их обработки любыми инструментами. Когда 1С поймет эту гениальную мысль, которую нормальные программеры поняли 40 лет назад - она перестанет выедать мозг у прикладных разрабов и возможно даже захватит мир.
@@user-xl8wn6ge2m никто ничего уже не переделает, будет так как есть.
@@vladyan01 1.С. - Одна Стабильность
В конфигураторе редактор формы нужен для работы над дизайном интерфейса, сгенерировать программный код на основе дизайна нет никаких проблем, благо есть куча обработчиков обегающих форму по элементам с генерацией кода который остается только вставить. Вообще не вижу проблем с этим.
Расширения это одно из лучшего что есть в 1С, если правильно их готовить то типовые обновления и локальные обновления работают отлично, скорость разработки и внедрения увеличивается. Данные в основной конфигурации, остальное в расширение, минимально меняйте типовые модули, тем более типовые регистры, если жизнь заставила используйте &ИзменениеИКонтроль, перед, после, реже вместо... Вводите регламент разработки, за нарушение соответствующие штрафные санкции. Тут получается аналогия торцовочной пилой отпилил себе пальцы из за нарушения техники безопасности, и запретил себе и подчиненным ее использовать, пилят лобзиками.... Если продолжать тему надо запретить СКД и динамические списки, из за неправильного использования вешается сервак ;) Придем к счетам, хотя они тоже опасны )))
Если с меня будут удерживать деньги, то я точно на расширениях ничего пилить не буду😂
если ПРАВИЛЬНО! а если НЕПРАВИЛЬНО, когда объекты фигачатся в расширении?! все равно надо при обновлении конфы с расширением всех выгонять (((
Используем расширение. Притом в нашей компании принято по максимум использовать их, т.е. и данные хранить если добавляем новые реквизиты. И часто бывает, когда делам для одного заказчика и понимаем, что это может быть полезно для других выделяем в отдельное расширения, которое удобно распространять и продавать. Проблема с тем, что работают несколько программистов с одним, расширение решается через хранилище конфигурации. Проблема, конечно, с формами есть, но при обновлении конфигуратора видно, что будет форма обновлена, тут, конечно, нет у нас заказчиков с 50+ расширениями, но надо идти к уменьшению их. Главный плюс для нас - это то, что расширения нам дали выделать какие-то решение в отдельный продукт и продавать их, а также в дальнейшем удобно их улучшать и сопровождать.
Круто 💪
Тоже когда-то пилил расширение, которые потом продавал
Спасибо за стрим) пересмотрел 2 раза, сам все перепроверил и очень продуктивно выступил на собрании на тему :" использовать ли расширения на новом проекте")
Рад, что было полезно
1. Проблемы с формой в расширении легко решаются...элементы на форму нужно добавлять программным способом в процедуре "ПриСозданииНаСервереПосле."
2. Не решается никак, Вариант только грамотным выбором логики захвата процедур или создания Собственного функционала тестирования кода.
Спасибо за стрим и за поднятые проблемы с расширениями. В доп материалах стоит ждать функцию ДоработатьФорму ?
Функции в доп материалах не будет.
Пишите Алексею в тг. Он пришлёт
Год назад переводил контору со 2й редакции бухни на 3ю. Нетиповую. Допиливал справочники, доки. Начал с тройки, допилил, потом переход, потом перенос данных. Потратил часов 60 учитывая исправления ошибок учета. Когда в следующий раз накинули клиента с нетиповой двойкой-нарисовал все расширением за пару дней. Если мне еще кто на вопрос ответит, где хранятся данные, которые мы закидываем в созданные в расширение, то я вообще жену выгоню, на расширении женюсь. Красотка.epf
Тим лид должен следить чтобы не было много расширений. У нас например одно расширениес типом адаптация подключенное к хранилищу 1С и все разрабы с ним работают(проблем с монопольным доступом нет, так как мы используем одни из подходов git flow при работе с хранилищем, то есть каждый в своей конфе и расширении работает и перидиодически делает пулл из хранилища разработки в свою конфу и расширение, а потом когда его функционал гоотов , то делает пуш через сравнение объединение устраняя конфиликты, но обычно их не бывает потому что временной лаг перед пушем и пулом кототкий) и каждую неделю доработки из нее перетекают в релиз, тем самым одно очищается. Расширение с типом исправление только от вендора ставим вручую, и только если они не перекрывают наши доработки, а если перекрывают то частично переносим код исправления из этого расширение в состав релиза. Расширение с типом дополнения также ставим только от вендора с по алгоритму как для расширений с типом Исправление. Этот подход пока не сломал нам ничего в том числе и накатывание типовых релизов.
Элементы формы всегда создаем программно в самой конфе , но есть две проблемы - это то что форма плохо кэшируется из за этого и то что пользовательская видимость в режиме предприятия для программно добавленных на форму реквизитов не работает. Возможно эти две проблемы уже устранили в новых версиях платформ.
Кстати ещё один незатронутый вопрос расширений. Если вы будете структуру данных менять в расширениях, то вам придётся все запросы научиться писать либо без консоли запросов, либо в пользовательском режиме, когда консоль видит все изменения данных всех расширений . Ну и с разработкой отчётов придётся помучаться.
Отличное замечание! Спасибо
Не смотрел, но тезис в заголовке полностью поддерживаю
Камент не читал, но автора поддерживаю 😂
У меня к УТ к основной конфигурации подключен купленный модуль. Весь чувствительный код в закрытых модулях обработки. Постоянные обновления. Расширения - единственный метод доработки.
почему нет до сих пор в 1с общего обработчика при создании любой формы? для программных доработок универсальных на несколько форм сразу.
12:00 Каждый реквизит формы (в т.ч. основной) расширяется отдельно и при необходимости. Если мне необходимо внести изменения в поведение формы без участия реквизитов формы, то нет никакого смысла добавлять их в расширение. Мне, как разработчику, это понятно и очевидно.
Подавляющее число доработок делаем для клиентов в расширениях. Да, приходится в некоторых случаях обходить ограничения (отсутствие констант в некоторых режимах совместимости, невозможность изменить составной тип, конструктор запросов не видит все объекты, добавить в существующий справочник предопределённого элемента). Но в целом по мне - отличный инструмент. Кстати, на экзаменах спецов сначала по УТ, а теперь и по ЗУП в билетах требование - доработка в расширении. Т.е. сама 1С склоняет к использованию расширений.
Все верно, доработка функционала расширений дело времени. Я понимаю что многие делают бизнес на обновлениях 1с, а тут хоп и ничего обновлять не надо, расширение выкатил разработчик и заказчик сам поставил. А посредник обновлятор сервисник не у дел. Обида ясна. В свое время так грохнули обслуживателей кассовых машин. Я бы посоветовал многим взяться за разработку, а не заниматься сбором денег с населения за рутинные операции по обновлению 1с, которые со временем по любому сведут к расширениям.
+100500
НО! при перенесении объектов и данных из расширений можно воспользоваться КД ))) Очень удобно - создать доп базу, в которой не будет расширений, навносить туда объектов из расширений и через КД сделать выгрузку-загрузку ))) опробовано в ЕРП БМК-БТК (которое вовсе не ЕРП, а сброд производственных хотелок из прежней БП поверх конфы ЕРП без использования ее типового функционала, хотя ткацкое производство и не такое уж сложное), где "гении от 1С" сначала фигачили объекты документов-справочников-регистров в расширениях, а потом все равно пришлось это переносить в основную конфу )))
Здравствуйте. При внедрении типовых конфигураций постоянно использую расширения (Новые объекты метаданных создаю конфигурации, весь новый код выношу в расширения, вывожу реквизиты на фору программно в процедуре "При создании на сервере после", в таком случае если перестает работать расширение не теряются данные т.к. объекты добавлены не в расширении а в основной конфигурации и при обновлении формы реквизиты тоже не пропадают т.к. они выводятся кодом ). Данная схема работы с расширениями очень упрощает процесс обновления конфигураций.
Да все так и делают, очень странно что это звучит как претензия к расширениям.
Если я когда-нибудь буду устраиваться на работу в компании, и на собеседовании я выясню, что компания - фанат расширений, я скажу им "спасибо, вы мне не подходите". С подобными уже под одним из прошлых видео спорил, сейчас не буду ничего писать...
Комментарий без комментария у Вас. Это мне напоминает спор между мной, владельцем здания в Москве (занимаемся разработкой с использованием расширений кстати) и неким специалистом по автомобилям, что мой х6 2023 года плохая машина и он бы ее не купил спасибо и даром бы не взял)))). Так же и ваше неприятие расширений- это ваше право быть таким забавным каким вы являетесь, но может вы их готовить не умеете? Таких много ходит по улице и знают как управлять миром и что им не подходит по жизни. Вот если бы ничего не писали, а показали решение-лидер с продажами от 50 млн в год (хотя бы) вашей разработки БЕЗ расширения (именно вашей лично а не работодателя), я бы готов слушать был Вас часами.
@@user-su5zk9vw3g Сами то что сказать хотели? У меня опыт разработки на расширениях более 3 лет, в различных комбинациях, плотно, сотни расширенных методов, несколько расширений в одной базе, обновление расширений по поставке вендора, и тому подобное. Почему-то уверен, что опыта побольше будет, чем у вас? И я смело могу сказать, что расширения - это шлак. Иногда терпимый шлак, если в них СЛИШКОМ много не писать. Это мое мнение. Что вы пишете то вообще, себя послушайте, какие 50 млн в год продаж, лол, в 1С? Да просто напишите, что вы только Илона Маска слушать будете, и все. Я при своем мнении. И в своем комментарии, кстати, прочих не спрашивал.
А сейчас при проверке возможности применения на несуществующие процедуры все-таки ругается. В топ!! Только я не знаю, с какой именно это платформы работает. Я вроде бы на 8.3.22.1923 проверял
Евгений, скажите, сколько лет у Вас опыта? А у Алексея?
В принципе, после обновления можно сделать сравнение - объединение расширений и посмотреть, что потерлось...
Зачем тогда расширения? Тогда уж дорабатывать как обычно
Какая версия платформы?
Информация полезная. Но, как можно говорить о переносе в продуктив обновлений/изменений без тестирования. В том числе функционального, на серьёзном проекте/клиенте если этого нет, то виноваты сами и клиент и подрядчик. Ситуаций сотни можно описать и смоделировать где платформа/инструмент не отрабатывает, но разве это оправдание переносить в работающую систему не проверенный код и функционал. Всё решается организационными вопросами. А ответ ваш: «А кто же пользуется тестами, все забивают» - просто шедевр! Регламенты и культуру разработки надо внедрять.
Конечно тесты надо внедрять. Но на практике мало кто тесты пишет.
Можно в квартире открыть газ и через час зажечь спичку. И жаловаться потом, что газ в квартире это зло ))
В начале ролика есть отличные и наглядные тесты. Где номера обращений в 1С по описанным проблемам? Они потенциально могут быть признаны ошибками и исправлены. Тем более есть чистые воспроизводимые примеры. Если гость сам отправить не может, пусть свяжется со мной.
Думаю Алексей отправлять ничего не будет
@@yellow_club А думаешь он заинтересован, чтобы описанные в ролике неудобства/проблемы/ошибки устранили в платформе?
Не знаю 🤷♂️
Можно посмотреть код "мф_УправляемаяФорма.ДоработатьФорму()" ?
Пиши в телеграмм Алексею. Он пришлёт
Получается нужно внедрять QA тесты с помощью Vanessa. Они покажут, где ошибки.
Кто бы ещё тестами пользовался
Привет. По поводу контроля изменений процедур в расширениях я в свое время делал целую разработку на базе сппр. Суть в том, чтобы контролировать процедуры в расширения с любой директивой "до", "после", "вместо", "измененияиконтроль". Я делал через анализ выгруженных конфигураций поставщика до и после обновления. Кому интересно поищите посты в телегам канале "аналитик 1с - лайфхаки и кейсы", там же есть ссылка на инструкцию к продукту для контроля.
Сппр в массы)
а еще недавно хранить новые реквизиты в расширении было не гуд. Расширение отваливалось и терялись данные. И поди их верни. Благо бэкап есть. Ну а так не дай боже было сломать расширение данные можно было потерять окончательно. Обычно добавлял все новые реквизиты в основной конфиг что бы данные точно не потерялись.
Надо бы добавить ролик на тему "Динамическое обновление это ЗЛО". Тогда Зло расширений покажется не таким уж злом)
Вроде про демоническое обновление все знают, не?)
Если по крупному - любая доработка - зло для обновления... нет идеальных решений, хотя расширение придумано 1С не просто так
понять логику БСП невозможно даже под грибами :) Те. я сижу такой , придумываю процедуры глобальных модулей а также объекты, а потом кто то должен понять мою логику и использовать, супротив логики синтакс-помошника. Жесть. Расширения - постоянные глюки, пропадания реквизитов управляемых форм и стремление уничтожить все доработки с расширениями...
Так когда-то было версткой под ie
ничего никуда не пропадает, если делать все проф. По поводу реквизитов формы тут написали уже, генерируйте элементы программно
Честно сказать, мне проще включить среду разработки для Windows. И написать программу под организацию с нуля. Но это будет моя программа с определенным функционалом, закрытым кодом. И это проще, чем понять в 1С, почему у тебя все исчещает и для чего столько галочек.
А в 1С всё уже превращается в дурдом. Осталось добавить еще больше настроек и галочек, чтобы уже точно никто не разобрался. 😆
1С это платформа для бизнеса, вы не берете в расчет что 90% достоинства 1С это транзакционный учет учетных единиц компании с аналитикой по контекстам проводок. Напилить CRM или какой то учет по количеству товара может и школьник, а вы попробуйте сделать с листа под требования нормальной организации с учетом амортизации, финансов, взаимодействия с клиент-банком, ЭДО, налоговой отчетности, зарплаты больничных декретных и тд и тп? если у вас ларек то да, можете напилить что то типа trello или юджил и радоваться красивым колонкам но профита никакого это не даст бизнесу, только увеличит электронную бюрократию
@@user-su5zk9vw3g Я уже не занимаюсь программированием, ушёл в крипто бизнес.
Одна сторона медали расширений.
стандартные конфигурации зло. должен быть некий базис, остальное подключаться расширениями по необходимости. минимум половина присутствующего в стандартной конфигурации просто не нужно, но приходится волочить это постоянно в конфигурации
очень странное суждение. Есть выражение - если вы этого не видите, это не значит его нет или не нужно. Достоинство 1С транзакционная система зависимостей объектов. И половина того что вам якобы не нужно участвует в проводках или может участвовать и просто так выдрать именно под ваш случай из жизни не получится, по сути придется переписать конфу под ваш случай
страшно стало, после просмотра.
Надеюсь не ночью смотрел?)
@@yellow_club На ночь)
Блиииин, не надо было(((( скорее всего всю ночь кошмары снились)
Расширения придумали вендоры для быстрых фиксов своих косяков, в остальном это просто треш. Не используйте их никогда при разработке своих объектов
и вы клиенту навязываете часы обновлений? выход из базы и все эти танцы с бубнами?))
Вот если аналогию с сараем проводить, когда изучил концепцию работы отряда ножовочных то все понятно, но когда не знаешь как работает расширение почему то начинает подгорать... странно как то и однобоко, не хотел бы я у этого мужичка в подчинении работать..... "в расширениях я полный ноль", а о чем тогда говорить?..... очень странно
Супер! Люблю такие комментарии!
Посмотрим как ты запоешь когда всё таки тебе придётся "в подчинении у этого мужичка работать".
@@xrollup упаси бог)))))))))))
@@xrollup дак большинство начальников айти такие к сожалению. Как то на собеседовании на начальника айти мне привели мужичка в костюме такого солидного, я его попросил на словах изложить решение одной задачки. Он мне ответил - я же на начальника пришел, а не программистом)))
Зло для кого? Для Исполнителя - 146% зло. Для Заказчика - это панацея.
Первая претензия что надо отдельно включить в расширение объект в форме это чисто мелочь техническая. Вторая претензия, так а что хочет он? Если он добавляет свой элемент в форму скажем в расширяемый элемент-группу, а в обновлении скажем убирают группу в которую он включил его? Никто в здравом уме не будет в расширяемый объект добавлять элементы в дизайнере формы, только ПРОГРАММНО. Так что тут тоже ни о чем, так много времени потратили на чисто мелочи
11:22 дальше можно не смотреть, чел не шарит. добавлять реквизиты в расширении - маразм
Почему добавлять реквизиты в расширение это маразм?
@@yellow_club может он имел в виду добавлять не программно?
@@yellow_club "Почему добавлять реквизиты в расширение это маразм?" - странный вопрос, вы вообще с расширениями работали или только слышали о них? Обычно одним реквизитом и одним расширением это не заканчивается, когда у тебя куча расширений и куча реквизитов в документе добавлено, их найти это целый квест, во вторых в конфигураторе нельзя нормально написать запрос через консоль, и посмотреть написанный через консоль, в третьих есть типовой механизм добавления "Дополнительных реквизитов" в объекты.
Это первое что вспомнил, из вышесказанного.
@@yellow_clubпотому что реквизиты добавленные в расширении будут храниться в отдельной таблице от реквизитов объекта основной конфигурации. При обращении к БД ним будет формироваться запрос с соединением 2 таблиц, что критично на больших базах.
это же касается любителей использовать механизм доп. реквизитов на больших базах, там вобще будет соединяется 3 таблицы на каждый доп.реквизит.
@@yellow_club потому что эти реквизиты будут храниться в отдельной таблице и обращение к ним будет происходить через соединение. На больших базах это критично.
@recursion545 по поводу механизма "Дополнительных реквизитов" - это абсолютное зло, т.к. для получения значения реквизита нужно соединить 3 таблицы, причём на каждый реквизит. Это имеет смысл только на базовых конфигурациях.