Объединить две базы ЗУП в одну
Здравствуйте.
Есть две базы 1С ЗУП. Типовые. В одной базе одна организация и в другой базе одна организация. Сотрудники из первой базы через реорганизацию присоединением переходят в организацию из второй базы. Через кадровый перевод просто. Соответственно нужно перенести сотрудников со всеми их начислениями, удеражаниями и прочим из одной базы во вторую. (как буд-то они у нас всегда работали во второй базе просто в отдельном подразделении, а кадровики уже с нужной даты их переведут в основное подразделение). Разумеется нужно, чтобы считались правильно налоги, средний заработок, больничные и все остальное.
От вас срок, стоимость (не за час) и почту или мессенджер для контактов. Сделать нужно максимально быстро — базы для переноса готовы.
Спасибо.
КАК ОБЪЕДИНИТЬ 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С
- ISO 9001:2015
- Карта сайта
- Наши услуги
- Внедрение решений на 1С
- Поддержка пользователей 1С
- 1С:Документооборот
- Ускорение производительности 1С
- Системы для бизнес-анализа (BI)
- Аналитика SimpleHR
- Комплексное обслуживание 1С
- Доработка конфигураций 1С
- Переход с 1С:УПП на 1С:ERP
- Переход на новый 1C:ЗУП 3.1
Объединение двух баз
Добрый день!
Организация имеет 3 обособленных подразделения не на отдельном балансе (территориально находились в разных районах). Подразделение 1 и 3 работали в одной базе1, подразделение 2 работало в базе2. Теперь появилось желание работать в одной базе через Линк. Надо объединить обе базы.
1) Возможен ли перенос через обработку ВыгрузкаЗагрузкаXML? Тогда наверное, необходимо, чтобы в обеих базах были идентичны Наименование организации, структура подразделений, ШР, настройки расчета зарплаты….? А потом перенести документы обработкой.
2) Только дописывать.
3) Вариант, которого я не знаю.
Спасибо!Обсуждение (8)
Мадлен Подписчик БухЭксперт8 :
1) Объединение организаций в ЗУП 3.1 при реорганизации (слияние, присоединение) этот вариант конечно интересный, но не наш случай, т.к. переводов не надо делать, просто соединить подразделения. Изначально надо было просто вести все 3 подразделения в одной базе.
2) Объединение несколько баз в одну. и по цепочке Переход на ЗУП 3.1 можно применить уже на этапе поиска дублей физ лиц, которые когда-то переводились и подразделения 2 базы 2 в подразделение 1/3 базы 1.Елена Пьянкова Сотрудник БухЭксперт8 :
Здравствуйте! Я бы остановилась на варианте использования обработки «Выгрузка и загрузка данных в формате xml» — Выгрузка в 1С из xml: как выгрузить данные из 1С 8.3 и загрузить в 1С 8.3 . Если будут дубли, потом их удалите с помощью штатной обработки «Поиск и удаление дублей» (раздел «Администрирование — Обслуживание — Корректировка данных»). Есть нюанс с номерами документов и регистрами, где значения повторяться не могут, но здесь уже нужно будет смотреть по конкретным ошибкам, как их исправить, может их и не будет вовсе.
Мадлен Подписчик БухЭксперт8 :
1)я экпериментально пометила на выгрузку всё у меня задвоились даже начисления Оклад, Надбавка…. Получается надо завести в базе, в которую загружаем, те же виды начислений(которых не хватает), что и в загружаемой? И потом просто не помечать на выгрузку.
2) Что делать с дублями номеров документов начислений, ведомостей, ШР? Не будет мешать работе программы? Может до переноса как-то добавить префикс, чтоб по нему различались? Как это сделать при уже созданных документах? Спасибо! 3) А может пометить только документы и регистры, потом связанные с ними позиции по инструкции на Вашем сайте и выгрузить?
4)Вопрос по обработке: не совсем поняла, на что влияют кнопки Отбор для периодических регистров (организация ведет учет с середины 2018,выгружаю весь период), Вместе с документами выгружать их движение (недостаточно, что флажками помечаем на выгрузку и регистры?)
Простите за такое количество вопросов, но как есть. Это не бухгалтерия)) там было проще.Мадлен Подписчик БухЭксперт8 :
Нет, не получается. Либо всё задваивается, либо Объект не найден, либо точь в точь организация образуется(2 шт в базе) и задвоенная нумерация документов, видов начислений…
Елена Пьянкова Сотрудник БухЭксперт8 :
Здравствуйте! Плохо, что задваиваются справочники. Получается у них уникальные идентификаторы не совпадают. Например, «Оклад по дням» в одной базе ИД 1, во второй «Оклад по дням» ИД 2. Перегружаем, программа не может их сопоставить и создает второй, либо создает с видом «Объект не найден…».
Тут либо обработку писать, либо пытаться удалить дубли, но справочники ещё можно обработать, но регистры некоторые могут выдать ошибку, да и нумерация документов задваивается. Можно попробовать из задвоенной организации сделать обособленное, подразделение выделенное на отдельный баланс и удалить дубли только справочников, тогда с нумерацией проблем не будет.Мадлен Подписчик БухЭксперт8 :
Спасибо! попробую вариант из задвоенной организации сделать обособку, а может еще и перевести в основную…
Мадлен Подписчик БухЭксперт8 :
Добрый день! Не смогла. Подскажите, могу ведь выложить это задание на Ваш новый сервис Эксперт24, чтобы найти исполнителя? Я правильно поняла его назначение?
Объединение двух организаций в одну базу
Здравствуйте уважаемые эксперты. Возникла задача объединить две организации (ЗУП одинаковой конфигурации) в одну базу. Выгружаю данные из одной базы через внешнюю обработку Выгрузка и загрузка данных XML. Загружаю в другую, все вроде бы подгружается и документы вроде бы все и в них сотрудники есть, но в списке сотрудников организации подгружаемой пусто. При попытке перепровести документ ПриемНаРаботу он проводится (но в списке сотрудников организации сотрудник не появляется), а любой другой кадровый (перевод увольнение…) пишет что сотрудник не работает в организации … что я делаю не так?
Метки вопроса: Перенос данных из других программ
Обсуждение (19)
Елена Пьянкова Сотрудник БухЭксперт8 :
Здравствуйте! Есть предположение, что в справочнике «Сотрудники» не заполнено поле «Головная организация». Можно ан копии базы попробовать с помощью встроенной обработки «Групповое изменение реквизитов» её проставить. Только предварительно нужно в справочнике «Сотрудники» установить отбор, исключающий первую организацию, чтобы нам у всех сотрудников в базе одинаковую организацию не поставить.
Видео с примером высылаю:al_p Подписчик БухЭксперт8 :
нет, к сожалению это не помогло… Сотрудники так и не появляются…
за появление сотрудников отвечают регистры сведений…(ДанныеДляПодбораСотрудников и еще несколько) я хотел тащить их по минимуму . но видимо не получится…al_p Подписчик БухЭксперт8 :
Решил перетащить вообще все… причем срезы не помогли, пришлось тащить все за весь период…худо, бедно документы и Сотрудники по затягиваемой организации появились… но беда с задвоением справочников, беда с отчетами … с чего они пропали и как восстановить, пока не ясно
Елена Пьянкова Сотрудник БухЭксперт8 :
Добрый день! Да, при перегрузке данных по организации, когда перегружаем все документы, лучше всего выбирать все регистры, иначе есть риск, что что-то потеряем.
По отчетам, возможно галочки слетели. По кнопке Ещё — Сбросить мои настройки их можно восстановить:
Или по кнопке «Настройка» вручную:
al_p Подписчик БухЭксперт8 :
в том то и дело что галочки некуда ставить! и в полном списке отчетов пусто… И это только на этапе после загрузки справочников и документов… регистры позже гружу…
Елена Пьянкова Сотрудник БухЭксперт8 :
Иногда бывают проблемы с константами, если чистая база создается не из шаблона поставки, а из файла .cf.
Можно попробовать запустить встроенную обработку «Начальная настройка программы» и прощёлкать до конца и нажать «Применить настройки». При этом проверить, все ли необходимы для работы галочки установлены.al_p Подписчик БухЭксперт8 :
Большое спасибо за быстрый ответ!
я объединял не в чистую базу, а к одной действующей, присоединял вторую действующую, которая в дальнейшем должна слиться с первой… до загрузки данных справочников и документов список отчетов был нормальным( привожу на рисунке). после загрузки — список пропал…
«Начальная настройка…» не помогла… Видимо какой то справочник все портитЕлена Пьянкова Сотрудник БухЭксперт8 :
Ещё можно посмотреть справочник «Предопределенные варианты отчетов». В справочнике заходим справа в меню Ещё — Установить стандартные настройки.
Елена Пьянкова Сотрудник БухЭксперт8 :
Также есть вариант, что при загрузке данных, что-то случилось с правами пользователей. Т.е. у данного пользователя просто нет прав на эти отчеты. Ещё не стоит исключать ошибку с временными файлами, можно почистить программный кэш (удалить базу из списка и добавить вновь) и пользовательские настройки удалить (раздел Администрирование — Настройки пользователей и прав — Персональные настройки пользователей — Очистки настроек).
Елена Пьянкова Сотрудник БухЭксперт8 :
Ещё иногда помогает запуск обновления базы через параметр «/с запуститьобновлениеинформационнойбазы»:
Или обновление платформы.
al_p Подписчик БухЭксперт8 :
Елена, а запуск с ключом обновлениеИБ, после всех зачисток помог! восстановил все списки отчетов. Спасибо Вам большое!
al_p Подписчик БухЭксперт8 :
Большое спасибо Елена!
С правами — действительно беда… пользователи задваиваются, права отпадают. У пользователя под которым делаю слияние очищаются все права, вплоть до запуска клиента… Пользователей почистил права додал. настройки пользователей тоже почистил — не помогло. Кеш зачищал, базу пересоздаю по несколько раз на дню…
Взялся за справочник Предопределенные настройки отчетов… там более 200 дублей образовалось.. после зачистки в кадровых отчетах с пяток отчетов в списке появилось…
Сейчас попробую не выгружать этот справочник из первой базы…al_p Подписчик БухЭксперт8 :
Попробовал не выгружать справочник Предопределенных настроек отчетов… Не помогло.
Елена Пьянкова Сотрудник БухЭксперт8 :Добрый день! Я бы обработкой «выгрузка и загрузка данных xml» перенесла бы все объекты, а потом с помощью встроенной обработки «Поиск и удаление дублей» попробовала бы их найти и удалить.
Есть ещё вариант настроить РИБ (распределенную информационную базу) и с помощью неё попробовать перенести. Но этот вариант не пробовала, надо проверять.al_p Подписчик БухЭксперт8 :
Здравствуйте! Ну я так и делаю , выгружаю все а потом борюсь с дублями… но доверять такой базе в дальнейшем как то уже не хочется…
РИБ я никогда не пробовал и , честно говоря , даже не знаю как подступаться к этому…Елена Пьянкова Сотрудник БухЭксперт8 :
При перегрузке данных из КА 1.1. в БП 3.0. внешними обработками я столкнулась с тем, что в программе могут задваиваться предопределенные элементы. Происходит это из-за того, что у записей разные уникальные идентификаторы в разных базах. Причем удивительно, то что в пределах одной конфигурации это тоже может происходить.
Однажды обработкой «выгрузка и загрузка данных xml» я догружала данные по одной и той же организации после перехода на ЗУП 3.1. с ЗУП 2.5. Просто пользователь сразу не перешел на новую базу, пришлось делать дозагрузку. В принципе проблем особых не было (производственный календарь задвоился). Я его удалила обработкой «Поиск и удаление дублей». Но у меня изначально одна организация была , поэтому в большинстве идентификаторы совпали.Елена Пьянкова Сотрудник БухЭксперт8 :
Пожалуйста! Рада была помочь! ?
Елена Пьянкова Сотрудник БухЭксперт8 :Вообще мне не очень нравится вариант с объединением баз ЗУП, т.к. не удобно работать когда в базе несколько организаций. В 1С:Бухгалтерии этот механизм реализован лучше, но там тоже есть свои минусы, например, если происходит смена собственника и нужно предать базу другим, то приходится удалять данные по другим организациям из базы. Это бывает не просто сделать.
al_p Подписчик БухЭксперт8 :
Здравствуйте! мне тоже не нравится объединять в одну базу несколько организаций… Но тут происходит слияние, и нужно обеспечить перевод без увольнения…Вот я и изгаляюсь… Объединяю, делаю вторую подразделением, обрабатываю справочники, документы перепровожу и затем делаю перевод сотрудников из подразделения в основную организацию…
С удалением данных по организации у меня уже проблем нет… есть обработки которые все вычищают…