Здравствуйте. Подскажите, пожалуйста, есть ли решение моей проблемы.

К новому году планируется перевод баз бухгалтерии на версию 3.0. В связи с большим количеством баз, поставлена задача организовать РИБ таким образом, чтобы все обновления и изменения конфигураций делались только в одной базе (корневой), а все остальные базы были подчиненными узлами и подгружали только изменения конфигурации. Таким образом не пришлось бы обновлять/изменять все базы по отдельности и они бы всегда были идентичными.

Так получилось, что одни и те же изменения в базы вносилсь не путем сравнения и объединения конфигураций, а НЕЗАВИСИМО ВРУЧНУЮ (например реквизиты справочника или новые перечисления). Таким образом, не смотря на то, что при выполнении "Сравнить, объединенить с конфигурацией из файла" данные полностью сопосталяются, эти объекты и реквизиты имеют РАЗНЫЕ ВНУТРЕННИЕ ИДЕНТИФИКАТОРЫ. При создании РИБ необходимо, чтобы конфигурации совпадали полностью (включая внутренние идентификаторы), поэтому перед установкой главного узла для подчиненных баз необходимо выполнить "Загрузить конфигурацию из файла" для каждой базы, а тут сопоставление идет уже по внутренним идентификаторам, а они НЕ СОВПАДАЮТ. Поэтому после сохранения все данные (внесенные пользователями) затираются.

Как быть в такой ситуации? Кик привести все базы к одной и той же конфигурации для организации РИБ без потери пользовательских данных?

РИБ только так и работает. Сделай 3.0 с нужными допилами, потом создай из неё подчинённую базу

просто но ёпко - создать пустые узлы, перенести данные

(0) Имхо только если делать пустые подчинённые базы, а потом в них грузить данные через xml.

(2)(3) А как лучше всего выгрузить и загрузить данные чтобы ничего не потерять? Там какая-то универсальная обработка была типовая. Ей?

>>не путем сравнения и объединения конфигураций, а НЕЗАВИСИМО ВРУЧНУЮ (например реквизиты справочника или новые перечисления)
Если знаешь их перечень - можно выгрузить нужные объекты, привести конфу в нужный вид, удалив несовпадающие метаданные, сравнением-объединением накатить нормальные и загрузить

не думаю что так много доработок вносилось вручную, этож гемор на многих базах

(5) не совсем понял что ты имеешь ввиду. Можно на конкретном примере? Вот допустим пусть в справочник "Контрагенты" добавлен реквизит "ПОЛ" типа "Перечисления.ПолКонтрагента". Соответственно в моем бы случае для всех бы контрагентов затерся бы пол. Как бы ты тут сделал?

(7) в XML выгружаешь справочник контров, удаляешь реквизит, сравнением-объединением реквизит "правильный" добавляешь, загружаешь xml

Переносиьт ВСЕ ланные во много баз тот ещё гемор, возможно вариант (8) будет менее трудозатратный. Тут надо смотреть на количество допилок кривых

(8) Теперь разобрался. Спасибо большое. А напомни, пожалуйста, как называется эта обработка для выгрузки/загрузки XML?

(10) ВыгрузкаЗагрузкаДанныхXML

(11) Спасибо, буду пробовать.

На другом сайте мне ответили: "Между прочим, для решения вашей задачи вполне пригоден механизм поставки конфигурации. А РИБ... с ним вы рискуете получить много проблем, совершенно вам не нужных."
Я с поставками не работал. Как считаете, правда с поставками можно проще решить эту задачу?

(12) проблем с РИБом не вижу, он прекрасен. Поставкам лично я не доверяю, надо готовить файл поставки, как то рассылать базам, обновлять каждую базу им, и не факт что с идентификаторами там не так же, как с РИБ.
Единственное при РИБ надо проверить как переход на другую версию типовых работает (обработчики по изменению данных после обновления)

(12) Те же яйца, только в профиль

(7) А если речь идет о документе? Представь, что у документа есть вот такой вот проблемный реквизит. Придется документы выгружать/загружать. Я так понимаю, тут все послетает или будет перепроводиться?

(15) У меня тут еще бывает, что есть типовое перечисление, например "ВидыПлатежейВГосБюджет", которое является субконто счета 68.02. Так вот в это перечисление добавлены в разных базах ручками новые значения и выбраны в документах.

(16) получается придется Регистр бухгалтерии выгружать/загружать. Чувствую не получится ничего хорошего(

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

(17) ну а полный перенос думаешь проще?

(18) Ок. Буду тестировать. Спасибо тебе большое

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

(21) да, пробовал. Во всех документах затерлись эти реквизиты

(22) ну вдумчиво, кусочками приводи конфы к единообразию

(23) ок) Их всего-то 27 баз))))

(24) ну не в каждой же ручками добавляли? пяток ущербных это не 27)

(13) ...как переход на другую версию типовых работает...
А вот это - в точку!
В периферийных некоторые обработчики запускаться не будет, когда увидят что база периферийная. Будут ждать загрузки измененных данных из центральной.
(0)Я бы посмотрел на механизм поставок.