На сколько я знаю многие WMS на базе 1С уходят от регистров накопления в сторону регистров сведений. И в принципе это логично поскольку например хранить резервы в регистре остатков особого смысла нет. История по движениям с резервами как правило никому не нужна. Есть срез на текущий момент и всё. Минусы которые я вижу это необходимость траты ресурсов на группировку записей, лишаемся таблицы итогов что явно не ускорит поиск записей, хотя учитывая что есть индексы и общее количество записей будет не велико может расходы и минимальны. Но наибольшие непонятки как это ударит производительности при записи наборов при увеличении количества пользователей?

(85) намного интереснее задача оптимальной раскладки по ячейкам в соответствии с правилами и фрагментацией

(85) Как обычно, все нюансы не раскрыты:
- в заказ входят разные детали?
- у деталей как там с комплектацией/разупаковкой?
- есть ли требования к самим заказам

Это только с первого взгляда

(82) да не вопрос - подправляйте! только в какой ячейке лежит этот возвращенный товар? вы ведь правите состояние остатков, ане сделанные ране с этим товаром вээмэсные операции.

(87) т.е. от момента поступления заказа из 100 строк через 100 мс готовы задания на сборку 100 товарных позиций ?

(90) в заказе 100 разных товарных позиций, без всяких аналогов и комплектов

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

Только у меня 47 филиалов в урибе на еле дышущей 77(срочно переводимой мной же на 8.2) с около 50 000 документов в день. в таких условия х сложно диктовать свой порядок. Сам ген дир подумал и встал на их сторону

(92) формирование листа сборки - вещь элементарная

(93) Производительность в этом случае ограничена регламентом обмена KIS и WMS

2 цикла, как я вижу

(92) а что, если вместо 100мс, задания на отбор будут спланированы через 500 мс - это сильно подломит физического сборщика комплектовщимка..? ;-)

(95) даже элементарные вещи требуют временных затрат - мне интересны оценки тех, кто уже сталкивался с подобным

(95) если просто товар отобрать - то совсем просто. если отобрать так, чтобы упаковщик все составные части шкапчика бпосле сборщика быстренько упаковал кучно - немножко сложнее... по всякому бывает..

(98) т.е. у тебя задание на сборку 100 товарных позиций создается за 0.5 сек ?

100 -- это мало. Причем нет всяких комплектов, это будет быстро. Если все, что хотел товарищ, он нам рассказал

(99) засечь за сколько у меня формируется листы отбора на 1000 позиций? - но уменя "тупо" сделано.

(101) сейчас вот специально засеку...

(102) мало это сколько? - 5 лет назад на курсах в УЦ1 100 товарных позиций было 500 сек, сейчас сколько ?

(91)>>только в какой ячейке лежит этот возвращенный товар?

вот уж чего нам еще не хваиало так это адресного размещения товара:))..

У нас товар лежит сам по себе на складе. За МОЛ. А он как то там размещает.

воруют конечно.Но мы боремся:)

(102) я читал про американскую wms манхетен, так для нее суточный предел 40 тыс товарных позиций

(106) отсутствие адресного хранения - зависимость от кладовщика и низкая скорость сборки

(105) на 7.7 самописная WMS как надстройка у ТиС выдавала моментально сборку практически любую. размещение да, могло несколько секунд считаться, но сборка - сразу.

(107) Максиальный предел не скажу -- я не разработчик.
Но 100 обрабатывае тся очень быстро. Быстрее только статус меняется

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

(109) один момент имеет разный размер - у русских один, у эстонцев другой.
вот Чебуратор ушел мерять и до сих пор не вернулся :)

533 позиции - 3-4 секунды

(112) у меня заявок активных больших сейчас нет!

(112) ну хз, до полусекунды 1000 наименований...

на складе 50к ячеек, вот сколько обход циклом их занимал, ну + небольшой оверхед - столько формирование сборки и занимало

(116)+ это максимум, если все, что нужно лежит в первых 10к, то дальше, естественно, не шло

...у меня еще паралельно с заданием пеформы формируются

(116) много ячеек!

(113) т.е. 150 строк в сек получается

лично у меня 4 левых соединения к остаткам по производительности быстрее в несколько раз одного левого соединения к срезу последних

какого на! заморачиваться супермегабыстротой формирования заданйи на отбор? - там что роботы подбегают и хватают?

особо упоротые пишут резерв в реквизит товара
производительность на высоте

(120) можно сказать и так (параллельно с формированием печформ). при этом я еще считаю сколько коробок-блоков-штук про каждой позиции ббрать, вес и объем...

(123) тоже вариант! ;-)

с другой стороны - я вот не заморачивался быстройдействием там где оно некритично. будет критично - будем оптимизировать. если делать заточенное решение - тогда и трудозатраты другие и подходы и вообще наверное все другое.. ;-)

проблемы все равно в другом - в несоблюдении регламентов.

как не хотелось делать количественный учет по ячейкам - но придется... так мне это не нравится, шо капец...

(94) да все просто.
ты, видимо, считаешь, что списываться с ячеек должно при проведении документа, а это не так.

У меня (упрощенно, много этапов я убрал) происходит так:
1. Менеджер выписывает накладную
2. Логист видит все выписанные накладные и в зависимости от графика отправляет на сбор определенные документы
3. Операторский отдел с помощью обработки выдает товар на сбор (в этот момент товар с ячеек списывается и помещается в некий кэш).
4. После того как товар собран, делают расходные ордера (в этот момент товар списывается с остатков и обработкой удаляеется из кэша. В этот момент возможен частичный возврат товара обратно в ячейки)

Все товар уехал. Обращаю внимания, никакой прямой связи между документом и списание с ячеек нет! Если документ перепровести (изменив количество, отменив проведение и т.д.), то с ячейками вообще ничего не произойдет.

Вполне нормальня ситуации, когда количество товара хранящегося в ячейках и числящегося на остатках - не совпадает.

Если накладную исправили и решили таким образом не оформлять возврат товара (просто уменьшив реализацию), то при фактическом получении товара назад - делают операцию "размещения товара в ячейки" и все.

это сильно упрощенно.

(119) много SKU - много и ячеек. в одной ячейке один SKU, один SKU может лежать в нескольких ячейках...

(130) ячейка отбора  - одна?

(129) Как бы, в идеале, это -- две разные системы

(131) а? в сборке один SKU может браться из нескольких ячеек. или что имеется ввиду?

(129) у меня еще проще... за счет этого и плюсы и минусы...

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

(135) есть отчет, называется сравнение остатков.
Он складывает товар в ячейках и кэше и вычитает числящиеся остатки.

(133) "ячейка отбора" - доступная для сборщиков. из нее подбирается товар при сборке. "ячейки хранения" - складской запас 9оттуда тоже берется если коробочная сборка крупная).

(135) это очень просто.
Если товар в кэше, то значит что он СОБИРАЕТСЯ.
А раз он собирается, то проводить по нему инвентаризацию не совсем корректно, но можно.

(136) это понятно. как определяешь физически то место где лежит закешированный товар - где конкретно ты будешь его считать?

(137) а... не, "складской запас" отдельно, ячеек отбора много

(132) в нашем случае это было бы не идеальным вариантом, а большим гемором. Я внимательно изучал этот вопрос.

(138) "СОБИРАТЬСЯ" заявка может достаточно долго... а считать надо сейчас..

(110) я посмотрел сейчас демо-базу совместного решения - создаются по 4 строки в секунду.
откуда берется "очень быстро" ?

(140) то есть ячеек отборана один товар - много?

(139) Еще раз, если товар лежит в кэше, значит его сейчас собирает кладовщик.
т.е. товар может быть в ячейке (при записи в кэш указывается ячейка) или его уже мог забрать кладовщик и отнести в зону сборки.
Соответственно, для правильно инвентаризации необходимо поймать кладовщика, остановить его работу и посчитать. Чтобы не вышло, что ты посчитал товар в ячейке и после в зоне сборке т.к. он успел его уже туда перенести. Но это не проблема учетной системы

(143) плоха система (с точки зрения быстродействия) значит.

(141) Это уже не проблема какой-то конкретной типовой, а необходимость создания собественно WMS. Всех карт у меня нет

Будь мужиком, блеать!

эх.. посмотрел статистику за дубабрь - 479 строк не хватило до 50'000 строк сборки. 92 строки/мин средняя скорость сборки.

(147) сферический конь в вакууме он идеален, но никому не нужен )

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

Т.е. из неполной информации невозможно собрать полный ответ.

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

самое печальное - что вся эта автоматизация - всего лишь для одного - чтобы заблокировать хреновую работу персонала.
.

(152) это ты про что?

(155) +1 я тоже не понял.

(155) я про (141)
Там явно не хватает инфы

(154) ты про адресное хранение?
если да, то я с тобой не согласен )

.. как только у персонала не заблокирована возможность сделать "не так" - все, капец... сделают "не так"...

(158) не только про адресное хранение.

(157) э... какой инфы?
почему в моем случае 2 разные системы было бы большим геморром?

(157) я НА ДАННЫЙ МОМЕНТ стою категорически против НЕСКОЛЬКИХ систем. если два участка могут работать в рамках одно йбазы - хочу чтобы сейчас это было именно так. Умрут у меня на обменах. и прочих косяках попутных.

(159) это следствие не правильных подходов.
Копьютер - это сложное устройство и использовать его должен квалифицированный персонал.

Движение по пути ограничений - это путь в никуда.
Необходимо двигаться по пути повышения квалификации персонала.
Сделал не так? будь добр - ответь. Ответственно очень мотивирует. А если можно свалить на программу, то тут тупик.

вот есть у меня в системе слабина - кол.учет по ячейкам не ведется. Все, капец. Изредка, но регулярно товар девается неизвестно куда. Как запилить без внедрения количественного учета по ячейкам - пока что представляю слабо.

А давайте прекратим спор, а то он напоминает детский:
"-Кто сильнее, Рембо или Шварцнеггер!
- Конечно Шварцнеггер!
- А если Рембо поможет Джет Ли!"

(161) 2 системы решают две разные задачи. Интегрированная система всегда эффективнее "сцепки" двух. Но всегда ли есть ресурсы на такую интеграцию? Может, для компании лучше иметь две разные системы и расширеную возможность обмена?

А вообще, я про то, что "Серебрянной пули" нет. И быть не может в этом вопросе. Каждое решение имеет сильные и слабые стороны. Наша задача в том, чтобы усилить сильные моменты и нивелировать слабые. Ведь так?

> Сделал не так? будь добр - ответь
- чтобы понять, кто должен ОТВЕТИТЬ - требуются эти самые ограничения.

(149) я тоже за декабрь посмотрел - непосредственно комплектация 447 772 строки, перебежки со скоростю 2.5 строки в минуту

(164) а в чем проблема?
Есть такое понятие, как материальная ответственность. Поверь, количественный учет по ячейкам (если ты про историю движения) ни разу тебя не спасет т.к. реально никакой дополнительной информации тебе не даст.
Ну вот был приход, вася туда положил 4 единицы, а теперь там 3. И что? Вася виноват? Или петя, который стырил?

(162) Складу складово, бухам бухово. В чем косность такого решения?
Задачи WMS и бухгалтерии не пересекаются. В чем-то даже противоречивы. Надо их разводить

(162) скажем так, твое утверждение истинно, но в ограниченном количестве случаев.

Если между подразделениям слабая связь, обязанности четко разграничены и есть возможность рассматривать подразделение как обособленное, то лучше отдельно.

если не делать количественный учет по ячейкам, то всего один путь (навскидку) к улучшению ситуации - маркировка уникальными штрихкодами каждой упаковки. Мастер-коробки - это уже есть, а вот блоки/минипаки - этого нет...
.
хотя, если запилить входящую поставку на маркировку всех упаковок уникальными штрихкодами - то можно и без количественного учета по ячейкам. Но это решение будет (явно?) дороже чем сделать количественный учет по ячейкам..

(169) эээ! не путайте бухов и отдел продаж. Бухию - стопудово с вээмэс мешатьне стоит. а вот продажников - очень даже возможно.

(171) еще раз, какую задачу ты хочешь решить с помощью количественного учета?

(170) > Если между подразделениям слабая связь,
- угу!!! именно как-то так...

(173) может голосом на скайп?

(173) может пнешь меня в нужном направлении...

(175) ministr30 сейчас зайду

на досуге ломаю башку - не получается без кол.учета. а делать его ну не прет меня реально.

ок. сейчас

такс... попробую запилить/ужесточить немного без количественного учета.. есть шанс...

всем спасибо за беседу

(181) и тебе спасибо.
Если честно, я про способ ведения ячеистого склада без количественного учета вообще не думал :)
По своему интересная идея и имеет свои плюсы.

(108) отсутствие адресного хранения в приципе возможно когда товар крупный, ассортимент мал и жестко закреплен за зонами, но на складах где около 1000 SKU и площадь более 5000 квадратов это равносильно остановке склада. Смешно и грустно было смотреть на поисковые бригады комплектовщиков которые за 4 часа не могли найти товар.

(123) резерв же по конкретной ячейке делается. В реквизит можно когда адресного хранения нет, но тогда и WMS не нужен.

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

(163) ну если все работает слаженно только за счет высокой квалификации персонала то это плохо. Сложнее/дольше натаскать замену, сложнее запускать новые объекты. Люди не дураки и понимают что если их сложно заменить то можно и повыпендриваться.

(164) не обольщайся, с адресным хранением он тоже магическим образом неплохо исчезает. Самое смешное когда не из зоны хранения а собраный товар с доков исчезает. И главное без камер не поймешь "кто". Если проблема только в этом то может оно и правда вам не нужно.

(171) единственный наверно более менее решающий эти проблемы вариант это на сколько я понимаю rfid метки. Датчики на все выходы и в проходах с камерами. Но говорят сложно и дорого. Зато все видно :)