Задача: нам приходит от поставщика N однотипных объектов (ну, не пригоршня изюминок - схавал и пофигу на их индивидуальные особенности; а пачка компакт-дисков с фильмом, например, или велики одной модели:)). После чего нам каждой единице надо присвоить Инв№ (и по нему потом отслеживать ее судьбу - износ, утрату и т.п.).

Я хочу сделать так (перенес эту идеологию из Аксеса - соответственно, терзаюсь смутными сомнениями, что в 1с8 этот подход оптимален)):

в документе Оприходование две ТЧ - ОбъектыПроката (они-то нам и поступают, документом Поступление) и Инвентаризация. А т.к. Оприходование создается на основании документа Поступление - то первая ТЧ оприходования заполняется из ТЧ поступления (они идентичны - просто свалка однотипных объектов). А вот вторая ТЧ (Инвентаризация) содержит ссылку на Справочник.ИнвентаризацияОбъектовПроката(а этот справочник, ессно, подчинен справочнику ОбъектыПроката);  причем, эта ТЧ заполняется новыми Инв№, генерируемыми для каждого объекта из первой ТЧ (столько штук, сколько поступило).

Т.е. в обработке заполнения в модуле Оприходования что-то вроде:

Процедура ОбработкаЗаполнения(ДанныеЗаполнения, СтандартнаяОбработка)
    Если ТипЗнч(ДанныеЗаполнения) = Тип("ДокументСсылка.ПоступлениеОбъектаПроката") Тогда
        Для Каждого ТекСтрокаПереченьОбъектовПроката Из ДанныеЗаполнения.ПереченьОбъектовПроката Цикл
            НоваяСтрока = ПереченьОбъектовПроката.Добавить();
            НоваяСтрока.ОбъектПроката = ТекСтрокаПереченьОбъектовПроката.ОбъектПроката;
            //...и другие рекивизиты ОбъектаПроката
            Для Счетчик = 1 По ТекСтрокаПереченьОбъектовПроката.Количество Цикл
                
                //создаем инвентарную единицу объекта проката - и вот ее-то качество и записываем в регистр
                НовыйИнвНомерОбъект = Справочники.ИнвентаризацияОбъектовПроката.СоздатьЭлемент();
                НовыйИнвНомерОбъект.Наименование = точтокактосгенерируем;
                НовыйИнвНомерОбъект.Владелец = ТекСтрокаПереченьОбъектовПроката.ОбъектПроката.Ссылка;
                НовыйИнвНомерОбъект.Записать();
                
                //добавляем запись во вторую ТЧ
                НовыйИнвНомер = Инвентаризация.Добавить();
                НовыйИнвНомер.ИнвентарныйНомер = НовыйИнвНомерОбъект.Ссылка;                
                НовыйИнвНомер.Качество = Перечисления.Качество.ОтличноеКачество;
                //...и другие рекивизиты каждой единицы
            КонецЦикла;
        КонецЦикла;
    КонецЕсли;
КонецПроцедуры

...поругайте-похвалите?...

>...поругайте-похвалите?...
это все куйня. Переделывай.

Я не понял проблемы. Надо при оприходовании генерить серийные номера?

>содержит ссылку на Справочник.ИнвентаризацияОбъектовПроката(а этот справочник, ессно, подчинен справочнику ОбъектыПроката)

прекрати плодить сущности без необходимости

(2) да, но если мне надо для каждого экземпляра (Инв№) в периодическом регистре сведений хранить некую инфу (Качество, например) - без сущности тут не обойтись
(1) с генерацией как-нибудь разберусь - вопрос в архитектуре. Мож, кто-то аргументированно объяснить, что в одинесине  все делают не так и направит на путь истинный))

(3) учет по сериям использовать не предлагать?

(0) А при чем тут, собственно, инвентаризация?
Генеришь серии и крепишь к номенклатуре.

(4) (5) мм...конфа с нуля ваяется - лепить партионный учет не предполагалось. Об ём речь?

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

(7) (5) (4) О! О! я чувствовал! "...я всегда чувствую..." (с)
спасибозанаводку!
...В типовой бух 3.0 эта плюшка есть (подглядеть)??

(8) в типовой ут 10.3 точно есть

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

(10) ага...тем более, похоже, серии тут не очень подойдут. По условию задачи, нужно про КАЖДЫЙ экземпляр знать, сколько раз его сдавали (износ посчитать, списать и т.п.).
А в задачах на Спеца как раз другой случай - там при поступлении редких товаров КАЖДЫЙ товар занимает СВОЮ отдельную строку, с Количеством равным 1. У меня как раз прикол в том, что принимается пачка, оприходуется поштучно!
Что ж, тем лучше, интереснее...)

ТС тока не говори что хочешь на каждый цветочек свой ШК налепить...

(12) а придется

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

(12)+ суть в чем если номенклатура чем то отличается... то это разная номенклатура

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

простейшая надежная реализация партий в типовых это через разные номенклатуры входящие в одну группу "лисапеды"

на Групповой учёт ОС смахивает

и при вводе в эксплуатацию каждая единица идёт отдельным элементом справочника

(11) у тебя товар - это номенклатура
экземпляр - номенклатура + серийник (какой-то ШК на нем)

и в зависимости от глубины разреза аналитики у тебя 5 велосипедов или 1+1+1+1+1 велосипед

(0) Че-то похожее сейчас ваяю. Делаю как в (18).
Посерийный учет в УТ 11 только не смотри, там ад и жесть)

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

(20) ДЫК!!! самый прикол, что ТЗ (тестовое, для вступления во франч) ведет речь как раз о регистрах накопления - при поступлении. А потом, этак невинно, с легкостью, заявляет - "а в документе оприходование присваиваем инв.№". А еще потом - в регистрах сведений сохраните-ка нам Качество КАЖДОГО объекта проката (вычисляется по количеству сдач его в прокат и предельно допустимому кол-ву сдач). Т.е. в самом ТЗ - глубокое противоречие.
Но я, желая доказать свою немеряную круть, пытаюсь (с вашей бесценной помощью, камрадес!) выкрутиться...
(19) ладно, не буду тратить время))
(16) ага: просто ли добавлять признак учета (+пр.уч.субконто) в план счетов?
))

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

но плюс - не надо городить доп. сущности и перекладывать туда-сюда отслеживая явно ее жизненный цикл

зы

сбоку можно присобачить характеристики и потом выгребать либо велосипеды/двухколесные либо велосипед №534353/красного цвета

(22)
Да. Я прям так и делаю. Серии и характеристики. Серия навечно прикрепляется к объекту.
В чем минус такого подхода?

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

>А еще потом - в регистрах сведений сохраните-ка нам Качество КАЖДОГО объекта проката (вычисляется по количеству сдач его в прокат и предельно допустимому кол-ву сдач)

неформализуемая величина по сути... накой хрен ее вычислять

я могу отдать диск новый и его перецарапает или сломает кривой привод. а могу отдать 10 раз и он как новый

(23) Я, собственно, спрашиваю потому что в УТ 11 этого функционала как раз нет.

(25) согласен, но задача условная. Формализация такая, по ТЗ:
"если количество передач объекта составляет менее 51% от максимально допустимого количества передач – качество отличное, если более 51% и менее 80% -- качество среднее, если более 80% -- качество плохое"
(18) так, в принципе, я в (0) и делаю, не? Серийник == Инв.№. Насчет характеристик покумекаю - я с ними только по книжке Радченко общался...

Вот понять не могу чем не подходит в справочник "Номенклатура" засунуть реквизит "Инвентарный номер"?

Где сказано что нужно будет аналитику по видам лисапедов делать в этой учебной задаче?

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

(28) >а в документе оприходование присваиваем инв.№

(30) и что?

(31)+ списываем 5 лисапед, приходуем 5 раз по лисапед 1, лисапед2 и т.д.

(32) т.е. обычный алгоритм разукомплектации

до этого было пофиг какой номер у лисапедов они все одинаковые поэтому одной строкой

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

(33) или не выделываться и сразу поштучно приходовать

но я бы сделал (33) и еще ссылку на "родительскую" номенклатуру оставил в виде реквизита или родителя в иерархическом виде справочника

(33) О!...надо подумать
(34) ПРИХОДОВАТЬ и надо поштучно. Но поступает - пачка, Количество >=1 (ложиться в регистр накопления)

(32) комплектация в обратную сторону? как вариант...

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

Товар1 1
Товар1 1

не проще написать
Товар1 2

?

(36) Ты - как всегда...
Мне не понятно: приходовать надо поштучно, но поступает пачка... Не по-нят-но.
Если приходовать поштучно - так и приходуйте + сразу шлепайте инвентарный.

(39)+ или тогда уже писать разную
Товар1 1
Товар2 1

(39) как бы это "учебная задача" поэтому "на ваше усмотрение"

(40) Это как-то "не комильфо")))

(41) Надо сразу стараться делать хорошо, ибо хреново - оно и само получится)

(43) а это по определению невозможно, если нет полного ТЗ со всеми исключениями

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

(44)+ а если реально то можно прекрасно обойтись 2 разными справочниками совершенно друг с другом не связанными

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

какое решение оптимальнее хз

(45)+ т.е. надеюсь понятно что в (0) в прокат выдаются не велосипеды... а инвентарные номера...

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

(44) По моему опыту - не бывает "полных ТЗ" - это как сферический конь в вакууме.

Может вам повезло больше)

(38) а, ну да....стандартная разукомплектация из (33) не катит.
(39) именно! ПОСТУПАЕТ - пачка. А ПРИХОДУЕТСЯ (другой док, вводится на основании дока поступления) - штука из пачки, каждая...
(44)(47) я СИИИЛЬНО подозреваю, что составители задания сами не в курсе, что они сочинили......

И, самое главное, что вы учитываете не товар.
У вас то, что сдаётся в прокат - это основные средства и оно каждое должно учитываться отдельно.
Причём, насколько я помню, с этим проблем нет.
Просто нужно при получении товара (а приходит у вас действительно товар) перевести это всё в ОС.

(48)
Короче, я бы не плодил лишних приходных документов.
Берешь в документе поступления генеришь на все что поступило инвентарные номера. Документ при проведении делает движения по РН "ТоварыНаСкладах" с доп. измерением "Серия/Инв.номер". И далее эта парочка "Номенклатура-Серия" фигурирует во всех движениях документов исключительно совместно.

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

Озарение: вообще, в любом варианте, документ при проведении НЕ должен СОЗДАВАТЬ никакие объекты. Ибо при распроведении дока будет ой...
Походу, надо объяснить составителю ТЗ, что ему самому еще поучиться надо....
Причем, подчеркну, в самом ТЗ ни слова о СОЗДАНИИ инв.№ - там речь идет о ПРИСВОЕНИИ. Но при этом при поступлении упоминается Количество.
В общем, противоречивая постановочка!

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

(50) стоп...какой РН? если будет измерение "Инв.№", то объект - ОДИН, и нет других объектов, кроме него, с таким "Инв.№"!...

(54) И че? На склад-то он должен поступить. Хоть и один.

(49)(53) интересненько... причем и Товар, и ОС - это ведь справочники? Только, в отличие от моего подхода, не связанные "напрямую"?

(53) Кому можно? В (0) конфа нулевая, там понятия даже такого нет.

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

+(58) тем более, что все плюшки РН при серийнике-измерении сходят на нет.

короче, Torquader похоже дело говорит.
Думаю завести справочник "Видеопродукция" (ака "Товар") - туды все поступает от поставщика, кладется в РН. Клиент когда интересуется мультиком, посылает запрос туда же.

А при оприходовании - ОбъектПроката (ака ОС). Имеет инв.№ (шлепается при оприходовании), общается с РС (учет того самого "качества" и др. индивидуальных характеристик)

(56) см (45) это и есть ОС

(61) ага
только РС в качестве средства связи.... Надо покумекать - мож, все же лучше подчинение?

(62) а какая разница как "партии сущностей" связаны с "наименованиями видов сущностей"?

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

>Надо покумекать - мож, все же лучше подчинение?

зависит от мощности связи

подчинение - две таблицы -> 1 ко многим
РС  - это третья таблица -> многие ко многим (с учетом структуры измерений РС)

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

Т.е. один справочник "Номенклатура" оставляем и все

(65) я первый))

(66)+ в 1с можно сделать иерархию групп и "элементов" и не выделываться с доп реквизитом

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

(66) для простоты - да...

(68) группа лисапеды и от нее вниз элементы?

(71) да
но это только для "учебной задачи"

для реальной сделал бы аналогично ОС

(71) или, элемент "лисапеды" и его "детишки" - инвентарные номера?

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

Можно было бы вообще "ОбъектыПроката" организовать так: верхний уровень - фильм (и реквизиты "Год", "Студия" и т.п.), второй уровень - вид носителя ("компакт-диск", и пр.); а далее - элементы с инв. номерами.
Тогда в РН измерение ссылается на группу второго уровня, а в РС - на элемент справочника!

>у группы - одни реквизиты, у элемента - другие, не?

так и есть. что реквизит и там и там - это объявлять надо в свойствах

>Можно было бы вообще "ОбъектыПроката" организовать так: верхний уровень - фильм (и реквизиты "Год", "Студия" и т.п.), второй уровень - вид носителя ("компакт-диск", и пр.); а далее - элементы с инв. номерами.
Тогда в РН измерение ссылается на группу второго уровня, а в РС - на элемент справочника!

упорот штоле? годы студии и прочее надо совать в характеристики

они позволят ответить на вопрос отчета - сколько дисков 80-х с Джеки Чаном есть в наличии... а как это отковырять из иерархии? через %подобно%?

Если отвлечься от 1С и товаров, то:
- Есть классы объектов, у которых есть какие-то свойства. Вполне вероятно, что одни классы могут быть потомками других, причём есть вероятность множественного наследования.
Для чего это нужно - это будет нужно, если пользователи будут что-то искать по принципу подобия.

Далее, если конкретные объекты, которым присваиваются инвентарные номера. Причём, если это диски, то нужно сразу понимать, что в реальности возможны наборы, когда на одном диске есть несколько фильмов. Просто, в этом случае, два или более классов объектов будут ссылаться на один экземпляр, а нам это не нужно.
Для правильной реализации, в этом случае, вводится новый класс, который наследует свойства всех предыдущих, а уже экземпляры ссылаются на него - экземпляры всегда должны быть одного и только одного конкретного класса.

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

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

(78) Так при желании туда можно еще бухучет прикрутить, расчет зп ремонтников/продажников, CRM и т.п.)))

(79) как бы понятно что задача решается за 12 т.р. внедрением типовой БП

(80) Как раз внедрением БП и даже УТ исходная задача не решается. Допиливать придется.