Хранение дополнительных характеристик #227877

Добрый день. Задача: хранение дополнительных характеристик объектов в не самих объектов. Регистр сведений со стандартной структурой (измерения: объект(тип справочник.Номенклатура к примеру), ПланВидовХарактеристик, ресурсы: ЗначениеХарактеристики) подходит для хранения уникальных значений, и подходит очень хорошо, система сама контролирует уникальность а как быть с неуникальными значениями? придестя прикручивать что-то еще(другой регистр сведений или еше что) А как можно организовать хранение уникальных и не уникальных характеристик в одном месте?

А зачем может потребоваться хранение не уникальных характеристик?

Как зачем? Предположим характеристика "регион сбыта". Это может быть как "Москва" так и "Ижевск".

Справочники отменили...

т.е.?

Сделай в справочниках...

может я не правильно поставил вопрос, как огранизовать хранение "многозначных" характеристик. Т.е у одно позиции может 1 и более значение одной характеристики. Вопрос как это хранить лучше всего. Господин ПЖ, фразу "Сделай в справочниках" я не понимаю, что в них делать не понятно, какие связи, чтоо к чему относится не понятно... опишите суть вашего предложения, пожалуйста, поподробнее.

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

нет у меня типовых 7.7...

Делай подчиненный справочник "регион сбыта" - и храни там все что хочешь.

чего!? сам понимаешь ошибочность своего предложения? Регионов сбыта "Москва" у меня будет ровно столько, скольким позициям номеклатуры я назначу свойство "Регион сбыта"... Народ, ей! Вы чего после праздников такие "медленные" :)

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

Если ты такой умный почему сам недогадаешься сделать не подчиненный справочник, а обычный??????

+ А подчиненность нужна для многих видов свойств.

Ребята, прости меня тупого но.... Мне необходимо хранить для каждой позиции справочника номенклатуры различные дополнительные характеристики. Причем хранить их необходимо учитывая следюущие требования: 1. Изменение, добавление, удаление видов характеристик должно осуществляться пользователями (ПланВидовХарактеристик идеально решает эту задачу) 1. Версионность (что идеально реализуется с помощью РегистровСведений) 2. Все изменения(назначение характеристик позициям номенклатуры, изменение, удаление) должные регистрироваться документами (РегистрыСведений тоже удовлетворяют этим требованиям) С уникальными характеристиками проблем нет (т.е. одна позиция номенклатуры может иметь только одно значение определенного вида характеристики, например Производитель или Бренд). Все супер. Но как мне поступить с видами характеристик, значений которых может быть несколько у одной позиции номенклатуры, например регион сбыта.

Добавь Третье измерение в РС по вкусу, первые два - ссылка на справочник и на характеристику.

Т.е. из регистра сведений со структурой РегистрСведений.ХарактеристикиНомеклатуры    Измерения:    Ресурсы:        ЗначениеХарактеристики;    Реквизиты: сделать регистр сведений со структурой Я правильно понял?

туплю.... чушь в написал.

Делай регистр сведений с периодичностью "По позиции регистратора"

Если ты о многозначных свойствах, тогда чем это поможет? В регистре сведений номер записи не входит в ключ, поэтому одинаковые значения измерений и даты одним документом записать не получиться. Или опять я туткак...

А зачем размышлять? Ты проверь. Если неполучится, то опиши пример, который неполучился.

А одинаковые это как? Два раза одной и той же номенклатуре присваивать Регион сбыта - Москва ? Какой в этом смысл? Вот если разные "Москва" и "Ижевск" - это я понимаю, а иначе никак.

Если стуктура регистра сведений   Измерения Тогда конешно ты прав, а если РегистрСведений.ХарактеристикиНомеклатуры    Измерения:        ЗначениеХарактеристики;    Реквизиты: Тогда обломс... :)

В табличной части значения характеристики.

что мешает сделать, как в , вариант 1 ?

вдогонку... форму списка(набора) регистра в форму элемента номенклатуры, отбор по первому измерению ессно и ровно через 2 мин механизм готов и работает...

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

Мешает то, что нам необходимо учитывать требование версионности харакатеристик, т.е. знать на какую дату какое было значение той или иной характеристики... и если использовать структуру регистра сведений из вариант 1, метод СрезПоследних на "Дата" будет возвращать таблицу значений состоящую из всех изменений произведенных до "Дата". Т.е. если я установил значение характеристики А для номеклатуры Н на 01.01.2006 равным B, а на 01.01.2007 равным С, то метод СрезПоследних на дату 01.02.2007 вернет таблицу значений:     Дата:        Номенклатура:      Характеристика:           Значение: 0. 01.01.2006           Н                  A                       B 1. 01.01.2007           Н                  A                       C А мну надо чтоб по правильному, по идеалогии... как сделать не знаю... :(

Но ведь именно этого ты и добивался в 0, разве не так?

+28. Неуникальные характеристики по объекту и представляют собой ТЗ.

нет, я не пытался этого добиваться... согласно назначению регистровсведений, его Срезы... дают значение ресурсов на определенную дату, а в я получаю не значение ресурсов на дату, и даже не набор измерений на дату, а вообще все изменения до даты...  и соответственно для УНИКАЛЬНЫХ характеристик я получаю ту же байду....и к тому же.... есть у номенклатуры Н на 01.01.2006 характеристика A c набором значений B и С,с 01.01.2007 у номенклатуры Н значение характеристики А должно быть D и Е... если я буду использовать вариант 1 из то при получении СрезПоследних на Дату 01.01.2007 я получу ТЗ в виде     Дата:        Номенклатура:      Характеристика:           Значение: 0. 01.01.2006           Н                  A                       B 1. 01.01.2006           Н                  A                       C 2. 01.01.2007           Н                  A                       D 3. 01.01.2007           Н                  A                       E а мне надо чтоб было было только D и Е.

можно попробовать регистр накоплений использовать

У меня работает. В результате только D и Е дт=01.01.2007

мне кажеться регистр накопления в данном случае использовать нерационально.. представь у меня 40000 позиций... по каждой около 15-20 характеристик - этот регистр накопления просто станет тормозом всей системы... регистры сведений гораздо шустрее шуршат.. хотя я могу ошибаться.

+ Или, можно так: Что тоже самое

РегистрСведений1 - опечатка

Представь к примеру ситуацию, мне необходимо получить значения характеристики А у номенклатуры Н. История изменений характеристики А у номенклатуры Н: 1. 07.08.2006 мы установили значение Характеристики А как B и С; 2. 12.12.2006 мы установили значение Характеристика А как D и E; Получи мне запросом значение характеристики А на дату 01.01.2007... (заметь ты не знаешь как значения это характеристики менялись во времени). Откуда тебе знать на какую дату тебе надо отфильтровывать записи условием "Период >= &дт"? Не получишь...

Неужели 1С-сообщество Мисты не в силах мне помочь? :(

Получается что выход один: Регистр Сведений со следующей структурой Измерения Такая стуктура позволит хранить как уникальные так и не уникальные характеристики, организовать версионность и документарность. Или у кого-то еще какие мысли есть?

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

индексировать по нему или нет?

Zolotorev  - ты это имел ввиду?

по прежнему , вариант 1... РегистрСведенийМенеджер, метод СрезПоследних, 2-й параметр... доп инфо(разработка в системе 1С:предприятие 8.0, автор сами знаете кто, стр.327,328..)

ты не прав, вот описание метода СрезПоследних: Получает наиболее поздние записи регистра, соответствующие установленным в параметрах метода значениям ключевых полей. Записи подбираются для КАЖДОГО СОЧЕТАНИЯ из всех имеющихся значений измерений. так что только вариант и ничего более.