По итогам темы нужен совет по разработке WMS родился продукт.

Наименование: Мобильный модуль системы управления складом A-WMS Mobile.
Сайт продукта: https://awms.ru/mobile.html

Кратко, что есть:
- Мобильное приложение под Android от версии 4.3, написано на Мобильной платформе 1С.
- Мобильное приложение работает со сканерами: ТСД (встроенный), bluetooth (внешний), через фото-камеру устройства.
- Мобильное приложение оптимизировано для массовых операций, может работать в режиме off-line с ассортиментом до 1млн.sku.
- Это клиент-серверное решение, серверная часть системы реализуется в модуле интеграции на стороне учетной системы 1С.
- Решение оптимизировано (образует бесшовный комплекс) для использования с конфигурациями 1С:УТ, КА, ERP.
- Решение используется как мобильный модуль отдельной WMS, подробно тут: https://awms.ru/basis.html
- Решение настраивается и поддерживается на стороне учетной системы силами программистов 1С.
- Лицензирование мобильной платформы 1С осуществляется самостоятельно.

В картинках приведены примеры интерфейса на сентябрь 2023.

(308) спасибо! взаимно! я всегда открыт для диалога!

(309) оно в плане/резерве висит, пока задание не закроется

ЗАДАЧА: разместить товар по динамическому списку ячеек.
сценарий: Товар->Ячейка.
выполнение:
1. "сканируем Товар";
2. открываем список предложений по ячейкам (формируется он-лайн на хосте, сортировка по остатку, наименованию, зоне доступности и т.п.), определяем нужную для размещения, размещаем;
3. повторяем пп.1-2 пока не разместим все.

ЗАДАЧА: сортировка товара по заказам в рамках волновой сборки в зоне отгрузки(сортировки).
сценарий: Товар->Заказ.
выполнение:
1. сканируем Товар;
2. система выводит список заказов для распределения - помещаем товар в нужный отсек, сканируем заказ;
3. повторяем пп.1-2.

(311) Система видит/знает в процессе сборки (когда пул заданий на сборку еще не выполнен полностью бегунком) что товар из ячейки изъят (и например, можно на ТСД штабелерщику выдать задания на подпитку в эту ячейку)...?

(312) "определяем нужную для размещения,"
- кто "определяет"? Система говорит "клади 20шт Товар1 в ячейку А1" или бегунок сам выбирает сколько куда положить? какова гибкость настроек? - для "тупых" бегунков д.б. безалтернативно (а то наЛожат..), для "умных" бугунков - д.б. возможность разместить товар в ячейку, отличную от запланированной системой. Может положить в любую ячейку? или только из перечня алтернатив? только в пределах доступных ему зон или в любую зону ДОСТУПНУЮ для данного вида операции?

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

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

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

(313) Зачем список заказов для распределения в п.2...? Количество отсеков (1заказ не более чем в 1отсек) менее количества заказов? - зачем тогда если это можно системно раскидать автоматом согласно "приоритету" заказов...?
.
система знает сколько каких товаров по каким заказам подлежит сортировке, зачем здесь какие-то манипуляции с заказами на уровне сотрудника с ТСД?
.
"помещаем в нужный отсек" -ок, "сканируем заказ"... - зачем сканировать заказ?
.
делал совершенно аналогичную вещь - там персонал вообще в процессе сортировки с заказами не работал. пул заказов выбирался при начале работы (сортировка поставки от поставщика сразу по заказам точек, отсеки были жестко привязаны к точкам) - далее (не глядя на экран (был комп с ручным сканером = ТСД ;-) - скан Товар - голосом "один!" - кинул в отсек1, скан товар - голосом "пять!" - кинул в отсек5, если лишний товар (ассортимент, нет в заказах точек голосом "Тыбыдым!" кидаем а спецкоробку на склад, итд) Можно для подтверждени кидания - жмакать по номеру отсека
.
в варианте (313) - при начале сортировки привязали отсеки к заказам (если совсем все хорошо сделать - то даже этого не надо, система сама привязала, система знает в каком отсеке какой заказ при дальнейшем перемещении по складу - содержимое отсека адресовано, известно какой заказ - "бери все содержимое отсека О5 - скан для подтверждения как вариант" - сканируй принтер форматf 40x60 (выбирается ближайший или закрепляется заранее) - вылезает дейбла - кладем в коробку - клеим лейблу - сканируй лейблу! - скан! тащи в ячейку ворота2" - все достаточно условно сценарий описан - главное - пока неясно для чего в (313) в п.2 список заказов и сканирование заказа...

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

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

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

"сканировать заказ надо для формирования факта выполнения, чтобы на хост попало, у меня же оффлайн-модель."
- наверное недопонял, но не сильно важно..
.
а что, на приложении, которое на ТСД вертится в "автономе" - совсем никакой логики? Насколько я представляю - "скидываются" на ТСД достаточно "атомарные" (в смысле возможности исполнения на ТСД) объемы данных/"задачи".
.
Факт выполнения "задания" есть совпадение плана (ожидаемые значения) с фактом, при совпадении плана-факта очень редко когда требуется явное подтверждение (весовой/мерный товар когда допускается перебор относительно плана или когда явным образом по регламентам обслуживания разрешен перебор количества типа заказал 10, а в заводском коробе 12 - обычно это еще на этапе подготовки заказа на стороне учетной системы подгоняется), подтверждение (сканированием/выбором например заказа) может потребоваться когда надо завершить заказ с недобором/менее 100% выпонения (план 100, по факту ну вот 98 только товара есть).

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

(298) кстати, вопрос! а есть ли где-то некий глоссарий по этой (складская/логистическая терминология) теме? не встречался?

(325) общего признанного классификатора нет. есть некий общий тренд по терминологии, формируется крупными игроками отрасли. но там по сути не сложно.

(326) Да я знаю, что "не сложно". Но уже третий зам.по логистике, и у каждого своя терминология, "на основе" "решений крупных игроков". Как пример: "подпитка", "пополнение", "дотарка". Всё бы ничего, но вот "особо одаренная особа" потребовала "переименовать кнопку", ибо "на предыдущей работе так было", и "какой дурак назвал дотарку пополнением". Ей, конечно, был посоветован анально-генитальный маршрут, но хотелось бы обходиться без скандалов...

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

(327) а в чем проблема переименовывания кнопки?

(329) а какой в этом смысл? Пересобирать МП, перезаливать в МУ, исправлять картинки в докуменнтации, переснимать видос по работе с ТСД по этой операции - чтобы что?

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

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

ЗАДАЧИ ИЗ РАЗДЕЛА: найти "потеряшку". работа контролера с разделом "Поиск товара" в режиме онлайн-отображения.

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

2. не нашли товар при отборе (проверяем очевидное):
- находим в списке товар по артикулу или ш/к - смотрим где лежит;
- делаем осмотр соседних ячеек;
- если нашли товар, то дважды сканируем ячейку - смотрим, числится ли этот sku, если нет, то возвращаем где не нашли.

(332) А можно чуть подробнее: как выглядит процесс обновления приложения на ТСД? Оно само скачивает APK из локальной сети?

(334) актуальный дистрибутив лежит на сайте.
приложение лезет на сайт, смотрит файл актуальной версии (файл ver15.id), сверяет со своим номером и если есть разница говорит типа "есть обновление, перейти?". при переходе открывается браузер с сайтом, оттуда качаем и ставим файл. на андроиде разрешаем установку из неизвестных источников.
тут вроде все. нормально на МП 1С не сделать, да и нормально мало щас кто обновляется..

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

(335) "все настройки для данной модели ТСД".
Кстати, вопрос: как определить модель ТСД в мобильном приложении? Я не смог найти, вроде как без ВК не обойтись. Может есть готовые бесплатные ВК для этого?

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

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

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

у яндекса прикольная WMS

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

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

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

для примера работы с типами заданий, можно рассмотреть модуль интеграции с Управление торговлей 11.
в УТ11 есть прекрасный документ "Отбор, размещение товаров". этот эпичный финал полета фантазии сотрудников 1С порождает минимум три элементарных складских операции: Отбор, Размещение, Перемещение по ячейкам.
в модуле интеграции эти три операции транслируются на ТСД в виде тех же самых операций, и там же определена логика разбора результата выполненного задания и трансляция этого результата в документ 1С.

для каждой операции на ТСД предусмотрен свой сценарий выполнения, определена возможность создания задания на стороне ТСД, некоторые интерфейсные и сервисные возможности.

допустим, у нас есть задача разделить сборку на два вида:
- сборка для розничных клиентов интернет-магазина, с маленькими по объему заказами;
- сборка для оптовых покупателей, с одновременным распределением заказа по товарным местам.
понятно, что нам нужно два сценария:
- "Ячейка-Товар" - для сборки без товарных мест;
- "Место-Ячейка-Товар" - для сборки с товарными местами.
далее задачу можно решать несколькими способами:
1. для работы с указанными двумя сценариями добавляем свои типы заданий для каждого: "Отбор" и "Отбор по местам";
2. используем один тип задания "Отбор", но при выгрузке задания на терминал привязываем к заданию сценарий, в зависимости от вида сборки;
3. используем один тип задания "Отбор", но перед выполнением задания на ТСД, исполнитель в меню задания выбирает нужный сценарий.

(340) под их объемы и с их ресурсами она как минимум должна быть прикольной)

(325) можно чуток посмотреть здесь

ГОСТ Р 59282-2020
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМЫ УПРАВЛЕНИЯ СКЛАДОМ
Функциональные требования

(327) подпитка, пополнение - норм.
дотарка, вытарка и прочее - бредятина

(327) "ибо "на предыдущей работе так было", и "какой дурак назвал дотарку пополнением".
.
аналогично было (только не про склад) "..а вот на предыдущей работе..." - ну так я и сказал просто: "ну так 3/14-дуйте на предыдущую работу..."

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

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

...и ранее писал - бытует мнение, что тянущие системы недостойны называться WMS...

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

(346) я тут примеры кидаю, как можно систему применить. по факту, разные ситуации приводят к очень неоднозначным вариантам использования.

(349) то есть сборщик сам определяет какой заказ он будет собирать руководствуясь личными интересами

"многозадачные исполнители - обычная ситуация в торговом бизнесе, тут нет странностей."
да, это сплошь и рядом по возможным ролям. Исполнитель тем или иным образом говорит системе в какой роли он будет работать: "я - сборщик" или "я - контролер" или "я - приемщик". WMS, которые бы сами перенаправляли сотрудника с роли на роль типа закончил сборку заказа, а система тебе - "иди работай на участок контроля контролером" - не слышал про таких (но может такие и есть, решая задачу распределения трудовых ресурсов в упрощенном виде). А вот когда сборщик приступил к сборке заказов (будем считать 1заказ = 1 задание на сборку) и сам определяет какой заказ собирать - чем руководствуется? если все заказы равноправны - разницы какой заказ собирать - нет, система сама может вытолкнуть заказы в нужной очередности. Но обычно равноправных заказов не бывает, хоть какой-то "приоритет" присутствует, а то запрасто ситуация когда несколько сборщиков выберут самые большие заказы каждый исходя - надо успеть бы собрать... в результате - пришло время погрузки  - ни один заказ на 100% не готов... а начали бы с мелких - хоть что-то уже и было готово... Обычно если приоритеты заказов не заданы и заказы равноправны - первым в работу идет тот который первым свалился в WMS из КИС (обычно такой вариант "по умолчанию" если Заказчик не определил приоритетность равнеоправных заказов.

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

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

продолжаем наши упражнения..
опишу как работает система коммуникации, связывающая погруженного в свои обязанности исполнителя на ТСД с внешним миром.

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

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

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

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

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

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

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

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

(355) "- появление нового задания отмечается звуковым сигналом и системным стикером;"

и что сотр должен сделать? если он в этот момент выполняет другое задание? если он вне заданий и ТСД вообще вне рук сотра...? в чем цель/смысл таких оповщений именно о новом задании? Замена управления голосом от начальника склада/старшего?

(356) "после выполнение незавершенного задания (если так случилось) можно продолжить."
- сотру выдался пул операций = задание = (собрать товар по 10 ячеек), сотр идет, собирает. на середине - половина товаров на палете, половина в ячейках - пауза образовалась (мало ли почему) - херак! сессия обрублена, хорошо если при этом задание не сброшено... Вопрос: где искать товар который изъят из ячеек? задание не завершено (паллета не доставлена в зону контроля/итд)..?

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

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

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

(363) сессия пофиг. речь о "длине задания", задание ДОЛЖНО БЫТЬ ЗАВЕРШЕНО полностью. то есть. сборщик собрал 20 из 20 и отвез в зону контроля. Если сборщик прерывается ("поступило срочное ЦУ, все бросаем идем на упаковку) - добирает текущий "квант" задания (конец отбора из текущей ячейки или конец отбора текущего товара из ячейки) - "говорит" системе - "я = конец задания" - тащит 7 из 20 выполненных в зону контроля, 13 из 20 невыполненные "падают" назад в "контейнер" невыполненных заданий. Товар отобранный из ячеек не должен болтаться неизвестно где, должен стоять в конкретной ячейке (Сам сборщик может быть тоже ячейкой, но это (условно) транзитная ячейка, и пока она не "обнулилась" - никаких других заданий падать на сборщика не должно, это один из возможных вариантов), в упрощенном виде можно без ячейки-сборщика, но задание должнобыть ЗАВЕРШЕНО. полностью или частичнго. как-то так примерно..

так, смотрю, у тебя богато всего нужного, в правильном направлении, гуд! Если на серьезные склады нацеливаться - поменьше внимания рюшечкам/фишечкам типа чатов и побольше внимания концеции "бегунок нихрена РЕШАТЬ не должен"...

Года два еще и норм продукт будет ;-)

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

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

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

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

(369) "бизнес" иногда такую хрень несет в качестве "живые задачи от бизнеса", просто потому что тупо не знает как можно/должно быть по уму ;-) Тут надо осторожно...

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

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

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

(373) задания не могут выполняться несколько дней.
задание - это пул/набор выданных на исполнение достаточно атомарных операций.
в мин.пределе задание - это одна операция.
например: задание сборщику на ТСД = 20 операций (из ячА1 взять 20 шт.товара, из ячБ3 взять 10 шт товара...) или задание погрузчику в размере 1операция: Из буфера Буф1 взять паллету перевезти в Буф77 (можно в задание напихать и несколько операций, но это - как пример - будет ухудшать параллелизм выполненяия операций). При исполнении даже одна операция может в системе зафиксирована как несколько операций - например, операция "изА1 20шт" по результатам выполнения может быть зарегена как три операции - отбор две коробки по 6(1оп) + блок по 3(2оп) + 5шт (3оп) - тут уже зависит от архитектуры как это регистрируется в системе.  
.
а все что "выполняется несколько дней" - оно не выполняется, оно ждет, когда начнетс выполнение. Лежит себе где-нить в "контейнере" туефа хуча запланированных дейсствий (операций) по исполнению всего одного заказа...
.
как-то так примерно.
.
тут видно, что все достаточно сильно зависит в части понимания как что работает - особенно со стороны - в глоссарии что/как значит, термины и определения...

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

(376) это чо там за заказ, что комплектовка пару дней?

Злопыч прав, все будет разбито на атомы, которые в конечном счете станут транспортными упаковками,
Коробка, паллета, фура, вагон

(376) ну, у меня четверо девок за рабочий день мАРКРОВАЛи порядка чуток больше 4 тыс штук. Маркировка - проклейка самопально изготовляеемыми этикетками штук товарв. этикетки печатались на А; (65 самоклеек на листе). На каждую собранную паллету с товаром (это могла быть и три коробки на паллете и больше), стоящую в зоне маркировки старшая по зоне маркировки печатала листы с этикетками - отдельно на каждую паллету - это по факту есть выдача задания на маркировку. 1 паллета = 1 задание. А до тех пор паллеты с товарами тупо стоят и ждут, у старшей маркировщицы - АРМ с перечнем заказов-паллет-итд. Клеили достаточно быстро, маркировка на листах печаталась по упорядочению артикулов, этикетки на каждый артикул отбивались разделителями ну итд. Работали бодренько, еще и болтать умудрялись, руки клеят, а языки чешут. Остатки листов А4 с отодранными этикетками - старшая маркировщица прощелкивала с ТСД (закрытие задания, перевод статуса "выполняется -> завершено". По факту "завершено" - паллета с промаркированным товаром могла быть перемещена уже как задание на перемещение паллеты в зону комплектации... ну итд. Все это зряче, когда задания (печать листов с этикетками) выдается по мере необходимости, а не все сразу... (чем больше атомарность/чем меньше работы с "кучей" - тем лучше видно реальное текущее состояние дел на складе). Но так как почти всегда (редко когда был перегруз по объемам маркировки) колво маркиировки было более-менее сбалансировано с производительностью маркировщиц - старшая по маркировке сразу печатала задания примерно на полдня, а то и на день.

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

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

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

(381) а что есть "зона доступности"..?

(378) оно и разбивается на атомы. но  атомов много. потом все пакуется в компактный обьект - фура)

(383) по типу отбора: вручную/погрузчик, мезонин и т.п.

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

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

(384) а у тебя есть возможность сценарий задать типа
"для клиентов из множества(условиемножества) отбор заводскими упаковкам не менее кратности 12 (или только заводскими упаковками кратсностью = Х) .. типа..?

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

(389) это да, гемора всякого бывает.
.
"регламентов неочевидных" - например (интересно)..?
.
ну, решения часто зависят от постановки задачи. а постановка задачи - вещь неочевидная.. тут и нужна "онолитеги", только не те, которые крыжики в 1С расставляют ;-)

(390) для того чтобы крыжики расставлять тоже голова нужна

эх, бросить все что ли и уехать.. в Простоквашино...
.

(391) кушать в нее, чтобы были силы крыжики расставлять?

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

(393) одна из частых причин завала проектов ерп, это как раз крыжики

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

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

(395) да, причем, крыжики зараза меняются от проекта к проекту: одни добавляются, другие пропадают.. приходится прогу лезть и смотреть что "ОНА имела ввиду")

(398) делай проекты быстрее 🤣

(399) я б рад - работать не с кем.

(400) найми кодеров.

(401) управлять людьми надо любить) я не из этой области)

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

Десятка 3 прогонишь через сито - останутся 1-2...

опишу один из вариантов использования A-WMS Mobile,
а именно, в связке с 1С:Управление торговлей, редакции 11.

модуль интеграции для УТ11 выполнен в виде расширения 1С:Предприятия 8.

в модуле интеграции, в программной переопределяемой части настраивается (программистом) логика формирования заданий для ТСД и обработка данных выполненных заданий.
для обмена с ТСД выделены следующие операции:
- "Отбор", "Размещение", "Перемещение", для документа "Отбор, размещение товаров";
- "Приемка", для документа "Приходный ордер";
- "Проверка", для документа "Расходный ордер";
- "Пересчет", для документа "Пересчет товаров".

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

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

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

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

для определения типов штрихкодов используется мини-регулярка вида: [{МШДШ}][любой символ], где
- "МШ" - модификатор шаблона, ДШ - длина строки;
- для "МШ": "n" - число, "*" - любой символ;
- для "ДШ": положительное число - длина строки, символ "*" - произвольная длина.
Примеры совпадений:
- {n13} = EAN13
- A{n1}-{n2}-{n2} = A1-01-01
- A{n5} = A77777
- A{*5} = A267Bq
- A{n*} = A26777777777777
- пустая строка, {*} или {**} - всегда совпадает
- {} - ложный шаблон, никогда не совпадает

отмечена рабочая нагрузка для одной из внедренных систем: до 100тыс. операций со штучным товаром в сутки, до 100 подключенных единовременно ТСД

новое
- добавлена возможность формировать фото-видео отчет по заданию;
- оптимизирована работа с аппаратной клавиатурой: возможность формирования матрицы клавиатурных команд для применяемых видов ТСД с полным покрытием стандартных действий комплектовщика;
- реализованы все возможные сценарии работы с посерийным учетом для 1С:Управление торговлей 11;
- добавлена возможность проверки типа кода AIM при сканировании.