Предыдущая ветка
WMS на 1С. Выбор (Голосовалка)

Продолжаем обмен мнениями, хроники удач и провалов
Хвалим себя, ругаем других
Для альтруистов и бесребреников: ругаем себя, хвалим других

Описываем и меняемся опытом по решенным/нерешенным проблемам.

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

И просее по существу складских вопросов

Номенклатуры 16 000 видов и подвидов: от Двигателя/рамы/КАМАЗа до шайбочки 0.1 на 0.1 см.
Когда заказ комплектуют - взвесте нам пожалуйста 1 КАМАЗ, 1 двигатель для него на всякий случай, 10 гаечек под него, и т.п.
Специфика: На север отправляем - он пока туда дойдет 2 месяца пройдет. Там КАМАЗ несчастно эксплуатируется 2-3 месяца посменно, потом идёт на кап. ремонт с заменой кабины и двигателя (нефтянка на 40 градусов мороза разъедает даже раму, не говоря уж о нежной кабине, где краска через 2 недели сползает кусками от постоянной полировки химикатами, гравием, песком, перепадом температур и проч.)

Ну и когда рама уже всё (порядка в среднем 4 года по той же причине что и кабина разрушается) КАМАЗ разбирают на части - то что можно ставят на новую раму, ну или новый КАМАЗ покупается.
Да, сразу скажу что всякие там маны/сканьи и проч. выходят тупо дороже. Кстати несмотря на то что двигатели Cummins признанны во всём мире, то на нашем севере часто от них отказываются - ходит он несомненно в 2-3 раза дольше, однако стоит так же и часто без спец. оборудования его не починить, ну и более сложен в настройке, требователен к топливу и проч.

Я конечно более жути нагнал но в целом это так.

(441) то есть на приемке у вас тут самая большая проблема - отсутствие маркировки штрихкодом на товарах..? Не пробовали приемщице дать ТСД чтобы тупо то что чиркала на бумажке - "пробивала" на ТСД - у меня сейчас есть такая процедура на ТСД
1. Приемщик идентифицирует товар
- жмаком по штрихкоду или
- выбором из списка товаров поставки (чего нет в списке - "СТАВЬ В КАРАНТИН" - или излишек или этого вообще нет в поставке)
- после идентификации вводит количество - тупо давит на клаве "150" или если укладка слоями тогда может надавить "3*10*5"
- после ввода количества проверка - если излишек - снова "ставь в каратин"
.
типа такого не пробовали? будет ли быстрее...? если в поставке много товаров - может получиться быстрее...?

(442) Со всеми с кем я разговаривал "в кулуарах" кто плотно внедрял Акселот - на вопрос "скольо переписал" - отвечали порядка 70%... ;-)

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

(451) Я как лайт модер могу про Акселот сказать матом но промолчу. Я когда на половину его переписал тупо за 3 недели своё написал. Если бы я срузу писал это даже дешевле вышло бы чем стоимость лицензий на Акселот)

(450) Скажем так - у нас на половине товара нет своих ШК. Но то что ты написал это как раз и делается. Но у нас ВЕСЬ товар маркируется своими ШК. Зачем? Хех, а вот тут мы очень хорошие продажники )

(446) "А у нас хоть и формально ОПТ, а на самом деле просто крупная крупная розница." - ну и нас также получается. ;-) у меня из миллиона отгружаемых единиц 80% грузится штуками, 15% минипаками, 5% - мастеркоробами. Опт, елы-палы... ;-)

Побегу кофе налью... Почитаю, сильно все занятно как на других складах...

(455) Ну вот тут подход Акселота и не канает по сути. Вот я всё понимаю - в целом вполне рабочая программа, но по сути только на картинке. К реальности не приближена.

(456) Тут скайп лучше поможет с демонстрацией рабочего стола.

(458) ну если будет время то стукнись в скайп, спсб

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

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

(431) Кстати о масштабировании, посмотри у себя в WMS на 8 функцию ТерминалыВыполнитьМасштабирование, там все достаточно примитивно :)

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

(460) Для облегчения работы операторов. Что бы 20 документов не плодить.

(463) Тоесть под каждый вид устройств делать свою форму? Накладно выйдет...

(465) Ну тут я думаю для ТСД 1 вид, для планшета другой. Имхо. Ну и вообще функции могут быть разные.

(379) все 6000 СКУ постоянно должны быть в наличии на складе?
если это так - что мешает еще 1000 ячеек отбора выделить?
если они будут уже на 2м ярусе - нет таких штабелеров чтоли?

(388) 2-3 ляма если по умному. и не последняя часть - это оборудование, недавно заметил что хорошие ТСД уже по 80-160 т.р. стоят...

(421) "с программистами немного проще - они могут в конфигураторе посмотреть и уже много вопросов исчезнет."

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

(467) Так 2 ярус тоже под отбор занят уже :))

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

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

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

(471) ну мы же друг друга понимаем, что в моем случае в НЭКМе был как раз самый неправильный вариант ))

(464) Сомнительно.
Ордера - складские доки. с ними работают складские. УПП - работают манагеры, все что надо - обеспечить в упп-док подтяжку из ордеров. Бо хотелки неизмеримы. У мну в "финансовом" доке есть "КолвоПлан"(то что ожидаем по докам), "КолвоФакт" (то что по факту) и штатное "Количество" (учетное) - вот что хотите - то и пихайте в учетное количество... я забодался вникать в хотелки бухов,"а вот если клиент вот этот то надо в качестве учетного взять факт"...

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

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

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

На всех удаленных проектах всегда проводилось множество Skype конференций + плотная переписка по почте + удаленная работа на сервере.

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

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

(475) не совсем так...
Арена внедряется разработчиком практически без дописок в коде - все вынесено в настройки. в этом плане да - простая, логичная и понятная.

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

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

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

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

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

(479) о чем и речь!
нужен даже не прог, а чел который может грамотно настройки (в терминах Арены - Стратегии) настроить.

(473) У нас факт соответствует докам в УПП. Это решение ГД, ГБ и ГЗамСклада. Как этого добиться это отдельная тема. Поэтому размножение общностей не нужно вообще.

(478) Какой том самостоятельно, в системе более 250 таблиц, из которых большая часть для настройки процессов ;)

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

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

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

В свою очередь столкнулись с такой проблемой в Exceed и не смогли правильно настроить. И во многих других системах видел такой простой подход.

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

По скорости вопросов пока не возникало.

(484) ...Вот опять же
Приемка
Размещение

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

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

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

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

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

(489) Да, правильный посыл. WMS на 1С ни в чем не уступают решениям не на 1С. Но не все, а только лишь некоторые :)

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

Иначе могут такое накрутить, что потом придется расхлебывать с привлечением сторонних специалистов. Но при этом программисты не признают своей вины, а будут все сваливать на разработчика
http://s017.radikal.ru/i417/1511/16/df637c5ca2ec.jpg

;)

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

.. еще что-то?

(492) Хороших программистов 1С, к сожалению, не так много, поэтому есть шанс, что даже простые вещи могут быть допилены довольно криво.

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

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

В той же конторе, из за нехватки времени, заказали разработку системы бюджетирования сторонним франчайзи. Написали толстенное ТЗ. Подписали. А по результатам получили систему, которая основывалась только на документах, без движений по каким-либо регистрам! Исполнитель напирал, что в ТЗ не указано, что отчеты должно строится по регистрам. А мы даже не могли предположить, что разрабатывая ТЗ нужно упоминать такие простые истины...

(494) "Хороших программистов 1С," - это правило применимо почти везде по моим наблюдениям. Правило 20/80.

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

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

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

(494) "А мы даже не могли предположить, что разрабатывая ТЗ нужно упоминать такие простые истины..." - надо ли в ТЗ на WMS отдельно упоминать что любые доработки проводимые, например, по каким-то складским операциям, должны обеспечивать регистрацию затраченного времени на операцию..?

(494) rsergio, напишите, пожалуйста, свою почту на yfilimonov собака yandex.ru, есть ряд вопросов.

Пиццот :)

(499) так на их сайте и почта, и скайп указан...

а кто нибудь работал с "Кортес: Адресный склад" ?
http://cortes.ru/software/AddressWH/

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

или просто настроить не смогли?

(502) У нас так не получиться к примеру. Не каждая программа подходит под каждый склад.

(503) как именно?

(504) Ну вот смотри - у нас к примеру на складе есть двигатель и комплект рессор. Комплект рессор весит меньше двигателя. Но если ты этот комплект рессор в контейнер положишь на двигатель, то двигатель может сломаться при тряске. И как тут эффективно распределить программа должна? На что опираться?

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

(505) (506) не понял причем тут это...

и о чем вообще речь? когда ездят на ричтраке и товар отбирают в ПЕ (коробку)? так их можно класть рядом на поддон.

или у вас в одной ячейке что попало друг на друга складывается??

а вообще, есть "группы совместимости товаров" в Арене например, там вообще много опций настраивается.

Завершили инвентаризацию двух складов. Как выяснилось принвентаризировать 15 тыс SKU и 2000 ячеек большая проблема. Запускаешь народ сканировать товар. 5 человек сканирует одну ячейку и все получают разные результаты. С учетом того, что сканируется одновременно много ячеек, отгрузки не останавливаются,  разобраться в этой каше достаточно сложно. Пришлось реализовывать специальный механизм контроля проведения инвентаризации.

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

Если же в одной ячекйе еще лижит товар одного вилда (винтики-10, винтики-12, винтики-14..) - это плохо.
Варианты для облегчения жизни.
Обязательное _физическое_ разделение - фанерой. картоном - полюбасику. как только это сделали - сразу стало намного легче.
ну и не мешать в одном ячейке похожий товар. меншать только разнородный товар который при счете ну очень трудно посчитать один за другой.

По механизму контроля - есть спец "рабочее место", я выше описывал

Запустился на складе с проектом ОХ.
Работает пока в основном как задумывалось.
Сижу думаю как обеспечить размещение тяжелого товара на нижних ярусах. Пока только в бошку приходит вариант зонирования. Вариант с типоразмерами ячеек мутить не хочется (по сути это то же самое зонирование)

Есть у кого опыт использования планшетов на складе?

Вчера прикрутил виртуальную клавиатуру к экранам ТСД. Теперь форма универсальная - как для обычных ТСД (240х320 и 480х640), так и для планшетов (800х600, 1024х768 и т.п.), масштабируется автоматически.

На iPad выглядит так:
http://s010.radikal.ru/i312/1511/44/8b14fdc37125.jpg

В качестве сканера можно использовать bluetooth сканер Motorola CS3070 или LI4278 (и множество подобных с 2D сканерами).
http://www.youtube.com/watch?v=JJ6e8Yz2JXc
http://www.youtube.com/watch?v=-bKl_7OvqKA

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

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

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

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

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

(509) У нас по факту все существенно хуже. Стандартно в ячейке лежит 8-10 наименований. Есть ячейки разделенные на коробки и ли отделенные фанеркой, но все равно там лежит по 10-20 наименований и до 300 единиц хранения.
Плюс проблема с тем, что отгрузки не останавливаются.
Но проблему инвентаризации я решил. Сделал регистр сведений ИтогиИнвентаризации, где хранится дата последней инвентаризации и статус Успешна/Не успешна.

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

выше написал - 1.физическое разделение 2.в одной ячейке не мешать товары одного вида.

"Но проблему инвентаризации я решил. Сделал регистр сведений ИтогиИнвентаризации, где хранится дата последней инвентаризации и статус Успешна/Не успешна."
- имхо херня-с... признаком успешности/неуспешности можно считать наличие остатка в "кармане отклонений". до тех пор пока там что-то болтается (по результатам !!текущих!! инвентаризаций - состояние данного товара = "неуспешно". И обнуление этого кармана только по результатам плановой инвентаризации или по решению МОЛ/ЛПР.

А то вот у тебя:
начальное состояние:

- инвентаризация 05.11.15
по учету=100, по факту=100, отклонение=0 - инвентаризация успешна

допустим что-то продали...

- инвентаризация 08.11.15
по учету=90, по факту=80, отклонение=-10 - инвентаризация НЕУСПЕШНА (привели учет к факту, куда вы дели отклонение - я хз (списали?), но зафиксировали что инвентаризация НЕУСПЕШНА).

допустим движений не было...

- инвентаризация 09.11.15
по учету=80, по факту=90, отклонение=+10 - инвентаризация НЕУСПЕШНА...? хотя вообщем-то как раз наоборот - УСПЕШНА - инвентаризация успешна, так как свела предыдущее отклонение (карман отклонений) в ноль...

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

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

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

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

В кортесе мне "нравятся" иконки для тыкания на радиотерминале. Они туда бы еще полноразмерную виртуальную клавиатуру приделали ;-) http://screencast.com/t/NXNIuGHEbfB

Прошла полная инвентаризация по двум зонам склада, отклонения примерно 0.5% от стоимостной оценки - принято допустимым.

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

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

Я так прикидывю примерно - при месячном обороте продаж ~100 лямов (в прайсовых ценах) - за год набежит 6 лямов отклонений (ктото там хорошо у вас обогащается) ;-)

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

(521) У меня корректировка остатков - это только 1. списание брака из ячейки "Брак" и 2. списание отклонений по результатам плановой инвентаризации.

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

(522) Ну 90% из этого пересорт, по результату по обеим зонам небольшие излишки. Если от оборотов считать - это сотые доли процента. Можно конечно увеличивать качество работы для дальнейшего снижения потерь, но для этого понадобится повышать качество и количество персонала, что приведет к росту ФОТ и не факт, что оно окупится...

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

(525)  пересорт это такая де хрень как недостачи и излишки
Или даже может хуже особенно когда в таких размерах
Получается что пипл постоянно косячит и забивает болт на цу от проги, облегчает жизнь?

Продолжаем тему с планшетами.

Взял на тест портативный сканер:
http://s017.radikal.ru/i437/1511/1f/12b1118e9b93.jpg

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

Прицепил к планшету:
http://s014.radikal.ru/i329/1511/75/bfff43217e1a.jpg

Для корректной работы нужно сделать несколько настроек. Включить режим возобновление связи - при просыпании после сна автоматом подключается к планшету и также выводит его из сна. Уменьшить подсветку экрана до 10 сек. Выбрать подходящий режим сканирования - мне понравился вариант когда один раз нажимаешь на кнопку сканирования и не нужно на нее жать пока не пройдет таймаут или не считается код.

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

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

вот, например, евросклад, секции из трех евроячеек
ПРОНУМЕРОВАНЫ. например, вот так

|_1_ _3_ _5_|_7_ _9_ _11_|_13_ _15_ _17_|

как красиво описать, что в эти все ячейки могут становиться европаллеты, а fin-паллеты могут становится только в 1,5,7,11,13,17 итд..? (понятно, что нумерация ячеек условная, и к ней привязываться в общем случае нельзя).

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

(528) вот еще тема с планшетами+сканером
http://catalog.mista.ru/public/424282/

(529) На самом деле задача немного сложнее, чем просто прописать какие паллеты куда ставятся.
Ведь если в 5 стоит fin, то в 1 и 3 вместе уже не поставишь по 1 euro, а если в 3 и 5 стоят euro, то в 1 уже  не поставишь fin, но можно поставить euro.

Обычно описывают вместительность ячеек в условных единицах, и паллетам тоже прописывают условные единицы. В одном поле (на балке) умещается 3 у.е.
1 euro - 1 у.е.
1 fin = 1.5 у.е.

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

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

(530) Спасибо, почитаю.

Я разковырял SDK к 3390 и реализовал доп. функции:
- Задействовал стрелки - теперь можно управлять курсором в планшете
- Левая софт клавиша - теперь Esc
- Правая софт клаввиша - теперь Enter
- Убрал с экрана отображение штрих-кода (нефига складским смотреть коды ячеек и паллет)
- Выключаю подстветку экрана сразу после нажатия клавиши

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

http://s019.radikal.ru/i606/1511/38/e4094e5d11cd.jpg

(531) "...Ведь если в 5 стоит fin, то в 1 и 3 вместе уже не поставишь по 1 euro, а если в 3 и 5 стоят euro, то в 1 уже  не поставишь fin, но можно поставить euro. " - зришь в корень!

(531) "..Обычно описывают вместительность ячеек в условных единицах, и паллетам тоже прописывают условные единицы. В одном поле (на балке) умещается 3 у.е."

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

Задачу можно решить по разному, но в WMS лучше решать так, как ближе к физическому смыслу.

Балка имеет свои физические ограничения. И кроме вместительности по паллетам еще и ограничение на максимальный вес на балке.

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

(534) Мужик, я ни [*****] не понял, что ты сказал мне, но ты мне близок. Ты заговорил и достучался до сердца."
.
" с группировкой по коду ячеек, за минусом места (или группировка по ряду, пролету, уровню)." - все это так или иначе задает связность ячеек.

надо думать...
не хочется контейнеры описывать...

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

т.е. для "типового евросклада"
|_1_ _3_ _5_|_7_ _9_ _11_|_13_ _15_ _17_|

дуга из 1 в 3 = вес 1,
дуга из 1 в 5 = вес 2,
дуга из 3 в 5 = вес 1,
дуга из 5 в 7 = вес 999999

.
может как-то хитроумно можно вывернуть на этой основе?
или не имеет смысла заморачиваться?

Я не понимаю почему надо бежать от описания физических взаимосвязях.

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

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

(533) Ну а если, например, автоматически занимать дополнительно 1 соседнюю ячейку, если не европалета ставится?

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

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

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

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

(537) Не универсально, но будет работать с определенными входными данными.

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

Потом нужно еще как-то эту ячейку "занимать" и вовремя освобождать.

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

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

у нас сейчас авторазмещение на ВМС работает для РХ, в АХ - товар закреплен за ячейками (подвижки ассортимента и изменения классов - небольшие). А вот по проекту ОХ - сразу запилил авторазмещение - начсклада не возражал, только "за" был. Авторазмещение не работает (ввиду нереализованности - описанной выше проблемы с негабаритами) по финпаллетам в евроблоки в зоны, не закрепленные за финпаллетами - там ставим пока "по месту", но финпаллет немного - штук 400...

что главное? главное - чтобы ничего не ломалось, там где не работает! если сломалось почему-то - то блин должно откатиться назад до состояния "перед" выполнением операции. или по крайней мере не ломаться а выдавать самый главный экран
.
http://content.screencast.com/users/Che66/folders/Jing/media/fccfc619-ccd3-4310-9263-9eea806e799f/2015-12-08_1852.png