Какое-то странное деление. Сталкивался со складом лет 14 назад, в OeBS уже и так все было и без всяких WCS.

1. А как может быть WMS без "подбор / комплектация" ?

Комплектация и без WMS требуется, и в обычном складе (Inventory), да и просто при оформлении заказа (Order Management, резерв под конкретный заказ). С точки зрения программиста: разделить код комплектации при отгрузки от резервирования - такое себе, слишком много общих частей. Т.ч. я бы расматривал и резерв, и комплектацию при отгрузки (и возможную комплектацию при перемешении внутри склада) как одну мега-задачу.

2. Если имеется в виду управление оборудованием/терминалами, так в нормальную WMS оно и так должно входит. Максимум выделяется в виде отдельного модуля в admin guide для OeBS, а в user guide так и вообще не выделяется.

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

Плюс минус километр, понятно дело я никаких фин. документов не видел, но порядки затрат примерно такие

Если заказчик готов оплатить стоимость_склада x 5-10 раз за разработку алгоритма и инф. системы - вот лично я бы в такое вписался))) год работы, а ты и твои дети могут уже не работать )))

Кто-то явно бредит и глючит.
Конечно возможно это я ))), но сомневаюсь.

Но насколько я понимаю, все такие алгоритмы работают на графах и на всякие 2D, 3D, 4D и прочее - им наплевать. Как граф соотносится с расположением в пространстве - глубо и полностью пофиг. Хоть 30-ти мерное пространство из теории струн оптимизируйте, граф он графом и останется.

AFAIK

IMHO

Т.е., как я понимаю, система разделяется на две части:
1. собственно "управление" железками. Тут кроме решения от поставщика железа, врят ли могут быть какие-то варианты. И вряд ли конкретное железо поддерживается стандартными ERM / WMS решениями (например OeBS)
2. хотелки и красивые поверпоинт-презентации про "оптимизацию" и прочее.

Если брать посроение маршрута: есть коробка, ее нужно положить в 5 учейку на 3 этаже. То алгоритм то банальный, на уровне программиста из детского сада на языке Лого.

Черепашка - переташи коробку по ленточному транспортеру до лифта
Черепашка - подними коробку на лифте на 3 этаж
Черепашка - переташи коробку до 5 ячейке
Черепашка - затолкай коробку в ячейку
Иди на строка 1, обрабатывай следующую коробку

))) Все. Алгоритм готов.

Есть брать оптимизацию, то IMHO & AFAIK самое сложное понять разумные критерия бизнеса, какой-же параметр мы оптимизируем.

Минимизируем перемешение механизмов = потребление электричества. Кучу денег на свете съекономим
Максимизируем кол-во одновременно перемещающихся коробок = вроде как загрузка оборудования выще, всем приятно, роботы трудятся - люди наслаждаются
и так далее и так далее
Но вариант "хотим быть богатыми и здоровными", тут не работает. Одно из двух. Оптимизируем по одному критерию, автоматически проигрываем по другим .

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

Опять таки, кто и что оптимизирует. Если коробки/задания поступают на вход из WMS системы "в разнобой", вряд ли на стадии "заталкивания в ячейки" что-то можно сильно оптимизировать. Т.е. значит оптимизация должна быть не только на уровен "роботов", но и на уровне правил размещения WMS-системы (да и на уровне резервирования при оформлении заказов ERP-системы так же), что бы на вход данные/коробки уже поступали оптимизировано и отсортированно.

Как и сказал в своем первом посте, деление системы на ERP, WMS, WCS мне представляется доволно сомнительным. Т.к. основные бизнес процессы и любые попытки оптимизации (если это не профанация) должны быть сквозные через все системы. Хотим, что бы склад работал максимально эффективно - то и бизнес-процесс, правила работы для продажников, оформляющих заказы и делающих ручные резервы, так же должны быть соответствующие.

IMHO С точки зрения дилетанта. WMS и склад видел давно. Складских роботов - не видел.

"ядро учетной системы" - слишком расплывчато

Я про Order Management (OeBS) оформление заказов на покупку, при оформление Sales Order уже может создаваться резервирование на складе. Это что же, каждую строчку заказа через "шину" прогонять? Мало того, что может потребоваться создавать резервирование, так ведь его же еще и в ручную создают, для некоторых "дефицитных" позиций вплоть до конкретной единицы товара (партии). И это не исключение, а повседневная рутинная работа отдела продаж (в той компании, где я сталкивался). Как развесистый UI ручного резервирована сделать через сообщения/шины.... мне кажется гемор еще тот.