Объединение нескольких баз БП 3.0 в одну
Поделитесь, пожалуйста, опытом — как объединить две базы в одну для ведения многофирменного учета.
Какой порядок действий? Как свернуть базы за старые периоды и ввести начальные остатки в объединенной?
Может кто-то правилами обмена поделится или ссылочек на полезные статьи покидает.
Просьба не ругать ))
(0) Проще сделать всё вручную.
Взять за основу одну из двух без и ручками занести в неё начальные остатки по другой.
Автоматизировать можно перенос некоторых справочников.
При больших объемах данных придётся писать свои правила конвертации.
Проблемы возникнут при синхронизации всей НСИ, которая является общей для всех организаций в базе.
Справочники.
— Номенклатура
— номенклатурные группы
— склады
— контрагенты
— статьи затрат
— статьи доходов и расходов
Следом пойдут все регистры, касающиеся учетной политики. Правила распределения затрат, например.
Если есть различия в учете НДС. Если одна контора на обычном НДС, а другая на раздельном, то включение раздельного учета там, где его не было, или перенос остатков из базы где, был обычный НДС, в базу, где он раздельный, становится нетривиальной задачей.
Отдельный геморрой — настройка синхронизаций со сторонними БД (УТ, ЗиУП), если таковые есть.
(4) Конфигурации — типовые БП 3.0 Проф.
Объемы баз не такие большие, как Вы приводите. гораздо меньше ))
Как создавались базы я не в курсе, но думаю, что отдельно.
(6), (8) Учет по нескольким организациям. (9) все правильно ответил.
(0) Делюсь опытом.
1. Определить дату перехода. В 99% случаях — это 1 января следующего года. в 1% — начало следующего квартала (если прям сильно припекает объединиться)
2. Определить мастер базу. То есть ту в которой учет будет вестись по прежнему. Другую фирму будем загружать в мастер базу. Обычно основными критерием являются.
а. Объем планируемых к переносу объектов — элементы справочников + остатки.
б. упорядоченность справочников (иногда имеет смысл в качестве мастер базы взять наоборот базу с минимальным количеством объектов, а в базе которую переносим — на этапе переноса избавиться от накопившихся неиспользуемых элементов справочников.
в. особенности бизнес процессов. Например при слиянии оптовой компании с огромным документооборотом и сервисной космпании, которая выставляет в конце месяца 100 документов на услуги — конечно имеет смысл присоединять сервисную компанию
г. Иногда стреляет иерархия бухгалтерий — поскольку для базы реципеиента практически ничего не меняется. а весь геморрой сваливается на пользователей базы донора — то выбор может быть волюнтаристским и зависит от степени взаимодействия ГБ и ЛПР.
3. Максимально подготовить справочники, отсортировать лишние элементы, провести сопоставление элементов справочников.
4. Выполнить перенос справочников и остатков в мастер базу в документы "Ввод начальных остатков".
Начать работать.
Проводить регулярную актуализацию остатков и справочников — в течение 2-3 месяцев — пока в старой базе не будет закрыт год и сдан баланс.
В зависимости от количество объектов переноса (элементов справочников, остатков) рекомендуется
1000 — 10000 объектов — перенос руками, актуализация руками.
10000-100000 объектов — разовый перенос КД. Актуализация руками
свыше 100000 — перенос с последующей периодической актуализаций элементов справочников и остатков. Выбор инструмента зависит от степени мастерства и накопленного экспириенса — можно КД, можно СОМ.
Но надо понимать что при большом количестве объектов универсальный ХМЛ начинает существенно уступать в скорости.
У меня был кейс когда мне нужно было объединить 2 базы в которых было 50000+ элементов номенклатуры, причем совпадавшей примерно на 60-70 %, потому что за 5 лет до этого фирмы были разделены из одной общей базы.
СОМ загрузка справочника занимала примерно 4-6 часов. тестовую ХМЛ выгрузку я сбросил на вторые сутки
Объединение двух баз
Добрый день!
Организация имеет 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, чтобы найти исполнителя? Я правильно поняла его назначение?
Как в 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% корректно, некоторые предопределенные элементы могут задваиваться. Но это самый простой способ. Можно начать с него. Но сразу говорю, что эта обработка не совсем для этих целей, поэтому нужно смотреть
КАК ОБЪЕДИНИТЬ 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С:ЗУП в одну и добиться того, чтобы простой в работе пользователей был минимальным. Клиент остался доволен уровнем нашего погружения в проблемы и их решением.