всех с Наступающим!

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

что уже есть:
1. сделал математику базовых операций: приемка, отгрузка, перемещение по складам, подпитка, перемещение по ячейкам, пересчет, переупаковка, комплектация;
2. входящие заказы на складские операции со статусами исполнения;
3. минимальная отчетность по товару и заказам;
4. база под реализацию механизма тарификации;
5. модуль для мобильных устройств;
6. используется БСП, работа с оборудованием.

планы на ближайшее будущее:
1. интеграция с учетной системой через КД2;
2. интеграция с учетной системой через веб-сервисы;
3. реализация потоковой схемы обработки заказов с минимальным участием оператора;
4. рабочие места оператора;
5. причесывание печатных форм и отчетов;

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

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

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

(100) это норм.\
"у меня отдельно считается остаток по заказу, и осатки по заданиям в работе."
"остаток по заказу" - это план.
может дорастешь что будешь считать остаток по заказу, находящийся в конкретном "татусе".
по заазу = 100, спланировано=100, в отборе = 40, на контроле 30, готово к отгрузке = 20....

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

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

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

(104) на стадии финального задания проверяется логичность остатка в зоне и опционально полное закрытие заказа

(104) "то можно скорректировать заказ, и товар повтснет в зоне отгрузки в свободном состоянии. дальше можно смотреть план на сортировку и формировать размещение этого товара.. по моему уже сделан регламент"
- хорошо но плохо. Представь, что у тебя получилось что на паллете лежит 100шту товара под заказ в отгрузку и на этой же паллете 20 шт свободного остатка. если не отработаешь АВТОМАТИЧЕСКИЙ регламент в этом случае - будут траблы, должно быть что-то типа (навскидку, может быть по разному):
1) - при отгрузке - жмак по паллете - если она заблокирован или на ней есть свой остаток - отлуп по отгрузке.
2) - если на паллете в зоне отгрузки образовался свободный остаток (в результате хз каких действий) - паллету надо блокировать или будет п.1 - надо проверять при отгрузке.
3) - при наличии свободного остатка на паллете отгрузки - генерить план ОТБОРА из паллеты отгрузки на отдельный носитель для последующего размещения.
.
_лучше всего_ по п.1 проверять непосредственно при отгрузке, и если есть свободный остаток (или - это от системы зависит - запланированные операции извлечения свободного остатка) - НА ТСД тут переброс сотра в операцию "извлечения свободного остатка" (без невозможности миновать этот этап). НО! при непосредственно отгрузке такие работы выполнять очень затратно (машины надо грузить быстро), поэтому если есть возможность - операции отбора свободного остатка надо делать заблаговременно. Крайне желательно чтобы система сама автоматом такие задания генерила и отдельно на монитор их и выдача в отбор на ТСД с наибольшим приоритетом.
.
такой процесс геморный, как форс-мажор - отработать нормально. но если это просиходит регулярно (даже нечасто - надо что-то в консерватории править).

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

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

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

"регламентации работы исполнителей"
- что ты под этим понимаешь/хочешь?

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

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

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

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

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

(112) да, понятно. правильно организованный процесс дает правильный результат.
выше лавок и не целюсь.

(114) Проблема в том, что на "лавках" даже правильно организованный процесс без твоего непосредственного участи и пинания сдеградирует почти до того состояния что и было. у лавок нет ресурса на поддержание, даже без развития/совершенствования уже сделанного процесса. Процесс будет деградировать и максимум что можно это максимально замедлить деградацию - жесточашим запиливанием автоматически исполняемых регламентов и жесточайшим начальным дрючением персонала. Вначале какие-то процессы один-два раза похерят и сделают это мимо системы потому что "срочно надо, нам некогда", потом это войдет в норму. ну и покатилось под гору. Будет деградировать медленно только если любое отклонение от регламентов приведет к практически полной невозможности исполнения складской работы. Поэтому или будут придерживаться правил или сразу перейдут на неавтоматизированную работу с ручным управлением. На лавках процесс живет и развивается тогда когда у руководящего состава есть ЧЕТКОЕ ПОНИМАНИЕ что это надо и пресекаются попытки упрощения и обхода.
как-то так..
могу ошибаться...

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

(56) с монитором я разобрался.

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

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

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

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

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

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

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

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

(118) монитор сейчас выглядит так http://awms.ru/img/b_monitor.png
всего 5 страниц, их можно независимо добавлять на Начальную страницу.
надо еще раскрасить критичные показатели и сделать переходы на отчеты-расшифровки.
и уже есть что тащить на мобилу в одноименный раздел

(121) категорически одобряю! понравилось (как вполне начальный вариант). не то что адское бяковое внешний вид МП твоего (может уже и лучше стало? с того молмента как последний раз смотрел).

(122) пасиб)

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

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

(123) ага. МП посмотрю...

(123) блиииин... ну ты бв (0) или в личке писал бы хоть адрес сайта...

(126) сайтов много а я один)
http://awms.ru

(127) посмотрел первые три скрина. Всë плохо. Будет интерес послушать - личку/мессенджеры знаешь, стучись

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

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

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

(131) не в ту ветку написал(

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

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

(133) немаркированная тележка не "потеряется". А вот немаркированная кучка товара - запросто при активной работе.

(133) рассчитывать на оптимистичный сценарий - это так себе подход, особенно там где задействован человеческий фактор - посмотри хотя бы на проблемы, ко орые создаёт персонал при работе с документами. А на складе количество операций с товарами и кучками будет больше чем документов в учёте. Понятно, что всегда выбирается какой-то компромисс. И если незначительное увеличение "стоимости" Операций на складе - на это следует пойти.

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

(0) Так а демка то где? Как ее погонять можно тестово?

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

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

У товаров могут быть сроки годности. У заказов могут быть сроки годности. Типа заказ от сети не менее 2/3 срока годности по остальным заказам пофиг.
У товаров могут быть доп параметры когда этот товар не больше 3 шт в высоту вроде сборщик может его взять, а из-за этого ограничения уже нет. Есть коробки которые должны идти в низ как тяжелые какие то вверх иначе их раздавит и еще куча нюансов. Между складскими ячейками есть какое то расстояние, что с оптимизацией маршрутов?

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

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

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

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

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

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

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

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

(144) Сроки годности есть даже у молотка.

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

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

(146) это да. но оптовику до срока годности молотка или пилы нет никакого дела.

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

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

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

(149) галактеко одобряет! ты продолжаешь строить "велосипед". кому-то пригодится тоже.
"получает распечатку сборочного листа на рядом стоящем принтере" - покатит если принтер один, а если их несколько? у меня на складе например порядка 12 штук иаркодов стояло и порядка пяти А4 - какеой ближайший - определяешь по геолокации? ;-)
м.б. посмотреть в сторону маркировки принтеров и при заказе печати - спрашивать "сканируй принетр" - какой отсканирует - на тот и печатать...

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

у себя печать этикеток делал аналогично.
добавлял возможность клавишами управления курсором увеличивать/уменьшать количество этикеток по 1, по 5, по 10
на тсд оказалось удобнее так количество вводить, чем ьыкать в экран или клавиши на ТСД

(150) там все прозаичнее. на каждое рабочее место с принтером идет свой набор команд. и никто ничего не спрашивает

(151) нет, на ТСД команды не выбираются! каждое рабочее место с принтером имеет доску со стикерами команд (подписанными).
при выборе конкретной команды на стикере, сервак знает какую инфу, в каком контексте, на какой принтер выводить.

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

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

(153, 154) тоже вариант.
(155) "при выборе конкретной команды на стикере, сервак знает какую инфу, " - внезапно у тебя тоже "доступ к компу"..? ;-)

(156) "народ ваще с буклетами штрихкодов ходит по складу" - это от бездуховности ;-)
обычно такое при недоработке логистики...

(157) типо да) но ваще тема с "протяжкой" команд через стикеры через сервак на принтер - тема) давно хотел)

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

(160) ну, это вообще типовая ситуация

..в том смысле что встречается сплошь и рядом

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

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

коллеги-программисты, кому интересно: собираю заявки на тестирование.
формат тестирования:
будет ссылка на подключение мобильного приложения (android, качаем Новое, на сайте) к базе, ссылка на вэб-интерфейс базы для подключения снаружи.
у кого есть ключи - этого достаточно. у кого нет ключей - надо будет договариваться по рдп-доступу.
заявки кидайте на почту [email protected].

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

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

надо сделать рабочее место формирования маршрутного листа, муторно, но надо

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

(166) "либо маршрутный лист частично или полностью расформировывается"
- В клубе джентельменов верят на слово!
И тут мне такая карта поперла...
.
расформировали МЛ сталипо метсам хранения развозить и тут хлобысь нет двух кастрюль на 5000 рублей.
какие претензии к водителю? он на духу говорит "я все коробки на склад отдал!"
.
и тут увстает вопрос - а ПРИЕМКА грузовых мест, которые чтислятся за водителем - выполнялась?! или выгрузили кучу коробок и всё...

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

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

(168) эту тему я понимаю, но мусолить смысла не вижу: есть товар на складе, есть товар у водителя. то что товар водитель сдал - это дело отдельного регламента, я на этом и остановлюсь

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

(168) да, водитель может контролить погрузку через ТСД и передачу товара клиенту, тоже

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

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

(174) крути как хошь.. это да... простор...
https://postila.ru/data/d7/5c/c4/a4/d75cc4a4d2713355faf7ada38208ce228b0313737aa0e6e758ce6e89f006ef0d.jpg

(176) да! НЕТ типовой застройке!)))

(177) долой человейники! каждому - свой скворечник! ;-)

(167) и еще раз да. пока ковырял доставку, сделал одно рабочее место на выполнение операций в зоне отгрузки: упаковка, подготовка к самовывозу, планирование маршрутов собственной доставки.
например, планирование маршрутов выглядит так: http://awms.ru/img/b_tracking.png

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

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

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

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

(181) схема2 обычно когда сроки отгрузки не столь критичные и отгрузка (в терминах нормального склада "отгрузка" это убытие товара за ворота склада, склад более ответственности за товар не несет) выполняется по мере ГОТОВНОСТИ заказов. Садится логист (не хухры-мухры, а целый, блин, ЛОГИСТ) и смотрит - какие заказы готовы (готовность заказа может определяться по разным "критериям", например у меня заказ считался "готовым к отгрузке" для логиста когда он - этот заказ - СОБРАН на 100% (отобран с мест хранения), но еще может быть не проверен, не упакован в грузовые места, не скопонованы паллеты отгрузочные итд - просто потому что если заказ собран, то упаковать/скомпоновать его в готовность к отгрузке - это ОЧЕНЬ БЫСТРО по сравнению с отбором)... "Готовность заказа" логист ПО ОПЫТУ может оценивать и просто по плановой датевремени отгрузки, так как независимо от текущего состояния заказа к плановому датавремени заказы практически всегда полностью готовы к отгрузке.
То есть логист садится, "берет" список заказов (которые уже ранее были скинуты на склад, склад чтото уже обработал, чтото может еще и нет) и "распихивает" заказы по маршрутам/рейсам.
.
Принципиальное отличие схему1 от схемы 2 - в том что в схеме1 ОЧЕРЕДНОСТЬ обслуживания заказов определяется ЗАРАНЕЕ ИЗВЕСТНОЙ ГРУППИРОВКОЙ по маршрутам/рейсам. А в схеме2 заказы на складе собираются по другой очередности (тупо по очередности поступленяи заказов на склад или начсмены уже ЗНАЕТ по опыту (или ПО БУМАЖНЫМ пометкам в заказах) что вот эти заказы скорее всего поедут в однйо машине и эй Петров, ты заказ10, эй сидорова, кидай нахрен заказ15, собирай заказ12 - потому что12 и 10 заказ поедут в однйо машине утром/обед, а 15 заказ вообще самовывозник приедет аж вечером).
.
часто логист работаем по схеме2, но по сути склад работет по схеме1, тупо потому что не автоматизирована выдача заказов в работу согласно "группировке" (маршрутова, ресов, волн итд).

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

ну в общем смысле я понимаю, нет "ощущения в руках")
завтра чирикну в скайп

(184) ага..ага... а когда на складе трэш и угар, а у "№лавочников" это в порядке вещей - начинается еще более подробно..
в первую очередь собираем заказы на рейс "МАН x176щж 77 рус", но при этом в первую очередь собираем заказы на "РогаиКОпыта" и "Алиса" и похрен что они в самой дальней точке маршрута - это суперпупер важные клиенты их надо обязательно, а ИП Пупукин который в начале маршрута - похрен, успеем - соберем в конце сборки, не успеем да и хрен с ним". А в пятницу Алису и РиК - не столь важно, а Пупкина - обязательно! ;-)

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

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

планирую пример реализации обмена с базами на 7.7. возможно будет первым проектом.

все вопросы с виртуальными складами лучше решать на стороне КИС. на стороне складской системы - что вижу - то и пою. никаких виртуальных складов нет.

(187) решается на стороне кис, да, но решается силами модуля интеграции с кис.

(188) складская система ничего не знает про виртуальные склады. и принимает от КИС все в терминах реальных складов и прочих измерений остатков (ячеек, партий, качеств, экземпляров итд). Вся траyсформация виртуального в реальные складские термины осуществляется на стороне КИС при передаче КИС->WMS. Вся трансформация реальных складских терминов в виртуальные всякие хрени при передаче ВМС->КИС осуществляется тоже на стороне КИС.
Нефиг на склад тянуть всякие чисто умозрительные учетные сущности присутствующие только в воображении учётчиков.
.
условный пример.
на стороне КИС есть виртуальный склад "Брак". на стороне склада это будет какая-то реальная физическая/логическая зона, где находится ТМЦ с (условно) измерением "качество = БРАК". А куда пойдет Брак на складе - зависит от того как настроена - может это пойдет в спецвыделенную зону (набор ячеек) специально под "брак". Или вообще брак может стоять в любой ячейке зоны хранения с соблюдением условия "брак не мешать с нормальным качеством".

хотя это все фигня... мышиная возня...

мыши плакали, возились..)) подведу итоги.

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

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

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

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

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

у меня на первом большом складе WMSники уложились за 3.5 месяца, с учетом что под меня ряд рюшечек пришлось дописывать по ТЗ

(192) не забудь ТЗ подписать даже если внедрение "тестовое"... ;-)

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

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

(197) это правильно - тренироваться на кошках.