Резервирование товара на складе построено на регистре остатков, в нём добавлен ресурс Резерв.
Документ "Счёт" этот ресурс увеличивает на количество товара в счёте, а документ созданный  на основании счёта - уменьшает на количество в счёте.

Изначально в базе на основании счёта можно было создавать только один документ и всё работало. Потом захотелось на основании счёта создавать несколько разных документов. При таком раскладе 2й и последующие документы созданные на основании счёта уже не должны изменять регистр остатков в части измерения Резерв

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

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

скрин регистра:
https://drive.google.com/file/d/1MRmKW3ls5kQhoMkdwi3OojwPMbFUDcz7/view?usp=sharing

(0) - остатки - это то что можно потрогать, это живой товар в наличии. Резерв - это виртуальная сущность. Его нельзя потрогать, пощупать. Поэтому разумно не путать одно с другим, а иметь 2 регистра - Остатки и Резервы, чем всякий раз при изменении резерва переписывать остатки.

(1) Ок можно было бы и два регистра завести, хотя интересно было бы понять, в чём конкретный минус перезаписи документами Счёт Регистра Остатки?

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

(2)Например тем, что остаток это ресурс для (Товар, Склад). А резерв для {Товар, Склад, Заказ}

(3) И несколько реализаций и любые другие документы тоже могут быть.
Т.е. логика такая - если по счёту выдан ЛЮБОЙ документ, проставленные счётом резервы сторнируются.

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

(4) У меня для резерва не используется измерение Заказ. Я не усложняю, мне достаточно видеть резерв только по Склад+Товар

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

Конечно самая правильная реализация /с точки зрения проектирования реляционных баз данных правильной формы - это мне не даёт покоя институтское прошлое :)/ резерв не хранить в регистре а высчитывать.
Т.е. тупо проверять все проведённые и не списанные счета и в них и будет зарезервированное количество товара.
Но в 1с наверное такой просчёт будет медленным

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

(7) Да, извиняюсь, я не уточнил. Я также облегчаю этот момент, когда счёт списывается, то по этому списываемому документу Резерв сторнируется на количество именно в счёте.
Не важно что в счёте 7шт а продано по счёту 2шт, сторнируется всёравно 7шт

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

(8) почитай 7
Ты всё с тр, ностью до наоборот исковеркал.
Н каких просчётов из регистра при реализации не делается. Считывается текущее дна, ение и все.
То сто ты сторон руешь ч ото в самом счёте это хрень полная исходя из классики 77.
Счёт увеличивает резерв. Реализация, уменьшает резерв.

(11) Это не понял. Но может и не нужно.

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

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

Мутная какая то задача. Что такое следующие документы? На основании чего они выписываются?

(14) :)
Так в чём трешь ?

С большего - у меня движок резервирования построен по такомуже принципу как и регистр остатков

(15) На основании исходного счёта. Блин, я думал что понятно объяснил ).

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

А недавно я разрешил на основании счёта через (Alt+F9) создавать много документов. И пошёл косяк в части резервирования, т.к. сторнирование резерва стало дублироваться в каждом выдаваемом по счёту документе

(17)Почему тогда при первой отгрузке списывается весь резерв. Надо списывать только то, что отргружается. Остальное остается в резерве для других отгрузок по этому счету. Почему  резервы нужны только 1 раз ?

Либо списывайте все и делайте другой счет. Он будет без резервов

(18) писал выше. Для облегчения реализации. Логика простая : если по счету выдан документ, даже пустой, значит резерва нет

(19) так и делаем. Если выдали не все по счету и на остаток нужен резерв, просто создаётся новый счёт на остаток

Не взлетит.

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

Ептя. Регистр счёт
Измерения товар счёт
По счету движение в Нью-Йорке боой реализации движение в минус по всему количеству остатка счета.

(21) хрень полная.
Как ты поймёшь все или не всё выдали по счету.

Сорри в дороге, пр Лу к компу отп шу.
Автор задачу описывает рваными кусками вместо цельного изложения. Требуется учитывать потребность клиента? Неясно! Требуется учитывать сколько мы можем о грузить из наличия - да.

(23) Ребята, у меня ощущение что Вы меня не слышите )

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

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

3й раз попробую:
есть два алгоритма резервирования:
В счёте Товар№1 5штук. Значит остаток по резерву стал +5.
Далее списываем счёт, но выдаём 2штуки
и тогда в вашем 1м (продвигаемом вами) варианте нужно списать по резерву только 2штуки со знаком минус и в регистре останется 3шт

а 2й вариант - это списать по регистру ВСЁ количество В СЧЁТЕ, т.е. 5 штук. И остаток по связке Товар№1-Склад станет равен 0, т.к. по данному складу нет не списанных счетов с данным товаром

(25) ))
Это видно в расходке. Если есть большое желание - легко это увидеть.

(26) >"Требуется учитывать потребность клиента? Неясно! "

Согласен, это не описал. Отвечаю: потребность клиента движок резервирования не реализует (и такой необходимости нет).
Движок резервирования заточен только под определение свободного остатка товара на складе.
Сори - это нужно было описать в (0)

(27) "а 2й вариант - это списать по регистру ВСЁ количество В СЧЁТЕ, т.е. 5 штук. И остаток по связке Товар№1-Склад станет равен 0, т.к. по данному складу нет не списанных счетов с данным товаром"

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

И я бы с удовольствием переделал свою реализацию под этот правильный способ /повторюсь, потому что так диктуют мне сделать мои учителя институтские, которые целый год вбивали мне принципы проектирования баз данных :)/,
но я не уверен что движок 1с будет справляться с такой задачей с приемлемой скоростью

Ответь на вопрос
1. Когда хотелка клиента в виде счета на 100 шт считается исполненной?

2.хотелку клтента регистрирует менеджер по пинку/заявке от клиента?

В парадигме автора резервы вообще нахрен не нужны. Резерв = мин(Остатокнаскладе, сумма незакрытых хотелок клиннта)
Всё.

У ТС резерв - обобщённый. Вот сколько можно сейчас со склада отгрузить по счету - столько и отгружают и пофиг на резервы. Они никому не принадлежат, их можно взять под любой счёт.

Всё что надо - вести учёт остатка товара. Это есть. И учёт сколько хочет клиентура - это просто учёт незакрытых количеств по счетам клиентов. Всё.
Развели бодягу... Я через 15 мин у компа. Если ТС интересно продуктивно пообщаться - телега @Dobrop

(31) >"1. Когда хотелка клиента в виде счета на 100 шт считается исполненной?"

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

>"2.хотелку клента регистрирует менеджер по пинку/заявке от клиента?"
Да, по заявке клиента манагер создаёт счёт и далее его контролирует. в 95% случаев по счёту отгружается весь товар из счёта сразу, в остальных 5% списывается часть товара и тогда по нажатию кнопки на остаток создаётся новый счёт.
Согласен что красивее ваш вариант, когда не нужно создавать новые счета а регистр сам считает не списанный остаток, но он сложнее в реализации и потенциально несёт больше ошибок, поэтому я пошёл по пути упрощения

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

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

(34) >"И учёт сколько хочет клиентура - это просто учёт незакрытых количеств по счетам клиентов. Всё."

Верно, и задача стоит - выбрать правильную реализацию сей хотелки.
Я вижу два варианта:
1) Оставляем текущий созданный регистр /описан в (0)/ как есть и тогда программно при проведении расходки смотрим - первый ли это документ выдаётся по счёту (и тогда при его проведении весь резервы ПО СЧЁТУ сторнируется) либо создаваемый на основании счёта документ не первый и тогда регистр резервов мы не двигаем.
Минус: придётся в нескольких местах чётко прграммно отслеживать проведение, распроведение, изменения количества в счёте и т.д. и всё равно можно где-то допустить ошибку и резервы будет не верно считаться.
Плюс: структура БД не требует изменений

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

а тему завёл выяснить, может есть 3й вариант, который я не вижу ?

(37) 1. Хрень полная
2. Да. Резерв (в твоём понимании) -
Это то сколько можно отгрузить по всем незакрытых счетам исходя из остатка на складе.
Всё.

Всё изменения сводятся к созданию жксплртнойиыункции с параметрами товар, склад, которая возвращает "сколько можем отгрузить"

(35) 1.ясно
2. Создавать по остатку новый счёт или работать по остаткам одного счета - проще и правильнее в рамках одного счета, создавать другой счёт на остаток - полная хрень.
.
Всего два регистра надо.
Счета и остатки.
Они покрывают задачу. И резервов нахер не надо. И не надо вычислять первая жто реализация или последующие. В е решается просто и прозрачно.
.
ТС влом голосом пообщаться?

(38) >"1. Хрень полная"

)))) Честно, прямота мне твоя нравится, но уже 2й раз прошу конкретики
__________
>"2. Да. Резерв (в твоём понимании) -
Это то сколько можно отгрузить по всем незакрытых счетам исходя из остатка на складе."

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

Пусть ТС хотя бы напишет
На какие вопросы должна давать ответ обсуждаемая "подсистема"

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

(39) "ТС влом голосом пообщаться?"

Нет конечно, Но считаю что это не совсем правильно ). Я темы создаю не тупо чтобы решить свою проблему, а больше подискутировать и какие-то знания получить. Дань форуму  в т.ч. нужно отдавать, тема создана, значит должна быть раскрыта и полностью закрыта и не только для меня )

(41) Задача: определять свободный остаток товар на складе. Он = "физический остаток минус количество данного товара в не списанных счетах".
Вот на скрине более понятно:
код товара     74238
на данный момент на остатке физически 2шт
и товар находится в двух не списанных счетах, в одном 1шт и во 2м 2шт.
И свободный остаток значит = -1шт

Работа с регистрами проста и прозрачна. И опасностей там минимум, не бол Ше чем в твоей схеме.

Твоя задача решается двумя регистрами Остатки и Ссета.
Какая тебе конкретика нужна?
Как проводить и аск считать показатели?
Сейчас напишу. Чая только после бани попью.

(43) После общения голосом вкратце итого подвожу:
моя изначальная наверное ошибка в том, что при создании на основании счёта  расходки я по регистру резерва сторнирую ВСЁ количество товара в СЧЁТЕ.
А правильней сторнировать по регистру резерва количество в расходке.

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

Покрутили, посмотрели.
Схема, которая у ТС - малость ракообразная (в части определения остатка по счету который надо отгрузить), но в принципе рабочая. Поспорили малость, пообсуждали. ОПРЕДЕЛИЛИ содержание сущностей (если здесь мы говорим что обязательство есть, то при его частичном исполнении надо обязательство закрывать частично, а не полностью), которых надо придерживаться при реализации схемы в коде, ну и вышли на проблемный "участок". Прокрутили = если сделать как дОлжно быть - все вроде складывается как надо. ТС ушел думать/крутить дальше. Должно получиться.

(40) "Хрень полная" и (в предыдущей ветке) "АдЪ и ИзраилЪ" -  это достаточно полное и исчерпывающее (хотя, на мой взгляд, излишне тактичное и мягкое) описание того, что у вас там наворочено...

Начиная от определений ("списание счета"), и заканчивая реализацией ("попытка-исключение").

На самом деле, все очень просто:
0. Отдельные регистры для "товаров на складе" и "товаров в резерве". у "товаров в резерве" допизмерение "клиент" и "счет"
1.Документом "счет" товар ставится в резерв. Для клиента. Возможно, даже резерв без склада (ибо товар клиенту пообещала контора "в целом", и пофиг, с какого склада).
Резервировать ли только "из наличия", или "из наличия и заказов поставщикам" - зависит от схемы работы. Я б делал "из наличия".
2. Свободный остаток - это "остаток в целом" минус "резерв в целом"
3. При отгрузке клиенту на основании счета резерв по клиенту уменьшается (в зависимости от методики (можно регулировать флажком) - либо на отгрузку, либо совсем - если клиенту больше отгрузок не будет), но не более того количества, которое было зарезервировано.
4. при необходимости - сделать служебный документ снятия "зависших" резервов.

(48) На самом деле, все очень просто

Да Вы счастливый человек. Лично я до сих пор не имею в голове идеального алгоритма по учёту резервирования товара. Туповат-с...

(49) есть анекдот про математика, инженера и голую женщину...
" я знаю, что уже очень скоро я буду достаточно близок для
любого практического применения!"©

Не знаю насчет идеальности описанного мной, но для практического применения он достаточен...

(50) Мне кажется, что склад (кладовщик) должен видеть онлайн резервирование/разрезервирование товара. Документа счёт он не видит.

(51) К сожалению не знаком с ТиС и поэтому возможно мои определения не совпадают с общепринятыми.
У нас счёт автоматически резервирует товар на складе

(51) "вы, наверное, математик..."©
Зачем кладовщику видеть хоть резервирование, хоть разрезервирование, хоть резервы (хоть онлайн, хоть оффлайн)?
Задача кладовщика - обработать документы, предназначенные (ваш К.О.) для обработки кладовщиком. Т.е. напечатать некий документ со статусом "к сборке" ("к отбору"), пройти ножками по складу, взять ручками товар "из бумажки", и отметить в электронном документе фактически собранное, и сам факт обработки документа, и сложить собранный товар (возможно, с напечатанным документом отгрузки) в место, предназначенное для обработки транспортной логистикой.

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

(53) и отметить в электронном документе фактически собранное

Именно! И на мой вкус - это и будет резервирование товара. Потому что мало ли какая позиция помята или перепутана. А счёт - это не резерв, а лишь заявка на таковой.
Но это мой идеал. Делайте как хотите, мне лень это всё обдумывать )
В любом случае то, что предлагает ТС - полная ахинея.

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

(56) "фактически собранное" никакого отношения к "резервированию" не имеет

Не согласен.

Ну для любителей пощупать резервы вживую можно делать так - товар собирается физически и перемещается на склад отгрузки. При этом сканируется, взвешивается, места/паллеты собираются, готовятся сопроводительные документы. Транспортная подъезжает и грузится за 10 минут

(48) Резерв у них сущность второстепенная, и на кого он повешен - пофиг. Система отгрузки - КОНКРУЕНТНАЯ, кто первый отгрузил свой счет - того и тапки, и пофиг на чужой резерв. Поэтому резерв исключительно для того чтобы видеть только свободный остаток (для этого достаточно просто знать сколько "резерва", а на кого он - неинтересно). А сколько надо отгрузить (сколько осталось по счету незакрытого товара) - считается валанданием счета и выборкой на основании ТЧ счета и сравнением с ТЧ реализаций (вместо нормального регистра остатков "Счета"). Костыль адский, но раз работает (95% счетов закрываются одной реализацией в ноль), то ТС и устраивает. Если счет в ноль отгрузкой не закрыт в ноль - манагер делает второй счет на незакрытый остаток. Этим и объясняется "бредовое" типа "если по счету хоть что-то отгрузили даже частично, то он считается закрытым" - потому что блин удобно в журнале видеть - если есть расходник к счету (отдельная колонка в журнале) - значит счет "закрыт", если пусто в колонке реализации - значит счет не закрыт. Ну вот так вот "здесь так заведено". "Резерв" - как отдельный ресурс в регистре "Остатки" (в принципе тоже норм, за исклчением того, что один регистр упрется в 1ГБ/2ГБ/количество запиcей гораздо быстрее чем два отдельных). Задача в т.ч. - не порушить нововведениями сложившуюся ситсему и адские костыли, сам помню такое - вросло в плоть и трогать страшно чтобы все не упало. А так - как выше писал для нормальной работы схемы которая у ТС - достаточно 2 регистра "Остатки" (классика) и "Счета" (учет взятых на себя обязательств по отгрузке и неотгруженных остатков по счету), ну и для ускорения расчета чтобы не два регистра дергать при расчете свободного остатка - можно и "резерв" в Остатки оставить - для быстрого расчета свободного остатка, а регистр "Счета" - чтобы убрать нафиг расчеты остатка по счету "сравнением" табличных частей счета и расходных накладных. Всё, как я выше и писал (ну там еще хвостом дальше отгрузка аналогов вместо исходных товаров есть, это посложнее но принципиально ничего не меняет)... Почему у ТС сделано так как сделано - да хз кто сейчас скажет, дело давнее, покрыто мраком темной стороны силы...
Дырку в своих расчетах ТС нашел, а дальше - дело хозяйское - тащить старую схему или хоть немного ее привести в божеский вид и пересмотреть малость подходы к привычке персонала, сделав в журнале счетов красивый фейс по взгляду на который чтобы сразу было видно состояние счета... Вот и все. По крайней мере в той части что обсуждал с автором.

(53) >"Зачем кладовщику видеть хоть резервирование, хоть разрезервирование, хоть резервы (хоть онлайн, хоть оффлайн)?"

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

п.с. Блин, очень интересная тема и хочется на всё всем ответить, но тяжёлый понедельник это осложняет

(60) "утром в понедельник самые хмурые люди выносят в мусорку самые звонкие пакеты"© ?

(60) документ "счет" ("заказ клиента") ДОЛЖЕН ставить товар в резерв. Т.е. если ты "принял счет" ("принял заказ", "пообещал клиенту"), то должен зарезервировать товар, чтоб выполнить этот заказ...

(55) "В любом случае то, что предлагает ТС - полная ахинея."
)) 4 раз читаю на этой странице, только не пойму зачем повторяться, если не писать конкретику. ?

(62) Ну так он у меня и ставит товар в резерв? Зачем цитировать моё (60) как будто меня не так?

(64) он неправильно ставит. И неправильно снимает.

(48)
> "0. Отдельные регистры для "товаров на складе" и "товаров в резерве". у "товаров в резерве" допизмерение "клиент" и "счет"
Уже выше была речь, что можно реализовать по отдельности а можно совещённый, у меня совмещённый
______
> "1.Документом "счет" товар ставится в резерв. Возможно, даже резерв без склада"
Да, я у же понял основное недопонимание. Как я понял по умолчанию под словом Резерв всеми понимается резервирование товара именно под клиента, с дальнейшей целью следить по данному клиенту за не исполненными перед ним обязательствами (его резервами). И поэтому да, в таком регистре даже Склад - не совсем к месту

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

> "2. Свободный остаток - это "остаток в целом" минус "резерв в целом")"
Всё верно, у меня также

> "3. При отгрузке клиенту на основании счета резерв по клиенту уменьшается (в зависимости от методики (можно регулировать флажком) - либо на отгрузку, либо совсем - если клиенту больше отгрузок не будет), но не более того количества, которое было зарезервировано."
Также и у нас. Реализовано только  У ВАС по другому: Вы считаете что единственно правильный вариант - это когда частичная расходка ОБЯзана частично уменьшать резерв пропорционально выданному товару.
А я говорю что такая реализация не единственно верная, хотя бы изза вашего 4го пункта ниже:

>"4. при необходимости - сделать служебный документ снятия "зависших" резервов."
Вот где саам суть. Что значит  " при необходимости "?? А зачем вообще резервированием заниматься, если по итогу их не контролировать??
Так вот в вашем варианте это и есть самый гемор - т.к. закрывать резервы придётся руками. А у меня они закрываются намного проще

(65) >"он неправильно ставит. И неправильно снимает."
А ктото считает что правильно.
И в чём смысл такой дискуссии? Может всё таки с 5й попытки можно написать в чём именно не правильно ?)

(62) у него не так. я написал в (59): система отгрузки КОНКУРЕНТНАЯ, независимо от того поставил товар в резерв или не поставил. даже если весь товар стоит в резерве (свободный остаток=0) и менеджер согласовал с клиентом счет - счет висит в системе и менеджер может отгрузить товар по этому счету если он раньше "встал". То есть - товарна складе есть - модем отгрузить! Кто не успел отгрузить - даже если расчитывал при выставлении счета что товара достаточно на складе - это проблемы того менеджера, кто не успед отгрузить. Кому товара не хватит - закупают у поставщиков.
Всё. Нет жесткого резервирования по конкретному клиенту.
Менеджер1 счет на 23 февраля, 50% текущего остатка на складе.
после менеджера1 второй менеджер со своим клиентом делает счет:
Менеджер2 счет на 19 января, 70% текущего остатка на складе (при терках с клиентом видит что свободного остатка на складе 50%, но это не ограничивает ЕСЛИ НАДО выставить счет и на больше).
остаток на складе=100%, резервов = 120%, свободный остаток=0%, к закупу = -20%
.
Отгрузка 19 января, полная по счету.
Остаток на складе стал = 30%, резервов=50%, к закупу = -20%
.
Если к концу февраля поставщики не поставят заказанное количество товара, по неотгруженным счетам - отгрузят столько сколько есть на момент отгрузки (кто первый того и тапки). на остальное - дадут отлуп.
.
а давать отлуп заказчику по Менеджеру2 при терках клиента - только потому что сейчас свободного товара нет, так как резерв аж под отгрузку через месяц - ну тоже как-то не комильфо. Отгружаем сейчас что есть, а под менеджер1 закупим...

Остаток на складе: 100%, резервов 120%, свободный остаток для других менеджеров при терках с клиентом = 0%, к закупу = 20% (100остаток-120резерв=-20). Закупили от поставщика 16 января 30% - остаток = 130%, резерв=120%, свободный остаток=10%).
.
достаточно простая и рабочая схема если налаженные каналы поставок и мало отлупов от поставщиков.
.
поянтноЮ что манагер2 и последующие будут стараться уложиться в свободный остаток

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

(66) "Так вот в вашем варианте это и есть самый гемор - т.к. закрывать резервы придётся руками. А у меня они закрываются намного проще"
- ага, при этом дополнительное создание дополнительных счетов - охерительный выигрыш. Обсуждали мы это с тобой голосом. Переставай нести бред, а то тутошние запишут тебя в неадекваты.
.
Тем более если ты делаешь доп счет и в результате НЕ ОТГРУЖАЕШЬ по нему (ну вот так случилось) - ты точно также будешь ЕГО ЗАКРЫВАТЬ РУКАМИ - исправляя количество в счете или помечая счет на удаление или иным способм но точно также закрывать руками.
.
тем более что не всегда ясно в момент когда выполнена частиная отгрузка по счету - в этот момент отгрузки не знаем еще 100% - отгрузим мы клиенту осттаток или нет. то есть счет незакрытый который ты создал второй - будет висеть до принятия решения и ты его либо отгрузишь либо точно так же ЗАКРОЕШЬ ручками.
.
поэтому совершенно пофиг будет осттаток висет на новом счете или будет висеть на исходном счете (отгрузка исходны счет не закрывает) - точно также - без дополнительного счета - ты либо догрузишь исходный счет второй-третье-пятой - пока счет в ноль не отгрузится - либо неотгруженную часть ЗАКРОЕШЬ РУКАМИ (исправим в исходном счете количество на меньшее - счет получится отгружен 100%) или сделав закрытие неотгруженного счета отдельным документом. Отдельным дококм правильнее - история взаимоотношений с клиентом и проблемы со счетом останутся. По таким документам закрытия непольностью отгруженных счетов можно влет собирать статистику по недроборам счетов - то есть ваши "провалы".
.
обсосоали же вчера голосом все.
Переставай тянуть свою кривую схему.
все тебе об этом говорят.

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

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

Мы в Вас не сомневались)

(70) >"Тем более если ты делаешь доп счет и в результате НЕ ОТГРУЖАЕШЬ по нему (ну вот так случилось) - ты точно также будешь ЕГО ЗАКРЫВАТЬ РУКАМИ - исправляя количество в счете или помечая счет на удаление или иным способм но точно также закрывать руками."

Нет, все счета автоматом распроводятся после окончания срока их действия

(70) >"поэтому совершенно пофиг будет осттаток висет на новом счете или будет висеть на исходном счете (отгрузка исходны счет не закрывает) - точно также - без дополнительного счета - ты либо догрузишь исходный счет второй-третье-пятой - пока счет в ноль не отгрузится - либо неотгруженную часть ЗАКРОЕШЬ РУКАМИ"

в том то и дело, что нет. Руками мы ничего не закрываем. Не закрытые резервы сами падают и это легко и понятно реализуемо - просто распроводится счёт.
И это легко контролируется

А вот во втором варианте релизации - когда расходка по счёту снимает резерв частично в пределах списанного - больше потенциальных проблем вылазит.
И одна и них - заводить такую новую сущность как "закрытие резерва" (например через новый документ ЗакрытиеРезерва)

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


п.с.
>"Переставай тянуть свою кривую схему."
а что меня бесит, это не то что в моей схеме может быть кривизна, это без проблем, а то что за 75 сообщений ещё никто не написал в чём она конкретно выражается :)

Т.е. если подытожить, то весь спор, а точнее ваше "как у тебя  - это трешь" )
сводится к простому, а именно:

и в вашем и в моём варианте ЕСТЬ РУЧНАЯ РАБОТА (при правильной реализации - это нажатие одной кнопки):

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

А вашем варианте ТАКЖЕ ЕСТЬ ручная работа - при частичной отгрузке товара определять, а частичная ли это отгрузка или нет. И если частичная отгрузка всё-таки полностью должна закрывать резерв в ноль то точно также придётся нажимать кнопку и его закрывать в ноль.
Либо придумывать ОДНОЗНАЧНО более сложную схему (чем простое распроведение счетов как у нас), которая будет сторнировать остаток долга по резерву через какойто период времени /чтобы они не висели бесконечно/

(68) "товар на складе есть - можем отгрузить" - ну и смысл тогда резервировать.
"проблемы того менеджера" - не, это создание проблем клиенту.  Если я заказал и оплатил, а мне дали отлуп - идет такой поставщик по одному из двух широкоизвестных адресов.
все временнЫе перестановки зависят от схемы резервирования (из наличия, из заказов) и надежности поставщиков, т.п.
(69) ага, новый счёт - как раз "сущность без необходимости", которых, как известно, плодить не следует..
(70) "Закрытие руками" - не обязательно человеческими руками. Вполне нормально закрывалось роботом, со всеми установлеными процедурами, включая финансовые звездюли менеджеру, державшему товар в резерве сверх установленного срока.
(71) насчет "жесткого резерва" - тут либо резерв есть, либо его нет. Если любой "чудак на букву М" (ну, в смысле, м[енеджер]) может продать зарезервированный товар - это не резерв.
Про фразу "да никогда такого не будет" - согласен. Для полноты нужно только добавить знаменитую фразу ЧВС "Никогда такого не было, и вот опять..."©

(76)"на основании исходного счёта создать новый счёт"... забываешь золотое правило...не плодить "сущности" без необходимости..

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

также как и 2+2 не всегда равно 4.
А почемуто большинство из Вас считает что все кто утверждает что 2+2 не всегда равно 4 - есть тупые.
:)

(77) " товар на складе есть - можем отгрузить" - ну и смысл тогда резервировать."

Ответ: дать менеджеру в ручном режиме принять сложное решение. Все прекрасно понимают, что идеального решения в вопросе резервирования не существует.
И глупо считать что раз так то и резервы не нужны.
Они нужны, но решение списать в минус или нет - принимает манагер.

(74) (75) документ не должен "автоматически распроводиться".
Проведенный документ фиксирует факт хозяйственной жизни: Менеджер Вася Пупкин пообещал клиенту Ване Писькину отгрузить  три хреновины, но по пять, и пять звиздюлин - но по три. Всё!
Если менеджера Петю Попкина спросят, почему он отказал клиенту Жене Жопкину - он откроет счет, где будет видно, что и хреновины, и звездюлины были зарезервированы Пупкиным для Писькина. А если робот снял резерв за истечением срока резервирования - Пупкину должно прилететь от его руководятла Гади Петровича Хреново финансовое взыскание за то, что товар провисел в резерве в то время, когда он пользовался необычайным спросом.

(79) если вы такой умный - коего хрена спрашиваетие советы как чесать левое яйцо левой ногой?

(78) Новый счёт это не сущность. сущность - это само понятие счёта, а новый счёт - т.е. остаток долга - существующая реальность, которая описывается новым документом.
Да, можно было реализовать и по другому, но "глобального косяка" я не вижу . Новый счёт - это всегда какието изменения изначального договора /не получилось отгрузить 100% как хотели/ - поэтому и создаём Доп соглашение

(81) >"Проведенный документ фиксирует факт хозяйственной жизни: Менеджер Вася Пупкин пообещал клиенту Ване Писькину отгрузить  три хреновины, но по пять, и пять звиздюлин - но по три. Всё!"

Вено, Также как и не проведённый
Не проведённые документы точно также легко обрабатываются/

Да можно было придумать более сложный и красивый вариант, но чтобы утверждать - распроведённые счета это 100% голимо - сомнетильно

(84) непроведенный - ничего не говорит. вообще. он "не имеет последствий"

(53) (81) +1 ....Геннадий да математик...хочет перегрузить головушку  кладовщика, совершенно ему не нужной информацией.

(86) я знаю, он МГУшник... но я просто цитировал анекдот...

(77) >"(70) "Закрытие руками" - не обязательно человеческими руками. Вполне нормально закрывалось роботом, со всеми установлеными процедурами, включая финансовые звездюли менеджеру, державшему товар в резерве сверх установленного срока."

Точно нет.
В резерве 100 штук, отгрузили 99 штук. Никакой робот не будет знать, последняя штука - это   долг или не долг (т.е. покупатель от него отказался). Так вот если это не долг, то нам ничего делать не нужно, а в вашем случае счёт нужно закрывать - ручная работа.
И наоборот если долг - то таже ручная работа уже у нас - создать новый счёт.
Полный паритет. Говорить что второй вариант - полное Г - очень странно

(82) Потомучто я не такой умный и многого не знаю. Но коечто точно знаю, в т.ч. что и 2+2 не всегда 4. А когда мне говорят что это не так и ты дурак - приходится отвечать ))

(88) будет знать. Потому, что отказ клиента тоже должен фиксироваться...

(89) 2+2 всегда четыре. Другое дело, что у вас "свои  понимания" о числах два и четыре, и , естественно, об операциях суммирования и знаке равенства.

(85) Это не значит что их нельзя обработать чтобы получить необходимую инфу

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

(91) >"2+2 всегда четыре."
))
Нет не всегда. И именно через ВАШИ понимания и ЧИСЕЛ и знаков суммирования - не всегда 2+2=4.

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

(55) "А счёт - это не резерв, а лишь заявка на таковой"...Счет с точки зрения ГК это оферта покупателю, которую нельзя отозвать, если не оговорено в самом счете. Так-что "классический" счет, это уже железно резерв.

(88) в документе "реализация" можно предусмотреть флаг "Закрыть заказ". Менеджер наверно уж знает, отказался клиент от части заказа или не отказался. в зависимости от флага делать движения разные

(94) Вот мне прям интересно щас стало. Это в каких таких случаях 2+2 не равно 4? В рамках стандартной алгебры? И куда конкретно надо смотреть, чтобы было шире?

(85) +1...все правильно, в классической "парадигме" от 1с, не проведенный счет можно рассматривать максимум, как некий черновик. Для показателей деятельности предприятия он ничего не значит. Другое дело , что ТС начинает наделять состояния/сущности неким смыслом ведомым только ему. Само по себе это не критично, просто это не по "классике"

(96) Верно, один из вариантов реализации. Только в НЕ МОЕЙ схеме для такой реализации и нужно вводить новые сущности (либо отдельный документ либо отдельный резерв).
А у меня все выданные счета автоматом закрыты в ноль. Всё просто и удобно. Называть это полным Г - пока ни одного нормального аргумента выше  я не увидел

(97) нужно расширять сознание. препаратами. как говорил Акопян - "Нужно дунуть. Если не дунуть - ничего не получится"©

(97) "Вот мне прям интересно щас стало. Это в каких таких случаях 2+2 не равно 4? В рамках стандартной алгебры? И куда конкретно надо смотреть, чтобы было шире?"

Первому кто ответит на этот мною придуманный вопрос от меня мороженое через курьера на дом.
До 15-00 пусть жду варианты ответа ))

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

(101) только не надо говорить, что мы имеем дело с кольцом вычетов по модулю 4 (например)
тогда 2 + 2 = 0

(102) нет. всё проще. Тот кто найдёт ответ сразу поймёт что он нашёл правильный ответ.
заведу лучше отдельную тему на него )

v7: Всегда ли 2+2 равно 4?

п.с.
тема удалена, значит вопрос остаётся здесь )

в типовой ТИС вполне работающий механизм резервирования. И вряд ли стоит упражняться в извращениях, непонятно ради чего. Я лично лишь делал более удобные документы СозданиеРезерва и СнятиеРезерва. Остальное более-менее логично и здраво

(99) внимательно читать (94): "Этим примером я говорю о том что люди часто закостенелы в своих знаниях и не могу смотреть шире"

(105) Я прочитал, верно. Всё зависит от конкретной предметной области. Не всем и всегда хочется летать конкордом из Лондона в Нью-Йорк.
Точно также и применительно ко многим учётным системам изначальный распроведённый счёт, который несёт в себе всю инфу по не состоявшемуся заказу - вполне себе нормальная реализация. Искать его со скорость меньше чем 0,3сек не всегда нужно

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

(106) если нормальное проектирование системы (и БП, и УС) позволяет получать данные быстро и понятно без дополнительных накладных расходов - нет смысла делать это долго и непонятно.

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

(101) в троичной системе счисления 2 + 2 = 10

(0) Автор слегка тупит.
И в (0) ибо простая проверка на неухождение Резерв <0 решает проблему нескольких документов по одному счету

И для 2+2=4
Ибо общий ответ "Не всегда"

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

(104) В 2001 /впрочем как и сейчас/ я ничего не знал о типовой поэтому и придумал то что имею. Пока всё-таки конкретных предметных изъянов я не увидел в этой ветке. Может быть и плохо смотрю,  не спорю

(112)я же не настаиваю. Нравится - используйте

(110) Молодец, только система четверичная ).
Пиши в телегу @evgpinsk адрес, пломбир придёт )

(114) 0, 1 и 2 - откуда четверичная то?