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

а тут такая фигня
В этом году приняли новую фишку, если у нас продукция из винограда выпущена, а не покупного виноматериала. То можно вычитать из акцизов.
Вот заносятся доки начиная с 2009 года.
Поэтому надо пересчитывать все.
Отсюда я и озаботился ростом базы, база то расти дико стала.

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

(0) Я бы решал эту задачу совсем не так
тебе нужен признак партии.
Почему бы не использовать в качестве признака партии характеристику например.

(72) в самописке дописать функциональность характеристик?

(73) можно из БСП подлить

(45) в этом суть технологий блокчейн

(71) Дык новые доки забиваются, лет так за 10 надо все восстановить. У нас коньяки есть 15-20 лет выдержки.

(72) Вопрос не что пользовать в качестве хранилища значения.
А как восстановить цепочку идя с конца.

(77) какой смысл, или у тебя учёт есть или его нет

(72) характеристики самый неудачный пример

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

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

(80) У вас автоматизирован расчет нормативных и фактических потерь спирта и(или) виноматериалов при хранении/производстве/перемещении?

(81) Ок, а какой алгоритм заполнения этой характеристики?

(83) тупо свойство характеристики некий номер партии

(84) Партии при переходе через передел меняются.

(84)+ и этот номер проходит по всем твоим пф и материалам

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

(82) Да есть такое, кучу справочников нормативов, температурных поправок загнали. Долго воевали, но осилили.

(87) Ок, это тупо будет некий реквизит. Как мне его заполнить?

(89) если используешь автоподбор по характеристикам то заполнять не надо - само должно заполняться
если нет - то делаешь дерево спецификаций с помощью своей приблуды типа "Конструктор спецификаций" из УПП

(90) Тугой я видно совсем. Не силен я в характеристиках. Это что у них за магия такая, что я узнаю, при выборе например некого виноматериала в какой он готовый купаж пойдет. Если крайний случай взять, купаж еще не выпустили. А будет он только через год например?

(91) если на этот купаж есть спецификация с автоподбором характеристик - то не проблема.

(92) в том же и проблема - купажи в виде спецификации не составляются до того, как они образовались на производстве.
Это "живой" процесс. Или по другому сказать пост-фактум.

Не нужно еще забывать о том, что спецификация не просто состав табличной части, но и количество на каждой позиции из состава. А тут купаж создается "в живую".

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

(92)(93) Зачем использовать спеки для этого дела

Я пока так и не увидел в чем проблема всей задачи

Вообще, можно попробовать что-то типа ключей РАУЗ организовать. Т.е. состав партий хранится в РАУЗ, а ссылки на ключ - в регистре. Только придется как-то разбить на определенные этапы тех. процесс, чтобы ключей не получилось слишком много.

Ну кроме неизвестных мне процессов, которые вызывают какой-то сумбур в голове постановщика

Не можете описать, нарисуйте схему купажирования и опишите все отклонения от схемы, вообще от блок схемы не отличаться не будет

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

(0) Это жизненный цикл изделия. PLM. Попробуй подглядеть у производителей Сименс: Teamcenter или такой продукт как Windchill. Наши не делают. Только только доросли. Это по состоянию на 2012г. Как сейчас не знаю.

(99) Это ты прав, правильно заданный врос содержит половину ответа.

Ну давай так. Один купаж. Без эгализаций. Упрощённая схема. Может я и сам соображу.
Получили виноград.
Несколько партий. Сгенерировали новые партии. Один виноград, одни день - это одна партия.
Переработали на сусло.
Тут пока просто, переработка идет сразу практически. В идеале получается одна партия винограда на входе одна на выходе.
Сгенерировали новые партии. Одно сусло, однин день - это одна партия.
Дальше оно тама бурлит.
Декантация. Вот тут уже сложнее. Сливается с нескольких ёмкостей в одну.
То бишь несколько партий сусла - одна партия виноматериала.
Сгенерировали новые партии. Один виноматериал, однин день - это одна партия.
Дальше перегонка на спирт.
Колона много вмещает, поэтому за день всю партию виноматериала могу не переработать.
И получается дробление
Одна партия виноматериала- несколько партий спирта молодого.
Сгенерировали новые партии. Один спирт молодой, одной крепости в один день - это одна партия.
Дальше заливают его на выдержку.
По бочкам, бочки небольшие. Опять дробятся партии.
Одна партия спирта молодого - несколько партий выдержанного спирта.
Сгенерировали новые партии. Один спирт выдержанный, одной крепости в один день - это одна партия.
Далее купаж. Где куча спиртов выдержанных собирается в одну партию.
Сгенерировали новые партии. Один купаж, одной крепости в один день - это одна партия.

А теперь надо узнать всю цепочку до винограда.
То бишь в один купаж может быть до пару десятков партий винограда.
И наоборот одна партия винограда может быть в десятке купажей.
Плюс в дороге куча сливов, переливов, различных обработок.

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

А еще не просто узнать что из какой партии хотелось реализовать, то и чего сколько было в цепочке было по количеству. Но это уже потом.

(103) Какую типовую знаешь?

УПП или ЕРП?

Это не надо
Сгенерировали новые партии. Одно сусло, однин день - это одна партия.

(103) Пользователь хочет жмакнуть на купаж...
И получить всю выше описанную цепочку/// и Вы это хотите всё "по правде" реализовать?

(103) Это очень похоже на многопередельное производство
а искомое дерево похоже на построение себестоимости по заказу.
Поэтому методики позаказного учета в производстве УПП (ЕРП) могут вполне подойти

В моем багаже есть работающие производства которые реализуют методику позаказного учета (УПП) с учетом характеристик
Сейчас занят как раз тем, что пытаюсь этот же подход реализовать в ЕРП 2.4

(108) Это базовый функционал, что ты там пытаешься?

(95) вас пугает тысяча записей на документ?? реально?
я наверное совсем отстал от жизни но в 7ке десятки тысяч записей это нормально абсолютно
а тут 8ка, с соответствующим железом, тут миллионы должны перевариваться без проблем.

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

(97) не мешайте человеку нетленку свою писать. Этот этап должен пройти любой программист.
(0) - то вы хотите давно реализовано в куче пищевых конфигураций. Проводите ключевые слова "1с, прослеживаемость, ХАССП". Посмотрите цикл вебинаров  http://inthepress.ru/press/p442198.html

Вообщем не майтесь фигнёй, либо подберите-купите конфу специализированную, либо посмотрите в них типовые решения.
Общее решение - простейший регистр накопления типа товаров на складах. Партия = серия. В регистр добавляются только РЕКВИЗИТЫ типа КорПартия, КорНоменклатура, в которых фиксируем серию, из которой пришло или в которую ушло.

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

Чо тут, чо тут, новая фузина? :)

(105) С УПП работаю.

(107) Я это уже реализовал. Вопрос как сделать более лучше что ли. алгоритмически правильно. Типа так.

(115) Алгоритмически правильно использовать регистр накопления с использованием принципа двойной записи (по типу учета затрат в УПП)

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

(113) Нет, старая добрая 1С.

(116) А подробней плиз.

(111) Ну так у меня это построитель раз в час запускается. Не вижу разницы.

(106) Почему это не надо партии генерировать? Очень даже надо.
Мы каждый передел делаем анализы и пишем отчеты для контролирующих органов.

(117) Вот у меня есть судоремонт/// у меня что-то среднее между судоремонтном и виноделием :)
Сырьё практически в полном объеме сливается в общую партию...

(119) не будет от него подробней - он больше тролль, чем спец. Успел в Политике набросить хх-а с лопаты и ушел отдыхать.

(122) т.е. да, как в (106) я ж и спрашивала -- неужели в программе надеетесь реализовать всё "как в жизни"?

(123) т.е. на одного специалиста меньше :(

(117) механическая сборка все-таки допускает разборку некорректно собранного элемента - разукомплектация.

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

(125) ну... если чел в чем-то идиот... ну это весьма сомнительный "специалист" - зачем он нужен?

(114) Ну значит открываешь УППшный учет серий и куришь его, документ для всех процессов-Комплектация

В серию дописывается вкладка- состав с гиперссылками на документы партии исходники, и все, счастье настало

Из бонусов, еще и себес посчитается

Ну давай вот на декантации попробуем.
На входе несколько партий сусла. Технологи посмотрели и давай говорят чуток из той партии, чуток из этой, а эта не влезла.
Пусть будет три партии сусла на входе. И одна партия виноматериала на выходе.
Ок, я делаю Комплектацию.
И в серию, ну которая типа партия виноматериала пишу док декантации такой то.
Правильно понимаю?

блин я уже 10 раз написал что надо сделать, не понимаю какими еще надо словами чтобы понятно стало.
есть документ 1 - виноград в сусло
док2 - сусло в куда то там еще
док3 другой виноград в сусло2
док 4 смешали 1 и 2 получили 3
док 5 смешали 1 и 2 в других пропорциях получили 4

в итоге пробежав по цепочкам заполнить регистр в котором будут по партии 4 привязаны документы 1 3 5
по партии 3 привязаны документы 1 3 4

и по обратной задаче к винограду1 привязаны доки 1 2 4 и 5
к винограду 2 доки 3 4 5

ну?

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

(130) Все правильно

Хотя нет, туплю, ты в серию пишешь не документ, у партии уже есть документ, ты в серию пишешь партии которые пошли на деканации, а они у тебя есть в сериях уже ;-)

Можешь писать и пропорции

(131) Не, я явно тупой. Ну не понимаю я как ты предлагаешь по партиям пробежаться. Ну прости меня такого тупого. Ты молодец, спасибо тебе.
Я еще раз перечитаю твои сообщения. Может въеду.

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

Кажись понял. Дайте пару часиков я тут покручу у себя.

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

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

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

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

(140) там зачем-то чистится все. я так и не понял зачем.

Тогда такая схема у меня вырисовывается.
Справочник Партии(уже есть)
Реквизиты
Номенклатура – ссылка на справочник номенклатура
Дата – дата партии.
Крепость – число.
Ёмкость – ссылка на справочник места хранения.

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

Переработка винограда.
При заполнений дока оператор обязательно указывает партию виноград. Там просто сканирование ТСД. Плюс всякие расчеты в доках, буду опускать.
При проведении дока, списывается виноград, появляется партия сусла. Генерируем партию сусла аналогично как у винограда. Одно сусло и одна емкость, где оно бродит это партия. И в партию пишем партии винограда.

Декантация.
Сусло перебродило, сливаем готовый виноматериал.
При проведении дока списывается  партия сусла. Генерируем партию виноматериала. Один виноматериал, одна крепость, и одна емкость. И в партию пишем партии копируем партии винограда из партии сусла, и пишем партии сусла.

И так погнали дальше, на каждом переделе копируем данные по партиям из партии входа и пишем свою сгенерированную партию.

По итогу в Партии купажа будут записаны все предыдущие ему партии.

Тут вот вопрос сразу возник, где лучше это хранить, табличная часть справочника Партии, отдельный справочник подчинённый справочнику Партии, или регистр сведений?

(142) Потому что данные задним числом вбивают. А регистр быстрее грохнуть, чем искать записи и перезаписывать.

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

А так с тебя 50к

(145) Чего я упустил?
Бардак не у нас. Бардак нар РАР устаивает с ФНС на пару.

(146) За что? Не жадничай. У меня зарплата меньше.

(148) Это Стимуляция была, а не то ты начал внимательность терять

Вот с Этим надо поработать

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

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

(147) Они не могут с тебя потребовать партию винограда в 1905 году, такого учета просто не было, значит вы или не вели его, или чего-то не понимаете

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

(152)в дороже так сказать = в дороге так сказать

(144) Быстрее оно на удаление быстрее. А как заново создавать, так и не быстрее ни разу. Впрочем, в тч справочника или документа оно пишется примерно с той же скоростью, если по одному писать. Смотря что изменяется и сколько. Можно отбор делать по значению измерения.

Тут вот вопрос сразу возник, где лучше это хранить, табличная часть справочника Партии, отдельный справочник подчинённый справочнику Партии, или регистр сведений?

Это не ко мне вопрос, я конфигуратор открывал 3 раза

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

Тут вот вопрос сразу возник, где лучше это хранить, табличная часть справочника Партии, отдельный справочник подчинённый справочнику Партии, или регистр сведений?

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

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

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

Регистр сведений, это если по методологии 1С.
Отчет строить на данных регистров надо.

(159) Дык вот чего я сюда и пришел. Не хочу я постоянно базу пересчитывать.

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

Физически, что регистр, что таблица табчасти справочника дают одинаковый эффект при получении данных. Но наличие измерений в независимом РС даст еще более свободную функциональность.

Значит будет регистр сведений. Независимы конечно.
Большое спасибо народ за обсуждение и советы.
Пойду пилить.

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

Но я бы еще и оборотный регистр крутанул. Сведения оно прикольно, по оборотный интересней. Конечно, при наличии измеримого ресурса.

(166) А что в оборонный писать?
Партионый учет у меня есть уже регистр накопления, остатки.

(165) Так я доки в последовательность загоню. Буду только теперь от последнего перероведенного дока перестраиваться.

(168) и запрет конечно включу.