Как объединить две базы 1С «базовой» версии в одну базу 1С версии ПРОФ?
Есть две базы 1С ЗУП 3 «базовой» версии, в которых отдельно ведется учет двух организации. Мы купили ЗУП версии ПРОФ и хотим вести учет этих организаций в одной информационной базе версии ПРОФ? Как перенести (совместить) две базовые версии в одну ПРОФ?
Ответ:
✅ Мастер класс «3 шага к идеальному НДФЛ»
Схема учета для ежемесячного контроля НДФЛ: Узнать подробнее ->>
✅ ЧЕК-ЛИСТ по проверке расчета зарплаты в 1С ЗУП 3.1
ВИДЕО — ежемесячная самостоятельная проверка учета: Узнать подробнее ->>
✅ Начисление зарплаты в 1С ЗУП 3.1
Пошаговая инструкция для начинающих: Узнать подробнее ->>
В этом случае можно поступить следующим образом.
- Одну из баз обновить на версию 1С ЗУП ПРОФ
- После этого вторую базу обновить до точно такого же релиза, что и первая база (это важно, чтобы релиз этих баз совпадал)
- После этого выполнить перенос данных из второй базы в первую, используя обработку Выгрузка загрузка данных XML (она доступна на ИТС). Эта обработка позволит перенести сведения между базами с идентичными конфигурациями
Чтобы узнать первыми о новых публикациях вступайте в группы в социальных сетях, где все материалы также регулярно публикуются:
Объединить две базы ЗУП в одну
Здравствуйте.
Есть две базы 1С ЗУП. Типовые. В одной базе одна организация и в другой базе одна организация. Сотрудники из первой базы через реорганизацию присоединением переходят в организацию из второй базы. Через кадровый перевод просто. Соответственно нужно перенести сотрудников со всеми их начислениями, удеражаниями и прочим из одной базы во вторую. (как буд-то они у нас всегда работали во второй базе просто в отдельном подразделении, а кадровики уже с нужной даты их переведут в основное подразделение). Разумеется нужно, чтобы считались правильно налоги, средний заработок, больничные и все остальное.
От вас срок, стоимость (не за час) и почту или мессенджер для контактов. Сделать нужно максимально быстро — базы для переноса готовы.
Спасибо.
Как в 1С объединить несколько баз в одну
Переходим на 1С 8.3, данные по основной деятельности заводим в рабочей базе, а по основным средствам в отдельной базе.
Как в 1С объединить несколько баз в одну?
Оцените, пожалуйста, данный вопрос:
(5 оценок, среднее: 4,60 из 5)
Зарегистрированным пользователям доступны более 300 видеоуроков по работе
в 1С:Бухгалтерия 8, 1С:ЗУП
Зарегистрированным пользователям доступны более 300 видеоуроков по работе
в 1С:Бухгалтерия 8, 1С:ЗУП
После регистрации на указанный адрес Вы получите ссылку на просмотр более 300 видеоуроков по работе в 1С:Бухгалтерия 8, 1С:ЗУП 8 (бесплатно)
Войти в кабинет
Вам будет интересно
Дата публикации: Янв 12, 2017
Поделиться:
Поставьте вашу оценку этой статье:
(5 оценок, среднее: 4,60 из 5)
Размещено пользователем:
Все комментарии (3)
Ирина Шаврова 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С:ЗУП в одну и добиться того, чтобы простой в работе пользователей был минимальным. Клиент остался доволен уровнем нашего погружения в проблемы и их решением.
Поделиться: Вконтакте
Спасибо за заявку! Мы перезвоним вам в ближайшее время. Подписывайтесь на нас в соцсетях
- О компании
- Контакты
- Блог
- Проекты
- Карьера в ФТО
- Вакансии
- Прайс лист 1С
- ISO 9001:2015
- Карта сайта
- Наши услуги
- Внедрение решений на 1С
- Поддержка пользователей 1С
- 1С:Документооборот
- Ускорение производительности 1С
- Системы для бизнес-анализа (BI)
- Аналитика SimpleHR
- Комплексное обслуживание 1С
- Доработка конфигураций 1С
- Переход с 1С:УПП на 1С:ERP
- Переход на новый 1C:ЗУП 3.1