Задача четко знать когда будет запущен в следующий раз задача по синхронизации.
+- 1 минута..Файловый вариант.
Была идея  ставить четко время начала например 8-00 и запуск каждые 300 секунд, но все равно расписание стартует с момента входа в базу юзера.
Т.е. надо как то отлавливать расписание этого задания и самому рассчитывать ?

Нафига?

(0) в файловых никак, там в 1 поток все регламентные работают. Если перед ним запустится какое-то длинное по продолжительности, то все остальные курят в сторонке и ждут очереди.

(2) и да, в базе кто-то должен сидеть в это время.

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

(3) ну это розница в которой все время кассир сидит ))

Там может быть через N сек после окончания текущего.
А это узнать невозможно

Можно сделать не каждые 300 сек, а ручками прописать все времена

(4) Добавьте РС, ставьте управляемую блокировку перед пробитием \ запуском регламентного задания и снимайте после выполнения.
Перед запуском регламентного и перед пробитием чека проверяйте возможность установки блокировки.

(8) Не понял идею.. Зачем регистр сведений..
Отключать регламентное задание перед пробитием чека и потом при завершении пробития - это работает.
Но делать это при каждом пробитии чека, на мой взгляд некорректно.
Потому встал вопрос со временем, дабы понять что скоро может запустится обмен.

Кстати, а на каком объекте возникает пересечение? На таблице документа, регистра/ов или таблице изменений?

Важный момент, это происходит только при продаже ЕГАИС алкоголя. А у нас 90% чеков с ним..

Справочник.ЕГАИСПрисоединенныеФайлы.

Ошибка при добавлении присоединенного файла "faa54890-f7d8-43a0-b526-3b5459fdcea7.xml":
Конфликт блокировок при выполнении транзакции:
{ОбщийМодуль.ИнтеграцияЕГАИС.Модуль(1336)}:  ВызватьИсключение КраткоеПредставлениеОшибки(ИнформацияОбОшибке());
{ОбщийМодуль.ИнтеграцияЕГАИСВызовСервера.Модуль(908)}:     Результат = ИнтеграцияЕГАИС.ПодготовитьСообщениеКПередаче(Сообщение.ТекстСообщенияXML, Реквизиты, Немедленно);
{ОбщийМодуль.ИнтеграцияЕГАИСВызовСервера.Модуль(51)}: ВозвращаемоеЗначение = ПодготовитьСообщенияКПередаче(Сообщения, Немедленно,, ИдентификаторВладельца);

(0) > Задача четко знать...
Четко - не решается в принципе. Нечетко можно прикинуть с помощью метода ТребуетсяВыполнение() у объекта расписания.

То есть если у тебя каждые 5 минут регламент, то при начале пробития чека можно прикинуть с помощью этого метоад, не запланирован ли на ближайшую минуту (например) запуск регламента.
Но проще и надежнее использовать объектные блокировки (метод Заблокировать(), который есть у многих прикладных объектов) в качестве условного мьютекса для разруливания параллельных задач.
Удобно для этого завести служебный справочник, предопределенные элементы которого будут работать такими мьютексами.
То есть перед началом пробития чека и перед началом того, чего там фоновое делает - сначала пытаешься заблокировать мьютекс. Если эксепшн - значит уже занят. У объектных блокировок в качестве мьютексов плюс в том, что они никак не связаны с блокировками БД и при этом гарантированно снимаются при любых сбоях.

вся беда в "файловости".
запускай юзера под которым выполняются регламентные задания - и пусть висит все время.
добавь рс ТормозаДляФоновых, измерение имя фонового задания, ресурс разрешенное время запуска.
допили проблемное "фоновое" - при запуске проверяет этот рс, если время не пришло - стопорится до следующего запуска по расписанию, если время уже про(и)шло - стирет эту запись из рс и стартует.
(остальные фоновые тоже кстати удобно будет притормаживать при надобности)