|
SEVCO WMS - кто работал? | ☑ | ||
---|---|---|---|---|
0
anatoly
13.02.15
✎
11:08
|
мы сейчас используем для складской логистики Арену ВМС - очень мягко говоря "оригинальное" решение - уже писал в одной ветке.
в среду были на семинаре сабжа: http://www.sevco-wms.ru/ правда непосредственно по софту сказали/показали крайне мало, в основном по самим процессам. кто нибудь сталкивался с этим зверем вживую? интересно насколько он реально удобен и для юзеров и для доработки. просто, учитывая что у них ТМС - Антор (вчера создал ветку) а в виде КИС - RS-Balance (дос!!!) возникают некоторые смутные сомнения... |
|||
69
ГеннадийУО
14.02.15
✎
22:53
|
(67) Я так понимаю, если регистр накопления закрывается, и используются только актуальные остатки, особых тормозов быть не должно?
|
|||
70
Злопчинский
14.02.15
✎
22:54
|
(65) при таких нагрузках вообще ничего не будет
Можно даже на классических документах построить |
|||
71
ГеннадийУО
14.02.15
✎
22:54
|
(68) Так вот в том и вопрос, насколько система правильная...
|
|||
72
ГеннадийУО
14.02.15
✎
22:56
|
(70) В перспективе гдето на порядок возрастет, еще в промэксплуатацию не запустились...
|
|||
73
Злопчинский
14.02.15
✎
22:58
|
(67) тут еще зависит наверняка от еоличества разрезов учета
Ести грубо товар-ячейка-фирма то и на тысячах и пару деятков тысяч номенклатуры будет болееменее Если туда пркрутить всякие характеристики срокигодности и еще богзнает что то могут наверное начятся трудности |
|||
74
H A D G E H O G s
14.02.15
✎
22:58
|
(67) Никогда не видел, ибо достичь такого можно только снеся кластерный индекс.
"Основная проблема регистра накоплений - избыточность данных. Он накапливает ежемесячно все остатки. И чем дальше тем больше данных, которые снижают быстродействие. Но если оперативно резать остатки переносом, то проблему можно контролировать." бредятина. |
|||
75
H A D G E H O G s
14.02.15
✎
22:59
|
(69) Да, так и есть. Но это совсем другое, нежели имел ввиду (67).
|
|||
76
H A D G E H O G s
14.02.15
✎
23:02
|
(69) Единственная проблема - получение остатков на МОМЕНТВРЕМЕНИ(). 1С строила кривоватый запрос, который заставлял делать clusteredindexscan по таблице движений РН.
Вроде поправили (разбили запрос к движениям на 2 запроса с объединением) |
|||
77
ГеннадийУО
14.02.15
✎
23:03
|
(75) Ну я реально видел регистр накопления, таблица итогов которого за 2 года выросла до 170 Гб (при размере основной таблицы что-то около 30 Гб) что составило примерно треть размера всей БД)...
|
|||
78
rsergio
14.02.15
✎
23:03
|
(69) Регистр не может закрываться ровно в какую-то дату, поэтому переходящие остатки из месяца в месяц будут.
Далее посмотрите какие запросы формирует 1С чтобы получить актуальные остатки. Помимо отборов по измерениям всегда стоит отбор по дате. (74) Попробуйте установить отбор не на измерение, а по ресурс и посмотрите план запроса "бредятина." Конструктивный диалог. |
|||
79
ГеннадийУО
14.02.15
✎
23:06
|
(78) Ну вот, условно говоря, имеем на складе 10 тыс. ячеек, 8 тыс. СКЮ. Таблица остатков разве будет большая???
|
|||
80
H A D G E H O G s
14.02.15
✎
23:06
|
(77) Либо не закрывалось ничего, либо дофига измерений, либо дофига остатков. Ничего страшного в размере нет. Страшное может быть в причине.
|
|||
81
Злопчинский
14.02.15
✎
23:06
|
(72) смотри
У меня на самопальной клюшке за восьмичасовуюсмену смену лелалось порядка около 20 тыс сканирований примерно 10 пиплов Причем это не было даже равно ерно размазано по смене И все это разруливалось чисто файловой системой почти все Выигрыш достигался тем что в частном случае у меня в онлайне по местам хранения количественный учет вести необходимости острой не было для удовлетворения потребностей в сборке Проблемы вылазят может быть там где нужно наверное живое онлайнпланирование Если есть возможность планировать заранее большую часть все проще |
|||
82
H A D G E H O G s
14.02.15
✎
23:08
|
(78) "Далее посмотрите какие запросы формирует 1С чтобы получить актуальные остатки."
Хорошие она запросы формирует, попадающие в индексы. Никаких тормозов от незакрытых/необрезанных остатков быть не должно. Остаток на конец месяца (типовая настройка) минус движения до текущей даты. |
|||
83
Злопчинский
14.02.15
✎
23:09
|
(79) это не показатель вообще
Это вообще мизерные цифры Определяющим имхо является темп обращения к данным по этим скю и ячейкам |
|||
84
rsergio
14.02.15
✎
23:09
|
(79) Смотрите - проводите инвентаризацию и просто ничего в базе не делайте. Что произойдет через месяц, через два, через год?
|
|||
85
ГеннадийУО
14.02.15
✎
23:10
|
(80) Самое смешное, что этот регистр был спокойно очищен, так как нигде не использовался...
|
|||
86
Злопчинский
14.02.15
✎
23:12
|
(82) хз как там в снеговике
Но у меня на клюшках например очистка нулевых записей таблицы итогов весьма существенно ее ужимала Критично ли доя быстрого обращения к данным и получения итогов лишние 40 мегабайт никому ненужных записей -хз Я до такого мегадаопросветления еще не достиг |
|||
87
ГеннадийУО
14.02.15
✎
23:12
|
(84) Вырастет таблица итогов. И что в этом страшного, если я использую только текущие итоги?
|
|||
88
H A D G E H O G s
14.02.15
✎
23:14
|
(78) "Попробуйте установить отбор не на измерение, а по ресурс и посмотрите план запроса "
ВЫБРАТЬ ЦеныНоменклатуры.Цена ИЗ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры ГДЕ ЦеныНоменклатуры.Цена <> 0 Rows Executes StmtText StmtId NodeId Parent PhysicalOp LogicalOp Argument DefinedValues EstimateRows EstimateIO EstimateCPU AvgRowSize TotalSubtreeCost OutputList Warnings Type Parallel EstimateExecutions ---- -------- -------- ------ ------ ------ ---------- --------- -------- ------------- ------------ ---------- ----------- ---------- ---------------- ---------- -------- ---- -------- ------------------ 3564 1 Clustered Index Scan(OBJECT:([Testbase].[dbo].[_InfoRg17227].[_InfoR17227_ByDims_RRRT] AS [T1]), WHERE:([Testbase].[dbo].[_InfoRg17227].[_Fld17232] as [T1].[_Fld17232]<>CONVERT_IMPLICIT(numeric(15,2),[@P1],0))) 0 0 Clustered Index Scan Clustered Index Scan OBJECT:([Testbase].[dbo].[_InfoRg17227].[_InfoR17227_ByDims_RRRT] AS [T1]), WHERE:([Testbase].[dbo].[_InfoRg17227].[_Fld17232] as [T1].[_Fld17232]<>CONVERT_IMPLICIT(numeric(15,2),[@P1],0)) [T1].[_Fld17232] 3564 0.0542361 0.0040774 16 0.0583135 [T1].[_Fld17232] PLAN_ROW 0 1 |
|||
89
H A D G E H O G s
14.02.15
✎
23:16
|
Веселый ребята работают в Арена.ВМС.
Умудрились |
|||
90
Злопчинский
14.02.15
✎
23:17
|
(87) если ты используешь только текущие итоги то в самой таблице итогов в одноэсном понимании вообще необходимости нет
Имхо злесь таблицей итогов может быит сам справрчник номенклатуры |
|||
91
_Demos_
14.02.15
✎
23:17
|
(45) у ВК есть минус код надо реализовать через С++
|
|||
92
Злопчинский
14.02.15
✎
23:18
|
(89) боже мой, все пропало?
|
|||
93
rsergio
14.02.15
✎
23:19
|
(87) Текущие итоги - это отдельный отбор. К нему потом добавляются другие отборы. Далее идет запрос к таблице по выборке данных.
По результатам замеров производительности на объекте, описанном чуть выше, было выявлено, что если таблица превышает объем более миллиона записей, то даже использования индекса все-равно не спасает от задержек в получении данных. (89) Вообще то это данные с рабочей базы. Запрос в 3.0 версии типа такого: ВЫБРАТЬ ПЕРВЫЕ 1 Взять.Владелец, Положить.Владелец КАК Владелец1 ИЗ РегистрСведений.усСтрокиПеремещения КАК Положить ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.усСтрокиПеремещения КАК Взять ПО Положить.ИдентификаторПакета = Взять.ИдентификаторПакета И (Взять.ТипОперации = ЗНАЧЕНИЕ(Перечисление.УстипыОпераций.Взять)) И (Положить.ТипОперации = ЗНАЧЕНИЕ(Перечисление.УстипыОпераций.Положить)) ГДЕ Взять.ИдентификаторПакета = &ИД И Положить.ИдентификаторПакета = &ИД И Взять.Ячейка.ТипЯчейки = ЗНАЧЕНИЕ(Перечисление.усТИпыЯчеек.ТорговыйЗал) И Положить.Ячейка.ТипЯчейки = ЗНАЧЕНИЕ(Перечисление.усТИпыЯчеек.ТорговыйЗал) И (НЕ Взять.Ячейка.КаналСбыта = Положить.Ячейка.КаналСбыта) И (НЕ Взять.Ячейка.КаналСбыта = ЗНАЧЕНИЕ(Перечисление.КаналыСбыта.Пустаяссылка)) И (НЕ Положить.Ячейка.КаналСбыта = ЗНАЧЕНИЕ(Перечисление.КаналыСбыта.Пустаяссылка)) При этом ИдентификаторПакета - это ресурс. Индексации не стояло. Поэтому отбор по нему - TableScan. Вопрос не к нам, а к разработчикам этой системы и тем, кто ее поддерживал. |
|||
94
H A D G E H O G s
14.02.15
✎
23:25
|
(93) Весело там у вас :-)
|
|||
95
H A D G E H O G s
14.02.15
✎
23:26
|
(93) Это написали Акселотовцы?
|
|||
96
ГеннадийУО
14.02.15
✎
23:26
|
(93) Ничего не понял. В моем понимании, при получении текущих итогов идет обращение только к таблице итогов с отбором по периоду. Где здесь замедление работы при увеличении количества записей?
|
|||
97
rsergio
14.02.15
✎
23:29
|
(95) Не знаю кто писал, конфа была перепахана внутренним отделом разработки. Замеряли производительность, искали запросы в топе по времени, выясняли причину, давали советы.
Там база более 100 Гигов весила, некоторые таблицы по 30 млн. записей содержали. Запросы по 5-10 секунд выполнялись. При этом работники с ТСД все это время стояли и смотрели на экран в ожидании когда появятся следующие данные... |
|||
98
H A D G E H O G s
14.02.15
✎
23:31
|
(96) Таблица итогов - одна.
Она - плоская, гигантская. Даже чтобы получить текущие (на 5999 год) итоги - надо выбрать из всего гигантского количества. Индексы позволяют выполнить это быстро, гораздо (геометрически) быстрее чем просто поиск. Но даже индексы на истино больших объемах данных могут выполнять поиск недостаточно быстро. |
|||
99
ГеннадийУО
14.02.15
✎
23:33
|
(98) Гигантская это сколько? Сотни миллионов записей?
|
|||
100
H A D G E H O G s
14.02.15
✎
23:36
|
(98)
геометрически-> логарифмически. |
|||
101
H A D G E H O G s
14.02.15
✎
23:37
|
(99) Неважно. Важно, что сложность поиска по индексу - логарифмическая:
https://ru.wikipedia.org/wiki/%C2%FB%F7%E8%F1%EB%E8%F2%E5%EB%FC%ED%E0%FF_%F1%EB%EE%E6%ED%EE%F1%F2%FC#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80.D1.8B |
|||
102
H A D G E H O G s
14.02.15
✎
23:39
|
(99) Почитайте про вычислительную сложность, деревья поиска, b+ деревья (на них ms sql строит свои индексы, на них же построены заголовки NTFS). Это полезно.
|
|||
103
_Demos_
14.02.15
✎
23:42
|
(102) вот что значит человек сдал на эксперта :)))
|
|||
104
H A D G E H O G s
14.02.15
✎
23:51
|
(103) Это мелочи в сравнении с экспертом.
|
|||
105
ГеннадийУО
15.02.15
✎
09:45
|
(101) Понятно, т.е. значительное замедление мы получим только на огромных объемах данных. К счастью, 1С позаботилась о нас, и для регистров накопления можно оставить использование только текущих итогов, и тогда действительно проблемы с использованием РН в WMS мы можем получить только засчет роста числа одновременно работающих пользователей.
Остался второй вопрос - какие проблемы можно получить, используя схему строка любого документа - отдельный специальный документ? |
|||
106
anatoly
15.02.15
✎
10:30
|
(32) я просто совмещал оборот товаров и выемку из ячеек. и обнаружил такой факт. это говорит о вообще никаком взаимодействии офиса и склада. одни смотрят в КИС (УТ) другие в ВМС и собственно на стеллажи, и думают что на другом конце итак все знают.
скинуть неликвид = освободить ячейки под оборачиваемый товар, большие запасы, чтобы реже поставщиков дергать. наш ИТ-директор верно говорит: "ИТ-отдел = высшая нервная система компании. мы видим все. другие видят только свое а на остальное кладут болт. и начинается *опа." |
|||
107
ГеннадийУО
15.02.15
✎
10:34
|
(106) Я так скажу, без поддержки собственников бизнеса на ИТ все положат болт...
|
|||
108
anatoly
15.02.15
✎
10:34
|
(35) "Или вот - ячейки не привязаны ни к каким координатам, просто нумерация."
это как так вообще?? а как оптимальный маршрут строить? а если по одному заказу/волне отборщика будут гонять из одного конца склада в другой? я видел такое как раз в СЕВКО - но у них свой склад хитрый, один единственный маршрут по хитрому лабиринту с обходом всех ячеек. но проходы узкие, если в самом начале весь заказ отобрал - до выхода едешь в холостую ибо не развернуться а следом другой отборщик едет. ну или наоборот - весь склад сначала проезжаешь если все товары в конце. пипец... |
|||
109
anatoly
15.02.15
✎
10:36
|
(36) аналог документа - справочник. аналог ТЧ - подчиненный справочник СтрокаДокументаБлаБлаБла.
|
|||
110
anatoly
15.02.15
✎
10:37
|
(49) какая у вас ВМС, если не секрет?
|
|||
111
anatoly
15.02.15
✎
10:39
|
(54) C# итак по идее скриптовый язык. ибо под .НЕТ.
сам .НЕТ - фреймворк, как JRE или платформа 1С. программа на C# - п-код исполняемый фреймворком. как то так... |
|||
112
ГеннадийУО
15.02.15
✎
10:39
|
(110) Пока проект не закончен, не хочется публично озвучивать. Но никому не порекомендую, очень много проблем при внедрении...
|
|||
113
ГеннадийУО
15.02.15
✎
10:42
|
(108) В большинстве случаев координаты не нужны, достаточно настроить правильный порядок обхода ячеек.
|
|||
114
anatoly
15.02.15
✎
10:43
|
(67) резать кстати не вариант.
когда я пришел, провели инвентаризацию, и возникло много вопросов - я сделал механизм через ЖурналТранзакций восстанавливать историю по товару/ячейке, жутко тормозит, но работает. это реально нужно чтобы выяснять кто когда и как накосячил. потому что кладовщики из чуркестана такие долбо@#$ы... |
|||
115
anatoly
15.02.15
✎
10:46
|
(107) пытаемся учить правильному пониманию, процесс со скрипом, но идет вроде...
|
|||
116
anatoly
15.02.15
✎
10:48
|
(113) как ты настроишь порядок обхода без координат??
я сразу не смог придумать... как я писал как у СЕВКО - не вариант, у нас склад - 74 ряда стеллажей, 2 ричтрака разъезжаются спокойно. |
|||
117
ShoGUN
15.02.15
✎
11:00
|
(111) Не совсем так, .NET - не интерпретатор, а JIT-компилятор. Так что и от JRE и от 1С он сильно отличается в лучшую сторону по производительности.
|
|||
118
ГеннадийУО
15.02.15
✎
11:10
|
(116) Поясни, что ты в виду под координатами имеешь?
|
|||
119
ГеннадийУО
15.02.15
✎
11:11
|
(116) Да, кстати склад у нас примерно такойже..
|
|||
120
anatoly
15.02.15
✎
11:14
|
(118) X,Y - координаты рядов на полу, Z-высота ячейки (хотя по моему лишнее - т.к. уровень яруса итак есть)
(119) такой же - как я у СЕВКО описал? |
|||
121
anatoly
15.02.15
✎
11:15
|
+ (120) если интересно - могу схему топологии из Арены в почту кинуть.
|
|||
122
ГеннадийУО
15.02.15
✎
11:19
|
(121) Скидывай gennayo собачка на яндекс.ру. Склад у нас такойже как у вас.
|
|||
123
ГеннадийУО
15.02.15
✎
11:22
|
(120) Не очень понятно, зачем это если есть идентификатор ячейки вида Ряд-Стеллаж-Номер яруса-Номер ячейки...
|
|||
124
Злопчинский
15.02.15
✎
11:36
|
(108) ячейкам присваиваются рейттинги всякие или порядки обхода и эти числа никак не связаны с номерами ячеек
И маршрут строится исходя из этих рейтингов/порядков обхода Это типа универсальность На самописке у меня было просто так как склад имеет резко выраженную регулярную симметричную мтруктуру я просио прямо в алгоритме строил маршрут без всяких рейтингов так как у меня получалось что номер ячейки это и есть порядок обхода |
|||
125
anatoly
15.02.15
✎
11:37
|
(122) выслал.
(123) вот на картинке посмотрит верхний ряд у стенки - там есть пролеты. знал бы о таком вопросе - выслал бы схему 1го склада, там ряды тоже разной длины и сдвинуты по разному от ворот. конфигурация склада разной может быть, номер ряда/стеллажа не всегда однозначно соответствует реальному расположению. |
|||
126
anatoly
15.02.15
✎
11:39
|
(124) это как например??
у нас задача - еще и рассчитывать оптимальный маршрут, типа мини-ТМС по площади склада. я уже вроде писал ранее почему... хотя, вроде начинаю догадываться, но лучше если пояснишь )) |
|||
127
Злопчинский
15.02.15
✎
11:41
|
(108) все зависит от частностей
Рассмотрим пример Допустим товарооборот таков что в одном заказе почти всегда присутствует почти весь ассортимент В этом случае совершенно пофиг как строить маршрут Его вообще можно не строить Сборщик все равно тупо подойдет к каждой ячейке Поэтому просто идет подряд по ячейкам |
|||
128
ГеннадийУО
15.02.15
✎
11:44
|
(125) Ну понятно, это в общем специфика вашего склада. В большинстве случаев хватает порядка обхода.
|
|||
129
Злопчинский
15.02.15
✎
11:52
|
(114) долбодятлы они везде
Одна из проблем это найти вменяемый персонал И я всегда говорю если начали автоматизацию склада то сразу заранее искать новый персонал У меня при наведении порядка в результате все раздолбаи и нераздолбаи но топырящие пальцы ушли со склада Из первоначального состава осталось 2-3 человека И как раз ребята из азии Очень хорошие как работники Они и на новом складе хорошо работают И тсд освоили быстро нормально А свои русские берешь на склад Вроде нормальный До первой получки В понедельник приходишь он трезвый но никакой ваще С него проблем больше чем пользы В итоге человек пять пройдет один ктото закрепится |
|||
130
rsergio
15.02.15
✎
11:52
|
(113) Возьмем средний склад. На нем расположены длинные стеллажи, вход в ряд возможен как в начале, так и в конце. Для сокращения пути обычно посередине стеллажей делают проход, снимая пару балок.
В итоге имеем, что в каждый ряд можно зайти с трех сторон - с начала, с конца, с середины. Сортировка по реквизиту всегда даст только один вариант обхода. Более продвинутая система позволит грамотно пользоваться проходами и посередине, находить такую последовательность перемещения, которая используют всю реальную топологию склада. Также часто склады разворачиваются на бывших производственных площадях, а там сложные помещения - ряды разной длинны, перпендикулярно друг другу и т.п. Тут простым числом сортировки не отделаешься. |
|||
131
Злопчинский
15.02.15
✎
11:53
|
(121) скинь мне если можно на почту [email protected]
|
|||
132
ГеннадийУО
15.02.15
✎
11:56
|
(130) Тут соглашусь на 100%, если имеем нестандартную топологию, то такой подход гибче.
|
|||
133
anatoly
15.02.15
✎
11:57
|
(127) этот пример слишком частный...
у нас до 100 позиций в заказе редко доходит. хотя - идея интересная, посчитать такую статистику. |
|||
134
ГеннадийУО
15.02.15
✎
11:59
|
(133) А у вас один наборщик собирает только один заказ?
|
|||
135
anatoly
15.02.15
✎
12:00
|
(130) совершенно верно!
и я так понимаю, вариант когда товар А лежит в начале ряда, а товар Б лежит в конце ряда, и в соседнем ряда за проходом по середине - версия 1.0 пошлет после А - в конец, а 2.0 - через проход в соседний ряд? |
|||
136
anatoly
15.02.15
✎
12:01
|
(131) ты мне в почту не ответил какая у вас ВМС ))
ответь, и можешь вашу схему кинуть - вышлю свою. |
|||
137
anatoly
15.02.15
✎
12:02
|
(134) в теории - один наборщик может сразу несколько собирать (в разные ПЕ) могут сразу несколько - один большой.
на практике с этим *опа, не всегда правильно проходит... |
|||
138
ГеннадийУО
15.02.15
✎
12:04
|
(137) А если один заказ на одну ПЕ не помещается, куда полная ПЕ должна приехать? И учитывается ли это при планировании маршрута?
|
|||
139
anatoly
15.02.15
✎
12:06
|
(138) есть ячейки сборки/комплектации - туда все свозят порциями.
это виртуальная зона очерченая на полу краской )) |
|||
140
ГеннадийУО
15.02.15
✎
12:08
|
(139) Я так понял, на твоей схеме они обозначена как ячейки сборки?
|
|||
141
Злопчинский
15.02.15
✎
12:10
|
вот кусочек моего склада - тут номера ячеек и есть по сути координаты
http://s015.radikal.ru/i332/1011/ab/cfcce08ec9fd.jpg |
|||
142
anatoly
15.02.15
✎
12:16
|
(140) да.
(141) ну у нас практически также, и даже тоже 7 ярусов. у вас чтоли четные ряда нумеруются в одну сторону - а нечетные в другую? |
|||
143
Злопчинский
15.02.15
✎
12:16
|
(125) на некоторых рядах у нас была тоже нерегулярность
например в мезонине нижний ряд паллеты а верхние более мелкие ячейки - нижний ряд нумеровался паралельно с верхними рядами например второй ярус номера 1-2-3-4-5-6, нижний ряд 2-5 - при сборке такая нумерация позволяла просто по порядку номеров ячеек и ярусов строить нормальный маршрут |
|||
144
Злопчинский
15.02.15
✎
12:19
|
(142) у меня нет рядов
у меня ПРОХОД когда у тебя "ряд" - то проге как-то надо говорить что ряд 1 и ряд 2 - это напротив друг друга у меня проход нумеруется абсолютно симметрично одна сторноа прохода нечетные стойки вторая сторона прохода четные соответствующие |
|||
145
ГеннадийУО
15.02.15
✎
12:19
|
(142)Нумерация произвольная, порядок обхода скорее всего будет таким как ты сказал...
|
|||
146
Злопчинский
15.02.15
✎
12:24
|
(133) у меня заказы совершенно разные может в заказе и 300 строк быть а может и 30. совершенно спокойно заказы и в 600 и 700 строк есть. пару раз были и более тысячи. в среднем я считал по статистике получается в районе 110 строк. те же самые 100-120 строк в час - скорость сборки. на одну строку приходится в среднем 3-4 захвата единиц товара из ячеек отбора
|
|||
147
anatoly
15.02.15
✎
12:26
|
(143) это как так - паллеты внизу а мелкие ячейки вверху??
афаик - паллеты как раз всегда сверху, чтобы сверху ричтрак их целые спускал - а снизу уже отборщик на обычном погрузчкике их дербанил по коробкам... |
|||
148
Злопчинский
15.02.15
✎
12:30
|
но вообщем некие реальные характеристики или относительные размеры надо задавать. иначе система тупит и змейку криво строит
она не понимает что из конца одного прохода надо не в начало следующего бежать а перепрыгнуть через два прохода в конец другого и по нему возвращаться в начало и потом вернуться в пропущенный ряд и закончить сборку им... |
|||
149
Злопчинский
15.02.15
✎
12:32
|
(147) это мезонин, там мелкая высота - три яруса всего в рост чела
|
|||
150
rsergio
15.02.15
✎
12:39
|
(144) Одно другому не мешает - в системе можно хранить и данные по рядам и проходам. Проходы использовать для логики, а ряды для нумерация и визуального поиска. Плюс иногда обход ячеек нужен именно по рядам, например, для подборщика со второго яруса на спецтехнике.
(148) Да, именно, в таких случаях, когда один ряд пропускается, системы с числовой сортировкой работают неверно, отправляя в другой конец ряда, заставляя идти в холостую. При правильной системе маршрутизации система отправит в ближайшую ячейку. |
|||
151
ГеннадийУО
15.02.15
✎
12:44
|
(150) И все-же, хочется услышать ваше мнение почему справочники для WMS предпочтительнее документов?
|
|||
152
H A D G E H O G s
15.02.15
✎
13:40
|
(117) "Так что и от JRE и от 1С он сильно отличается в лучшую сторону по производительности."
Вот жеж глупости пишите. 1С как правило не требуется производительность :-) Кроме как в xdto сериализации. Все. Это почти единственная вещь, где требуется производительность. Все задержки 1С связаны с тем, что документ пишет 100500 движений в разные регистры, которые тянут за собой таблицы остатков. Будь на месте 1С та же Дельфи - она бы точно также "тормозила" |
|||
153
ShoGUN
15.02.15
✎
13:43
|
(152) Вообще не в тему. Я абсолютно не про то, что 1С тормозит. Я про то, что на C# можно написать скриптовый движок, и он вряд ли будет по скорости сильно уступать 1С, написанной на плюсах. А вот скриптовый движок на 1С самому 1С точно будет сильно уступать.
|
|||
154
ГеннадийУО
15.02.15
✎
13:51
|
(153) И то, и другое никому не нужно, и смысл сравнивать?
|
|||
155
ShoGUN
15.02.15
✎
13:53
|
(154) Смотри (54)
|
|||
156
ShoGUN
15.02.15
✎
13:54
|
А насчёт "никому не нужно" - так это бабушка надвое сказала. Когда есть работающий аналог - конечно никому не нужно.
|
|||
157
ГеннадийУО
15.02.15
✎
13:57
|
(156) Именно, без такой экосистемы, как у 1С, любая учетная система будет иметь в РФ очень узкое применение.
|
|||
158
ShoGUN
15.02.15
✎
13:59
|
(157) Зачем вот в данном конкретном случае 1С? При том, что стандартные объекты не используются, а РС - это почти голые таблицы с ограничениями по индексам и ОРМ-обёрткой?
|
|||
159
ГеннадийУО
15.02.15
✎
14:01
|
(158) Самое главное - скорость разработки и наличие относительно недорогих специалистов, которые смогут поддерживать систему после окончания поддержки производителя.
|
|||
160
ShoGUN
15.02.15
✎
14:06
|
(159) А что, кроме 1С-а везде всё с нуля пишут? Насчёт дешевизны специалистов - то-то я не хочу слезать никуда, потому что за 1С платят в основном БОЛЬШЕ при прочих равных.
|
|||
161
Злопчинский
15.02.15
✎
14:27
|
(160) не знаю... не знаю...
|
|||
162
Злопчинский
15.02.15
✎
14:30
|
(150) навскидку не представляю, как без геометрических размеров-привязок обеспечить правильный универсальный механизм маршрутизации
|
|||
163
rsergio
15.02.15
✎
14:40
|
(162) Правильно, нужная привязка к координатам XYZ. Шаг может быть в любых единицах измерения - или реальных (мм, м) или в условных (1 у.е. ~ 1 м).
Далее нужно еще прописать маршрут движения, желательно отдельно для людей и машин (если они отличаются). |
|||
164
anatoly
15.02.15
✎
14:47
|
(163) привязка к Z как я уже писал - сомнительна. это уровень яруса.
ЕИ - вообще пофиг, размер ячейки пропорционально соотнося с ним ширину прохода между рядами. на картинке что я выслал - так и есть, все в условных рамерах ячеек. |
|||
165
Злопчинский
15.02.15
✎
14:48
|
(163) желательно не столько прописать разные маршруты, а спланировать такое взаимодействие персонала и техники чтобы и друг другу не мешали и минимизировали суммарные затраты на сборку например. тогда это можно назвать системой управления складом.
|
|||
166
anatoly
15.02.15
✎
14:50
|
(144) ты скажи уже наконец - какая у вас ВМС? с такой нумерацией. как партизан, мля...
|
|||
167
anatoly
15.02.15
✎
14:51
|
+ (164) перепутал кому отвечал ))
|
|||
168
rsergio
15.02.15
✎
14:57
|
(165) Надо разделять исходные данные, которые требуются для работы и оперативные решения.
Если система обладает нужными исходными данными (координаты ячеек, возможные пути движения разных видов техники, ограничения на нахождения различного оборудования внутри участка), то уже в оперативном режиме можно перенаправлять потоки исходя из загруженности персонала и занятости проходов на текущую секунду. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |