Пятница на дворе, а я к вам с серьёзными вопросами.

Есть у меня потребность отслеживать некоторые процессы перемещения ТМЦ. Если абстрагироваться, то это перемещение чего-нибудь из одной кучки в другую. Перемещение растянуто во времени.
Когда процесс запускается, то определить когда он точно закончится можно только приблизительно, и по ходу дела время окончания может поменяться.
(типа "-Алё, сегодня не привезем, завтра привезем. Ну, край - послезавтра. Но до следующей пятницы точно")

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

В результате надо видеть на каждый момент в разрезе пунктов назначения и дат поступления сколько туда сейчас летит. Это для оперативного контроля.
А в историческом контексте интересно посмотреть, как оно ползло, с точки зрения уточнения планирования.

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

Может кто даст золотую идею, а то в меня уже кофе не лезет

добавить статусы партии. двигать дополнительно статусы по регистру. можно и в ресурс засунуть.

(0) Что-то типа "Заказ на перемещение". В нем храним плановые значения.
Атомарные документы "Перемещение" в разрезе заказа.
Опционально документ "Закрытие заказа на перемещение" для случаев, когда заказ закрывается вне плана.
Регистры по вкусу.

Классические "товары в пути".
ТоварыНаСкладах минус
ТоварВПути в плюс

(2) не указал (0) конфу - в УТ11 ордерной схемой это делается без доработок.

(3) даты, меня интересуют даты!

(0) видел в 7.7 реализацию через простое Перемещение, где все промежуточные операции через Склад делались. В том числе, каждая машина это отдельный Склад. Даты отслеживались по дате Перемещения

(5) ордерная схема - дата ухода со склада фиксируется ордером. Дата прихода тоже ордером. Это фактические даты. У ордера есть статусы и дата ордера это план приемки, дата приемки факт.

(7) у меня плановая дата двигается. И получается, что нужен остатщв разрезе этих плановых дат

(8) у тебя двигается фактическая дата, а плановая нарушается

(8) "Корректировка заказа на перемещение"
Ты от хозяйственных операций пляши.

(9) никуда фактическая не двигается. как уехало - записали, как приехало - записали, всё.

(10) хоз.операций тут всего две: ушло-пришло. мне-то интересно знать _когда_ оно придёт

Ну у тебя же есть документ который ожидает доставки (в нем реквизит), или реквизит не в нем, а в отдельном РС с одним измерением - документ. РС чтобы документ постоянно не перезаписывать.

(13) отдельно в измерение лучше не выносить - так система будет требовать восстановления последовательности если кто задним числом что-то поправит

А может задачу сделать и её двигать?..

История изменения плановой даты нужна?

(16) в историческом контексте нужна.хотят анализировать "промахи"

(17) https://its.1c.ru/db/utovio#content:188:1:issogl1_4-й_этап_подведение_итогов_процесса_перемещения_товаров
В заказе на перемещение ожидаемая дата - плановая дата доставки товара
В приходном ордере дата - фактическая дата получения.
Анализируй и не парься.

Отдельно хранить плановые даты, отдельно выполнение заказа

1 РС с каким нибудь ИД по каждой эпопее ресурсами НаСтарте, ВДороге, Прибыло и реквизитом Маршрут(справочник с ТЧ промежуточных точек)
+ ещё 1 РС с каждым шевелением груза: по этой ИД убыло из точки №4 в точку №5 тогда-то столько-то

ну и да справочник Маршрутов

и это только для факта, для плана можно сразу строить план и писать в РС такой-же структуры