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

Самописная конфигурация, платформа 8.3.5. В конфигурации есть такие справочники:
1. Справочник "Номенклатура ТМЦ". В моей когфигурации он выполняет роль именно классификатора номенклатуры ТМЦ, а не справочника самих ТМЦ, как в типовых. Например, "Ботинки защитные", "Освежитель воздуха" и т.п.
2. Справочник "ТМЦ" - подчинен справочнику "Номенклатура ТМЦ", в котором хранится информация о конкретных ТМЦ. Например: "Ботинки защитные Wurth", "Ботинки защитные Red Wing", "Освежитель воздуха AirWick", "Освежитель воздуха Glade" и т.п.
3. Справочник "Варианты ТМЦ" - также подчинен справочнику "Номенклатура ТМЦ", и предназначен для хранения различных вариантов номенклатурных позиций. Например, для ботинок это могут быть "Размер 41", "Размер 42" и т.п. Для освежителей воздуха - "Запах лаванды", "Запах Лимона" и т.п.

Есть регистр остатков "ТМЦнаСкладах", с измерениями "Склад" (СправочникСсылка.Склады), "НоменклатурнаяПозиция" (СправочникСсылка.НоменклатураТМЦ), "ТМЦ" (СправочникСсылка.ТМЦ) и "ВариантТМЦ" (СправочникСсылка.ВариантыТМЦ, может быть пустым) и ресурсом "Количество".

Есть регистр "Резервы ТМЦ", с измерениями "Склад", "ЦелевоеНазначение", "НоменклатурнаяПозиция", "ТМЦ", "ВариантТМЦ" и ресурсом "Количество".

Ну и соответственно есть документ "Резервирование ТМЦ", с табличной частью с реквизитами "НоменклатурнаяПозиция", "ТМЦ", "ВариантТМЦ", "Количество".

Сложность состоит в том, что при резервировании в этом документе можно не указывать ТМЦ либо ВариантТМЦ (либо ни то, ни другое). Т.е пользователь может оформить резерв в 4 вариантах: "Освежитель воздуха Glade с запахом лимона", или "Освежитель воздуха с запахом лимона" или "Освежитель воздуха Glade" или просто "Освежитель воздуха".

Два дня пытаюсь написать соответствующий код, но получается уж очень сложный алгоритм, который кучу раз обращается к данным. Кто может подсказать, как это сделать правильно? Повторяю, за готовый код заплачу 100 у.е.

100 уе мало. Давай умножим на 100?

А на счет освежителей, скажу. Так, гомном пахнет только в помещении нужника. Иначе - по всему офису в перемешку с запахом лимона. Ну серьезно!

(0) http://1clancer.ru/
и за 100 USD с тобой вряд ли кто станет общаться

(3) Раньше мне тут за бесплатно помогали, первый раз решил простимулировать материально, так сразу стали фыркать и носом крутить...

(1) Закатай губу обратно. Тут работы на 1 день максимум, если писать умеешь. А те, кто не умеют, пусть хоть на миллион умножают.

(5) Ну если человек не может, а надо - почему бы не нагреться на этом? Или ты тоже добрый?

(6) Про кривую спроса и предложения слышал? ;)

(7) Пох

(8) Ну вот сам себе ответил. Именно пох.

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

(10) В чем бред, если ты не читал? )))

(11) ты готов заплатить 100 уе, чтобы я вникся и проникся постановкой?

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

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

(13) Ну раз ты понял связь с ботинками и освежителями, то тебе тоже ни хрена не светит ))

(0) Почему в типовой не подглядеть алгоритм резервирования? Религия может не позволяет?

(15) Да уж куда мне... Лох атипичный йа.

(16) В типовой другая структура регистров и справочников. Она не подходит для моей предметной области.

эммм... начнем по порядку

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

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

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

(17) Лох, не лох - тебе виднее, но пописдеть просто так точно любишь ))

Надоел со своими освежителями ))

я-бы оценил задачу в 50..100 круб,

примерное тз для задачи примерно в 200$

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

(22) .опа не слипнется?

(19) По второму пункту, так и есть - существует регистр "Очередь резервов".

(23) Есть регистр "Резервы ТМЦ", - ?
И "воздушный" док Предварительная заявка? Не?

(23) на текущих регистрах нифига не выйдет
(24) нет

регистр "Очередь резервов" выброси. Это лишнее.

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

(28) Не выброшу - мне нужна ))

тебе нужен регистр примерно такого вида

измерения:
номенклатура,
группа1,
группа2,
группа3,
группа5,
группа6

Все группы это отдельные справочники, например
группа1 - классификатор
группа2 - производитель
группа3 - цвет
группа4 - запах
.....

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

(31) это немного не красиво в плане масштабируемости, но я о принцепе...

(29) это тебе кажется, что вышло :)

(33) Могу код прислать, но его ты точно без 100 баксов читать не захочешь ))

(33) А вообще работает. А твоя схема уж как-то очень страшно выглядит. Зачем плодить измерения в регистрах? Тем более, что чем их больше, тем сложнее задача получится.

Могу дать программу, которая программно плодит измерения в регистрах. В 1CD влезает и плодит. Но не дам. Потому что я не написал её еще.

(36) Напиши, пожалуйста. За "пожалуйста" же напишешь? ;)

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

я на текущей работе в регистр остатков добавил измерение "видОстатков" Доступно/Оформление/Резерв и теперь у меня все сильно упростилось.

Резерв у меня делает 2 проводки списание доступного и приход резерва, документ отгрузки без подписи МОЛ делает списание доступного/резерва и поступление "оформление", а по подписи просто удаляется поступление "оформления".

Все отчеты и тюдю делаются легко и красиво, мы всегда видим в ОТДЕЛЬНЫХ колонках сколько у нас выписано но по факту не отгружено (оформление), сколько в резерве и сколько в наличии.

Но у тебя резервы пересекаются, это не имеет отношение к остаткам....

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

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

Все одним запросом делается, сделаю за символические 10$ :)

(41) Демпфингующих норот сжигает на костре. Живьем. Грамотно, что бы не успел от дыма потерять сознание, а помучался как можно дольше. И команду медиков, что бы адреналин вводили, что бы не лишился сознания от болевого шока.
Закричишь от боли - лох. Тебя бензином обольют в добавок.

(42) А рубить за один запрос 100$ с айтишника это нормально? Там писать то нечего...

(43) 100 баксов - ненормально.
Вот пару тыщ - это нормально

(41) Точно одним запросом сделаешь? Мне и 100 не жалко, если только сделаешь. Могу выслать конфигурацию для удобного решения задачи.

(40) Ты не понял задачу.

(41) обьясни как ты сделаешь резерв в такой ситуации

есть
1. шампунь лимонный Тимоти - 5шт
2. шампунь лимонный хелден шолдер - 3шт
3. шампунь яблочневый Тимоти - 5шт

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

сначала вникни а потом уже пиши

(40) Суть в том, что резервируются не конкретные остатки.

Допустим, на складе есть:
Освежитель воздуха, Glade, Лаванда - 20 шт
Освежитель воздуха, Glade, Роза - 20 шт
Освежитель воздуха, Glade Premium, Лаванда - 20 шт
Освежитель воздуха, Glade Premium, Роза - 20 шт

Поступает заявка на резерв:
Освежитель воздуха, <Пусто>, Роза - 30 шт.

Смотрим, на остатке таких есть 40, резервов пока никаких нет, значит разрешаем резерв на все 30 шт.

Поступает еще одна заявка на резерв:
Освежитель воздуха, Glade Premium, <Пусто> - 30 шт.
Смотрим, таких у нас 40 шт на остатке, но есть резервы на 30 роз, и эти резервы нельзя обеспечить без 10 наших глейдов премиум. Так что 20 - разрешаем к резерву, остальные - в очередь.

И так далее.

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

(49) а как ты реализуешь в типовой (48) ????

(50) не вижу сложностей, задачка века что ли ?

(51) ты хотя-бы из 47 напиши русским языком сколько какого товара поставишь в резерв....

задача типовыми не решается, по тому как содержит резерв вида "Товара1 ИЛИ товара2 в резерв 5шт", то есть нет определенности партий в резерве...

Регистр.
Измерения:
- Номенклатура (Освежитель воздуха)
- Бренд (Glade, Glade Premium)
- Запах (Роза, лаванда)
.
Накладываем фильтр из имеющихся Измерений. Получаем выборку. Резервируем.
.
Вроде все..?

(52) т.е. я твои мысли должен русским языком написать?
открывай типовую торговлю, РН. СвободныеОстатки. и внимательно-внимательно смотри на ресурсы.

p.s. да и пофиг, может подпилить надо что-то будет.

(53) именно это я написал в (31) :)

только это не масштабируемое решение, если характеристик будет штук 100 ???

В услвоиях, когда товар, на который надо сделать резерв - не простое указание ,а сложное условие - то есть резерв на N товаров одновременно - получаем не тривиальное резервирование ПОСЛЕДОВАТЕЛЬНО для каждой номенклатуры, а некую "оптимизационную" задачу, где критерий оптимизациии - максимально возможное количество зарезервированного товара совокупно по всем товарам в заявке.
.

(55) о, спасибо, великий гуру! сенсей всех сенсеев, гуру всех гур! ;-)

(54) в моем примере есть много разных способов резерва, и все они будут правильными, но не оптимальными....

вариант 1
1. шампунь лимонный Тимоти - 5шт / 3 резерв (лимонный)
2. шампунь лимонный хелден шолдер - 3шт  
3. шампунь яблочневый Тимоти - 5шт / 3 резерв (тимоти)

вариант 2
1. шампунь лимонный Тимоти - 5шт
2. шампунь лимонный хелден шолдер - 3шт  / 3 резерв (лимонный)
3. шампунь яблочневый Тимоти - 5шт / 3 резерв (тимоти)

вариант 3
1. шампунь лимонный Тимоти - 5шт  / 3 резерв (тимоти)
2. шампунь лимонный хелден шолдер - 3шт  / 3 резерв (лимонный)
3. шампунь яблочневый Тимоти - 5шт


и так далее, все они удовлетворяют условим, какой нужен?

(58) отсортировать по сроку годности - брать те, что скоро срок кончится.. ;-)

(59) а при таком раскладе можно продать "шампунь яблочневый Тимоти - 5шт" ????, по логике - да, но в варианте 1 и 2 можно только 2 шт продать...

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

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

в (0) - человек пошел по легкому пути велосипеда и у него 3 измерения. соответственно, ему понадобится +-3 ресурса...

вообще задача интересна с теоретической точки зрения :)

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

Есть на остатке:
Освежитель воздуха, Глэйд, Роза - 10 шт.
Освежитель воздуха, Глэйд, Лаванда - 10 шт.

Поступает заявка на резерв:
Освежитель воздуха, Глэйд, <Пусто> - 15 шт.

По вашему мы должны какие-то из тех 20 зарезервировать. В том то и суть, что ничего подобного. Мы просто должны запомнить (т.е. записать в отдельный регистр), что есть такой резерв и надо его обеспечить. Т.е. если позже прийдет покупатель (другой, не тот, который резерв делал), и попросит 5 розочек, то мы обязаны ему их выдать, т.к. у нас после этого останется еще 15 глейдов (5 розочек и 10 лаванд). Если он вместо розочек попросит лаванды - то же самое. Только разница в том, что на остатке останется 10 розочек и 5 лаванд). Т.е. смысл - оптимизировать резервы, максимально продавать имеющийся товар, если он есть. А по вашему, мы должны изначально выбрать, что резервируем, розочки или лаванды. И если не угадаем и зарезервируем 10 розочек и 5 лаванд, а придет покупатель и попросит одну розочку, мы разведем руками и скажем: "А нэту". Хотя есть!

И ни в какой типовой такого нету.

(63) я тебя правильно понял :) и Серега то-же :)

Возможно, потому что слишком сложный алгоритм решения, не знаю.

(65) Да, я к остальным обращаюсь, кто уже "придумал" как. )) Пока что это все не то.

Не соответствует условию задачи.

давай рассуждать логически

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

(62) И да, это точно, задача действительно интересна с теоретической точки зрения, но с практической - это просто ад какой-то ))

(69) Ну этих характеристик всего две. И проблема в том, что они независимы друг от друга.

я вижу пути

1. ограничение условия резерва к простому (не более одной характеристики)
2. приведение условия резерва к некой функции хеша
3. при каждом запросе расчет по алгоритмам типа "раскрой, рюкзак"

(71) это сейчас 2 характеристики а через год будет 5.... знаем, плавали...

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

(72)+ если характеристики реально независимы - то нужно смотреть в сторону хеширования набора характеристик, я так делал для РЛС по наборам с переменным количеством характеристик, работает вполне шустро...

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

100 енотов - явно не та сумма за такой алгоритм.

(74) Опять двадцать пять. То, что вы говорите - абсолютно не то, что нужно. Нужно:
1. По возможности принять резерв;
2. Обеспечить наличие этого резерва при других отгрузках или резервах таким образом, чтобы максимально использовать имеющиеся остатки.

(77) Ок, забудем про деньги ))

(73) Нет, характеристики точно 2 и не будет больше. Это ведь даже не характеристики. Все характеристики умещаются в Вариантах. Там можно создать их хоть сто для каждого варианта разных.

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

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

(63) "..Мы просто должны запомнить (т.е. записать в отдельный регистр), что есть такой резерв и надо его обеспечить. Т.е. если позже прийдет покупатель (другой, не тот, который резерв делал), и попросит 5 розочек, то мы обязаны ему их выдать, "
- протвиоречие первчй части фразы (поставить в очередь и обеспечить резерв) со вторйо частью фразы "когда придет покупатель".
.
видно, что пришедший поупатель - имеет макисмальный приоритет удовлевтроения. несмотря на то, что планировалось раньше этот товар под кого-то другого впердолить. Поэтому никаких ПРЕДВАРИТЕЛЬНЫЪХ !РЕЗЕРВОВ! - нафиг не надо. прото регистрация ожидаемой КОГДА_НИБУДЬ отгрузки (без резервирования).
.
обычная конкурентная продажа по типу "кто первый встал - того и тапки". Поэтому тупо регистрируем ХОТЕЛКИ КЛИЕНТА, а резеврирование как таковое возникает только в момент необходимости "отгрузки" по окончательному решению (пришел клиент или приняли решение начать сборку товара).

(80) тогда тебе нужен регистр с 4 измерениям
номенклатура, ВладелецНоменклатуры, Характеристика1, Характеристика2

дальше сам допетришь :)

(82) Ничего подобного. Покупатель не имеет приоритета. Он должен получить по максимуму в пределах того, что НЕ НАРУШИТ РЕЗЕРВА. Т.е. если покупатель попросит 6 глэйдов - ему отказ.

... хотя на складе их 20.

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

(82)(86)  вот этим снеговик и отличается от клюшек. другое мышление.

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

(84) см. (86)

Получить информацию по имеющимся резервам не так уж сложно. Например, я такой запрос написал:

Запрос = Новый Запрос;
    Запрос.МенеджерВременныхТаблиц = МенеджерВТ;
    
    Запрос.Текст =
        "ВЫБРАТЬ
        |    ТМЦнаСкладахОстатки.ТМЦ.Владелец КАК НоменклатурнаяПозиция,
        |    ТМЦнаСкладахОстатки.ТМЦ,
        |    ТМЦнаСкладахОстатки.ВариантТМЦ,
        |    ТМЦнаСкладахОстатки.КоличествоОстаток
        |ПОМЕСТИТЬ ТМЦнаСкладе
        |ИЗ
        |    РегистрНакопления.ТМЦнаСкладах.Остатки(
        |            &ТочкаИтогов,
        |            Организация = &Организация
        |                И Склад = &Склад
        |                И ТМЦ.Владелец В
        |                        (ВЫБРАТЬ
        |                            ПереченьТМЦвДокументе.НоменклатурнаяПозиция
        |                        ИЗ
        |                            ПереченьТМЦвДокументе КАК ПереченьТМЦвДокументе)) КАК ТМЦнаСкладахОстатки
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    ТМЦнаСкладахОстатки.ТМЦ.Владелец,
        |    ТМЦнаСкладахОстатки.ТМЦ,
        |    ТМЦнаСкладахОстатки.ВариантТМЦ
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ
        |    РезервыТМЦОстатки.НоменклатурнаяПозиция,
        |    РезервыТМЦОстатки.ТМЦ,
        |    РезервыТМЦОстатки.ВариантТМЦ,
        |    РезервыТМЦОстатки.КоличествоОстаток
        |ПОМЕСТИТЬ РезервыТМЦ
        |ИЗ
        |    РегистрНакопления.РезервыТМЦ.Остатки(
        |            &ТочкаИтогов,
        |            Организация = &Организация
        |                И Склад = &Склад
        |                И ((НоменклатурнаяПозиция, ТМЦ, ВариантТМЦ) В
        |                        (ВЫБРАТЬ
        |                            ТМЦнаСкладе.НоменклатурнаяПозиция,
        |                            ТМЦнаСкладе.ТМЦ,
        |                            ТМЦнаСкладе.ВариантТМЦ
        |                        ИЗ
        |                            ТМЦнаСкладе КАК ТМЦнаСкладе)
        |                    ИЛИ (НоменклатурнаяПозиция, ВариантТМЦ) В
        |                            (ВЫБРАТЬ
        |                                ТМЦнаСкладе.НоменклатурнаяПозиция,
        |                                ТМЦнаСкладе.ВариантТМЦ
        |                            ИЗ
        |                                ТМЦнаСкладе КАК ТМЦнаСкладе)
        |                        И ТМЦ = &ПустаяТМЦ
        |                    ИЛИ (НоменклатурнаяПозиция, ТМЦ) В
        |                            (ВЫБРАТЬ
        |                                ТМЦнаСкладе.НоменклатурнаяПозиция,
        |                                ТМЦнаСкладе.ТМЦ
        |                            ИЗ
        |                                ТМЦнаСкладе КАК ТМЦнаСкладе)
        |                        И ВариантТМЦ = &ПустойВариантТМЦ
        |                    ИЛИ НоменклатурнаяПозиция В
        |                            (ВЫБРАТЬ
        |                                ТМЦнаСкладе.НоменклатурнаяПозиция
        |                            ИЗ
        |                                ТМЦнаСкладе КАК ТМЦнаСкладе)
        |                        И ТМЦ = &ПустаяТМЦ
        |                        И ВариантТМЦ = &ПустойВариантТМЦ)) КАК РезервыТМЦОстатки
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    РезервыТМЦОстатки.НоменклатурнаяПозиция,
        |    РезервыТМЦОстатки.ТМЦ,
        |    РезервыТМЦОстатки.ВариантТМЦ
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ,
        |    ЕСТЬNULL(РезервыТМЦ.КоличествоОстаток, 0) КАК СуществующийРезерв
        |ПОМЕСТИТЬ СуществующиеРезервыПоВсемТремИзмерениям
        |ИЗ
        |    ТМЦнаСкладе КАК ТМЦнаСкладе
        |        ЛЕВОЕ СОЕДИНЕНИЕ РезервыТМЦ КАК РезервыТМЦ
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = РезервыТМЦ.НоменклатурнаяПозиция
        |            И ТМЦнаСкладе.ТМЦ = РезервыТМЦ.ТМЦ
        |            И ТМЦнаСкладе.ВариантТМЦ = РезервыТМЦ.ВариантТМЦ
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ,
        |    СУММА(ЕСТЬNULL(РезервыТМЦ.КоличествоОстаток, 0)) КАК СуществующийРезерв
        |ПОМЕСТИТЬ СуществующиеРезервыПоНоменклатурнойПозицииИТМЦ
        |ИЗ
        |    ТМЦнаСкладе КАК ТМЦнаСкладе
        |        ЛЕВОЕ СОЕДИНЕНИЕ РезервыТМЦ КАК РезервыТМЦ
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = РезервыТМЦ.НоменклатурнаяПозиция
        |            И ТМЦнаСкладе.ТМЦ = РезервыТМЦ.ТМЦ
        |ГДЕ
        |    РезервыТМЦ.ВариантТМЦ = &ПустойВариантТМЦ
        |
        |СГРУППИРОВАТЬ ПО
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ,
        |    СУММА(ЕСТЬNULL(РезервыТМЦ.КоличествоОстаток, 0)) КАК СуществующийРезерв
        |ПОМЕСТИТЬ СуществующиеРезервыПоНоменклатурнойПозицииИВариантуТМЦ
        |ИЗ
        |    ТМЦнаСкладе КАК ТМЦнаСкладе
        |        ЛЕВОЕ СОЕДИНЕНИЕ РезервыТМЦ КАК РезервыТМЦ
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = РезервыТМЦ.НоменклатурнаяПозиция
        |            И ТМЦнаСкладе.ВариантТМЦ = РезервыТМЦ.ВариантТМЦ
        |ГДЕ
        |    РезервыТМЦ.ТМЦ = &ПустаяТМЦ
        |
        |СГРУППИРОВАТЬ ПО
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ,
        |    ТМЦнаСкладе.НоменклатурнаяПозиция
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ,
        |    СУММА(ЕСТЬNULL(РезервыТМЦ.КоличествоОстаток, 0)) КАК СуществующийРезерв
        |ПОМЕСТИТЬ СуществующиеРезервыПоНоменклатурнойПозиции
        |ИЗ
        |    ТМЦнаСкладе КАК ТМЦнаСкладе
        |        ЛЕВОЕ СОЕДИНЕНИЕ РезервыТМЦ КАК РезервыТМЦ
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = РезервыТМЦ.НоменклатурнаяПозиция
        |ГДЕ
        |    РезервыТМЦ.ТМЦ = &ПустаяТМЦ
        |    И РезервыТМЦ.ВариантТМЦ = &ПустойВариантТМЦ
        |
        |СГРУППИРОВАТЬ ПО
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ,
        |    ТМЦнаСкладе.НоменклатурнаяПозиция
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    ТМЦнаСкладе.НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ
        |    ТМЦнаСкладе.НоменклатурнаяПозиция КАК НоменклатурнаяПозиция,
        |    ТМЦнаСкладе.ТМЦ КАК ТМЦ,
        |    ТМЦнаСкладе.ВариантТМЦ КАК ВариантТМЦ,
        |    ТМЦнаСкладе.КоличествоОстаток КАК ОстатокНаСкладе,
        |    ЕСТЬNULL(СуществующиеРезервыПоВсемТремИзмерениям.СуществующийРезерв, 0) КАК СуществующийРезервПоВсемТремИзмерениям,
        |    ЕСТЬNULL(СуществующиеРезервыПоНоменклатурнойПозицииИТМЦ.СуществующийРезерв, 0) КАК СуществующийРезервПоНоменклатурнойПозицииИТМЦ,
        |    ЕСТЬNULL(СуществующиеРезервыПоНоменклатурнойПозицииИВариантуТМЦ.СуществующийРезерв, 0) КАК СуществующийРезервПоНоменклатурнойПозицииИВариантуТМЦ,
        |    ЕСТЬNULL(СуществующиеРезервыПоНоменклатурнойПозиции.СуществующийРезерв, 0) КАК СуществующийРезервПоНоменклатурнойПозиции
        |ИЗ
        |    ТМЦнаСкладе КАК ТМЦнаСкладе
        |        ЛЕВОЕ СОЕДИНЕНИЕ СуществующиеРезервыПоВсемТремИзмерениям КАК СуществующиеРезервыПоВсемТремИзмерениям
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = СуществующиеРезервыПоВсемТремИзмерениям.НоменклатурнаяПозиция
        |            И ТМЦнаСкладе.ВариантТМЦ = СуществующиеРезервыПоВсемТремИзмерениям.ВариантТМЦ
        |            И ТМЦнаСкладе.ТМЦ = СуществующиеРезервыПоВсемТремИзмерениям.ТМЦ
        |        ЛЕВОЕ СОЕДИНЕНИЕ СуществующиеРезервыПоНоменклатурнойПозицииИТМЦ КАК СуществующиеРезервыПоНоменклатурнойПозицииИТМЦ
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = СуществующиеРезервыПоНоменклатурнойПозицииИТМЦ.НоменклатурнаяПозиция
        |            И ТМЦнаСкладе.ТМЦ = СуществующиеРезервыПоНоменклатурнойПозицииИТМЦ.ТМЦ
        |        ЛЕВОЕ СОЕДИНЕНИЕ СуществующиеРезервыПоНоменклатурнойПозицииИВариантуТМЦ КАК СуществующиеРезервыПоНоменклатурнойПозицииИВариантуТМЦ
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = СуществующиеРезервыПоНоменклатурнойПозицииИВариантуТМЦ.НоменклатурнаяПозиция
        |            И ТМЦнаСкладе.ВариантТМЦ = СуществующиеРезервыПоНоменклатурнойПозицииИВариантуТМЦ.ВариантТМЦ
        |        ЛЕВОЕ СОЕДИНЕНИЕ СуществующиеРезервыПоНоменклатурнойПозиции КАК СуществующиеРезервыПоНоменклатурнойПозиции
        |        ПО ТМЦнаСкладе.НоменклатурнаяПозиция = СуществующиеРезервыПоНоменклатурнойПозиции.НоменклатурнаяПозиция
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ
        |    ПереченьТМЦвДокументе.НоменклатурнаяПозиция КАК НоменклатурнаяПозиция,
        |    ПереченьТМЦвДокументе.ТМЦ КАК ТМЦ,
        |    ПереченьТМЦвДокументе.ВариантТМЦ КАК ВариантТМЦ,
        |    ПереченьТМЦвДокументе.КоличествоВБазЕд КАК КоличествоВБазЕд,
        |    ВЫБОР
        |        КОГДА НЕ ПереченьТМЦвДокументе.ТМЦ = &ПустаяТМЦ
        |                И НЕ ПереченьТМЦвДокументе.ВариантТМЦ = &ПустойВариантТМЦ
        |            ТОГДА 1
        |        КОГДА НЕ ПереченьТМЦвДокументе.ТМЦ = &ПустаяТМЦ
        |            ТОГДА 2
        |        КОГДА НЕ ПереченьТМЦвДокументе.ВариантТМЦ = &ПустойВариантТМЦ
        |            ТОГДА 3
        |        КОГДА НЕ ПереченьТМЦвДокументе.ТМЦ = &ПустаяТМЦ
        |            ТОГДА 4
        |    КОНЕЦ КАК РеквизитУпорядочивания
        |ИЗ
        |    ПереченьТМЦвДокументе КАК ПереченьТМЦвДокументе
        |
        |УПОРЯДОЧИТЬ ПО
        |    РеквизитУпорядочивания,
        |    НоменклатурнаяПозиция,
        |    ТМЦ,
        |    ВариантТМЦ";
    
    Запрос.УстановитьПараметр("ТочкаИтогов", ТочкаИтогов);
    Запрос.УстановитьПараметр("Организация", Организация);
    Запрос.УстановитьПараметр("Склад", Склад);
    Запрос.УстановитьПараметр("ПустаяТМЦ", Справочники.ТМЦ.ПустаяСсылка());
    Запрос.УстановитьПараметр("ПустойВариантТМЦ", Справочники.ВариантыТМЦ.ПустаяСсылка());
    
    ПакетРезультатов = Запрос.ВыполнитьПакет();
    
    ТаблицаОстатковИРезервов = ПакетРезультатов[6].Выгрузить();
    
    Выборка = ПакетРезультатов[7].Выбрать();
    Пока Выборка.Следующий() Цикл
        
        // Тут ад
        
    КонецЦикла;

А вот там, где "Тут ад", там вся сложность.

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

(45) Скидвый конфу, напишу запрос. Отправил письмо на твое мыло.

Только пусть автор отпишется - удовлетворил ли его запрос из (92).
интересно.

(90) а в чем трудность прочитать ранее зафиксированные резервы...? - нет такой трудности...

(92) Отправил. Только еще раз внимательно вникни в суть задачи: (63)

(94) Ну вот и я говорю, в этом сложности никакой )) А вот дальше...

(93) Конечно же, отпишусь!

(95) Получил, задачу понял, на 8.3.4 база не завелась, качаю 8.3.5 ...

(98) Включи в свойствах конфигурации режим совместимости с 8.3.4.

(99) Так не дает даже открыть. Скачал 8.3.5, запустил.
У тебя там еще "Партия" есть, в условиях задачи такого не было :)

Как партии учитывать?

Да можешь никак. Оно там вообще ни на что не влияет.

Партии - в остатках. Резервов они не касаются. Так что тебе даже обращаться к ним не придется.

Если все равно смущают - удали.

Только тогда и в модуле проведения "Поступления ТМЦ" удали строчку, где партия прописывается.

Обрати внимание, что в функцию, внутри которой тебе нужно написать код, передается МенеджерВТ, в котором хранится временная таблица - ПереченьТМЦвДокументе.

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

Задачу решить можно, но не за 100 баксов ))

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

(107) Во сколько реально можно оценить эту задачу?

(109) учитывая, что с первой итерации врядли выйдет - примерно 1...2 недели для нормального спеца, вот и считай...

ждем вестей с фронтов

>Т.е пользователь может оформить резерв в 4 вариантах: "Освежитель воздуха Glade с запахом лимона", или "Освежитель воздуха с запахом лимона" или "Освежитель воздуха Glade" или просто "Освежитель воздуха".

Эй, все, кто тут "напишу в 1 денЬ" или "одним запросом за 10 баксов"!
Напишите-ка за 10 баксов нечеткий посик в 1С. А уж потом будете к резервированию подбираться, и изучать, что это такое.

мдаа... судя по (63) тут велосипедом не отделаешься...

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

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


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

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

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

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

Но как это будет работать в многоюзверской версии или еще хуже распределенка хз полное

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

(115) попробуйте реализовать нечеткий поиск _В 1С_ на основе "еще одной таблицы и пары подписок на события".
(113) да-да, заодно все "да я за 1час!" познакомятся с "будущим резервированием", когда нужно отслеживать БУДУЩЕЕ поступление (т.е. кроме всего прочего - постоянно принимать решение: оставить запрос в ожидании резерва, закрыть запрос, или удовлетвоирть запрос тем, что есть), резерв, спрос, и на основе этого формировать новый резерв.
И пусть SF это все уместит в "еще одной таблицы и пары подписок на события" ))

(114)>Но как это будет работать в многоюзверской версии
- никак это не будет работать, раз при разборе КАЖДОГО резервирования - будете сначала пеерпроводить совершенно "нейтральные" по отношению к запросу на резерв, документы.

(116) на 2-й пост к (113) дает ответ (114) никаких проблем с будущим резервированием потому что его просто нету )) точнее не надо

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

(117) про это и речь что тормоза жуткие при таком изврате, нормально только если мало этих "резервирований тмц"

(119)>нафига нечеткий поиск там где он не нуже
- т.е. вы однозначно получите из ""Освежитель воздуха Glade с запахом лимона", или "Освежитель воздуха с запахом лимона" или "Освежитель воздуха Glade" или просто "Освежитель воздуха"" - 3 шт с лимоном, 5 шт Glade, и вообще всего освежителей (они же "Освежитель воздуха") - 10 шт?

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

(116) (117)
я писал выше Регистр Свободные остатки. В котором хранится информация о свободных (доступных для продажи) товарах. Он обновляется при движениях по товарам на склаха и резервированию. Можно резервировать конкретную серию, а можно только товар (без серии). Остатки проверяются по двум ресурсам: количество и количество сводно по сериям. Итого получая отрицательное движение по одному из ресурсов - мы берем чтото из резерва. Это в 2х словах.

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

(121) ШЕФ ты не понял, нам не ехать, а шашечки...

Было же объяснено что не нужен никакой нечеткий поиск потому что
"с реквизитами "НоменклатурнаяПозиция", "ТМЦ", "ВариантТМЦ""

т.е. все украдено точнее разделено до нас и есть иерархия по владельцам...

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

(125) резервирование в будущем это просто (походу с типовыми плохо знакомы кстати) обработка в модуле проведения приходных документов, которая проверяет резервы висящие и закрывает их поступающими приходами

(124) менеджер делает запрос не по "НоменклатурнаяПозиция" или "ТМЦ" (его эти категории не волнуют, это бухгалтерское разделение), а "дай-ка мне любой освежитель с лимоном, да потом еще десяток освежителей Glade!"

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

(123) >>резервировать надо в будущем
Это фантазии, рожденные в голове теоретика. в (0) и (63) просто разговор про то, что надо резервировать не конкретный товар. а например вид ТМЦ. На примере как это работает в типовых с сериями я уже рассказал

(126)>которая проверяет резервы висящие и закрывает их поступающими приходами
- особенно хорошо закрывает, если приход под совсем дургой резерв/заказ/для продажи напрямую предназначен ))
Это, согласен, (не)работает на все 200% ))

(129) не вид а пересечения множеств с условием ИЛИ

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

(131) и что? типовая не справится? )))
в типовой можно ставить резерв по конкретной серии или по товару. так?

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

(133) да не нужен резерв ни по серии ни по номенклатуре....

резерв нужен по любой свободной удовлетворяющей неким условиям, например условия (тип = Освежитель И запах = лимон). поди сделай на типовой :)

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

(135) да легко. тут половина считает мега-задачей контроль остатков на типовой ...

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

(136) судя по тому, что делает автор, это торгаши попали :)

(131) ну да выбираем все подходящие запросом и берем первые из них в документ )), запрос конечно с union будет

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

к спецу по платформе*

вместо нетленки лучше б ут базовую купили, если бюджет колеблется в районе 100 уе

(134) подемпингуем )) конфу конечно и тз не видел но готов сделать за вилку от 800 до 2000 у.е.

Делаю ставки - (137), (140), (141) сначала по 100 баксов/в месяц возьмут за внедрение, потом - $2000 за (попил) допил, и еще штук десять в итоге - за разработку своего механизма вдобавок к типовому.

(139)>нерешаемая задачка из сборника
- ты хоть с реальными пользюками работал? Длела обработку ошибок в 3\4 от всей конфы? Их ошибки отлавливал? Человеческий фактор учитывал в своих лабораторно-"специалистических" разработках?

(112) нечеткий поиск в 1С - успешно работает и кучу на нем всего нафигачил...

vde69 правильно все выше написал.
+ При поступлении каждой новой заявки - полный пересчет всех имеющихся на данный момент "резервов" с учетом новой заявки (в противном случае может получиться не максимальное удовлевторение заявки) + с учетом что ранее поставленные "резервы" должны подтвердиться 100% (но возможно перераспределение подмножеств - запахов-брендов).

(144) у меня уже пол года крутится робот на 1с на нечетком поиске, засасывает тендерные площадки и по новым лотам отрабатывает сотни разнотематических запросов, результат шлет на почту :)

правда пока только 3 тендерных площадки нормально парсятся, но когда доберусь до остальных подумаю может подписку организую на ежедневный автопоиск, типа 500 руб в месяц 1 комбинированый запрос не более 1000 слов :)

Прикинул - вполне реально...

(146) для каких сделано? из http://aetp.ru/etp/list

просто весьма интересно...

(147)нет,

сделано фабрикант, етр, и мгтс
в плане сбер, госзакупки и еще пара

(143) Работал и работаю) Рене, ты не въехал даже в задачу, придираешься к словам и вообще тупишь. Пиши еще, посмеемся хоть)

Ух ты блин, какие тут дебаты...
По поводу (125), т.е. того, что "резервировать надо в будущем". Еще один не понял задачи. Резервировать надо сейчас. Сейчас проверять, есть ли этот резерв на складе или нет. Еще раз (или просто) прочти (63). Резервировать нужно в тот момент, когда заявка на резерв поступает. Т.е. в этот момент мы проверяем остатки, существующие резервы на эти остатки, и рассчитываем, достаточно ли на складе ТМЦ, чтобы удовлетворить новую заявку, вместе с существующими. Все. То, что достаточно - ставим в резерв, остальное - в очередь резервов (регистр, аналогичный регистру "Резервы ТМЦ", только там есть еще измерение "Приоритет").
То же самое делается и при отгрузке, если она не является отгрузкой по существующему резерву. Чтоб понимали, реальный регистр резервов выглядит так:

Измерения:
   Организация
   Склад
   ЦелевоеНазначение
   Проект
   ЦелевойОбъект
   НоменклатурнаяПозиция
   ТМЦ
   ВариантТМЦ
Ресурсы:
   Количество

Для простоты понимания можем заменить ЦелевоеНазначение Проект и ЦелевойОбъект одним измерением Клиент. Т.е.:

Измерения:
   Организация
   Склад
   Клиент
   ТМЦ
   ВариантТМЦ
Ресурсы:
   Количество

В отгрузочном документе указывается Клиент. Мы проверяем существующие резервы, если находим достаточное количество зарезервированных ТМЦ по данному клиенту, то мы просто списываем их с резерва и выдаем клиенту. Если же чего то, что указано в отгрузочном документе нет в резервах, то опять тот же алгоритм: проверяем остатки, существующие резервы на них и рассчитываем, будут ли эти резервы обеспечены, если мы проведем отгрузку. Если нет - значит говорим, что недостаточно свободных ТМЦ и не разрешаем отгрузку.

(137) Я смотрел типовые. И если ты их тоже смотрел, то должен согласиться с тем, что там подобного механизма нет и никогда не было. Там есть просто четкое резервирование остатков. Конкретных остатков. И такой механизм у меня уже реализован. Но я еще раз повторяю, задача - оптимизировать систему резервов так, чтобы мы могли максимально использовать существующие остатки.
В типовой нет конкурирующих параметров, как в моем примере, т.е. когда может заказываться Номенклатурная позиция и ТМЦ без указания варианта, а может Номенклатурная позиция и Вариант ТМЦ без указания самой ТМЦ. Именно в этом вся сложность задачи.

(134) Ты путаешь характеристики и структуру номенклатуры. Для выделения характеристик как раз сделан подчиненый справочник ВариантыТМЦ. Для него можно определять характеристики. Хоть две, хоть пять, хоть тысячу. Например, для Номенклатурной позиции Ботинки защитные можешь сделать варианты "Размер 41", "Размер 42" и т.п., т.е. разбить их по одной характеристике - размеру. А можешь сделать варианты "Размер 41 белый", "Размер 41 Черный", "Размер 42 белый", "Размер 42 черный" и т.п. Можешь и еще какую-нибудь характеристику выделить. Но в дальнейшем оперировать ты будешь все равно элементами справочника Варианты ТМЦ. Так что с этим все нормально.

(152) можно сделать резерв на 5 тапочек 39 размера белого цвета и без разницы какой фирмы и фасона? если - да, то я все правильно понял....

(150) ну ты утомил...
.
"то, что достаточно - ставим в резерв, остальное - в очередь резервов (регистр, аналогичный регистру "Резервы ТМЦ", только там есть еще измерение "Приоритет")"
.
"остальное - в очередь резервов " - это и есть "резервирование в будущем" - иначе - это было бы зарезервировано сейчас. А ты, наскольо я понимаю планируешь необсепеченные резервами позиции резервировать, например, при поступлении товара... (таковая задача в тему ветки не входи оставим ее пока)
.
очередь резервов в ТиС не описывается регистром "РезервыТМЦ". "очередь резервов" в ТиС описывается регистром ЗаказыЗаявки -0 который заодно и выстраивает "будущие" резервы по приоритету (ну это тоже не особо важно).
.
"Очередь резервов" - обычный регистр с конкретной номенклатурой, которйо не хватило при очередном "витке" резервирования.
.
У тебя при любом планируемом изменении остатков товара надо считать оптимизационную задачу максимального удовлетворения ВСЕХ ТЕКУЩИХ РЕЗЕРВОВ + вновь поступающих заявок(резервов)/отгрузок/поступлений.
.
При отгрузке надо пересчитать ВСЕ текущие резервы (по всем заявкам) - тогда возможно удастся отгрузить те товары, которые есть в отгрузке, но не было в резерве. Если таковой пересчет не сделать - не удастся максимально удовлетворить отгрузку из существующих остатков.
.
также возможно (в заивисмости от выбранной тсратегии отгрузки - с догрузом по заявке или с полным закрытием заявки неполнйо отгрузкой) - придется пересчитывать очередь резервов - потому что могут появится свободные товары.
.
Любое поступление товара который падает в "свободный" остаток на склад - ведет к запуску процедуры резервирования для "очереди резервов".
.
Люая корректировка (отмена/снятие/итд) существующих резервов - полный пересчет текущих резервов и очереди резервов.
.

(153) Все зависит от того, что значит "размер, цвет, фирма, фасон". Я уже писал, что возможно 4 варианта.

1. С указанием только номенклатурной позиции. Например, я заказываю  освежитель воздуха, и мне все равно какой.
2. С указанием номенклатурной позиции и конкретной ТМЦ (не обязательно ТМЦ делятся по производителям). Например, я заказываю Освежитель воздуха Аirwick (а на складе при этом есть Airwick, Airwick Plus, Airwick Ultra, Glade, Glade Super... и каждый с различными вариантами запаха). И мне все равно, какой запах.
3. С указанием номенклатурной позиции и варианта ТМЦ. Например, я заказываю Освежитель воздуха с запахом лимона. И мне все равно, будет ли это Airwick, Airwick Ultra, Glade или что-то еще.
4. С указанием номенклатурной позиции, ТМЦ и варианта ТМЦ. Например, я говорю, мне нужен освежитель воздуха Glade с запахом лимона.

все я ушел из темы.... у тебя частный случай того о чем я говорю, или ты намудрил чего-то.

Все равно я уже ничего нового не напишу не вникая в конфу...

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

(154) Оставим очередь резервов. Задача с очередью вообще не является сложной, она у меня уже давно реализована и работает без проблем.

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

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

(160) Совершенно верно.

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

(161) ярад что наши мнения совпали

(159) Читай (152)

Скольо примерно в среднем стоит "номенклатур" в резерве и в очереди резервов?

(162) Как раз для решения задачи аналогов и были созданы 2 справочника: "Номенклатура ТМЦ" и подчиненный ему "ТМЦ". Т.е. ТМЦ, у которых один владелец - это и есть аналоги.

(164) угу, это непринципаильно как сделать - можно по всякому... А речь идет о том, что если у тебя будет стоять резерв по какому-то набору "характеристик" - надо четко знать какой конкретно номенклатуре ИЗ ЗАЯВКИ КЛИЕНТА эта запись в ресгитре резервов соответсвует.

(167) Не нужно этого знать. Просто при отгрузке проверяем, есть ли в резервах такие, как отгружаются и их списываем с резерва.

(166) хз как там имеет смысл сделать.
.
если набор "характеристик" - ограничен типа видТМЦ, бренд, запах - то (возможно) проще эти характеристики "зафиксировать" в картчоке номенклатуры и юзать их в лагоритмах. Бо вести/соблюдать корректность справочника аналогов - вручную не справятся... или будет сидеть стадо "обезъян" за которыми глаз да глаз нужен...

(168) "Просто при отгрузке проверяем, есть ли в резервах такие, как отгружаются" - и как ты это проверишь...? при отгрузке "освежитель лимон" - будешь в резервах искать "освежитель глайд лимон" или "освежитель аура лимон"...?
- могут быть неоднозначности... и нагрузка на систему лишняя будет.
.
а если известно что резерву "Освежитель Глайд лимон" в заявке/отгрузке соответсвует строка с номенклатурой "освежитель Лимон" (а не "освежитель Глайд") - все будет чуток попроще .. имхо..

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

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

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

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

(172) По-моему, ТС как раз хочет разгрузить менеджеров.

И ты продолжаешь обсуждать другую задачу - резервирование конкретного товара на складе.

(1710 (172) угу - примерно так я выше и написал по ряду вопросов

(172) (174) То, что ты описал, как раз таки давно везде есть и работает. И тут действительно никакого велосипеда придумывать не надо. Но как правильно заметил мистер в (173), ты продолжаешь обсуждать абсолютно другую задачу, зачем ее обсуждать, тут все и так знают, как она решается. ))

Для любителей типовой:

У кубиков 2 свойства, цвет и материал.
Белый, черный, красный;
Дерево, пластик, металл

На складе 45 кубиков по 5 штук каждого вида.

Зарезервируйте хотя бы 36 кубиков по такой заявке:

12 белых
12 деревянных
12 черных

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

(177) как им на оптимизацию с колокольни

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

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

угу как же вот из (176) есть резерв на 10 кубиков белых
(он выполняется на данный момент 5 деревянными и 5 пластиковыми)
- замечательно, но вот нужен еще резерв на 15 пластиковых кубиков (5 белых, 5 черных, 5 красных) и надо учесть что произойдет некое "перерезервирование"
- теперь 10 белых = 5 белых дерево и 5 белых металл

т.е. нужен приоритет обработки или алгоритм подбора/распределения конкретных товаров по этим условным "резервам"

(178)(177)  (176) в типовых 8ках почти все это есть. и никакого супер-алгоритма не надо. Просто надо пару раз внедрить хотя бы торговлю.

(178) Блин, о чем ты вообще говоришь? Какое на хрен перерезервирование? Что значит "продать то, что в резерве отложено". Ничего подобного моя задача вообще не подразумевает и близко. И это не я не понимаю какой-то проблемы, а до тебя никак суть не дойдет. Если ты говоришь о каком-то там "перерезервировании", то вряд ли ты вообще понимаешь, о чем речь.
Вот рассуждая о примере из (176) ты говоришь о резерве 10 белых кубиков и пишешь: "он выполняется на данный момент 5 деревянными и 5 пластиковыми". Уже по этой фразе понятно, что в вопрос ты не въехал нисколечки. Потому что резерв выполняется не 5 белыми и 5 черными кубиками. А есть некое множество комбинаций различных кубиков, с помощью которых данный резерв можно обеспечить. И на момент резерва, нам не важно, какие именно комбинации, не нужно ничего высчитывать. Главное понять, что они есть. И если придет заявка на новый резерв (или отгрузку), то опять нужно не считать, какие там кубики оставляем под резерв, а нужно проверить, останется ли хотя бы одна комбинация кубиков (любая), удовлетворяющая существующие резервы. Если таких комбинаций одна и более - разрешаем. Нет - отказываем. И никакого на фиг "перерезервирования". Это опять из совершенно другой оперы.

(179) Аналогично (178) - так ты ничего и не понял. Нет в типовых ничего подобного, хоть ты сто раз внедряй УТ, УПП, УП, БП и все-все-все.

(180) Замечательно а теперь какой будет алгоритм проверки что все созданные документы резерва в данный момент обеспечены?

Что для них хватит реального товара для реализации?

А если не хватает то может надо просто перераспределить товар между реализациями и все замечательно хватит?

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

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

И хватит ли времени дождаться пока все ("Если таких комбинаций одна и более") будут проверены? А их дохрена будет причем кол-во комбинаций растет ё моё видать про комбинаторику ну совсем не в курсе ))

(180) потому что! допустим пришла заявка в которой надо конкретный товар "Освежитель глейд оимон" - а ты его не сможишь зарезервировать потому что он у тебюя стал в резерв под какую-то другую заявку с условие "освежитель лимон".
.
Поэтому при поступлении новой заявки - то что раньше "освежитель лимон глейд" обеспечивал резерв по "освежитель лимон" - снимается, теперь "освежитель лимон глейд" обеспечивает резерв по новой заявке для "освежитель лимон глейд", а для старой заявки "освежитель лимон" будет обеспечиваться "освежитель лимон аурум".
.
если этого не сделать - такого "перерезервирования" - то по новой заявке ты не сможешь зарезервировать/отгрузить заказанный "освежитель лимон глейд" - потому как его нет в "свободном остатке". В какой момент перерезервировать - по заявке или по факту отгрузки - уже не суть важно

(179) в типовых есть (183)..? - очень сомневаюсь!!!

(182) > А если не хватает то может надо просто перераспределить товар между реализациями и все замечательно хватит?
- вот-вот, и я про это написал. а ТС как-то уперся и не понимает...

(185) +100500 ))

(180) Противоречишь сам себе
"..И на момент резерва, нам не важно, какие именно комбинации, не нужно ничего высчитывать. Главное понять, что они есть."
.
чтобы ПОНЯТЬ что они есть - как раз ПРИДЕТСЯ посчитать.
.
и ЖЕЛАТЕЛЬНО просчет - зафиксировать, то есть запомнить - какие варианты как разлеглись.
.
просто потому, что если что-то можно посчитать и запомнить сейчас - это наджо делать СЕЙЧАС. ПОТОМ может сложиться ситуация, что банально не хватит времени.
.
да, в принципе, может быть и нет необходимости фиксировать резервы. но это значит что при любом движке заявок/отгрузок придется пересчитывать весь массив поступивших и незакрытых на данный момент заявок. При этом надо помнить что какие-то заявки ранее по ним был принято решение "заявка может быть обеспечена в полном объеме". если Не запоминать ранее просчитанный резерв пожд эту заявку - при новом расчете (при поступлении новой заявки) - может оказаться что старую заявку не поностью получится удовлетворить - а это плохо, так как по ней скорее весго уже "договорено" все...
.
при фиксации таких "нечетких" резервов - по крайней мере при оформлении реализации не надо будет делать повторный просчет - тупо отгружаем ранее просчитанный резерв. хотя бы на этом можно выиграть...

(187) Кстати можно ведь проще все сделать, да будет частичное решение но менагеров удовлетворит в принципе

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

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

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

(183) Ты все упорно хочешь зарезервировать остатки. И никак не можешь отойти от этой мысли. "...а ты его не сможешь зарезервировать потому что он у тебя стал в резерв под какую-то другую заявку с условие "освежитель лимон"."
Ничего никуда не стает! Пойми ты наконец! НИКАКИЕ остатки НИКУДА не встают!

(182) "Замечательно а теперь какой будет алгоритм проверки что все созданные документы резерва в данный момент обеспечены?"
Замечательно! Ты наконец начинаешь подбираться к сути вопроса ))

(180) "И если придет заявка на новый резерв (или отгрузку), то опять нужно не считать, какие там кубики оставляем под резерв, а нужно проверить, останется ли хотя бы одна комбинация кубиков (любая), удовлетворяющая существующие резервы. Если таких комбинаций одна и более - разрешаем. Нет - отказываем. И никакого на фиг "перерезервирования". Это опять из совершенно другой оперы."
.
мы говорим про одно и тоже разными словами. под "перерезервированием" - мы как раз и понимаем то что у тебя обозначено как "а нужно проверить, останется ли хотя бы одна комбинация кубиков (любая), удовлетворяющая существующие резервы. Если таких комбинаций одна и более - разрешаем. Нет - отказываем." - как ты ПРОВЕРИШЬ - не проведя ПЕРЕСЧЕТ с учетом новой заявки...? - это собственно и есть перерезервирование. дальше - чисто технические вопросы... вот твое "..нужно проверить" - как раз и будет некая оптимизационная задачка...
.
При псотуплении новой заявки прдется"проверять" - как проверили - результат такой "проверки" - фиксируем как текущее состояние резервов. после последней "проверки" - нет изменений заявок и делаем отгрузку - смотрим - в отгрузке нет "новых" строк - тупо берем ранее зафиксированные резервы и отгружаем конкретные номенклатуры (которые были привязаны к нечетким резервам). Если в отгрузке есть новые строки - снова пересчет с целью макисмального удовлетворения хотелки клиента и отгрузка по факту пересчета.
.
вертеться будет все очень небыстро.

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

(187) "...и ЖЕЛАТЕЛЬНО просчет - зафиксировать, то есть запомнить - какие варианты как разлеглись..."
Вот в том то и проблема, что ты этого желаешь. Но если это сделать, то это будет совсем не то, о чем я говорю. А будет то, что уже давно сделано в типовых. Но задача другая, епрст!

(190) мы поняли что не встают )) но виртуально то нужна проверка хватает ли? вот и говорим что ВСТАЮТ, только не запоминаем но лучше бы запомнить чтобы потом заново не подбирать все...

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

(195) см (194)

(196) А кто говорил про "мгновенно"?

(190) ты - дятел. Встают. отписал выше почему так лучше. Можно и не ставить. но тогда будет проблем больше.

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

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

ну пусть 2-3 минуты - устроит?

(198) и (200)+  ага менагер будет ждать несколько минут пока документ резерва проведется покажет результат )) ню ню

(194) ты дятел *2.
На складе
- освежитель Лимон Аурум = 1шт
- освежитель лимон Глейд = 1шт.
.
(упростим) Пришли две заявки одновременно (упрощени тут как раз) один клиент хочет "освежитель лимон", второй хочет "освежитель лимон глейд".

ВАРИАНТ А)

ПОСЧИТАЛИ - можем удовлетворить две заявки - запомнили сам факт что можем удовлетворить две заявки. ИТОГО = 1 ПРОСЧЕТ.
.
Отгружаем заявку (пофиг какую). Чтобы понять какую КОНКРЕТНУЮ номенклатуру отгрузкить под "нечеткую" хотелку клиента - ДЕЛАЕМ ВТОРОЙ ПРОСЧЕТ чтобы найти конкретные позиции ТАКИЕ, ЧТОБЫ ОСТАВШИЕСЯ НАШИ КОКНРЕТНЫЕ ОСТАТКИ НОМЕНКЛАТУРЫ МАКСИМАЛЬНО УДОВЛЕТОВРЯЛИ оставшиеся заявки. ИТОГО = 2 просчет.
.

ВАРИАНТ Б)
ПОСЧИТАЛИ - можем удовлетворить две заявки - запоминаем сделанный просчет:
хотелкаКлиент1: "освежитель лемон" = "наша номенклатура Освежитель лимон Аурум"
хотелкаКлиент2: "освежитель лемон Глейд" = "наша номенклатура Освежитель лимон Глейд"
ИТОГО = 1 просчет.
.
выполняем отгрузку: тупо из запомненного ранее просчета выдергиваем наши конкретные номенклатуры и отгружаем их.

вариант А) = 2 просчета
вариант Б) = 1 просчет
.
экономия ресурса = 50%, что вообщем нехило...

(202) не не устроит он же не хочет запоминать промежуточные зачем базу раздувать да ))

Вот тут у меня киношечка, имеющая некоторое отношение к обсуждаемой задаче (спасибо NS)
.
http://screencast.com/t/hBHfxBu9
.
раскладывается около 300 позиций примерно..

(202) Ты осел. Что значит 2 заявки "одновременно"? Ты вообще 1С в глаза видел? )))

(202) Посмотри пример (63) и попробуй прикрутить к нему свой "Вариант Б". Может, до тебя допрет в конце концов.

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

(205) глаза разуй, и напряги извилины. я написал что УПРОЩЕНИЕ состоит в том, что две заявки пришли одновременно.

(207) Ну если для тебя это одинаковые, и ты в упор не видишь, к чему твой "Вариант Б" приводит (вместе с твоими раскладываниями), то наверное, пытаться тебе что-то объяснить вообще бесполезно. Лучше помалкивай, а то позоришь свои "умные извилины".

(209) ну я вообщем то на конкретном примере показал преимущества варианта Б) над Вариантом А).
.
разложи свое видение на примере (63) - поподробнее плиз.
хочется посмотреть что и как и скольо раз ты будешь считать в своем варианте вИдени ярешения задачи.
.
все чертики кроются в мелочах, пока оперируем округлыми словами "мы понимаем что удовлетворяем резервы/заявки" - все зашибись... как только станем реализовывать "мы понимаем" - все становится веселее...
.
собственно, за сим я ветку покидаю ввиду бесперспективности ;-)надеюсь,  Garykom меня поймет/поддержит.
.
топикстартеру: если вдруг не получится реализовать задачу - стучись... мыло в личке...
.
rsergio что-то с запросмо который он собирался быстро надыбать - пропал...

(210) Какие к черту преимущества, если "Вариант Б" не решает задачи ВООБЩЕ?

начнем с того как хранить "резервы"

1. справочник "Номенклатура ТМЦ" добавляем ТЧ "ШаблонХарактеристик" с ПВХ
2. Справочник "Номенклатура" добавляем ТЗ Характеристики с колнками Параметр, значение, заполняется по владельцу
3. Делаем Справочник "КлючиНоменклатуры" с ТЧ "Характеристики" аналогичным как в "Номенклатуре", создание элементов - полностью автоматическое, для всех вариантов запроса по характеристикам, в наименование пишем хеш ТЧ (это будет текстовый ключ)
3. Делаем регистр подчиненный регистратору резерв "Номенклатура Тмц", "Номенклатура", "КлючНоменклатуры", "НомерСтроки", "НомерВарианта", в регистр пишем все возможные варианты резерва по конкретному документу

далее...

Делаем регламентое задание которое укладывает рюкзак резервов и заполняет в регистре новом регистре сведений заказ+вариант резерва,

можно и без регл задания, но лучше с ним....

далее запрос к регистру остатков+регистр активных вариантов+запрос к регистру вариантов

(212) Давай на этом и закончим ;). Зачем это все? ))

(212) Зачем ТЗ характеристики в Номенклатуре? Я же четко описал, как сделано. И с характеристиками там проблем нет.

(214) это решение которое можно реализовать, которое будет работать БЫСТРО и вполне потянет сотню активных юзеров

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

(211) это почему он не решает задачи: поступили две заявки, под них успешно разлеглись "резервы", по сделанным резервам успешно отгрузились заявки. Я как-то считаю, что задача выполнена.

(216)я не настаиваю, можно и в регистре

(215) если у тебя все работает - что ты ищешь здесь в нашем убогом местечке..? ;-)

(217) Соглашусь, что разные, но я уже писал, что для этого есть справочник "Варианты ТМЦ". Для элементов этого справочника можно определять любые характеристики в любом количестве с помощью планов видов характеристик.

(220) Где ты взял, что все работает? Прекрати писать ерунду.

(212) вон даже vde69 описывает конкретное решение практически уже - почти то что я изложил. По крайне мере мне понятен ход мыслей vde69

(218) Считай дальше.

(223) Тебе не понятно главное. Суть моей задачи. И я уже уверен, что до тебя никогда не допрет.

(22) еще раз: по варианту Б) описан вариант реализации. которы йрешает твою задачу. на складе есть две номенклатуры. Поступили 2 заявки, в однйо из которых номенклатура не совпадает ни с однйо из конкретных номенклатур. далее показа вариант "резервирования", который при отгрузке позволяет удовлетворить хотелку клиента.

(226) Прекрати писать ерунду и позориться.

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

(226) Ладно, ты все решил, молодец. Только успокойся, прошу тебя. ))

(225) снизрйди господи до нас смертных, нарисуй для варианта

остаток на складе:
- Освежитель лемон аурум = 1шт
- освежитель лемон Глейд = 1 шт.
.
заявка клиента1: освежитель лемон = 1шт.
заявка клиент2: освежитель лемон глейд = 1шт.
.
ход расчетов вплоть до проведени яотгрузки - в том числе какие расчеты нужны (если нужны) непосредственно в самой отгрузке..

(228) - второй регистр для ускорения нахождения решения при поступлении новых заявок..?

Ладно, снизойду и попробую последний раз вразумить тебе, в чем суть. Давай пошагово:

Есть остатки:
Освежитель воздуха, Глейд, Лимон - 10 шт.
Освежитель воздуха, Глейд, Роза - 10 шт.

Поступает заявка:
Освежитель воздуха, Глейд, <Пусто> - 15 шт.

Что ты будешь резервировать?

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

кроме того в этом регистре можно сделать что-то типа "активен".

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

(232) Просчет1
Резервирую:
"Освежитель воздуха, Глейд" (Освежитель воздуха Глейд Лемон) - 10 шт
"Освежитель воздуха, Глейд" (Освежитель воздуха Глейд Роза) - 5 шт
.
Следующий вопрос..? (заметь - я стараюсь быть как можно более конкретным)

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

(233) угу, понятно

(234) Молодец, зарезервировал! Идем дальше... Приходит Клиент №2 и говорит: "Дайте мне один освежитель воздуха с запахом лимона". Твои действия?

Просчет2

Резервирую:
Заявка1, "Освежитель воздуха, Глейд" (Освежитель воздуха Глейд Лемон) - 5 шт
Заявка1, "Освежитель воздуха, Глейд" (Освежитель воздуха Глейд Роза) - 10 шт
.
Заявка2, "Освежитель воздуха, Лемон" (Освежитель воздуха Глейд Лемон) - 1 шт

Следующий вопрос..?
Топичи клаву быстрее мне на автобус бежать...

(238) И как это у тебя так зарезервировалось? Ты же уже 10 лимонов зарезервировал )))

(238) Теперь подумай сам, какой смысл в этом резервировании-перерезервировании? И попробуй ка написать процедуру, которая будет делать то, что ты тут написал.

(240) ОЧЕНЬ ПРОСТО ЗАРЕЗАЕРВИРОВАЛ - У МЕНЯ НЕТ СТАТСИЧЕСКИХ РЕЗЕРВОВ.
.
взял наличные заявки в составе
Освежитель воздуха, Глейд, <Пусто> - 15 шт.
Освежитель воздуха, <Пусто>, Лемон - 1 шт.
.
и "разнес" их на складские остатки.
.

(242) Ты же сам себе противоречишь. Что значит "разнес их на складские остатки"? Это и есть твои "статические резервы", как ты выражаешься.

(241) ну по крайне мерея я написал что нужен некий алгоритм, который будет делать таое "резервирование".
.
от тебя пока что не дождался раскладки - по товему примеру - распиши, как ты будешь резервировать.
.
у меня Просчет1 и просчет2 - это "процедура", которая возвращает нужджный ОПТИМАЛЬНЫЙ результат.
.
жду от тебя варианта товего

(242) И повторяю - напиши ка процедуру, которая будет это делать. Тогда до тебя точно должно дойти, в чем проблема.

(244) Ты вообще соображаешь, что пишешь? )))) Я эту тему начал с вопроса: "подскажите, какой должен быть алгоритм, чтобы это реализовать". А ты мне отвечаешь: "Должен быть какой-то алгоритм ))))

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

Но лучше беги на автобус, а то опоздаешь ;)

а хорошо ведь вбросил, вон сколько алгоритмов предложили )))

по теме: время жизни у резерва какое?

(245) фигли тебе подсказывать - когд анаичнешь тебе верхние слои алгоритма разъяснять - ты орешь что мы все тупые и нихрена не понимаем... ;-)

у тебя в (63) написано: "Задача в том, что мы не ставим в резерв конкретных ТМЦ.."
.
ну и у меня так же:
Заявка1, "Освежитель воздуха, Глейд" - 05 шт
Заявка1, "Освежитель воздуха, Глейд" - 10 шт
Заявка2, "Освежитель воздуха, Лемон" - 01 шт
.
то что я к этим НЕКОНКРЕТНЫМ тмц в скобочках указал наши конкретные ТМЦ - так это просто полезный бонус, который мне облегчит жизнь...
.
и то что у тебя описывается словами типа "...мы понимаем, что можем обеспечить заявку клиента" - у меня "реализует" процедура "Пересчет".
.
Я надеюсь ты как-то предполагаешь/предполагал фиксировать то, что ты "понял, что способны удовлетворить заявку"..? - да, каким-то способом скорее всего делаешь это. Я тоже такое "понимание" фиксирую - так как это описано в (234). С каждой пришедшей заявкой я снова делаю попытку понять, могу ли я удовлетворить новую пришедшую заявку - и снова такое понимание "фиксирую". если таковое "понимание" тем или иным образом не фиксировать - придется делать как минимум на один расчет больше - придется делать расчет при оформлении отгрузки - тогда ведь какими-то общими резервами не обойдешься - придется грузить вполне конкретную номенклатуру. а опыт показывает что клиентура ждать вообще не любит - ни 5 минут, не 10, ни вообще даже 2 минуты. ей возьми и положь прямо сейчас...
.

.

(247) 100 убитых енотов мне погоды не делают, я такие суммы трачу обычно не глядя... так что за тарелку супа - ты вон к vde69 стучись - он в теме, сделает тебе за 100 бакинских...
.
или вот rsergio обещал по быстрому запросец наклепать...
.
а если не осилишь - тады уже стучись... будет время - повертим задачу (хотя я сильно осмневаюсь что уменя будет свободного времени, своей работы хватает).
.
Но такие задачки - интересные, оживляют нашу серую 1сную жизнь...

(249) гораздо интереснее -
1. каково среднее суммарное количество позиций всех активных заявок клиентов, которые одновременно могут стоять в у нас в "резерве" и
2. каков средний размер в строках одной заявки клиента...?
3. каков средний темп поступления заявок клиентов (считаем что совпадает с темпом отгрузок) и поступленйи товаров..?

(252) примерную оценку я озвучил в начале ветки, это от 50 до 100 тр, так, что 100 бакинских тут катит только если есть чисто спортивный интерес....

(253) о чем я твержу уже 3 дня, конкретика решения СИЛЬНО будет зависить от предпологаемых объемов. Например ту-же задачу рюкзака (которую хдесь обязательно нужно решать) для 100 заявок можно решать перебором, а для 10 000 перебор поставит базу колом...

Когда я писал, что сделаю одним запросом, то не осознал еще суть задачи, когда осознал было уже поздно :)

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

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

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

На этом моменте я понял:
- Задача не решается ни за 10, ни за 100$.
- Вроде как основную массу кода написал и уже осталось совсем немного, но предположил что это "совсем немного" может затянутся на несколько дней отладки
- Согласен с Злопчинским, что резервы нужно считать сразу же. Почему? Потому что если мы просто ответим при резервировании "Можно!", то при отгрузке не понятно "А что можно то?" И задачу нужно будет решать повторно по тому же алгоритму. С учетом, что это практическая модель, а не логическая, то думаю таких вот хитрых резервов в базе не должно быть слишком много.
- Задача изначально не жизненная. Зачем нужны такие хитрые резервы и зачем их решать именно таким способом? Я не нашел примеров из жизни когда это нужно, вернее когда без этого обойтись совсем нельзя.

В общем немного напряг мозги, за что отдельное спасибо. Но дальше лезть и добивать код уже нет мотивации :)

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

(256) математическую модель? да ораторы тут на личности уже переходят, поэтому и не видят очевидного:
типовая УТ, регистр свободные остатки.
Можно делать резерв по товар+серия, Товар + <пустая серия>

Сделать контроль остатков по Количеству и Количеству по сериям сводно.
Задача в сабже отличается только тем, что надо будет добавить ресурс "сводно по виду ТМЦ"

p.s. как работает регистр "Свободные остатки" описывать не надо? )

(257) да пофигу на регистр, ты скажи чего ты писать будешь в резерв при таком заказе

ВидТмц=Шампунь
Номенклатура=Неопределено
Количество=100

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

(258) не поверишь так и запишу)
хватит мыслить шаблонами. открой УТ - посмотри как сделан регистр свободные остатки и как сделан контроль.

(5) т.е. за день работы ты готов заплатить только 100$?

движения по регистру СвободныеОстатки (вид ТМЦ / Номенклатура):

поступление товаров - запись приход :
"Освежитель" - "Glade" - 100 шт - 100 шт


резервирование (допустим нам не важно, любой освежитель). Запись расход:
"Освежитель" - "Неопределено" - 20 шт - 0 шт

Резервирование конкретного освежителя: Запись расход:
"Освежитель" - "Glade" - 30 шт - 30 шт

Итого имеет итоговую таблциу остатков

"Освежитель" - <пусто> - 50 шт - 70 шт
"Освежитель" - "Glade" - 70 щт - 70 шт

Это значит, что мы можем зарезервировать не более 50 шт (Сводно по освежителю)

Как проверять остатки при резервировании и запросы, надеюсь не попросите писать?

(259) то есть ты зарезервируеш пустую номенклатуру? и как будешь получать свободный от резерва остаток если у тебя 10 разных шампуней? Ты для каждого уменьшишь остаток на 100 или еще как?

Просто опиши как это будет выглядеть в форме подбора, выбрал я любой шампунь а там факт-100 ????

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

(262)+ кстати этот вопрос относится и к автору, интересно услышать его мнение

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

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

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

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

(266) вот это и нужно решить сначала. Без решения этой задачи в теории все остальное бесполезно.

(267) Ну вот поэтому и я предлагаю не хранить абстрактные позиции, а на этапе заказа автоматом подбирать РЕАЛЬНЫЕ позиции. Т.е. просто сделать помощник выбора по абстрактному запросу. Этим самым мы не поломаем все остальные механизмы и удовлетворительно решим задачу.

(0) Кстати, эта (268)  идея как раз и стоит 100$.

(268) Возможно, удовлетворительно. Но не полностью. Пример:
Освежитель Лимон 100шт
Освежитель Апельсин 100шт
Пришел заказ на 100 освежителей любых. Зарезервировалось, например:
Освежитель Лимон остаток-100шт; резерв-100шт; своб.остаток-0шт
Освежитель Апельсин остаток-100шт; резерв-0шт; своб.остаток-100шт
Пришел второй заказ Освежитель Лимон 50шт. Пересчитываем текущие заказы. Граничные два случая (между ними возможны промежуточные случаи, но к ним тот же вопрос):
А)
Освежитель Лимон остаток-100шт; резерв-100шт (по 50 шт на первый и второй заказы); своб.остаток-0шт
Освежитель Апельсин остаток-100шт; резерв-50шт (на первый заказ); своб.остаток-50шт
Б)
Освежитель Лимон остаток-100шт; резерв-50шт (на 2-й заказ); своб.остаток-50шт
Освежитель Апельсин остаток-100шт; резерв-100шт (на 1-й заказ); своб.остаток-0шт

А теперь вопрос - какие свободные остатки у нас сейчас на складе после двух резервов? Иными словами - как ответить на вопрос клиента "а какие освежители у вас сейчас доступны"?
Если резервировать РЕАЛЬНЫЕ позиции, то в случае А не увидим остаток лимонного, в Б - апельсинового. Несмотря на то, что правильный ответ (что в резерв сможем поставить) - либо 50шт одного либо 50шт другого (или 49шт одного и 1шт другого; или 48 одного и 2 другого).

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

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

+(271) Лучше сделать сайт с прайсиком и корзиной и плясать от этого.

(270) А для этого есть система характеристик - у нас Освежитель - это товар и его у нас 200 на складе и 150 в резерве. А требует ли резерв точного указания характеристики или нет - это уже вопрос к реализации.
Просто, если мы вводим аналоги, характеристики и т.п., то потом может оказаться, что для кого-то кипятильник и утюг - это аналоги.
Поэтому, или точный резерв по конкретным позициям, а в случае приближённого - списание "по среднему", то есть чтобы конечные резервы всех аналогов оказывались наиболее близки друг другу, или использование характеристик и аналогов и куча головной боли с проверкой доступности товара.

(255) спсб, я рад что наши оценки совпадают

(254) тут не столько количество заявок, скольок суммарное количество строк в живых заявках

(273) "у нас Освежитель - это товар"
Ненене. По условию задачи у нас Освежитель - это номенклатурная группа, а Лимон и Апельсин - это разные товары. С разными ценами, производителями, поставщиками, артикулами, фасовкой, объемом, еще один из них - российского производства, а другой - ЕС. И у каждого из них еще по нескольку характеристик.
"его у нас 200 на складе и 150 в резерве"
Ага. Вот только как без точного резерва точно сказать, какие запахи доступны для продажи у этих 50 свободных штук?
Как-то не вижу я решения без точного резерва. Надо у того товарища спросить, который ут 10 предлагал.

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

(270) > А теперь вопрос - какие свободные остатки у нас сейчас на складе после двух резервов?
.
Свободные остатки у нас на складе - ответ на этот вопрос несущественен в рамках рассматриваемой задачи. Так как клиента интересуют не конкретные позиции, а "обощенные" хотелки...
.
> "Иными словами - как ответить на вопрос клиента "а какие освежители у вас сейчас доступны"
- в рамках того как я описывал (с фиксацией к обощенной хотелке клиента конкретной номенклатуры, закрепившейся к обобщенной) - ответ дается практически мгновенно - достаточно снять обычный отчет по свободным остаткам - только потому что в вопросе максимальная степень обобщенности "Освежители".
.
А вот ответ на вопрос "у вас есть освежители Глайд" - потребует пересчета "резервов" (без запоминания варианта расчета) - потому что это даже не фиксация хотелки клиента. И если через 5 минут клиент созреет для заказа - может оказаться что фиг вам - "Освежитель Глейд" - уже будет недоступен для этого клиента (как в ситуации с обычными резервами на обычные товары)

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

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

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

(271) > Поэтому надо думать в направлении формирования четких заказов
.ясен пень - клиен прислала какие-то общие хотелки, а мы зарезервировали конкретные номенклатуры - так бы было зашибись... Однако у топикстартера - одно из требований к алгоритму - максимальное удовлетворение заявок, а это можно обеспечить только при полном пересчете всех текущих "резервов" при поступлении новых заявок.
.
Вдобавок надо иметь в виду - клиент прислал заявку, мы ее обощенно зарезервировали - ага... 30 тыс (если танцевать от фиксированных позиций, соответсвующих обобщенным). Клиент приезжает - оказывается что нифига не 30 тыс, а 40 - потому что пока ехал - куча заявок пришла от клиентов и вся ситуация с резервирвоанием обобщенных - поменядась... Такой вариант может быть неудовлетворительным. А это значит, что после соглдасования суммы - обобщенный заказ превращается в менее обощенный - при пересчете позиции можно менять примерно на такие же по цене.
.
ясен пень, если клиента сумма заказа как таковая не волнует вообще, вплоть до момента получения товара - все гораздо проще - считаем сумму по факту отгрузки... но тут ооооо!!! открывается море перспектив - клиенту сразу втюхиваем максимально дорогой/с наибольшим доходом товар (это второе условие оптимизации после макисмального обеспечени язаявки)...
.
;-)

(279) я думаю что до счетов у ТС вряд ли дело доходит.. ;-) скорее всего  это "большой ларек" куда приезжают затариваться всякие ларечники/ипшники... по факту...

(279) Поэтому пусть делают сайт или пускают в базу покупателей и пусть себе набирают чего хотят.

1. Выкинуть первый справочник нах
2. Третий подчинить второму
3. У второго добавить булев реквизит: УчетПоВариантам, если Истина, то вариант указывать обязательно

(283) Ну все. 100 баксов теперь точно твои.

(278) Читая твои посты, я ощущаю себя сказочно тупым.
"ответ дается практически мгновенно - достаточно снять обычный отчет по свободным остаткам - только потому что в вопросе максимальная степень обобщенности "Освежители""
Вот у меня в 270 маленький пример. Какой отчет может показать доступные для покупки освежители в разрезе запахов - учитывая 51 разную комбинацию ??

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

(285)не гони волну ;-) в твоем вопросе изначально было ""а какие освежители у вас сейчас доступны"? - про "в разрезе запахов ничего сказано не было...
.
> "Какой отчет может показать доступные для покупки освежители в разрезе запахов" ?? - тривиальный отчет: "выдергиваем" все наши конкретные существующие товары, которые подходят под шаблон "Освежитель+Запах", сворачиваем их до уникальных кортежей "Освежитель+Запах", из полученного перечня формируем псевдозаявку клиента, натравливаем на нее наш красивый алгоритм "пересчета/резервирования" - получаем ответ в виде аналогичном проводящемуся штатно резеривроанию.

(286) угу, тут извините от ЧЕТКИХ подборов и ручных действий манагеров придется отказаться. Тем или иным образом "вколотили" заявку клиенат в обобщенном виде - запулили в очередь на проведение/расчет. получили результат. Через 5 минут клиент звонит - эээ там я просил 6 освежителей.. вы это.. ну там.. вычеркните - мне надо 3 лимона + 2 яблока и обязательно один Глейд - вколотили - ушло в очередь - все "резервы" переколбасились - удалось удовлетворить - зашибись... не удалось - извините.. единсевенный выход удовлетворить клиента - предложить ему увеличит порог обобщенности - вместо 3+2+обязательно глейд" снова вернуться к "просто 6 освежителей"... или посчитать возможные варианты, близкие к затребованным кдиентом - вместо лемона - грейпфруты.. ;-)

И ещё не забываем случаи, когда пересчёт одного в другое идёт не 1 к 1, например, изделие в упаковке 2, 3 или 4 (как обычно батарейки продаются).

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

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

(291) резиновые сапоги и калоши это аналоги???

тут вопрос сложный ними :)

Фигли тут обсуждать...
ждем когда ТС сумку с баблом из кабинета гендира принесет..

(293) ТС похоже в срочном порядке место работы меняет.

(287) "в твоем вопросе изначально было ""а какие освежители у вас сейчас доступны"? - про "в разрезе запахов ничего сказано не было... "
Ах ты к словам придираешься?! Тогда я... тогда я... тоже начну, вот!
Всего два разных освежителя; разные они - запахами. Т.о. "какие" - может означать только "какие в разрезе запахов", ибо других разрезов освежителей в моем выдуманном простом примере нет.
Далее.
Ты продолжаешь заставлять меня чувствовать себя тупым. Где в процессе "выдергивания" на менеджера выскочит 51 вариант доступных товаров? При "из полученного перечня формируем псевдозаявку клиента"?
Лично мое мнение, что если эти варианты в какой-то момент на менеджера выскочат, то это будет пример решения математически верного, но в прикладном плане бесполезного. А без этого я совсем не понимаю, как реализовать подбор по свободным остаткам.
(293) Не принесет ТС от гендира ничего, кроме жалостливой истории.

(262) (263)

да легко. форма подбора в виде:
"Товар" "запах" "Остаток своб" "остаток"
"Освежитель " "<все сорта>" 50 шт (100шт)
"Освежитель" "glade" - 50 шт (50 шт)
"Освежитель" "glade2" - 50 шт (50шт)

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

(295) на менеджера - ничего не будет "выскакивать" (если бы я делал). Потому что ненужная эта инфа.. тем более в виде "51 варпианта" - нахрена ему что-то выскакивать/показывать..? оно что будет делать - считать быстрее и лучше чем комп? - полностью уверен что нет. все что манагеры делают ручками - все криво и косячно в мегаподавляющем колве случаев. особенно при большом потоке инфы.

.. поэтому (296) - абсолютно бесполезная инфа для манагеров, и может прокатить когда заявки состоят из 1-3 строк... при суммарном количестве "резервов" строк примерно до 15-20. да и это количество не осилят.

Готов получить 100$ - прямо в тему обсуждения:
.
http://infostart.ru/public/295343/

ну что там? как дела? ТС где-то потерялся...

(301) и ... с ним лучше с Алгоритм нахождения подстрок в строке помогите ))

(276) Совсем не так. Изначально Шампунь - это да, что-то вроде номенклатурной группы (если выражаться правильным языком, то это номенклатурная позиция). Но Лимон и Апельсин - это не разные Товары. Разные товары - это:
...
- Шампунь Лореаль Мультивитаминный 0.2 л.
- Шампунь Лореаль Мультивитаминный 0.5 л.
- Шампунь Лореаль Восстановление волос 0.2 л.
- Шампунь Лореаль Блестящие волосы 0.2 л.
...

И еще есть варианты товаров. С шампунями реального примера не приведешь, но вот, например с обувью это будет:
...
- 41 размер черные
- 41 размер коричневые
- 41 размер синие
- 42 размер черные
- 42 размер коричневые
- 42 размер синие
- 43 размер черные
- 43 размер коричневые
- 43 размер синие
...

И нет никаких "других характеристик", о которых ты говоришь.

(278) Вообще ничего подобного

(280) Ужасная логика.

(283) Ну это стандартная структура справочников. Раньше в конфигурации именно так все и было, но понадобилось изменить структуру именно до того вида, как это сейчас (справочник "НоменклатураТМЦ" и два подчиненных ей справочника: "ТМЦ" и "ВариантыТМЦ").

(292) Нет, не аналоги.

(293) А ты что, решил задачу? Давай код, для тебя мне и 300 не жаль. Только вот видя твои рассуждения очевидно, что ты никогда эту задачу не решишь. Вот rsergio уже все понял. Ты пока нет.

(294) С какого перепугу мне это делать?

(305) согласен.. в (280) - можно сказать домыслы.. размышления. я такое называю "в порядке дежурного бреда".. ;-)

(304) ничего подобного - чего именно ничего подобного?

(308) ну-ну... мне вот понятно, что rsergio и я "думаем" эту задачу примерно одинаково... Пока что мне понятно, что ты задачу сам не понял.. бо у тебя в голове вертятся некие общие соображения по этой задаче. а конкретики - нет.
.
Задача сложности - выше средней, где-то примерно 0.75 по моей оцценке на шкале сложности. Но вполне решаема. Суперсложной математики там не будет. даже примерно понятно как ее решать. но стоит это решение не 100 и 300 бачинских - так что - как-нить без меня.. за тарелку супа трудитесь...
.
слава богу, все задачи разной сложности, которые передо мной стояли - более-менее успешно решал. надо будет мне - и эту решу.
.
А пока, вьюноша, трудитесь! труд - он облагораживает... ;-)

до тысячи добить решили?)

(303) "Я тебя полюбил - я тебя научу" (Кин-Дза-Дза, да?)
Ты придумал много собственных названий для определенных и всем известных вещей. Так вот, выражаясь ОБЩЕУПОТРЕБИТЕЛЬНЫМ языком: "Шампунь" - это номенклатурная группа; конкретный товар "Шампунь вкусный витаминный арт.7123789/123" - это и есть товар (номенклатура); а "41 размер черные" - это характеристика (справочник, подчиненный товарам). Любой, кто хоть раз открывал типовую, понимает разговор в таких терминах. Так что все у меня правильно написано.

Ты лучше на (270) ответь, на элементарном примере - как ты хочешь видеть свободные остатки после двух резервов?