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

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

я вижу 2 алгоритма
1. без дополнительных регистров, берем остатки и по лифо отматываем обороты отгрузок назад, к результату прибавляем период товарного кредита
2. мутить дополнительный регистр в котором документы будут писать период равный дате планированной оплаты и потом простая выборка

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

какие будут мнения?

(0) взаиморасчеты по документам расчетов?

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

(2)+ в реальности у нас учет не по договорам а по "сделкам", это не договор и не документ учета, это что-то среднее...

(2) Тогда все остальное лажа.

(2) тогда по сути ты в своем регистре (который п.2 ) будешь изобретать велосипед уже реализованный механизмом учета взаиморасчетов по расчетным документам.

(5) нет, регистр нужен по тому, что период другой...

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

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

(6) Дебиторка в разрезе отгрузок с отсрочкой оплаты и есть планируемые поступления :)

Конфа вообще какая?

(0) ИМХО, в таких случаях выбираю обычно вариант:
"отчет как 3 копейки, но зато нужно все пересчитывать при движениях задним числом или изменении периода товарного кредита."

Т.к. "тяжелый пересчет" при необходимости можно повесить на регламентную обработку (восстановление последовательности, перепроведение на сервере и т.д.), зато пользователь (в отчете) получает результат БЫСТРО.  
Пусть "железо" работает, а люди довольны мгновенным результатом. Разве не это наша ОСНОВНАЯ цель? ;)

(8) самописка с 0

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

сабж именно в этом, заворачиваться с пересчетами или делать сложный отчет...

(9) тут вопрос валидности данных... изменил параметр а пока регламент не отработает отчет все равно старый...

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

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

(11) "а регламент может и тупо встать на пару суток, бывает такое..."

Если регламент это будет делать "двое суток", то отчет из "пункта 1" почему быстрее сформируется?

Зато "регламент" сделал один раз, зафиксировал информацию в регистре и всё, можно пользоваться.

А если отчет (из п.1) сформировали и потребовалось переформировать, опять ждать? ;)

На мой взгляд, преимущество в любом случае за "регламентом".

PS в отчете можно вывести признак актуальности информации.

(10) если ведение взаиморасчетов по расчетным документам - то такое изменение периода отсрочки ничего принципиально не меняет в отчете - пользователи увидят новую реальность с учетом нового периода отсрочки - осталось тебе только реализовать этот типовой механизм в своей конфе

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

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

Если в бухгалтерии такое находят бухи и исправляют, в торговле это будет задница, такая аналитика никому не нужна здесь и ее никто не будет отслеживать, а на отчетах "по сделке" такие минусы будут давать очень интересную картину, если учесть, что все это влияет на начисление бонусов от продаж, то мне этого крайне хочется избежать.

(16) Вы пытаетесь в условиях бардака получить правильные цифры?

(17) да, именно так... И самое главное навести порядок вариантов нет, нужно работать с тем, что есть...

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

(18) Сочувствую.. Бегите оттуда.

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

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

(20) Угу... И в сданной ранее декларации по НДС в налоговой он тоже поменяется автоматически..  И в платежках он поменяется, и оплаты перезачтутся.... Автоматизация, куле!

(0) Я сделал 1.
Полгода как, жалоб нет.

(21) при чем здесь взаиморасчеты по расчетным документам и декларация по НДС - которая строится совсем по другим регистрам

Ознакомился.
Поржал.
Проходил не раз.
Варианта работы два в условиях бардака:
- пусть правят задним числом что угодно, но при наличии нарушения 9а его можно "вычислить" - ПОЛНОСТЬЮ БЛОКИРОВАТЬ ТЕКУЩУЮ РАБОТУ. то есть приводить к порядку.
- в рамках одного договора на сейчас суммировать долг и аванс . Получили итоговую цифру. Разматываем ее назад по документам. Из документов получаем план. Никаких допмеханизмов я бы не вводил (там тоже будет бардак). А расчет назад - обсасывался уже много раз, на ИС есть хорошие статьи прям с идеологией и примерами как это получить быстро.
.
а можно тупо строить палан даже с нарушениями. ну вылезут нарушения в отчете в виде какой-то цифры - ну и что? кто за правильные цифры отвечает? перед формированием отчета выплевывать типа "данные нарушены, отчет будет недостоверный" - и эту же надпись обязательно в печформу

(0) У нас например франчи засунули срок отсрочки платежа в реквизиты документов реализации. Хочешь из документов бери, хочешь из договоров...

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

(24) наверно это для меня самый понятный ответ в данном топике, сам думаю точно так-же.

(0) Переходите на БП 3.0 там это реализовано.

(0) я делала учет по докам расчетов + свой регламент авторазноса задним числом

(10) матом ругаться, что еще-то?
что мешает не делать задним числом таких изменений?

(18) какой тогда им нахрен учет?