Не знаете, в чем прикол?
Есть 2 конфы, Бухгалтерия предприятия КОРП, редакция 2.0 (2.0.66.64) и Зарплата и управление персоналом КОРП, редакция 2.5 (2.5.137.2).
И та, и та переписанные немного.
Правила обмена в ЗУП нынче хранятся в обработке ВыгрузкаДанныхВБухгалтерскуюПрограмму, макет "ПравилаОбменаБП20".
Собственно, выгружаю их в xml, загружаю в "Конвертацию данных", (Загрузить правила в новую конвертацию данных).
А дальше - следите за руками)).
Если в качестве Приемника и Источника я выбираю предварительно  загруженные их файлов xml, выгруженных обработкой MD8.2 конфигурации (которые фактические метаданные конфы, со всеми изменениями и доработками) - то в созданной конвертации в ПКЗ у реквизитов типа Строка длинна задана например "Строка (Ф9)".
Вот так: https://a.radikal.ru/a34/1901/af/0c7b3a602a43.png

А если я в качестве Источника и Приемника выбираю типовые конфы, включенные в типовые правила ("Загрузить правила в новую конвертацию данных", Источник-Приемник галки "Создать новую", обработку MD8.2 вообще не используем, структуру метаданных не выгружаем/загружаем) - Источник и Приемник создаются, все нормально, но - у реквизитов типа Строка длинна "Строка (Неогр)"
Вот так:  https://c.radikal.ru/c16/1901/70/1838c9340f87.png

Очень интересно, это так задумано, или...?
Честно говоря, я даже не знала, что можно миновать этап "выгрузить метаданные"/"загрузить метаданные", грузанув сразу Правила для их дальнейшего редактирования, поэтому такое вижу впервые.

провались из правил в реквизиты конфигураций, или о чем ты?

ну теперь узнала .завтра узнаешь новое .

(1) пример: справочник "Организации", ПКЗ "Код". Первая картинка - тип Строка, длинна 9.
Вторая картинка - тип Строка, длинна Неограниченная.

И так у всех реквизитов Строкового  типа.

В реальности и в Источнике, и в Приемнике длинна реквизита Код = 9.

Почему оно так и "это баг, или фича"?

(2) так это так задумано? Или почему у всех строковых реквизитов длинна не перенеслась, не знаете?
Я даже как погуглить, понять не могу, как это назвать коротко))))

Если думать почему так задумано в 1с то времени на самообучение не хватит . ты делай .а потом с опытом поймешь почему оно так

(3) раз интересно провались в реквизиты конфигураций, посмотри алгоритмы приведения номеров. Поставь себе плюсик

(5) так вот оно в это все и упирается -я понять не могу, это так задумано логикой 1С, или я что-то сделала не так (хотя там вроде нечего сделать не так...)

(6) ничего не поняла...Куда провалиться, где? В Конвертации, или в самой Конфигурации? Как это сделать? Туплю(((.

(7) в конвертации сравни типы реквизитов в конфигурациях участниках. БП из типовых, автоматом созданную из правил, и БП выгруженную экспортом мд.

Потому что в правила тип свойства выгружается просто как Строка без уточнения длины:
<Источник Имя="Значение" Вид="Реквизит" Тип="Строка"/>
С числовыми значениями кстати тоже самое просто "Число" и тип будет Число (0.0)
По большому счету конвертации все равно на точность типа, преобразование/обрезка произойдут при загрузке, а уже передать правильное значение это прикладной смысл решения ваших правил.

(9) то есть это так задумано, выходит.
смысл в том, что когда не указана длина в ПКС - недоступна галка "приводить к длине приемника" и приходится прописывать ручками в ПКЗ.

Спс, я поняла.

Скорее теоретическое любопытство: я правильно понимаю, что если алгоритм одинаковый, то вместо прописывания в ПКС каждого объекта, можно использовать "После загрузки" глобального обработчика КД, и уже там менять значение свойства? Почему все мануалы по теме для изменения значений свойств объекта (например, код, номер) отсылают в ПКС?  
Я единственным минусом использования глобального обработчика вместо ПКС каждого из объектов вижу сложность (если не невозможность) обращения к значениям свойств объекта в случае, если результат зависит от конкретных значений каждого из объектов.
А так вроде бы огромный плюс - не надо прописывать ПКС для каждого из кучи, при обновление вспоминать, что-где правил... В чем подвох))?