Выгрузка из 1С во внешнюю базу не видит правку задним числом. Как её поймать

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

Я воспроизвёл это на тестовой базе. Документ датой 25 сентября перенесли на 25 марта. Выгрузка с окном в две недели перечитала последние 14 дней, увидела, что в сентябре строки больше нет, и удалила её в приёмнике. До марта окно не достаёт, туда строка не пришла. Будь окно единственной проверкой, строки не было бы ни в сентябре, ни в марте, а журнал выгрузки остался бы чистым.

Поймала это другая проверка, я называю её паспортом дня: по каждому дню всей истории сравнить число строк и суммы с тем, что уже выгружено. Март в 1С стал на одну строку больше, чем при прошлой выгрузке, и эту дату выгрузка отправила в приёмник заново. Ниже разбираю, как такая проверка собирается на обычных запросах 1С и сколько она стоит на регистре в 10 миллионов строк.

Что делает окно и почему этого мало

Слово "приёмник" дальше означает внешнюю базу, куда уезжают данные: хранилище под отчёты или базу соседней системы. Окном называют самый распространённый способ держать приёмник свежим: каждый прогон заново читает последние N дней целиком, новое вставляет, изменённое обновляет, пропавшее удаляет. Остальную историю окно считает неизменной, хотя старые периоды в учёте двигают постоянно: перепроводят документ после исправления, меняют дату, снимают с проведения, помечают на удаление.

Если документ ушёл из сентября в март, окно отработает сентябрьскую половину правки, а мартовскую не увидит. Увеличить окно до полугода можно, но это лечит только длину. Перечитывать всю историю каждую ночь дорого, а правку за пределами любого окна всё равно не увидишь. Нужен способ узнать, что изменилось в старом периоде, не перечитывая его.

Перенос документа на полгода назад: что делает окно и что видит проверка по дням

Что видит сравнение числа строк

Первое, что обычно ставят после окна, - сравнение числа строк: сколько в 1С, столько и в приёмнике. Правку внутри существующей строки такая проверка не замечает.

Сценарии правок я гонял на регистре "Товары на складах" тестовой базы Управления торговлей, там 5 545 строк движений с января 2026 года. Испортил в приёмнике одну строку за 20 июня: количество 2 стало 3. Документы в этой базе крупные, за 20 июня в регистре 500 строк. В 1С их 500 и в приёмнике 500, а сумма движений за день в 1С -1 210, в приёмнике -1 211 (расход считается с минусом, поэтому сумма отрицательная).

Счётчик строк ловит потерю или дубль строки. Правку суммы или склада в строке, которая уже есть, он пропускает.

Почему менять в приёмнике надо день целиком

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

Построчная загрузка по ключу "регистратор плюс номер строки" тоже рабочая. Перенос даты для неё обычный MERGE: строка с тем же ключом получает новый период. Затык у неё в удалениях. Если документ перепровели и строк в нём стало три вместо пяти, приёмнику нужны ключи двух пропавших строк, а в 1С их уже нет. Выгрузке пришлось бы хранить ключи всех строк с прошлого раза и сравнивать с текущими. При замене дня удаление получается само: день стирается и заливается тем, что в нём есть сейчас. Второй довод практический: проверки ниже тоже считают по дням, и разошедшийся день чинится заменой этого дня, искать конкретную строку для ремонта не нужно.

Одно условие при этом жёсткое: пакеты грузятся строго по порядку. Первая версия обработки его нарушала. Пакеты назывались временем создания с точностью до секунды, два прогона в одну секунду записали пакет в одну папку, второй затёр первый, а ремонтный пакет с тем же временем встал в очередь после более свежего. Загрузчик приёмника упал на повторяющемся ключе. Теперь у пакета сквозной номер, и правило "по возрастанию номера, каждый один раз" записано в описание формата, которое лежит рядом с пакетами.

Остаётся вопрос, какие дни класть в пакет. Окно отвечает "последние четырнадцать", и мартовскую правку это не покрывает.

Паспорт дня: дешёвая проверка всей истории

Паспорт дня - это несколько чисел на каждую дату: сколько строк движений и какая сумма каждого ресурса. После выгрузки паспорт сохраняется рядом с пакетом. Следующий прогон строит паспорт заново по всей истории, с первого дня, и сравнивает с сохранённым. Разошёлся день - его строки уходят в новый пакет целиком, даже если это март.

Паспорт строится одним запросом с группировкой по дню. Для регистра остатков приход идёт со знаком плюс, расход со знаком минус, иначе перенос строки из прихода в расход сумму не изменит. В примере один ресурс, чтобы запрос читался; обработка складывает так каждый числовой ресурс регистра, у "Товаров на складах" это ВНаличии и КОтгрузке:

ВЫБРАТЬ
	НАЧАЛОПЕРИОДА(Т.Период, ДЕНЬ) КАК День,
	КОЛИЧЕСТВО(*) КАК Строк,
	СУММА(ВЫБОР
			КОГДА Т.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
				ТОГДА Т.ВНаличии
			ИНАЧЕ -Т.ВНаличии
		КОНЕЦ) КАК ВНаличии
ИЗ
	РегистрНакопления.ТоварыНаСкладах КАК Т
ГДЕ
	Т.Период >= &НачалоИстории
	И Т.Активность
СГРУППИРОВАТЬ ПО
	НАЧАЛОПЕРИОДА(Т.Период, ДЕНЬ)

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

Объём я мерил отдельно от сценариев, на синтетике в регистре "Движения денежных средств" той же базы. Сначала 3 000 документов по 100 строк, 300 000 строк с января 2023 года. Потом добавил 9 700 документов по 1 000 строк, всего вышло 10 миллионов строк в 1 362 днях. Паспорт и версии по всей истории, три прогона подряд:

Паспорт - это полный проход по таблице регистра с группировкой по дню, индекс ему не помогает, и время растёт вместе с объёмом. Числа сняты на тестовой машине с 16 ГБ памяти, где сервер 1С и SQL Server стоят вместе, при 0,6-4 ГБ свободной памяти, восемь серий по три прогона подряд в три разных дня. Первый проход после простоя, пока СУБД не подняла таблицу в кэш, шёл 35 секунд, следующие уже 6-9. На рабочем сервере под нагрузкой будет дольше: в одной серии, когда машину грузили соседние процессы, паспорт шёл 20-22 секунды, версии 14-20. Линейная оценка на 50 миллионов строк - 20-45 секунд на спокойном сервере. Для ночного прогона это немного, поэтому паспорт я считаю по всей истории каждый раз.

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

Версии документов: то, чего паспорт не видит

Следующий сценарий я поставил специально против паспорта. В той же мартовской строке заменил товар на другой, а количество и дату оставил. Число строк за день прежнее, сумма прежняя, паспорт зелёный. В приёмнике при этом лежит не тот товар, и отчёт по номенклатуре врёт.

Такую правку ловит третий слой - версии документов-регистраторов. Платформа меняет ВерсияДанных при каждой записи объекта, и её можно получить обычным запросом. Сначала один проход по регистру собирает регистраторы и дни их движений, потом по каждому виду документа читаются версии:

ВЫБРАТЬ
	Д.Ссылка КАК Ссылка,
	Д.ВерсияДанных КАК Версия,
	Д.Дата КАК Дата,
	Д.Проведен КАК Проведен,
	Д.ПометкаУдаления КАК Пометка
ИЗ
	Документ.ОприходованиеИзлишковТоваров КАК Д
ГДЕ
	Д.Ссылка В (&РегистраторыЭтогоВида)

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

Порядок "сначала проход по регистру, потом версии по встреченным видам" появился не сразу. Первая версия делала подзапрос к регистру на каждый вид документа, который вообще может писать в этот регистр, а у регистра бухгалтерии таких видов десятки, то есть десятки лишних проходов по регистру вместо одного. Версии 12 700 документов на 10 миллионах строк читаются за 4,8-8,5 секунды. Документы в синтетике крупные, по 1 000 строк; если документов миллионы, дольше станет и чтение версий по ссылкам, этого я не мерил.

В сценарии с заменой товара паспорт нашёл 0 дней, версии 1 день, и этот день вне окна.

Зачем тогда версии, если в платформе есть регистрация изменений через план обмена? С авторегистрацией она ловит любую запись документа, в какой бы период он ни попал, а если включить в состав плана сам регистр, то и запись набора записей мимо документа. Регистрацию после выгрузки снимает сама выгрузка методом УдалитьРегистрациюИзменений, и снимать её можно после зелёной сверки приёмника, о которой ниже. Паспорт и сверка приёмника ложатся поверх плана обмена так же, как поверх версий. Довод против у меня один: плана обмена под выгрузку в типовой конфигурации нет, а появиться он может правкой конфигурации или расширением, которое меняет структуру данных. Такое расширение надо согласовать с владельцем базы и сопровождать при каждом обновлении. Версии читаются запросом из любой базы как есть. Если менять базу можно, план обмена с регистром в составе надёжнее версий и закрывает дыру из раздела про границы.

Какой слой что поймал на пяти правках

Сам приёмник тоже надо сверять

Всё, что выше, отвечает на вопрос "изменилась ли 1С после выгрузки". Есть второй вопрос, и его задают реже: дошло ли выгруженное до приёмника целиком. Пакет мог не загрузиться или загрузиться наполовину, а кто-то мог поправить строку прямо в хранилище.

Ответ тот же паспорт, только посчитанный на стороне приёмника: по каждому дню число строк и суммы ресурсов. Приёмник кладёт его файлом рядом с пакетом, 1С сравнивает с паспортом выгруженного. Я гонял это на отдельной базе MS SQL, куда пакеты грузились тем самым правилом "удалить строки дат из пакета, вставить строки пакета". Регистр тот же, "Товары на складах" на 5 545 строк.

Паспорт приёмника подмену товара не видит по той же причине, по какой её не видит паспорт 1С. Находит её только разбор дня: приёмник отдаёт свои строки за этот день, они сравниваются со строками 1С по ключу "регистратор плюс номер строки", и в ответ приходит адрес вида "Реализация товаров и услуг от 05.07.2026, строка 1, поле Номенклатура". Разбор дня дорогой, поэтому я запускаю его точечно: на красный день или на тот, про который спросил бухгалтер.

После красной сверки нужен ремонт. Отдельной кнопки "перевыгрузить дни" я делать не стал: сверка сама кладёт пакет на красные дни, собранный из текущего состояния 1С, со следующим номером в общем ряду, и приёмник грузит его тем же порядком. В сценарии с порчей за 20 июня ремонтный пакет заменил 500 строк дня, и следующая сверка стала зелёной.

Чего не ловит ни один слой и во что это обходится

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

Регистры сведений схема не покрывает. Слой версий держится на том, что у каждой строки есть документ-регистратор, а у независимого регистра сведений его нет. Поэтому обработка работает с регистрами накопления и бухгалтерии.

Обратная сторона версий - лишняя работа. ВерсияДанных меняется при любой перезаписи, даже если движения остались теми же. Групповое перепроведение документов за квартал отправит в пакет все дни квартала, приёмник перезальёт их теми же строками, и пакет после такой ночи будет большим.

Узкое место схемы - первая выгрузка. Она пишет всю историю в файл кодом 1С, строка за строкой, вместе с представлениями ссылок. На синтетике в 300 000 строк это заняло 481-521 секунду, около 600 строк в секунду, файл вышел на 156 МБ. Первую выгрузку 10 миллионов я не гонял: линейно это четыре-пять часов, а 50 миллионов - около суток, в одну ночь не влезает. С той же скоростью пишется и окно при повторном прогоне. На 300 000 строк повторный прогон шёл 5,7-5,8 секунды, из них около секунды паспорт и версии, остальное запись 2 600 строк окна. На 10 миллионах в окно 14 дней попадает около 100 000 строк, и по той же оценке это около трёх минут записи.

При замере первой выгрузки вылез ещё один затык. Вызов, который ждал её окончания, оборвался по таймауту, а сервер 1С продолжал писать. Я запустил выгрузку снова, и два прогона почти четыре минуты писали в один каталог. Теперь прогон ставит в каталоге замок и снимает его в конце, второй получает отказ с именем того, кто занял каталог.

Как это собрано

Все три слоя, сверка приёмника и разбор дня собраны в обработку "Выгрузка регистров 1С во внешнюю базу со сверкой сходимости". Она работает на запросах 1С и файлах: к СУБД базы не обращается и в базу не пишет. Приёмник может быть любым, от MS SQL до таблицы в системе отчётности (BI): ему достаточно уметь удалить строки дня, загрузить файл и посчитать свой паспорт. В архиве рядом с обработкой лежит пример приёмника на MS SQL под "Товары на складах" (таблица, загрузка пакета в одной транзакции, паспорт приёмника) и описание формата пакета и паспорта. Проверял на регистрах накопления Управления торговлей 11.5 и на регистре бухгалтерии с корреспонденцией Бухгалтерии для Казахстана 3.0.

Обработка из этой статьи: Выгрузка регистров 1С во внешнюю базу со сверкой сходимости.

Другие наши инструменты

• Анализ правил обмена КД 2 - если данные уезжают через обмен по правилам Конвертации данных 2 и надо понять, что именно попадает в очередь.
• Выгрузка данных 1С для нейросети - когда данные едут в чат с нейросетью или в программу, которой нужен Markdown или JSON.
• Чек-ап СУБД под 1С - если ночная выгрузка стала медленной и подозрение падает на сервер.
• Карта объёмов базы 1С - прикинуть, сколько строк поедет в первую выгрузку, до того как её запускать.

Вопрос

Как вы сейчас проверяете, что хранилище сходится с 1С, и сверяет ли ваша проверка что-нибудь кроме числа строк? Если возите регистр на десятки миллионов строк, напишите, сколько у вас занимает полный проход по нему: интересно сравнить с моими числами.