КАК ОБЪЕДИНИТЬ 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С:ЗУП в одну и добиться того, чтобы простой в работе пользователей был минимальным. Клиент остался доволен уровнем нашего погружения в проблемы и их решением.