Связанные таблицы

← →
Dik © (2004-11-12 01:03) [0]

Есть две базы склад и расход товара со склада В расход добавляется запись с количеством товара со склада оно естественно списывается. Как избежать одновременной продажи одного и того же товара К примеру два продавца послали запрос на склад и получили ответ что есть чегото например 2 банки и оба их продали по 2. Как лучше решить эту проблему

← →
Petr V. Abramov © (2004-11-12 01:58) [1]

Сначала списывать, потом добавлять запись в "расход", потом commit. До commit`а запись в "складе" будет блокирована.

← →
HSolo © (2004-11-12 08:38) [2]

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

← →
Sergey13 © (2004-11-12 09:44) [3]

Достаточно указать на складе ограничение на количество>=0.

← →
msguns © (2004-11-12 10:37) [4]

>Sergey13 © (12.11.04 09:44) [3]
>Достаточно указать на складе ограничение на количество>=0.

Очень опасное ограничение при учете по товару (а не по поставкам, где оно естественно). У чела, похоже, учет по товару.

← →
Dik © (2004-11-12 10:38) [5]

> Сначала списывать, потом добавлять запись в "расход", потом commit. До commit`а запись в "складе" будет блокирована

А как узнать удачный ли результат списания со склада или нет

← →
Sergey13 © (2004-11-12 10:47) [6]

2[4] msguns © (12.11.04 10:37)
Расшифруй плиз. Интересно. Я не большой знаток складской бухгалтерии.

← →
Соловьев © (2004-11-12 10:50) [7]

> А как узнать удачный ли результат списания со склада или
> нет

мысли о Commit не к чему не приводят?

← →
msguns © (2004-11-12 10:58) [8]

Если учет по поставкам, то "хендлом" позиции товара является идентификатор строки фактуры приходной (от поставщика на склад) накладной. Все дальнейшее движение этой позиции сопровождается именно этим "хэндлом". Т.е. если у меня на склад по 4 накладным 4 раза поступали от одного и того же поставщика одни и те же горшки, то каждый их них "сопровождается" по всем всем своим перемещениям автономно. Если при выписке, например, накладной на отгрузку, требуется 100 горшков, а у меня имеется 30 с первого прихода, 50-со второго и 20 с третьего, то в фактуру отгрузки включется 3 (три) строки.
Текущие остатки ведутся по каждой строке каждой приходной накладной
Удобен тем, что нет проблем с с/взвешенной ценой, позволяет вести партионный учет и контроль по срокам хранения/реализации.
Но есть и неудобства: сложность откатов приходов (приходится писать "веерные" алгоритмы), большее кол-во вычислений и, как следствие, проигрыш в скорости (хотя это смотря как и на чем реализовать), некоторые неудобства при создании отчетов (объединение нескольких "хэндлов" с подобными характеристиками (обычно через справочник наименований и общих характеристик товара) в одну строку.

← →
msguns © (2004-11-12 11:01) [9]

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

← →
Sergey13 © (2004-11-12 11:04) [10]

2[8] msguns © (12.11.04 10:58)
Спасибо, но это я худо-бедно представляю. Я просил расшифровать "Очень опасное ограничение при учете по товару". В чем опасность то?

← →
msguns © (2004-11-12 11:47) [11]

Извини, недопонял. Видать, еще не проснулся ;))

Опасность в том, что при учете "по товару" имеет место быть такая вещь как пересортица. В переводе на "рабоче-крестьянский" это означет то, что товара нет на карточке в БД, но он имеется фактически на складе. Объяснять почему это происходит, думаю, не надо,- ты мальчик взрослый и сам все знаешь ;))

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

← →
Sergey13 © (2004-11-12 11:55) [12]

2[11] msguns © (12.11.04 11:47)
А зачем тогда вообще учитывать? Лежит на складе - давай. 8-)
ИМХО, такой путь ведет к неразберихе и хаосу. Все таки склад - это место хранения мат ценностей. А отрицательное их количество - это нонсенс.

>Sergey13 © (12.11.04 11:55) [12]
>>[11] msguns © (12.11.04 11:47)
>А зачем тогда вообще учитывать? Лежит на складе - давай. 8-)
ИМХО, такой путь ведет к неразберихе и хаосу. Все таки склад - это место хранения мат ценностей. А отрицательное их количество - это нонсенс.

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

Если можно небольшой примерчик с Commit, ну чайник я в IB

Ну не знаю, не знаю. ИМХО ты все таки смешиваешь склад и торговлю. Это связано, но не одно и то-же. Девочке, которая оформляет заказ, пофигу чем там на складе воняет. Нет в компьютере - не будет и в заказе.
Да и вопрос в топике, имхо, был попроще. 8-)

>Sergey13 © (12.11.04 12:15) [15]

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

>Dik © (12.11.04 12:14) [14]
>Если можно небольшой примерчик с Commit, ну чайник я в IB

Какими компонентами пользуешься ? Если IBX, то в хэлпе по TIBTransactin много чего полезного. Если неясно, то иди куда послал HSolo © (12.11.04 08:38) [2]

Использую IBDatabase, IBQuery, IBTransaction

Связанные таблицы Найти похожие ветки