Заказчику нужен
"Учет взаиморасчетов с отсрочкой платежа по номенклатуре" (для каждой номенклатуры задается число дней отсрочки платежа).

Вижу решение через Оборотный регистр Расчеты (механизм остатков тут бесполезен, ибо считать их предстоит от ДатыОплаты)

Измерения: Контрагент,Номенклатура,ДатаОплаты, Ресурс:Сумма
Документы "Поступление" пишут в него плюсовые суммы, "Платежки" - минусовые

Кто сталкивался с подобным, не будет ли неприятностей в обозримом будущем при такой стуктуре данных?

Если в одной накладной будет номенклатура с разными сроками? Какая конфигурация?

Бухгалтерия будет оплачивать конкретную номенклатуру?
И документ отгрузки еще добавь

(0) пофиг на отгрузку, как оплату разносить?

(0) Если 8, то 1 регистр накоплений,1 регистр сведений,и подписка на событие.... это в случае если погашение по фифо, если ручное распределение то тогда таблицы погашения в документы прописать и обработку распределения платежей...

В дистрибуции продуктами питания стандартная фишка...

(1) УТ 10.3
(2) Точно, думал Регистратором обойдусь
(3) По ФИФО либо вручную, если будет нужно

(4) Таблица погашения фиксируется в ТЧ "Платежки"

(2) Бухи оплачивают суммой, которую спустят из коммерческого отдела, тут есть нюанс? Ожидаю юридических подвохов..

Распределение фифо автоматическое?

(4)Регистр сведений "РежимОтсрочкиПлатежа" для хранения числа дней отсрочки и Перечисления с указанием события, от которого рассчитывается дата (от начала след месяца, от даты Поступления, тысячи их)
А есть ли необходимость в регистре накопления?

(8) Автоматическое, если вручную в документе оплаты не заполнена ТЧ распределения

ой. а я подумал тут про украину

(1) разумеется, приход на 100 наименований одним документом ПоступлениеТоваровУслуг, он же двигает регистр "Расчеты"

(11) желтые ленточки закончились, утром обещают подвезти ))

(0) Я бы не стал делать механизм с потенциальными "петлями времени" и контролем последовательностей. Будь проще. Реквизит в справочник товаров и хватит.

(5) Если по ФИФО, тогда пофиг

(14) Петля времени не должная быть вызвана сменой условия отсрочки, если регистр условий периодический, если верно понял

(0) а в договоре, по крайней мере в УПП, вроде ж есть условия по которым можно задать "алгоритм" платежа и отсрочки.

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

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

(17) логично для типовых регистров, они все остались целы, тут более узкая задача и нагромождение сущностей излишне раздует базу и усложнит отборы, потому к регистратору и периоду только контрагент и его номенклатура
(18)ок, все движения буду  фиксировать в ТЧ

(18) (19) ну да, и обработку "распутывания последовательности" придется прикручивать, не дошел пока до подписки на событие, по всей видимости, событием будет проведение Поступления, а обработчиком - восстановление цепочки

(20) Вместо того, чтобы распутывать, можно просто не запутывать.

(21),(14) Обращаться в отчете по остаткам взаиморасчетов к "периодическому регистру сведений отсрочек платежа" для номенклатуры?
Боюсь потерять на этой экономии возможность планирования платежей, вот бы поподробней рассмотреть этот вариант решения.

Воплощаю (4), дистрибуция прессы