VladiChПо-моему тут или в постановке задачи что-то не так, или я ее смысл не понял.
То есть остатки должны пересчитываться до нажатия кнопки Save, сразу после добавления позиции в накладную? С какой целью это делается?

Смотрите:
накладная пишется в базу не сразу, так как она может быть сохронена - Save, или отменена - Cancel. Для этого просто делается кеширование на стороне клиента. тут проблем нема. Проблема в другом, что када создается накладная, и какое-то кол-во продукции уже указано, то оно сразу должно быть недоступно другим юзерам, хотя инвойс еще не сохранен. Для чего так делать? А чтоб другие юзеры не захапали, типа кто первый встал, того и тапки. Иначе, ситуация, когда накладная создана, наживается кнопка Save и тут прога поехала выдавать мессаги - продукции уже нет на складе и так далее. Это плехо.

gardenmanвот все и рассавили по своим местам - и блокировочники и версионники :))

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

VladiChёма-ё...
опять заговариваюсь.

По-моему в любом случае нужно чтобы добавляемые в накладную товары не влияли на остаток, пока не нажата кнопка "Save". Редактирование накладной - это фактически аналог транзакции, просто реализуемой не средствами СУБД, а вашим приложением СУБД. В вашем же варианте получается что транзакция незавершена, а ее результатами уже пользуются. Если у вас ситуация с конфликтами в результате такой "транзакции" возникает слишком часто, значит надо блокировать вручную используемые ресурсы - то есть если вы добавляете товар в свою накладную, то в другую накладную этот товар добавить уже нельзя, пока вы не завершите свою "транзакцию". Или же использовать разные версии данных о товаре, о чем я выше и писал.
Если ситуация когда "прога поедет выдавать мессаги" у вас будет встречаться исчезающе редко, используйте вариант без блокировки. Если чаще - используйте блокировки или версионность. Вы оценивали вероятность возникновения такого рода конфликта?

понедельник тока наверное, нераскачигарилися :)

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

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

UrryMcA2 Alex Ustas

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

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

best regards!!

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

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

Серега Alex Ustasоценить сложно, но ситуаци вполне реальна. т.е. вероятность что кто-то другой захочет отгрузить эту же продукцию большая. Блокировать низзя, так как я могу взять 5 единиц, а на складе 10, и вся продукция будет заблокирована, и накладная теоритически может делаться сколь угодно долго и этот процесс не должен мешать другим.
Что мешает "продвинутому" узеру создать накладную (не сохраняя ее!!!) и захапать под себя весь товар (ну типа жадный он, будет один торговать или ему обещали позвонить после обеда и купить много и он страхуется). И все идут лесом. В конце дня он отменяет накладную (ну не позвонили ему) и весь товар валяется непроданным, при том что весь день все орали, что торговать нечем.
ИМХО, ты просто меняешь знак у проблемы не решая ее. Если не хватает товара на складе - то это проблема бизнеса, а не программы и прога должна просто информировать об этом кого нужно, причем заранее (наверное есть какие то нормативы остатков/резервов). Если это происходит через раз, то такой склад закрывать надо, а снабженцев увольнять. ИМХО опять же.

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

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

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

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

Серега gardenmanВ том то и дело, что в системе будет видно кто захапал весь товар.
Ну и что? 90% времени уйдет на то, чтобы выяснить кто, зачем, на сколько времени чего занял и переругаться по этому поводу.
Плюс к этому. Если "творчески работать" с накладной, т.е. например набирать разного товару на определенную сумму, то запаришься резервировать/разрезервировать с пересчетом.
И все только потому, что "а вдруг не хватит".
Я бы выяснил поподробнее, насколько часто реально возникает у заказчика ситуация "не хватило". Ну не верю я, что это "постоянно". Все таки в 99.9% случаев, приходя в магазин и видя товар на прилавке, можно его (товар) купить и не нарваться на "извините, кончилось".

ну, творческая работа в основном будет с Sales Order, на основание SO формируется Invoice. А что вы имеете ввиду запаришься с резервировать/разрезервировать с пересчетом? нихто парится не будет, как я уже говорил, все для пользователя прозрачно, все что ему нужно, это указать в накладной Qty Shipped и усе, прога сама поставит на логическй резерв. Если накладная будет таки записана, склад обновится, а резерв будет очищен, если отменена - просто очиститься резерв.

Серега Alex Ustas То что чувак может указать 4 единиц товара из 10 имеющихся, но накладная еще не сохранена, при этом остальные юзеры видят уже тока 6 - вот конечный резюльтат нашего механизма.

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

Ну, ситуация из разряда вредительской, но вполне может быть. Как правило, путь до накладной такой:
Quotation - Sales Order - Invoice. Т.е. это по существу конвеер, и хапнуть и не отпускать до конца дня - это уже что-то вроде из разряда вон выходящего. Просто такой механизм предотвратит ситуацию када в накладную Qty Shipped уже указано, а оно оказалось не окончательным, и тот кто попроворнее может перехватить, тогда придется опять корректировать Qty Shipped. Т.е. именно вот такую ситуацию хочется избежать. Т.е. еще раз, указанное в накладной Qty Shipped окончательное, и не корректируется под воздействие внешних факторов.

UrryMcA>>Так что с постоновкой все нормально.

Вам виднее.

>>Или укажите на реальные возможные косяки.

Заказывайте анализ - покажу если есть.

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

Тем не менее, всем спасибо, было интересно и позновательно.