Многоуважаемый All, помогите выбрать принцип организации сохранения данных. Документы, такие как Клиенты, Поставщики, Накладные будет иметь кнопки “Сохранить”, “Отмена”. Клиент пишется на Delphi, база MS SQL Server. В общем, остановились на двух вариантах, но интересует ваше мнение относительно только накладных:

1) Вся инфа сразу пишется в базу, т.е. при создании, редактировании, удалении продукции из накладной все это сразу попадает в базу, где срабатываю триггеры, и сразу обновляются таблицы складских остатков. Затем, если тыкается кнопка “Сохранить”, то ничо не делается - типа все сохранено :) и закрывается окно, “Отмена” – длается дикий откат, ведь все надо восстановить в первоначальное состояние.

Преимущества: остатки правятся автоматом триггерами
Недостатки: по сути, вообще некорректный подход, т.е. документ появляется в базе, но кнопка Save еще не нажата; если зависает прога, то документ так и остается, хотя он не был сохранен; Если корректно восстанавливать остатки после “Отмена”, то всю служебную инфу остатков тоже надо куда-то засасывать, а не только ProdID, Qty.

2) Вся инфа по редакированию данных накладной кешируется на клиенте и только когда пользователь тыкает “Сохранить” данные пишутся на сервер, НО тут возникает такая проблема, как заблокировать количество продукции для накладной, ведь данные сразу не пишутся в базу. Возникла такая идея, записывать инфу о продукции из не сохраненных накладных во временную таблицу, так чтоб видели все сессии, а остатки всегда должны рассчитываться с учетом данных в этой временной таблице.

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

Интересны Ваши мысли по этому поводу, и если есть опыт поделитель, пожалуйста, кто как такое делает.

Alex.

Если кому интересно, как будем делать:

Основополагающий принципы:
- Кеширование самой накладной на сервере
- Короткая транзакция записи
- Резерв продукции в специалной таблице резервов
- Расчет отстатков продукции с учетов таблицы резервов

1) Резерв

При указании кол-ва продукции в накладной, запускается sp
с параметрами SessionID, GUID, PoductID, Qty, где
SessionID - сессия
GUID - уникальный номер, ведь в рамках сессии может быть несколько одноврмеменно набираемых докуметов
PoductID - код продукции
Qty - кол-во

При это, если есть достаточное кол-во продукции, то заносится необходимая инфа в таблицу резерва

2) Сохранение данных

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

3) Отмена изменений

Очищается резерв

4) Подсчет остатков, чистка зависших сессий.

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

Alex.

Alex UstasЕсли кому интересно, как будем делать:

Основополагающий принципы:
- Кеширование самой накладной на сервере
- Короткая транзакция записи
- Резерв продукции в специалной таблице резервов
- Расчет отстатков продукции с учетов таблицы резервов

Alex.

апшипка, читать так:

Основополагающий принципы:
- Кеширование самой накладной на клиенте
- Короткая транзакция записи
- Резерв продукции в специалной таблице резервов
- Расчет отстатков продукции с учетов таблицы резервов

UrryMcAГосподин Черный плащ абсолютно прав - Alex Ustas ИМХО ошибочно объединил два процесса: процесс резервирования товара и процесс фактической отгрузки.

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

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

В некоторых случаях целесообразно формировать движение по регистру "Заказы покупателей" сразу же по окончанию ввода строки в документ "Заказ покупателя". Это позволит действовать по принципу "Кто успел, тот и съел" при большом количестве sales-managers.

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

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

А по поводу резервирования Заказом, тут просто такая штука, прога на западный рынок, и у них есть такое понятие как backorders - т.е. недопоставленная продукция, т.е. на основание invoice в который не полностью покрывает sales order можно сгенерировать backorder - т.е. что необходимо допоставить, и усе, нормальная практика.

UrryMcA>А по поводу резервирования Заказом
Понятно. Схема в данном случае может быть и с накладной. Зависит исключительно от бизнес-процесса. Ничего в этом случае сказать не могу - т.к. не знаю Ваш бизнес процесс.

>>не, никакой ошибки нет, резервирование идет только под накладную и в
>>процессе создания накладной, для пользователя абсолютно прозрачно и он
>>об этом не подозревает. Это необходимо чтоб не использовать длинные
>>транзакции, т.е. если использовать штатные средатва, то нормальной
>>рабочей проги не получиться, это что-то вроде попытки обмануть природу ;)

Можно подробнее? Какие "штатные средства" и откуда возникли "длинные" транзакции?

Ну, имеется ввиду, что задача не может быть решена в лоб, т.е. надо или логически разбивать процесс, на как тут предлагили резервирование, или как Вы предлагали Заказ, или в рамках устоявшегося процесса придумывать какие-то подпорки. Мы пошли по пути подпорок, так понятней и проще конечному пользователю. Т.е. мы хотим, чтоб накладная до сохранения могла под себя подгребать продукцию и другие пользователи уже немогли ее использовать в своих накладных, но тем не менее, пользователь всегда должен иметь возможность нажать Cancel - и все должно откатиться в первоначальное состояние. Транзакции используется короткая, тока на момент записи, когда нажимается кнопка Save.

UrryMcA>>Т.е. мы хотим, чтоб накладная до сохранения могла под себя подгребать продукцию и другие пользователи уже немогли ее использовать в своих накладных, но тем не менее, пользователь всегда должен иметь возможность нажать Cancel - и все должно откатиться в первоначальное состояние. Транзакции используется короткая, тока на момент записи, когда нажимается кнопка Save.

Вполне нормальное решение, а не "подпорки" ИМХО.

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

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

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

VladiChВас спасет ручная оптимистическая / пессимистическая блокировка. Оптимистическая - это что-то похожее на Ваш вариант 1, т.е. в базе может храниться несколько версий данных, при сохранении проверяется, редактировались ли сохраняемые данные за время, пока у вас открыта форма кем-либо. Если да, возникает конфликт (правила разрешения конфликта на вашей совести, т.е. можно последнюю введенную запись оставить или первую, или по времени начала редактирования отсекать). Оптимистическая предполагает, что таких конфликтов будет мало.
Пессимистическая наоборот предполагает, что их будет много, т.е. при редактировании накладной она должна на логическом уровне блокироваться, чтобы никто другой не смог ее редактировать. Т.е. если вы начали редактировать накладную это будет означать, что товары, которые в ней присутствуют, заблокированы, и никто не может изменить их количество или другие параметры на время редактирования.
Я бы предпочел вариант с оптимистической блокировкой, хотя он и немного сложнее в реализации, т.к. насколько я понимаю вероятность возникновения конфликтов невысокая.

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

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

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


Дык в том то и дело, в базу информацию об изменяемой накладной и измененных остатках мы не пишем до Save, при этом другие пользователи должны видеть статки
In Stock Product Qty - This Invoice Product Qty. Т.е. вариант, что по Save проверяется а можем ли мы со склада снять такое колво продукции, и если не можем выдать сообщение - не приемлем.

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>>Так что с постоновкой все нормально.

Вам виднее.

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

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

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

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