Здравствуйте!

Думаю как реализовать следующую задачу.
В организации нужно в рабочую базу ЗУП 3.1 залить данные из другой базы ЗУП 3.1 по другой организации, т.е. сделать слияние баз в одну.
Можно такую процедуру сделать стандартными средствами без написания обработок переноса?

На форуме была подобная тема, но там топикстартер решил применять КД с последующим допиливаем правил обмена.
Я боюсь, что такой метод будет слишком трудоёмкий, а времени до начала следующего года не так уж и много.
Возможно этот метод не оптимальный.

А какие-то дубли тебя не пугают? Например, виды расчетов повторяться будут и что-то тому подобное, вплоть до дублей физлиц?

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

(0) Я бы хорошенько подумал: а так ли это нужно на самом деле ?
Причем рассматривать надо только реальные причины, а не желание пользователей и начальства "шоб так було"

И еще не поставлен вопрос - после "слияния данных" сколько в базе будет организаций?
Если подразумевается, что две, тогда план обмена в конфигурации встроенный для этого есть. Только перед началом обмена надо установить в обе базы одну и туже конфигу поставки.

ОбменВРаспределеннойИнформационнойБазе

как уже сказали, ВыгрузкаЗагрузкаДанныхXML такое может, НО там полно нюансов. Самое главное - ни в коем случае не сливать базы, которые ранее были созданы путем копирования из какой-то одной, т.к. внутренние идентификаторы объектов у них будут совпадать и новая информация затрёт старую. И второй момент - если просто переливать все объекты (справочники, регистры сведений), то продублируются некие предопределенные объекты, которые бы совсем не стоило объединять. Например, "валюты", "виды начислений", "регламентированныеотчеты" и т.п.

Даже поиск и удаление дублей не всегда выправляет ситуацию. Короче, можно, но не элементарно, чтобы щёлк и готово.

(2) И куча дублей предопределенных элементов, ага!

Ситуация такая.

Организация ООО "Ромашка" покупает организацию ООО "Дельфин". Ранее между организациями не было никаких отношений.
В организации ООО "Дельфин" свой учет по зарплате (своя база).
Руководство приняло решение слить данные по зарплате в базу ООО "Ромашка".

(1) Физические лица не должны пересекаться. Виды расчетов???? Вопрос интересный и не однозначный.

(9) в смысле, предполагаете, что Дельфин и Русалка живут в разных морях и там одних и тех же физиков не водится? Не в техническом смысле, а в физическом. Если водятся, то после "слияния" в справочнике физических лиц дубль должен выскочить.

(8) Не может быть такого, что штатное подразделение Дельфин окажется и теперь обособленным подразделением относительно Ромашки?

(10) Да. Физические лица не пересекаются.
(4) В базе ООО "Дельфин" одна организация. В базе "Ромашка", в которую будет сливаться информация по зарплате, изначально около 8 организаций.

(8) >>Руководство приняло решение слить данные по зарплате в базу ООО "Ромашка"

Ну просил же без идиотских обоснований типа "начальство решило"

В этой ситуации почти неизбежно придется уволить всех из Дельфина и принять заново в Ромашке. Объясняется это очень просто: у сотрудника изменяются многие существенные условия труда, поэтому тут без нового ТД не обойтись
Поэтому ничего никуда заливать не надо, увольнение и прием - вот что придется делать

(13) не будут они этого делать

Могли бы, но не будут. Будут говорить, что нет оснований, что не будут закрывать компенсации за неиспользованный отпуск и не будут переносить или пересоздавать резервы отпускных и т.д. и т.п.

(12) так вот... еще раз переспрошу - прежний Дельфин со своими штатными подразделениями останется в виде обособки или обязательно исчезнет? Возможно он в другом городе/районе/регионе и тогда точно останется.

(15) Вообщем сейчас конкретно узнал всё.

Организация ООО "Дельфин" выкуплена, но остается такой-же самостоятельной, т.е. не будет является обособкой или поглощаться ООО "Ромашка".

В ЗУПе ООО "Ромашка" должна появится ещё одна самостоятельная организация ООО "Дельфин", т.е. хотят вести учет по нескольких независимым организациям в одной базе. В дальнейшем данным перекачиваются в БП.

Цель избавится от лишней базы и все организации вести в одной.

По поводу кадровых документов и начисления зарплаты нужно перекачивать всё что есть в базе ООО "Дельфин".

(16) ну вот тогда есть что пробовать

Есть типовой план обмена РИБ По Организации. Откроешь в конфигураторе, увидишь. Там планов всех в ЗУП не так много, как в БП.

Я бы сделал сразу в целевой базе, там, где Ромашка, новую Организацию. Просто новую и все. И указал в ней все нужные реквизиты, хотя, это может и не столь важно.

Затем вывалился бы с ней в новый периферийный узел.

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

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

НУ там конечно, выгрузить и основной Текущую конфигурацию - именно из нее, а не из интернета.
Затем загрузить ее в базу Дельфин и прикрутить же в дельфине сам узел периферийный в списке обменов.
В общем, сделать можно. Повесить затем перед попытками обмена что эта база не главный узел. На итс инструкция есть, как создавать новый периферийный узел альтернативными способами.

(16) >>Цель избавится от лишней базы и все организации вести в одной

Это не всегда возможно и не всегда целесообразно
В этом есть смысл (для ЗУПа) если одни и те же сотрудники работают в нескольких фирмах холдинга.
Не стоит также забывать что часть настроек может задаваться целиком для базы, а не для организации  в базе

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

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

Сделайте через выгрузить данные для перехода в сервис и загрузку данных из сервиса

(16) "хотят вести учет по нескольких независимым организациям в одной базе" - зачем хотят?
"Цель избавится от лишней базы и все организации вести в одной. " - это не цель!

Целью может быть:
а) упрощение работы расчетчиков и бухгалтеров - это объединением баз не достигается
б) упрощение администрирования (но судя по всему, об этом не думают)

А вот что теряют - это полное разделение данных, чтобы кому не надо, не лез в чужое ООО.

(22) При желании настраивается доступ на уровне записей. Т.е. абстрактный юзер Вася не сможет посмотреть документы, касающиеся организаций, складов, контрагентов и т.п., не указанных в ЕГО правах

(23) угу... и одновременно с этой настройкой по такому желанию отхватываются тормоза от RLS

Лично мое мнение, которое в некоторых случаях находится в эксплуатации :

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

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

(0) Делал такое в БП через ВыгрузкаЗагрузкаДанныхXML. Потом заколебался чистить дубли, справочников 20 набежало в общем, особенно аккуратно нужно с теми что в БСП входят. В ЗУП думаю будет еще сложней отловить косяки.

(17) А как заставить "периферийную базу", которая являлась самостоятельной до текущего момента, думать, что она таковой является?

(26)+ не сразу увидел (18), буду читать)

(12) "Около 8 организаций" - и никаких проблем нет?

(18) Из базы ООО "Ромашка" я создал периферийную базу. А как подменить эту базу базой ООО "Дельфин"?

(29) https://its.1c.ru/db/metod8dev#content:2277:hdoc

прочитал это? Там можно увидеть принципы привязки периферийной базы к обмену

Данный способ является альтернативным способом создания нового узла распределенной информационной базы. Он может применяться в случаях, когда, например, нет необходимости в переносе всех данных во вновь создаваемую информационную базу. Во многом операции, которые необходимо выполнить для создания нового узла распределенной информационной базы данным способом совпадают с операциями, выполняемыми платформой 1С:Предприятие 8 при создании начального образа. Опишем данный способ подробнее:

и подробно там в ссылке

(30) Статью читал, но брал не тот абзац из статьи. Теперь нашел там всё что нужно.
Оказывается всё просто. Основной нюанс загрузить конфу в базу ООО "Дельфин" из базы ООО "Ромашка". Узлы настроил без проблем.
Спасибо, что тыкнули носом в статью.

Теперь попробую выгрузить все данные из Дельфина в Ромашку и буду анализировать справочники и виды расчетов.

Я бы начал со сравнения нового узла с Дельфином.
- когда был создан периферийный узел типовой и без пользовательских данных Дельфина и Ромашки,
то перескочившие в новый узел данные имеют УИДЫ из Центрального узла и это практически предопределенные данные.
Подозреваю, что именно эти данные могут задублироваться, когда будет выполнятся обмен
Либо после обмена с Центром на их месте внутри объектов из Дельфина окажутся ссылки на "объект не найден"

Не из Дельфина нужно начинать выгрузки делать, а повторно помечать данные узла в Центре и грузить в Дельфин и заменять дубли экземплярами объектов из Центра.

Виды расчетов задвоились ((((

Перестала начисляться зарплата.

Метод РИБ по сути убил базу ЗУПа, в которую вливались данные

В смысле "перестала начисляться" - не заполняется вкладка в документе Начисление?

(36) Ну, хотели объединить - получили что хотели :)

(37) Создаю новый документ "Начисление зарплаты". Нажимаю на кнопку "Заполнить", чтобы автоматически заполнились табличные части документа, но получаю на экране ошибку.
https://i0.wampi.ru/2019/12/24/QIP-Shot---Screen-004.png

Я попробовал скопировать документ прошлого периода и провести его. И получаю ошибку.
https://i8.wampi.ru/2019/12/24/QIP-Shot---Screen-005.png

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

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

(41) Релиз конфигурации какой?

(41) Тоже через РИБ переносили?

(43) он написал, что через Выгрузку загрузку.
И еще не написано в его сообщение : уже попробовали создавать новые документы с Начислениями или только старые перенесенные из база в базу посмотрели и все?

(39) первая ошибки - потеряна связь с показателем НормаДней, который и дает деление на ноль.

Эти НормаДней в дублях были?

(45) Какой Регистр сведений хранит эти данные?

(0) Какова конечная цель этих телодвижений?

вопрос
сколько народу работает в базах?
если один человек,то слияние оправдано,а если несколько,то лучше для каждого своя база.

опять же,табельные номера и т.п.поменяются.
и ЗУП не очень готов к реальной многофирменности.

Изучал эту тему и пришел к выводу, что только написанием своих правил обмена можно получить результат. Видел результаты слияний через  ВыгрузкаЗагрузкаДанныхXML и РИБ для БП 3. С вероятностью 90% ЗУП после такого работать не будет совсем по всем организациям. Деление на 0 и еще че-то там вылетать будет.

(47) Нужно в базу ЗУП, в которой ведется учет по нескольким организациям влить данные базы другой базы ЗУП ещё с одной организацией.
Или хотя бы влить данные так, чтобы расчет зарплаты и кадровый учет не поломался по тем организациям, которые уже в базе есть.
А с новой организацией можно потихоньку разбираться.
Вчера вечером через РИБ залил данные в базу. Сегодня утром звонок. Аванс надо начислять, а в базе ошибки при проведении документов.
Пришлось всё откатить.

(49) Мне кажется деление на 0 это начало снежного кома.

Если перекачать только справочники и документы, то ошибки скорее всего будут тоже

(51) В ЗУПе куча независимых регистров, которые пишутся подписками и прочими "отложенными" механизмами. Если их не перенести естественно получишь проблемы.
Перепровести документы в приемнике тоже скорее всего безболезненно не получится.

Если свои правила обмена писать, то достаточно много времени нужно, чтобы их отточить до идеального состояния

По сути самый трудоёмкий путь

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

Т.е. очередность действий над базами оказалась не совсем та.

Как минимум, это дало бы возможность откатывать не все базы сразу, а только одну.

И вопрос, а другие данные в центральной базы, кроме данных Дельфина остались работоспособны у вас или сломалось все для всех организаций? Вы сохранили для продолжения экспериментов эту "сломавшуюся" центральную базу?

(55) Визуально в центральной базе всё нормально. Бухгалтера наткнулись только на невозможность работы с начислением ЗП.
По сути сломаться данные центральной базы не должны, т.к. периферийная база добавляет свои не изменяя существующие.
Бэкап центральной базы есть после загрузки в неё данных периферийной базы.

Но Начисление было именно в организации Дельфин - остальные не испортились?
Насколько масштабная катастрофа

з.ы. для теста данные остались?

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

Бэкапы все есть

Понятно.

Теперь возникает вопрос, каким образом появление еще одной базы из обмена смогло сломать Показатели?
Впрочем, все показатели, кроме добавленных вручную, назначены достаточно жестко на уровне конфигурации.
Или они были перезаписаны в процессе получения данных из Периферийки с заменой ссылок на новые объекты.

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

(60) А ты уже делал слияние ЗУП 3.1 или только теоритические гипотезы высказываешь?

Забавно. 2 года назад разделяла базы, в которых было по 7-16 организаций. Часть закрывали, часть поделили собственники. Условие было "чтобы никаких остатков -даже справочник Организации очистить". Когда расплачивались, то ворчали, что обновления, на которых решили сэкономить, столько не стоили.

(62) А что забавного? Причем тут обновления? Я ничего не понял

(63) Обновляли всего 4 базы, в которых было 50-60 организаций.

+(63) а забавно то, что вначале они кому-то заплатили, чтобы базы слить, а через 2-3 года делиться начали.

Ну так-то слияние баз еще и в разы экономит программные лицензии. Ну и два-три года комфортной работы тоже весьма клево.

(61) Я разделение базы делал (Не слияние, а разделение). С разделением никаких особых заморочек не возникло на 3.1. На ЗУП 2.5 заморочки возникали, но там базы были испорчены разными вмешательствами, так что и не актуально это теперь.

По РИБ тоже делил и соединял, но не конкретные свежие версии ЗУП 3.1 - в целом, твое замечание справедливо в той части, что нужен уникальный опыт на уникальных свежих базах, т.к. развитие типовых происходит такими способами, что сохранение работы штатных РИБ тоже может оказаться под большим вопросом.

(66) как оно лицензии экономит-то? Есть пользователь - есть лицензия пользовательская - ну есть у этого пользователя десять баз или десять организаций в одной? Берешь ключ, лучше юсб и однопользовательский, на его рабочее втыкаешь и забываешь о проблемах клиентских лицух

(50) "Нужно в базу ЗУП, в которой ведется учет по нескольким организациям влить данные базы другой базы ЗУП ещё с одной организацией." - это я понял. Я не увидел причину, зачем это нужно.

В свое время была такая шальная идея. Пытались несколько организаций слить в одну базу. В итоге, бросили эту затею: конечный результат не оправдывает затраченные ресурсы.

(69) Не только Вы, никто не увидел причины

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

(70) Главное в таких случаях: предупреждать руководство о том, что последствия могут быть тяжелыми. Хотя такое упоротое руководство всё равно виноватым выставит: "ты нам плохо объяснил".

(71) Тяжелые последствия могут быть только у совсем упоротого исполнителя. Нормальный человек все будет делать сначала на копии базы и смотреть что получается. Автор так и поступает, так что последствий не предвижу

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

(60) Я попробовал залить данные по базу ООО "Дельфин" и такие же ошибки появились причем по всем организациям.
Вообщем без разницы в каком направлении делать загрузку данных. В любом случае появляются однотипные ошибки во всех организациях.

(69) Хотят вести всё в одной базе.

(49) Почему только. Еще видел когда решением руководства дружно все вколачивали данные с программу несколько месяцев:) в цене не сошлись с работой по выгрузке из не 1С системы.

(70) Я делаю работы на копиях баз.

(74) До сих пор так не озвучена причина "хотелки". Зачем?

(67) Ну разделить через РИБ не проблема вообще, я тоже так делал. А вот сливать так, я че-то очкую.

(77) Да что вы прицепились с вашим "зачем"? Разве не очевидно, что проще работать с одной базой, как пользователям, так и разрабам и админам?

(79) Пока здесь только доказательства обратного прозвучали

(79) Представь, что ты строишь дороги. Нужно проложить дорогу из точки "А" в точку "Б". Но есть проблема: прямой дороги не получается - между "А" и "Б" находится гора.  

Варианты решения:
1. Сделать дорогу вокруг горы. Для выполнения задачи нужно 5 дней.
2. Снести гору. Для выполнения задачи нужно 30 дней (срок примерный, потому что никто не может оценить объем работ).

Да, прямая дорога - это хорошо для всех. Но... Есть определенные сроки и ограниченные ресурсы.

Что будешь делать?

Я забросил идею с РИБом. Вообщем мне помогла обработка УниверсальнаяЗагрузкаВыгрузкаXML. Поставил на выгрузку только справочники и документы. Остальное флажками "по необходимости". Ещё галку поставил выгружать документы с движениями. Первое что порадовало, что не было проблем с заполнением и проведением документов.

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

Единственное я выяснил, что способ РИБ вообще не применим при слиянии баз по причине того, что при загрузке в базу приёмник не происходит поиск по полям, а тупо если по идентификатору элемента нет, то значит грузим как новый. Лучше сразу пробовать обработку.

(83) Открыл сейчас Виды начислений и там есть задвоения. Даже если и есть двойники можно по ходу событий поправить. При варианте с РИБом результирующая база становиться мёртвой, т.е. не возможность проведения и заполнения документов. Со справочниками такая же беда.

(85) А теперь посмотри, не вылезли ли артефакты. Недавно сам делал подобное - так журналы "документы продажи" и "документы покупки" начали сбоить из-за задвоения идентификаторов метаданных. Пришлось лечить.

(86) Я отдавал на тестирование бухам. Они говорят, что всё устраивает.

(85) проверь ещё интервальные регистры и подобное

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

Вот тебе к примеру:
ГражданствоФизическихЛиц
ВоинскийУчет
КадроваяИсторияСотрудниковИнтервальный
ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам

и т.д.

Производственный календарь сломался

либо их стало два или больше либо еще что то

(89) Независимые регистры перенесутся. Согласен.

(91) если переносил через УниверсальнаяЗагрузкаВыгрузкаXML, то производственные календари при переносе дублируются и надо вычищать дубли. так же как и основные виды расчета

(93) когда я такое делал, писал свои правила

(93) многие технические справочники могут перенестись

(94) Сколько по времени ушло на написание правил? И какие данные через эти правила переносили?

ЗУП образца 2020 это не ЗУП 2013, последний дико тормозод даже по одной оранизации если кол-во ФЗ было более 5К
Сейчас десяток оргов в одной бд и ничо - механизм представлений в дсписках творит чудеса.