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