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

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

  • автор:

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

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

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

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

(5 оценок, среднее: 4,60 из 5)
Зарегистрированным пользователям доступны более 300 видеоуроков по работе
в 1С:Бухгалтерия 8, 1С:ЗУП

Зарегистрированным пользователям доступны более 300 видеоуроков по работе
в 1С:Бухгалтерия 8, 1С:ЗУП

После регистрации на указанный адрес Вы получите ссылку на просмотр более 300 видеоуроков по работе в 1С:Бухгалтерия 8, 1С:ЗУП 8 (бесплатно)

Войти в кабинет

5 4_1

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

Дата публикации: Янв 12, 2017
Поделиться:
Поставьте вашу оценку этой статье:
(5 оценок, среднее: 4,60 из 5)
Размещено пользователем:
Все комментарии (3)
Ирина Шаврова Profbuh8.ru Янв 12 2017 — 17:01

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

4_1

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

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

5

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

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

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

если конфы одинаковые, то выгрузкой-загрузкой xml можно

но задвоятся все справочники..

(0) По-хорошему надо перекинуть из первой базы во вторую только то, чего там (во второй) нет.
(2) Пробую универсальный обмен данными. Там для выгрузки требует правила обмена.

(4) Конвертацию в руки и вперед 🙂

Пол дня займет, примерно.

(0) А такой вопрос, нахрена?

Я наоборот, разделял.

(5) Видимо придется. Просто надеялся, что кто-то такое уже делал.
(4) ну пробуй, че
(6) Бухгалтерия хочет объединить, им удобнее в одной.
(7) Ну я делал, я, и что? Правила все равно устарели. Проще новые нарисовать.
(1) еще как нужны. без правил будет огромная попа
(9) Когда покупают очередную объединенную кучу ***на, я матерюсь так, что на весь офис слышно.

Со справочниками непонятно. Если например Наименование совпадает, а какой-нибудь реквизит отличается, надо же переносить с задвоением.

(7) Учти, если есть ручные корректировки в проводках, то надо переносить с движениями (вообще лучше все переносить с движениями, мало ли как менялись механизмы).

Переноси документы, остальное по ссылкам.

Очень осторожно с полями поиска, а то будешь разгребать дубли лопатой.

И периоды скорее всего нужно будет перезакрывать.

В общем, лучше переубеди бухов 🙂

(13) не какой-нибудь реквизит, а один из ключевых реквизитов
(13) Ага, ту надо много думать 🙂

Типа так (2), потом поиск и удаление дублей, по-моему через КД примерно так же будет по результату, но тут полдня работы или день чаепития,

А документы при совпадении номеров как переносить?
(13) много думать с годами всё тяжелее 🙂
(18) так организации же разные?
(18) Префиксы.
(19) Переубеди бухов 🙂 Угрожай, шантажируй 🙂
чтобы ничего не перезакрывать, можно всё перенести временным рибом, а потом дубли заменить
(24) А если бублей минога-минога?
(22) возможно так и сделаю

(0) если в базе старые данные есть то лучше переубедить бухов до НГ, там сверку базы можно и предыдущий год оставить, если что ручками поправить, в одной базе обработкой поменять префиксы доков, потом выгрузка загрузка данных хмл — поиск удаление дублей и готово

(25) а какая разница? их всё равно обьединить только вручную можно
(24) можно подробнее. как из обычной базы сделать временно распределенную.

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

если префиксов сейчас нет, и будут ошибки из-за неуникальности номеров, то надо создавать префиксы

(24) Не, перезакрытие можно использовать как инструмент шантажа!
(28) Ну вот, а если правила писать, то можно поизвращаться с полями поиска и бублей будет мало.

(30) ЕМНИП, как только в бухе заводишь вторую организацию, автоматом включается механизм разделения (префиксы и т.д.)

А вего случает да, нужна перенумерация с префиксами.

(29) открываешь будущую периферию, загружаешь cf из будущего центра, заполняешь план обмена, включаешь периферию, регистрируешь все объекты, делаешь обмен

в итоге центр остаётся залоченным и с данными двух баз

(32) так это тебе работать придётся, а так бузи будут работать

(33) я помню еще в мохнатом 2006 году мне рассказывали, что в БП 8, даже если одна организация в базе, нужно указать префикс. Потому что потом может стать более одной организации

Задвоится — это однозначно. А если все это будет делаться не одновременно, то и затроится. Типовые решения не позволяют объединить две базы в одну без больших проблем. Формально объединить можно, но работать все это не будет. Если конфигурации одинаковые, то и базы не очень большие, то за неделю можно объединить не типовыми обработками.

ну если префиксов нет, то надо их включить, но без перепроведения доков
(23) И план счетов должен быть одинаковый (всякие там субконто).
(35) И получаешь полностью задвоенные данные справочников, а может быть и план счетов.
Конфигурации одинаковые. А вот субконто могли и добавить где-нибудь в режиме Предприятие.

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

И некоторые настройки.

Например: «Учет расчетов с персоналом»

(42) Иди, пугай бухов 🙂
С учетом того, что у человека Бухгалтерия 3.0, то в этой каше никто никогда не разберется
(43) Настройки учета для каждой организации свои вроде. Нет общих констант для всех организаций.
(41) план счетов не задвоится, а справочники в любом случае задвоятся, кроме предопределённых

(38) Не так сложно, как кажется, но и не так просто 🙂

Когда я делал консолидацию (60 в 1), пришлось приводить базы в примерно одинаковый вид (план счетов, настройки и т.д.)

В общем, возможно, если очень надо 🙂

(47) И некоторые настройки.

Например: «Учет расчетов с персоналом»

(47) я о настройках плана счетов — наличии субконто на некоторых счетах.

(46) Вдумчивые правила рулят. Но еще раз, это если ОЧЕНЬ надо 🙂

ИМХО, «бухам удобнее» не относится к «ОЧЕНЬ надо» 🙂

(45) Пугать — бесполезное дело.
Ответ будет стандартный: «вы-ж программист, а не мы. Вот и сделайте, чтоб не задваивало.»
И останется только утереться.

После обновления релиза, правила придется пересматривать видимо.

Я в свое время соединял данные при переходе из из нескольких баз бухгалтерии 1с77 в одну БП2. Пришлось разрабатывать специальные алгоритмы работы КД2 (учить ее синхронизации по GUID) между 1с77 и 1с8. Делать промежуточную синхронизацию баз 1с77. Ну и переносить начальными остатками с началала года.

(53) Смотря как напугать 🙂

Если в перспективе замаячит перезакрытие всех периодов, разгребание дублей и минога дней ковыряния в оборотках, две базы не такое уж неудобство 🙂

Мои работают в 10 каждый и не жужжат 🙂

Пусть пообещает что-нибудь заавтоматизировать, если не будут ныть 🙂

А у (0) могут задвоится все классификаторы
(54) Смотря что изменят. Но это не страшно, если ты уже написание и отладку пережил 🙂
(57) вот у классификаторов убрать задвоения как раз не проблема

(56) +53 это — женщины, и разговаривать с ними «ДО» — пустая трата времени. Они не знают, что надо сделать, и знать не хотят. А вот «После» — только держись! Умные — аж оторопь берёт.
Пытался я составить что-то типа ТЗ лет 40 назад, пошел к ГБ, договорившись о рандеву, поспрошал, и получил в конце: «МНЕ надо, чтобы я нажала кнопку, и 5-й отдел принёс мне готовый расчет зарплаты!». Точка.
А сотров-то у меня в базе было 2500..

(60) Ну может у ТС не такие 🙂

(60) он же не будет сразу на рабочей базе делать, а вариант с рибом практически без трудозатрат, если конечно не сидеть и не втыкать в монитор

+(62) завтра покажет им результат
Ну, Бог ему в помощь.
(64) там даже думать не надо, что несомненный плюс — голова не заболит
Да, РИБ — неожиданный вариант.. А ведь может и прокатить.

(66) и что риб решит проблему сопоставлений например обьектных данных если разные гуиды? Тут имхо толко правила конвертации и вдумчиво писать в ПКО поля поиска а то с дублями огребешь маманегорюй

(66) у говорили ведь. Дофига и более дублей возникнет. Потом будут полгода разгребать.

Короче можно без проблем и дублей слить две базы Бухгалтерия с разными Организациями в одну. Необходимым и достаточным условием успешного слияния являются:
1. Одинаковый релиз двух баз.
2. Одинаковый план счетов
3. Корректно заполненные ИНН Организации и Контрагентов
4. Синхронизованные справочники Номенклатура по Артиклу/Коду/Наименованию.
Если признаться были большие сомнения, что это возможно. Но здесь неожиданно по работе привалилась такая же задача. Необходимо слить в одну базу две базы УТ10 (переработанные). При этом базы не синхронизованы по GUID и частично синхронизованые по ИНН, артикулу, наименованию.
Написал универсальный перенос информации между одинаковыми базами по ОЛЕ и все работает. Единственный минус — быстродействие. Благодаря многолетним усилиям, 1С практически убила механизм ОЛЕ. Примерно 80% времени занимает операция ЭлементОЛЕ.Метаданные(). До этого 90% времени занимало определение ТИпа и вида элемента ОЛЕ. Сейчас средняя скорость объединения двух баз — 5сек/документ. С такой же задачей 1с77 справляется в 10 раз быстрее. Короче 1с82/83 конфигурация для ларьков с понтами

(70) открой для себя XMLТипЗнч().ИмяТипа

(71)
XMLПредставлениеТипа = БазаУдал. XMLТипЗнч(ТекЭлементУдал).TypeName — действительно самый быстрый способ определения типа и вида элементы. Примерно в 5-10 раз быстрее прочих.

Объединить две базы ЗУП в одну

Здравствуйте.
Есть две базы 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 не будет опубликован. Обязательные поля помечены *