1с как объединить две базы в одну

Объединение баз данных 1С для создания многофирменного учета

Суть многофирменного учета заключается в ведении регламентированного или управленческого учета нескольких организаций в одной информационной базе. Достигается это путем объединения нескольких баз данных 1С в одну.

Можно объединять базы данных любых предприятий и организаций:

• аффилированные или не аффилированные (входящие в одну группу компаний или нет);
• с одинаковыми или различными видами деятельности;
• с однотипным или различным составом нормативно справочной информации (НСИ) и т.д.

Схематическое изображение многофирменного учета в 1С

Основные проблемы и неудобства, с которыми пользователи сталкиваются при ведении учёта в разных базах:

• увеличение ошибок, связанных с «человеческим фактором» из-за работы с множеством баз;
• увеличение счета на оплату за поддержку и администрирование баз;
• отсутствие сопоставимых между собой данных для целей консолидации.

Ниже наглядно продемонстрировано удобство работы с объединенной базой, в отличии от работы в базе каждой организации отдельно:

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

Преимущества работы в единой базе

Поддержка и администрирование

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

• обновление конфигурации (обновить одну ИБ быстрее и дешевле для Заказчика);
• обновление платформы;
• модернизацию конфигурации;
• настройки конфигурации;
• поддержку обменов и выгрузок (5 баз 1С:БУХ и 5 баз 1С:ЗУП требуют настройки и поддержки 5 обменов против одного обмена в единой базе);
• регламентные работы (тестирование и исправление ошибок, реиндексерование, обновление статистики, перепроведение документов, удаление помеченных объектов, сохранение резервных копий и т.д.).

Администрирование сервера и организация работы

• служебные данные одной базы занимают меньше ОЗУ и места на диске, чем служебные данные 5 баз меньшего размера;
• база недоступна для пользователей во время проведения технических операций, которые проводят в нерабочее время.

Отсутствие ошибок пользователей

• в документах не нужно выбирать реквизит «Организация», что позволяет избежать ошибок;
• работа с базой ведется из одного окна без надобности переключений между базами, в связи с чем исключаются ошибки по невнимательности.

Производительность

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

Нормативно-справочная информация (НСИ)

Единый источник для ввода НСИ позволяет:

• стандартизировать данные;
• централизовать ответственность за ввод данных;
• исключить ошибки многократного ввода;
• повысить достоверность и актуальность данных за счет удаления дублей и своевременного обновления.

Данные для консолидированной отчетности

• данные в одной базе структурированы;
• есть возможность консолидировать данные типовыми отчетами 1С.

Дополнительные возможности

Без хранения данных в одной базе невозможно использовать следующие механизмы:

• «интеркампани» (межфирменные продажи) — возможность продавать товары, которые нам еще не принадлежат;
• централизованное казначейство — использование «Кэш-пулинга», единого Платежного календаря по ГК, согласование заявок по единым для группы мастер бюджетам и т.д.

Отсутствуют сложности обмена документацией между юридическими лицами компании в рамках одной ИБ, когда для одного юридического лица документ отображается как отправленный, а для другого — как полученный.

Объединение двух баз

Добрый день!
Организация имеет 3 обособленных подразделения не на отдельном балансе (территориально находились в разных районах). Подразделение 1 и 3 работали в одной базе1, подразделение 2 работало в базе2. Теперь появилось желание работать в одной базе через Линк. Надо объединить обе базы.
1) Возможен ли перенос через обработку ВыгрузкаЗагрузкаXML? Тогда наверное, необходимо, чтобы в обеих базах были идентичны Наименование организации, структура подразделений, ШР, настройки расчета зарплаты….? А потом перенести документы обработкой.
2) Только дописывать.
3) Вариант, которого я не знаю.
Спасибо!

Обсуждение (8)

1) Объединение организаций в ЗУП 3.1 при реорганизации (слияние, присоединение) этот вариант конечно интересный, но не наш случай, т.к. переводов не надо делать, просто соединить подразделения. Изначально надо было просто вести все 3 подразделения в одной базе.
2) Объединение несколько баз в одну. и по цепочке Переход на ЗУП 3.1 можно применить уже на этапе поиска дублей физ лиц, которые когда-то переводились и подразделения 2 базы 2 в подразделение 1/3 базы 1.

Здравствуйте! Я бы остановилась на варианте использования обработки «Выгрузка и загрузка данных в формате xml» — Выгрузка в 1С из xml: как выгрузить данные из 1С 8.3 и загрузить в 1С 8.3 . Если будут дубли, потом их удалите с помощью штатной обработки «Поиск и удаление дублей» (раздел «Администрирование — Обслуживание — Корректировка данных»). Есть нюанс с номерами документов и регистрами, где значения повторяться не могут, но здесь уже нужно будет смотреть по конкретным ошибкам, как их исправить, может их и не будет вовсе.

1)я экпериментально пометила на выгрузку всё у меня задвоились даже начисления Оклад, Надбавка…. Получается надо завести в базе, в которую загружаем, те же виды начислений(которых не хватает), что и в загружаемой? И потом просто не помечать на выгрузку.
2) Что делать с дублями номеров документов начислений, ведомостей, ШР? Не будет мешать работе программы? Может до переноса как-то добавить префикс, чтоб по нему различались? Как это сделать при уже созданных документах?

3) А может пометить только документы и регистры, потом связанные с ними позиции по инструкции на Вашем сайте и выгрузить?
4)Вопрос по обработке: не совсем поняла, на что влияют кнопки Отбор для периодических регистров (организация ведет учет с середины 2018,выгружаю весь период), Вместе с документами выгружать их движение (недостаточно, что флажками помечаем на выгрузку и регистры?)
Простите за такое количество вопросов, но как есть. Это не бухгалтерия)) там было проще.

Нет, не получается. Либо всё задваивается, либо Объект не найден, либо точь в точь организация образуется(2 шт в базе) и задвоенная нумерация документов, видов начислений…

Здравствуйте! Плохо, что задваиваются справочники. Получается у них уникальные идентификаторы не совпадают. Например, «Оклад по дням» в одной базе ИД 1, во второй «Оклад по дням» ИД 2. Перегружаем, программа не может их сопоставить и создает второй, либо создает с видом «Объект не найден…».
Тут либо обработку писать, либо пытаться удалить дубли, но справочники ещё можно обработать, но регистры некоторые могут выдать ошибку, да и нумерация документов задваивается. Можно попробовать из задвоенной организации сделать обособленное, подразделение выделенное на отдельный баланс и удалить дубли только справочников, тогда с нумерацией проблем не будет.

Спасибо! попробую вариант из задвоенной организации сделать обособку, а может еще и перевести в основную…

Добрый день! Не смогла. Подскажите, могу ведь выложить это задание на Ваш новый сервис Эксперт24, чтобы найти исполнителя? Я правильно поняла его назначение?

КАК ОБЪЕДИНИТЬ 20 БАЗ 1С:ЗУП В ОДНУ И ДОБИТЬСЯ МИНИМАЛЬНОГО ПРОСТОЯ ПОЛЬЗОВАТЕЛЕЙ

В связи с укрупнением бизнеса возникла необходимость объединения отдельных баз данных в одну. Например, мы в ФТО решали задачу по объединению 20 однотипных (с одинаковой конфигурацией) баз 1С:ЗУП.

Что было на входе?

• 20 организаций с численностью от 10 до 4000 сотрудников.
• У каждой своя 1С:ЗУП Проф 3.1.
• 70 уникальных пользователей, часть пользователей повторялась в разных базах.

Какая перед нами стояла цель?

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

В качестве «инструмента» был выбран механизм синхронизации: «План обмена» + «Правила обмена» + «Универсальный обмен данными в формате XML». Для однотипных конфигураций решение подходило хорошо. НО для баз, в каждой из которых количество сотрудников больше полутысячи и данные ведутся не один год, время выгрузки/загрузки могло растянуться на часы.

КАКИМ ОБРАЗОМ…

Обеспечить минимальный простой пользователей?

Первое, что пришло на ум: а давайте выполнять все работы в нерабочее время. Но нерабочее время заказчика – это, во-первых, и наше нерабочее время как исполнителя, во-вторых, самые большие базы могли занять более 12 часов на выгрузку/загрузку, и мы всё равно не уложились бы в отведенный интервал. Если учитывать, что при объединении баз 1С в простой уходит не только база-источник, но и приемник, при этом в приемнике с каждым последующим объединением количество пользователей и организаций становится всё больше, то простой видится достаточно рискованным.

Что мешает делать объединение на копиях баз 1С?

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

А можно ли «копить» данные и изменения, внесенные пользователями после начала объединения?

Конечно можно! Применили тот же механизм синхронизации с регистрацией изменений в 1С и те же правила обмена данных, которые использовали для основного объединения. И назвали это накоплением «дельты». Объем накопленной «дельты», даже для больших организаций, гораздо меньше, чем основной объем данных, и их загрузка/выгрузка проходит быстро.

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

Для выгрузки мы использовали «Универсальный обмен данными в формате XML» с теми же правилами обмена, которые применяли к основному объединению. Это позволило сэкономить время на разработке отдельных правил.

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

Таки образом прорисовалась определенная схема:

В чем сложность? Добавляем процесс тестирования и приемки пользователями каждой базы/организации и «вуаля» — процесс растягивается на месяца. С учетом загруженности пользователей и важности процессов — это же зарплата — «свободных окошек» в месяце остаются считанные дни. Что же делать?

ОПТИМИЗИРОВАННЫЙ ПОДХОД

В результате «мозгового штурма» мы пришли к идее, которую в итоге и реализовали. Взяли копии всех баз и сделали последовательно основное объединение для всех баз 1С:ЗУП с получением первого варианта консолидированной базы.

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

После подтверждения результата от всех пользователей по всем организациям мы перешли к заливке «дельты». Мы последовательно согласовывали и блокировали для работы пользователей отдельные базы, выгружали оттуда «дельту», разрешали пользователям временно вернуться к работе в отдельной базе, заливали «дельту» в консолидированную базу 1С. Так прошлись по всем базам. Временная работа пользователей в отдельной базе была необходима для непрерывности основных процессов (прием, увольнение, срочный перевод), всё остальное было отложено до окончательного перехода в консолидированную базу.

Все данные, введенные в период временной работы, пользователи затем продублировали в консолидированную базу вручную. По каким-то организациям вообще таких данных не было, по каким-то они были, но в количестве, вполне доступном для быстрого повторного ввода в объединенную базу 1С:ЗУП.

РЕЗУЛЬТАТ

Были ли сложности при реализации? Конечно, были:

• бухгалтеры-расчетчики в «своих» отдельных базах имели роль Администратора. В консолидированной базе 1С:ЗУП доступ должен был остаться только к «своей» организации. Мы оперативно создали профиль «Унифицированный бухгалтер» с урезанными правами;
• встал вопрос: как автоматически при объединении баз разграничить «Группы доступа» по организациям? В правилах выгрузки добавили к наименованию «Группы доступа» наименование организации, из которой переносятся данные. Плюс в ограничение доступа добавили данную организацию. Всё разграничение прав было выполнено автоматически, без каких-либо ручных корректировок;
• одинаковые начисления в разных базах рассчитывались по разным формулам. То есть при объединении нельзя было использовать единый перечень Начислений и Удержаний. В правилах выгрузки мы предусмотрели перенос Начислений и Удержаний из каждой организации с указанием данной организации;
• в стандартном функционале заявление на вычеты НДФЛ в консолидированной базе у сотрудника допускалось только одно в один период времени. У заказчика же один и тот же сотрудник мог числиться работающим в разных организациях одновременно, и вычеты НДФЛ по нему могли быть заведены несколько раз. В правилах выгрузки мы предусмотрели перенос всех документов «Заявление на вычеты НДФЛ», но если на одного сотрудника их было больше одного в один период, то такие документы-дубли переносились непроведенными. Далее пользователи проверяли и удаляли лишне документы.
• обычно при синхронизации переносились только документы, а все движения воспроизводились в базе-приемнике путем перепроведения. Для нас этот вариант не подходил, т.к. все расчётные данные прошлых периодов должны были остаться неизменными. Поэтому мы пошли по пути переноса всех движений документов/регистров «как есть».
• Часть регистров в рамках общей выгрузки/загрузки переносилась некорректно. Это происходило из-за встроенных алгоритмов автозаполнения на основании регистрации данных в других регистрах. Мы их очищали и отдельно повторно переносили.

Со всеми проблемами команда успешно справилась благодаря:

• сплоченности и компетентности, что позволило адекватно и быстро реагировать на запросы Заказчика;
• великолепной внутренней коммуникации – всё оперативно обсуждалось и принималось к реализации;
• пониманию Заказчика по критичности на внесения изменений в рабочие конфигурации и принятия моратория на изменения в период проекта;
• повсеместно заложенной инфраструктуре проекта и оперативной реакции со стороны Заказчика на потребности в серверных ресурсах.

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

• перед стартом подобных проектов провести нормализацию баз, т.е. одинаковые данные в отдельных базах завести одинаково, чтобы при объединении баз их можно было легко сопоставить друг с другом. Например, пользователи во всех базах должны быть заведены по одинаковой маске ФамилияИО. Нормализация баз выполняется, в основном, силами Заказчика, но Исполнитель как минимум может рекомендовать, на какие данные стоит обязательно обратить внимание;
• разработать единую методологию учёта/расчета для объединяемых организаций. Особенно актуально для начислений, удержаний, видов использования рабочего времени. Это необходимо, чтобы настройки, которые действуют для всей системы без разграничения по организациям, были едины. И правила расчета одинаковых начислений/удержаний таким образом тоже должны быть едины.
• выделить отдельное время/ресурс на проработку прав и ролей пользователей. Данный пункт оказывается важным, когда вроде бы в отдельных базах всё хорошо работало, но при объединении начинают провялятся условия и ограничения, очень существенные в рамках консолидированной базы.

Плановая продолжительность проекта составляла 3,5 месяца. В результате возникших нюансов мы запустили проект на 1 месяц позже. Нам удалось объединить 20 баз 1С:ЗУП в одну и добиться того, чтобы простой в работе пользователей был минимальным. Клиент остался доволен уровнем нашего погружения в проблемы и их решением.

Как в 1С объединить несколько баз в одну

Переходим на 1С 8.3, данные по основной деятельности заводим в рабочей базе, а по основным средствам в отдельной базе.

Как в 1С объединить несколько баз в одну?

Оцените, пожалуйста, данный вопрос:

Вам будет интересно

Ирина Шаврова Profbuh8.ru Янв 12 2017 — 17:01

Добрый день!
Я вижу два решения проблемы. , если Вы хотите справиться с решением задачи собственными силами.
1. Поищите в интернете, например, на сайте ИНФОСТАРТ правила конвертации Бухгалтерия 3.- – Бухгалтерия 3.0 для выгрузки данных Вашей неосновной базы в файл XML
Делать это Вы будете по типовой обработке, которая есть в Бухгалтерии 3.0 “Универсальный обмен данными в формате xm”@

Ирина Шаврова Profbuh8.ru Янв 12 2017 — 17:05

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

Ирина Шаврова Profbuh8.ru Янв 12 2017 — 17:07

2. Можно попробовать вариант с обработкой “Выгрузка и загрузка данных xml”, что есть на диске ИТС. Но тут конфигурации выгружаемой базы и загружаемой должны быть одного релиза. Кроме того в этом случае не всегда все проходит 100% корректно, некоторые предопределенные элементы могут задваиваться. Но это самый простой способ. Можно начать с него. Но сразу говорю, что эта обработка не совсем для этих целей, поэтому нужно смотреть