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

(0) Приглашайте спеца и готовьте деньги.

(0)[и ему скоро хана будет. ] +[Правило генерации партии, один сорт, один день и одна переработка  - это одна партия.]
нормальное решение, если партия справочник или документ, грохать Рг не надо

(2)Партия в справочнике
А грохнуть его быстрее чем искать и перезаписывать.

(4) топик то о чем ?

через справочник типа ключ аналитики номенклатуры при проведении документа для новой партии туда пишем номенклатуру реквизиты новой партии и ссылку на входную партию (этот же справочник)

(5) Топик как сделать лучше.
Я сейчас всю базу перерываю.
Что пока она мелькая незаметно, но дальше будет дикие тормоза.

(6) Это я уже сделал.
Как мне теперь от конца к началу цепочку построить?

(7) Осталось угадать что за базу и что уже сделал. Остальное легко.

(9) Не надо ничего угадывать.
Обычный партионый учет, по методу ФИФО.
Документ пердела генерирует партию. Все.
Есть Регистр сведений в котором пишется соответствие ПартииВхода ПартииВыхода

(10) Документ пердела = Документ передела

(10) У ПартииВхода всегда только одна ПартияВыхода?

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

(13) А какая структура у регистра сведений?

Получается не меньше четырёх измерений: Инградиент, Партия входа, Партия выхода, Изделие

(14) Да любой нарисую.
(15) Ну да, Виноград, ПартияВхода, ПартияВыхода, Купаж.
Виноград то понятно как заполнить, можно предавать из партии входа при проведении дока.
А Купаж как?

На входе.

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

Партия на входе - в самом начале это документ Закупка или отчет сборе винограда

Потом что-то там происходит.

Вопрос в топике: как увидеть с чего все началось? Так вот поясни, что начинается с самого первого документа или начинается с некоторой позиции спр Номенклатура ?

Да, можно вести вход1-выход1 -- вход2-выход2 и т.д. Но тогда получается, что сквозным элементом для измерения является Виноград, а не Партия. Партия все время подменяется.
Ну да, ну можно восстановить от выходов ко входам, но это получается классическое восстановление Дерево значений в запросе.
Родительский элемент не должен содержать ссылку  на родителя, а у остальных эта ссылка не пустая.

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

Купаж это всегда из множества партий входа в одну партию выхода.

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

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

На каждом этапе может быть Эгализация, сливаем несколько партий в одно, тоже док передела.

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


У меня сейчас сделано два регистра сведений.
В одном с сопоставляю партии входа, партии выхода, если партий входа несколько то и записей несколько.
потом беру доки купаж и второй регистр цепочка.
Пишу так Купах партия входа партия выхода уровень 1.
И погнал цикл, ищу с первом регистре по партии выхода партию входа, и это уровень два
и так пока до конца не дойду. по бишь по уровня хожу.
Бывает шесть, максимум есть 32 уровня.

(0) переходи на ерп, там все реализовано

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

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

+21 Это был вариант "фактического рассчета".
Для планового расчета можно завести рецептуру и считать по рецептуре.

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

хотя стоп от конечной, тогда деревья строить, да.

(20) Нет, конечно.
Посмотри на это вот с какой стороны: в ERP этот функционал уже придуман и разработан.
Да, ты можешь сделать свой, "с преферансом и куртизанками", но почему ты решил, что твоё решение будет лучше?

Открой ERP, посмотри структуру данных. Не знаешь, как сделать - стащи идею из ERP.

рекурсивно в обратную сторону.
берем партии конечной продукции. потом партии для партий полуфабрикатов и тд до сырья

(25) // стащи идею из ERP.

И будет как в анекдоте про хрустальный х...

з.ы. Чтобы стащить идею из ERP на разузлование этапов производства - придется тащить очень и очень много.

Тут немного другая специфика. Отраслевая. Если что-то пытаться тащить на уровне идей, то нужно не просто ERP, а отраслевку для хим-производств или фарм-производства.
Но оно все равно не подойдет.

Виноделие работает с "живым" продуктом. Если Kongo2019 будет в настроении, то он возможно расскажет, что такое работать на "живом" вине или виноматериале.

з.з.ы Это намного больше заморочек, чем дистилят из браги выгонять

(27) Много букв, но сути не увидел, где проблема построить сквозную цепочку?

Могу хоть на ЕРП голом его построить без ФИФО, или УПП

(20) Может ты меня начнешь грузить ;-) У меня как бы специализация, жаль вино пить нельзя ;-)))

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

(28) Проблемы построить цепочку нет. ERP для этого не нужен.

(32) Вот и я думаю, где вы нашли проблему построить цепочку документов

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

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

(35) А если _каждый_ передел из начала производственной цепочки попадает в _разные_ финальные партии готовой продукции?

(0) В данном случае при большом объеме данных задачу придется решать итеративно.

(31) Там обычно связь многих ко многим, и это все усложняет.

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

(38) Ну он же не сказал, что все партии полностью расходуются в один купаж. Могут взять 10% от партии, например. И эта партия в 10 выходных попадет. А другой сорт возьмут 1,5 партии.

(38) см (18) он там уточнил описание из топика.

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

(40) И задача обычно учесть все промежуточные этапы, чтобы если всплывет косяк - определить какая партия (или партии) косячная и отозвать всю готовую продукцию, где использовалась косячная партия (партии). Т.е. отчет должен в 2 стороны работать.

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

(41) угу. Потому что эта "готовая продукция" еще какое-то время находится в бочках, а уже бутилирование бывает много позже.

А если не рассчитывать отчётом, но сразу хранить текущий состав каждой партии? И при образовании новой рассчитывать её из состава образующей партии? Может там и потери сразу будут видны.

(44) избыточность. 32 передела и в каждый тащить все предыдущее - зачем?

(46) А какая тебе разница?

Можешь расчитывать, можешь хранить

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

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

(45) Не в каждый, а текущий.

Давай на примере?

Вырастил я тёрн. 20 килограммов. Это Партия1.
Развёл 1.6 кг спирта и 4 кг воды. Это партия2.
Залил на неделю половину тёрна, "на глаз" сахара (пишем 3 кг) и половину спиртосмеси. Получил 8 литров, то есть 7 кг, настойки составом (Тёрн, 10)+(спирт, 0.8)+(вода, 2)+(сахар, 3) -это Партия3. И на остатках есть 1/2 партии1 и 1/2 Партии2.

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

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

Допровоедение в принципе хорошая идея.
Только это не реквизит надо делать регистр сведений, так как один и тот же док, может попасть в разные купажи.

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

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

(53) Фишка то что в разных бочках

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

А еще есть такая процедура как эгализация, можно списывать по несколько партий в одно, выравнивается плотности, сахара, крепости, на выходе одна партия как правило.
И может быть такое что 90 процентов одна партия и 10 партий по проценту туда.
Это технологи рулят. Дегустации, лаборатории и все такое.

Ну и как это меняет задачу?

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

(52) ну да, я в (49) поправился с учетом разливов по партиям.
хорошая задача, не скучная )

(59) Ну нас есть партии, тоже самое только вид сбоку.
И да учет четкий. Все ёмкости штрихкодированые. Все идет через мерники.
РАР заставил. Так что партия отслеживается четко. Каждый чих сливается в ЕГАИС.

(58) Усложняет.

(60) Доппроведение это теже яйца только сбоку. Или я не понял идею.
Мне все рано надо гнать от выхода ко входу. А так везде многие-ко-многим, то у меня еще тот ежик в отчетах получается.

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

(62) Чем, если методика единая, то абсолютно пофигу

(64) Вопрос только в объеме этого регистра... это как раз тот случай, когда на сервере надо от 512 Гб ОЗУ чтобы задействовать новый механизм.

(64) Так у меня сейчас так и сделано.
Раз в час, фоновое задние убивает мой регистр сведений Цепочка. Убивает мой регистр сведений Соответствие партий. И начинает.
Проходит по всем докам, пишет соответствие партии входа партии выхода, если партий входа несколько то значит будет несколько записей.
Потом берет док выпуск купажа.
и пишет в Регистр Цепочка
Купаж такой-то, партия входа, номенклатура входа, номенклатура выхода, уровень 0, док передела такой-то
и погнали в цикле, смотрим на регистр Соответчике партий, ищем по партии выхода партию входа и пишем в
Регистр Цепочка
Купаж такой-то, партия входа, номенклатура входа, номенклатура выхода, уровень 1, док передела такой-то
и так пока буду находится партии входа.

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

(67) А зачем убивать регистр Цепочка ? Ведь все если что-то и предлагают, то исходят из того, что факт после выпуска уже не меняется.
Иначе в самом деле получается, что в таком подходе это не является _учетной_ системой. Это виртуальная система, в котором каждый час создается новое состояние.

Странно как-то.

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

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

а тут такая фигня
В этом году приняли новую фишку, если у нас продукция из винограда выпущена, а не покупного виноматериала. То можно вычитать из акцизов.
Вот заносятся доки начиная с 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) и запрет конечно включу.