Архив форума

Добрый день друзья! Пишу в BPwin процедуру приемки товара на складе адресного хранения  с помощью терминалов сбора данных. Если у кого-нибудь есть такой опыт или завалялся алгоритм такого вида приемки огромнейшая просьба откликнуться!
Заранее благодарен за любую информацию.
 
----------------------
См. также:  
ТСД http://logist.ru/forum/YaBB.cgi?num=1202314412
Штрихкодирование. Плюсы и минусы http://logist.ru/forum/YaBB.cgi?num=1096857828

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

Константин.
Для начала нужно определиться по дговору:
- Если это договорответхранения и Вы пользуетесь скл. свидетельстами, тогда достаточно описания опломбированных мест по объму.
- Если у Вас договор на складскую обработку, т.е Вы являетеся грузоотправителем, тогда без справочников не обойтись.

на производительность wms может влиять только активная номенклатура в остатках, а общий список товаров ограничивается размером таблиц СУБД (для MS SQL2005 - 32 ТБ).
хотя дым от серверов всегда может пойти, особенно в жаркое лето и без кондиционеров

Или я чего-то не понимаю или ........
Я всегда думал что с этим должна справиться любая WMS.
1) Есть справочник товаров
2) Есть справочник компаний разделенных по признаку - владелец, поклажедатель, грузоперевозчик, грузополучатель, посредники т.п.
3) Приходуем товар, отгружаем опираясь на эти признаки
4) + грамотные отчеты
5) + грамотная архивация данных где-нибудь раз в три месяца чтобы база не росла (имеется ввиду обрезание ненужных данных и упаковка их в архив)  
 
Волки сыты, овцы целы

Процитировано сообщение: Петров Константин от 26.07.2007 :: 13:13:20:

В слабых системах чистят. Серьезные продукты позволяют хранить справочники в 1 000 000 позиций без снижения быстродействия.
Гораздо большей проблемой является то, что у одного клиента вес, у другого - цвет, у третьего серийные номера и т.д и т. п., Особенно, если  
атрибуты надо как-либо обрабатывать, например, при приемке. Надо поддерживать целый арсенал параллельного функционала, разные диалоги или формы и пр. пр.
Короче - страшно не количество, а многообразие.

Процитировано сообщение: Соломатин Владимир от 27.07.2007 :: 16:07:09:

Разделяю это мнение.
Процитировано сообщение: Соломатин Владимир от 27.07.2007 :: 16:07:09:

И даже это, но не совсем. Если база написана без таблиц шириной в черное море, а как завещал дедушка Кодд, то это совсем не обязательно делать так часто.
У большинства реальных систем, к сожалению, с этим не все в порядке...

Все выспросил теперь расскажу свою историю
 
был склад свой. теперь хотят его перенести на отдельное ООО, кот. будет на упрощенке, за счет чего планируется немного сэкономить на налогах.
Т.е. как бы 3PL, только СВОЙ и только для себя и пары аффилированых структур.
 
Были горе-консалтеры, представившие за немалое количество денег какой то бред вместо расчета и бизнес плана. А воплощать мне.
 
Сейчас в головной компании пользуется БЭСТ. Вопрос стоит поднимать ли его в будующем "складе ", повторяя все справочники?  
 
Консалтинги наговорили много операций делать и продавать их как доп услуги, НО одно дело продать ПОСТОРОННЕМУ клиенту переработку товара, а другое дело ГОЛОВНОЙ фирме, где все равно себестоимость общая в любом случае. Т.е. хоть в ОДНОЙ компании происходит переработка, хоть в выделенном собственном ООО.  
 
Так вот мыслишка есть, а ЗАЧЕм вообще их там учитывать, все эти перерабтки/подъемы погрузчиком/ручные разгрузки, если их учет будет требовать ДОПОЛНИТЕЛЬНЫХ затрат как физических, так и материальных?
 
Будет как бы приниматься груз, пусть по весу (ибо объем неадекватен), и по весу выставляться счета?  
А еще проще по стоимости товара привязаться  наценивать за переработку фиксированный процент. Но очень уж сомнительно будет смотреться имхо.  

Процитировано сообщение: Петров Константин от 30.07.2007 :: 14:07:47:

Нет! Не подымайте БЭСТ на складе. И когда поставите на складе WMS не связывайте ее с Бестом.
Практика использования этой чудесной программы позавчерашнего дня в связке с другими системами у меня негативная.
Особенно инвентаризация, корректировки запаса, приемка с отклонениями в количестве.
Вы получите то, что сейчас обсуждается в:
Процитировано сообщение: Сазанович Марина от 20.07.2007 :: 14:05:08:

Процитировано сообщение: Петров Константин от 30.07.2007 :: 14:07:47:

Нормально будет смотреться, если все свои издержки плюс планируемую прибыль будете раскидывать на весь товар. Ничуть не хуже чем биллинг.
И там и там цены среднепотолочные. Чем одна cхема хуже другой? В этой хоть Вам ненапряжно, и она почти бесплатно считается.

Процитировано сообщение: Петров Константин от 26.07.2007 :: 10:42:38:

 
Товар ненадо заводить для каждого контрагента отдельно.
Есть смысл добавить в табл. товрара поле контрагент-поставщик.  
И при отгрузке что бы он его тянул. (спрашывал.)

Уважаемые коллеги. Поделитесь, пожалуйста, своим опытом.  
У нас есть склад 4500 м2
Установили стеллажи, ввели адресную систему.
В учете используем 1С 8.1.  
В среднем в день к отгрузке готовится 7000-10000 документострок.
Возник вопрос, куда двигаться дальше. В частности, каким образом передавать заявки  на отгрузку на склад в какой форме ее должен получить наборщик. В электронном -  т.е. закачать в ТСД и там производить контроль правильности набора или заявка будет на бумаге, а кладовщик с терминалом будет все перепроверять?  
А может существуют еще какие либо варианты?
Оговорюсь о сторонней WMS речи не идет. Имеется группа талантливых программистов, которые могут почти все.

Процитировано сообщение: Павлов Валерий от 15.09.2009 :: 18:25:38:

 
Согласен, но обычно цепочка Эксперт->ТЗ->Программисты без постоянной обратной связи пораждает продукт, которым в конечном счете пользоваться не удобно, а може даже вредно. Реально нужно брать хорошего специалиста в штат, который кроме написания ТЗ постоянно консультировал на этапе создания первого макета, направлять его в нужно русло и присутствовать при запуске проекта. Лучше, если этот специалист будет еще в курсе основ проектирования баз данных или/и "талантливые программисты" поработали на складе с месяц. Ну а правильней - купить готовый продукт с возможностью доработки - это будет и быстрее и дешевле (в конечном счете).

Василий, а бесталанных программистов на экскурсию пустите ?

ок - готовлю договорную жидкость

Процитировано сообщение: Шебуков Василий от 07.10.2009 :: 09:22:15:

 
Я бы тоже прогулялся, жидкость имеется