Как перенести платежные поручения между идентичными базами 1С:Бухгалтерия государственного учреждения 1.0

Перенос данных между конфигурациями — задача, с которой рано или поздно сталкивается любой специалист 1С. В случае с 1С:Бухгалтерия государственного учреждения ред. 1.0 (БГУ) ситуация осложняется строгой привязкой документов к бюджетным классификаторам и особенностями работы на обычных формах. В данной статье мы разберем, как наиболее эффективно перенести платежные поручения, сохранив целостность данных и избежав появления дублей в справочниках.

Метод 1. Универсальная обработка «Выгрузка и загрузка данных XML»

Если конфигурации в обеих базах абсолютно идентичны (совпадают релизы и нет уникальных доработок, влияющих на структуру метаданных), самым быстрым способом будет использование стандартной обработки ВыгрузкаЗагрузкаДанныхXML.epf. Этот инструмент позволяет напрямую передать объекты из одной базы в другую.

Рассмотрим порядок действий:

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

Проанализируем главную опасность этого метода: обработка сопоставляет объекты по их внутреннему идентификатору — GUID. Если организация «ООО Иванов» была создана вручную в обеих базах, их GUID будут разными, даже если названия и ИНН совпадают. В результате загрузки в базе-приемнике появится второй элемент «ООО Иванов». Это критическая проблема для учета, поэтому данный метод подходит только в том случае, если база-приемник изначально была создана как копия базы-источника.

Метод 2. Использование конфигурации «Конвертация данных 2.1»

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

Выясним, как настроить правила для корректного поиска. Для справочника Контрагенты в БГУ 1.0 недостаточно искать только по наименованию. Мы рекомендуем установить «Поля поиска» по следующей связке:

• ИНН
• КПП
• ЭтоГруппа

Разберем ситуацию программной настройки в КД. В обработчике «Поля поиска» для ПКО Контрагенты мы можем прописать уточняющую логику:

Если СвойстваПоиска["ЭтоГруппа"] = Ложь Тогда
    // Ищем только по ИНН и КПП для элементов
    СвойстваПоиска.Вставить("ИНН", Объект.ИНН);
    СвойстваПоиска.Вставить("КПП", Объект.КПП);
КонецЕсли;

При таком подходе, если программа найдет в базе-приемнике контрагента с таким же ИНН и КПП, она подставит его в платежное поручение, а не создаст новый объект. Это решает проблему «сидения бухов неровно» и появления хаоса в справочниках.

Метод 3. Перенос через формат «Клиент-Банк» (TXT)

Если бюджетная организация небольшая, а базы сильно замусорены, рассмотрим альтернативный, «полуручной» метод. В 1С:БГУ предусмотрен штатный механизм обмена с банковскими системами.

Выполним следующие шаги:

1. В базе-источнике перейдем в журнал платежных документов и запустим обработку «Экспорт в казначейские системы/банк».
2. Сформируем файл выгрузки в стандартном текстовом формате 1С.
3. В базе-приемнике откроем обработку «Импорт документов».
4. При загрузке система проанализирует файл. Если контрагент или счет не будут найдены, программа предложит выбрать их из существующих или создать новые.

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

Нюансы бюджетного учета: КПС и КЭК

Проанализируем специфику БГУ 1.0. Платежное поручение в этой программе не может существовать без привязки к рабочему плану счетов. При переносе крайне важно убедиться в следующем:

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

Рекомендации по автоматизации и проверке

Для минимизации ошибок при массовом переносе, рассмотрим использование префиксов информационных баз. Установим в базе-приемнике уникальный префикс (например, «ПЕР»). При загрузке документов номера платежек получат этот префикс, что позволит легко отфильтровать перенесенные данные от созданных на месте.

Также полезно использовать расширенные версии обработки XML с диска ИТС, которые поддерживают режим «Проверять наличие объектов при загрузке». Это позволит увидеть потенциальные дубли до того, как они будут записаны в базу данных.

Подведем итог: для быстрого переноса между точными копиями выбираем ВыгрузкаЗагрузкаДанныхXML. Для регулярного обмена или переноса в рабочую базу с риском дублей — используем Конвертацию данных с настроенными полями поиска по ИНН/КПП. А для разового и контролируемого переноса небольшого объема данных отлично подойдет механизм Клиент-Банк.