Многоуважаемый 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 проверяется а можем ли мы со склада снять такое колво продукции, и если не можем выдать сообщение - не приемлем.