Наименование: Система управления складом A-WMS Basis
Сайт продукта: https://awms.ru/basis.html

Это развитие складской темы Программа сбора штрихкодов на Android (мобильный модуль WMS)
На текущий момент две разработки образуют завершенный комплекс управления складом.
В октябре 2023 года система A-WMS Basis была впервые внедрена на складе электрооборудования: 2тыс.кв.м, 1,5тыс.sku, управляющая система 1С:УТ 11.

Система A-WMS Basis написана на платформе 1С:Предприятие 8 и содержит интегрированный модуль управления мобильными устройствами A-WMS Mobile ( https://awms.ru/mobile.html ).

Кратко, что в "коробке":
- учет исполнения входящих заказов складской службе;
- поддержка работы с несколькими территориальными подразделениями (складами), с общей НСИ и возможностью разделения доступа пользователей;
- учет остатков товаров на складах и в ячейках;
- учет элементарных складских операций: приемка, размещение, отбор, пересчет и т.п.;
- исполнение операций на ТСД;
- базовый функционал учета отгрузок собственной службой доставки;
- подготовка под функционал биллинга складских операций и статистическая отчетность;
- бесшовная интеграция с внешними системами на базе 1С УТ11, КА, ERP.

Предложения и заявки на тестирование можно слать на почту info@awms.ru

(104) если ВМС не коннетится в внешним миром по статусу марок, то например все марки на стадии приемки (то есть ПРОСТО ОТСКАНИРОВАННЫЕ при приемке) - считаются валидными? то есть работа с марками по такой концепции (отсутствие связи марок с внешним миром) идет "тупо" как с уникальными серийными номерами и собственно к валидности марок никак не привязана? так получается?

(105) откуда у производителя берутся марки? он их заказывает!
соответственно, есть возможность достоверно определить начальный статус марки. а дальше считаем куда ушла, откуда пришла. да, можно дополнительным регламентом проходить запросами к ЧЗ по списку марок, но в указанном контексте смысла в этом не много.

(106) это если исходить из оптимистической стратегии: когда все работают на отлично и нет никаких траблов ни у кого.

(106) "есть возможность достоверно определить начальный статус марки."
- и как он определяется?

(107) (108) есть производитель одежды, под выпуск продукции он заказывает в ЧЗ марки.
поехали дальше:
1. марка заказана - она фиксируется в системе со статусом "известна но не доступна";
2. марка принимается приемкой. на момент приемки марка должна быть "известна но не доступна". после приемки становится "доступна";
3. на момент выбытия марка должна быть доступна.

(109) п. 1 неясно откуда инфа по п.1 возникает в ВМС?
Приходит из КИС с заданием на приемку?

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

(111) понятно, по сути - как в (95) написал.

(109) Товар принимается коробом. Короб физически не вскрывается. По факту там могут быть марки с кривым статусом. Кроме того, даже если при приемке всё ОК, то потом статус код может поменяться.
(93) Например, в МДЛП можно перетащить "на себя" любой код,  часто это следствие предыдущего абзаца (пересорт).

(98) "сами считайте их статус" - стучаться в ГИС МТ при каждом пике? Так в этом и проблема. Нужно знать статус в ГИС МТ, а не в своей системе.

(113) "Нужно знать статус в ГИС МТ, а не в своей системе."
ну так в (95) я об этом явно написал. в ВМС стучаться наружу по каждому пику или даже массовым запросом по готовности к отгрузке - так себе удовольствие, к работе склада это вообще побоку.
Разумнее в ВМС подсасывать/скидывать/обновлять из КИС перечень валидных марок, не делать заключение о валидности марки только по входу марок на ВМС. Да, по готовности "заказа" к отгрузке может и имеет смысл в каких-то случах тем или иным образом сткунуться наружу сразу или транзитом через КИС и получить ответ, но правильнее валидность марки при отборе проверять по обновляемому массиву валидности, а не стукаться наружу. Как-то так я себе представляю. Но тут как заказчик захочет, на этапе техпроекта определяется.

(114) Мы ведь не знаем заранее, какую марку возьмёт сборщик. Может попасться марка, которой вообще не должно было быть на складе.
" обновлять из КИС перечень валидных марок" - не понимаю эту фразу. Валидность определяется данными в ГИСМТ, а не данными КИС.
Просто сейчас у нас нет ни конвейера, ни сплошного сканирования (в основном используется обратный акцепт по лекарствам, когда марки сканирует покупатель). Но как быть, если придётся сканировать всё подряд? Кроме как смириться с ошибками, вариантов не вижу. Останавливать отгрузку и ждать пока придет информация из ГИСМТ или МДЛП - это перебор.

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

(115) вы не работаете В ГИСМТ.
Валидность марок определяется описанием их валидности в рамках вашей КИС. Насколько часто валидность в КИС "синхронизируется" с ГИСМТ - отдельный вопрос. Вот и все.
Остальное в (116) описано.

(117) "валидность в КИС "синхронизируется" с ГИСМТ " - это невозможно по двум причинам:
1) количество марок
2) физическое наличие на складе марок, которых нет в КИС, но которые могут быть вполне валидные в ГИС МТ

Конечно, первая ступень контроля - это текущие данные КИС. Если на этом этапе ошибка - не даем собирать этот товар, и сигнал на проверку. Если всё ОК - долбим ЦРПТ, и если успели отловить ошибку до этапа контроля - мы молодцы. Если отловили уже на этапе отгрузки, тут выбор: если заказ мелкий - проще его отменить, если крупный - можно забить на одну проблемную марку. Наверное, так.

"Если всё ОК - долбим ЦРПТ"
- долбить ЦРПТ по пику складом на каждую марку? во время сборки?

(119) Пик - Сборщик товар кладет в коробку - ставим марку в очередь на проверку. В течение пару минут (пока коробка едет до контроля, правда, пока непонятно сколько по факту будет ехать) проверка отрабатывает (в апи запросы идут блоками по 500 штук).

понятно.

Ужасная картинка доставки.

(122) Растяни боян

(123) Уже говорили?

(124) про что?

Часто задаваемые вопросы по A-WMS Basis

1. В: Это программа на базе 1С?
О: Да, это конфигурация платформы 1С:Предприятие 8.

2. В: Это самостоятельная система, или это доп.настройка/встраиваемый блок?
О: A-WMS Basis - отдельная программа (конфигурация платформы 1С:Предприятие 8), может работать как в связке с системой оперативного учета, так и изолировано.

3. В: Программа поддерживает адресное/ячеистое хранение?
О: Да, поддерживает. Программа предназначена для управления адресным/ячеистым складом, учитывает остаток товара в разрезе ячеек.

4. В: Программа умеет работать одновременно с несколькими складами?
О: Да, программа поддерживает учет товаров одновременно в нескольких складах с разными топологиями.
При этом, учет на каждом складе может вести своя команда (операторы/комплектовщики), с ограниченным доступом к данным "чужих" складов.

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

6. В: Возможна ли работа с системой в зонах хранения при отсутствии доступа к сетям WiFi/GSM?
О: Да, система допускает выполнение складских заданий в зонах ограниченной связи, при условиях:
- связь необходима для получения задания на мобильном приложении, при этом система позволяет принять в работу сразу несколько заданий;
- для выполнения задания на мобильном приложении связь не обязательна;
- после завершения задания на мобильном приложении, система ожидает соединения для отправки данных завершенного задания, не блокируя работу по следующим ранее принятым заданиям.

7. В: Возможна ли интеграция системы с корпоративной 1С?
О: Да, система поддерживает интеграцию с корпоративными системами при помощи технологии "web-api", принимающей стороной является A-WMS Basis.

8. В: Какие преимущества дает A-WMS Basis в сравнении со встроенной в 1С:Управление торговлей ред.11 системой управления складом?
О: Прежде всего, A-WMS Basis - отдельная программа, предназначенная исключительно для складских сотрудников, что позволяет повысить достоверность учета.
Прочие отличия:
- более простой и линейный учет (складской заказ - элементарные операции), относительно ордерной компоновки в 1С:Управление торговлей;
- возможность использования виртуальных складов на стороне 1С:Управление торговлей (акции, предпродажная подготовка, и т.п.), с трансляцией данных по ним в один физический склад на стороне A-WMS Basis;
- более лучшая масштабируемость системы A-WMS Basis;
- A-WMS Basis позволяет выполнять задания при помощи ТСД "из коробки".

9. В: Какие преимущества дает A-WMS Basis в сравнении с прочими тиражными WMS-решениями?
О: Основные факторы:
- система A-WMS Basis оптимизирована для использования в связке с системами оперативного учета на базе программ 1С:Предприятие 8: 1С:Управление торговлей, 1С:КА, 1С:ERP, что обеспечивает высокую скорость адаптации решения для торгово-производственных компаний;
- система A-WMS Basis поддерживает работу с территориально распределенными складами (склады филиалов, накопительные склады, склады торговых точек) в одной программе;
- система исполнения мобильных заданий позволяет работать в зонах ограниченной связи;
- оптимизированная модель складского учета и хорошая эргономика мобильного приложения позволяют понизить требования к операторам и комплектовщикам;
Все вышеперечисленное позволяет обеспечить низкую стоимость внедрения и поддержки решения.

п.9 - ни в дугу.
надеюсь что A-WMS поддерживает не только в разрезея ячеек, но и в разрезе паллет(конейнеров, когда в ячейке1 стоит пал1 с товар1 Nштук и пал2 с товар2 Yштук) и грузовых мест (как с борных грузовых мест/коробов с известным составом товаров, например сборные идентифицированные короба на идентифицированных паллетах в ячейках, так и грузовые места с обезличенным товарным составом)

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

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

(127) написал для тех, кто только подходит к теме.
(128) от меня хотят слышать "быстро запускается и дешево поддерживается" - именно это я и предлагаю))
(129) агрегированная обработка товара поддерживается.

(130) у вас есть сравнение с БИТ:ВМС и 1С:ВМС Логистика? У нас как раз начальник складского комплекса подыскивает, что на склад хочет ставить.

(131) красиво оформленного сравнения нет.
глобально, все решения делают одно и то же,
БИТ:ВМС не смотрел,
относительно 1С:ВМС Логистика (поддерживал ее):
- готовая интеграция под ут,ка,ерп;
- модель учета оптимизирована под ут,ка,ерп;
- проще управление, и обучение.
меня выбирают прежде всего из-за цены вопроса.

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

(132) Ты продаешь экспертизу по цене айти консалтинга, отсюда и разница

(131) стукнись в личку

(132) чтото в вмс оптимизировать под модель учета типовых 1с - это так себе выбор, это может вылиться под выстрел себе в ногу.

(132) А на проект тебя можно позвать?

Надо отметить что у автора хороший подход к архитектуре в части возможности построения разных процессов обработки товара.

(137) смотря что за проект.

(139) Запускаем новый склад, "с чистого листа", "железки" (не алкашка, не пищёвка), серийные номера, и, в перспективе ЧЗ.
Оптовка + производство

(0) самый вкусный вопрос - есть ли свой софт для ТСД или надо брать у двух известных поставщиков софта ТСД.

(141) я с софта для тсд как раз тему и начинал, в шапке есть ссылка на параллельный продукт.

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

(136) сейчас это реалии, т.к. меня интересуют только те кто продает, а это 70/80% ут11, ка, ерп.. а из за того что системы настраиваются "галочками", то это образует боль для неадаптированной вмс.

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

(144) на той же ка, ерп, ут, уны - на каждой из упомянутых можно реализовать несколько схем, от простых до сложных и в т.ч. извращенных. Подстраиваться под каждую?
.
Есть у тебя апи? Апи работает на рush/pop? Или под каждую схему, которая есть у клиента - пишешь интеграцию?
.
Файловый обмен поддерживается? Куча вроде серьезных контор на проектах встречается, а обмен по онлайн каналам сделать на стороне КИС не могут. При этом куча контор на проектах внедренцев вмс вообще не пускают на сторону своей КИС.

(145) это норм;-) прикольно наблюдать как народ нервничает, а к концу дня с выпученными глазами: "Оно работает!"

Обычно нервничают от того что не понимают что делают подиумравлением самой ВМС. Ибо привыкли "управлять" сами. Но при росте грузопотока, количества заявок, разнородности условий для "управления" по разным критериям - "рычагов" оказывается десятка полтора и больше, а "рук" - всего две...

На одном проекте (но не у меня) было под охрененное количество правил по обработке товаропотока для достижения эффективного управления складом.
.
Что обычное на проекте внедрения вмс - отсутствие формализации правил обслуживания заказов/клиентов/направлений. И каких либо усилий для обоснованной нормальной формализации Заказчик не может/не хочет сделать
И все что в таком варианте получается сделать - перенос работы с бумаги на тсд и некоторое увеличение скорости. И бывает заказчик этим удовлетворён. А бывает и так: а че оно не так как нам представлялось? При том что все представление в стиле "чтобы было зашибись и ничего нам не было".

Сейчас вот мониторю проект внедрения ВМС и изредка консультирую РП со стороны Заказчика. Занятно наблюдать за результатами ;-)

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

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

(147) склад однозначно проще внедрять, чем ут11))

(152) Вообще пофигу

(153) это если сам не пишешь код, иначе есть небольшие отличия)

(153) склад проще. по складским процессам нет понятия исправлений задним числом. все косяки/нескладушечки/нестыковочки - вылазят практически сразу, а не при каком-то мудачном "закрытии месяца". ну итд.

(155) Смотри (153)

(156) Смотри (155) ;-)

(157) Ты не смог освоить простые правила?

Прочитал тему полностью, успехов!
По факту шаришь как и Злопчинский!
Тема нужная, как раз сейчас занимаюсь похожей фигней!
Но процессы немного специфичнее скажем так)

(159) было бы интересно услышать про "процессы немного специфичнее", на тему прикинуть себе можно ли выкрутить специфичные процессы настройками (если что - то можно и в личку)

(159) Спасибо.
Злоп круче - у него стаж больше)
но я внедряю собственный софт.

(161) Это смотря в чем стаж мерять ;-)

(161) я тоже писал велосипеды. это время конечно подымает квалификацию, но потрачено в никуда. Этим стоит заниматься только если нацеливаться на создание тиражного продукта и сопровождения и развития в одно рыло. Можно посмотреть на Arena WMS - чем это все закончилось.

по итогу текущего проекта.
отработали 4 дня.
первоначально был перенесен остаток на общую ячейку, работу склада не останавливали, параллельно пересчитываем.

массово фиксируем попытки отбирать не то, но тсд не пропускает. осознали, приняли)

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

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

по этапам,
месяц ушел на обклейку и подготовку, пара дней на обучение, совмещенное с тестовым запуском.

в целом, нормально и показательно: месяц-полтора и адреса в работе. допом много времени ушло на согласование и ожидание, но это лирика. общая складская площадь порядка 8тыс.кв.м., ~10тыс.sku, товар сложный, впереди сроки годности.

(163) ну меня ситуация привела к необходимости писать, да и возможность "закрыться" на пол года была.
потом, я предлагаю адаптированную под типового клиента технологию внедрения, а это сроки и деньги. запросы на систему есть, потихоньку двигаю.

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

(165) Если бы были "типовые клиенты" - нафиг никаких доработок не надо было бы.

(164) "сроки годности".
готовься для "типовых клиентов" - для разных категорий клиентов разные варианты допустимых сроков годности. Где-то по ОСГ - строго не менее 70% на дату отгрузки (например, сети и вип-клиенты), есть категория клиентов которым допускается незначительное нарушение ОСГ, но не более чем в ворота, требуется 70, но до 68% тоже прокатит. Где-то сроки годности будут "эквивалентны" датам производства. Всяким мелким ИПшникам/рознице - можно грузить вообще наплевав на сроки годности, даже малые пойдут ибо берут малыми количествами и быстро распродают. А где-то придется не от ОСГ плясать, а от абсолютных величин: - и это все придется из КИС передавать как требования к сборке. И внезапно окажется что для сборки с требуемым сроком годности - товара нет в ячейках отбора и придется подпитку делать с верхних ярусов, а свободных ячеек внизу нет и надо кидать в оперативную зону... Плюс к этому придется адски бороться за ячейки, ибо мешать в одной ячейке существенно разные сроки годности - прямой путь к траблам. И если на верхах обычно одна паллета = одна серия, то в ячейках отбора бывает можно миксовать незначительно расходящиеся сроки годности. Плюс к этому как всегда крупный поставщик поставляет 10 паллет, 9 - моносрок, а на последней паллете поставщик подобрал хвосты и там смесь разных сроков - на приемке надо сразу разделять...
И понеслось...
То что навскидку вспомнил...

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

Но по всякому - ты молодец, двигай дальше.

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

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

(166) типовой клиент = типовая КИС, я про это. конкретная КИС определяет много факторов взаимодействия, если они учтены в коробке вмс, то много времени экономится. так же, уже готовая статистика позволяет не наступать на пройденные где то ранее грабли.

(167) да самое веселое - это сроки годности и маркировка

(173) Короче, ждем репортажей с линии внедрений ;-)
А то совсем что-то движухи тут нет

(174) Да скукота

Приехать,
сделать модель учета под штучную маркировку
Получить от заказчика, что так сложно ему не надо, и нужно под общий учет
Допилить систему под общий учет
Вернуться к первоначальной модели под штучную маркировку

аналогично и со сроками годности и со всем остальным

(176) "Допилить систему под общий учет
Вернуться к первоначальной модели под штучную маркировку"
итого ценник*2
;-)

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

(179) правильно, ибо нехер выпендриваться. Позвали специалиста - делайте как специалист говорит, а не вот это вот все.

Про персонал... KPI всякий...

новое

- передали решение в эксплуатацию: товар - фасованная химия, общая площадь хранения порядка 8 тыс.кв.м., 10 ТСД, КИС - ERP. пока стадия активной поддержки. в активной фазе внедрения проект был порядка 1,5 мес. особенностью проекта стала потеря кучи времени на решение орг-вопросов, но прорвались.

- начат новый проект: упаковочные материалы, 3тыс.кв.м. порядка 15 комплектовщиков (высокая оборачиваемость товара). завершается стадия предпроектного, на днях будет готова базовая интеграция с КИС (УТ11). планируемый срок завершения проекта - конец марта. складом рулит сильная команда, есть все шансы побить рекорды внедрения)

хочу обозначить этапы типового проекта:

1. предпроектное, базовая интеграция, разворачивание базы WMS, срок - до 2-х недель, далее ждем завершения этикетирования;
2. формирование модели под нюансы учета, согласование новых процессов, доработка WMS под согласованные процессы, тестирование, срок - до 2-х недель, с момента завершения этикетирования;
3. обучение, передача в эксплуатацию и оперативная поддержка, срок - до 2-х недель.

переход на новые регламенты получается достаточно плавным:

1. тестируем, тестируем.. а потом я переношу начальный остаток в эту же базу и мы уже работаем)
2. с момента переноса остатка, весь остаток числится на одной ячейке (мусорной), плюс сразу запускаем пересчет и в систему постепенно добавляются "белые ячейки". все операции делятся на операции с мусорной ячейкой и с "белыми". в первом случае работают старые регламенты, для пересчитанных ячеек уже новые.
3. сначала делаем упор на минимально необходимых для ведения адресного учета регламентах: все отборы с ТСД, все операции с белыми ячейками с ТСД. в процессе становления ячеек "белыми" решаем задачи мотивации персонала.
4. как только все ячейки стали "белыми", убираем остаток с мусорной ячейки. к этому времени, все кто должен быть уволен уже покинули территорию, саботажа минимум.

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

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

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

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

(182) норм!
.
а так конечно будет интересно когда-нибудь увидеть чем будет обосновываться собственником переход с A-WMS на другую WMS

Немного не понял "я предлагаю практически готовую к применению модель, не переписывая заново весь управляющий код при внедрении." - про управляющий код, что такое "управляющий  код"

(185) это маловероятно на поздних стадиях, т.к. это перевнедрение. (186) логика модели

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

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

(189) каким образом актуальные остатки по складу оказываются в кис когда весь товар оказался в белых ячейках?

(190) никаким) сведение остатка кис и вмс - задача годовой инвентаризации. или полугодовой - пофигу)
процесс на переходный период организован таким образом, что на стороне вмс остатка всегда достаточно, принимаем, что он не достоверный. но как только списали мусор, начинаем верить тому, что говорит вмс.

(191) риска никакого нет, все равно пока живем по данным кис

фу, какая бяка.
на переходный период еще понятно. но дальше как-то аккуратнее  должно быть. Какой смысл если в КИС манагер видит 2500шт, а на складе реально 2300. Какому-то клиенту - опа! недогруз! а клиент внезапно випом оказался...

А потом корячиться с догрузом недовоза.
Или с довозом недогруза.
;-)

Но, наверное, где-то и с кривыми остатками в КИС народ счастлив. Склад стал шустрее с ТСД сборку делать - уже радость!

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

хроники хронического внедренца)
сегодня устроил сеанс обучения на оператора начальнику склада. на второй час мнение с "да все херня, ща раскидаем обязанности и сами потянем" поменялось на "где взять оператора?!". а все потому что привыкают к вечному затыканию бардака, а когда приходит Система - падают в обморок)

(197) если система нормальная - то оператор нужен когда манагеры хреном груши околачивают. Или недостаточность автоматизации в самой системе. Там где бегунков 8-12 оператор как таковой и не нужен чтобы постоянно рулить.
Задания падают из кис, результаты выплевываются в кис. Задания в вмс упали из кис. Система спланировала-раскидала в очереди, задания из очереди выталкиваются бегункам на исполнение. Оператор здесь нужен пару раз в день эпизодически чтобы трэш который продавпны творят разруливать когда не выстроена стстнма приоритезации и диспетчеризации и всем этим вручную занимается оператор - сидит и все поступающие задания ручками планирует/распределяет. Это по сути самы нижний уровень автоматизации складской работы.
.
Обычно оператор/начсклада рулит распределением ресурсов - сколько поставить на сборку, сколько на приемку, сколько на маркировку, упаковку итд. Бо нормальное автоматическое управление персоналом в рамках вис я не встречал. Может что и появилось.
.
Я пытался с помощью коллег с форума чтото выпилить, но то ли мотивации в меня настоящей не было, то ли это не очень надо было - не пошло дальше намнток что и как.
.
Чаще всего все планирование ресурса на уровне далборда типа если будем собирать с таким же темпом то к 17-00 не успеется или успеется собраться заказы требуемые или промаркироваться или упаковаться.
.
А вот такого типа чтобы успеть собрать все заказы к назначенному времени и промаркировать например и упаковать - надо с маркировки где сейчас работают 3 чела перекинуть одного человека на сборку. А с упаковки где 2 чела - перекинуть одного на приемку (ибо товар не принят и заказ в сборку не планируется и не успевает к сроку.
.
Как такое управление ресурсами сделать - практически не представляю. И надо ли оно? Обычно на основе статистики уже понятно сколько строк за день успевают собрать, промаркировать и прочие операции сделать. И на рабочий день типа некий стек операции-емкость и если стне заполнен то срок задания сдвигается на след.день.
.
Но это имхо тоже совсем не просто. То же самое планирование ресурсов в чуть упрощённом виде. В вис не встречал такого. Может где и есть, молчат же в п кто имеет опыт эксплуатации всяких акселотов, псиаев, одинассвээмэсов итд...

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

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

вот так и живут операторы: пришел заказ - приняли - разруливаем косяки офиса, разруливаем косяки криворуких сотрудников склада.. процесс не сложный, но жопа в мыле.

(199) дичь продолжает творить офис
- это да. При творящем дичь офисе эффект от автоматизации склада есть конечно, но совсем не тот что может быть. Дикий офис приводит как раз к ручной диспетчеризации оператором. А эффект от ускорения сборки спустя какое-то время съедается увеличившимся валом заказов на тот же самый ресурс времени - склад о стал работать "лучше". И продолжается та же самая зарара с нехваткой времени на обработку заказов, ручными управлением вася пилай назер свой заказ на 450тыс и похер что посередине и беги срочно собирать а то тут мегапупер суперважный самовывозник с двумя позициями на 4200 руб. Да, пересортов на порядки меньше, претензий мало от клиентов. Но принципиал нот ничего не поменялось. На своих проектах всегда заказчику говорил что если хотите чтобы было ряшно - или склад потянет да собой упорядочивание работы взаимодействующих подразделений (чем и должен заниматься начсклада с народом и начзакупом) или будет конечно получше, но не так хорошо как вы себе рисуете единорогов. Ктото параллельно с внедрением вмс сразу прорабатывает приоритетность и диспетчеризацию заявок на уровне продаж, а кого то и дикий офис устраивает.

(199) абсолютная автоматизация - согласен и это понятно. Постоянный движ который резко возник или умрет через 2-3 недели или новая какая-то хрень станет нормой и автоматизируется и летит дальше на автомате. Все зависит от бюджетов. Я как-то упоминал что на каком о проекте было нивъ..ное количество правил автоматического разруливания товаропотока и заказов. И работало. Понятно что не за 2-3 дня такое устаканивается. Но если работать над совершенствованием процессов на складе постоянно более-менее - вполне достижимо. Там где в этом реально заинтересованы. Ибо цена разруливпния неавтоматизированных косяков начинает реально ломать очень сильно.
А так да, правильно все пишешь. Интересно.
Имеет смысл вести с полей и вот это все писать не только здесь но у себя в канале или в меня в мелких каналах в телеге по вмс, заодно и аудитория подтянется и клиенты потенциальные

(200) дикий офис со временем уходит: склад в какой то момент начинает оперировать статистикой и пипец шустрым и наглым карапузикам)
но все очень индивидуально.

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

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

(202) " и пипец шустрым и наглым карапузикам)"
- как будто до WMS не было понятно из-за чего жпс, а не только из-за того что склад весь такой неадекватный ;-)