Если мне память не изменяет, через этот реквизит как раз тч свяываются между собой разных доков. Там еще есть КлючСвязи - это уже вторая фигня для связи подчиненной ТЧ, и как раз таки она заполняется при записи, т.к. сам понимаешь - в подчиненные тч можно и так понапулять строк. Но там есть нюанс - там максимум берется от числа. И если ты очистишь источник-тч, и начнешь заново ее как-то заполнять, у тебя ключ связи тоже начнется новый. Поэтому по ключу связи более работа такая интерактивная - там все чухается - изменение товара, удаление строки, диагностика по количеству и т.д.

Cвязь с другими доками (например, строка заказа и строка реализации) через числовой КодСтроки, это помню что было всегда.
А вот щас увидел прям УИДный идентификатор, он для связывания не используется.

Одно из мест использований нашел - регистр сведений "СуммыДокументовВВалютеРегл", где этот УИД строки ТЧ - единственное измерение.
Т.е. у ребяток задел на то, что по этому УИДу строки однозначно можно выйти на ТЧ и сам документ.

точно. это связь регистра со строкой тч :)

Навскидку придумал три довода, почему нельзя было обойтись "по-старинке" составным ключом "УИД объекта + НомерСтроки", который гарантированно уникален в пределах инфобазы (в отличие от этого нового реквизита):
- этот новый ИД не меняется от перестановки строк ТЧ
- простое связывание со строкой ТЧ в запросах
- если разные типы документов имеют одинаковый УИД (что норма в обменах при конвертации "один ко многим"), то составной ключ "УИД объекта + номер строки" уже не подходит, надо в него в идеале мутить еще и тип объекта

почитал, посмотрел документацию, похоже это прекрасный продукт какой перекрывает почти все потребности.
но он требует покупки КИП, даже чтоб посмотреть попробовать. Так что Ансибл нужен.

Третий вариант не понял. Если один ко многим - то совпадет и УИД объекта и уникальный идентификатор строки у разных типов

Дождись тогда Magic Updater в Opensource - то же самое будет

Ансибл не нужен - оно для другого предназначается... интересно, кто рассказал?....

Тот кто рассказал про ансибль не рассказал к примеру про Salt stack? :))) И не пояснил для чего они применяются? :)))

Ансибль нужен для того чтобы инфраструктуру вести как код, хранить в гите состояния, автоматически обновлять (провидить инфраструктуру к состоянию, описанному в плейбуке).
Отличие ансибля от солт стека основное идеалогическое в режиме получения заданий, ансибль требует координатор и не требует раннеры, он работает в режиме пуш, солт стек требует раннеры и работает в режиме пул.
Мэджик апдейтер хранит состояния в гите? Приводит к ним инфраструтктуру? Или просто распределенные команды выполняет.
Если нужно массово все обновить то это одна задача, если нужно версионировать и понимать как менялась инфраструктура с возможностью в любой момент откатититься на любое изменение - это другая задача.

Человеку нужно тестовые базы на компы разработчиков накатывать

Какой там ансибль

Я думаю чтоь тестовые базы накатывать ансибль не нужен)

MU делали для pull - чтобы не держать всегда открытые дырки... salt более современен и более правилен... ИМХО конечно

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

Но это всё в любом случае больше к теме Iaas

А ЦА и MU решают несколько другие задачи

Идемпотентность

неее, не про то совсем.