Как исправить ошибку «Данные из указанного файла переноса данных уже загружались» в 1С 7.7 УРБД?

← На главную

При работе с Управлением распределенными базами данных (УРБД) в платформе 1С:Предприятие 7.7 администраторы часто сталкиваются с ситуацией, когда при попытке загрузить очередной пакет обмена в Центральную базу (ЦБ) или Периферийную базу (ПБ) система выдает критическую ошибку: «Данные из указанного файла переноса данных уже загружались...». Данное поведение является штатным механизмом защиты платформы, однако оно полностью блокирует дальнейший двусторонний обмен данными.

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

Выясняем причину: как работает механизм защиты УРБД

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

Каждому выгружаемому файлу обмена (обычно архиву формата .zip) присваивается уникальный идентификатор сессии обмена — DWNLDID.
При импорте файла принимающая база данных обращается к своей служебной таблице 1SDWNLDS (в SQL-версии она называется _1SDWNLDS).
Система ищет запись, в которой код базы-отправителя (DBSIGN) совпадает с кодом импортируемого пакета, направление обмена (DIRECT) указано как входящее (I — Incoming), а идентификатор пакета равен DWNLDID из загружаемого файла.
Если запись с таким идентификатором уже присутствует в таблице, программа делает логический вывод: этот файл уже был успешно обработан ранее. В целях безопасности загрузка прерывается.

Чаще всего эта ошибка возникает по двум причинам: из-за банального человеческого фактора (когда оператор на точке повторно отправляет старый файл или путает папки выгрузки) либо из-за технических сбоев (например, при восстановлении базы данных из старой резервной копии, когда счетчики пакетов в ЦБ и ПБ «рассинхронизировались»).

Способ 1. Проверка каталогов обмена и исключение человеческого фактора

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

Проверим следующие моменты:

Совпадают ли пути выгрузки в настройках конфигуратора 1С и фактические пути, откуда файлы отправляются в центральный офис.
Не завис ли старый файл обмена в промежуточном каталоге (например, на FTP-сервере или в почтовом ящике). Если там лежит старый файл с тем же именем и номером сессии, принимающая база будет постоянно пытаться обработать именно его.
Для исключения подобных проблем в будущем рекомендуется использовать специализированный софт для автоматизации транспорта файлов, например, утилиту URBDMaster. Она работает как служба Windows, берет на себя весь транспорт, автоматически переименовывает архивы, очищает временные папки после успешного импорта и полностью исключает человеческий фактор.

Способ 2. Исправление ошибки через прямое редактирование таблиц базы данных

Если сбои произошли на уровне базы данных (например, после восстановления из бэкапа) и файлы действительно новые, но система отказывается их принимать, нам придется скорректировать содержимое системной таблицы 1SDWNLDS.

Сначала проанализируем структуру таблицы 1SDWNLDS:

DWNLDID — Уникальный идентификатор сессии обмена (числовой счетчик).
DBSIGN — Трехсимвольный код информационной базы, с которой производится обмен.
DIRECT — Направление пакета: O (Outgoing — исходящий пакет для текущей базы), I (Incoming — входящий пакет).
ACKNOWL — Признак подтверждения обработки пакета (символ A).

Рассмотрим два варианта корректировки этой таблицы.

Вариант А. Точечное удаление мешающей записи

Если нам необходимо повторно загрузить конкретный файл обмена без сброса всей истории:

Откроем таблицу 1SDWNLDS. В файловом режиме (DBF) для этого можно использовать любую утилиту для работы с DBF-файлами (например, DBF Commander). В режиме MS SQL откроем базу через SQL Server Management Studio.
Найдем строку, где значение DBSIGN соответствует коду приславшей файл периферийной базы, поле DIRECT имеет значение I, а значение DWNLDID совпадает с ID пакета, на который ругается конфигуратор.
Удалим эту строку.
Важно для DBF-версии: после удаления записи обязательно нужно выполнить физическую «упаковку» (Pack) таблицы, удалить индексный файл 1SDWNLDS.cdx и запустить монопольно 1С для автоматического перестроения индексов.

После этой процедуры принимающая база «забудет» факт импорта данного пакета и успешно примет его заново.

Вариант Б. Полный сброс истории обменов в принимающей базе

В случаях серьезного рассогласования распределенной сети проще начать отслеживание пакетов «с чистого листа»:

Полностью очистим (удалим все строки) таблицу 1SDWNLDS в принимающей базе данных.
Если база файловая, удалим файл индексов 1SDWNLDS.cdx.
Запустим базу монопольно для индексации.

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

Способ 3. Обход проблемы через фиктивное изменение конфигурации (Dummy MD Change)

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

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

В Центральной базе (ЦБ) зайдем в конфигуратор и внесем любое незначительное изменение (например, добавим новую неиспользуемую константу с типом «Число»).
Сохраним конфигурацию (файл 1cv7.md).
Сразу же удалим эту константу и снова сохраним конфигурацию. Физически структура данных не поменяется, но конфигурация получит новый внутренний маркер изменения структуры метаданных.
Сделаем выгрузку из ЦБ в сторону проблемной ПБ.
Загрузим этот файл в ПБ. Обновление метаданных заставит ПБ применить новую конфигурацию и скорректировать свои внутренние счетчики ожидания.
Сделаем ответную выгрузку из ПБ и загрузим ее в ЦБ. Обмен восстановится.

Архитектурное решение: проектирование правильной миграции данных «Центр — Точки»

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

Штатный механизм УРБД 1С 7.7 не позволяет гибко настраивать условия миграции для стандартных документов «Перемещение». Если документ мигрирует «Все ИБ», то все торговые точки увидят перемещения друг друга, что конфиденциально и избыточно. Если поставить миграцию «Место создания и Центр», то перемещение из Центра на Точку-А просто не придет в базу Точки-А.

Для решения этой задачи спроектируем классическую схему «Транзитного документа».

Проанализируем шаги реализации этой схемы:

В конфигурации создаем документ ПеремещениеТоваров. Устанавливаем для него область миграции: «Только ЦБ» (этот документ списывает остатки со склада в Центре и не уходит напрямую по каналам связи).
Создаем второй, служебный документ — ТранзитПеремещения. Для него устанавливаем область миграции: «Все ИБ». В его реквизитах будут храниться простые типы данных (текст, числа): код склада-получателя, артикулы товаров, количество.
В модуле проведения документа ПеремещениеТоваров в Центральной базе пишем код программного создания транзитного документа:


Процедура ОбработкаПроведения()
    // Проводим движения по регистрам Центральной базы
    Регистр.ОстаткиТоваров.Расход(Фирма, СкладОтправитель, Номенклатура, Количество);
    
    // Автоматически генерируем транзитный документ для отправки на периферию
    ДокТранзит = СоздатьОбъект("Документ.ТранзитПеремещения");
    ДокТранзит.Новый();
    ДокТранзит.СкладПолучательКод = СкладПолучатель.Код;
    ДокТранзит.НоменклатураАртикул = Номенклатура.Артикул;
    ДокТранзит.Количество = Количество;
    ДокТранзит.Записать();
КонецПроцедуры

Транзитный документ улетает во все периферийные базы.
В глобальном модуле или модуле проведения транзитного документа в ПБ пишем обработчик загрузки. Каждая ПБ при проведении или записи входящих документов проверяет реквизит СкладПолучательКод:


Процедура ПриЗаписи()
    // Проверяем, предназначен ли транзитный документ нашей базе
    Если СокрЛП(СкладПолучательКод) <> СокрЛП(Константа.КодЛокальногоСклада) Тогда
        // Если склад чужой, документ просто сохраняется без движений и не мешает работе
        Возврат;
    КонецЕсли;
    
    // Если склад наш, автоматически создаем локальный документ прихода
    ДокПриход = СоздатьОбъект("Документ.ЛокальныйПриход");
    Если ДокПриход.НайтиПоРеквизиту("ДокументОснование", ТекущийДокумент(), 1) = 0 Тогда
        ДокПриход.Новый();
        ДокПриход.ДокументОснование = ТекущийДокумент();
        // Заполняем табличную часть, сопоставляя номенклатуру по артикулу
        // ...
        ДокПриход.Записать();
        ДокПриход.Провести();
    КонецЕсли;
КонецПроцедуры

Для локального документа ЛокальныйПриход настраиваем миграцию «Место создания и Центр». Он проведет товар по регистрам конкретной торговой точки и вернется в Центр как подтверждение приемки, при этом не засоряя базы других периферийных точек. Эта схема является максимально надежной, производительной и проверенной годами практики в распределенных сетях на платформе 1С 7.7.