По итогам темы нужен совет по разработке 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.

Ветка согласована

(0) наличие бесплатных аналогов не смущает?

(2) где такое же есть бесплатное?

(3) Barcode Harvester ака Штрихкод Комбайн

(4) это не такое же, разница в функционале. у меня упор на бесшовное решение для системы адресного хранения, УТ, например.

какие ВК используются ?

(6) компонента одна, сам писал. сделана по примеру драйвера под БСП - чтобы можно было переключаться со стандартной от 1С.
в принципе, ее можно выдрать и использовать, она "чистая".
да, там фича - поиск блютус устройства по имени.

рис 4.3.6 - крыжики M/S это что?

(5) Бесшовное решение не требует принудительных обменов при интеграции. Все обменя для персонала должны выполняться "втихушку"

(7) APK же пересобрано?
Manifest поменян?

android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">

?

(8) маркированный, посерийный учет

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

(13) Аппаратные кнопки?

(9) ну пока что есть. не решил как сделать фоновый поток)

(14) работают через ACCESSIBILITY_SERVICE отдельной апк, события ловятся встроенной в приложение компонентой

(16) Ясно. Нууу, такое, ну ладно.
Но все равно это не отменяет доп разрешения в настройках Ведроида, так?

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

где в главном меню "Приемка"...?

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

ну, как первый двухколесный "Школьник" - пойдет...

(19) это все рюшечки, настраивается. лишние нули.. ну удалю, ок))

(21) на то и расчет. это бюджетное решение.

а как она будет работать со встроенными ШК ? например в авто смарт лайт ?

(20) ACCESSIBILITY_SERVICE требует ручного разрешения для задекларированного APK, или нет?

(24) широковещательные сообщения, либо буфер обмена

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

(27) Да. Это я понял еще 10 минут назад. Этому, отдельному приложению, как даются права на ACCESSIBILITY_SERVICE ? По умолчанию этих прав нет у приложений. Это особые права.

(22) при чем здесь нули?
ну будет у него отражаться 10/2/7 - какую пользу последние два несут для сотрудника рядового?

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

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

(30) События в 1С МП через AddInNative ?

(32) да

(33) Как отлаживал Native C++ ?

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

(34) да никак не отлаживал, там кода почти нет, да и примеров полно.

(35) Аналогично. Мертвая фича

(36) Ясно

(36) это вообще самая быстрая часть разработки - около недели разбирался)

(39) Ну у меня дичь творилась в системе, поэтому я заморочился и подключился мдацким отладчиком в native C++, но потом оказалось, что в java строки надо сравнивать через equal()

(40) о! та же фигня была! но мне среда разработки подсказала почти сразу - легко отделался)))

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

(41)  Вот, кстати, тоже суко неделя
Кто-нибудь отлаживал NDK (С++, неуправляемый код) Android через VisualGBD ?

(41) но я косяк в яве локализовал, в сишном коде нечему было чудить

(41) В 2019 такого умного Android Studio не было.

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

(31) фу, бяка.
мониторить состояние сотрудников и что-то от них "хотеть" - на АРМЕ/десктопе "начсклада".
а не на дивайсах линейных сотрудников.

Кнопочку нажали - прилетел intent,на экране окно Идет сканирование с кнопкой отмена.
Конпку Отмена нажали - полетел intent обратно,и сканер выключается,не дожидаясь taimout-а.
Ну и прочие возможности.
Когда на браузер переключились - у сканера включается режим клавиатуры.

(47) дык оно ж оффлайн, а фоновых нету) но я подумаю)

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

(50) Это ты сейчас с идейным наследником Егора пытаешься диалог построить.

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

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

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

(53) Человек, мне кажется, далек от практики, вот и пишет странные вещи :-)

Вчера запустил систему на небольшом складе: 9 ТСД, эл.оборудование, до 10тыс.SKU. УТ там старая, пришлось интеграцию встраивать внутрь. Наблюдаю пока.
в планах на доработку:
1. я использую один системный сигнал платформы на все случаи, надо хотя бы на завершение задания отдельный;
2. сейчас лицензирование работает на каждый вариант переустановки программы - оказалось неудобно, надо реализовывать свой вариант DeviceId, привязанный к железу. но на выходе вырастет стоимость лицензии;
3. оптимизация рабочего места оператора в модуле интеграции УТ - не нравится реализация журнала заданий, пока собираю статистику.

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

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

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

(58) А мобильное приложение с внешней компонентой может обновляться на смартфоне через публикацию МП или его нужно обязательно собирать Сборщиком приложений?
Сложно было самому разобраться в С++, JNI и JAVA ?
Я вчера поначитался теории, но что-то пока мутно все )
Я так понял, что нужна отдельная IDE для С++ и Андроид студия для JAVA ?

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

(59) Все делается в Android Studio.

(60) для атола и зебры вполне подходит компонента из мобильной библиотеки 1С
Почему решил свою компоненту ?

(62) у компоненты от 1С минимальная платформа 4.4.4 (API 19).
у меня не заработала на зебрах мс36 (API 18): события не ловит никак.
ну и своя разработка дала возможность ловить аппаратную клавиатуру.

вряд ли кто-то без тебя сможет это внедрять

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

(65) После 1Са, похоже что С++ на пару с Джавой и Андроидом это пара пустяков )))

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

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

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

(69) еще раз отмечу, сейчас решение полностью бесплатное.

(68) такое приложение уже тоже есть (бесплатное)

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

(0) я не с тобой работа по сканеру ШК под Андроид?

(71) возможность выбора - это хорошо, это правильно!

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

(73) нет. но внедрение описываемой системы - хороший способ заработать!

(76) опасно внедрять систему, у которой басфактор = 1

всем с подозрением на басфактор - не внедрять!)
добавил возможность выбора произвольных звуковых оповещений по событиям.

Ждем документацию

(78) так кроме тебя и не будет никто внедрять

(79) на сайте есть необходимый минимум мануалов

(80) не увидел в ветке принуждения.
здесь автор стремится поделится своим мнением и его подход к автоматизации склада имеет право на жизнь

Спасибо , посмотрел. Понял почкму бесплатно

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

(84) тут каждому свое: кто то на форуме троллит, кто то работает

(85) Так работай. Но надеятся что кто-то будет внедрять твою прогу наивно

Просто у меня ща написано под тсд, маркировку и ветис, а у тебя там ни настроек архитектуры, ни настроек сопоставления, ни документации

вылысыпыдысты.

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

склад... "модель учета"...

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

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

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

(92) насчет фейса - это да. то что есть сейчас - ужос страшный

(93) немного переделано основное окно и меню задания, глаза не режет.
подниму тему.
на текущий момент работает пара десятков терминалов: один склад и сеть магазинов, реализуется переход на новую программу еще для 30 терминалов на складе с маркировкой.
рекламаций по мобильному приложению пока нет. функционал устоялся, пожеланий на доработку нет - всего хватает.
что есть интересного:
1. серверная часть реализована сразу на хосте(УТ,ERP,КА): обмен работает быстро, админу хорошо.
2. пользователь мобильного приложения использует для входа учетную запись хостовой системы, с ней же мобила заходит на хост - можно использовать функционал РЛС, да и админу хорошо.
3. нет привязки лицензий к оборудованию: бизнесу дешево, админу - ваще хорошо.
4. можно делать разные онлайны: проверки серий, марок, ячеек, упаковок при сканировании, смотреть остатки и цены по товару. включается опциями, логика проверок и отбора данных реализуется на стороне хоста.
сейчас в проработке тема дизайна предложения.
до конца года вернусь к разработке своей хостовой части (сейчас она в виде скелета, без "сладкого") - для формирования полноценного WMS-решения.

(94) тебе до полноценного ВМС-решения - как до Плутона. если и будет ВМС-решение, то оно самого начального уровня. Чуть больше чем "адресное хранение". ВМС решение в первую очередь - это ядро. ахеренное ядро.

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

подниму тему.
на моей системе работает уже больше 50 терминалов: три склада, сеть магазинов; учетные системы - УТ11 и одна самописка, есть маркировка легпром.
система прошла проверку и работает на больших объемах сборок, на многодневных сборках (одежда, обувь, электротовары).
система показывает приемлемую производительность на 300тыс SKU (honeywell eda, atoll s.s, zebra mc).
система воспринимается пользователями нормально, все радуются новым возможностям, отсутствию тормозов при обмене, при падении приложения данные не теряются.
=
модуль интеграции с 1С из свободного доступа убран - это теперь платная услуга.
но привязки лицензий к оборудованию нет и не планируется - в системе можно использовать любое количество ТСД.

(97) мобильная субд еще не сдохла? Можно ли верить вам, джентельмен?

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

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

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

(101) зачем выносить складской блок

?

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

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

(101) ну так переведи вообще весь складской блок на мобилу, зачем вообще тогда сервера?

(106) а офисным за что зарплату платить?!)))

(107) ну, можно еще озаботиться дивидендами учредителей...

(108) работаю работу за что мне платят)

UP

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

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

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

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

при этом доступно сканирование штрихкодов (с вводом количества) и отправка их на электронную почту.
на почту приходит структурированный файл json для разбора средствами 1С.

как включить/настроить:
1. качаете с сайта приложение.
2. создаете подключение с адресной строкой "email".
3. в основном меню создаете тип заданий с произвольным названием.
4. в основном меню создаете подключение к эл.почте.
5. в основном меню создаете устройство (блютус или встроенный, иначе придется вводить товар руками при сканировании, но так тоже можно).
6. в основном меню создаете склад и выбираете его как основной (без этого надо будет заполнять склад через меню задания).
7. в журнале заданий снизу задаете настройки по-умолчанию (проставляете все галки, сценарий заполнять не надо).
8. создаете задания и выполняете, при этом, товар создается автоматом при сканировании/вводе ш/к.
9. завершаете задание через меню задания, задание уходит на почту либо автоматом, если включена опция автоотправки, или по нажатию на кнопку Обмен.
10. на почту приходит файл задания в формате json, он разбирается средствами 1с работы с json на объекты типа Структура и Массив и грузится дальше куда угодно.

в режиме без интеграции доступна работа со сценариями сканирования и шаблонами штрихкодов.

(111) упростил процесс подключения:

1. качаем с сайта приложение.
2. запускаем, в основном меню жмем "Начать тестирование".
3. в основном меню вносим изменение в подключение к эл.почте.
4. в основном меню вносим изменение в название блютус-устройства или создаем новое.
5. создаем, выполняем и завершаем задание (через меню задания), задание уходит на почту либо автоматом, если включена опция автоотправки, или по нажатию на кнопку Обмен.
6. на почту приходит файл задания в формате json, он разбирается средствами 1с работы с json на объекты типа Структура и Массив и грузится дальше куда угодно.

(112) и выложил на сайт пример обработки загрузки из файла json документа "Пересчет товаров" для УТ 11.5

из нового:
- возможность обмена сообщениями между оператором и исполнителем.

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

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

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

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

сколько стоит ? как пощупать

ячеистый склад, ут 11, терминалы зебра

(117) пришлите, пожалуйста контакты на [email protected], я с Вами свяжусь.
пощупать можно на сайте awms.ru/mobile.html, приложение бесплатно-распространяемое, ставится на андроид-телефоны, начиная от 4.3 (API18).
т.к. лицензирование не завязано на устройства, то есть нюансы: выгода от использования начинается от 2-3 устройств.

(118) я сталкивался с зеброй мс36, на них работает

(120) отправил.

(120) zebra tc26

(122) в них андроид 11, с ним приложение работает.
по настройке, надо смотреть утилиту управления, где прописывается идентификатор события.
на мс36 это
Action Name: com.symbol.scanconfig.SCANDEMO
Category: com.symbol.category.DEFAULT
Extra Data: com.symbol.scanconfig.decode_data

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

Коллеги, и сопричастные!
Всех с наступающим Новым годом!
Успехов нам во всех начинаниях!
Больше решений полезных и разных!

(125) ESET ругается на сайт. Проверь, не взломан ли.

(126) спасибо за информацию!
ругается на отсутствие https, пока не подключал.

из нового:
1. немного изменился сайт: появились разделы, переехали на отдельную страницу ссылки на обновления и документацию.
2. тестируется новая версия приложения с поддержкой управляющей системы A-WMS Basis.
пока в загрузках две версии: старая и новая, потом останется одна - самая живучая..

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

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

Не очень понятно -
1. есть ли платные возможности или все бесплатно?
2. Приложение на стороне сервера - это конфигурация 1С, работает на компьютере?
3. Умеет ли приложение работать с несколькими ТСД?

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

(131) приложение оффлайновое

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

1.На скриншоте вижу самописную конфигурацию, но в загрузках ее нет или используется типовая УТ например?
2. Под бесшовной интеграцией понимается отправка из ТСД сразу в 1с и обратно? Сколько стоит бесшовная интеграция?

Так вы слона не продадите.... Если честно - нифига не понятно, хотя я вроде не первый день с 1С. Над сайтом нужно поработать...

(134) 1. самописная конфа - это отдельный проект, он не готов пока.
система управления ТСД работает с мая 22 года. для УТ-подобных конф есть модуль интеграции в виде расширения.

2. понимается именно бесшовная интеграция: все автоматом бегает, пользователь - только наблюдатель.
сейчас ценник на услугу подготовки и подключения интеграции 50тыс руб. для последних УТ,КА,ERP, при этом программа на ТСД не требует лицензий для подключения(не ограничено).

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

Идея отдельного блока мне нравится - тестеры не нужны? Можем у себя развернуть - что то доработать. Как раз что-то подобное нам нужно.

Не знаю, что тут продавать. Такое на раз два пишется. Тока разве что если компонента подключения сканера своя, но она может еще и глючить..... (0)

(127) а зачем он тебе?
список выделять курсивом ....

(138) там реально нет сложностей! пробуйте, и все получится!

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

Так приложуха собранная, где исходники. Что там ставить? Конфы тоже нет, как смортеть то, супер продукт? (0)

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

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

(143) Благодарю.)

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

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

новое.
выложил пример работы с приложением в бесплатном режиме на мобильном телефоне с блютус сканером.

в видео пропущен момент прописывания данных эл.почты, но остальное занимает меньше минуты!
с ТСД, конечно, подольше: минуту занимает настройка утилиты сканирования в режиме broadcast и прописывание события в приложении.
хотя есть ТСД с преднастроенным событием, там все быстрее.

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

ссылки на видео будут тут: http://awms.ru/help.html

(146) нескромный вопрос - видео экрана как снимал ?

(147) на китайской старой трубе хероми утилита встроенная. ищу аналоги, чтоб с ТСД писать, может посоветуете что?

(148) утилита встроенная - apk extractor не берет?

(149) она просто не ставится никуда - ошибку выдает, видно свое апи использует или привязка аппаратная.

новое видео:
пример выполнения задания на отбор по сценарию "Ячейка->Товар->Упаковка".

(151) концепция норм.
интерфейсы и процесс - херня полная. 4 балла из 10.

И по видео вопрос:
1. что значит "отбор групповой"...?
2. какую полезную информацию это несет для сборщика?

qr считает? я в пяти минутах чтоб за пилить подобное в опенсоурс на pwa

(153) назвал так тип заданий в управляющей системе. просто работа по сценарию. это кусок автоматизированного тестирования.

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

(155) пока все что видно как примеры работы на ТСД - трэш и угар.

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

(157) ну оно в живую же как-то работает.. все в нашем мире очень относительно.

(159) сейчас живут три проекта, три разных варианта внедрения, примерно под сотню ТСД, от зебр на 4.4.3, до хонейвеллов на 11-м андроиде.

(160) живут и живут, слава богу.

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

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

при эффективной работе часто вариант "идентификации" товара совпадает сразу с вариантом "взял 1шт" или "взял 1короб из 16шт". Пиплы часто тупят когда щелкают по коробу - прога илдентифиуирует товар - короб уже на рохле - а прога по прежнему показывает ИСХОДНОЕ число сколько надо взять.
.
это просто на подумать/на развитие

может спрашивал уже, сорри если повторяюсь:
надо взять 106шт товара
идентифицировали товар - ТСД даст подсказку "плана набора" типа
план: 106 факт: ...
уп*16 = 6
бл*8 = 1
шт*1 = 2
ю
пикаем по коробам блокам штукам - в заголовке меняется ПЛАН в сторону уменьшения, факт в сторону увеличения
также в плане набора тоже уменьшается соответсвующий показатель. если набираем все блоками взяли 3 блока - прога автоматом пересчитала подсказку
план: 82 факт: 24
уп*16 = 5
шт*1 = 2
.
?
тоже на развитие на подумать

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

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

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

(165) я противник возможности выбора комплектовщиком чего-либо и принятие им решений. работать он должен исключительно по сценарию указанному на ТСД.
сотрудник при отборе имеет регламент административный, если он есть и ограничения налагаемые логикой ТСД.
если сотруднику может быть похер на регламент административный, то ТСД же ему просто не даст просканить лишнее.
в примере сотрудник будет пикать товар, пока система ему не заорет "ХВАТИТ, ДОВОЛЬНО..")

(167) типовая ситуация: учет остатков штучный. но к товару указана возможнеы единицы - шт, блок, упаковка, паллета
учет количества в упаковках - не ведется. то есть на складе Nin? но сколько упаковок, блоков итд - не знаем.

.. соответсвенно операции сборки/разборки упаковкок - нет.

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

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

(169) "будет пикать товар, пока система ему не заорет "ХВАТИТ, ДОВОЛЬНО..")
ну так про то и речь. Только товара на складе нет. есть вполне конкретные физические единицы товара - штуки, блоки, упаковки... и сборщик пикает не товар как некую обезличенную ни к чему непривязанную сущность.
.
поэтому в (173) - как именно будет "пикаться товар"..?

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

(173) .. и тут будем исходить из реальности: персонал сборщиков - это самое низовое звено. меняется часто. грубо говоря умножая в уме 16*6 они запросто могут получить 86 или 106.

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

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

(177) ну так типовая схема, интересно лишь одно - что "видит в задании"? Конкретнее.

(178) это да.

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

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

(182) система не подсказывает ничего, почему так сделано - я указал выше.

коллеги и сопричастные!
предлагаю сотрудничество по внедрению системы управления ТСД "A-WMS Mobile".
со своей стороны я обеспечиваю программную логику для типовых решений и консультирую по работе с системой.

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

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

контакт: [email protected]

(184) до полноценной ВМС даже низкого класса тебе еще топтать и топтать ;-) то что есть - адресное хранение с простейшим функционалом. многим и этого хватит.

новое.
1. выложил релиз (пока альфа) новой версии мобильного приложения, версии 2.
2. выложил модуль интеграции для УТ11. в планах сделать модуль для УНФ.

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

А ещё можно ключ на модуль для ут. Одна организация на ключ. И она же на склад. Два склада - два ключа!

(187) эт зочем? это бюджетное решение, для загнивающего мелкого предпринимателя!

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

(0) дык главное - почем? если я клиентам захочу на их андроиды ставить вместо ТСД? Пиши в личку, есть клиенты.

(190) общая информация. есть две версии:

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

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

сочиняю новый вариант автоматизации: система встроенных мнемонических/цифровых команд.

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

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

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

(191) для моих клиентов дорого 50к. Я делал ценник 5-10 просто за софтину на андроиде, которая по введенному ШК дергает Http-сервис базы клиента. Это цена чисто за софтину для клиента, большую часть денег за нее отдавал разработчику, сам брал за расширение для 1с.

если будут варианты примерно в этом диапазоне дернуть HTTP-сервис через POST, передать отсканированные позиции или по одной позиции дернуть GET-сервер, можно обсудить.

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

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

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

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

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

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

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

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

(199) работать надо с кнопками по наиболее частным операциям - по тем кнопкам, которые есть почти на всех дивайсах. на многих диваайсах есть Ф1 и Ф2, часто бывает и Ф3 и Ф4.
.
ну а дальше будешь очередной лисапет ваять. делать подсистему описания назначения команд на кнопки для разных клавиатур...

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

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

(201) я могу продавать только то, во что верю) ну продавец-двоечник, чо))

(203) Во всех книгах по продажах, это второе или третье правило, чтобы стать топом

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

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

Отбор групповой
Группового чего?
Если просто "отбор" - жто отличается от группового отбора?
Какие ещё виды отборов есть?

(205) видео примеров навскидку не нашёл. Есть видео помощь.

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

Почему на выборе ячейки выдаётся не обозримый список ячеек с общим планом/фактом по ячейке целиком, а не обозримый список ясейка-товар...? Если 15-40 ячеек, в каждой ячейке по 2-3 товара - в чем ценность и практ. Смысл предоставления сборщику озерительного списка на 30-120 строк? Чтобы посмотреть и ох..л?
Сотру надо выбрать ячейку из списка ячеек, а тут блин какие-то товары, да ещё на не, колько экранов.. Нахрена сотра этим грузить? Если уж хочется, что-то полезного то список ячеек с указанием общего веса по ячейке и общей кубатуры по ячейке - это хоть как-то позволит сотру сориентироваться хотя бы какую тару брать...

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

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

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

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

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

(210) ответа что такое групповой отбор так и нет. Чем отличается от простого отбора.

(211) нормально всё описал, тут вопросов нет. А по (209) ответа нет. И позиен выборка жто из базы или список заданий. К представлению на экране это вообще отношения не имеет. Так что вопрос остался без ответа.

(212) это гуд. Сценарии привязываются к чему? К товарным группам? К клиенту (кому-то нужна доп маркировка, кому-то нет) или как?

Пока из того что видел - ядро/арх текстура движется в правильном направлении имхо. Визуализация для сотров на ТСД - близка к отстою. Невзирая на то что "внедрена несколько раз и нравится клиентам". Клиентам которые с ТСД сняли часть своих проблем и ничего не видели - будет нравится всё.

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

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

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

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

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

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

новое

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

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

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

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

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

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

(223) еще нужна инфа гдечто числится/должно лежать = ну это либо абсолютно справочная инфа для размещения товарв при свободном размещении либо как выше говорил - система подсказывает куда класть (исходя из du[ и правил размещения) - так? при чем здесь ячейки по умолчанию для размещения? это ячекйи статически закрепленные за товаром? или что?

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

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

(225) я тестирую новый функционал. тестирую даже на скороварках. суть не в этом

новое

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

2. исправил ошибку при создании задания в режиме тестирования.

новое

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

Jing
До 5 мин нахаляву

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

у вмс крутое:
1. задания на сборку
2. контроль временной сборной площадки (пересчеты контролером)
3. подпитка на основании оборота полок высокой доступности с полок низкой доступности
4. контроль нагрузки на складчиков (сколько кг перетащил в итоге)

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

был не в курсе

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

по "голове", сейчас архитектура позволяет навесить все вышесказанное.
на текущий момент там реализовано основное ядро, которое позволяет стартовать в связке с УТ,КА,ERP или вести учет независимо. ну и дописывать остальное по месту.
вопросы с функционалом будут закрываться потихоньку.

(231) посмотри MyMobiler, только ищи более поздние версии, автор развитие для WinMobile прекратил, перешел на андроид. На винМобпйде у меня работаерт до сих пор - можно делать скрины, писать видео, удаленное управление, файловый обмен. это типа такой radmin для мобильных дивайсов.
.
или же смотри на проги удаленного управления дивайсами

(231) я пишу FasStone Capture? там же есть простенький редактор для вырезания ненужного, вставик надписей в клип итд.
мне хватет, я им уроки для манагеров писал для "сложных" вещей. Но не зашло им. "Тупые" они. Некогда им думать, им трясти надо...

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

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

Подумай в ту сторону, что на мобиле должны реализовываться сценарии процессов, описанные "на сервере"/складские процессы. Так вроде у тебя норм, но езе до серьезного продукта - думать и делать, делать и думать, передулать и передумать.
Например: на любую складскую операцию может быть навешана ИНСТРУКЦИЯ, показываемая переж выполнением операции. Причем инструкции могут быть достаточно разнообразные, например:
инструкция как на контроле (да пофиг где, хоть на сборке) упаковывать:
- инструкций нет;
- (используется если нет инструкции на конкретную номенклатуру) инструкция на номенклатурную складскую группу (которая нихера общего не имеет ни с группами номенклатуры в справочнике КИС, ни с теми же номенклатурными группами тоже в КИС - потому что в большинстве случаев в КИС это - ДЕЛЕНИЕ ДЛЯ МЕНЕДЖЕРОВ. А деление для целей склада - другое, и тут подумать что вообще-то такую номенклатурную складскую группу надо задавать в КИС и это обменом прилетает в WMS/складской контур, или это только в ЦЬЫ/складском контуре задавать)
- инструкция на конкретную номенклатуру.
- ..далее на конкретную номенклатуру/ном.группу для конкретной группы клиентов/клиента - то есть такой некий настраиваемый на уровне без конфигуратора вариант.
и учесть как его показывать на мобиле:
- каждый раз безусловно перед выполнением операции
- по запросу пользователя
- показать один раз в данном "СЕАНСЕ" выполнения операции, далее - по запросу
.
итд итп.
.
привел, кстати, вполне реальный кейс. используется не на одном проекте...

на самом деле все эти ВМС - достаточно "тупые" штуки. в которых просто ДОХЕРИЩА зашито исходных данных, ив хорошей складской системе таких исходных данных прсот охереть сколько если сравнивать с количеством исходных данных, используемых в учетных прогах/контурах.

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

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

(243) запустили - молодцы. Есть возможность пиши в личку в телегу параметры склада, товарооборота, заявок, по персоналу кого, колько задействовано. Набирай статистику. Бери обязательно официальные отзывы о результатах внедрения если дадут, пиши на сайте раздел внедрённых проектов если дадут добро на упоминание ибо не всё фирмы го овы светить квадратуру, клада и ещё какие-то параметры.
Дикий народ у нас...

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

новое

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

2. немного оптимизировал интерфейс для тестового режима.

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

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

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

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

(248) п.2 тут не то что что-то куда-то вверх, куда-то вниз.
.
основное - ОЧЕНЬ МНОГО РАЗНОГО ВСЕГО. не надо на ТСД тащить принципы организации фейса десктопов!!! и мрбильных всяких прог (пункты в которых используются редко) - на ТСД элементы фейса используютяс постоянно. разнообразие в них вредно. выделение тем или иным способом - да, надо. разнообразие - нет. Выделение можно всегда почти порешать текстом, размером, жирностью и иногда цветом.
.
всего элементов немного для песронала быть: типа
1. список
2. кнопка (сюда и кнопки по которым попадаешь в другой скрин и сюда же свякие свернуты-развернутые подпункты - их тоже кнопкой - переход на экран с детальной инфой (развернутой))
3. поле ввода (числа, строки, даты)
4. перключатель да/нет вкл/выкл - тут я не буду настаивать, но я бы делал кнопки ДА/НЕТ, ВКЛ/ВЫКЛ

я и своими-то фейсами частенько недоволен...

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

вот нахрена на экране ОТБОР - пункт меню?
отобр начал делать - есть два варианта - дойти отбор до конца или прекратить отбор - с доставкой собранного к пункту назанчения. всё.

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

(255) п.2 "2. я постепенно ищу оптимальный вариант. но уж очень много функций на этом меню.."
подходи просто. когда человек смотри в экран ТСД - он находится во вполне конкретном месте и работает с вполне конкретным предметом. нахрена ему функции В ЭТОТ МОМЕНТ, которые не относятся к ДАННОМУ МОМЕНТУ? на меню, которые повешено в этот момент можно назначить ВСПОМОГАТЕЛЬНЫЕ ФУНКЦИИ для данного момента (т.е. возможные, но используемые редко). основное - линейный персонал. конвеерный принцип. не надо на ТСД делать "АРМ кладовщика". если таковой АРМ требуется на ТСД - он может быть, но это должен быть совершенно другая отдельная роль сотрудника которую он выполняет. не может он быть одновременно сборщиком и оператолроа (условно). поэтому "ТСД" для "Оператора" - может быть, но это совершенно отдельный фейс с совершенно отдельными задачами. и смешивать эти функции с функциями линейного персонала - очень плохая идея.

(255) п.3 - то что написал в предыдущем посте. пока что п3. - в общем = плохо.
думай сильнее.

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

пока всё. пошел харить кришну.

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

(259) да, тоже надо)

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

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

новое

раздел новостей по продуктам разместил на сайте: https://awms.ru/news.html

новое

1. состоялся первый запуск в работу объединенного решения: системы управления складом A-WMS Basis и системы управления ТСД A-WMS Mobile, в котором максимально полно раскрываются возможности A-WMS Mobile (например, паллетная отгрузка, монитор состояния склада, он-лайн контроль этапов сканирования, онлайн команды управления).

2. собираю опыт практического применения A-WMS Mobile без интеграции. штука полезна в случаях когда нужно быстро сделать пересчет/проверку штрихкодов по товару. для УТ11 механизм разворачивается в течении 5 минут: от установки приложения, до выгрузки шк из 1С на ТСД или мобильный телефон. все необходимое есть на сайте в разделе загрузок.

(265) отписал на почту, если что - можно переговорить и голосом будет

(266) да, на связи

Всех с Наступающим! Желаю профессиональных успехов, личностного роста и исполнения желаний!

(268) Аналогично, коллега!
Особенно творческих узбеков на складе! ;-)

коллеги, хвастаюсь: появился пример использования системы A-WMS для ТСД на складе 20тыс.кв.м в оптовой компании, продающей маркируемый товар: одежда, обувь, с количеством sku ~500тыс. используются ТСД, хонейвеллы и М3. используют свою самописную систему учета товара в ячейках.
отмечу очень высокую скорость адаптации итоговой системы учета к изменению условий бизнеса за счет использования сценариев элементарных операций.
=
одновременно наблюдал внедрение акселот другому оптовику, если коротко - ад. избыточная сложность продукта подразумевает хорошую (дорогую) команду внедренцев и поддержки, нафиг не нужные "обязательные" регламенты ну и веселые пляски в попытках "натянуться" на это вот все.

Сценарии элементарных операций - это тоже избыточная сложность...

(271) как показала практика - все что может быть изменено на лету и своими силами имеет право на жизнь!

десятка два РАЗНОТИПНЫХ совершенно проектов сделаешь - тогда избыточная сложность внезапно превращается в необходимую потребность...
.
ну и у акселота офис большой, кормить всех надо, это не ты в одну моську весь проект. Как будет одновременно проектов штук семь и все надо сдать вовремя и хорошо - "хорошая (дорогая) команда внедренцев" даже без избыточной сложности появится как адская необходимость.. если это рассматривать как бизнес, а не как хобби...

и склад на 20 тыс квадратов может для автоматизации быть проще чем складик в промзоне на 300 квадратов...

(272) И за сколько тыщ., ты это добро к УТешке 10.3 Подключаешь?

(273) я один мало сейчас что делаю, в основном в командах все.
хотя, вот только недавно в одного УТ11.5 на 20 человек внедрил. но буду завязывать с это темой, нервы надо беречь)

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

(275) для неуправляемых у меня нет ничего - все примеры для управляемых форм. есть готовый модуль интеграции для УТ11.5.
можем пообщаться по теме, если есть кому писать.

пока в отпуске, решил начать описывать варианты применения системы. одна из ключевых особенностей системы - Сценарии.
что такое сценарии в системе A-WMS Mobile?
сценарий - это последовательность этапов сканирования в рамках одной элементарной операции.
сценарии настраиваются для каждого вида операции учетной системы, количество сценариев, как для одного вида операций, так и в целом, не ограничено.
нужный сценарий может быть жестко задан в плане задания, или выбран исполнителем непосредственно перед выполнением задания, при наличии доступа.
далее, я буду приводить примеры задач, и соответствующие варианты сценариев.
ЗАДАЧА: собрать товар с ячеек, одновременно распределяя его по коробкам (позаказная сборка).
сценарий: ш/к Ячейки* -> ш/к Коробки* -> ш/к Товара.
выполнение (этапы отображаются у сотрудника на ТСД, после старта задания):
1. "сканируем Короб" - сканируем;
2. "сканируем Ячейку" - сканируем;
3. "сканируем Товар" - сканируем, пока не закончится план по данной ячейке;
4. "сканируем Ячейку" - повторяем пп.2-3, пока не закончится место в коробе;
5. "сканируем новый Короб" - повторяем пп.1-4, до конца задания.

(276) набери меня, как отдуплишься с отдыха

ЗАДАЧА: собрать маркированный товар с ячеек. на товаре наклеены коды ЕАН13 и марки.
сценарий: Ячейка*->Товар->Марка
выполнение:
1. сканируем Ячейку;
далее, до завершения плана в ячейке, вариант а):
2. сканируем ЕАН13;
3. сканируем марку, если появляется запрос;
или до завершения плана в ячейке, вариант б):
2. сканируем марку, если она есть, иначе сканируем ЕАН13.
=======
да, система понимает, что именно она отсканировала, и если это марка, то выполняется попытка разбора марки и определение GTIN.

(279) "ЗАДАЧА: собрать товар с ячеек, одновременно распределяя его по коробкам (позаказная сборка)."
- это не "позаказная сборка".
.
Позаказная сборка - это самый простой вариант - за проход по складу собирается один заказ.
.
То что ты написал - это называется мультипикинг (multi-picking) или кластерный отбор (кластерная сборка).
.
Не добавляй хаоса в терминологию, с этим в области складской автоматизации и так не очень хорошо ;-)

(280) ок, наберу. пару дней надо отмокнуть.

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

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

(279) странный сценарий (или я что-то не понял в очередности выполнения).
обычно это выглядит так (весьма условно):
1. иди к ячейка А1
2. пришел, жмак-скан по А1
3. сканируй товар Т1 30шт
4. положи в коробку К1 (подтверждение если надо = жмак-скан по К1)
5. сканируй товар Т1 20 шт
6. положи в коробку К2 (...)
...
повторяем по всем товарам из ячейки А1 (в одной ячейке может быть несколько товаров) для всех нужных коробок, переходим к другой ячейке.
.
то есть ту ПЕРВОЕ: позиционируемся на ячейке, потом внутри ячейки крутим товары-коробки. По твоему сценарию "сценарий: ш/к Ячейки* -> ш/к Коробки* -> ш/к Товара. - вроде норм, но п.1 - какой-то непонятный.
.
и даже здесь надо смотреть конкретно для конкретного склада - конкретных групп товаров - в приведенном p-sjaft сценарии - из одной ячейки набиваем сначала нужную ОДНУ КОРОКУ всеми товарами, потом переходим в этой же ячейке к набиванию второй коробки. В ряде случаев применяется сценарий "шк ячейки - шк товара - кладем в короб".
.
какой из сценариве предпочтителе в той или иной ситуации - надо смотреть конкретно. В однйо зоне может быть такой сценарий, в другой - другой. Но обычно так не делают, народ начинает клинить... последовательность сборки обычно делают одинаковым порядком, разный порядок может быть когда сборщики закреплены в определенных зонах и редко ходят в другие зоны с другим сценарием...

(285) малость не въехал почему мультипикинг "нельзя" применять с одновременной упаковкой... Может просто ступил здесь я/не понял

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

(288) вопрос по ходу: где/как числиться в адресном хранении товар когда он изъят из ячейки-источника, но еще не попал в ячейку-получатель.?

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

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

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

(289) задание выполняется по плану. план же вешает резерв на отбор по ячейке.

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

(291) и да, я этот сценарий привел: сканируем кучу ячеек и товара и один раз сканируем, куда все несем

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

(290) угу, норм!
пара проектов была когда время сборки экономили адски (риски предупрежден Заказчик), там во время сборки даже короба и товары не сканировали. Скрины я на Т1С приводил.
.
порядок товар-коробкИ или коробка-товарЫ прикидывали с клиентом на каком-то проекте, порешали что в рамках одной ячейки минимизация переключений между товарами во время сборки более предпочтительна чем минимизация переключений между коробками. И не факт что это был выбран правильный/лучший вариант, проводить испытания - ни бюджета, ни времени не было.
.
а когда система позволяет сценарий перестроить для мультипикинга быстро (как у тебя, надеюсь что это достатоно безболезненено такая перестройка) и попробовать пару дней по одному сценарию, пару дней по второму и "сравнить" что лучше - это вери гуд! У себя на клюшках такую гибкость не писал, не те запросы, а в нормальной WMS такие сценарии перестраиваются на раз "администратором WMS" или складским логистом. Проблема в том, что ни того, ни другого х зачастую нет... ;-) на проекте приходится отдельно обучать "админа" WMS...

(292) "упаковка - это часть заказа, товарное место."
- упаковка ОБЫЧНО - это ЗАВОДСКАЯ УПАКОВКА. Стандарт.
.
то что ты написал в разных системах по разному, более употребительный термин = "грузовое место", собранное оно (грузовое место) в дальнейшем по складу ходит ка кнеделимый объект перемещений, отгрузок итд (даже приемка бывает отдельно грузовыми местами, а уже потом по количеству и качеству). Грузовое место также как оно было скомплектовано - может быть и разукомплектовано.
.
"Грузовое место" мне тоже не особо нравится, но это явно лучше чем "упаковка" или "товарное место". ГМ (грузовым местом) может быть целая паллета, на которую во время сборки накидали ЗАВОДСКИХ УПАКОВОК разных товаров...

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

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

(298) да, но мне терминологию навязывают по сути)

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

(299) волна - вообще отдельная тема. для продуктов типа УТ11 она сложнореализуема. но так то, в своей вмс я вариант сделал)

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

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

(302) " тсд оперирует одной сущностью "заказ такой то".
- ну... возможен и такой вариант.
.
по большому счету на ТСД заказов как таковых для исполнителей вообще сущность нахрен ненужная. ТСД - это выполнение конкретных операций. Рулит этими операциями - система. И сама система унтуре себя (там где ЛПЧ-неонка, значит) оперирует всякими заказами/волнами/мультипикнгами/прочими совершенно прозрачно для бегунка с ТСД. Вариации когда на ТСД бегуно что-то конкретно делает с конкретной сущностью "ЗАКАЗ" - это как частный вариант (чаще всего - недостатки логистики складских процессов, ограничения бюджета итд), реализуемый частным сценарием. А закладывать сущность "заказ" - как одно из _ключевых_ явно используемых персоналом на ТСД - это дорожка не в ту сторону куда надо идти при развитии решения...

(306) ну заказ как сущность в сортировке только используется, а так да, оно за кадром - как атрибут задания, максимум.

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

а, вопрос "где числится то, что взяли из источника, но не положили в ячейку-получатель" - остался

(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 при сканировании.