Алгоритм построения обратной цепочки по переделам.
Доброго.
Задачу опишу по аналогии с производством, нужен сам принцип, алгоритм как такую задачу решают. С деталями реализация я сам разберусь.
Есть такая цепочка документов, берется некое сырье, из него делается полуфабрикат. Классический производственный передел.
Списывается с остатка одна номенклатура, на выходе другая номенклатура, доком генерируется партия.
Потом идет несколько разного вида доков со своими движения, но общее, что мне нужно у них всех одно. На входе списывает один полуфабрикат, вот тут важно, обязательное указание входной партии в документе, на выходе другой полуфабрикат, с генерацией партии.
Партия в принципе упрошено генерируются про признаку один день одна номенклатура, с неким свойством это одна партия. То бишь есть в один и тот же день было несколько доков, с одной номенклатурой и одинаковыми свойствами, то это одна партия.
И так до выхода, готовой продукции. Переделов может быть до 10.
Необходимо отследить. Всю цепочку от готовой продукции.
Конфа нетиповая, делать можно все что угодно. Так что любой вариант годится. Ограничений на доработку конфы нет.

(0) Реквизит ПартияРодитель

"Необходимо отследить. Всю цепочку от готовой продукции"
- ну и что надо-то?

(2) из какого сырья делали.

(1)Куда его прикручивать?

(0) Насколько я помню, у нас было так:
1. Есть передел (на входе одно - на выходе другое). Отражает факт производства.
2. Есть общая калькуляция без переделов.  Служит для плановых расчетов "туда и обратно".

(5) Мне не калькуляция нужна. Мне вся цепочка доков нужна. То бишь видит эту готовую продукцию сделали из этого сырья по вот этой цепочке.

(4) В партию конечно же.
И будет у тебя цепочка
Партия1 - Партия2 - Партия3 и т.д.

(6) Ты путаешь документы с партией.
У партия != документ в общем случае

(6) Цепочку мы тоже пытались раскручивать. Потом отказались от этой идеи.
Слишком много неоднозначности.

(7) У меня партия это справочник. Причем не один а несколько, так как партии независимые сущности, и генерация идет по сложным условиям.
Но в принципе решаемо, реквизит составного типа будет.
У меня уже есть регистр сведений уже где я сделал, соответствие входящей партии и исходящей.  
(8) Это понятно.

(9) Вот для этого всю эту бодягу и затеяли, нужна однозначность.

Не очень понял проблему. В чем отличие от разузлования?

(12) А есть где описание этого замечательного алгоритма?

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

(11) Вот тебе реальный пример (производство колбасы и п/ф):

1. Получили 3 туши коровы, 5 туш свиней.
2. Разделали. На выходе получили мясо по сортам.
3. Подготовили п/ф. Мясо взяли часть из текущей партии, часть из прошлой.
4. Подготовили фарш. Сырье взяли часть из текущей партии, часть из прошлой.
5. Засунули фарш в оболочку. Один и тот же фарш может пойти на разную колбасу (разная фасовка).
6. Отправили в темоотделение (варка, жарка и т.д).
7. Остудили, отправили на склад.

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

ну если втупую - перебирать доки с упомянутыми партиями

(15) Берем партию колбасы (7). Находим последний передел по прямым сырьевым затратам (5). Определяем долевое соотношение партий фарша по этому переделу. Дальше идем по истории фаршей (4). Определяем долевое участие партий сырья по каждой партии фарша, пошедших на производство колбасы. И так далее. Ничего сложного, если нет зацикливания.

(17) Вот тоже не понял в чем проблема.

Как раз по колбасе делал рекурсией. Более простого варианта не придумал.

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

(19) Так и разузлование тоже рекурсией делается.

(15)А у меня на входе грубо говоря толька коровы, вот мне и надо знать из какой коровы эта колбаса. Как это сейчас модно типа блокчейн.

Ну вот я пробую руками запросы наколбасить.
Шаг один. Запрос_1
Отбор по регистратору(выпуск готовой продукции), нахожу типа входную партию в этом доке.
Шаг второй. Запрос_2
Отбор по ранее найденной партии и виду движения - приход. Нахожу док создавший партию из шага 1.
Шаг третий. Запрос_3
Отбор по ранее найденному доку из шага 2 и виду движения - расход Нахожу партию входную к этому доку.
Шаг четвертый. Запрос_4
Отбор по ранее найденной партии и виду движения - приход. Нахожу док создавший партию.

Ну вот как-то так.

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

Чтобы понять рекурсию, сначала нужно понять рекурсию.

(23) Вот шаг 2 и 3 и сделай в рекурсии)
Только ограничь ее глубину, на всякий случай.

Запросы в цикле, да еще и в рекурсии.
Вы же сами мне руки за такое оторвете.

(27) Тада фигач транзитивное замыкание)))

Мы сделали так. Фиксируем выходную номенклатуру и входную в регистре.
При выгрузке ищем в регистре по выходной номенклатуре входную и так пока не дойдем до начала. Получается дерево. На 1с работает крайне медленно. СКЬЮЭЛЬ программист написал хранимку. Работает в цикле. 50 номенклатуре по где-то 8 переделаем меньше секунды. С учетом того что разузловывет еще и по номенклаутре и по серии.
Основная проблема, с которой столкнулись - посчитать вес, который пошел на партию из другой партии. А именно так нужно в Меркурий выгружать данные оказалось нереально по факту. Есть переходящие остатки, еще какой-то шлак. В результате вес считаем по плану, по спецификациям.

Кстати, в ЕРП есть разузлование номенклатуры?

(13) Общие понятия с некоторыми конкретными реализациями на SQL тут:

https://www.red-gate.com/simple-talk/sql/t-sql-programming/the-sql-of-parts-explosions/
https://www.ibm.com/support/knowledgecenter/en/SSGNPV_2.0.0/com.ibm.db2.luw.sql.ref.doc/doc/r0059242.html

рассмотрим задачу математически.
пусть у нас продукция - это пратия продукции,то есть поивязанная к дате и т.п.
одна продукция собирается из другой
есть спецификация,где сказано как это делать,но в специкации не сама продукция,а типы продукции,также в зависимости от входных типов спецификация будет разной,но это в любос случае пропорция входных продукций для выпуска выходной.
по спецификации делается выпуск,то есть результат производства,здесь классы пррдукции преобразуются уже в саму продукцию,которая идет на вход.
то есть Ki*Pi- это входной набор,где K это количество,а P это конкретный вид продукции.
на выходе имеем Kr*Pr определенное количество выходной продукции.
далее,все производство оптсывается набором таких соотношений.
при поиске мы начинаем разворачивание данных соотношений,пока они не кончатся.

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

на самом деле,систеиа имеет решение только из-за закона сохранения массы или энергии.
если 2x+3y=6z,то может и не получиться.
просто,готовая продукция может заменить часть сырья,но это,по сути,добавление прошлого сырья,так как в производственном процессе,то,что выпускается может пойти ч сырье только после выпуска.

В обще делаю регистр сведений, куда доки будут записывать входящую партию, и соответствующую им исходящую.
Потом обработкой будет привязан последний док.
Другого вариант тупо не придумал.