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

вопрос в том КАК? и кто похожее делал

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

не, не надо объяснять зачем
объясни лучше как по нему суммировать остатки?

регистр сведений.... ХМ а как же ключевое поле ? т.е. измерние...
да и будет при чтении на SQL производительность низкая...

(2) я бы сказал это как  булево ... есть или нет .... скажем как то так ...

(4) чего?

немного поясню задачу... есть ячеистый склад ... есть пачка номеклатуры (у нее свой весь который хранится в справочнике)  движений по нему не может быть ... пачек не может быть одинаковых .... дак вот мне надо знать в какой ячейки какие пачки ))) както так

что мне приходило на ум .. дак это только то что в ресурс пихать движения с +/-1 ... и соотвественно искать итоги

+1, -1 не подйдет никак в ресурсе?

пачки уникально идентифицируются? тогда РС

я почти закончил писать приложение на LightSwitch но руководство забоялось ... что если я уйду то поодерживать они не смогут

(9) да они уникальные...  в регистре будет не то .... т.е. регистр с измерением пачка в ресурсе ячейка.... немного не прально ... хотя похожее решение я делал в Лайте

(6) Классическое описание Регистра Сведений. Зачем вам Регистр Остатков?

(12) из-за незнания 1С.

(12)(13) если вы не заметили то меня интересовали остатки ... так как при размерах записей в несколько милинах .... сводить движения вы будете очень долго .... а движения должны быть ... запись нельзя просто удалить ( как я понял вы на это намекаете )

гм.. а количество пачек в ячейке всегда 0 или 1? 4 пачки в одну ячейку не поместятся? Или количественный учет не нужен?

(15) нужно знать только какие там пачки

+ к(16) (15) количество пачек в ячейке произволльное ... по размещению там свои алгоритмы

Хорошо давайте по порядку: главный критерий - уникальность пары "номенклатура+ячейка"
Измерения:Номенклатура,Ячейка
Ресурс:Количество

Регистр сведений:
При попытке сделать "дубль" будете видеть ошибку: "Запись с такими ключевыми полями уже существует"

Регистр остатков:
Можно сделать кучу записей.
Да, можно вывернуться и при записи (проведении) документа делать проверку записей в регистре, но зачем?

Опять вопрос:
читаю (6)"движений по нему не может быть"
читаю (14)"а движения должны быть"
Так движения есть или нет?

(18)
данные
1) уникальность пачки
2) уникальность ячейки

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

движения есть (там просто не правильно выразился) имелось ввиду количество


движения возможные :
тип движения  |  ячейка   |  Пачка
----------------------------------
приход        |   я1      | пачк333
расход        |   я1      | пачк333

(16) как я понимаю, "пачка" это как "серия/партия", т.е. нужно выносить в измерение (получаются измерения ячейка + номенклатура + пачка) при таком раскладе. А считать не просто нолики и единички (есть пачка/нету пачки), а хотя бы вес/объем/сумму.. Иначе как-то все это притянуто за уши.

(20) что-то наподобие ... я бы правда назвал это неделимой упаковкой  больше т.е. она не делима... и соотвественно она ОДНА

А пачка какого типа значения?

(22) спавочникСсылка

(22) Справочник

+(24) и уже в ней содержится номенклатура кстати  и еще куча данных

недели ячеистых складов на мисте

(26) всмысле ?
да у нас все это используется... и пачки дробятся...  но есть ответхранение с такой схемой...

Пачка используется однократноили многократно?

(19) на какой вопрос ты хочешь ответить?
1) в какой ячейке лежит "пачка"?
- тогда это РС, причем ячейка - ресурс. Если периодический - то с сохранением всей истории перемещений.
2) какие "пачки" лежат в ячейке (да на произвольную дату)?
- тут ближе, конечно, РН.. Но считать хочется явно не "единички" (есть/нету), а что-то полезное. Иначе смысл вообще в вопросе? Что дальше делать с этой информацией в таком разрезе?

Вообщем...Открываем УПП.
Смотрим справочник МестаХранения и регистр сведений МестаХраненияНоменклатуры.
"Плясать" надо именно от той печки.

(25) а, например, в РС Контактная информация (когда он еще был РС) тоже два измерения: "тип" и "вид".
Хотя по виду "мобильный телефон" всегда можно однозначно определить тип "телефон". Вот ведь "избыточность" какая..

(28) однократно ... когда окончательно выйдет со склада.... но могут быть перемещения пачек  между ячейками.
(29) на тот что в шапке
1) переодика не подойдет ... так как может быть движение между ячейкмаи внутри одного дня
2) да да именно какие пачки есть )) просто есть .... а не количество в них веса... количество веса я беру из самого реквизита в справочнике...

объсню почему нельзя использовать количество... есть источник (внешний по XML) этих пачек  и я их гружу оттуда ....  а вдруг количество поменяется ? ))

(25) знаю но меня не напрягает JOIN в запросах

(33) к (31)

на регистре накопления считались штатные единицы в зарплате. Хотя там конечно учет ведется с количесвами больше чем булево да/нет, в любом случае ты не впишешь ссылку в ресурс накопления. Как минимум, придется рисовать измерение и ресуср 0/1.

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

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

(36) я образно имелл ввиду а не конкретные сумирование и тп.

(37) ну так если в ячейку может поместиться больше чем одна пачка, то вот и нужно считать их количество в каждой ячейке, соответственно, по ссылкам на справочник пачек

(37) ну в (19) же написано:

"в одной ячейки может быть сколько угодно пачек"

как будет определяться Итог по ресурсу: остатки, обороты и т.п. ?

(33) дело не только в лишнем соединении, но больше в индексах и возможности наложить дополнительный отбор на уровне виртуальной таблицы.

(32) Периодика бывает до секунды.. А если даже этого мало - можно доп. измерение внести, и это все равно будет "правильнее" РН, если хочется получить именно историю перемещений конкретной пачки.

По вопросу из шапки: "КАК создать регистр накопления (остатки)  ресурсом которого должен явится ссылка ( справочник)"
ответ однозначный: никак, это технически невозможно. Ресурс РН - только численного типа. Пересматривай структуру данных.

А про динамическое изменение веса - эт зачетно. Клали в ячейку, которая выдерживает вес 10кг, а потом хопа - стало 150кг. И ничего что все расчеты по размещению, которые проводились для пачки 10кг, стали сразу неактуальными.

ИМХО, задача поставлена некорректно. Сами по себе знания "что лежит в этой конкретной ячейке" бесполезны. Может быть интересно: сколько весит(стоит) товар в ячейке / сколько в ячейке осталось места / в каких ячейках лежала эта номенклатура(пачка) / в каких ячейках лежат другие пачки этой номенклатуры..

Если ну совсем никак - считай "единички", озарение придет позже..