При интенсивном документообороте типовая синхронизация между конфигурациями 1С:ERP Управление предприятием и 1С:Розница может занимать значительное время (час и более). В таких ситуациях запуск следующего сеанса по расписанию может накладываться на еще не завершившийся предыдущий обмен. В результате документы в приемнике начинают массово распроводиться и перепроводиться заново, блокируя работу пользователей и вызывая взаимоблокировки в СУБД. Разберем по шагам, почему возникает эта проблема, чем опасны попытки передачи документов внешней обработкой по GUID и как грамотно оптимизировать процесс обмена.
Почему нельзя передавать документы в обход плана обмена по GUID
Идея написать внешнюю обработку, которая при зависании регламентного обмена точечно перенесет нужные документы по их внутреннему идентификатору (УникальныйИдентификатор), несет серьезные архитектурные риски:
Накопление «грязных» изменений: Передача объекта сторонней обработкой не снимает регистрацию изменений в типовом плане обмена. При следующем штатном запуске документ снова попадет в выгрузку.
Конфликты версий: Повторная штатная загрузка перезапишет документ на стороне приемника, что приведет к коллизиям версий, повторному снятию с проведения и дублированию движений в регистрах.
Нарушение ссылочной целостности: Если документ ссылается на новую номенклатуру или контрагента, которых еще нет в приемнике, ручной перенос только документа приведет к появлению битых ссылок (объектов «Не найден»).
Устранение наслоения сеансов обмена
Штатный механизм платформы 1С не запускает повторный экземпляр одного и того же регламентного задания, пока выполняется предыдущий. Если наслоение происходит, выясним причину и применим надежные методы защиты:
Проверка источника запуска: Если сеансы запускаются из внешнего планировщика операционной системы через командную строку или COM-соединение, внешняя программа не видит статус активного сеанса. Рекомендуется перевести запуск на встроенный механизм регламентных заданий конфигурации.
Установка свойства «Ключ» регламентного задания: В свойствах регламентного задания необходимо заполнить реквизит Ключ (например, значением Синхронизация_ERP_Розница). Платформа 1С гарантирует, что задание с одинаковым непустым ключом не будет запущено параллельно в нескольких фоновых потоках.
Настройка расписания в одном сценарии: Настройте сценарий синхронизации так, чтобы отправка и получение данных выполнялись в рамках одной базы последовательно с обязательной паузой между итерациями (например, 5–10 минут после завершения).
Разделение загрузки и проведения (отложенное проведение)
Основное время при синхронизации расходуется не на формирование и передачу XML/JSON-сообщения, а на проведение документов в базе-приемнике. Для кардинального ускорения процесса разделим фазу быстрой записи и фазу проведения:
Запись с флагом загрузки: При импорте объектов обязательно устанавливается режим загрузки данных:
Этот режим отключает тяжелые платформенные проверки в обработчиках ПередЗаписью и ПриЗаписи, исключая лишние пересчеты.
Использование отложенного проведения: На стороне 1С:Розницы документы записываются только в статусе проведенных по признаку или отправляются в специализированную очередь отложенного проведения БСП. Само фактическое формирование движений выполняется отдельным фоновым заданием небольшими порциями, не блокируя основной процесс приема данных.
Включение разделения итогов: Для высоконагруженных регистров накопления убедитесь, что включено свойство РежимРазделенияИтогов = Истина. Это снижает уровень эскалации блокировок при одновременной записи нескольких документов.
Оптимизация авторегистрации и переход к мелким пакетам
Штатный обмен пакетами по несколько тысяч объектов создает эффект «снежного кома»: если один документ из тысячи не провелся, весь пакет выгружается заново. Проанализируем правила регистрации и формат передачи данных:
Отказ от полной авторегистрации: В метаданных плана обмена для тяжелых документов и регистров установите свойство Авторегистрация = Запретить. Замените ее точечной регистрацией через подписки на события ПриЗаписи и ОбработкаПроведения, проверяя только существенные изменения реквизитов.
Дробление пакетов данных: Вместо одного гигантского сообщения раз в час разделите передачу на множество мелких сообщений (вплоть до одного документа на пакет) с частой периодичностью. Это позволит фиксировать транзакции СУБД практически мгновенно и распределит нагрузку в течение рабочего дня.