Задача следующая:
Когда появляется реализация, контрагенту нужно отправить уведомление, чтобы тот подписал документ. Если через 5 дней подписания не произойдет, нужно отправить повторное уведомление.

Пока дошел вот до чего.
Измерение:
- Реализация
Ресурс:
- Статус (какое перечисление лучше? ОжидаетОтправки|УведомлениеОтправлено|ПовторноеУведомлениеОтправлено)

Чего не хватает? ДатаСледующейОтправки?

Дальше вопрос производительности. В фоновом задании будем брать СрезПоследних, где Статус В (ОжидаетОтправки,УведомлениеОтправлено). В индексы это дело попадет каким-то образом? Второй регистр лепить не хочется.

(0) Зачем здесь срез последних? Непериодический регистр сведений. Измерение: Реализация, ресурс: дата последнего уведомления.

(0) Начните с НАЗВАНИЯ регистра

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

Похоже на эдо. Изобретение велосипеда?

(4) прикручивать ЭДО ради отправки одного уведомления??

Лучше создать документ "Письмо", а в нём "Основание" со ссылкой на док. "Реализация".

(0) "Когда появляется реализация" - неправильно. Правильно - когда товар хотя бы отгрузился со склада. Или документ по ЭДО ушел клиенту.
Достаточно двух свойств:
- дата подписания документа контрагентом
- дата последнего уведомления

Да, видимо, историю проще в лог вынести. Всем спасибо!

(8) а-ха-ха...🤦

(8) Проще не значит лучше. В данном случае простота хуже воровства

(10) В чем проблема?

(11) Отслеживать по текстовым логам что-то на постоянной основе сомнительное удовольствие

(0) Справочник ИсходящиеСообщения

(13)+ РС обычный не периодический
СтатусыУведомленияДокументов

И регламентное для обработки
Еще подписки на события для документов

(14) СтатусыУведомленияДокументов - плохое название.
лучше УведомленияКонтрагентов

(12) Так а что там отслеживать? Наоборот, на всякий случай пусть будет.
В общем, посыл понятен, благодарю.

(16)
>> Так а что там отслеживать?
в (0) написано:
>> Если через 5 дней подписания не произойдет, нужно отправить повторное уведомление.

Как будете отслеживать 5 дней?

(18) Непериодический регистр
Измерение:
- Реализация
Ресурсы:
- Статус
- ДатаСледующейОбработки или ДатаПоследнейОтправки

Статус индексируем.

(18) Плохое решение.

измерение: реализация
ресурс: статус
1. при проведении реализации статус "создана"
2. при отправке клиенту статус "отправлена клиенту"
3. при повторной отправке статус "отправлена клиенту n-раз"
...
4. после ответа клиента статус "принята клиентом"

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

Чтоб отправить уведомление - надо сохранить где-то:
1) текст уведомления
2) кому
3) дата отправки
4) текст ошибки
5) и др.
В любом случае потребуется документ "Исходящее сообщение".
Даже регистр не нужен особо, если только для ускорения

(19) Аргументы?

(20) И как фоновое задание будет отбирать то, что нужно отправить?

(21) а я предлагал в (6)

(22) слишком частное

(21) С простой отправкой уведомлений проблем нет, вопрос не про это

(22) при периодическом регистре срез последних, где статус <> "принята клиентом"

при непериодическом РС придется делать запрос с соединением с самим собой по максимуму даты события

если не нужен аудиторский след, то хватит примитивного варианта с одним измерением (реализация) и двумя ресурсами (дата отправки клиенту, дата ответа клиента).

(26) Про СрезПоследних я писал в (0), последний абзац.

Стандартные реквизиты:
- Период

Измерения:
-Документ

Ресурсы:

-Сообщение
-Условие повтора (понятное для трансляции, хоть кодом, например, "документ.Подписан = Истина")
-Период повтора

Читаем все сообщения через срез последних (их всех удалим)
Те у которых условие не сработало, пишем обратно с новым периодом. И т.д.

Период можно вынести в измерение "дата" чтобы читать/удалять наборами, срезы тут особо не нужны.

(28) 👍 Да, это уже более общее решение, которое охватит больше документов и больше сценариев. Это более архитектурный подход. Решение более устойчиво к дальнейшему развитию и пересмотру.

Можно добавить ресурс "Количество сообщений отправлено" если очень хочется узнать сколько раз игнорили, и его каждый раз в +.

(0) Решение от ChatGPT 4o ниже:

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

Измерения:
* Документ (тип документСсылка)
Ресурсы:
* Статус (перечисление ОжидаетОтправки | УведомлениеОтправлено | ПовторноеУведомлениеОтправлено, см. ниже)
* ДатаПоследнейОтправки (дата, отражает последнюю дату уведомления)
* ПлановаяДатаСледующейОтправки (дата, когда нужно отправить следующее уведомление, если нет реакции)

Статус:
* ОжидаетОтправки — еще не было отправки уведомления.
* УведомлениеОтправлено — уведомление отправлено, но требуются проверки на подпись.
* ПовторноеУведомлениеОтправлено — отправлено повторно, но подписания по-прежнему нет.

Запрос, который покажет документы, по которым надо отправить уведомление прямо сейчас:

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

Запрос выбирает документы, по которым либо еще не было отправки, либо истек срок ожидания подписания, и требуется отправка нового уведомления.

Такой подход обеспечивает гибкость в работе с различными типами документов и их состояниями.

(32) Отбор по Статусу индекс нужен

(33) Не поможет. Здесь уже СрезПоследних
А может поможет...
Ну можно добавить, чтоб наверняка

(30) Про запросы в циклах и тормоза не понаслышке знаете, смотрю
1С Предприятие замедляется, 1С Executer ускоряется. Обсудим будущее 1C Предприятие 8...#41

(32) (34) Садись, два