Переношу самописную конфигурацию при помощи конвертации2. Данные в базе разделены. Кто-нибудь сталкивался с таким, как лучше это сделать?

Если где-то кто-то что-то разделил - почти всегда это можно объединить обратно.

PS. Фарш - исключение.

Если я правильно понимаю, то вопрос состоит в том, как правильно соединить данные? Типа дубли что ли? Поля поиска указать.

(2) Есть такая технология разделения данных в 1с. На подобии организаций в типовых. Данные разделены, но конфигурация общая. Вот как несколько баз с одинаковой конфигурацией в одной.

в наличии в каждом разделении, одинаковые коды и названия

(3) Что значит "на подобии организаций"?
У разных организаций - общие справочники, разные док-ты. Но, опять-таки, есть нюансы.
И "несколько баз с одинаковой конфигурацией" - это о чем?

(3) похоже основные действия надо выполнять в ПВД. Выбирать данные сначала для одного параметра сеанса, потом для другого и т.п. потом соединять данные и уже отдавать в ПКО.

+(6) Только не понято, что делать при выгрузке по ссылке. короче слишком мало информации по твоей базе и что конкретно ты переносишь.

(0) если используется типовой механизм разделения данных, то тут 2 варианта

1. для каждого значения разделителя делать отдельный файл выгрузки по стандартным правилам кд2, а при загрузке как-то не стандартно все сливать

2. делать выгрузку из под неразделенного пользователя, правда я не уверен, что прокатит

(5) Можно вести несколько организаций в одной базе. Разделение данных... Можно погуглить.

(6) Да, вся проблема в том, что выгружается только то, что доступно в текущем сеансе. А при загрузке невозможно загрузить из-за того, что коды справочников и документов накладываются друг на друга и получается фарш.
Вопрос в том где/в какой момент объединить.
Какая тут информация, два десятка справочников и документов на которых включено разделение данных.

(8) так и есть пробую не стандартно залить, но не все гладко получается.
к пункту 2 при разделении общего пользователя нет. при попытке объединить данные в источнике - база рассыпается.

что значит рассыпается ? Дубли что появляются ?

(12) пропадают данные.

В одном разделителе у тебя номенклатура код 105 - "Молоко топлёное б/у", в другом "BMW слегка дырявая (80 отверстий 5.24)"
И как ты их будешь объединять?

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

(14) :-)) молоко БМВ топленое дырявое

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

(15) Ну если подробно то так. Если перенумеровать все элементы справочников и документов ещё получается. А вот если отключить разделение или попытаться выгружать загружать то справочники и документы получаются пустые.

(17) Это самописка

(17) перенос в другую базу с объединением.

(17) Во вреше не работал?

Честно говорю, я вчера не пил, но понять не могу.
Выгрузка идет через файл ? Перехватить файл возможно ? Посмотреть что выгружается в файл можно ?
В этих данных есть переносимые данные ? Да/Нет
Если данные есть, то что же загружается ?
я вот с разделителями не работал, но если этот признак допустим есть в выгрузке и его база приняла не может ли быть так что ты "не видишь" этих данных в базе после переноса .
Хоть что нибудь переносится?

(22) Я выше писал (10) (11)

(21) что это?...

(24) https://1cfresh.com/

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

(26) Я это и смотрю, но написал на форуме на тот случай, если кто-то уже имел дело с таким и мог бы поделиться опытом или идеей, чтобы не изобретать велосипед.

а в чем тут велосипед то ? это правила обмена .. что сказал , то и получилось

(25) у меня во фреше типовая БП лежала. что-то я не помню там разделения справочников по организации...

(29) Организация и разделитель данных в фреше - немного разные вещи.

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

(27) При загрузке ищи по ГУИДу, зачем по стандартным реквизитам искать?

(31) Так и делаю.

лучше перенести как есть, а потом заниматься удалением дублей

(17) любая типовая (хоть бух) имеет 100% функционал разделения, включается по 2м константам, после этого без всяких фрешей и прочей лабудени все работает с разделителями.

я думал ЗУП так сделать, по тому как типовой план обмена в ЗУП "по организациям" нифига по организациям не работает, он столько мусора выносит в узел, что ппц

(35) чтобы сделать РЛС по организации, например, для справочника "Номенклатура", у этого справочника как минимум должен быть реквизит Организация. в типовой БП он есть?...

(34) так не выйдет, причин много...

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

(36) будешь удивлен - есть
ОбластьДанныхОсновныеДанные + ОбластьДанныхВспомогательныеДанные

(37) +
и соответственно этот реквизит в конвертации используй для поиска

(38) конечно буду...

(37) можно причины озвучить?

(37) Да, вариант.

(41) Причины в том, что дублей нет и данные могут иметь одинаковые ссылки, коды итд.

(41) например ключ поиска не включает в себя разделитель,
например у меня есть 2 разных по смыслу контрагента с одним ИНН и одним КПП но разделенные разделителями, при твоем подходе - они сольются и будет использоватся только 1 набор....

пример:
для разделителя 1 - инн=000000 название=Прочие
для разделителя 2 - инн=000000 название=Наша черная компания
для разделителя 3 - инн=000000 название=Официальный постащик из Франции

как думаешь, что получится ?

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

Ну так представь что это физически разные базы и тебе нужно слить в одну

(45) Тебе кажется. При независимом разделении - могут.
См. https://its.1c.ru/db/v8313doc#bookmark:dev:TI000000879 пункт 24.2.1

ПВД со способом выборки "Произвольный алгоритм" и твори там все что хочешь. И обмен быстрее работать будет.

(48) Да тут вариантов не много. Главное данные не потерять. И я думал, что все-таки возможно сразу выгрузить, но придется под каждым сеансом выгружать.