Имя: Пароль:
1C
 
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) Надо разделять исходные данные, которые требуются для работы и оперативные решения.
Если система обладает нужными исходными данными (координаты ячеек, возможные пути движения разных видов техники, ограничения на нахождения различного оборудования внутри участка), то уже в оперативном режиме можно перенаправлять потоки исходя из загруженности персонала и занятости проходов на текущую секунду.