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

тут дальше идут рассуждения ..
Наверное, правильнее сделать РС. независимый. непериодический (хотя тут надо подумать). С колонками типа - Заказ клиента / товар / <Отслеживаемый параметр1> / <Отслеживаемый параметр2> /...

ну и как все это отслеживать

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

есть идея?

может оно и так все есть и типа - отчетами просто попользоваться ...

Версионирование включить не вариант?

(0) Версионирование же есть

включено

но - оно отслеживает только 1 объект (определенный док .. определенный спр)
а тут связка параметров - которая зависит от проведения того или иного документа

На вот тебе почти ТЗ:
РС Статусы Документов. Можно периодичсеский. ВидДокумента, период, Статус - Перечисление.
При определенных действиях (запись, проведение, изменение) пишешь туда статус документа.
Затем, делаешь красивый отчет со статусами и отправляешь его ключевым или каким там сотруднкам. Естественно. отправку фиксируешь в другом РС, чтоб дважды не отправить.

(4)
мм ..
разжуй .. не понял ..

важен же не статус документа по1С - который клиенту не интересен.
клиенту интересен товар - его состояние ..
когда ждать от нас - чтобы начинать монтировать
и тд и тп

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

(7)+ ну да флажок какой-то нужен, чтобы примерно отслеживать

(6) можно в момент записи документа оценивать суть изменений и решать что делать рассылку или нет

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

ну вот как я вижу ..
РС.
при проведении документа Заказ клиента - в этот РС пишем инфо
- заказ клиента
- дата
- товар
- количество в заказе


потом - в этот РС при провеении поступления или реализации или ... - находим строку с нужным параметром - заказ/товар .. и пишем туда необходимо значение


Сразу возникает вопрос
- распровели заказ
- изменили состав заказа (товар убрали .. заменили .. добавили..)

что делать с записями РС ..

или ..
заказ клиента был сегодня. сформировались записи сегодня
а поступление через неделю. как искать - в какую запись установить - что товар пришел (сам ж заказ погли провести сегодня - появились записи в РС. потом провели завтра - еще раз записи появились ..)

(11) я бы добавил еще и тип документа, породившего изменения в заказе.
"а поступление через неделю. как искать - в какую запись установить - что товар пришел (сам ж заказ погли провести сегодня - появились записи в РС. потом провели завтра - еще раз записи появились ..)"
тот же заказ, только регистратор, ну, или еще одно измерения, ПТиУ. Ну и статус, какой тебе заблагорассудится.

блин ..
если искать последнюю запись и в нее писать информацию  что товара пришло столько то ..
тогда тут может быть так

01 01 провели заказ клиента. в РС записи появились.
02 01- перепровели заказ. записи еще раз появились. с новой датой.

10 01 утром. товар пришел. изменилась запись в РС от 02 01
10 01 в обед заказ перевроели ... и получается ж.
на состояние 10 01 вечер - есть запись в РС , но в нем не отражен приход товара.

(12)
разжуй ... не понимаю

я зациклился на одном видении ситуации
и не понимаю (

"01 01 провели заказ клиента. в РС записи появились.
02 01- перепровели заказ. записи еще раз появились. с новой датой.  "
А вот тут уже тебе решать, какое событие должно порождать записи в РС, а какое нет. При перепроведении ты можешь решить, необходимо ли менять статус заказа, или нет. И если не необходимо - смотроеть текущий статус этого же заказа, и, если он не изменился - не делать никаких движений.

что есть статус документа ?

Статус = перечисление ( Проведен, Удален, Записан) ?

(17) да вообще любой: готов к отгрузке, зарезервирован под отгрузку, аннулирован и.т.д.....

можно разжевать логику ?

проблема пока именно в том - что когда кто куда пишет ... кто что когда отслеживает ..

может сделать иначе
- делаем РС - список документов - которые были изменены сегодня (заказы клиента, постепления, рееализации товаров)
Событие документа - при записи .
РС - не периодический. Но не дублировать записи - если один и тот же документ перепроводится. Просто - этот документ был сегодня изменен.
(а может просто в него писать только заказы клиентов - которые были затронуты сегодня. Например, изменили поступление товаров. но по факту - по назначени. - есть заказ клиента - состояние которого было изменено)
----------
Вечером - роботом - смотрим все измененные документы - заказ клиента.
и составляем слепок ситуации не сегодняшний день.
Типа - заказ клиента такой -то . дата изменения - сегодня. список товаров. заполняем количество пришло/ ушло / заказано ...

составили.
потом берем сегодняшнее состояние и "вчерашнее"
сравниваем по ключевым параметрам ...
----------

?

ап

(20) ну вот смотри: у тебя ключевой параметр - заказ, состояние которого интересно клиенту. Ок, идем дальше: на состояние заказа влияет хоз.деятельность, а именно, изменение каких либо документов, связанных с заказом по критерию отбора.
Таким образом, состояние заказа меняется одним из типов дочерних документов.
Например, при записи ПТиУ по заказу отслеживаешь: если пришло, к примеру, более 50% позиций, то статус заказа, например, порожденный документом ПТиУ будет "скомплектован более чем на 50%". Ну, или что-то в этом духе. Тебе надо определиться:
1) какие вообще будут статусы у заказа (какие статусы нужны клиентам)
2) при наступлении какого события, должны меняться статусы
3) при наступлении каких статусов, необходимо отправлять оповещение клиенту.
как-то так...

Что должно приходить клиенту? Данные о измененных позициях или просто уведомление об изменении со всеми данными? То есть нужны ли данные что были изменены или хватит только реквизита об изменении?

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

(25) естественно все в ваших руках, можно сделать несколько ДС "Изменена ТЧ Товары", "Изменен статус" и тп, но создавать лишний РС достаточно избыточно

(0) Я бы разбил задачу на два этапа:
1. Информирование клиентов о статусе заказа: заказ принят, заказано у поставщика, товар получен, Заказ отгружен заказчику.
2. На этом этапе уже заморачиваться списком товаров.
2.1. Расписать, какие могут быть ситуации (убрали позицию из заказа, изменили количество). Что из этого важно, что не важно. Что нужно отслеживать, что не нужно.
2.2. Разработать механизм контроля только для "нужных" ситуаций.

(24)
клиенту должна уходить инфо до конкретного товара. не только общий статус по документу.

(26)
избыточность - да. так и есть.

(23)
не .. когда просто отслеживать статус целого документа и делать уведомление клиенту - это одно
тут даже вопросов нет - как это сделать.

с товарами - полная засада ..
особенно - если изменили состав товаров
провели
распровели
и тд и тп

(29) в хранилище? базе правда плохо будет

(30)
не уловил
что значит - в хранилище ?

(31) изв.. бегло прочел.

Чтобы реализовать то что ты хочешь, нужно включить версионирование(при проведении) и  сравнивать по нужным тебе метаданным эти документы, и если есть изменения по ним, то отправлять  уведомление на почту клиента. С регистром сведений такая вещь не прокатит. Еще продумать варианты закрытия месяцев, или при групповом перепроведении документов, так как событие будет отрабатывать. Для этого нужно делать дополнительные записи в регистр сведений при проведении, измерение(заказ), ресурс (булево или перечисление) истина\ложь | Отправлено\не отправлено. И если отправлено то пропускать, чтобы не было дублированных писем. А еще можно продумать как именно убедится что письмо действительно отправлено, а не пост фактум поставлен статус. Примерно как то так, не идеально, но как вариант.

(33) там версионирование не подходит

(34) По ним можно сравнивать документы, только для этого

(35) прочти всю ветку

(36) Увидел, это сложнее)

Можно проще обойтись, при проведении задавать вопрос Да\нет оператору, "Уведомить клиента о изменении заказа?". И просто отправлять текущую версию.

(38)
и вот клиент получает 100500 писем ..
из них
500 - по одному документу
400 по второму
...
...
..

как он потом будет определять - какое текущее состояние письма актуальное ?

(39) ну это уже совсем другое

(40)
да  - это называется - не уважение к клиенту

(41) согласен

(41) так кто мешает добавить дополнительную проверку? Если документ был изменен, клиент получит новый вариант документа, если нет, то и вопрос задавать не нужно (Модифицированность() )

(43)
коммент поставили
документ Модифицированность()=Истина
а толку для клиента = никакой

(44) Верно, можно свою проверку придумать. Вот есть статья на ИТС
https://its.1c.ru/db/metod8dev/content/2754/hdoc

Так и пихай свой изначальный док в хранилище значений и по расписанию по критериям сравнивай - надо/не надо

(0) Задача изначально неправильно поставлена.
Сначала нарисуйте всевозможные формы-примеры сообщений для клиентов с нужными данными, о которых уведомляется.
А затем уже пытайтесь решить как получить требуемую информацию для сообщения клиенту.

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

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

(47)
почему НЕ правильно поставлена задача?
это = задача.
и смысл - уведомить клиента 1 раз в сутки по всем изменениям по накладным в разрезе до товара - которые его касаются.
те клиент раз в денб получает письмо со списком только того  -что было изменено
- товар - ожидаемая дата поступления изменена с .. на ..
- товар - пришло на склад
- товар - отгружено
------------------------------------------
как тут отталкиваться от отчетов клиенту ?
если пришло ушло - еще можно наверное по  отчетам ловить
то реквзит тч документа - дата прихда = уже в отчете нигде не выведется.

и тд