Как перенести данные по организации из базовой 1С:ЗУП в существующую базу 1С:ЗУП ПРОФ?

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом IT и автоматизация бизнеса
← На главную

Перенос данных из отдельной информационной базы 1С:ЗУП (базовой версии) в уже работающую базу ЗУП ПРОФ, в которой ведется многофирменный учет нескольких организаций, — распространенная практическая задача. Основная сложность заключается в том, чтобы корректно перенести кадровую историю, расчеты и начисления, не повредив данные других организаций в базе-приемнике и избежав дублирования справочников.

Разберем детально, почему штатная выгрузка может аварийно завершаться ошибками, как правильно подготовить базы к переносу, а также рассмотрим несколько проверенных подходов: от прямого обмена через XML до настройки правил конвертации и ввода начальных остатков.

Причины падения выгрузки и ошибки «Произошла непредвиденная ситуация»

При попытке выгрузить данные через обработку «Выгрузка и загрузка данных XML» пользователи нередко сталкиваются с аварийным завершением работы или ошибкой «Произошла непредвиденная ситуация». Выясним главные технические причины такого поведения:

  1. Нехватка оперативной памяти процесса (Out of Memory): Если клиент 1С запущен в 32-разрядном режиме (x86), объем адресуемой памяти процесса ограничен 2–4 ГБ. При формировании дерева объектов или разборе тяжелого XML-файла с сотнями сотрудников парсер исчерпывает этот лимит, и сеанс аварийно закрывается.
  2. Ошибки ссылочной и логической целостности: Наличие в базе-источнике битых ссылок (с отображением Объект не найден) или поврежденных записей регистров нарушает работу встроенного механизма сериализации платформы.
  3. Недопустимые символы XML: Присутствие в наименованиях или строковых реквизитах непечатаемых управляющих символов (диапазон ASCII 0–31) вызывает сбой штатного XML-парсера при чтении потока.
  4. Несовпадение структур конфигураций: Если базовая версия и версия ПРОФ имеют разные релизы, структуры метаданных отличаются, что делает прямую загрузку XML некорректной.

Подготовка баз и предварительное обновление

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

Разберем первый обязательный шаг: выравнивание конфигураций. Базовая версия ЗУП имеет технические ограничения на многофирменный учет. Чтобы структуры метаданных полностью совпали, обновим копию базовой базы до версии ПРОФ того же самого релиза, что и база-приемник:

  1. Открываем копию базовой базы в режиме «Конфигуратор».
  2. Переходим в меню «Конфигурация» — «Поддержка» — «Обновить конфигурацию».
  3. Указываем файл поставки конфигурации ПРОФ (.cf) строго того же релиза, который установлен в базе-приемнике.
  4. Применяем изменения и запускаем базу в режиме предприятия для выполнения регламентных процедур обновления данных.
  5. В базе-источнике и приемнике выполняем тестирование и исправление («Администрирование» — «Тестирование и исправление») с проверкой ссылочной и логической целостности. Для файловых баз также проверяем целостность утилитой chdbfl.exe.
  6. Запускаем обе базы исключительно под 64-разрядной платформой 1С (x64), чтобы исключить нехватку оперативной памяти.

Способ 1. Использование обработки «Выгрузка и загрузка данных XML» с предотвращением дублей

Обработка «Выгрузка и загрузка данных XML» сопоставляет объекты исключительно по внутреннему идентификатору (GUID). Если организация, графики работы, должности или начисления уже заведены вручную в базе-приемнике, их GUID не совпадут, и платформа создаст дубликаты. Кроме того, загрузка выполняется с параметром ОбменДанными.Загрузка = Истина, что отключает модули проведения и бизнес-проверки.

Чтобы избежать дублирования ключевых элементов, проанализируем грамотный алгоритм выравнивания идентификаторов:

  1. Перенос существующей организации из приемника в источник: Если в целевой базе ПРОФ карточка организации уже создана, сначала выгрузим с помощью XML именно эту организацию из приемника и загрузим ее в копию источника. После этого с помощью обработки «Поиск и замена значений» заменим исходную организацию на загруженную. В результате GUID организации в обеих базах станет идентичным.
  2. Поэтапная выгрузка данных: Не выгружайте всю базу целиком. Сначала выгрузим нормативно-справочную информацию (подразделения, должности, графики работы, физические лица, сотрудники). Затем — кадровые документы. И только потом — расчетные документы небольшими порциями (по месяцам).
  3. Контроль затяжки системных справочников: При выгрузке по ссылкам следите, чтобы не затянулись служебные справочники (пользователи, настройки вариантов отчетов, присоединенные файлы), иначе вы рискуете затереть настройки базы-приемника.
  4. Слияние дублей: После переноса запустим типовую обработку «Поиск и удаление дублей». Обратите особое внимание: объединять можно только дубли Физических лиц, но ни в коем случае нельзя объединять элементы справочника Сотрудники, так как это разрушит кадровые регистры плановых начислений, стажей и вычетов.

Способ 2. Перенос через «Конвертацию данных 2.1» (КД 2)

Если в базе сотни сотрудников, перенос документов «в лоб» через XML требует огромного объема ручной выверки. Наиболее контролируемый путь разработки правил — использование конфигурации «Конвертация данных 2.1» и типовой обработки Универсальный обмен данными в формате XML.

Рассмотрим по шагам настройку правил:

  1. Выгрузим структуру метаданных из обеих баз с помощью внешней обработки MD83Exp.epf.
  2. Загрузим структуры в конфигурацию КД 2.1 и создадим конвертацию.
  3. Для объектов справочников снимем признак «Искать объект приемника по внутреннему идентификатору» и настроим естественные поля поиска:
    1. Для справочника Организации: по реквизитам ИНН и КПП.
    2. Для справочника ФизическиеЛица: по СтраховойНомерПФР (СНИЛС) и ИНН.
    3. Для справочника ПодразделенияОрганизаций: по наименованию с учетом владельца (организации).
    4. Для планов видов расчета (Начисления, Удержания): по наименованию с установленным флагом «Не замещать существующие объекты при загрузке».
  4. В обработчиках событий для документов (например, ПередЗагрузкой) установим режим загрузки данных, чтобы исключить запуск тяжелых механизмов перерасчета прошлого периода.

Способ 3. Перенос остатков на дату (рекомендуемый для промышленного учета)

При переносе прошлых расчетных периодов из ЗУП возникают серьезные риски рассогласования регистров СФР (подраздел 1.1 формы ЕФС-1 / СЗВ-ТД), где каждое кадровое мероприятие имеет уникальный системный UUID. Также повреждаются цепочки сообщений по СЭДО и ЭЛН, которые жестко завязаны на идентификаторы базы.

Поэтому на практике оптимальным решением часто является фиксация даты перехода (например, 1 января текущего года) и перенос в базу-приемник только актуальных остатков:

  1. Перенос кадрового состава: Создаем в базе-приемнике документ Начальная штатная расстановка на выбранную дату. Этот документ регистрирует срез кадровых данных: сотрудников, их подразделения, должности, оклады, тарифные ставки и плановые начисления без необходимости переноса всех исторических приказов о приеме и переводе.
  2. Остатки отпусков: Вносим актуальное количество накопленных дней отпуска для каждого работающего сотрудника документом ввода остатков отпусков.
  3. Данные для расчета среднего заработка: Переносим сведения о доходах за предыдущие два года документом Справка для расчета пособий (входящая) для корректного расчета больничных листов.
  4. Средний заработок для отпусков и командировок: Вносим данные о заработке за предшествующие 12 месяцев через форму ввода данных для расчета среднего заработка или вспомогательные документы Перенос данных по регистрам расчета.

Такой подход полностью исключает возникновение скрытых дублей в регистрах накопления и расчета, снимает проблему конфликта кадровых UUID мероприятий СФР и гарантирует стабильную работу регламентированной отчетности в базе ЗУП ПРОФ.

← На главную