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

Коротко о важном на промо-странице: https://awms.ru/promo2.html

Система A-WMS Basis написана на платформе 1С:Предприятие 8, компактна и имеет простое управление.

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

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

А так же A-WMS Basis - это недорогая лицензия без ограничений на количество подключений мобильных и десктопных рабочих мест.

По вопросам приобретения, внедрения и интересных предложений можно писать:
- на почту info@awms.ru;
- в телеграм https://t.me/awms_sales.

Новости и обновления продуктов в канале телеграм https://t.me/awms_it

Поздравляю

(1) спасибо)

Акцизные марки и иерархию упаковок можете сбоку приделать?

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

Пересчёт товаров
Не видно кто пересчитывал.
Не виден момент времени когда пересчитывали.
На время пересчёта ячейка блокируется?
Что происходит когда идёт пересчёт ячейки, а в этом время план руется задание на отбор?

(5) привет.
1. кто пересчитывал есть на на первой вкладке как исполнитель;
2. на форме не отображается, инфа относится к мобильному модулю, сверху ссылка для перехода на мобильное задание;
3. да, ячейка блокируется полностью;
4. если товара впритык, то будет сформировано задание на частичный отбор, как только появится остаток, то сформируется еще задание.

(0) Поздравляю с  выходом на "коробочное" решение, это большой труд
1. Напишите, пожалуйста, подробное функциональное сравнение с адресным хранением в УТ 11.5
2. Можно ли показать док-обоснование почему у электро клиента решили пилить отдельное решение ?
3. решение в виде расширения к УТ11 или отдельная база ?
4. раскройте Ваше понимание "бесшовная интеграция", что в Вашем понимании "швы" ?
5. какая версия БСП используется если используется ?
6. в какие типовые объекты УТ11 идет накопление информации ?
7. какой товарный/складской функционал УТ11 точно не совместим с Вашей разработкой ?

8. а может заодно и подробное функциональное сравнение с другими WMS - Акселот и прочие

(7) спасибо. и спасибо за вопросы!

1. распишу, надо время.

2. решение сделано не под конкретного клиента - только компиляция опыта (общую историю появления темы можно найти по ссылке в первом сообщении). я предложил вариант, решение принимал клиент. основные цели:
- упростить переход на новую УТ 11.5+ЦРМ, текущая 11.2 сильно перепилена;
- дать возможность использования виртуальных складов в УТ11.

3. решение - отдельная база.

4. хост-система(УТ, например) и складская связаны автоматическим обменом (web-api), работают как единое целое.

5. версия БСП: 3.1.5.171

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

7. писалось с учетом взаимодействия с УТ11, с некоторыми обобщениями. есть то, что просто не доработано: хранение товара в разрезе серий, автоматическое размещение по ячейкам на основе ВГХ.

8. про Акселот - я сам только участвовал во внедрении как консультант со стороны заказчика и писал модуль интеграции его с УТ11. отмечу крайне высокий уровень абстракции модели, что влечет за собой сложность внедрения и разные нюансы, которые приходится обходить костылями. у последних версий (от Ситек) уже свое мобильное онлайн-приложение, много заморочек с настройками. основную мысль я вывел - мелкому-среднему оптовику это не нужно.
да, переход со склада в УТ на A-WMS Basis занял пару дней, плюс пара дней учил оператора. комплектовщики уже работали с мобильным модулем до этого. сильно позже была смена оператора, на второй день человек уже без подсказок работал.

Это перегруз

(6) 2. Какая инфа относится к мобильному модулю? Мобильный модуль не является собственно самОй WMS, с регистрация времени выполнения операции (в данном случае пересчёта конкретного товара в конкретной ячейке или пересчёта конкретной ячейки) имхо должна регистрироваться.

(7) 1. В типовых решениях УТ учётные документы дробят всё мпл че и мельче, заказ- ордер, ордера начинают дробить на задания. - всё раком.
Для WMS всё наоборот. Основная единица - регистрируемая складская операция. А из этих операций уже собирается более высокоуровневые массивы инфы.
Но я не настаиваю на своём видении.

Сравнивать решение ТС с решениями уровня акселота - смысла не имеет. У ТС ВМС скажем так - посередине между начальным и средним уровнем. Но в архитектуру у ТС заложены некоторые хорошие решения, что даёт надежду на последующее правильное развитие. Ещё когда ТС поймёт что нужно отказаться от типовых ТЧ документов - получит ещё плюшек.

Высокий уровень абстракции Акселота и других аналогичных по возможностям ВМС - позволяет выкручивать весьма  замысловатые складские процессы без кодинга, силами одних консультантов.
А то, что проекты внедрения сложные - ну так та  куча времени уходит на реально частные заморочки для данных конкретных проектов.
.
Ну и когда у ТС одновременно будет в работе штук 8 проектов - вот тогда и будет понятно что и где допиливать и какие уровни абстракции вводить.
.
В своё время, когда пилил на 77 для бедных клиентов вмс-частное решение - аж тошнило от адских велосипедов, потому как к тому времени и со стороны заказчика проект большого склада сделал, и потом со стороны вендора пару проектов и как РП и в составе команды. И смотришь на то что пишешь самопально - хосподя, ну когда эти лисапеты кончатся и жлобные клиенты для которых это пилится...

(10) догруз недовоза или довоз недогруза?

Писать ВМС систему, ориентируясь на взаимодействие с УТ - неправильный путь.

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

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

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

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

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

(17) по (14) - как выше писал - вот как будет у тебя одновременно в работе проектов 8-10, тогда и подходы не только к архитектуре рефакториить придётся, но и подход а внедрению будет другой... И за каждую неделю "исследования работы комплектовщиеов" Придётся учитывать в деньгах... И внезапно стоимость внедрения окажется немножко другой...

Но всё недорогое решение для не особо требовательных клиентов и простых процессов - вполне имеет место под солнцем.

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

Но са оп прикольное когда начнётся: зовут тебя чтобы сделать лучше. Ок. как лучше? Мы не знаем, но лучше. Ок. Ходишь, исследует, прикидываешь. А на, вот так будет лучше. - нет, жто нам не подходит, так делать не будем. Спрашивается: а нахера вы тогда меня звали, если позвали специалиста - делайте как специалист говорит, или ипитесь сами... Много интересного вылазит за годы работы... ;-)

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

(21) я с таким не сталкиваюсь, обычно есть конкретная задача, со сроком сдачи "вчера")

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

(23) ну, это не всё время такие попадаются ;-)
.
Были проекты где ит-шный отделы вообще не видишь, один-два раза в начале проекта, потом им АПИ скидываешь - всё делается без проблем.
.
Был проект, где вроде серьезный склад, но блин принтеры этикеток настроить - неделя...
.
Был проект, где логист заказчика (РП), видно что стремается/волнуется, ибо косячки вылазят, но тащит, успокаиваю ибо косяк чисто технический, к завтра исправят, запускаемся норм, довольные как слоны.
.
Был проект где на складе человек 5-6 всего, запускаемся, начало дня туда-сюда, середина дня - сборщики на нервах, а блииин середина дня ещё ничего не собрано, ааа, не успеем, а-а-а-а-а! Сам тоже не сильно спокоен, но косяков нет, консультант сидит рядом мониторит, подсказывает, обучает, говорю: работаем как ведёт система! К итогу дня всё "сходится" Как и должно быть, няшненько. Айтишники потом со складом вроде сами потом на остальных своих складах запустились.
.
Был охеренно тяжёлый проект, еле вытянул, конс помогал сильно, когда я говорю типа все капец ща здохну, конс берёт процесс на себя, вижу конс курит в тяжёлом состоянии - беру процесс на себя. Вытянули. Но потом отходил очень долго, хотелось забыть как страшный сон.
.
Было обследование процессов на складе крупного игрока на рынке, ещё дали молодого конса "на обучение", от заказчика команда-афтишноскладская аутсорсеры, которая потом на внедрение должна была  работать - ребята нормально подкованные, с толикой опыта, тоже непросто было, так как задача стояла обследовать As is, а всё пытались тянуть в сторону To be ;-) ниче, справился, разошлись довольные друг другом, потом эти аутсорсеры хорошо отработали от заказчика на внедрении, успешно всё получилось.

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

Как-то вот так, сорри, на мемуары потянуло...

Ясен пень этот не всё проекты...
Были и личные проекты с разной степенью успешности.
Был и мутный проект где на складе были
- начальника "складского комплекса"
- директор склада
- начальник склада
- складской технолог (с кем можно было что-то делать, но замученный вдрызг).
Проект по переходу с неспрааляющейся ВМС.
Проект - на 3 месяца. После первой недели работы над тех проект ом - я понял что не взлетит. Доложился руководству. Надо тянуть. Тянул. В результате меня с РП после первого месяца руководство сняло, ещё и поменяли ;-) ну и слава богу!!! Ну не люблю я делать чужую работу и общаться с мутными персонами ;-) Проект потом в несколько раз превысил сроки, а я - ПРЕДУПРЕЖДАЛ! Надо было слушать Сергея Михайловича ;-)

(27) Мемуары... ты не конечно не злопамятный, просто злой и с хорошей памятью 😁

(7) по сравнению с УТ11.

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

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

что похоже/совпадает:
- справочные сущности: есть Номенклатура, есть Характеристики номенклатуры, есть Упаковки, единицы измерения, Партнеры, Физлица, Склады.. часть сущностей оптимальна, часть оставлена для упрощения обмена;
- работа с оборудованием, оставлена работа со сканерами, но это к БПО;
- хранение остатков по складам, в целом и в ячейках, по аналогии с УТ, сделано через два регистра, но как сказал выше, логика отличается и своя схема резервирования;
- поддержка упаковок;
- совпадает часть логики работы с номенклатурой и штрихкодированием, но сервисные обработки свои;
- остальное похожее исходит из БСП.

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

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

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

мои клиенты:
playtoday.ru - производитель популярной детской одежды и обуви;
энергия.рф - производитель электротехнической продукции.

общая автоматизированная площадь превышает 25тыс.кв.м.

прошедшая в сентябре выставка CeMAT RUSSIA 2024, на участие в которой я был любезно приглашен компанией ТопЛог, показала высокую востребованность IT-продуктов нижнего ценового сегмента для управления складскими процессами. поддержим мелкий бизнес, ему сейчас сложно!

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

(35) я за вами слежу!

(36) наше Вам огромное спасибо за контакты)

новое!

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

Ахаха

(0) Если есть УТ11, зачем она нужна ? ТСД поддериваются

(40) спасибо, поржал.

(40) ответ аналогичен (39)

многим и УТ11 хватит.

(39) на "заставить склад работать" ценник в прайсе указан)

(41) Чо поржал то ?

(44) да ты сегодня в ударе, не пятница же

(46) идет много запросов типа "хотим склад, но что так дорого?". вот, подстраиваюсь под ситуацию.

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

(47) найми продажника

(49) это в процессе, но пока что есть

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

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

(52) "успешно находят" - где, в КИСе? ;-)

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

и ничто В ПРИНЦИПЕ не мешает в КИСе работать аналогично без перекосов. Просто тем, кто работает в КИСе - это нафиг не надо, "тут так заведено".

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

(56) ну так где косяки по узким местам? В КИСе или ВМСе? кто косячит?

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

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

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

(60) "ой не туда, отменили, "
- ну, по идее должно быть по отмене в КИС в складской системе сформироваться задание на расформирование или что-то похожее.

(0) Заинтересовала система, при первичном ознакомлении возникло несколько вопросов:
1. Учет сроков годности товаров - реализовано?
2. Можно ли из собираемого товара сформировать грузовые места и можно ли указать вес/габариты этих мест для дальнейшего использования. Будут ли эти данные в каком то виде доступны в КИС (УТ/ERP)

3. Можно ли где то более подробно ознакомиться с возможностями блока учета отгрузок? Или, ставя вопрос шире, как то можно полученные грузовые места (если на второй вопрос ответ положительный) состыковать с каким нибудт модулем TMS, например 1С:Предприятие 8. TMS Логистика. Управление перевозками?

(68) 1. да. есть пример работы с сериями в связке с ERP, КА или УТ.
2. да. есть механизм обратной трансляции вплоть до единиц собранного товара.

(69) могу демо просмотр организовать через энидеск, например.
по интеграции с ТМС не вижу проблем.

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

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

Да, будет интересно и посмотреть и пообщаться. Но немного позже, когда у нас определенность с КИС появится. Мы сейчас сидим на самописной и самобытной конфигурации на семерке, есть желание перейти на восьмерку, сейчас в стадии изучения и принятия решения. В целом понятно что это будет УТ или ERP (так то нам УТ в целом достаточно, но заинтересовал блок бюджетирования в ERP, ради которого выбор в его пользу возможно склонится), пока нет определенности со сроками. Уж больно грандиозная задача :)
Для реализации склада ваша WMS показалась интересной, в силу относительной простоты. Сейчас есть адресное хранение, но на довольно простом уровне. Сам склад 2тыс м2, 15 ТСД, порядка 6тыс SKU в наличии на складе и порядка 150тыс в оперативной работе (под заказ).

(73) Меня вгх не товара интересует (с ним функционал УТ понятен) а получившегося грузового места. Мы заказы упаковываем или в двп-ые ящики (25 типоразмеров) или паллетуируем или просто в картонные короба. И фиксируем получившиеся габариты/вес. Вот это и интересует, как это организовать в УТ или внешнем WMS модуле.

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

(74) я параллельно УТ11 внедряю, мелкие объемы сам полностью, крупнее - в команде, как архитектор. могу как минимум что то подсказать. напишите контакты на почту, я с Вами свяжусь.
по WMS сейчас один из проектов более 5тыс.кв.м рулит, на трех территориально распределенных складах.
(75) там вариаций достаточно много, это по месту решается. базовая механика заложена.
(76) тоже заложена базовая механика, как по текущей загрузке, так и по производительности/тарификации.

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

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

отмечу, что идет параллельное развитие связанного продукта для управления ТСД - "A-WMS Mobile".

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

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

(79) "расширен функционал работы с сериями, сейчас он покрывает возможности модели УТ,КА,ERP"
- появится какой-то новый вариант/новая типовая (а УНФ как?), где модель не похожа на УТ/КА/ЕРП - и будет ЖПС...
.
Непонятно, АWMS - самостоятельная система или функциональный блок для типовых? Если самостоятельная система - то пофиг на модели всех типовых... - работа с сериями на складе в рамках ВМС должна покрывать большинство процессов обработки/использования серий. А как это потом транслируется в модель типовых конфиг или других систем КИС (не обязательно 1С) - совершенно пофиг

И интересно было бы услышать от разработчика - что понимается под серией в его ВМС (не привязываясь к терминологии/моделям типовых)...?

(82) серия, партия, экземпляр - дополнительная аналитика к товару

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

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

дополнительная аналитика чего? для чего? остатки в разрезе доп.аналитик?

(80) эта модель делалась почти 20 лет, куда она денется?
то что сейчас сделано в УТ/КА/ЕРП, на мой взгляд, закрывает все вопросы.

система самостоятельная, подключиться можно из любой конфы (web-api), просто не используем не нужное.
но модель учета оптимизирована под УТ/КА/ЕРП, т.к. типичный заказчик уже работает в УТ или на стадии перехода.

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

(85) для учета товара в разрезе серийных номеров или партий поступления

(87) Чем учет в разрезе серийных номеров отличается от поэкземплярного учета?

Какие варианты работы по серийным номерам поддерживаются?

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

(30) ууу.... без маркировки сейчас никуда :(

Мы вот готовимся сейчас внедрять конвейер на склад и зависли с честным знаком.
Как лучше на таких складах проверять корректность марок?
В момент "пика" ТСД сборщиком - малореально, всё равно задержка будет.
Пока коробка едет до зоны контроля? А если не успеет пройти проверка?
Что делать в случае недоступности ГИС МТ?
Кто-то скажет - проверяйте на приемке. Так и делаем, но не поштучно, а часто бывают пересорты в коробах. Плюс, во время хранения какой-нибудь "умный" участник оборота может перетащить марки на себя, или вообще вывести из оборота.

(91) А  подумать?

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

(91) " Так и делаем, но не поштучно, а часто бывают пересорты в коробах."
- прям вот от всех поставщиков идет такая беда?

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

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

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

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

(98) B как решили?

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

(100)  регистр сведений - в твоей WMS?

(101) не в предлагаемой. тоже мое решение, но более раннее. оно сейчас обслуживает 20тыс.кв.м на одежде, мобильные рабочие места на A-WMS Mobile.

(100) (101) "регистр сведений, в него пихаются все марки по текущим операциям,"
если марки по текущим операциям регаются в ВМС, то откуда ВМС вообще знает - валидная это марка или нет? например, можно вообще эту марку на приемке принимать (а если она вообще уже по какой-то причине выведена из оборота)? Отгрузка, например, установлено контрольно-надзорными органами что партия марикрованная марками - контрафактная и вся партия "стопорится" в ЧЗ (условно) - откуда ВМС будет об этом знать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

понятно.

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

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

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

(124) про что?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

новое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

о!! дикий офис, шустрые карапузики!! надо запомнить))

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

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

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

(206) +100

(208) +100

хроника внедрения (продолжение)

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

осталось дописать код под регламенты.
в планах запуститься 3-4 апреля.

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

(211)

(212) от слова "обклейка" меня мутит)))

Маркировка

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

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

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

(218) У богатых свои причуды (с) Народное

(214) согласен.

(219) ну, если есть возможность маркировку (КИЗ) наносить на этапе производства - то почему бы и нет. это экономит кучу ресурса.

(215) не, не пойдет. Маркировка плотно ассоциирована с ЧЗ, ЕГАИС и прочими изподвыпердами.

хроника внедрения (продолжение)

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

(217) У нас с осени начинается поштучная маркировка БАДов. Все расхождения кодов - через УКД и УПД-И. Размер геморроя просто непредставимый! Как решали эту проблему?

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

(224) решать надо проблему, которая приводит к "расхождению кодов".
Откуда берутся эти расхождения.

(225) поддерживаю...

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

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

(225) Весь гемор - в КИС и стыке с WMS. И общении с аптеками, которые от УКД и УПД-И отмахиваются как черт от ладана.

(228) Хочется сделать максимально просто для претензионистов. Вариантов работы много:
- покупатель утвердил УПД - одна история, одна цепочка ЭДО
- не утвердил - другая
- неправильное количество - третья
- неправильная сумма - четвертая
- И сочетание последних двух с первыми двумя
- Туда короб - обратно штуки и т.п.
- А если короб - в нем возможен заводской пересорт
И кто-то всё это должен разгребать.

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

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

(230) нет там никакого гемора.
Рсоыт писал и ч напишу
1. Не надо тащить в вис то, что не пасается физической обработки товара.
2. Если вы на приемке не отрабатываете приемку так как надо а потом плачетесь - ссзб.

(231) заводской пересорт - вещь редкая и погоды не делает.
Если производитель - говно и пересорт идет постоянно - это отрабатывается на приемке. Для этого давным давно кейсы отработаны.
.
Для "тупых" - на приемке экономить НЕЛЬЗЯ! При нормальной приемке - остальная складская работа - это простые технологические операции где не надо никакого ума.
.
Экономите на приемке - ип..сь с корректировками, возвратами, первичкой, кучей бухов и прочего. Ссзб.

(231) еще раз. Облегчать работу отделу претензий - да, полезно и нужно. Но это задача даже не второй очереди. Не в ту сторону смотрите...

хроника внедрения (продолжение)

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

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

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

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

(239) ну так первый совет после предварительного экспресс-осмотра склада - отделу кадров тихим сапом готовиться к смене 80% линейного персонала (это в особо запущенных случаях)
;-)
Мой мелкий опыт показывает - при нормальной автоматизации склада - всякая шушера вымывается со склада достаточно быстро, а те кто нормальные работяги - они и дальше нормально работают. Еще и прибегают - когда на промзапуске сидишь или при работе надипроектом на складе заказчика - они еще и ценную инфу притаранят бывает и прибегут с типа вот здесь херня какаято, смотришь - действительно херня... Но это у меня обычно на складах с относительно небольшим количеством бегунков, человек до 15...

Правда сейчас со складским персоналом пишут что напряг. Курьерстово/доставка многих вымыла...

А как оно на больших складах - хз...
На этом проекте сколько на складе бегунков?

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

(241) ну почему то да, проблема. тут тоже: нужен контролер, а то и пара - кадры мнут тити месяц уже

(242) 9 - первый этаж, еще 4 - 2 этажа мезонина, итого 13 комплектовщиков. плюс водители 2, плюс один пока контролер, плюс 2 приемщика.

(244) в контролеры переквалифицировать самого умного бегунка.

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

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

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

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

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

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

(252) куча мусора в том смысле что остатки того чего нет?
Или что?
Интересно.

(253) раздел ком.тайны. работают, но дохера нюансов.

(254) ком.тайна. ну конечно. Уникальные процессы типа здесь играем, здесь не играем, здесь рыбка лежала ;-)

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

новое

тестирую модель автоматического размещения товара в ячейках.

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

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

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

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

Что такое неконтейнерное размещение?

Какая разница по перечню форматов ячеек? Будет их н типоразмеров или 50.. В чем ограничение?

Статистика размещения товара в определенный формат - типа товар 10 раз размещался в типоразмер1 и 50 раз в типоразмер3?

.. Есть накопленная информация о количестве?
Типа что в ячейку типоразмера3 входит 10 штук товара?
Учитывается ли что вместимость ячейки по количеству припересчете в базовые штуки будет разной если товар размещается поштучно и заводскими упаковками..?

Суть (257) пока мутновата. Толком не понял что и как...
Разверни баян пошире, без углубления в техподробности, а концептуально.

Стандартно есть два варианта расчета размещения в ячейки (будем говорить о монотоварных ячейках активного хранения (ячейки ручного отбора)).

1.Размещение на основе вгх ячейки и вгх товара. Требуются исх.данные по типоразмерам ячеек и вгх товаров. ВГХ товаров считываются/задаются обычно на этапе приемки. Есть варианты когда вгх товара известны (например, пришли из КИС), но требуется единожды верификация при приемке.

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

2. Вариант когда вместимость задается по принципу: товарN в ячейку ТипМ помещается в количестве Хшт, YупаковокА, ZупаковокВ
Такой вариант требует большого количества задания исходных данных и расчет такого количества вместимостей разных упаковок для исходных данных неочевиден и трудоемок. Но вполне работает, если данные потихоньку вводить по мере работы

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

Например, товар 50 штук. Сотрудник разместил 40шт в яч1 и 10 шт в яч5 (одинаковый типоразмер). СКОРЕЕ ВСЕГО в яч1 максимально возможное количество раз размещение пришлось раздробить. Во время размещения статистика скорее всего не обновляют.

Короче, непонятно что и как. Ждём баян

(258) навалом, без упаковки(контейнера) ))

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

Остальные вопросы автор не пояснил.. Шифруется...

(258) навалом, без учета какой-либо агрегации.
(259) один смысл - не бесконечное количество.
(260) максимальное количество в ячейке, с учетом возможных ошибок размещения.
(261) если товар учитывается на остатке в разрезе упаковок, то упаковки учитываются и в механизме размещения.
(267) данные по размещению обновляются оператором(предпочтительно) при первичном размещении. сам порядок комплектации указывается в п/ф заказа на приемку, выдается приемщику.
(270) чтобы учитывать упаковку, на ней должен быть ш/к и его надо иногда(товар чужой) наклеить. так вот, при высокой оборачиваемости, процедура обклейки ВСЕГО получается достаточно дорогая и клеят минимум этикеток. поэтому возможны варианты: учитываем или только штучно ( итоговое количество по кратности считаем руками), или клеим основные короба (кратность определяет сам тсд). поэтому, если можем - клеим все, штуки и все короба. если не можем - имеем некоторый компромисс.
(271) я в отпуске еще, весь день дорога иногда случается.

(272) по (261) - например, товар НА ОСТАТКАХ в разрезе упаковок не учитывается. Но это не значит что заводскую упаковку, которую приняли на приемке, следует рассчитывать сам факт размещения как штучные товары. 100 indr товара - по ВГХ в текущее свободное место в ячейке могут влезть, а упаковка 100 штук - может и не влезть... или даже наоборот... ;-) часто товары сложной формы в упаковке занимают меньше места чем навалом ... Но это так, чисто замечание на "подумать"

(272) по (270) и часто идет заводская упаковка хотя бы даже без штучного ШК на упаковке? дешманские товары из китая?

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

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

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

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

(277) ну так-то конечно. А закупщики поставщика нагнуть не могут по одинаковости шк... Допа со всех сторон, никто низера сделать не может, только автоматизаторы. Ща тарелку супа.

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

немного рекламы для поднятия темы.

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

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

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

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

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

новое

добавил документацию (ссылки есть на странице продукта):
1. Описание конфигурации A-WMS Basis: https://awms.ru/docs/b_description.html
2. Описание интеграционного решения A-WMS Basis: https://awms.ru/docs/b_integration.html

новое

добавил раздел блога и пару статей:

1. перечисление ключевых особенностей продукта:
https://awms.ru/articles/promptresponse.html

2. описание технологии типового внедрения:
https://awms.ru/articles/smoothintegration.html

(282) дешево - это когда Китай дешманский.
Лучше синоним "недорого"?

(283) в том контексте нормально, выражение устоявшееся

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

(285) учтем

новое

добавил FAQ по продукту: https://awms.ru/docs/b_faq.html

немного помусолил тему про внедрение своими силами: https://awms.ru/articles/freeintegration.html

(287) Напомните, пожалуйста, как в вашей системе организован учет себестоимости хранимого и организован ли? Или товар хранится исключительно в количественном эквиваленте?

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

(289) Спасибо. А Ваша система позволяет получать информацию по остаткам не только в разрезе МОЛов (кладовщиков), но и Ответственных держателей (лицо, отличное от Мола)?

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

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

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

новое

добавил размышления на тему причин необходимости перехода на WMS: https://awms.ru/articles/whywhywhy.html

(291) Учет по МОЛам может вестись не только когда нет возможности разделить учет по складам. Например его используют, когда на складе есть разномастные товары, например: крепёж, тросы и запчасти. Все хранится на одних и тех же складах, ячейки для хранения выбираются в зависимости от их заполненности (на одной ячейке могут лежать и гвозди и уплотнительные кольца для компрессора), но за каждую группу отвечает свой МОЛ (он проводит инвентаризации и т.п.). Причем один МОЛ может отвечать за товары одной группы не на одном физическом складе. Поэтому эти два параллельных учета могут использоваться одновременно.

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

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

(295) какой регламент у мол, когда его товар "потеряли" на полках? кто платит?

но в общем смысл понятен: совмещение приемщика и ответственного за ассортимент.

(291) на сколько понял вопрос, учет товара в разрезе МОЛ нужен когда нет возможности делить учет по складам.

Нет. Учет товара в разрезе МОЛ, это возможность посмотреть остатки по МОЛ. МОЛ - материально ответственное лицо, отвечающее за хранение этого товара.

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

МОЛ и Ответственный держатель - это разные лица. Первый - материально отвечает за хранение. Второй - отвечает за все оставшиеся вопросы.

Еще вопрос к вам: допустим к вам на склад ("складскую территорию") пришло некое ТМЦ. Далее, оно со склада уезжает в его место эксплуатации. Я правильно понимаю, что классификация ТМЦ в этом случае определяется элементом справочника "Склад"?

(296) смотря как "потеряли". Товар может пропасть с ячейки, например, если была ошибка сборщика, и он пробил код одной ячейки, а взял товар с другой. Тогда этот артикул попадает в контрольный лист. Он числится "условной недостачей". При инвентаризациях (они бывают по артикулам и по группам ячеек регулярно), такой товар обычно находится через некоторое время (есть алгоритм расчета, показывающий, за какое максимальное число инвентаризаций товар найдется). Потому как при обоих видах инвентаризации сканируются коды всех коробок в проверяемых ячейках. Только при поартикульной не все заносятся в ведомость. Если контрольный срок прошел, а товар не найден, тогда признают как реальную недостачу. Если реальная потеря, но без криминала (например сборщики ошибочно взяли три упаковки вместо двух, а покупатель не сообщил о излишке) - тогда распределение суммы, часть на МОЛ, часть на бригаду сборщиков, часть на бригаду кладовщиков (они размещают товар при приемке и перераспределяют товар чтоб пополнить более близкие к зоне сборки секции израсходованным товаром). Процентовку назначает начальник склада после расследования (там все равно далеко не 100% покрытие недостачи, а только уменьшение премии на некую сумму в несколько процентов от стоимости, но не больше 25% от премии).

(297) у вас "Ответственное лицо" появляется если товар привезли не в общую "кучу" а под конкретный заказ/проект? Т.е. товар сразу резервируется и взять его никто не может?

Поменьше тащить в складской учет в WMS всякой аналитики, которая не относится к товародвижению тмц внутри склада.

Тот же "ответственный держатель" - сущность его так и не понял. Критично для "ответственного держателя" что "его" товар стоит именно в ячейке А1...?

Может всё-таки речь идет, как выше отметили, про некое "резервирование"..?
.
В WMS могут выделять разные стратегии "резервирования" (в. т.ч. тмц резервироваться может уже с приемки, в т.ч. и резервирование запаса на местах хранения). Резервируется по разному: и под конкретные заказы, и под конкретного клиента, и под группу клиентов, по направлениям деятельности (резерв сетевого обслуживания итд), итд.

(301) что "его" товар стоит именно в ячейке А1.

Нет. Что его товар - на таком-то складе. Если это его имущество - оно там-то. И т.д. В какой конкретно ячейке/паллетте и т.д., его не интересует, конечно.

Сущность его так и не понял.
Это нормально, я перед собой и не ставил цели Вам что-то объяснить. Я же для себя выясняю детали, а не для Вас.

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

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

По МОЛ - сколько делал и видел - такого не встречал. Может гдето и надо. На складах под управлением WMS хранение товара обеспечивается не участием МОЛ в каких-то процедурах, а следованием установленным регламентам и работой системы.
.
Что будет если МОЛ внезапно заболел?
На нормальном складе это никак не повлияет на работу склада, ну может поначалу немного тормоза будут, пока другой со рудник притрется к специфике данного товара.
.
Чаще, проведя зонированин склада и складских групп товаров, за зоной закрепляется со рудник, который работает преимущественно в закрепленной зоне товара и лучше знает специфику обработки товара (условно при сборке товара для вот этого тмв его надо брать вот таким образом чтобы было удобно/быстро).
.
А назначение не кольпих "мол" на одну ячейку микс товара на мой взгляд как и выше отметили приведет к конфликтам, скорее всего скрытым. А за хранение "отвечать* не надо. Когда на зону закреплен сотрудник - он обеспечивает в своей зоне порядок, хранение итд.

В развитых WMS на любую складскую операцию/процесс можно назначать сотрудников. Если надо - на складскую группу товара (изоленты) или на произвольный набор тмц можно назначить конкретного сотрудника. Эти Задания на инвент будут выданы только ему и никому другому.
.
Или по складу постоянно бегает по заданиям системы группа "контролёров", которая постоянно занимается устранением проблем, зафиксированных в системе, инвенты, поиски "пропавшего" товара, выемка брака итд...

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

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

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

Если это важно для обслуживания заказов покупателей, например, то надо очень сильно думать, какую часть управления товаропотоком следует возлагать на склад, а какую часть на КИС. Если для обслуживания заказов менеджеру надо знать что у него под боком, а что придётся везти с другого склада на центральный - наверное такой разрез учета разумнее вести в КИС.
.
Для внешнего контура - с которым взаимодействует склад - WMS в первую очередь исполнительская система (в примере выше вмс как исполнитель получит от КИС несколько заданий, одно задание для центрального склада, одно задание для удаленного склада, сюда же еще подключится тмs для доставки с удаленного на центральный) Попытки переложить на WMS задачи планирования, касающиеся того, что находится за воротами склада - надо очень сильно думать, а стоит ли специализированную систему нагружать несвойственными ей задачами).

С покладелателями бывает много заморочек.
По сути одна контора, но куча ИП. Каждый ИП - поклажедатель. Ну вот так вот внешний клиент-поклажедатель договаривается и ничего более знать не хочет.
А потом начинается - пришел заказ по ИП Петрову, но товара на нем не хватает. "Ну возьмите с Иванова!" - хрен там! Нужно как-то товар Иванова превратить в товар Петрова, ибо когда начнутся разборки по недостачам/потерям товара поклажедателя - за все придется отвечать копеечкой. И начинаются в WMS танцы с бубнами...

(304) это понятно и для WMS это рядовая задача. Потому как вполне достаточно не торговых складов, а складов (условно) МТО.
И где/чье/где лежало/как перемешалось (критично может быть и температурный режим и соседство с другими тмц) - определяется вполне конкретным Физическим атрибутом (штрихкод, маркировка партии, и прочее что может быть). Под партией может пониматься и примеряться разные варианты - это может быть и производственная партия, и партия по конкретной приемке, и партия по конкретному ГТД которая заходит на склад в несколько приемов, вплоть до поэкземплярного учета). И в разрезе таких признаков можно посмотреть что надо. Независимо от того, что еще вчера "ответственным держателем" был менеджер Вася (или площадка буровая23), а сегодня это уже петя (и буровая17).
.
Это все должно определяться на этапе техпроекта на вмс, все значимые особенности.
.
В одном проекте прослеживаемость на всех этапах требовалась вплоть до поставщика и конкретной поставки, где склад мто был всего лишь одним звеном ОКР военки. Что там дальше было - не знаю, бо сразу отпихнулся всеми руками и ногами, видя что там не "складской учет наладить надо" (как озвучили), а там - надо сделать ВСЁ (при том, что в УПП там внешними силами только какой-то фискальный бух учет удалось осилить).

(309) а стоит ли специализированную систему нагружать несвойственными ей задачами).

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

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

И склад, и помещение - это место хранения ТМЦ. Они никакие "не внешние", относительно вашего предприятия.

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

Задача любого складского хранения/обслуживания - сократить до минимума срок хранения. Тут и балансируют между этим показателем и всякими страховочными запасами итд...

(313) Если вмс управляет складом

Моим первоначальным вопросом, я и пытаюсь это выяснить у ТС. В рамках его конфигурации, возможен только учет материала/товара, принимаемого на складе? Кстати, по поводу Вашего замечания в (311):

"И в разрезе таких признаков можно посмотреть что надо. Независимо от того, что еще вчера "ответственным держателем" был менеджер Вася (или площадка буровая23), а сегодня это уже петя (и буровая17)."
Именно таким "признаком" и является Ответственный держатель. Если Вы обратили внимание, то ТС обозначает аналитику хранения остатков как "склад, ячейка, агрегация(контейнер), товар, партия.". Но в рамках одной партии могут быть разные ответственные держатели. Именно поэтому и интересуюсь.

(297) про мол, я ответил исходя из контекста, а так да - Вы правы.

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

сам справочник Склады используется как:
- сквозная аналитика для учета товара;
- как отправитель/получатель товара по заказу в случае перемещений, производства и т.п.

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

(316)(317) спасибо за ответы.

а в каком виде приходят задания на выбытие?
Как заявка на получение ТМЦ. Конечно никакой МОЛ (кладовщик) в ней не указывается, т.к. эта информация и не известна даже, её нужно как-то вычислить, и не понятно - зачем? Если ты знаешь, что твое ТМЦ - тут, то ты оформляешь заявку на получаение этого, идешь и получаешь. МОЛ (кладвощик) здесь не нужен. Однако держатель (владелец), конечно хочет видеть - сколько и каких ТМЦ на нем числится.

"то привязку делаем только в партиях."
А Вы можете привести кейс, по моему примеру, как сделать "привязку в партиях"?

Допустим, есть одно приобретение, оно заезжает на 1 склад. В этом приобретении, допустим 10 товарных позиций. Я хотел бы их привязать к 3 разным ответстветнным, при этом одна номенклатурная позиция, вполне может иметь 3 ответственных (в случае, когда каждая штука идет на своего ответственного).

Что нужно вашей системе сделать, для такого случая?

(318) а не основные ли это средства?

(318) 1. добавляется реквизит МОЛ в справочник партий ("Серии номенклатуры")
2. определяется регламент привязки МОЛ к партии. проще всего в качестве мол регистрировать пользователя ТСД, который выполнил задание на приемку или выполнил задание по регламенту формирования контейнера.

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

(320) с МОЛом я понял, спасибо. А с владельцем (ответственным, держателем) как быть? Его есть куда вписать и так же прощить вместе с серией по всему учету?

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

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

(322) то привязываемся к партии.

А можете какой-то скрин показать, как это у Вас происходит?

Есть 1 партия, там 1 товар в кол-ве 3 шт. Я хочу повесить его на Иванова, Петрова, Сидорова (это не молы).

Можете показать на скрине, как это мне через партию сделать у вас? Если я правильно все понял, конечно же.

(323) показать сложно, подобного кейса пока нет.

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

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

(324) Спасибо.

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

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

(321) если !!единовременно!! у одной или  несколько экземпляров товара только один ответственный держатель - например используйте механизм ответственного хранения с указанием поклажедателя = ответственный держатель. Ничего дописывать не надо в ВМС. Другой вариант: используйте ид партии (например, номер производственной партии) как "держатель".
.
Можно в качестве ответственного держателя просто держать в ВМС резерв на клиента=держатель.
.
Можно в качестве держателя использовать "категорию качества" для ТМЦ. Что позволяет например реализовать схему когда
20 болтов - категория качества "норма"
10 болтов - категория качества "площадка17"
45 болтов - категория качества "площадка45"
При этом "площадки" можно быть как "норма" Или как "не норма разных видов"
.
Что позволит избежать ситуации когда в ВМС свалилось задание на 35 болтов и система автоматом цапанет в сборку болты "площадок" (Что запросто может быть при использовании ОПИСАТЕЛЬНЫХ признаков партий например типа МОЛ что не учитывается в механизмах планирования сборки и потребуется либо дописывать алгоритм либо настраивать спец схему процесса сборки имеющимися средствами ВМС.
.
А для того чтобы в сборку пошёл пул товаров "площадка17" - в задании из КИС явным образом указывается "качество = площадка17"

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

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

(329) а автор - хитрый зая, читает тут и в код переводит)))

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

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

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

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

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

(334) как сказала мне уролог "не ссыте, Сергей Михайлович, всё будет нормально". ГлаВное чтобы потом покупатель, ориентировавшийся на цену, не начал предъявы строить по типу "Должно быть потому что ну это же очевидно что это должно быть" Типа "ответственного держателя" Или отсутствия здпакера загрузки в машину и ещё интеграции с битриксом покупателя...

(335) на то договор есть, описание процессов есть - все исключительно полюбовно проходит)

(336) ну-ну

Бодался я как-то НЕДЕЛЮ с клиентом, которые в старенький релиз ВМС, заинтегрированный с iiko, хотели впихнуть кучу всего из учётных прог (потому что учётной проги не было в принципе), потому что ну это же должно быть, причём практически забесплатно, да даже и за большие деньги делать бы это никто не стал, ибо работа в никуда.
Вернулся из командировки - высосанный в аут, но непобеждённый.

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

(336) описание и процессов - после договора?

(339) это да

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

На адресном складе ведется учет отрезного товара (кромка). Товар приходит от поставщика уже маркированный в стандартных бобинах (например, 100м). Нарезать товар в момент отбора не представляется возможным, поэтому процесс отбора разбит на подпроцессы:
1. Отбор из хранения (в сборку)
2. Комплектация (сборка)
(3. Возврат остатков из сборки в хранение)
Т.е. пришел товар - 10 бобин по 100м. Нужно отгрузить клиенту товар - 120м. Работник склада подходит к ячейке и набирает 200м (2 бобины по 100м), тащит в зону комплектации. После этого работник собирает заказ - кладет 1 целую бобину и от одной отрезает 20м. Остаток 80м маркируется (в штрихкод зашивается артикул и количество). Заказ идет в отгрузку. Остаток 80м хранится в зоне комплектации и может использоваться для комплектации других заказов. Если потребности в остатках нет - они возвращаются в хранение.
Такая схема работы может быть реализована в A-WMS?

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

"Остаток 80м маркируется (в штрихкод зашивается артикул и количество).
- смотря что маркируется, если маркируется БОБИНА, как товароноситель ТМЦ - в нормальной ВМС это излишне, она и так знает по номеру бобины/паллеты/сборного грузового места что лежит в этом "носителе".

Места в зоне "отреза"/комплектации обычно не очень много и копить там "бобины" с отрезами не всегда комильфо. После отреза "бобина" с остатком кладется в выходную буферную ячейку. Наличие в такой буферной ячейке ТМЦ - сигнал для планировщика (который постоянно крутится фоном) и планируется задание на вывоз бобины в зону хранения или в "оперативную ячейку".

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

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

(345) опять же задачи знать какие именно обрезки хранятся на складе - не стоит. Т.е. в наличии может быть 400м, а как они выглядят - 4х100м или 40х10м - особой роли не играет. По крайней мере на текущем этапе и касаемо конкретно этого товара. Поэтому принято решение упростить учет и вести просто товар-ячейка

В Акселот WMS X5 это решается через т.н. операцию "Перекладывание". Т.е. если место хранения (палет, бобина) не может быть отгружен как есть - создается отдельная операция по перекладыванию товара из этого МХ на другое (новое). Т.е. собственно операция "отрезания" куска от имеющегося контейнера. Но вести учет всех контейнеров как то не очень хочется.
На данный момент логика реализована в КА2 так, что при отборе из хранения в сборку можно взять больше чем требуется. Т.е. нужно 20м, а сборщик берет целую бобину 100м или обрезок 80м. А вот уже при отборе из зоны комплектации (окончательная сборка) - уже строгий отбор. При превышении количества система предлагает сделать "обрезание" и распечатать этикетки на куски.

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

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

по-моему, учитывать контейнеры только вендору этой wms интересно))

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

(347) "Просто в qr-код вшиваем количество, чтобы удобно было это самое количество вводить на ТСД."
- в ВМС при использовании товароносителей (особенно когда товароноситель - монотоварный) - система и так знает сколько на носителе товара лежит, и там где надо - подставляет количество на товароносителе и/или тупо говорит - "иди к ячейке A1, бери Паллету 238 и тащия в ячейку Буф2" - и сборщика нахрен не должно волновать сколько на этой паллете количество.
.
но решение зашивать в ШК количества я не сильно одобряю, но и не возражаю. случаи всякие бывают. в самопальных системах это позволяет упростить логику обработки в коде. сам так делал. но с развитием самОй системы - какой-то смысл в ШК следует зашивать там, где без этого никак иначе.
.
В самопльновелосипедной типа миниВМС делал, например, так при подготовке с глобальному инвенту по верхам - ячейкам паллетного резервного монохранения, где паллеты стояли застрейчованные - когда была возможность - штабелер ездил, просчитывал паллету - по сути проводил инвент - на штабелере присобачили принтер этикеток - вылазил лейбак с ШК, в котором зашито не только артикул и количество, но и количество коробов. А на глобальном инвенте - штабелер проехал по верхам, прощелкал эти лейбаки. Но пришлось дописать обработку инвента...
.
Так что возможно все. но если можно обойтись без частностей, универсальностью, - то лучше без частностей.

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

Не сталкивались с погрузчиками, которые на вилы могут брать по 2-3 паллеты с товаром из зоны приемки и развозить по местам хранения? причем паллеты могут быть и с разным товаром, и когда на пал1 - товар1 в кол=120, а на пал2 - товар1 в кол=100...

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

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

зашить в ШК-куер содержимое миксовой паллеты (да даже и монотовароной) - по сути это аналог упаковочного листа на паллету - это очень хорошая вещь.
.
приходит фура с 37 паллет миксовых, заводскими коробами миксом несколько товаров на паллете (когда было хорошо - в фуре приходило ~120 артикулов, когда стало ж.па - и по 600 артикулов запросто) - не было бы упаковочного листа на каждую паллету - пока всю поставку не просчитаешь - стоит ждет развозки на хранение. А когда упаковочный лист на паллету есть - просчитал паллету - сошлась? - ок! - пошла на развозку, товар "сразу" падает в доступ планировщику сборки...

Идем по складу - стоит паллета с товаром, маркировки никакой нет. ЭТО ЧТО? если есть нумерованный товароноситель - тупо жмакаем по нему сканером в режиме просмотр остатков, видим все что надо, в т.ч. что паллета эта на исполнении на данный момент находится на сотруднике "Вася"...

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

(359) выгрузили паллету из авто = сделали приемку. самый главный пересчет как раз и происходит при размещении.

(359) в общем, нет, смысла нет

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

Есть разные поставки/приходы. Есть такие, когда решение размещать или нет - принимается только после полного пересчета поставки. Есть отклонение - размещение запрещено, делается контрольный пересчет или всей поставки или тмц с отклонениями.

выгрузить из машины = приемка.
- приемка чего? что будет зафиксировано что именно принято?
Выгрузили сборные микс короба, в каждом коробе - разные ТМЦ. По результатам "приемки" в случае отклонений - поставщику нужен ответ в каком коробе что именно "отклонилось" (короба, слава богу, нумерованные). Короба при выгрузке приняты и зафиксированы в системе по количеству мест(коробов)..? Если нет - и по факту размещения из нумерованных коробов в конце размещения выяснится что хз где-то не хватает целого короба - какого?
какой сценарий для такой ситуации, начиная с момента заноса коробов из авто в ворота склада? еще веселее - когда короба на стрейчованных паллетах...

проигрываю разные сценарии...

(343) сталкивались с такой проблемой, что вы отгрузили бобины с датами изготовления, например 2023 год, 2-ой квартал. а в отгрузочных документах номера ГТД от какого-нибудь 2022 года и покупатель выставляет претензию, мол у него учет не бьется?
(354) Напольное хранение в неразмеченной зоне часто бывает, когда, например, есть крупногабаритный товар, например станки или какие-нибудь компрессоры. Так что это вполне рабочий вариант.

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

Сделал промо-страницу: https://awms.ru/promo2.html

(368) +, норм

(368) красные галочки вызывают когнитивный диссонанс в пищеварительной системе головного мозга

(370) поправлю, ок. какие ставить?)

(371) зеленые, но втрое более жирные.

(372) галки все сделал жирными, пункты выделил другим способом.

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

(374) да, подумаю, спасибо.

(350) В Акселот WMS X5
Mitroshin, скажите, а в упомянутой Вами WMS, себестомость как-то учитывается?

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

По скриншотам также видно, что в интерфейсе присутствует раздел "Затрат", но скриншотов что там внутри я не нашел.

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