Это в секцию "Математика и алгоритмы", но её уже нет.

Дано:
Есть N организаций (N > 1). У каждой организации есть M𝑖 складов (для простоты без потери общности предположим, что ровно по 1 складу).
Каждая организация может резервировать товары не только на своём складе, но и на складе других организаций, при отсутствии свободного товара на своём складе. ("Свободным" является количество товара из имеющегося на складе, не находящееся в резерве).
Случай, когда организация A резервирует товар на складе организации B назовём "перекрёстным резервированием" (ПР).
Если при этом организация B резервирует тот же товар на складе организации A, то такой случай назовём "встречным перекрёстным резервированием" (ВПР).
(Замечание 1. В общем случае цепочка ПР может быть длиннее 2: А резервирует у B, B резервирует у C, С резервирует у A, etc)
(Замечание 2. Всю "механику" как на практике получается ВПР я приводить не буду. Это возможно, можете поверить :)

Требуется:
Придумать алгоритм свёртки ПВР. Вариант "в лоб": "снять все резервы и зарезервировать заново" не прокатит.

(У себя я эту задачку решил, интересно посмотреть ваши варианты)

Т.е. ты хочешь свернуть типа такую ситуацию?
на сейчас:
Товар1, А резервирует у Б 100шт
Товар2, Б резервирует у А 40шт
.
????
по идее такого быть не может, если Б резервирует у А - значит у А был свободный остаток, если был свободный остаток у А, он должен был закрыть потребность в резерве у этого же А. и Тогда у А не осталось бы свободного остатка для потребности Б

Разве это не тоже самое примерно что и рауз делает?

если втупую без математики
каждому складу присваиваем приоритет
Собираем кортежи резервов
Склад1,Склад2, 100
Склад2,Склад1, 40
если кортеж неупорядочен по приоритету - сортируем со сменой знака
Склад1,Склад2, 100
Склад1,Склад2, -40
Сворачиваем, итог
Склад1,Склад2, 60
.
???

(0) математику убили - жуть.

А по задаче: цель одномоментно сворачивать все резервы везде или по возникновению встречных резервов внутри организации?
Если второе, то организация просто списывает свой резерв и резерв у себя на одинаковое количество и сообщает другим участникам что их резервы перенесены.
Например
А зарезервировала у Б 50 ед,
Б зарезервировала у В 40 ед.
Б обнаружила у себя встречный резерв и у себя списала по 40, и сообщила А, что 40 ед. её резерва теперь размещены у В, а В сообщила, что теперь этот резерв закреплен за А

Будем рассматривать один товар, т.к. товары между собой не связаны.
Пусть есть таблица с полями:
КтоРезервирует, УКогоРезервирует, Количество

Тогда ищем пары записей вида:
А, Б, Х
Б, В, У

находим М = Мин(Х,У)

Заменяем на записи:
А, Б, Х-М
Б, В, У-М
А, В, М

Удаляем записи вида:
А, Б, 0
и
А, А, ...

Пишу удаляем (случай А=В) - можно просто сразу не записывать, просто для удобства описания алгоритма.

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

Могу, конечно, ошибаться, но возникновение ситуации когда требуется такая свертка причина - косяки в алгоритмах резервирования.

(6) не обязательно. Например отмена резерва

(0) Придумал алгоритм решения линейных уровнений?

Но в любом случае все резервы отменить, а потом поставить - это единственное решение.
Ибо перенос с одной организации на другую это и есть минус и плюс

(9) Но в любом случае все резервы отменить, а потом поставить - это единственное решение.
а если все резервы правильные - нафига делать это?

(0) Я не вижу смысла никакого сложного математического алгоритма тут придумывать. Берёшь таблицу остатков, связываешь с таблицей резервов и с таблицей потребностей. Всё левым, всё  в одну строчку. Где потребность меньше резерва и больше остатка - сворачиваешь и выкидываешь в ВТ, дальше уже либо в коде либо в запросе можно обрабатывать, считать куда надо новые резервы сделать, а потом уже перерезервировать.

(0) Обычные графы и циклы

Поправьте если я не прав. Резерв списывается при реализации. Резерв должен измениться при поступлении. Не?

(10) так таблицу же свернуть надобно перед движениями. А после свертки она будет пустой

(11)+ "Заметим, что, если в графе есть вершины с петлями, то алгоритм будет работать корректно, так как при запуске поиска в глубину из такой вершины, найдется ребро, ведущее в нее же, а значит эта петля и будет являться циклом"
https://neerc.ifmo.ru/wiki/index.php?title=Использование_обхода_в_глубину_для_поиска_цикла

(14)+ Хотя тут скорее не петли а направленный граф и пары вершин имеют парные ребра противоположного направления

(6)Есть два магазина. В первом есть 5 яблок, во втором 0. Во втором заказали 3 яблока, их зарезервировали на первом. На второй поступило 10 яблок от поставщика. На первом заказали 5 яблок, 2 с остатков, ещё 3 уже со второго. В целом ситуация из (0) правдоподобна, но случаи скорее всё-таки очень редкие.

(16) для этого есть понятие товаров в пути)

(16) очень редкость зависит от оборота и количества позиций.
Так то может и редкая а с учетом будет позиций 100

(17) а если заказали сильно потом?

(19) у товаров в пути есть понятие, когда планово товар должен поступить на склад. А тут либо не надо было резервировать, так как есть возможность и время заказать у поставщика, либо приходит товар с первого склада и списывает тем самым резерв.

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

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

Но в теме акцент на "математика и алгоритмы". В такой ситуации не важно резерв это или другие встречные требования. С долгами даже более наглядно. И решение приведено в (5)

(21) так графы после формализации превратятся ровно в (5)

(17) Товары в пути (если речь идет о резервировании в поставках) кардинально дело не меняют.

(24) как не влияют? А если вам известно, что завтра на склад от поставщика придет 100500 товара1, смысл его резервировать на удаленном складе, который в лучшем случае в течение 3х дней доставит товар?)

(25) про время в задаче нет вообще ничего. будем считать, что любая организация может отгрузить товар с любого склада

ну  т.е. нам нет необходимости физически таскать товар между складами

(27) тогда интеркомпани спасет (хотя бы до конца месяца) =)

(22) мы решили делать это в 2 случаях: а) ночью в технологическое окно - сворачиваются все ВПР; б) при формировании интеркампани перед отгрузкой - только резервам текущего заказа

(28) так эта задача и вылезла из интеркампани :)

напоминает классические анекдоты про студентов и сессию

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

(30) у меня регламент делает ежедневно перепродажи между организациями, для этих целей)

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

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

Зачем какие-то цепочки? Т.к. внешних резервирований нет, то берем из (5) для каждого склада просто
"находим М = Мин(Х,У)"
и уменьшаем резерв по дебету и резерв по кредиту на М.

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

(23) На графах алгоритм проще
Остается только исходные данные привести к виду графа, отработать алгоритм а затем получить результат

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

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

(40) эээ маркировка что ли?
как иначе доказать обратную продажу если оба у поставщиков закупали внешних

(41) ГТД

(42) Проще их подменять ))

(42) говорят, что за не указание ГТД небольшой штраф, по сравнению с указанием не верного номера ГТД))

(7) и что? отмена резерва увеличивает свободный остаток. что приводит к ненадобность резервов на свою организацию/склада с другой оранизации/склада в сейчас когда будет рассчитываться потребность в резерве при какой-либо операции.

(16) если говорить только О РЕЗЕРВАХ - а в постановке задачи именно резервы которые МОДЖО СВЕРНУТЬ (и пофиг что резерв уже собран и должен уехать на другой склад, а мы его херак сняли - поэтому считаем что речь идет только о ЦФИРАХ а не о реальных товарах, то есть о резервах которые еще не поступилти в складскую обработку, условно статус не стоит типа "в работе уже")
.
Есть два магазина. В первом есть 5 яблок, во втором 0. Склад1остатоксвободный = 5, Склад2остатоксвободный=0)
Во втором заказали 3 яблока, их зарезервировали на первом.  (Склад2заказ = +3, Склад1резерв = 0+3 =3, Склад1остатоксвободный=5-3=2)
На второй поступило 10 яблок от поставщика. (Склад1резерв = 3-3=0, Склад1остатоксвободный=2+3=5, Склад2резерв = 0+3=3, Склад2остатоксвободный=10-3=7)
На первом заказали 5 яблок, Склад1резерв = 0+5 = 5, Склад1остатоксвободный=5-5=0).
Итого,
Склад1резерв с остатков своего склада = 5, Склад1свободныйостаток = 0
Склад2резерв с остатков своего склада = 3, Склад2свободныйостаток = 7
.
Никаких перекрещивающихся резервов нет.
.
если резервы выданы в работу (например, сборка товара на складе) - такой резерв сворачивать нельзя, ибо он уже может стоять упакованный и готовый к отгрузке на перекрестный склад. и взять с него товар в другой резерв своего же склада - нельзя.


2 с остатков, ещё 3 уже со второго. В целом ситуация из (0) правдоподобна, но случаи скорее всё-таки очень редкие.

(46) физические склады наверняка никак по организациям не делятся

(46) да скорее всего вообще 1 склад, просто товар покупается 10тью конторами, а продается 20ю другими. А по факту это все одна и та же контора, но нужно указывать правильный код ГТД в счетах фактурах. А чтобы это сделать, нужно товар с одной конторы передать другой. Я как-то так понял)

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

(48) обычно ГТД - это "воздух" и определяется собственно в момент реальной продажи (отгрузки). если это не прослеживаемый товар (да и по прослеживаемому онлайна пока вроде не надо) что мешает в продаже Организации1 указать ГТД отрганизации2? по интеркомпани все равно зхакроется, и резервов тут никаких нет

(48) такую хрень я еще делал хрен знает когда , году этак в 2005-2007. ровно как в (50)

(50) " и определяется собственно в момент реальной продажи" - при условии, что у этой организации есть этот товар с ГТД. А если нет, то просто ничего в реализации не попадет и счет фактура будет без номера ГТД. Вроде как-то так емнип

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

(52) если нет товара своей организации что мешает указать ГТД другой организации? интеркампани закроет перепродажей.

(54) а кто это будет указывать?) 1ска по умолчанию не проставляет(так как нет у организации), в реализации вроде нет поля с ГТД, Интеркомпани закроет это в конце месяца/дня, а счет фактуру надо прям сейчас отправить

(55) кривые решения порождают следующие кривые решения. у меня нормально все было, см.(50).

(0) если абстрактоно решать я бы разбил на 2 этапа
1. свертка - на складах посчитать свернутое количество (резерв с другого склада - резерв на другой склад)
- результате по складам имеем по одному числу (+ значит склад только получает / - склад только отдает)
2. построение новой схемы резервирования по данным свертки

(56) да можно конечно свою логику присваивания гтд написать и не париться

(55) "в реализации вроде нет поля с ГТД,"
а это смотря где как сделано, в т.юч. и типовых в 8-ке...
. РН в типовой 1Ске с указанием ГТД https://www.screencast.com/t/vYp660dB

(59) не открывается ссылка

(59) В той же УТ11 в реализации есть ТЧ с видами запасов, вот там и указывается номер ГТД, но обычно эту ТЧ 1ска сама заполняет автоматом.

в пользовательском интерфейсе лишь ТЧ с товарами и там указания ГТД нет.

(51) да-да, только в те годы у ФНС не было автоматических встречных проверок

(0) Делал такое в УНФ вот совсем  недавно, с интеркампани. Только резервирование + что есть в оргн А, добиваем количество по оргн Б.  Один отчет по начал жестко врать :)

(54) Прослеживаемость мешает ;-)

(60) я хз.. то у тебя ГТД нет в реализации, то ссылка не открывается...
открывается ссылка

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

(65) разве сейчас прослеживаемость по РНПТ онлайновая? - таки вроде нет...
да даже если и так что надо иметь практическивыполянемую прослеживаемость - то что мешает перепродажу делать сразу же перед выполнением собственно продажи на сторону?
.
и собственно к резервированию в (0) - ГТД каким боком?

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

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

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

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

(71) в (46) я это и описал на примере, то что типовая этого "не умеет" - это проблемы ежиков...

(72) нормально написанная интеркампани сумеет автоматом вычислить ключевые точки и их количество для документов перепродаж.
(я это делал в тех-же 2004-2007 гг. а там это все усугублялось еще и тем, что четко отрабатывалось недопущение минусов даже внутри периода)

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

(74) С момента 2004 или разработки ЕРП 2010, все усложнилось на порядок или порядки в зависимости от групп товаров

(76) жрите кактус и не жалуйтесь;-)

Вы еще ЕГАИС вспомните,там документ должен уехать в систему до выезда автомобиля со склада.

(78) ну, с этим-то как раз легче. шаманить не надо...
и уезжает не документ, а отсканенные/подобранные на складе штуки с отсканенными марками, оформленные в документ для передачи в ЕГАИС

(79) В чем легче? у тя измерения от 2 до 3-х по юр лицу

(80) не вкурил про что здесь..

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