Дополнительные реквизиты табличных частей в БСП
Добрый день!
Большой недостаток любой типовой конфигурации - отсутствие у заказчика возможности самостоятельно добавлять аналитику в табличные части документов или справочников (без снятия запретов на изменение конфигурации производителя).
А как было бы удобно получить такой функционал в виде "Дополнительных реквизитов табличных частей в БСП"?
(типовая конфигурация стала бы тогда на 99% универсальной и заказчику осталось бы использовать штатный СКД).
С уважением
Большой недостаток любой типовой конфигурации - отсутствие у заказчика возможности самостоятельно добавлять аналитику в табличные части документов или справочников (без снятия запретов на изменение конфигурации производителя).
А как было бы удобно получить такой функционал в виде "Дополнительных реквизитов табличных частей в БСП"?
(типовая конфигурация стала бы тогда на 99% универсальной и заказчику осталось бы использовать штатный СКД).
С уважением
По теме из базы знаний
- Универсальное заполнение реквизитов табличных частей документов штатных конфигураций (УФ + БСП 2.2)
- Групповое редактирование реквизитов табличной части и движений документов LITE (управляемая форма)
- Табличная часть из дополнительных реквизитов с обработкой событий в расширении
- Наглядные доп.реквизиты товара в табличной части документа за 5 минут
- Дополнительные реквизиты табличной части документов без изменения хранения данных
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) dj_serega, В том то и беда - авторы не согласны с идеей как с вражеской! А за такое упрямство платят ни в чем не повинные пользователи - за коверканье структуры базы данных со снятием замков. А план видов характеристик добавить в БСП + вывести на формы еще одну табличную часть или регистр сведений между тем заняло бы у разработчиков часы и конец мучениям.
(5) zekrus, в шапках как раз нужны.. ведь они расширяют реквизиты регистратора! А вот детализация до регистратора - вполне востребована для отчетов. А по табличной части много вы видели отчетов с детализацией до табличной части? не до движений, а именно до строк таб части...?
ПС: касаемо технической точки зрения реализация доп реквизитов для таб. частей тоже не однозначна.. ведь доп реквизиты существуют только для ссылочных объектов, а у конкретных строк таб части - нет ссылок, поэтому привязка через стандартные методы платформы уже не получится
ПС: касаемо технической точки зрения реализация доп реквизитов для таб. частей тоже не однозначна.. ведь доп реквизиты существуют только для ссылочных объектов, а у конкретных строк таб части - нет ссылок, поэтому привязка через стандартные методы платформы уже не получится
(7) zekrus, тогда мне непонятно как эти доп. реквизиты будут попадать в значения движений конкретных регистров (причем видимо часть должна попадать в измерения, а часть в ресурсы). Лично для меня реализация подобного механизма на платформе не ясна даже теоретически. Что например будет если я захочу в элементарно группировать одинаковую номенклатуру в ТЗ для формирования движений и складывать количество? куда доп. признаки девать будем ?
(8) AllexSoft, В СКД если обратите внимание уже есть возможность выводить дополнительные реквизиты. Аналогично стоит поступить и с табличными частями. Собственно и записывать в этом случае в движения документа эту аналитику не будет нужно, ее будет видеть отчет по ссылке регистратора.
(9) zekrus, я вам уже объяснил в (6) почему это нельзя, потому что 1С придется менять идеологию работы таб частей и делать для каждой строки уникальный идентификатор... так что
вот это не получится... аналогично. Ответьте себе на вопрос чем отличается непериодический регистр сведений от справочника? Думаю если вы поймете зачем вообще они в разных метаданных то все встанет на свои места.
по регистратору и сейчас есть, а до таб части - и не нужно. Еще раз что будет если я записывая движения буду просто группировать номенклатуру одинаковую и записывать движения в регистр? у меня будет записей в регистре 10 скажем, а в таб части 20.. потому что каждая вторая номенклатура была введена повторно.. что будем пользователю показывать записи регистра или записи таб части?) Думаю вы не совсем понимаете смысл создания регистров как таковых и зачем 1С так настойчив в своих методиках не выбирать данные по документам, а использовать именно регистры для выборки в отчетах.. не из за быстродействия или удобства виртуальных таблиц (хотя это тоже), а совсем по другим причинам.
Аналогично стоит поступить и с табличными частями.
вот это не получится... аналогично. Ответьте себе на вопрос чем отличается непериодический регистр сведений от справочника? Думаю если вы поймете зачем вообще они в разных метаданных то все встанет на свои места.
Собственно и записывать в этом случае в движения документа эту аналитику не будет нужно, ее будет видеть отчет по ссылке регистратора
по регистратору и сейчас есть, а до таб части - и не нужно. Еще раз что будет если я записывая движения буду просто группировать номенклатуру одинаковую и записывать движения в регистр? у меня будет записей в регистре 10 скажем, а в таб части 20.. потому что каждая вторая номенклатура была введена повторно.. что будем пользователю показывать записи регистра или записи таб части?) Думаю вы не совсем понимаете смысл создания регистров как таковых и зачем 1С так настойчив в своих методиках не выбирать данные по документам, а использовать именно регистры для выборки в отчетах.. не из за быстродействия или удобства виртуальных таблиц (хотя это тоже), а совсем по другим причинам.
(10) AllexSoft, Именно про идеологию я и завел сабж. Справочник - объектная сущность, регистр - нет. Как раз до табличной части можно и нужно! А по поводу быстродействия и т.д. подумайте вот об чем: Что делает с базой заказчик? Да тоже самое, просто своими кривыми ручками и при этом платит кучу бабла. Вот тут я думаю собака и зарыта. Как в анекдоте про молодого и старого доктора.
(11) zekrus,
ну тогда вы не правильно выразились в (1)
тогда недостаток платформы... ибо таб часть это тоже не объектная сущность, как регистр...
вы только запутаете пользователя.. он будет видеть что по отчету записей 2, а в табличной части их 4ре причем по тому же отчету, просто с доп. аналитикой! а может и вовсе больше, ну например что то не записалось с отрицательными остатками, или какие нибудь строки с флагом (Отменена).. да бог его знает сколько алгоритмов можно придумать почему не все строки в ТЧ могут быть записаны в регистры в конечном итоге..
ПС: по поводу доп реквизитов как таковых, они удобны только для каких то косметических вещей, ради которых не хочется трогать конфу.. для всего остального, лучше изменить конфу и добавить обычный нормальный реквизит. Был печальный опыт когда свойства номенклатуры сделали через 20 доп реквизитов, потом расхлебывали когда аналитикам понадобились отчеты и обработки по ним..
Именно про идеологию я и завел сабж
ну тогда вы не правильно выразились в (1)
Большой недостаток любой типовой конфигурации
тогда недостаток платформы... ибо таб часть это тоже не объектная сущность, как регистр...
Как раз до табличной части можно и нужно!
вы только запутаете пользователя.. он будет видеть что по отчету записей 2, а в табличной части их 4ре причем по тому же отчету, просто с доп. аналитикой! а может и вовсе больше, ну например что то не записалось с отрицательными остатками, или какие нибудь строки с флагом (Отменена).. да бог его знает сколько алгоритмов можно придумать почему не все строки в ТЧ могут быть записаны в регистры в конечном итоге..
ПС: по поводу доп реквизитов как таковых, они удобны только для каких то косметических вещей, ради которых не хочется трогать конфу.. для всего остального, лучше изменить конфу и добавить обычный нормальный реквизит. Был печальный опыт когда свойства номенклатуры сделали через 20 доп реквизитов, потом расхлебывали когда аналитикам понадобились отчеты и обработки по ним..
(12) AllexSoft, Препираться можно до бесконечности. Факт снятия замков остается - это бантик который хочет заказчик в 99% случаев. И как раз задачей производителя на мой взгляд и является этот бантик вшить в штатный функционал с оговоркой об ограничениях. А уже использовать функционал или нет дело хозяйское. Как по вашему удобнее расхлебывать данные в конфигурации на замке или со снятыми замками? В моем понимании на замках как то спокойнее (хотя очевидно, что ошибок и у производителя хватает - один только партионный учет в УТ 11.0 чего стоил?).
(13) zekrus, про включение изменений в конфигурацию я с вами согласен, это нежелательно в любом случае. 1С много что еще нужно сделать, в том числе возможно и с таб частями (мне иногда пригождалось связывать 2 таб части, было бы удобно если строки таб частей были ссылочными, иначе приходилось вводить свой уникальный идентификатор связки в поле ТЧ). Но сейчас помоему гораздо актуальнее доработка динамических списков, там много событий которые бы очень хотелось, например типа ПриЧтенииДанныхНаСервере, возможность работы с пакетными запросами.. Возможность в одном запросе использовать внешние источники и объекты метаданных. По самому языку запросов много пожеланий.. Элементарно только что мне надо было типа условия
Где Обьект1.Комментарий + Объект2.Комментарий ПОДОБНО &Текст , а нельзя.. 1С не умеет.. пришлось через ИЛИ в 2 условия писать..
По RLS механизмов никакних нет, ни отладки шаблонов, ни грамотного понятного журналирования ошибок доступа, ни конструктора шаблонов..
По СКД, нет редактора формул СКД, механизм макетов тоже не однозначный..
Потом уж можно и доп. реквизиты для таб частей )))
Где Обьект1.Комментарий + Объект2.Комментарий ПОДОБНО &Текст , а нельзя.. 1С не умеет.. пришлось через ИЛИ в 2 условия писать..
По RLS механизмов никакних нет, ни отладки шаблонов, ни грамотного понятного журналирования ошибок доступа, ни конструктора шаблонов..
По СКД, нет редактора формул СКД, механизм макетов тоже не однозначный..
Потом уж можно и доп. реквизиты для таб частей )))
Коллеги, я тут столкнулся с интересной методикой обновления конфигурации средствами СУБД (без 1С):
1. Внешней обработкой в 1С получается структура полей новой конфигурации.
2. Прямым запросом в СУБД проводится сравнение метаданных с генерацией текста запроса создающего копию таблиц с данными с строящего пустые с новыми полями.
3. Прямым запросом в СУБД создаются новые таблицы и меняются поля в существующих.
4. Прямым запросом в СУБД переименовываются таблицы с данными на новые имена.
1. Внешней обработкой в 1С получается структура полей новой конфигурации.
2. Прямым запросом в СУБД проводится сравнение метаданных с генерацией текста запроса создающего копию таблиц с данными с строящего пустые с новыми полями.
3. Прямым запросом в СУБД создаются новые таблицы и меняются поля в существующих.
4. Прямым запросом в СУБД переименовываются таблицы с данными на новые имена.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот