← На главную

Синхронизация данных между конфигурациями «1С:Бухгалтерия предприятия 3.0» (БП) и «1С:Розница 2.2» — один из ключевых процессов в автоматизации торговой деятельности. Однако при работе в клиент-серверном варианте на платформе 1С:Предприятие 8.3 специалисты часто сталкиваются с неприятной проблемой: процесс обмена через сетевой каталог успешно запускается, проходит первые шаги, но на третьем этапе («Сопоставление и загрузка данных») примерно на 65% прогресс-бар замирает, и сессия аварийно завершается.

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

Почему происходит обрыв на 65%? Выясняем технические причины

Когда базы данных работают в клиент-серверном режиме, выполнение синхронизации кардинально отличается от файлового варианта. Все основные ресурсоемкие операции выполняются непосредственно на сервере приложений 1С рабочим процессом rphost. Пользователь на своем компьютере видит лишь визуальное отражение процесса.

Обрыв синхронизации на этапе сопоставления данных чаще всего обусловлен следующими факторами:

1. Ограничения оперативной памяти процесса rphost. На этапе сопоставления система считывает XML-файл обмена и пытается полностью загрузить его структуру в оперативную память сервера для сравнения с существующими объектами базы-приемника. Если объем передаваемых данных велик (особенно при первой настройке обмена), а на сервере установлены лимиты памяти на один рабочий процесс или используется 32-битная версия сервера 1С, процесс rphost аварийно перезапускается операционной системой из-за нехватки ресурсов. Сеанс пользователя при этом мгновенно обрывается.
2. Проблема прав доступа службы сервера 1С. Поскольку чтение файла из сетевого каталога выполняет сервер, учетная запись, от имени которой запущена служба «Агент сервера 1С:Предприятие» (обычно это локальный пользователь usr1cv8), должна обладать полными правами (чтение, запись, изменение) на этот сетевой каталог. Если прав недостаточно, то при попытке прочитать очередную порцию данных или записать временный лог-файл сервер блокирует операцию, и обмен прекращается.
3. Переполнение дискового пространства во временной папке Temp. В процессе парсинга XML-пакетов сервер распаковывает данные в системный каталог временных файлов (%USERPROFILE%\AppData\Local\Temp пользователя службы 1С). Если на системном диске сервера СУБД или сервера приложений заканчивается свободное место, запись прерывается, вызывая критический сбой.

Природа ошибки «Неопределено» при сопоставлении объектов

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

• Несоответствие версий метаданных (формат EnterpriseData). Современный обмен между БП 3.0 и Розницей 2.2 базируется на универсальном формате EnterpriseData (XDTO-пакеты). Если конфигурации имеют разные релизы, структура метаданных может не совпадать. Приемник, считывая XML-файл, обнаруживает новые реквизиты, которых еще нет в его структуре данных. Парсер XDTO не может определить тип этого реквизита, присваивает ему внутреннее значение Неопределено, что в итоге приводит к падению платформенных алгоритмов сопоставления.
• Наличие битых ссылок в базе данных. GUID-идентификаторы сопоставленных объектов записываются в служебные регистры сведений: СоответствияОбъектовИнформационныхБаз и ПубличныеИдентификаторыСинхронизируемыхОбъектов. Если в одной из баз объект (например, номенклатура или контрагент) был удален напрямую без контроля ссылочной целостности, то в этих регистрах остается ссылка вида <Объект не найден>. При попытке сопоставить данные алгоритм считывает эту битую ссылку, получает пустое значение и прерывает синхронизацию.

---

Пошаговое руководство по решению проблемы синхронизации

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

Шаг 1. Выравнивание версий конфигураций и платформы 1С

Прежде всего, убедимся в совместимости используемых версий программного обеспечения. Конфигурация Розница 2.2.11.29 требует использования платформы не ниже 8.3.13.1690. Проанализируем текущие релизы обеих баз. Выполним следующие действия:

1. Обновим конфигурации «Бухгалтерия предприятия» и «Розница» до актуальных и взаимно совместимых релизов. Это критически важно, так как новые релизы содержат обновленные XDTO-пакеты формата EnterpriseData.
2. Установим одинаковую версию платформы 1С:Предприятие на сервере приложений и на рабочих местах пользователей. Оптимальным решением будет переход на стабильные ветки платформы (например, актуальные релизы 8.3.14 или выше, если это поддерживается конфигурациями).

Шаг 2. Обновление и перезагрузка правил обмена

Часто сбои происходят из-за повреждения или устаревания внутренних правил конвертации и регистрации данных. Перезапишем их заново:

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

Шаг 3. Очистка кэша сервера 1С

Временные файлы и кэш метаданных на стороне сервера могут искажать логику работы фоновых заданий обмена. Проведем очистку серверного кэша:

1. Остановим службу «Агент сервера 1С:Предприятия» через консоль служб Windows (services.msc) или с помощью командной строки.
2. Перейдем в каталог расположения кластера серверов (по умолчанию это C:\Program Files\1cv8\srvinfo).
3. Найдем папки с именами формата reg_1541. Внутри них будут находиться папки кэша конфигураций с длинными буквенно-цифровыми именами (UID). Удалим эти папки (внимание: не удаляйте файлы настроек кластера 1CV8Reg.lst).
4. Запустим службу сервера приложений 1С заново.

Шаг 4. Очистка битых ссылок и тестирование баз (ТИИ)

Проверим целостность ссылок в обеих базах данных. Для этого запустим конфигуратор каждой информационной базы под учетной записью Администратора и выполним следующие шаги:

1. Откроем меню Администрирование — Тестирование и исправление...
2. Установим флажки напротив пунктов:
   • Реиндексация таблиц информационной базы;
   • Проверка логической целостности;
   • Проверка ссылочной целостности.
3. В блоке «При наличии битых ссылок» обязательно выберем переключатель «Очищать объекты» (или «Создавать дефолтные объекты», чтобы не потерять важные связи, но для регистров сопоставления лучше выбрать «Очищать»).
4. Нажмем кнопку «Выполнить» и дождемся окончания процесса.

Шаг 5. Очистка служебных регистров сопоставления

Если в базах присутствуют зависшие сопоставления с некорректными типами данных, очистим их вручную. Для этого:

1. Используя обработку «Функции для технического специалиста» (или «Все функции»), найдем регистр сведений СоответствияОбъектовИнформационныхБаз.
2. Проанализируем записи регистра. При обнаружении строк, где в качестве уникального идентификатора или самого объекта отображается <Объект не найден>, удалим данные записи.
3. Аналогичную операцию проведем с регистром сведений ПубличныеИдентификаторыСинхронизируемыхОбъектов.

Шаг 6. Дробление первой выгрузки данных (порционный обмен)

При первой настройке обмена объем данных слишком велик, что гарантированно приводит к пиковым нагрузкам на сервер 1С. Разделим процесс на этапы:

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

Шаг 7. Проверка обмена через локальную файловую копию

Для того чтобы локализовать проблему и понять, виновата ли серверная инфраструктура или сами данные баз, выполним диагностику:

1. Создадим резервные копии (выгрузки .dt) баз БП и Розницы.
2. Развернем их локально на мощном персональном компьютере в файловом варианте работы.
3. Настроим локальный обмен через обычную папку на жестком диске.
4. Запустим синхронизацию. Если на файловой копии обмен прошел успешно и без ошибок, значит, проблема кроется исключительно в нехватке аппаратных ресурсов сервера 1С, лимитах процессов rphost или правах доступа службы usr1cv8 на сервере.

Применяя эти шаги последовательно, мы гарантированно сможем выявить «узкое горлышко» процесса синхронизации, устранить программные конфликты типов данных и успешно завершить первоначальный обмен между конфигурациями 1С.