190-Чучундер > Все молчат, говоришь?
Ну-ну...

Когда будешь серийно продавать свою мега-разработку - не забудь перечислять ройалти мне ежемесячно.
За (192).

201-DeiMos > вот как раз и не придумвается пока как красиво и ненапряжно для юзера сделать
Все какаяио банальщина в бошку лезет

202-Чучундер > Как у тебя занятость ячеек определяется? Максимальный доступный для размещения вес/объем считаешь?

203-Reaper > у ячейки есть ограничение по весу. например для 7 яруса это до 500 кг. От 6 до 4 - до 650 кг. для 3 и 2 - это до тонны

то есть если например надо разместить паллету 600 кг, и нет свободных ячеек на 6 и ниже ярусах (а на 7 есть) - то при попытке взять паллету - ТСД ругнется "нет доступных ячеек", если взяли паллету весом допустим 300 кг - то система попытается ее закинуть на 7 ярус, если там нет свободных ячеек - то на 6, если нет - то на 5 (порядок определяется по рейтингу ячеек)

То есть система построена так, что в первую очередь забиваются верхние ярусы, оставляя нижние для тяжелого товара. Это настраивается типоразмером ячейки (по весу), в рамках одного типоразмера распределение идет по рейтингам ячеек (чтонастраивается). например: если пришла паллета 600 кг, то по типоразмеру ячеек она может попасть на 4,5,6 ярус. В первую очередь забивается 4 ярус, потом 5, потом 6. Определяется это конечно же не номером яруса, а рейтингом ячейки. так как в общем случае нумерация ячеек может быть произвольной.

204-Чучундер > Маловато. Без учета объема универсального решения не придумаешь. Придется на негабарит лепить костыль

Кстати, насчет (205) - должно быть так как написано. а вот как получилось на самом деле - я сейчас задумался. Надо проверить ;-)

207-Reaper > В данном случае у меня проще - все ходит на паллетах (евро или фин). И ячейка считается занятой, даже если на ней стоит паллета с двумя коробками.

207-Reaper > И, кстати, по объему - в WMS хреново получается. даже для коробов (а не для негабарита). Чтобы посчитать сколько коробов по объему влазит в ячейку надо для каждого товара (однотипные короба) считать ОПТИМАЛЬНУЮ УКЛАДКУ на паллету. Считать наполнение по объему по типу снежного кома делением объема ячейки на объем короба - не получается.

Поэтому, например, для товара для каждого типоразмера ячейки просто указывается вместимость ячейки в штуках, в блоках/минипаках, в коробах. Тогда получается все отлично.
Вместимость в коробах для типоразмеров ячеек считает оператор через packer3d - новинки у нас идут постоянно, но не так чтобы сотнями каждый день, поэтому просчитывает просто ручками через вебинтерфейс на портале пакера. если нужно автоматизировать это дело - то это тоже возможно.

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

|_1_ _3_ _5_|_7_ _9_ _11_|_13_ _15_ _17_|

"Связность ячеек" должна показывать что ячейки 1 и 3, 3 и 5 - являются "соседними". а вот 5 и 7 - нифига не соседние ячейки - между ними физическая стойка...

вот и думаю как эту связность красиво описать, чтобы ненапряжно и понятно было. У Акселота это сделано через контейнеры, но как-то это мне не нравится, но вот боюсь что придется делать что-то похожее...

203-Reaper > ...надо еще учитывать и высоту ячеек, у меня это не критично, т.к. высота паллет отсеяна еще на этапе согласования матрицы товаров.

конечно, по уму, надо прикрутить и вместмость по высоте - так как у меня есть ~90 ячеек над пожарными проходами во 2 ярусе с заниженной высотой, ~1м - туда надо в первую очередь пихать товар с небольшой высотой паллеты (у клиента как раз есть такого немного). Но это некритично, так как свободных ячеек типовой высоты на данный момент с запасом, поэтому нетиповые ячейки просто тупо заблокированы и все.

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

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

За две недели успешно прокрутили ~1100 паллет
Прикрутил авторасчет отбора, пока напрямую из ячеек в зону отгрузки
Штабелерщик снимает паллету и клеит лейбу с номером отгрузки
Карщики просто отвозят и группируют в зоне отгрузки
Вроде ок

Но чуть не накосяпорили
Алгоритм планирования отбора уже был, но упустил что все идет целыми паллетами, а паллеты вообщем нестандартные хотя отбор спланировался нормально типа паллета 870 взять 10 коробов а на паллете 168 коробов, штабелерщик и снял целую паллету не глядя на количество коробов потому что работаем паллетами, а получилось так потому что при автоподборе среди стандартных паллет проскочила нестандартная меньше на 10 коробов, в самом начале еще с клиентом ругался что делать в проблемных случаях, потому что заявки идут все в коробах и грузить надо по fefo - я говорю в общем случае ваша заявка не сможет быть подобрана без возможности нашего самостоятельного корректирования в сторону увеличения или уменьшения, нет говорят наши операторы будут скидывапть правильные количества - ага, как же. Теперь при первой же встрече буду кидаться грязью в лицо...

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

Рассмотрим на примере, по FEFO такие остатки:

паллета1 = 181шт
паллета2 = 196шт
паллета3 = 196шт
паллета4 = 196шт
паллета5 = 196шт

Заказ на отгрузку = 588шт

подбираем, получается = 181+196+196 = 573, мало, +196 = 769шт, получился излишек = 181шт, (решаем упрощенно, без рюкзака): сортируем по возрастанию количества пытаемся набрать излише=181 шт, подходит первая паллета - ее исключаем, в итоге в отбор спланировалось 196*3=588шт как заказано. При этом не в чистом виде соблюдается FEFO, но так как ОСГ большие, то и фиг с ним ;-) Ибо что планировать в отбор при наличии нестандартных паллет клиентом было "мягко обойдено" - несмотря на мои неоднократные "вопли" что вашиклиентские операторы не смогут даже при наличии стоковых остатков в разрезе емкостей паллет и сроков годности выдавать в заказ правильные количества в коробах - ну на что буквально же в первые дни и наткнулись. Пошел базарит с операторами клдиента и тыкать носом... В итоге порешили нестандартные паллеты пропускать и отгрузку таких нестандартов при необходимости делать ручками, на что вообщем я "заметил" что при пропуске нестандартных паллет в общем случае все равно не удастся подобрать требуемое количество коробов ибо стандартных паллет тупо не хватит. Сделали вид - что это фигня.. "как-нибудь" - мне вообщем все равно - время ходьбы и утрясания идет в зачет... ;-) вот как-то так...

Самый главный скриншот
[img]http://content.screencast.com/users/Che66/folders/Jing/media/fccfc619-ccd3-4310-9263-9eea806e799f/2015-12-08_1852.png[/img]

Вместо приведенного выше экранчика - сделана отгрузка. Можно отгружаться по ТСД. Потестировал, вроде все ок. Завтра проверим...

Скриншотики, назло врагам, на радость маме

[img]http://content.screencast.com/users/Che66/folders/Jing/media/7457da0e-733b-41b0-beb9-0a09c16a916a/2015-12-09_2130.png[/img]

[img]http://content.screencast.com/users/Che66/folders/Jing/media/929c8216-dd96-49e8-9c0f-77862cf4ab1f/2015-12-09_2132.png[/img]

[img]http://content.screencast.com/users/Che66/folders/Jing/media/0f977fbe-0bdc-411d-86f4-5d3399700057/2015-12-09_2133.png[/img]

Короче, босс Чучундера встретился случайно на Мальдивах с потенциальным арендатором его площадей...

Сможешь принять и отгрузить 100500 тонн ежемесячно?
Легко!

Плачу 100500 долларов за это!!!

ОК. У меня есть там какой-то Чучмундер.
Если что - обращайся к нему, он все сделает, я сейчас прямо дам ему приказ.

Только 100500 долларов мне сначала перечисли.
И я тут же при тебе позвоню своему чмучмундику.
Он все сделает идеально, атвичаю, брат.

- Граф, это вы играете такую прекрасную музыку?!
- Да так, хренячу помаленьку...

219-Чучундер > Проверили в боевых условиях работу по операциям отгрузки с ТСД (см.219). Работает без сбоев! Как говорится - "хреняк, хреняк, и в продакшен!".

Это вам не тотально глюковые типовые мегаконфы на восьмерке (пнуть снеговика - милое дело! ;-)

Что-то размещение не туда планирует как задумывалось... странно... очень странно... надо подумать...

Подумал, посмотрел.
Отчего непонятки возникли? - Оттого что я умный сильно. Чем умнее и больше знаний - тем шире граница контакта с непознанным и неведомым...

Проблемы, вообщем, не было... Все работает как задумывалось. Оборудование, с помощью которого проводилось размещение не имело доступ в зоны "ожидаемого" (на уровне "должно туда") размещения.

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

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

Вообще в конфигурации как таковых всего два отчета:
- отчет по остаткам
- ведомость по движениям

И хватает чтобы увидеть все что надо в части товародвижения и остатков.

Отчет по остаткам позволяет сформировать три разновидности:

сток-отчет для Собственника/поклажедателя - остатки по партиям/срокам, с разделением по емкостям паллет, также показывает и "зарезервированные" товары

И отчет по остаткам для аупа - с полной детализацией по партиям, местам хранения, паллетам, заказам, емкостям паллет, качеству

И сводный отчет для аупа - то же самое что и предыдущий, но свернута аналитика по местам хранения и заказам

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

Понятие резерва как такового отсутствует.
Резерв по сути есть остаток в разрезе аналитики "заказ", то есть резерв всегда предметен - под какой заказ, в каком конкретно адресе и тд

Сидел, развлекался построением отчетов в разных группировках/разрезах. Почемуто это на меня благотворно действует -успокаивает, точно также как наблюдение за процессом дефрагментации...

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

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

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

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

235-Зелёный тролль > Меня совершенно не парит.
У меня 32 процессора хьюлеттовских, пусть восьмерка грузит сколько хочет.

234-Зелёный тролль > никак у меня многопоточность не организована. тупо все. работают же разные экземпляры семкрки, на разных ядрах, а не на одном. Поэтому те, кто работает на ТСд - нагрузку вообщем не создают. Нагрузка только на неразделяемом ресурсе - на одновременном доступе к базе (с разных ТСД/рабочих мест (и проблема в (233) есть у меня подозрение что она из-за неправильного "отката" в случае блокировки базы). На ТСД - "обработка" жмака занимает для сложного "алгоритма" ~0.05 сек, так что человек 15-30 я думаю с активно жмакающими (что тоже сомнительно) терминалами я потяну... Большая нагрузка может быть когда "роботом" какое-нить планирование идет, но пока вроде тоже все ок. Смысл простой - делать транзакции как можно короче. Поэтому, например в транзакцию не пихается 50 строк заказа при планировании (где скорость не важна), делается 50 транзакций по 1 строке - что дает "дырку" всяким мелким запросам с ТСД. Как-то вот так.. посмотрим что дальше будет. Я сомневаюсь, что будут какие-то совершенно ступорно-критичные проблемы... - масштабы жмаков на терминалах не те..

235-Зелёный тролль > Фигасе....
Срочно пригласите специалиста.

То есть, я правильно понимаю, у Вас сто тысяч пользователей работают на одном ядре, и при этом стотыщ ядер простаивают?

Вот сижу, думаю - надо ли схему склада сделать. Со всякими фишками и плюшками типа жмакнул по ячейке и получил подробную инфу что там в каком количестве, партия и прочее. Потом типа стал на това - показываетполсвечивает где еще такойже товар, стал на партию - показывает где еще такая же партия. То есть по сути некий визуальный отчет об остатках.
Правда зачем такая фигня? Но удобно и быстровизуально? Всякие аупы и начсклады такое лело приветствуют - хотя по сути - мультик. Из полезного можно тупо по схеме склада в ручном режиме отбор планировать или перемещения...
Надо ли? Или нет? Непонятно...
В предыдущей версии программы самописки которая была существенно ниже уровнем схема склада была, начсклада пользовался

239-Чучундер > Так ты же планируешь в будущем монетизировать данное решение?
Чтобы оно тебя кормило стабильно на пенсии в старости?

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