Добрый день,
кто как думает - что предпочтительнее
Есть документ Накладная
Может создаваться на основании Заявки, а может на основании другой накладной - тогда это возвратная накладная
Что лучше
1) Сделать поле ДокументОснование составного типа (Заявка, Накладная)
2) Сделать 2 поля - Заявка, НакладнаяКВозврату
Вроде бы с учетом поиска по полю составного типа предпочтительнее второй вариант, тем более, насколько я понимаю, на размер базы это скажется незначительно.
Но тогда вопрос почему в типовых делают поле ДокументОснование составного типа?

потому что жизнь длинная и непредсказуемая, завтра надо будет вводить на основании РТУ, а после завтра введете еще свой документ основание, зачем городить кучу реквизитов?

потому что могут.
потом с этими составными полями есть нюанс при запросах, но это решаемо.

составной тип

(1) тогда получается, если ничего не меняется, то лучше первый вариант?

(2), (3) так а чем составной тип лучше?

(0) У тебя не коррелируется
"
с учетом поиска по полю составного типа
"
и второй вариант. Во втором варианте не составной тип

(6) перефразирую
"с учетом того, что я всегда могу однозначно определить по какому полю искать - по Заявке или Накладной, а поиск по составному полю в первом варианте требует больше ресурсов -
предпочтительнее второй вариант"
Так лучше?)

(5) да тем лучше, это одно поле.
смотрите, допустим вам нужно получить поле "номер" документа основания
в случае 1 вы напишете в запросе ДокОснование.Номер и платформа сама развернет это в 2 левых соединения с вашими типами документов.
в случае 2 вам самому придется писать чтото вроде
выбрать Естьnull(Заявка.Номер,НакладнаяКВозврату.Номер) как номер
результат будет 1 но телодвижений меньше
плюс масштабируемость на будущее
главное с ней не переборщить и не делать там там "ДокументССылка"

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

Пожалуй уточню свой вопрос
Приведите причины "за" составной тип)

(8) хороший пример - спасибо)

(9) не исключаю конечно такой возможности)

(0) Если исходить из чистой логики, то должно быть два отдельных поля:
- Заявка - заявка
- Накладная - накладная, по которой поступил возвращаемый товар.
У возвратной накладной будет заполнено оба поля - и Заявка, и Накладная.

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

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

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

Это я ответил на вопрос почему так делают в типовых. А как сделать у тебя, сам решай.

(15) в критерий отбора закинуть 2 поля - Заявка, НакладнаяКВозврату. тогда все попадет в структуру подчиненности документа.

(15) там можно в структуре подчиненности хоть 20 оснований задать, что-то вы не в теме.

(17) Хм... Когда я туда смотрел, было так. Возможно, это было давно.

(15) ерунду говоришь.