Списание товара со склада

← →
Diks © (2005-01-25 12:38) [0]

Списивается товар со склада 10 продавцами (большая вероятность одновременного списания товара). Как правильно реализовать код списания чтоб не влететь в минус при одновременном списании товара, т.е. списать больше товара чем есть?

← →
Соловьев © (2005-01-25 12:41) [1]

Один списал - подтвердил транзакцию. второй при списании перечитал - и получил реальные, и опять списал и подтвердил транзакцию... 10-й перечитал, поматерился и не продал ничего.

← →
msguns © (2005-01-25 12:57) [2]

Если учет по товару, то отриц. остатки могут быть допустимы (пересортица), а если по поставкам, то нет.
А вообще в [1] все верно сказано.
Вообще надо работать с документом так:
1. Откатить документ перед началом коррекции
2. Откорректить и подтвердить транзакцию изменения документа, но не текущих остатков.
3. Провести документ, т.е. скорректировать в БД текущие остатки.

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

При такой системе отриц.остатков в принципе возникнуть не может.

← →
HSolo © (2005-01-25 13:08) [3]

http://ibase.ru/devinfo/pslock.htm

← →
Diks © (2005-01-25 13:08) [4]

Меня беспокоит следующее если оба продавца в одно и то же время посмотрели остаток(он есть) и дали запрос на его списание, как тут быть? Списание идёт без резервирования сразу со склада.

← →
Плохиш © (2005-01-25 13:17) [5]

>Diks © (25.01.05 13:08) [4]

Первый списал, следующий поматерился. см. [1]

← →
msguns © (2005-01-25 13:24) [6]

>HSolo © (25.01.05 13:08) [3]
>http://ibase.ru/devinfo/pslock.htm

Применимо, если два узера хотят редактить один и тот же документ. В нашем случае ситуевина несколько другая. ИМХО, не туда копнули.

>Diks © (25.01.05 13:08) [4]
>Меня беспокоит следующее если оба продавца в одно и то же время посмотрели остаток(он есть) и дали запрос на его списание, как тут быть? Списание идёт без резервирования сразу со склада.

Внимательно прочитали [2] ? Если нет, то еще раз, особенно то место, где говорится о разных статусах документа: непроведенный и проведенный.
Одновременно ничего не происходит: ни в БД, ни тем более в компе. Все запросы обрабатываются сервером строго последовательно. Вообще, ИМХО, Вам надо разобраться с транзакциями. Налицо непонимание механизма их действия.

← →
HSolo © (2005-01-25 14:28) [7]

>msguns © (25.01.05 13:24) [6]
>Применимо, если два узера хотят редактить один и тот же документ. В нашем случае ситуевина несколько другая.

Чем же она другая? Вопрос о том, как не дать списать товара больше, чем есть на складе. Приведенные в статье "побудительные причины для блокирования" № 1-2 именно это и описывают, о документах там ни слова. Почему Вы считаете, что в нашем случае сие неприменимо?

← →
msguns © (2005-01-25 16:18) [8]

>HSolo © (25.01.05 14:28) [7]
>Чем же она другая? Вопрос о том, как не дать списать товара больше, чем есть на складе. Приведенные в статье "побудительные причины для блокирования" № 1-2 именно это и описывают, о документах там ни слова. Почему Вы считаете, что в нашем случае сие неприменимо?

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

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

Именно для такой системы справедливо то, что написано в статье по приведенной Вами ссылке.

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

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

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

> msguns © (25.01.05 16:18) [8]
Большое спасибо за развернутый ответ :) Как обычно: я отвечаю на поставленный вопрос, Вы смОтрите шире :)

Хотите для Вашей коллекции еще одну схему? Это вариант приведенной Вами 2-й; так сделано, например, в бух.программе "Дебет+" (made in Киев, знаете такую?). Учет там партионный. Но когда юзер вводит в накладную кол-во товара, то ему сразу предлагается список партий этого товара, с остатком по каждой партии, и предлагается указать, сколько конкретно с какой партии списать. Иным способом кол-во товара в накладную ввести нельзя. Т.е. тут тоже присутствует "битва за остаток", только уже на уровне партии товара. Со всем отсюда вытекающим :) Другой вопрос – насколько это удобно юзеру. Бухгалтеров вроде устраивает, но если предложить такое оператору, который отпускает товары клиентам... боюсь, он не слишком обрадуется :)

>HSolo © (25.01.05 17:02) [9]

То, что Вы написали про Дебет+ (такую программу я, конечно, знаю) есть всего навсего реализация интерфейса на клиенте (не буду ни ругать, ни хвалить, скажу лишь, что видывали куда получше). Схемы это не касается ;))
Для избежания мороки со списком остатков на разных приходах существует FIFO либо варианты на выбор:
- LIFO (снимается самый "свежий"),
- выгребание остатков (в перую очередь снимается с того кода, по которому минимальный остаток),
- достаточный остаток (снимается с того прихода, где текущего остатка достаточно для расхода),
- ручной.

В FIFO/LIFO и достаточном алгоритмах просмотр списка приходов в порядке хронологии поступления или срока хранения (радиобатоны на форме выбора в документ)

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

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

>msguns © (25.01.05 17:26) [10]

>видывали куда получше
Бесспорно. Я тоже.

>варианты на выбор
Да. Знакомо :) Мне еще попадался вариант "наибольшая/наименьшая цена поставщика".

>msguns © (25.01.05 17:33) [11]

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

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

Списание товара со склада Найти похожие ветки