|
|
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Alex UstasИнтересны Ваши мысли по этому поводу, и если есть опыт поделитель, пожалуйста, кто как такое делает. У нас (самописная система) при внесении позиции в накладную товар снимается с остатков и резервируется в специальную таблицу на сервере вида spid\login\tovar\amount\sklad. При сохранении накладной таблица очищается. При построении отчётов - содержимое таблицы добавляется в остатки. В клиенте есть два отчёта: "Текущий остаток на складе" и "Товарный отчёт" Пример: всего товара 100 единиц. В накладную внесли 50. Накладная ещё не сохранена: Текущий остаток на складе - 50 единиц в наличии, 50 в резерве. Товарный отчёт - 100 единиц. Накладная сохранена: Текущий остаток на складе - 50 единиц в наличии. Товарный отчёт - 50 единиц. Опыт эксплуатации показывает, что такое решение не всегда адекватно. Например, одни заказы будут отгружаться сегодня, а другие - завтра. Заказы оформляются несколькими операторами независимо друг от друга. Если так получилось, что один оператор оформил (сохранил) накладные на завтра, для сегодняшних накладных может не остаться товара на остатке (в системе не поддерживаются отрицательные остатки). ___________________________________________________ ИМХО Оптимальным было бы иметь в окне формирования накладной галку "Резервировать товар". Поставил галку - и вбиваешь товар с резервированием. Потом клиент говорит "Знаете, мне сегоня не надо - через недельку привезите.". Не вопрос - убрал галку, освободил товар. А заказ остался. Тут клиент вдруг передумал, звонит снова: "давайте всё таки на сегодня оформим". Снова ставим галку - а нам болт. Не хватает товара. :) В данном случае клиент сам виноват. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2005, 17:51 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Вот и я о том же. Зачем весь этот гемор? Чуть чуть поменяли логику - и все в порядке. Вводите правило - количество зарезервированного товара не может превышать наличия на складе. А количество товара которое доступно - разница между складом и резервом. Все то же самое, но никаких проблем с остатками. Можно даже фичу приделать - хранить резерв до определенного момента времени. Типа покупательне пришел за товаром вовремя-пеняй на себя... :)) Именно такой подход я и реализовал в там куда давал ссылку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2005, 11:15 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
gardenmanВот и я о том же. Зачем весь этот гемор? Чуть чуть поменяли логику - и все в порядке. Вводите правило - количество зарезервированного товара не может превышать наличия на складе. А количество товара которое доступно - разница между складом и резервом. Все то же самое, но никаких проблем с остатками. Можно даже фичу приделать - хранить резерв до определенного момента времени. Типа покупательне пришел за товаром вовремя-пеняй на себя... :)) Именно такой подход я и реализовал в там куда давал ссылку. Если я понял правильно, вопрос был не об алгоритма резервировании (у меня документ имеет несколько состояний - счет на оплату-накладная-счет/фактура, счет на оплату резервирует, время резервирования дается в настройках, но можно детализировать и по контрагенту и по товару исходя из рейтингов), а о том как это сделать удобно для оператора и непротиворечиво. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2005, 11:26 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
2 Сахават Юсифов Я вот хочу спросить есть такое понятие как "Заказ"? Если товар в наличии на складе - то он должен быть зарезервирован. Если нет в наличии - значит нужно предпринять соответствующие действия чтобы он появился. Заказ должен быть оплачен до такого-то времени. Рассмотрим работу аптеки. Звоните, говорите - хочу аспирину 10 пачек, и пачку свечей от геморроя. Вам говорят приходите до 19-00 - если не придете, заказ будет анулирован. И, в любом случае если вы придете в оговоренное время, то вам гаранитируют что ваш аспирин в количестве 10 пачек и прочие позиции заказа вы получите. И никаких накладных, никаких изменений остатков... Ведь покупатель может и не прийти вообще... А инфа о том, что был "заказ" сохранится. Потом можно будет проанализировать спрос... Честно говоря я не вижу тут место для кнопки "зарезервировать". Вижу только "сохранить"/"отменить". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2005, 12:12 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
gardenman Честно говоря я не вижу тут место для кнопки "зарезервировать". Вижу только "сохранить"/"отменить". Да поймите же Вы, не о том речь "как зарезервировать", а о том "как непротиворечиво зарезервировать один и тот же товар одновременно несколькими продавцами". Т.е. эти драные блокировки, транзакции, изоляции и т.д. хреновина, которая для этого предназначена, но помочь ничем не может, кроме как "извините туалет занят, приходите попозже" или "та, на ком вы хотели женится, уже не девочка - обскакали". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 00:21 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Я тоже думаю, что это только организационными мерами решается, а какими именно (кто прав - забирающие, забравший, при каких условиях) - надо на пользователя выносить (в настройки), так как в разных организациях по разному. Совокупная потребность в каждый момент неизвестна, кто что какой дурак предпримет - неизвестно, достоверное состояние склада неизвестно (так как в этот момент идут неизветсные транзакции). Это - проблема неизвестности, с ней вообще ничего нельзя сделать. Статистический резервный (на резервирование) можно ввести (если слово "я резервирую" клиента - закон), но также смешно, плюс оборотка дополнительная. Надо просто "резервировать онлайн", то есть пусть клиент знает, что сортир занят, пусть всех об идущих транзакциях сервер извещает и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 01:00 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Да поймите же Вы, не о том речь "как зарезервировать", а о том "как непротиворечиво зарезервировать один и тот же товар одновременно несколькими продавцами". Т.е. эти драные блокировки, транзакции, изоляции и т.д. хреновина, которая для этого предназначена, но помочь ничем не может, кроме как "извините туалет занят, приходите попозже" или "та, на ком вы хотели женится, уже не девочка - обскакали". Никак не могу понять логики. А есть смысл "непротиворечиво зарезервировать один и тот же товар одновременно несколькими продавцами" как вы этот один и тот же товар разным покупателям продавать то будете. Уважаемый gardenman все правильно описал. Именно так все и делают, и не натыкаются ни на какие противоречия. В стране работают тысячи складов, маганизонов, аптек и т.д. И нигде не возникает особых колизий. Зачем в очередной раз велосипед изобретать? Мир удивить? Мы и так с успехом это долгое время делаем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 10:04 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
2 ЧП Спасибо за поддержку. Тезис: если вы не понимаете что и как нужно делать, то совсем не значит что не найдется кто-то кто может и понимает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 10:20 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
И еще в догонку. Преждем чем что то продавать. Товар нужно правильно (присвоить ему уникальный номер к примеру) оприходовать на склад. Тогда не будет ситуации когда несколько человек резервируют и продают одно и тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 10:25 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Черный плащ. Никак не могу понять логики. А есть смысл "непротиворечиво зарезервировать один и тот же товар одновременно несколькими продавцами" как вы этот один и тот же товар разным покупателям продавать то будете. Вы думали зачем во всяких там SAPах и т.д. цепочка чуть ли не десяти документов для отпуска товара? Намерения, заявки, потвержденные, утвержденные,проведенные,учтеныее....??? Врод бы к чему все это дермо, когда можно написать "5 штук зарезервировано"? Для развода во времени и в пространстве = организационные меры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 10:26 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Тогда я не понимаю о чем спор. Все говорят об одном и том же (резервировании) но разными словами. У одного это сделано с разделением по времени через много документов, другой прямо формирует резерв. А существование одного и того же товара нарушает всю целостность базы данных в области работы с объектами учета. Не должно быть слов один и тот же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 11:21 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Черный плащ. Не должно быть слов один и тот же. Тогда все было бы просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 12:18 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Черный плащ.Тогда я не понимаю о чем спор. Все говорят об одном и том же (резервировании) но разными словами. ИМХО потому это, что часто пытаются совместить "Заказ", "Резервирование" и "Отгрузку" в одном флаконе (как правило на складе по моим наблюдениям). А с учетом специфики это могут быть совершенно разные вещи. Заказ можно принять и на месяц вперед и на два. Что, резервировать товар надо? А может и товара то сейчас нет. Посылать клиента? Резервировать, ИМХО, можно, когда есть уверенность, что заказчик придет за товаром (например оплата прошла) ну или срок заказа подходит и получили какое то подтверждение. "Отгружать" только по факту собственно отгрузки на складе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2005, 13:54 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Серега Заказ можно принять и на месяц вперед и на два. Что, резервировать товар надо? А может и товара то сейчас нет. Посылать клиента? Резервировать, ИМХО, можно, когда есть уверенность, что заказчик придет за товаром (например оплата прошла) ну или срок заказа подходит и получили какое то подтверждение. "Отгружать" только по факту собственно отгрузки на складе. Первые здравые рассуждения в топике. А то ишь, создают "коробочный вариант" под чей-то конкретный бизнес-процесс ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2005, 17:27 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Dogen Серега Заказ можно принять и на месяц вперед и на два. Что, резервировать товар надо? А может и товара то сейчас нет. Посылать клиента? Резервировать, ИМХО, можно, когда есть уверенность, что заказчик придет за товаром (например оплата прошла) ну или срок заказа подходит и получили какое то подтверждение. "Отгружать" только по факту собственно отгрузки на складе. Первые здравые рассуждения в топике. А то ишь, создают "коробочный вариант" под чей-то конкретный бизнес-процесс ;) Ну, вы б еще и через год пришли и стали давать свои ЦУ, чего только "ишь" стоит :) для тех кто в танке еще раз скажу, резерв в накладной - это чиста логическая операция, выполняется в процессе формирования накладной и служит для того, чтоб не увели остатки когда уже что-то забито в поле Qty Shipped. И не в коем случае не пересекается с полноценным резервом продукции, в моем понимании, точнее предлагали отталкиваться имеено от резерва, но для нашего коробочного варианта это не подходит, слишком тяжеловесно для постоянного использования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 02:11 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Alex UstasНу, вы б еще и через год пришли и стали давать свои ЦУ, чего только "ишь" стоит :) для тех кто в танке еще раз скажу, резерв в накладной - это чиста логическая операция, выполняется в процессе формирования накладной и служит для того, чтоб не увели остатки когда уже что-то забито в поле Qty Shipped. И не в коем случае не пересекается с полноценным резервом продукции, в моем понимании, точнее предлагали отталкиваться имеено от резерва, но для нашего коробочного варианта это не подходит, слишком тяжеловесно для постоянного использования. Ну год-то пока еще не прошел, топику вроде две недели? Если давать возможность "чиста логически" зарезервировать товары до сохранения заказа, то ушлый менеджер будет пробегаться по всему списку дефицитных и не очень товаров, забивать себе огромные количества товара, а потом спокойно и долго беседовать с клиентом, выясняя, что ему конкретно нужно. Как-то это не сильно лучше чем резервировать товары в момент сохранения заказа. Не хотите откатывать транзакции "чиста логического" резервирования - ну пишите эти данные (строки заказов) в отдельную таблицу, она будет невелика, можно постоянно прибавлять данные из нее к "полноценному резерву". У Вас, судя по всему, есть таблица с остатками и количествами зарезервированного товара, вот к ее данным прибавьте сумму строк редактируемых новых заказов. Надо отметить, что может иметь смысл создание нового заказа и редактирование "полноценно зарезервированного" рассмотреть отдельно. Где-то вверху спрашивали, кто как делает. Отвечаю. Для оптовой торговли сделали резервирование при сохранении заказа. Народ привык. Дефицит, если таковой присутствует на складе, все равно распределяется "вне информационной системы". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 13:17 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
DogenЕсли давать возможность "чиста логически" зарезервировать товары до сохранения заказа, то ушлый менеджер будет пробегаться по всему списку дефицитных и не очень товаров, забивать себе огромные количества товара, а потом спокойно и долго беседовать с клиентом, выясняя, что ему конкретно нужно. Как-то это не сильно лучше чем резервировать товары в момент сохранения заказа. След то остается - резервирует/освобождает и не продает. У руководства вопрос - нам такие умники нужны? Сохранить же значит сохранить свой труд - набрал 30 позиций, и тут клиент говорит, ой пожди, я через полчасика позвоню, кажется это мне вчерашнюю заявку подсунули, ОК, сохраняю, а клиенту говорю -учти, через полчасика этого может уже не быть - я не резервирую. Вместе с функцией копирования сохранение без резервирования легко реализуют типичные наборы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 14:13 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
ModelRСлед то остается - резервирует/освобождает и не продает. У руководства вопрос - нам такие умники нужны? Зависит от эффективности работы "умника". "След", опять же, писать в какой-то журнал нужно, просматривать... ModelRСохранить же значит сохранить свой труд - набрал 30 позиций, и тут клиент говорит, ой пожди, я через полчасика позвоню, кажется это мне вчерашнюю заявку подсунули, ОК, сохраняю, а клиенту говорю -учти, через полчасика этого может уже не быть - я не резервирую. Вместе с функцией копирования сохранение без резервирования легко реализуют типичные наборы. А почему бы не зарезервировать? А потом еще дописать? Ближе к жизни нужно быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 14:17 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
Dogen Ну год-то пока еще не прошел, топику вроде две недели? Если давать возможность "чиста логически" зарезервировать товары до сохранения заказа, то ушлый менеджер будет пробегаться по всему списку дефицитных и не очень товаров, забивать себе огромные количества товара, а потом спокойно и долго беседовать с клиентом, выясняя, что ему конкретно нужно. Как-то это не сильно лучше чем резервировать товары в момент сохранения заказа. Не хотите откатывать транзакции "чиста логического" резервирования - ну пишите эти данные (строки заказов) в отдельную таблицу, она будет невелика, можно постоянно прибавлять данные из нее к "полноценному резерву". У Вас, судя по всему, есть таблица с остатками и количествами зарезервированного товара, вот к ее данным прибавьте сумму строк редактируемых новых заказов. Надо отметить, что может иметь смысл создание нового заказа и редактирование "полноценно зарезервированного" рассмотреть отдельно. Где-то вверху спрашивали, кто как делает. Отвечаю. Для оптовой торговли сделали резервирование при сохранении заказа. Народ привык. Дефицит, если таковой присутствует на складе, все равно распределяется "вне информационной системы". та я пошутил, смайлик ведь добавил, "ишь" как-то резануло глаз :) небольшое отступление, слово "резерв" я употребил в мысле резервирования под накладную в процессе ее ввода, с целью недопущения увода остатков, по окончанию ввода оной. уф, загнул :) не, заказ не резервирует под себя продукцию, только накладная, вообще схема такая: Quotation - Sales Order - Invoice. т.е. когда Invoice формируется по Sales Order, то манагер пляшет от цифер указанных в Sales Order, т.е. в поле Qty Shipped инвойса у него нет возможности перепрыгнуть Qty Ordered. Т.е. хапнуть больше чем сможет проглотить у него нет возможности. Ну, в общем, про отдельную таблицу речь и была, т.е. в процессе ввода Qty Shipped в накладной - это кол-во не снимается с остатков сразу, а попадает в отдельную таблицу, эта таблица учитывается при расчете остатков. Ну и по Save - записывается сама накладная, обновляются остатки, очищается таблица, и все это в короткой транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 14:28 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
DogenА почему бы не зарезервировать? А потом еще дописать? Ближе к жизни нужно быть.Я же сказал - вопрос к заказчику, можно так можно, это его жизнь. Только не забудьте вопрос задать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 09:10 |
|
||
|
Какой принцип сохранения данных выбрать
|
|||
|---|---|---|---|
|
#18+
ModelR DogenА почему бы не зарезервировать? А потом еще дописать? Ближе к жизни нужно быть.Я же сказал - вопрос к заказчику, можно так можно, это его жизнь. Только не забудьте вопрос задать. Ну типа если коробочный вариант делать то не одного-единственного заказчика опросить надо :) А как минимум реализовать пару-тройку ходовых алгоритмов, или потом придется нагло пиарить свой любимый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 17:45 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33399210&tid=1545532]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
149ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 439ms |

| 0 / 0 |
