Маркировка обуви. Смотрю, как сделано в типовых... Наворочено там, конечно, ужас, но это другой вопрос.
Смысл такой. Каждой паре обуви присваивается уникальный штрихкод. И надо постоянно следить за его нахождением (склад) и статусом (выведен из оборота).

Хочется сделать регистр накопления, но статус в нём хранить не получится. Отсюда вывод - делаем РС. Норм?

В УТ11 так и сделано. Только не пойму, почему регистр сведений независимый, но с измерением "ДокументОснование" (тот же регистратор, если я правильно понял).

Отсюда ещё один вопрос.
Два измерения: ДокументРегистратор, Штрихкод
Ресурс - Статус

Как получить последний статус по штрихкоду?

Так он периодический должен быть. Оттого и РС.

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

По РС можно выбирать из среза последних на актуальную дату.

При таком устройстве регистра ты по простому не получишь последний статус,т.к. срез последних тебе вернет все записи по измерениям. Это не регистр накопления.
Зачем ДокументРегистратор в измерения? Он точно там нужен? Может его в ресурсы засунуть или вообще в реквизиты?

(2) Вот я таким вопросом из задался.
Подумал, может я чего не знаю, и можно как-то по-модному делать срез по одном измерением.
Наверн, сделаю подчиненный регистратору тогда, с одним измерением.

(1) Разумеется, он периодический)

В общем, спасиб, всё-таки лыжи не ехали)
Если никто ничего лучше не предложит, буду делать РС с одним измерением

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

Измерений я бы составил два Номенклатура и Штрихкод. И вроде документом основание является тот документ, от которого ШК появился. Он затем повторяется как и Номенклатура и позволит в любом срезе последних увидеть, например, что это было со ссылкой на конкретное Поступление-партию по конкретной Номенклатура.

Ну а дальше можно и Ссылку на документ установивший статус.

Если поставить только ШК, то где-то будет еще храниться отдельно связь, а к кому этот ШК записали?

(4) ШК - Элемент справочник ШтрихкодыУпаковокТовара (Сделал по типу УТ11)
Там реквизит Номенклатура. Вроде логично.

А делать одно измерение для документа основание, которое потом будет повторятся.. Ну хз. Очень легко в ногу себе выстрелить. Проще ещё один РС завести, но смысла пока особого не вижу.

(5) ДокОснование - это не измерение, а ресурс.
И ресурсов можно сделать несколько, чтоб не бегать по множеству таблиц с одной и той же парой Номенклатура+ШК

А как лазить каждый раз через реквизит ШК, если в этом справочнике будут овердофига элементов?

Периодический
Измерения
    Номенклатура
    ШК
Ресурсы
    Статус
Реквизиты
    ДокОснованиеШК
    ДокОснованиеСтатуса

з.ы. в РС между реквизитами и ресурсами разница практически нет - только визуально показывает, что у Ресурса как бы приоритет у информации выше.

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

(6) >А как лазить каждый раз через реквизит ШК, если в этом справочнике будут овердофига элементов?
Не понял. Обычное левое соединение?

(7) Ну и пусть висят, пользователь же не будет с ними работать.
Какая разница, будут они гроздью висеть в РС или в дополнительном справочнике?

Не пойму, зачем выносить номенклатуру в измерение, если она есть внутри ШК

Там же один раз вяжется всё это дело с номенклатурой, и дальше отвязывать не нужно будет

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

(9) Так точка влияет на производительность только в случае составных типов и кривых рук :) Я про выбор не через ВЫРАЗИТЬ)
А так индекс накинуть на реквизит и тот же РС только в профиль

(2) "по простому не получишь последний статус,т.к. срез последних тебе вернет все записи по измерениям" // Ну так по периоду-то можно отсортировать же

Давайте я вам все расскажу:

Смотрите, есть 4 разных пути:
1) Полностью независимый регистр сведений, прямо как типовой 1С АкцизныеМаркиЕГАИС, но в котором есть измерение Документ, стоящее вторым, следом за измерением Марка, чтобы можно было отменять движения. Это самый здравый путь в плане быстродействия, но он потребует компетенций от разработчиков.
2) РС, подчиненный регистратору, непериодический. Получить текущий статус марки мы можем лишь залезая ЛевымСоединением в регистратор, чтобы получить дату документа и отсортировать по ней, либо... денормализовав данные и вынеся Дату документа в Измерение, придя к
3) Варианту - периодическому регистру сведений с периодичностью Секунда. Однако, нам не важна дата, когда сменился статус марки, нам важен сам статус, поэтому нам все же лучше вариант:
4) периодическому регистру сведений с периодичностью ПоПозицииРегистратора.

(11) Если номенклатура одна, то всё ок. Если массив - беда. Вложенный запрос, группировка и т.д.

(12) Почему первый вариант самый здравый? В нём статус марки, который лежит в ресурсе, можно будет получить только через гланды. Зачем отказывать от СрезаПоследних?

(13) Все лежит в Измерениях

(13) Пока СрезПоследних формируется платформой через ВложенныйПодзапрос, а не через отдельную ВТ - он опасен

(14) Первое правило оптимизации - не оптимизируй)
Немного смысла в этом есть, согласен

(15) Можно пример?

(16) Большой регистр с несколькими измерениями - боль

(17) Несколько измерений это сколько? Три уже много?
Странно, что не придумали ещё что-то подобного, как и у регистров накопления.

Тут я вроде наоборот предлагаю только одно оставить)

Я сделал так для фармы:
1) РС ИсторияУпаковок - подчиненный регистратору, по позиции регистратора (но срезы использовать не планирую).
Измерение: Упаковка (справочник)
Ресурсы: Состояние, МестоДеятельности
Документ-регистратор фиксирует изменения состояния упаковки в системе маркировки.

2) В событии ПриЗаписи этого регистра анализирую всю историю по упаковке и пишу последние актуальные данные (МестоДеятельности, Статус) в реквизит справочника Упаковок.

(17) С чего бы?

(19) Мои поздравления. Вы свелосипедили ИтогиСрезаПоследних :-)

(18) >Странно, что не придумали ещё что-то подобного, как и у регистров накопления.
Ладно, я понял. Это частный случай.

(19) Зачем писать в справочник, если можно использовать срез?

(16) Потому что почти каждый соединяется со срезом последних "на лету", а не через предварительное помещение среза в ВТ.
А время выполнения соединения с вложенным запросом слишком волатильно, в отличие от ВТ.

срез последних не нужно делать
нужно делать коррелированый подзапрос соединение

(24) Сколько человек из числа 1Сников ты встречал, кто знает, что это такое?

я и сам кстати до недавнего времени не знал что 1с так умеет

(16)

ВЫБРАТЬ
    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена,
    ЦеныНоменклатурыСрезПоследних.ВидЦены КАК ВидЦены
ПОМЕСТИТЬ ВременнаяТаблица
ИЗ
    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дат, Номенклатура = &Ном) КАК ЦеныНоменклатурыСрезПоследних

http://prntscr.com/q9rtli

(26) Я бы отнес это к грязным хакам. Конструктор такое не сумеет сделать, но сумеет переварить.

(21) Практически да.
Только анализ истории более хитрый и значения - сразу в справочник.

(28)  в конструкторе и имеющие нельзя написать и что теперь?

(30) Можно.

(24) Что это? Пример?

(31) как? от руки в конструкторе писать не предлагать

|ИЗ
        |    Документ.УпаковочныйЛист.АкцизныеМарки КАК УпаковочныйЛистАкцизныеМарки
        |        ЛЕВОЕ СОЕДИНЕНИЕ Документ.УпаковочныйЛист.Товары КАК Товары
        |        ПО (Товары.ИдентификаторСтроки = УпаковочныйЛистАкцизныеМарки.ИдентификаторСтроки)
        |            И (Товары.Ссылка = УпаковочныйЛистАкцизныеМарки.Ссылка)
        |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.алкАкцизныеМаркиЕГАИС КАК АкцизныеМаркиЕГАИС
        |        ПО (АкцизныеМаркиЕГАИС.АкцизнаяМаркаЕГАИС = УпаковочныйЛистАкцизныеМарки.АкцизнаяМарка)
        |            И (АкцизныеМаркиЕГАИС.Период В
        |                (ВЫБРАТЬ ПЕРВЫЕ 1
        |                    Рег.Период
        |                ИЗ
        |                    РегистрСведений.алкАкцизныеМаркиЕГАИС КАК Рег
        |                ГДЕ
        |                    Рег.АкцизнаяМаркаЕГАИС = УпаковочныйЛистАкцизныеМарки.АкцизнаяМарка
        |                    И Рег.Период < &Дата
        |                УПОРЯДОЧИТЬ ПО
        |                    Рег.Период УБЫВ))

(34) Ахахах. КТ-шечка. С их офигенным помарочным.

(0) Да ладно, срез последних без ВТ - почти типовой запрос. ЗУП примерно из таких запросов на 50% и состоит, по крайней мере старый, а в новом, суть та же, но красивая реализация.

(33) Ладно, ты победил. В Условии, после мышечного добавления поля, нужно дописать агреггирующую функцию.

(27) Посмотрю. Спасибо
Что за прога так умеет?

(34) Ужс. Следующие программисты офигеют
Было бы интересно посмотреть на сравнение производительности
Если порядок тот же, то лучше отдать предпочтение читабельному запросу

(38)
1) MS SQL Profiler
2) Все нормально с производительностью, мы это пользуем в дин списках, для аггрегации подчиненной таблицы.

(27) Смысл в том, что 1 лишняя выборка? Или что-то страшнее?

(35) у нас от них только названия остались

(40) Забейте.

(41) Что за фирма то?

(40) тогда делай рег сведений с итогами и юзай типовой функционал

(43) это коммерческая информация

(42) По скрину запрос сложно читать
Уже качаю SSMS - интересно разобраться

(45) Скучно с вами, Анатолий Печкин.

(34) Смысл ясен. Где использовать - не очень =\