Данные по двум организациям обрабатываются в двух разных базах ЗУП. Требуется объединить в одну базу.

Можно было бы перенести данные через универсальный обмен XML. Но задвоятся все справочники и классификаторы.

Может, быть есть какое-то другое решение?
Я сколько искал - не нашёл.

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

(0) Тут 2 выхода:
1) Через серилизацию (выгрузка/загрузка данных XML, добавить как распределенную базу в план обмена, выгрузка данных для перехода в сервис и т.п.) и потом дубли сворачивать.
2) Через разработку правил конвертации данных. (можно попытаться выдернуть правила КА-ЗУП и уже их дорабатывать.)

Оба варианта геморройные.

А зачем же переносить классификаторы?
Лично я пошёл бы по пути переноса кадровых приказов, ШР,  физлиц, сотрудников, данных для расчёта средних и сальдо на 01.01.2025

Все варианты выглядят как "3 месяца мучений" :(
А так хотелось счастья. Легко и в удовольствие :)

(4) Легко и счастливо это не про ЗУП) Там еще могут быть неочевидные подводные камни, например виды начислений, которые вроде по названию одинаковые, а формулы разные - ловил такой прикол при объединении зупов)

(3) Самый понятный вариант.
Типы объектов выбрать в универсальном обмене XML?

(4) Никаких "три месяца" :(
Уравнять версии конфигураций; временно поднять РИБ; одну базу объявить ЦУ, другую - ПУ; далее "вручную" пачками регистрировать изменения записей нужных справочников и документов и проводить сеансы обмена. Если вторую из баз создавали копированием первой базы и изменением исходных данных - то могут быть проблемы (неуникальные идентификаторы), а если базы реально поднимались как автономные и независимые друг от друга, то GUIDы уникальные и высока вероятность что такой вариант прокатит.

(6) Чую не понимаешь чем это чревато. Сводная база будет нерабочей

(6) Это не ко мне.
Добавлю, что после проверки (3) на отсутствие дублей и битых ссылок можно перенести уже документы начислений и выплат за 2025 год, но без проведения. Проводить хронологически с пересчётом и перезаполнением выплат.

(6) Не брались бы вы за это если не понимаете суть...
Я пару лет назад делал правила ЗУП-ЗУП. Ушло пару месяцев на них, но там была подмена ВР, свертка базы, заполнение служебных полей и т.п. В (3) как раз и описан вариант переноса правилами. Теоретически вендор уже сам реализовал похожий механизм в правилах по переводу с КА в ЗУП (в обоих используется одна и та же подсистема зарплаты), но просто из коробки это не заработает - нужно пилить.

Дублей бояться - базы не объединять. Есть же обработка выявления и устранения дублей.

Ещё бы понять, а зачем РАЗНЫЕ организации приспичило вести в ОДНОЙ базе.

(12) А чё нет-то?

(7) Этот вариант я описал в (2), те же проблемы будут. Что у вас в ПВР "начисления" допустим будет? Они же кодом создаются и с разными гуидами и будут дубли расчетов РК, СН и так далее. Нет тут быстрого варианта к сожалению...

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

(12) Как по мне, то хотелось бы услышать почему изначально решили вести учет в раздельных базах. И что с тех пор изменилось.

(13) Ну... зачем светить лишний раз аффилированность?
Это ж не голова и филиал, где ИНН один.
Не знаю - не вижу практического смысла в одной базе.

(17) наши аргументировали что хотят отчетность видеть нажатием одной кнопки а не ждать 10 отчетов из разных баз от разных бухгалтеров да еще и проверять их потом когда цифры сходиться не будут.

(16) Да всякое бывает. Есть например известная сеть фитнес-клубов, каждый клуб отдельное юрлицо, изначально у каждого была своя база на сервере локальном. Потом завели централизованный сервак, решили и базы объединить

(18) Да я не настаиваю. Понятно, что всё индивидуально. Если все фирмы пушистые, то можно и в одной базе.

(18) А зачем ждать, когда можно открыть все 10 баз на своём компе?

(21) У нас заходила одна организация на проект, так часть филиалов была на разных Зик вусмерть переписанных, часть на Камин (разных), а часть вообще не на 1С... Откройте и посмотрите сводно

(22) Речь не про филиалы, а про налогово РАЗНЫЕ организации. Дробление бизнеса для сохранения УСН. Я бы не стал их вести в одной базе, а вы как хотите.

(21) у нас была картина как в (22)
ну и филиалы удаленные не до всех стабильная сеть
главбух не хотела в 4 разных программах разбираться как собрать нужные ей данные и отчеты.

(0) Не вижу особой проблемы
Я бы слил все как есть в одну базу
Затем постепенно через поиск и удаление дублей вычистил

(25)+ Дубли в базе это нормально
Ненормально когда нет регламента и регулярных действий по их исправлению

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

стесняюсь спросить, а на хера это надо? логичнее делать ЗУП под каждое юрлицо... а вот в общий компот их сливать, это надо альтернативно одаренным быть...

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

(28) Разделить базу не проблема в любое время
Как через удаление в копии так и через выгрузку/РИБ по организации
Это слить сложно из-за синхронизации/сопоставления и дублей НСИ

(27) Если бухгалтера (и админы) разные есть смысл разных баз по организациям
А вот если одни и те же - удобней иметь одну базу а не зоопарк
Банально обновление типовой проще

(30) вообще не понял про админов. причем тут админы?...

на предыдущем месте работы было более сотни ЗУПов. админы тут вообще не причем...

обновлялось все хозяйство автоматически с помощью Обновлятора...

(29) А представь теперь что вышло косячное обновление
Его без особого тестирования накатили на продуктив. Если у тебя 1орг=1база, то последствия будут в разы меньше чем в одной базе N орг-ций.
А таких случаев за последние 4 месяца было навалом. То имущественный вычет предоставлялся кому не надо, то из за него же не пересчитывался НДФЛ по Рк и СН, то ошибка в карточке физлица, то в премии за счет резерва

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

(32) (33) vs (34) - интересные противоположные мнения

(32) под админами я подразумевал всех кто обновляет, сопровождает типовые и в первую линию разбирается с любыми проблемами
понятно это не только админы но и в целом 1Сники разных уровней

(33) это даже не смешно про обновлятор
в типовых там через раз то записи регистра стали неуникальными то еще что
и самое веселое когда нечто вроде перехода ЗУП с 2.5 на 3 - как это на зоопарке баз?
какие трудозатраты относительно одной?

(34) откатить одну базу проще чем две или более
как и разбираться с проблемами проще в одной базе а не в нескольких
например передать базу франчу по итс чтобы разбирались в типовой

и самое главное удобней юзерам в одной работать, меньше действий и быстрей
и меньше лицух требуется если на сеанс

https://infostart.ru/1c/articles/1330045/
https://infostart.ru/1c/articles/2155981/

Актуализируйте данные и вперед

(0) Делал такое лет 5 назад.
На КД2 создаем правило. Прописываем поля поиска.
Проблемы были в основном с дублированием.

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

Если сотрудники из одной организации в другую бегают, их тоже проверить сразу.

И вроде не подчиненные регистры сведений переносились не так просто.

(34) Обычно если накатывают обновление на продуктив, то сразу на все базы. Т.к. обновление требуется всем.

+39 ....не подчиненные регистры сведений ...
регистры сведений без регистратора

(40) Не всегда. На позапрошлой работе было 7 разных зупов, с разными допилками (пилили еще до меня), обновление каждой занимало полдня. Поэтому обновление всех растягивалось на пару недель (по выходным)

(36) Нет никаких противоположных мнений. Я согласен с (27) - одно юрлицо-один ЗУП. Нефиг сажать всех в одну базу

(37) Если у тебя 5 баз и ошибка вышла в одной - не обновляй остальные пока не разберешься

(42) Вот именно. А если этот ЗУП еще не сам по себе, а как блок ЕРП - это обновление может вообще месяц готовиться и производиться

(34)
>>А представь теперь что вышло косячное обновление

Я обычно жду неделю (если позволяет время) и читаю мисту.
Если "плачей Ярославны" нет - накатываю.

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

(36) >> это даже не смешно про обновлятор
в типовых там через раз то записи регистра стали неуникальными то еще что
и самое веселое когда нечто вроде перехода ЗУП с 2.5 на 3 - как это на зоопарке баз?

не было никаких неуникальных записей регистра за 5 лет. и других косяков не было. обновлятором нормально обновлялось.
переход с 2.5 на 3 прошел успешно и безболезненно. в чем проблема?...

(46)
Проблема в том что кто-то сказки рассказывает или с проблемами некто другой разбирался
А сказочник только рукамиводил

(47) да нет. не было проблем. не все же рукожопы...

(47) Пользуюсь Обновлятором второй год, обновляю пару десятков баз
Никаких неуникальных записей регистров за это время не обнаружилось. Как и никаких других проблем вообще

(47) (49) было такое, но не в ЗиК
крайний раз в сталкивался БГУ 2.0 при обновлении с релиза 95 на 96 чуть больше года назад конец января-начало февраля 2024
процесс обновление ползет-ползет, потом процентах на 60 хоп и вываливается ошибка. но! программа не закрывается, а предлагает проверить обновления (патчи), нажимаешь установить патчи, устанавливает и обновляется дальше. Прикол в том, что патч выпущен для 96 релиза и на 95 автоматом не ставился. То есть сначала в конфигураторе  обновляешь с 95 на 96 релиз, запускаешь в режиме предприятия, дожидаешься вываливания ошибки, жмешь поставить патчи и и процесс обновления ползет дальше :)
какой конкретно патч надо было искать, лень, ставил все автоматом, но кажется вот этот, хотя может и не точно он.
"EF_00_00631762     
При дополнении идентификаторов классификаторов, которые обязательны для обновления в Фреш отсутствует удаление дублей."

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

(50) +
Вот они, родимые неуникальные записи. "Запись с такими ключевыми полями существует".  БГУ 2.0.96.57 вышла 07.04.2024. Так что менее года тому назад.
(48) у кого рукожопость? Вот эта конфа, которая на скрине - никогда с поддержки не снималась, замочек на месте, никаких расширений левых. Все строго только и исключительно от вендора. Так что рукожопость только у кого? у разработчиков? Лечится, как я выше сказал, установкой патчей к 96 (то есть к тому, на какой обновляем) релизу. То есть чтобы обновить, нужно установить патчи, а чтобы установить патчи, нужно сперва обновить :)))
Обновлятор мне в этом конкретном случае не помог.
И да, это не случайность, это тридцать разных баз в разных учреждениях, как файловых (файл серверных) так и на MSSQL. Картинка одна и та же.

Если не выжидать и не прыгать уже после по наилучшим релизам
А ставить каждый только выходящий промежуточный + все патчи
В этом случае проблемы (с которыми не поможет обновлятор) возникают практически через раз!
Понятно только на больших базах с кучей разных операций, да еще с кривизной в данных, от криворуких и юзеров и разрабов

Получается обновлятор можно смело выкидывать
Точнее писать свой, который умеет сносить все патчи (если почитать то это обязательное действие перед обновлением) и ставить только нужные
И обновлять с выполнением нужных действий в режиме предприятия по некоему шаблону

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

Обновлятор же хорош для автоматического обновления (на много релизов) сильно отставших конф/баз
Или кучи мелких баз чтобы автоматом
Затем смотрим какие не взлетели авто и уже вручную разбираемся

пока вывод один.
базы 1С без помогалок в лице 1Сника как-то не очень живут. и это при том, что это же "тупые" бизнес-приложения. Грустно все это. А хочется розовых единоргов, сферических коней в вакууме, а по факту - как копались в гуано 20 лет назад - ничего не поменялось. Вот такой у меня взгляд на всю эту автоматизацию. Сплошные химеры.

Вообще, объединение баз ЗУП - дело непростое. Пример нормального подхода: https://dzen.ru/video/watch/6630e62c2b59bc3445376ef8?share_to=link

Куча допущений, масса условий, тонны проверок...

По поводу Обновлятора, было как то пару раз конфигурация поставщика слетала у знакомых, приходилось снова ставить на поддержку. Впрочем, это и при ручном обновлении случалось раз у меня уже. Интересно, как он merge-конфликты разрешает. Подозреваю, там тупо настройка объединения как по-умолчанию, т.е. это подойдет в основном для баз с небольшим числом доработок. Опять-таки, вопрос доработок в расширении, если они есть, которые тоже нужно иногда обновлять, и обновления измененных форм (буквально полгода назад было, когда структуру форм многих документов в БП поменяли в связи с ГИС-ами и прослеживаемостью.)

(55) "А хочется розовых единоргов"

Чтобы нас всех с работы выгнали ?
Если типовые станут такого качества что тупой юзер сможет разобраться в любой ситуации, зачем тогда прог/конс/аналитик  ?

(4) Легко не получится, хотя, с двумя организациями может за месяц можно справиться
Свертка ЗУП3.1 как?
Тут в сообщении указана обработка свертки, которой в том числа у нас пользовались. Хотя, лично я сторонник правил обмена, которые все разом сделают в пустую базу, но такие быстро устаревают. Тем не менее, здесь уже упомянули (2) такой вариант, значит возможен.
У нас программист по ЗУП делала так:
1. Свертка базы обработкой выше.
2. Перенос выгрузкой-загрузкой XML (здесь неизбежно будет куча дублей по результату).
3. Чистка дублей и борьба за качество данных, разгребание косяков.

(59) Путь понятный, хороший.
Если бы я был на ставке - так бы и сделал.
Но тут клиент требует фиксированную сумму. А объём дублей и косяков - сложно предсказуем.

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

(60) Клиент думает, что это дешево. Если озвучить нормальный ценник (включающий сопровождение в течение двух месяцев для исправления косяков), то он может и передумать.