Главное место бухгалтера: сверка двух баз 1С, расхождения обмена и готовность к закрытию месяца

Остаток не сходится, а обмен зеленый

Двадцать восьмое число. Бухгалтер открывает оборотно-сальдовую по 41 счету и видит остаток, который не сходится с ведомостью по складам из торговли. Разница в двести тысяч рублей. Синхронизация настроена, вчера отработала, в мониторинге стоит зеленая галочка «Синхронизация данных выполнена».

Дальше начинается день, который знает каждый, кто сопровождает пару УТ и БП. Выгрузить обороты из торговли в Excel. Выгрузить обороты из бухгалтерии в Excel. Свести ВПР по номеру и дате. Найти, что одного поступления в бухгалтерии нет вообще, а у другого сумма отличается на копейки НДС. Выяснить, что первое не уехало еще в прошлом месяце, а второе уехало, но с другой ставкой.

Через месяц история повторяется, и через два тоже.

Обмен при этом работает нормально. Он просто не рассказывает, как отработал: зеленая галочка означает «сеанс завершился», и ничего больше. Про то, одинаковые ли теперь данные в двух базах, галочка не говорит.

Почему обмен молчит

У синхронизации через универсальный формат есть четыре излюбленных способа сломаться. Это не классификация, а то, что мы ловили чаще всего; общее у них то, что ни один не выглядит как ошибка.

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

Документ уехал, но не создался в приемнике. В протоколе синхронизации предупреждение, оно легло в список проблем обмена, список никто не открывал. Или хуже: в настройках узла включена галочка «Пропускать объекты с ошибками». Вот как это описано у нас в базе диагностики:

Объект, не прошедший проверку по схеме формата, молча выбрасывается из сообщения обмена. Ошибки не будет ни в протоколе, ни в предупреждениях — данные просто не доедут, и найти это можно только сверкой.

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

Документ создался, но с другой суммой. Потерялась строка табличной части, не совпала единица измерения, разошлась ставка НДС. Количество документов в двух базах одинаковое, отчет по количеству сойдется, а деньги — нет.

Справочник разъехался. Два контрагента с одним ИНН и КПП: часть документов легла на один экземпляр, часть на другой. Сальдо по контрагенту перестает сходиться, хотя каждый отдельный документ выглядит правильно.

Общее у всех четырех случаев одно: чтобы их заметить, надо сравнить данные двух баз. В релизах, с которыми мы работаем (УТ 11.5.22 и БП 3.0.191), готового средства для такого сравнения мы не нашли: смотрели мониторинг синхронизации, состав проблем обмена, отчеты подсистемы обмена данными. Все они рассказывают про сеансы и про свою сторону, а не про то, совпали ли данные. Поэтому и появляется Excel.

Сколько в вашей базе документов, про которые никто не знает, доехали они или нет? Честный ответ обычно звучит как «не считали».

Если задача разовая — пришли, посмотрели, поставили диагноз, — расширение для этого не нужно. Часть картины читается запросами прямо из базы: узлы, очередь регистрации, публичные идентификаторы, состояния сеансов. Я выложил их отдельной статьей, бесплатно, вместе с настоящим выводом и граблями языка запросов: «Обмен УТ и Бухгалтерии отчитался „выполнено“. Семь запросов, чтобы не поверить на слово».

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

Что делает расширение

Расширение ставится в обе базы. Каждая база складывает в общий каталог снимок своих данных, вторая забирает чужой снимок и сравнивает со своим. Результат — список: что не доехало, что доехало иначе, что мешает закрыть период.

Вопрос, на который оно отвечает: можно ли закрывать месяц.

Чтобы не держать главное на последней странице: расширение загружено в обе базы пары и прогнано там на живых данных, снимок, сверка, диагностика, отчеты и акт отрабатывают. Релизы, на которых это проверено, и что осталось непроверенным — в разделе «На чем проверено».

Снимок вместо соединения

Для сверки двух баз первым делом приходит в голову COM-соединение. У нас оно каждый раз упиралось в чужого администратора: нужен пользователь во второй базе с правами на чтение, нужен подходящий COM-коннектор, нужен сетевой доступ, а базы нередко стоят на разных серверах и у разных подрядчиков.

Поэтому обмен идет через файл. Снимок — это zip-архив с XML внутри: состав документов за период с суммами, ошибки обмена, настройки узлов, остатки по счетам, если база их ведет. Архив кладется в каталог, видный обеим базам: сетевая шара, общий диск, папка облачной синхронизации. Ни COM, ни веб-сервис для работы не нужны. Во вторую базу надо попасть один раз, чтобы загрузить туда расширение конфигуратором; дальше сверка идет без всякого доступа к ней.

Документы и справочники базы расширение не трогает. Проверял грепом по исходникам версии 1.16, по тем же семи образцам, что и раньше (.Записать(, ЗаписатьНабор, СоздатьДокумент, .Провести, РежимЗаписиДокумента, Константы.<Имя>.Установить, .Удалить()), и добавил к ним три новых: регистрацию изменений в плане обмена, постановку напоминания и отправку письма. Почти все найденное пишет в свое: регистры сведений и константы с префиксом ГМБ_, архив снимка, файл отчета по кнопке.

По этому поиску за пределы своих объектов выходят три вещи, и все они появились в новых версиях:

• регистрация объекта к выгрузке в плане обмена — только по кнопке «Отправить неподтвержденные» или из разбора документа, руками. Худший исход ошибки здесь — лишняя выгрузка, которая лечится следующей синхронизацией;
• напоминание пользователю в регистре напоминаний БСП — так приходят оповещения;
• письмо через системную учетную запись почты — тоже оповещения, если вы указали адрес.

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

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

Одна оговорка про файловые базы, на которой я сам споткнулся. Регламентные задания файловой базы выполняются, только пока в ней открыт хотя бы один клиент. Закрыли программу в пятницу — в понедельник снимок другой базы трехдневный, и рабочее место напишет «данные устарели» вместо чисел.

Значок обмена прямо в журнале документов

В список документов добавляется колонка «Обмен», первой слева. По значку в строке видно состояние: расхождение, отправлен, ждет выгрузки, принят, одобрено, введен вручную, не проверено, вне обмена. Под списком — расшифровка значков и дата сверки, по состоянию на которую они показаны: цифры без даты обманывают. Та же колонка есть в списках справочников, которые участвуют в обмене: номенклатура, контрагенты, организации.

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

Пока настройки не заведены, колонка показывается сама по составу плана обмена: где обмен есть, там и значок. Так вышло не сразу. Расширение ставят в обе базы пары, настройки заводят в одной, и во второй колонки не было нигде — притом что ни одной ошибки не возникало и сказать об этом было некому. Незаведенная строка означала «выключено», а выключенный индикатор молчит намеренно. Теперь пустой регистр настроек означает «еще не настраивали», и первая же заведенная строка это умолчание отменяет.

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

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

По моим наблюдениям, рядовому бухгалтеру эта колонка нужнее всего остального: ничего открывать не надо, состояние обмена видно там, где он и так работает.

Рабочее место

Одно окно и четыре числа вверху: сколько документов проверено, сколько разошлось, сколько не приехало, сколько ошибок обмена. Строкой ниже — свежесть данных и сколько документов из проверенных вообще подлежат обмену. Дальше вкладки, о каждой по порядку.

Если баз-корреспондентов больше одной — например, торговля обменивается с двумя бухгалтериями, — над числами появляется выбор базы, и все вкладки показывают сверку с выбранной. Состояния, правила исключения и настройки сверки у каждой базы свои; колонка «Обмен» в журналах одна и показывает базу, названную основной.

Расхождения

Дерево: документ, под ним — что именно разошлось, значение здесь и значение в другой базе. Разворачивается до реквизитов шапки и до строк товаров, так что в итоге читаешь «в строке 3 количество 10 против 12» вместо глухого «сумма не сошлась».

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

Не приехало

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

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

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

Это же отвечает на первый случай из начала статьи. Документ, не попавший в очередь, здесь не появится, зато очередью и правилами занимается диагностика: у нее на это отдельная группа.

Справочники

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

Код сравнивается, только когда он заполнен с обеих сторон. Иначе колонка бесполезна. В сверке 5 октября на нашей паре из 79 расхождений по справочникам 76 оказались одного вида: у контрагентов торговли код пустой, у бухгалтерии заполнен. Это свойство двух конфигураций, а не беда конкретного контрагента, и красить им весь справочник значит приучить человека не смотреть в эту колонку. Сейчас, после правки и на свежих данных, их шесть в сверке торговли и два в сверке бухгалтерии: разные наименования, группа против элемента, пометка удаления с одной стороны.

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

Суммы

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

Обороты по контрагентам. Суммы проведенных документов по контрагенту, месяцу и виду документа — здесь и в другой базе, с разницей. Под таблицей документы, из-за которых строка не сошлась, и причина словами: «нет в другой базе», «не проведен там», «сумма отличается», «есть только в другой базе». Двойной щелчок открывает документ. На тестовой паре так нашлось поступление, которое в торговле на 3,66, а в бухгалтерии на 450,18 рубля.

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

Взаиморасчеты. Долги по каждому контрагенту на конец периода сверки: в торговле — по регистрам расчетов с клиентами и поставщиками, в бухгалтерии — по счетам 62 и 60. Контрагенты сопоставляются по ИНН, без ИНН — по наименованию. Сверяются только рубли: сложить рубли с долларами хуже, чем не сверять валютные долги вовсе. Разница тут бывает и без ошибки обмена (ручная проводка, корректировка долга), поэтому таблица стоит рядом с оборотами, а не вместо них.

История

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

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

История ведется с установки версии 1.14. Что было до нее, не восстановить, и все расхождения, найденные первым прогоном, датируются этим прогоном.

Хранить все подряд не обязательно. Галка «Вести историю» выключает ее целиком, а колонка «В истории» на вкладке «Объекты» оставляет только нужные виды: например, реализации и поступления без справочников. У вида, с которого галку сняли, новые строки не заводятся, а уже открытые доживают до закрытия. Оборванная на середине строка читалась бы как расхождение, которое так и не закрылось.

Оповещения

Чтобы узнать о новом расхождении, не нужно открывать рабочее место. На вкладке «Оповещения» указываются получатели, и после каждой сверки они получают напоминание в программе или письмо — о трех вещах: появились новые расхождения, данные другой базы устарели, сверка не выполнилась.

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

Каналы — напоминание БСП и письмо через системную учетную запись. Если в базе выключены напоминания или не настроена почта, вкладка так и пишет и говорит, где это включается. Кнопка «Проверить оповещение» шлет пробное сразу, чтобы не ждать первого расхождения и не гадать, почему ничего не пришло. Одна особенность БСП: в уже открытую программу напоминание приходит с задержкой ее опроса сервера, по умолчанию до двадцати минут; при входе в программу — сразу.

Оповещения выключаются целиком галкой «Оповещения включены» или по видам объектов — колонкой «Оповещать» на вкладке «Объекты». Кнопки «Включить все» и «Выключить все» там действуют на ту колонку, в которой стоит курсор: оставить оповещения по трем видам из сорока можно без тридцати семи щелчков и не трогая сверку. Выключенный вид все равно запоминается как «сообщенный», поэтому после включения обратно старые расхождения не приходят лавиной как новые. Устаревший снимок и сбой сверки к видам не относятся и подчиняются только общей галке.

Ошибки синхронизации

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

Диагностика

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

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

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

Аномальный объем очереди выгрузки. Очередь в десятки тысяч объектов — обычно след от «перерегистрировать все» или от массовой обработки, которая перезаписала справочник. Ближайший сеанс обмена будет идти часами и с большой вероятностью упадет по таймауту.

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

Сюда же попадает четвертая беда из начала статьи, та, что про разъехавшиеся справочники. Ею занимается группа «идентификация»:

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

Соседние правила той же группы ищут близнецов в номенклатуре, контрагентов без ИНН и номенклатуру без единицы измерения, то есть ровно то, обо что спотыкается обмен при сопоставлении.

Тридцать шестое правило появилось уже после прогона 13 октября, после того, как я полдня искал ошибки расширения в журнале регистрации рабочей торговли и не нашел ни одной. Журнал регистрации в той базе был выключен совсем, и все, что расширение туда писало с августа, никуда не попадало. Теперь это правило «журнал регистрации не ведется» в группе настройки самого расширения.

Правило, которому в этой базе нечего проверять, говорит «неприменимо» и тут же называет причину. Молчаливое «неприменимо» — та же зеленая галочка, с которой статья началась, и в диагностике ей не место.

Это не теория. Три правила сверки сальдо показывали «в снимке нет сальдо» и выглядели совершенно законно. Оказалось, что дата в снимке читалась текстовой функцией, которая для нестроковых значений возвращает пустую строку; правило получало пустоту и делало вывод, что данных нет. Дефект нашелся в конце сентября 2026-го, и ровно потому, что пришлось объяснять каждое «неприменимо» словами: настоящая причина («в этой базе нет регистра бухгалтерии») с выдуманной не совпала. Таких мест набралось четыре, все исправлены в 1.4.0.

Закрытие месяца

Чек-лист готовности периода, девять строк:

1. Документы сопоставлены с другой базой.
2. Все за период уехало и принято.
3. Нет документов с расхождением сумм.
4. Нет непроведенных среди принятых.
5. Нет ошибок синхронизации за период.
6. Обмен отработал по расписанию все дни периода.
7. Нет свежих дублей номенклатуры и контрагентов.
8. Нет объектов, не сопоставленных с источником.
9. Снимок актуален.

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

Раз уж эта цифра попала в кадр, объясню ее. Скриншоты сняты на копии демонстрационной базы, в которой регламентное задание синхронизации выключено. Это первая же находка диагностики. Обмен там ходил от случая к случаю, поэтому охват — чуть больше половины. Для статьи это удачно: именно так выглядит строка охвата, когда ей есть о чем предупредить.

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

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

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

Настройки

Каталог снимков, глубина сверки в месяцах, порог свежести снимка в часах, предел строк в отчетах. Там же галка «Считать разную проведенность расхождением», по умолчанию снятая: при обмене документ приезжает непроведенным почти всегда, приемник проводит его сам, и если считать это расхождением, красным горит каждый свежий документ. Непроведенные при этом не теряются, у них своя строка в чек-листе закрытия месяца. Какие виды сверять и где показывать колонку «Обмен», задается на вкладке «Объекты», о ней выше.

У правил выгрузки появилось поле «Для базы»: правило можно завести для всех корреспондентов сразу или только для одного.

Отчеты и акт

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

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

Акт закрывает отдельную боль подрядчика. Устное «я посмотрел ваш обмен, там все плохо» заказчику продать трудно, а с бумагой, где перечислены все проверенные позиции, найденное по каждой и часы на устранение, разговор идет заметно проще.

Поиск объекта по ГУИДу

Побочная вещь, а пользуюсь я ею чаще всего остального. В протоколе обмена объект назван одним идентификатором, и по нему надо понять, что за ним стоит.

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

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

Что диагностика нашла на тестовой паре

Прогон на моей паре баз 13 октября 2026 года, версия расширения 1.7.0. Все 35 правил в обеих базах, снимки сняты в тот же день.

Чтобы таблица не оставалась голыми числами, вот все четырнадцать находок по торговле, как их выдал прогон:

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

Одно правило стоит посмотреть отдельно. Неделю назад прогон давал замечание «Снимок устарел, дней: 8»: снимки лежали с пятого октября, и все сравнение между базами шло по данным недельной давности. Это и есть та ловушка, которой диагностика существует: расхождения считались правильно, только не по тем данным. После свежих снимков правило зеленое.

Числа по двум базам не совпадают, и это не сбой, а ровно то, ради чего правила объявляют свои требования. Расширение в обеих базах одно и то же: файл .cfe я снял с базы торговли и этот же файл загрузил в базу бухгалтерии. Разные тут конфигурации и настройки.

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

В бухгалтерии таких шесть, и делятся они на две половины. Первая — правила, которым не нашлось объекта:

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

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

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

На каких конфигурациях работает

Пара «Управление торговлей и Бухгалтерия» — самый частый случай, но к ней расширение не привязано. Привязано оно к одному: к Библиотеке стандартных подсистем. Оттуда берутся список планов обмена, регистр публичных идентификаторов, результаты обмена данными, настройки узла, напоминания, почта и роль базовых прав.

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

Никакого списка документов внутри расширения нет. Состав для сверки берется из состава плана обмена в вашей базе: что настроено обмениваться, то и сверяется. Сверка сальдо включается сама, если в базе есть регистр бухгалтерии «Хозрасчетный», и молча выключается, если его нет. Каждое правило диагностики объявляет, какие объекты метаданных ему нужны, и в их отсутствие отвечает «неприменимо» с причиной.

Значок в журналах цепляется к общим модулям БСП, а не к формам списков. Поэтому ему не важно, как устроена сама форма журнала, нужен только вызов подключаемых команд в ее коде; исключения — в разделе про установку.

Вживую расширение проверено только на паре УТ 11.5.22.149 и БП 3.0.191.41. Для остальных конфигураций я сделал две вещи.

Первая — проверка по выгрузкам. Скрипт собрал из исходников расширения все прямые обращения к метаданным типовой — документы, регистры, планы счетов, общие модули БСП, таблицы в текстах запросов — и проверил их наличие в четырех выгрузках: УТ 11.5, БП 3.0, БП КОРП 3.0 и ERP «Управление холдингом» 3.2. Все общие модули БСП, на которые опирается расширение, есть во всех четырех. Объектов, которых нет хоть в одной, нашлось три, и все три закрыты проверкой наличия: виды субконто нужны только там, где есть бухгалтерия, регистр соответствий внешних баз есть только в ERP, а реестр документов упоминается лишь в комментарии. Регистры расчетов с клиентами и поставщиками в ERP устроены так же, как в торговле, поэтому сверка долгов там должна идти тем же запросом; вживую это не проверено.

Вторая — попытка поставить расширение в живую ERP. Не вышло, и не из-за расширения: пустая файловая база из этой выгрузки ERP не собирается сама по себе. Конфигурация загружается, а обновление структуры падает на регистре сведений, у которого уникальный индекс длиннее, чем допускает файловый режим; увеличение страницы базы до 64 КБ не помогло. Нужен сервер 1С с СУБД, которого у меня на стенде нет. Так что для ERP у меня есть только сверка по выгрузке, а не прогон.

Розницу, УНФ и Комплексную я не проверял ни так, ни так: их выгрузок у меня нет. Комплексная и ERP — одна кодовая база, и за Комплексную я спокоен больше, чем за остальные, но «спокоен» — не результат. Старые планы обмена (Розница, УНФ, торговля 10.3 с бухгалтерией) расширение теперь видит, а пары документов там находит по собственному идентификатору объекта, без регистра публичных идентификаторов. Вживую такой пары у меня нет, и это тоже свойство кода, а не результат опыта.

Если у вас пара не из УТ с бухгалтерией, напишите в комментариях: это первое, что я хочу прогнать дальше, и начну с той, которую назовут чаще. Так какая пара у вас?

Чего расширение не делает

Читать до покупки.

Не чинит обмен. Оно показывает, что документ не уехал, и объясняет, почему. Само оно умеет только одно: зарегистрировать неподтвержденные документы к повторной выгрузке, и то по вашей кнопке. Исправить правило регистрации, перепровести, поправить сумму — руками или другими средствами.

Не создает и не меняет документы. Ни в одной базе. Что именно и куда оно пишет — в разделе про снимок выше.

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

Сверка сальдо по счетам в паре с УТ неприменима. Торговля бухгалтерских остатков не ведет; эта группа проверок работает, когда обе стороны — конфигурации с бухгалтерским учетом. Долги по контрагентам при этом сверяются и в паре с торговлей — на вкладке «Суммы», оперативный учет против счетов 60 и 62.

Валютные долги не сверяет. Только рубли.

Рассчитано на общий каталог. Штатный путь передачи снимка — папка, видная обеим базам. Если такой папки нет, есть кнопка «Загрузить снимок из файла»: архив можно принести чем угодно, и сверка пойдет по нему.

Не работает без БСП. Подробности в разделе выше.

Установка и права

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

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

Права раздавать не нужно. Обычная ситуация с расширениями: объекты в нем свои, а в типовых ролях их нет, поэтому у пользователя с полными правами раздел расширения открывается пустым, и это выглядит как неработающая поставка. Здесь права на объекты расширения добавлены в типовую роль базовых прав БСП — ту, что есть в конфигурациях на библиотеке; проверяли на УТ и БП. Если доступ надо разграничить, в расширении есть свои роли: просмотр и администрирование.

Конфигурацию расширение не меняет и с поддержки ее не снимает — расширения этого в принципе не делают. Заимствует оно три объекта БСП, и все щадящим образом:

• роль базовых прав, которой добавляет права на свои объекты (та самая, из-за которой роли не надо раздавать руками);
• общий модуль ПодключаемыеКоманды, в который добавляет обработчик с аннотацией &После. Типовой код при этом выполняется как был, а расширение просто узнает, что открылась форма списка;
• общий модуль ОбщегоНазначения, тоже с обработчиком &После, на установку свойств динамического списка. Он появился из-за номенклатуры: ее форма списка после открытия подменяет запрос целиком, и колонка «Обмен» терялась вместе со старым запросом. Теперь она возвращается после подмены.

Второй и третий пункты заодно объясняют, почему значок появляется в УТ и БП одним и тем же способом: расширение не заимствует ни одной формы списка. Оно цепляется к ПриСозданииНаСервере подключаемых команд и получает форму параметром.

Тут и живет та вторая граница. Вызывает подключаемые команды не платформа, а сам код типовой формы, и есть формы, где этого вызова нет. Я посчитал по выгрузкам обеих конфигураций: в торговле из 270 документов со своей формой списка вызов есть у 257, из 10 журналов — у 9; в бухгалтерии из 369 форм списка у 334, из 36 журналов — у 25. Где вызова нет, колонки не будет, и настройками это не лечится. В торговле так устроен, например, «Реестр торговых документов» — журнал, с которого как раз хочется начать.

Если что-то пойдет не так, ошибка уйдет в журнал регистрации, а форма останется типовой и откроется.

Про платформы: два файла, и почему не режим 8.5

В карточке два файла, и с версии 1.16.1 они разные. Отличаются они режимом совместимости расширения, а не платформой, которой собраны.

Сначала я проверил, влияет ли на файл сама платформа. Собрал одно и то же расширение платформами 8.3.27 и 8.5.1 и сравнил хеши: сошлись. Файл задает режим совместимости, а чем его выгрузили, неважно. Доказывает этот опыт факт про конкретный файл; распространять его на любую сборку я не берусь.

Поэтому файл для 8.3 собран в режиме 8.3.24: он ставится на любую платформу от 8.3.24 и выше, включая 8.5. Размер 403 800 байт, MD5 60C75A7D1EFF6AFD569EDDD3CDFAD73F.

Для 8.5 я сначала собрал файл в режиме 8.5, и он не встал. Торговля 11.5 и бухгалтерия 3.0 сами работают в режиме 8.3.27, и платформа ответила прямо: «Режим совместимости расширения конфигурации больше режима совместимости основной конфигурации». Тогда я перевел копию торговли в режим 8.5, и не запустилась уже она: платформа 8.5.1.1150 конфигурацию в режиме 8.5.1 не поддерживает и предлагает 8.3.27. Получается, что расширение в режиме 8.5 сегодня некуда поставить, даже на саму 8.5.

Файл для 8.5 собран в режиме 8.3.27. Это самый высокий режим, который принимают и платформа 8.5, и нынешние типовые. Размер 404 731 байт, MD5 857352F2BD09878CCBD4D7C773E3B889. Работает он так же: никаких возможностей новее 8.3.24 код расширения не использует. Проверял я его только на платформе 8.5; для платформ 8.3 есть первый.

Заодно проверилась вторая вещь, более нужная покупателю. Файл я снял с базы торговли, а загрузил в базу бухгалтерии — и расширение там заработало без реструктуризации базы данных. Это не само собой разумеется: расширение сопоставляется с конфигурацией либо по внутренним идентификаторам объектов, и тогда годится ровно для одной базы, либо по именам. У ГМБ стоит сопоставление по именам, и теперь это не настройка в свойствах, а проверенный факт.

Отсюда же нижняя граница: платформа нужна не ниже 8.3.24. На более старых мы расширение не ставили, обе проверенные — те, что названы выше.

Если не знаете, какой брать, берите файл для 8.3: он ставится везде, где встает второй.

На чем проверено

Управление торговлей 11.5.22.149 и Бухгалтерия предприятия 3.0.191.41, платформы 8.3.27.2214 и 8.5.1.1150, сентябрь и октябрь 2026 года. Версия расширения 1.16.2.

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

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

Таблица находок выше — из прогона 13 октября, обе строки посчитаны в этот день заново, по свежим снимкам.

С прошлой редакции статьи проверено то, что раньше стояло в списке непроверенного:

• регламентные задания по расписанию — на копии рабочей торговли, сверка каждые 60 секунд, четыре прогона подряд без ошибок;
• загрузка снимка из файла — сверка по загруженному архиву дает те же цифры, что по каталогу (сам диалог выбора файла автоматикой не нажимался);
• вторая бухгалтерия — на двух копиях бухгалтерии в паре с торговлей: каждый узел берет снимок своей базы, состояния и исключения из сверки не перемешиваются, повторная отправка регистрирует именно тот документ;
• обновление с прошлых версий — с 1.4.0, 1.7.0 и с копии рабочей торговли: история прогонов переносится, записи старого формата привязываются к узлу;
• справочники — значок обмена в их списках, разбор «Почему не уехал» и отчеты на СКД работают и для элементов справочников;
• оповещения — напоминание и письмо (письмо — через локальный почтовый сервер на копии), повторов нет;
• сверка сумм и история — на копиях пары, обе стороны дают зеркальные цифры;
• оповещения и история по видам — на копии торговли с шестнадцатью расхождениями пяти видов: при всех выключенных видах напоминание не пришло, при одном включенном пришло ровно о его четырех расхождениях, с выключенной общей галкой не пришло ничего; история с одним выбранным видом завела четыре строки вместо шестнадцати, после снятия и этой галки четыре открытые строки остались, а с выключенной общей галкой история не завела ни одной.

Чего я не проверял:

• формы в бухгалтерии под живым клиентом — там проверена только серверная часть;
• кнопки «Включить все» и «Выключить все» в колонках «Оповещать» и «В истории» — их работа на колонку под курсором следует из кода, прогона в клиенте не было;
• оповещения об устаревшем снимке и сбое сверки при выключенных видах — то, что они от видов не зависят, тоже следует из кода;
• ERP, Розница, УНФ, Комплексная и пары на старых планах обмена — о них раздел «На каких конфигурациях работает».

Файл .cfe версии 1.16.2 для 8.3 мы загрузили в копию бухгалтерии платформой 8.3, а файл для 8.5 — платформой 8.5 в обе копии, и сверка каждый раз дала те же числа, что и до обновления. Все вкладки рабочего места открываются без сообщений об ошибках.

Ядро 1.16.2, схема снимка 9. Читаются снимки начиная с восьмой схемы, а новые разделы снимка (долги, денежные виды) необязательные: база старой версии их просто не пришлет, и проверка по этим разделам не выполнится.

Что дальше

Все, что описано выше, есть в версии 1.16, а что и где проверено — в разделе выше. Этот раздел о другом: здесь план, а не описание.

В работе помощник по ошибкам синхронизации. Он будет объяснять бухгалтеру простыми словами проблемы, которые нашла сверка, подсказывать решение по базе типовых случаев и передавать специалисту то, чего не знает. Решенные случаи помощник будет запоминать и в следующий раз отвечать сам. Задуман он так, чтобы работать на компьютере пользователя: к базе напрямую не подключаться и данные клиента никуда не передавать. Выйти он должен обновлением ГМБ.

Порядок работ я составляю по комментариям. Чего вам не хватает сильнее — другой пары конфигураций, валютных долгов или чего-то, о чем я не подумал?