Есть конкретная задача - вести учёт оборудования на рабочих местах, по сути ОС.
Выбрали решение Регистр сведений с 2мя измерениями - РабочееМесто и ОС.
Периодический.

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

Или вообще решение не то (тогда направьте в другую сторону) или непонятно как сделать именно "удаление" записи соответствия РабМесто+ОС на Период.

а чо не регистрНакопления?

накапливать особо нечего, каждое ОС - уникально (инв. и серийный номер)
Разве что писать  +1  и -1
Если не получится РегСведений - то конечно накопление сделаем

(2) ну сделайте вообще без регистра, какой-нибудь реквизит в справочнике ОС меняйте и всё

(3)+ или таб часть с историей

не очень подходит, есть подзадачи, типа "Сотрудники <-> Рабочие места"
Поэтому хотелось бы единообразно, регистром.

"чтобы итоговая таблица СрезПоследних была полегче" при наличии там записей не получится

(5) Заведите рабочее место "Корзина"

(6) т.е. получается, что из РегистраСведений периодического удалить некую запись соответствия из СрезаПоследних - невозможно, так?

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

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

(10) Миллион, не миллион, а архитектуру продумывать надо заранее.
Сам принцип пытаюсь понять.

(9) Так работаем то на свежих релизах.
Пытаемся выбрать именно "правильное решение", задача то обычная, может есть какие рекомендации - как именно хранить подобные данные.

(11) Чтобы продумать архитектуру, надо знать процесс во всех точках на трех уровнях: ввод данных, их изменение и их получение

(12) Документом вводят 2 вида комплектации - "Рабочее место + ОС" или "Сотрудник + Рабочее место"
Документом перемещают, 2 вида операции - ОС на другое рабочее место, либо сотрудника на другое рабочее место, либо отмечают выбытие ОС, увольнение сотрудника, "закрытие" рабочего места.
Получение - это отчёты, об истории движения ОС, либо о сотруднике - где сейчас работает/ ранее работал и какие ОС на этом рабочем месте.

Остаточный регистр накопления тогда: ввод рабочего места в плюс, выбытие / закрытие - в минус, перемещение - плюс-минус

Недостаток: со сверткой регистра потеряется история

(15) А вы не сворачивайте.

(11) так выключите итоги тогда

(+7) да.... или признак "Выбыл (Списан)"

(17) Итоги регистра сведений где выключаются? Вы про СрезПоследних ?

(19) в конфигураторе
а ещё вот это неплохо почитать
https://its.1c.ru/db/v8std#content:708:hdoc

(20) Спасибо за информацию.

Но нам как раз НУЖЕН СрезПоследних, чтобы быстро определять "Кто где сидит и каким компом пользуется", по при этом мы не хотим перегружать РегСведений лишними записями в СрезПоследних.

(21) Ужас какой.
А нас потом на партнерке за такие решения и не слушают.

По методологии 1С, ну по краней мере что нам там втирают Ваша задача решается 2 РС.
1) История ОС. Измерения РабочееМесто и ОС Периодический или нет, на вкус
2) Текущиее мето ОС Измерение ОС Ресурс - Рабочее место, дата ввода
Это 1 с детка.

(0) Связь Один (Рабочее место) ко Многим (ОС)

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

(23) Ну соответственно если в п1) регистр непериодитеский - то надо в ресурс запихать дату. Но скорее всего периодичность тут уже не нужна. И в ресурс же надо записать что то ТипДвиженияОС.
Оба регистра - подчиненные регистратору.

(23) (25) Слишком сложно когда можно проще (24)

(21)
СрезПоследних у вас будет в любом случае;
Лишние" записи" только у вас в голове, для РС они совсем не лишние;
одна запись на каждый выбывший объект в таблице итогов - такая "перегрузка" даже обсуждения этого не стоит

(24) Не, канонично 2 регистра.
Один историю
2ой - оперативное состояние.
Это более правильно

(28) Зачем когда достаточно одного регистра и для истории и для состояния?

(29) При большом количестве ОС и Рабочих мест - потенциальная опасность

(30) В плане производительности.
Если хранить срез последних расчитанным - долгая запись.
Если вычислять, особенно не с детализацией конкреноеОС\конкретное рабочее место, тоже опасность

(31) А так будут и волки сыты и овцы целы.
Притом гарантируб, там кучу всяких еще служебных полей, которые в задаче не обозначены, но 100% будут

(31) Срез последних лучше банально реквизитом в справочнике у ОС хранить, куда текущее рабочее место записано ))

(33) Вот смотри.
Перемещение ОС - документ.
Документом меняешь Рабочее место -> меняешь реквизит справочника.
А потом берешь и отменяешь проведение документа.
Что будет?
1) Говня, когда данные не совпадают с реальными учетными.
2) Много кода, что бы это предотвратить
+ Постоянное дергание справочникОбъект.

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

(34) При отмене берем из РС предыдущее место

Короче я согласен что мало данных чтобы решить как правильно.

Но чем больше разных РС тем больше проблем с их рассинхронизацией, что и происходит постоянно в последних типовых типа УТ11, КА2 и ERP, особенно с работой задним числом и интеркампани.

(36) и получаем Справочник объект меняем в нем реквизит и записываем.
+ Юзер пошел прошаренный и поиск и замену ссылок умеет.

Правильно ли я понимаю следующие моменты:
1. Одно ОС может быть только на одном рабочем месте в каждый момент времени.
2. На одном рабочем месте может быть несколько ОС в каждый момент времени.

В этом случае, подходит обычный РегистрСведений
ОС - Измерение
РабочееМесто - ресурс

При окончательном выбытии, в рабочее место пишется ПустаяСсылка.
Ещё как вариант дополнительный булевый ресурс "НетВНаличии". В момент выбытия, делается запись по ОС и последнему рабочему месту с НетВНаличии = Истина. При снятии среза последний по наличию ОС устанавливается фильтр "НетВНаличии = Ложь"

(37) Дело не в РС, а в том, что в любой реализации надо предусмотреть некорректные сценарии.
Разработчики типовых в этом плане меня разочаровывают, я 10 часов потратил на поиск ошибки в новой системе взаимозачетов.
При проведении почему то захотелось в закрытый период залезть, хотя в этом не было необходимости, всю голову сломал, но нашел таки. Решение было ещё более неочевидным.

(39) зачем хранить состояние выбытого ОС?

(41) Не понял вопрос. Мы храним только историю перемещений ОС и его выбытия.

(42) ну по канонам надо хранить историю и оперативное состояние, но как показала практика - делать это надо в отдельных сущностях.

(43) потому что при расширении функционала - это становится головной болью.

(39)(42) После выбытия нам не нужна (!) запись об ОС в "остатках", в СрезеПоследних.
Вот эту проблему при использовании периодического РС не удаётся решить.

(43) Если состояний больше чем 2 (в наличии/не в наличии), то я согласен.
Для данной задачи, в постановке ТС для отслеживния местонахождения ОС в наличии - достаточно одного регистра.

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

(45) Я и указал, для того чтобы не получать эту запись, надо наложить соответствующий фильтр "НетВНаличии = Ложь" или "НЕ РабочееМесто  = Значение(Справочник.РабочиеМеста.ПустаяСсылка)"
При выбытии ОС при выборе любого метода реализации задачи, это самое выбытие нужно где-то регистрировать.

(48) Выбытие хранится в истории.

(45) А после выбытия ОС вы элементы справочника удаляете или может быть используете их "для экономии" под вновь поступившие ОС ? :)

(50) А ты я смотрю прошаренный)

(45) всего не читал, но в (10) сказали правильное решение
срез последних с условием ГДЕ Выбыл = Ложь даст нужный результат, выбывшее ОС не попадет

(21)Вы хотите странного. Либо у вас есть история и есть записи, либо после выбытия чистите все записи по этому ОС и лишаетесь истории. Сколько их там у вас, что вы так боитесь "перегрузки" регистра?

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

Я так и не понял - почему остаточный РН отвергли?

Хотя, по большому счету, даже 100 тыс. ОС - это фигня для СрезаПоследних.

Интересно а временного перемещения или передачи сотруднику нет, так чтобы по окончании само назад вставало. Если есть, то ещё бы и аналог интервального регистра из ЗУП не помешало бы.

(57) А чем не устраивает вариант с реквизитом состояние.
И временное перемещение легко будет сделать, и запрос с срезом можно с условием по нему сделать.
Или вообще ОС  в ресурсы переместить. (если есть возможность конечно)
И тогда выбытие легко делать.
типа Ноутбук  - раб место 1 01.07
Ноутбук - раб место 2 10.07
Срез будет показывать, что ноутбук на раб месте 2 чистится, а срез до 10 на раб месте 1.
У нас например примерно так и сделано, только еще в ресурсы запихнули МОЛ и Помещение. Работает.

Решили всё таки делать через РегистрНакопления (РН, 2 штуки).
Задача не стояла в формате "не использовать статус", использовать его без проблем.

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

(59)
мде, тут столько советов неплохих дали, а сделали всё равно херню.
рано вам еще, похоже, архитектурой заниматься

(0) Решение в (23) самое нормальное. Оно избыточно для простых случаев, но обладает запасом по масштабируемости. Если не хотите дополнительную таблицу "СрезПоследних", то не делайте РС периодическим. Виртуальная таблица "СрезПоследних" реализуется обычным запросом (http://catalog.mista.ru/public/527518/#Как_работает_СрезПоследних_в_запросе).

(59) С одной стороны, нет особого смысла в регистре накопления, у которого в ресурсе "Количество" всегда будет 1.
Но, с  другой стороны, всегда есть что-то типа оборотно-сальдовой ведомости, которую можно вертеть в различных изменениях и периодичности, без особых затрат на разработку отчётности.
Осталось непонятным, зачем 2 штуки РН, но вам, очевидно, виднее.

(62) ранее в итерации решения было "Всё-в-одном", сейчас решили разделить при переделке.
функциональное разделение:
1) Петров может сидеть за столом N1 или N2 (какой свободен)
2) На столе N1 стоит телефон 111 и комп с IP 111, на столе N2 соответственно другое оборудование

Звонит Петров. Служба поддержки видит номер 111, слышит фамилию Петров. 1С:ServiceDesk по фамилии "Петров" находит "111" и "222", а специалист выбирает и подключается к компу "111" для решения вопросов.