Как в один реквизит влепить несколько элементов другого справочников ? #228680

Есть справочник,например контрагенты.У него есть реквизит "ПаркТехники".Нужно в этом реквизите держать несколько элементов типа=спр.Номенклатура.На форме поле,типа списокЗначений.Юзер кнопкой добавляет новый элемент номенклатуры в этот список.В дальнейшем предполагается сделать отчет в котором по заданным критериям будут выводиться контрагенты по списку параметров отбора:наличие опред. элемента номеклатуры,с опред.платежеспособностью,с опред.регионом,по закрепленному менеджеру и т.д. Это я к тому,что можно было бы сделать строковый реквизит неогр.длины и в него добавлять новый элемент номенклатуры,но потом у меня возникнут проблемы с написанием отчета.Да и вообще ненедежен реквизит с неогр.длиной.

А подчиненный справочник?

1 +1

1+1+1Подчиненный справочник, который считывается при открытии и заполняет Список значений на форме

Это первое,что пришло в голову,но там и так комплексная(еле ворачается),а если еще и подчиненный,то ляжет вообще.

аа... веская причина. ну ты удали пару-тройку других каких-нить, не особо нужных.

Мы легких путей не ищем :)) Блин,было бы на 8-ке.Ну а по теме еще есть какие предложения ?

в страшном сне мне не привидится пользовать такое ршение как 1+1+1+1

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

Блин,вы че,прикалываетесь ? Если бы через подч.справочник,то фиг бы тут спрашивал.Тут помню,тоже умники-теоретики-скептики на счет контроля доступа писали.Так сделал я и все нормально функционирует.ЗЫ.Хотел оригинальное решение,но какие-то вы тут все зашоренные в рамках ЖКК

А чем стандартный вариант (ТиС) "СвойстваКонтрагентов" и "ЗначенияСвойств" не подходят?

Честно говоря,давно не пользовал свойства кроме как для того,чтобы указать менеджера.Не думал,что все так просто,счас попробую.

"Все у нас получится!" (социальная реклама)

Не,сразу не сообразил.Не пойдет.Сам механизм смены не устраивает.Если у контрагента были трактор и эксаватор,а потом трактора не стало.Это же удалять нужно и будет он висеть помеченным до посинения.Блин,хоть отдельную дбф-ку заводить и там хранить.

Эх, Плюшкин, Плюшкин.... "Хотел оригинальное решение,но какие-то вы тут все зашоренные в рамках ЖКК"... На мир оглянись. Все машины на 4-х колесах отчего? "Зашоренность" во всем мире? Нет, оптимальность схемы. И стулья на 4-х ножках, и штаны по одной схеме шьют...И конструкция БД тоже подчиняется своим законам. И эти законы тоже диктуют оптимальные решения. В деталях искусство остается, в деталях, а принципиальные схемы - едины.Как конструкция штанов от разных кутюрье ;)

Ну и пусть висит, он же трактор! :)))

Очень Люблю синие трактора!

А если серьезно, то сделай "ЗначенияСвойств" периодическим и "трактор висеть не будет""...Санько, а милиционер все равно на тебе висит!"

А если экскаватор ? :)Ну так защита на уровне доступа к КОНКРЕТНОМУ реквизиту формы-это ведь тоже не стандартное решение и ни в каких мануалах не описано.Но ведь я сделал и эта защита работает.Или тот же механизм зачета НДС,я его сделал еще до того как фирма 1С такое в своих релизах стала использовать.Конечно-это больше было продиктовано моим нежеланием влазить в дебри типового формирования кнПродажПокупок и то,что бухи часто по своемУ разумению зачитывают НДС.

Не верю я, Плюшкин, что ты сделал как надо... Ибо даже в этой ветке просматривается отсутствие в твоей голове цельной логической конструкции. С одной стороны "Если у контрагента были трактор и эксаватор,а потом трактора не стало.Это же удалять нужно..." (кстати, не проблема), с другой - об отчетах говорил выше. А какие могут быть "отчеты" без истории? Если объекты уничтожаются по желанию оператора? Если нет хранимых ссылок на объекты?

VZ поддерживаю

Ну ладно,по сабжу я пока не определился.А вот про НДС ты зря.Еще когда 1С не сделала в своих релизах галку "ВключатьВКнигу", у меня уже она была.Ведь после выхода закона по НДС это настолько просто,что ошибиться там никак нельзя.Да и обработку по установке доступа к реквизитам я сделал как надо.Там нет ничего сложного(это мне сейчас так кажется),пришлось правда использовать 1С++(формЕкс) для получения идентиф. самих реквизитов ну и в некоторых справочниках проставить идентиф. где и небыло.

Чего вы его отговариваете? Человек нетленку ваяет! Не мешайте!  Делай! СЗ в строку и делу край! И зоопарку тоже ...

В своем репертуаре ? Лень СЕЙЧАС воспользоваться поиском по форуму,но раньше ради интереса глядел,кроме как обс...я других и обхаивания 8-ки,больше ничего по твоему нику не нашел.И еще.Если нечего сказать по теме,иди дальше,ладно ? Данная тема не имеет в своем заголовке слова "ОФФ",так что твой пост-флуд.Странно,почему модератор не удалил ?ЗЫ.Что заставляет мужчин брать себе женские ники ?

Хачу то - не знаю что...Сделать как - подскажите....Должно летать, ползать на полметра под землей и плавать на Луне....ну ка быстро подскажите ...А тоя вас быстро обо... обо .... обо... (не пропущено) и пайду весь в шакаладе...

Интересно узнать, для каких целей необходимо учитывать у контрагента технику?имхо, нормально решается через свойства, можно еще добавить реквизит СтатусСвойства, к примеру. ПаркТехники из контрагента долой. Оператор добавит новую строку в ВидыСвойств "ПаркТехники(принимает множественные значения)".И еще, с чего это от подчиненных справочников базы должны тормозить. Все и построенно на подчиненных, а как по другому?

1+1+1+1+...+1Слухай что дяди говорят."Это первое,что пришло в голову,но там и так комплексная(еле ворачается),а если еще и подчиненный,то ляжет вообще."Ляжет то как раз с твоим списком-строкой.А вот с подчиненным то чего ей ложится? Ты что там Министерству по сельскому хозяйству конфу дорабатываешь? У тебя там что, сотня тысяч клиентов с тысячей единиц техники по каждому?И ты отдельной таблице базы данных предпочитаешь огроменные строки в одной таблице? Каков следующий шаг? Дай угадаю. Уровень 5го класса, вторая четверть. Все записи хранить в текстовом файле и красиво отображать их в интерфейсе :)Отчеты ты как потом собрался строить? Неужто через ЗначениеИзСтроки?В общем, забудь про .

и"Ну так защита на уровне доступа к КОНКРЕТНОМУ реквизиту формы-это ведь тоже не стандартное решение и ни в каких мануалах не описано.Но ведь я сделал и эта защита работает."взаимосвязано... или всё таки это не оттуда???а по теме, помоему, самое оптимальное - служебный документ....

А я бы сделал через документы и регистр - была в своё время такая схема - учитывали холодильники у клиентов (холодильники были наши).

а регистр зачем.... из не вижу необходимости в регистре.. если тока историю хранить...... ну так в вроде нет этого

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

Ну так от тебя я иного и не ожидал :))) Что ни спроси,у тебя это давно реализовано :))) Вот только конкретики от тебя никогда не дождешься,только вода.Вы в курсе,что когда выполняется запрос(а в конфах на регистрах так почти всегда),то идет запрос ко ВСЕМУ справочнику,вот и подумай "дядя",от чего зависит быстродействие отчетов.Так что лучше не подначивай,я же уже сказал,что пока не вижу хорошего решения и не считаю,что решение в -хорошее,иначе не спрашивал бы здесь.И тут задал вопрос не для того,чтобы слушать <фильтр не пропустит> типа и.Если есть по существу,то пожалуйста.Нет,защита не у этого клиента,к тому же прекрасно работает и не тормозит.Тем более,что ВК используется только для получения ид.реквизитов.А вот про подчин.док подробнее можно ?.........Если кто с 8-кой работал,то должны знать как там реализованы табличные части в справочниках.Вот примерно так и требуется.

где бы ты ни хранил инфу, из индексированной дбф достанешь быстрее.

[0]Итого видится три варианта:1) В подчиненном справочнике (идеальный);2) В реквизите типа строка неограниченной длинны как СЗ преобразованный в строку (пойдет только для хранения ненужной инфы);3) [32] во внешнем файле (почему бы и нет?).

а чего подробнее то..у реквизит ДокПарка... по кнопке пускай открывается документ... там можно состав менять....подробнее не могу, ТЗ то нету...

Документ

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

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

[0]Только не документ. Тогда твоя комплексная совсем загнется ...раком

ну уж изменять, так обработкой что-ли....а, так да... каждому контру (которму надо) - свой док...

какая разница, документ это будет, или подчинёный справочник?

[40]1)Быстрее заполнить ТЗ открыв выборку по подчиненным элементам.2)Сколько в АТСке общих ревизитов, граф отбора для журналов документов? Какие таблицы займут больше места, "справочные" или "документные"?

Можно, только в базе прибудет две таблицы, одна из которых тоже подчиненная. А автор, к подчиненным категоричен, так что - забудь :)p.s. кстати , так и не объяснил, нафига у контров технику считать. Может тогда лучше сразу предусмотреть банк и кассу?. имхо больше пользы ;)

да ну?!"Быстрее заполнить ТЗ открыв выборку по подчиненным элементам." - это быстрее чем просто тупо открыть документ?! да ладно... не верю..."Сколько в АТСке общих ревизитов, граф отбора для журналов документов?" - не знаю не считал.... тока не углядел связи с обсуждением...."Какие таблицы займут больше места, "справочные" или "документные"?" - не заню... думаю всё зависит от справочника и Документа соотвественно, нет?

документами имеет смысл хранить динамически изменяющиеся массивы данных, в справочнике хранить статические, имхо в этом случае справочник, а для комплексной - _лучше_ справочник именно из-за общих реквизитов

[44]Ну хватит его пинать :] Поспорить захотелось может человеку... аFтор просил же незашоренные взгляды.[0]Создать специальную отдельную базу 1С. Открывать через ОЛЕ :))) (очень свежее решение)

(440 ну так ТЗ давайте... бум смотреть какой у него там массив, динамический али статический..... а при чём тут общие реквизиты??

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

ТЗ в причём довольно странное, общие реквизиты _всегда_ причём, по ним лишние индексы строятся, соответственно размер базы вспухает, в подчинённом справочнике неиндексируемом этой лишней инфы не будет... бесполезный спор - мой ответ один из первых был...

с ТЗ - согласенно согалсно данные как раз динамические...

под динамическими я понимаю те данные которые меняются _часто_в моём случае был подч справочник Остановки, подчинён Маршруты, их забивали 1 раз и раз в полгода корректировали, а был ещё и документ типа "Расшифровка маршрута" вот он присобачивался к путевому листу, первоначально заполнение шло из подч. спр., потом оператор менял порялдок проезда маршрута и выгр/загр вес...вот в спр. _почти_ статическая инфа, а документ прослеживает динамикупо ну не все же _каждый_ день/месяц парк техники меняют/обновляют

про остановки согласен...