Довольно часто в практике сопровождения 1С возникает задача: есть две идентичные базы (например, 1С:Бухгалтерия предприятия 3.0). В одной базе данные обрываются прошлым годом, а во второй ведется учет по сегодняшний день. Нам необходимо "малой кровью" перекачать данные за недостающий период (например, за один конкретный год) из новой базы в старую. При этом нужно перенести абсолютно все: документы, ручные операции, регламентные операции по закрытию месяца и так далее. Давайте разберем по шагам, как правильно подойти к решению этой задачи, какие инструменты использовать и как избежать типичных ошибок, таких как задвоение планов счетов и справочников.
Первое, что приходит на ум — настроить стандартную синхронизацию. Однако, проанализируем ситуацию: попытка использовать типовой обмен через формат EnterpriseData для такой задачи обречена на провал. Выясним причину.
Формат EnterpriseData изначально спроектирован для интеграции разных конфигураций (например, между 1С:Управление торговлей и 1С:Бухгалтерия). Он оперирует унифицированными бизнес-сущностями и не предназначен для создания точных бухгалтерских копий. В этом формате просто не предусмотрена выгрузка и загрузка специфичных ручных операций, корректировок регистров или внутренних регламентных документов закрытия месяца. Для полного переноса данных между клонами нам потребуются другие механизмы.
Рассмотрим самый популярный и быстрый способ для абсолютно идентичных баз. Это использование специализированной обработки, которая переносит данные без правил конвертации, опираясь исключительно на структуру метаданных.
Где найти эту обработку?
EXE/EXTREPS/UNIREPS83/UploadToXML.Обработка работает очень просто: мы выбираем период, выбираем нужные типы документов и справочников, и система формирует XML-файл. В базе-приемнике мы открываем ту же самую обработку и загружаем данные.
Проанализируем главную опасность первого метода. Важное замечание: обработка "Выгрузка и загрузка данных XML" перенесет данные гладко только в том случае, если база-приемник и база-источник являются точными потомками (клонами) одной и той же исходной базы на уровне файловой системы или SQL.
Почему так происходит? Система синхронизирует объекты по их внутреннему уникальному идентификатору (УИД / GUID). Если вы создали базу "с нуля" и завели там справочник валют, у рубля будет сгенерирован один УИД. Во второй базе, даже если она идентична по структуре, у рубля будет совершенно другой УИД.
При загрузке XML программа не смотрит на код или наименование. Она видит новый УИД и создает новый элемент. В результате вы гарантированно получите задвоение элементов справочников (особенно классификаторов) и, что самое страшное, размножение Плана счетов. Удалить лишние счета потом крайне сложно, так как на них могут завязаться проводки.
Если ваши базы не являются клонами одной выгрузки, нам нужно отказаться от прямого переноса по УИД. Рассмотрим более надежный метод. Нам понадобится встроенная обработка УниверсальныйОбменДаннымиВФорматеXML и правила переноса, которые мы создадим в конфигурации "Конвертация данных 2.1" (КД 2.1).
Разберем алгоритм действий:
Код; Контрагенты — по реквизитам ИНН и КПП; План счетов — по реквизиту Код.При таких настройках универсальный обмен при загрузке данных сначала найдет существующий элемент в базе-приемнике по понятному нам коду, и лишь обновит его, а не создаст дубль.
При использовании автосгенерированных правил обмена вы можете столкнуться с ошибкой при загрузке специфичных документов. Посмотрим на частый пример: документ ОтражениеЗарплатыВБухучете выдает ошибку пустой даты.
Это происходит потому, что автогенератор правил иногда не захватывает скрытые или служебные свойства документов, либо порядок инициализации реквизитов требует явного указания даты до записи табличных частей.
Чтобы это исправить, нам нужно открыть наши правила в "Конвертации данных 2.1", найти ПКО проблемного документа и в обработчике событий "Перед выгрузкой" или "Перед загрузкой" написать небольшой корректирующий код. Например, принудительно установить дату:
Если ПустаяСтрока(Строка(Объект.Дата)) Тогда
Объект.Дата = ТекущаяДата(); // Или передать дату из параметров
КонецЕсли;
Также часто помогает исключение из выгрузки (снятие галочек в правилах) сугубо служебных реквизитов табличных частей, которые система должна рассчитывать сама при проведении.
Если вы все же воспользовались первым методом и получили задублированные справочники, не стоит паниковать и откатывать базу (хотя бэкап всегда должен быть!). Рассмотрим штатный инструмент спасения.
В современных версиях 1С:Бухгалтерия 3.0 есть отличная встроенная обработка. Перейдем в раздел Администрирование -> Обслуживание -> Корректировка данных и откроем пункт ПоискИУдалениеДублей.
В этой обработке:
Проанализируем еще два профессиональных подхода, если классический XML-обмен вам не подходит.
Вместо формирования промежуточных XML-файлов можно использовать обработки обмена через OLE/COM. В этом случае база-источник подключается к базе-приемнику напрямую. Плюс этого метода в том, что при переносе объектов обработка может "на лету" проверять базу-приемник на наличие элементов с такими же кодами или наименованиями. Это позволяет гибко обходить проблему дублей без сложной настройки правил в Конвертации Данных. Существует множество готовых обработок на профильных ресурсах, реализующих этот механизм для идентичных конфигураций.
Если вам нужно получить базу с абсолютно идеальной структурой и гарантированным отсутствием дублей, рассмотрим метод через создание узла РИБ.
ПланыОбмена.УстановитьГлавныйУзел(Неопределено).В итоге мы получаем полностью самостоятельную, рабочую базу за нужный период. В ней на 100% совпадают все внутренние идентификаторы, нет проблем с планами счетов и не требуется писать правила конвертации для обхода ошибок пустых дат.
Подведем итоги: для переноса данных между базами всегда проверяйте, являются ли они полными клонами. Если да — смело используйте типовую выгрузку XML. Если их истории создания разнятся — используйте "Универсальный обмен" с правилами поиска по реквизитам или механизм создания образа через РИБ.