Как объединить 2 базы 1с в одну
Перейти к содержимому

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

  • автор:

Способы интеграции баз 1С между собой. Что выбрать

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

КД2

В случае внутренней интеграции (база 1С — база 1С), выбор инструментов не столь уж большой. И первый из них это продукт под названием Конвертация данных, редакция 2, сокращенно КД2.

Он представляет собой отдельную конфигурацию и для того, чтобы им воспользоваться вы разворачиваете отдельную базу. Затем вы идете в базу-источник, в пользовательский режим. Запускаете там обработку, которая прочитает конфигурацию базы и сохранит ее в файл. Потом идете в базу-приемник. В ней проделываете то же самое. Далее идете собственно в базу КД2. Загружаете из файлов, полученных на предыдущих шагах две конфигурации. Вы еще не устали? Ничего, скоро нас ждет награда. Еще несколько нажатий на кнопки. Говорим, что у нас будет источником, что приемником и, наконец, даем команду создать нечто, называемое правилами обмена. Теперь, когда у нас есть эти самые правила, мы можем запустить внешнюю обработку под названием «Универсальная выгрузка, загрузка данных xml», указать файл правил и заняться собственно выгрузкой, а затем загрузкой данных. И данные (о чудо!) действительно попадут из одной базы в другую.

В чем плюс КД2? Вы не вникаете досконально в структуру данных. В чем минус? . вы не вникаете досконально в структуру данных. Изначальная идея была вполне себе годной. Создать low code инструмент. Но сделать это оказалось не так-то просто. Вот несколько цитат со знаком «+» и со знаком «-«.

Как-то видел человека, который долго и дорого писал правила ЗУП-ЗУП. Вроде бы из четырех баз ЗУП надо было положить в одну — что там такого, да? Но месяц правила писались, были написаны на половину, отлажены вообще не были. Я за три дня написал код, который делал вот только это и ничего больше. Потом оказалось, что есть совместители, которые уже в одной из этих баз на постоянке. При том совместитель устроился раньше, чем на постоянку. Потом внешние и внутренние, а нельзя быть одновременно тем и этим. Ну и дальше множество нюансов, которые на КД2 я вообще не представляю, как пришлось бы делать, ибо пакеты приезжают одновременно из четырех баз в одну, и они друг с другом связаны.

Обмен между идентичными базами пилится минут за 10:1) Формируется описание конфигурации.2) Загружается в КД21.3) Создаём правила, где источник и приёмник — одна и та же конфа. Отвечаем «да» на вопрос об автоматическом создании ПКО.Ровно ноль строк кода.Я думаю, ни в 25, ни в других постах противоречий нет — писать код там, где можно обойтись без кода — это глупо, но всегда возможно.

У меня клиенты малые и очень. И типовые решения 1с (базовые версии) используются ими процентов на 10-20. Железо не новое. Когда начал настраивать типовой обмен Розница и БП3, время и громоздкость первоначальной настройки (сопоставление объектов и проч.) разочаровала. А нужна была только выгрузка базы товаров, установки цен, поступлений (возвратов) и продаж. Сделал свое. Публикация здесь на ИС. Работает. Есть у меня знакомые бухгалтера-аутсорсеры я им сделал удаленный доступ к базам клиентов, 2 обработки, выгрузка и загрузка. Никаких настроек. Выгружают, загружают раз в месяц/квартал, чтобы посчитать налогооблагаемую базу. Время на основную идею потратил 2 дня по 4-5 час, я не чистый программист, бывает месяцами ничего не программирую. Тут в новостях узнаю, что вместо Розницы 2 будет 3, у кого штатный обмен — опять придется планы обмена настраивать. А я потрачу 1-2 часа на доработку, и далее будет работать

Между идентичными конфигурациями за рабочий день я нарисую столько правил, сколько позволит по времени выгрузить\загрузить метаданные. Как писали ниже, просто берешь нужные объекты и автоматически создаешь ПКО, КД всё делает корректно. Между УТ-БП БП-УТ естественно дольше.

Я без труда наберу вам еще с десяток и в ту, и в другую группу. Похоже, что мнения специалистов разделились примерно поровну. И это верный признак, что что-то пошло не так.

Когда у вас идентичные конфигурации и документы переносятся один к одному, то тут, да, возникает магия low code. Но если ситуация хоть чуть сложнее, например, документ одного типа в источнике превращается в документ другого типа в приемнике, тогда код писать все равно придется. Этот ваш код попадет в тот самый xml файл правил обмена (и это прелестно!), но прежде вам предстоит усвоить целый ряд новых понятий: правило конвертации объекта, правило конвертации свойства и т.д. А после этого вам надо будет придумать способ отлаживать код, который оказался в xml файле. И все это непонятно ради чего.

Ситуации с обменом бывают всякие. Но очень редко когда это что-то совсем простое или что-то по настоящему сложное. Чаще всего надо запрограммировать какую-нибудь ерунду. Это-то и раздражает специалиста, который посреди процесса вдруг осознает, что если бы он не пытался в low code, а пошел обычным путем, то он бы уже давно все сделал.

КД3

Конвертация данных редакция 3 подается как отдельный продукт, который не заменяет, а дополняет КД2. Оно и понятно. Натерпевшись с КД2, люди не спешат от нее отказываться. Только научились отлаживать код внутри xml, а тут оказывается, что нет ничего ценного в этом навыке. Так не пойдет!

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

Кроме этого, процесс обмена разделен. Выгрузка отдельно, загрузка отдельно. И это, кстати, тоже правильно. Далее, в КД3 решили пусть будет некий единый формат данных для обмена под названием ED (Enterprise Data). В этом есть свои плюсы. Выгрузка отделяется от загрузки во всех смыслах. Их могут вообще две независимые команды делать. Если что-то поменялось в конфигурации источника(приемника), то переделываем не все, как это было с КД2, а только часть. Кроме того, и базой-источником и базой-приемником теперь может быть не только база 1С, а какая-нибудь другая база. Т.е. КД3 можно рассматривать как универсальный инструмент. Он подойдет как для внутренней, так и для внешней интеграции.

Все было бы замечательно, но. XDTO. Именно это используется для создания Enterprise Data. XDTO (XML Data Transfer Objects) это еще одна концепция, рожденная в недрах 1С. С целью покорить если не весь мир, то хотя бы сердца 1С-ников. Но, как и в случае с low code, создать удачный формат не так-то просто. Вот формат скобка фигурная, скобка квадратная (JSON) он действительно покорил мир. Потому что решает реальную проблему минимально необходимыми средствами. А с XDTO проблема даже не в том, что сложно. А в том, что непонятно — ради чего. Ради того, чтобы оперировать не узлами и атрибутами, а свойствами объектов? Ну спасибо! Но если дело дошло до дела, и я начал кодировать, то мне, в принципе, все равно. Сложность работы нисколько не уменьшается. Только появляется дополнительное нечто, во что надо въезжать

Простой способ

Если вдуматься, то от инструмента, помогающего нам организовать обмен данными, надо не так уж и много. Освободить нас от монотонного переписывания:

В типовых конфигурациях сейчас реквизитов ну очень много. И табличных частей тоже. Надо ничего важного не пропустить при переносе данных. Настоящий low code, это когда мы без изучения каких-либо дополнительных понятий и концепций получаем заготовку кода для выгрузки(загрузки) в базе источнике(приемнике), в которой будут все отмеченные нами объекты, реквизиты, табличные части. В этой заготовке должен быть минимум необходимого для обмена. Выборка из плана обмена, сериализация в JSON или XML в правильном порядке (группы раньше элементов) для выгрузки. Для загрузки это будет поиск объектов, чтобы изменять существующие и создавать не существующие. Минимальная заготовка будет легко читаться и столь же легко дополняться. Такого рода инструменты имеют хождение среди специалистов.

Заключение

Что использовать? Зависит от ситуации. Стоит обзавестись некоторым минимумом знаний и по КД2 и по КД3. Возможно, что ваш обмен будет частью чего-то большего. И в этом большем уже основательно завязались на XDTO. Но если перед вами не поставили жесткого требования делать обмен по КД2 или КД3, тогда лучшим решением будет воспользоваться инструментом для получения заготовки кода. Исключением может быть случай, когда действительно все совсем просто. Конфигурации однотипные и обмен один в один. Тогда КД2 сэкономит вам время.

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

Объединение несколько баз в одну.

Доброго времени суток.
1С, Версия ПРОФ,ЗУП 3.1,
С июля решили объединить четыре базы ЗУП в одну
1 Организация 400 человек, 13 обособленных подразделений, на ОСНО.
2 Организация 300 человек на ОСНО
3 Организация 60 человек, 2 подразделения на ОСНО.
4 Организация 20 человек на УСН.
Можно узнать у Вас плюсы и минусы объединения?
Как лучше протестировать объединенную базу на наличие ошибок и на что обратить внимание ? Может быть нужно будет вести учет параллельно в раздельных базах и объединенной?
Спасибо.

Все комментарии (1)

Ольга Горшенина Сотрудник БухЭксперт8 :

Здравствуйте! Особенностью ведения учета нескольких организаций в одной базе является то, что в этом случае справочники становятся едиными для всех организаций. Например, справочники «Физических лиц», «Должности», «Способы отражения зарплаты в бухучете» и т.д. Настройки «Начислений» также становятся едиными для всех организаций. Также стоит обратить внимание на технические моменты. Файловый вариант баз скорее всего уже не подойдет, необходим будет клиент-серверный вариант. Перед переносом данных в ЗУП 3 рекомендуется базы протестировать. С какими сложностями Вы можете столкнуться в процессе объединения можно посмотреть в данном обсуждении — Переход на ЗУП 3.1

Как объединить две базы 1С в одну – практическое руководство для пользователей

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

1С – одна из самых популярных программ, которая помогает автоматизировать управление бизнес-процессами. Благодаря её возможностям, можно легко справляться с задачами учёта, управления закупками и продажами, налогового учёта и другими важными процессами. Однако, порой возникают ситуации, когда нужно объединить две базы 1С в одну.

Это может быть вызвано разными факторами – от изменения компании и перехода на другие подразделения, до пересмотра стратегии управления базами данных. Как бы то ни было, основная трудность, при объединении баз, заключается в том, чтобы сохранить всю необходимую информацию, не потерять ничего важного, и при этом гарантировать правильную работу программы. В этой статье мы дадим рекомендации, как это сделать.

Шаг 1: Создание резервной копии баз данных.

Первое, что нужно сделать перед объединением баз 1С – это создать резервную копию каждой базы. Это позволит сохранить всю необходимую информацию в случае возникновения каких-либо непредвиденных обстоятельств.

Шаг 2: Определение объема информации.

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

Шаг 3: Объединение данных.

После того, как вы определились с объемом информации, можно приступать к объединению. Для этого нужно открыть программу 1С и выбрать “Файл” > “Импорт из файла”. Затем нужно выбрать нужный файл с дополнительными данными и выполнить импорт.

Шаг 4: Проверка корректности.

После объединения баз, важно провести проверку на корректность. Для этого можно воспользоваться инструментами программы 1С, чтобы обнаружить какие-либо ошибки в работе. Если их нет, значит, все прошло успешно.

Шаг 5: Окончательная проверка.

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

В заключение, объединение двух баз 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С:ЗУП в одну и добиться того, чтобы простой в работе пользователей был минимальным. Клиент остался доволен уровнем нашего погружения в проблемы и их решением.

Поделиться: Вконтакте
Спасибо за заявку! Мы перезвоним вам в ближайшее время. Подписывайтесь на нас в соцсетях

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *