← На главную

Синхронизация данных между конфигурациями Управление торговлей 10.3 (на обычных формах) и Бухгалтерия предприятия 3.0 (на управляемых формах) — классический сценарий для автоматизации торгового и бухгалтерского учета. Однако администраторы и программисты 1С часто сталкиваются с крайне неприятной ситуацией: после очередного сеанса одностороннего обмена (УТ -> БП) документы за прошлые, давно закрытые периоды в базе-приемнике (БП) внезапно оказываются помеченными на удаление.

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

Техническая суть проблемы: почему «старые» документы помечаются на удаление?

Для того чтобы понять логику системы, нам необходимо проанализировать работу механизмов регистрации изменений и Библиотеки стандартных подсистем (БСП), на базе которой построен обмен в Бухгалтерия предприятия 3.0.

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

1. Случайная регистрация изменений: В базе-источнике (УТ 10.3) пользователь или внешняя обработка (например, групповое перепроведение, восстановление последовательности или групповое изменение реквизитов) затрагивает документы прошлых периодов (например, за 2018 год при дате начала обмена 01.01.2019). В этот момент уникальные идентификаторы (UID) этих документов автоматически регистрируются к отправке на узле плана обмена.
2. Фильтрация по дате начала обмена: При запуске синхронизации система начинает выгружать зарегистрированные объекты. Правила регистрации объектов (ПРО) видят, что дата документа (2018 год) меньше, чем установленная в настройках узла дата начала обмена (01.01.2019). Соответственно, сам документ (его реквизиты, табличные части) в файл обмена не выгружается.
3. Генерация транзакции удаления: Поскольку документ зарегистрирован к обмену, но не проходит по критериям даты выгрузки (он «выпал» из разрешенного диапазона обмена), БСП считает, что этого документа в базе-приемнике быть не должно. Система делает вывод: «Раз объект зарегистрирован к обмену, но по правилам фильтрации он не должен передаваться, значит, его нужно удалить из приемника». В выгружаемый XML-пакет записывается команда УдалениеОбъекта с уникальным идентификатором этого документа.
4. Выполнение команды в приемнике: При загрузке файла в Бухгалтерия предприятия 3.0 система считывает команду удаления и послушно помечает соответствующий документ у себя на удаление.

Опасность изменения «Даты начала обмена» на лету

Отдельно проанализируем ситуацию, когда администраторы пытаются изменить «Дату начала обмена» непосредственно в работающем узле (например, сдвигают ее с 01.01.2017 на 01.01.2019, чтобы ускорить обмен). Doing так «на лету» категорически противопоказано!

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

Пошаговое руководство: как исправить проблему и защитить закрытые периоды

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

Решение 1. Настройка даты запрета загрузки в БП 3.0 (Главный рубеж обороны)

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

Разберем по шагам, как настроить этот механизм:

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

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

Решение 2. Очистка зарегистрированных изменений в УТ 10.3 перед обменом

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

Выполним следующие действия в Управление торговлей 10.3:

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

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

Решение 3. Безопасное изменение параметров обмена (Пересоздание синхронизации)

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

1. Полностью удалите настройки синхронизации в обеих базах данных (и в УТ, и в БП). Это действие автоматически очистит все служебные таблицы регистрации изменений в СУБД.
2. Создайте новую настройку синхронизации данных с чистого листа.
3. На этапе настройки сразу укажите верную дату начала обмена (например, 01.01.2019).
4. При первом запуске выполните сопоставление объектов вручную, чтобы избежать дублирования информации.

Решение 4. Контроль флага «Отражать в БУ» в УТ 10.3

Проанализируем еще одну частую причину удаления документов. В Управление торговлей 10.3 в документах есть важный флаг — Отражать в БУ (Отражать в бухгалтерском учете). Если менеджер или бухгалтер в торговой базе случайно или намеренно снимает этот флаг у документа, система при обмене считает, что данный документ больше не предназначен для бухгалтерии. Соответственно, в БП 3.0 уходит команда на пометку удаления этого документа. Проинструктируйте пользователей о важности этого реквизита и ограничьте права на его изменение в закрытых периодах.

Как восстановить уже помеченные на удаление документы?

Если неприятность уже произошла и документы в БП 3.0 массово пометились на удаление, нам необходимо их восстановить:

1. Перед любыми восстановительными работами обязательно сделайте резервную копию (бэкап) базы данных Бухгалтерия предприятия 3.0.
2. Воспользуемся стандартной обработкой Групповое изменение реквизитов (раздел Администрирование -> Обслуживание -> Корректировка данных).
3. Выберем необходимый тип документов, настроим отбор по дате (например, «Дата меньше 01.01.2019») и признаку пометки на удаление («Пометка на удаление равно Да»).
4. В списке изменяемых реквизитов найдем реквизит ПометкаУдаления, установим значение Ложь и выполним обработку.
5. Помните, что документы могли не просто пометиться на удаление, но и распровестись. Для восстановления их проведения в закрытом периоде используйте обработку проведения документов, предварительно сверив оборотно-сальдовую ведомость (ОСВ) с архивной копией базы до сбоя, чтобы убедиться, что проводки и движения по регистрам восстановились корректно.