мы сейчас используем для складской логистики Арену ВМС - очень мягко говоря "оригинальное" решение - уже писал в одной ветке.
в среду были на семинаре сабжа: http://www.sevco-wms.ru/
правда непосредственно по софту сказали/показали крайне мало, в основном по самим процессам.
кто нибудь сталкивался с этим зверем вживую?
интересно насколько он реально удобен и для юзеров и для доработки.

просто, учитывая что у них ТМС - Антор (вчера создал ветку) а в виде КИС - RS-Balance (дос!!!) возникают некоторые смутные сомнения...

(67) Я так понимаю, если регистр накопления закрывается, и используются только актуальные остатки, особых тормозов быть не должно?

(65)  при таких нагрузках вообще ничего не будет
Можно даже на классических документах построить

(68) Так вот в том и вопрос, насколько система правильная...

(70) В перспективе гдето на порядок возрастет, еще в промэксплуатацию не запустились...

(67)  тут еще зависит наверняка от еоличества разрезов учета
Ести грубо товар-ячейка-фирма то и на тысячах и пару деятков тысяч номенклатуры будет болееменее

Если туда пркрутить всякие характеристики срокигодности и еще богзнает что то могут наверное начятся трудности

(67) Никогда не видел, ибо достичь такого можно только снеся кластерный индекс.

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

бредятина.

(69) Да, так и есть. Но это совсем другое, нежели имел ввиду (67).

(69) Единственная проблема - получение остатков на МОМЕНТВРЕМЕНИ(). 1С строила кривоватый запрос, который заставлял делать clusteredindexscan по таблице движений РН.

Вроде поправили (разбили запрос к движениям на 2 запроса с объединением)

(75) Ну я реально видел регистр накопления, таблица итогов которого за 2 года выросла до 170 Гб (при размере основной таблицы что-то около 30 Гб) что составило примерно треть размера всей БД)...

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

Далее посмотрите какие запросы формирует 1С чтобы получить актуальные остатки. Помимо отборов по измерениям всегда стоит отбор по дате.

(74) Попробуйте установить отбор не на измерение, а по ресурс и посмотрите план запроса

"бредятина."
Конструктивный диалог.

(78) Ну вот, условно говоря, имеем на складе 10 тыс. ячеек, 8 тыс. СКЮ. Таблица остатков разве будет большая???

(77) Либо не закрывалось ничего, либо дофига измерений, либо дофига остатков. Ничего страшного в размере нет. Страшное может быть в причине.

(72) смотри
У меня на самопальной клюшке за восьмичасовуюсмену смену лелалось порядка около 20 тыс сканирований примерно 10 пиплов
Причем это не было даже равно ерно размазано по смене
И все это разруливалось чисто файловой системой почти все
Выигрыш достигался тем что в частном случае у меня в онлайне по местам хранения количественный учет вести необходимости острой не было для удовлетворения потребностей в сборке

Проблемы вылазят может быть там где нужно наверное живое онлайнпланирование

Если есть возможность планировать заранее большую часть все проще

(78) "Далее посмотрите какие запросы формирует 1С чтобы получить актуальные остатки."

Хорошие она запросы формирует, попадающие в индексы.
Никаких тормозов от незакрытых/необрезанных остатков быть не должно.

Остаток на конец месяца (типовая настройка) минус движения до текущей даты.

(79) это не показатель вообще
Это вообще мизерные цифры

Определяющим имхо является темп обращения к данным по этим скю и ячейкам

(79) Смотрите - проводите инвентаризацию и просто ничего в базе не делайте. Что произойдет через месяц, через два, через год?

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

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

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

Я до такого мегадаопросветления еще не достиг

(84) Вырастет таблица итогов. И что в этом страшного, если я использую только текущие итоги?

(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

Веселый ребята работают в Арена.ВМС.

Умудрились пролюбить потерять кластерный индекс

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

(45) у ВК есть минус код надо реализовать через С++

(89) боже мой, все пропало?

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

(89) Вообще то это данные с рабочей базы. Запрос в 3.0 версии типа такого:

ВЫБРАТЬ ПЕРВЫЕ 1
    Взять.Владелец,
    Положить.Владелец КАК Владелец1
ИЗ
    РегистрСведений.усСтрокиПеремещения КАК Положить
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.усСтрокиПеремещения КАК Взять
        ПО Положить.ИдентификаторПакета = Взять.ИдентификаторПакета
            И (Взять.ТипОперации = ЗНАЧЕНИЕ(Перечисление.УстипыОпераций.Взять))
            И (Положить.ТипОперации = ЗНАЧЕНИЕ(Перечисление.УстипыОпераций.Положить))
ГДЕ
    Взять.ИдентификаторПакета = &ИД
    И Положить.ИдентификаторПакета = &ИД
    И Взять.Ячейка.ТипЯчейки = ЗНАЧЕНИЕ(Перечисление.усТИпыЯчеек.ТорговыйЗал)
    И Положить.Ячейка.ТипЯчейки = ЗНАЧЕНИЕ(Перечисление.усТИпыЯчеек.ТорговыйЗал)
    И (НЕ Взять.Ячейка.КаналСбыта = Положить.Ячейка.КаналСбыта)
    И (НЕ Взять.Ячейка.КаналСбыта = ЗНАЧЕНИЕ(Перечисление.КаналыСбыта.Пустаяссылка))
    И (НЕ Положить.Ячейка.КаналСбыта = ЗНАЧЕНИЕ(Перечисление.КаналыСбыта.Пустаяссылка))

При этом ИдентификаторПакета - это ресурс. Индексации не стояло. Поэтому отбор по нему - TableScan. Вопрос не к нам, а к разработчикам этой системы и тем, кто ее поддерживал.

(93) Весело там у вас :-)

(93) Это написали Акселотовцы?

(93) Ничего не понял. В моем понимании, при получении текущих итогов идет обращение только к таблице итогов с отбором по периоду. Где здесь замедление работы при увеличении количества записей?

(95) Не знаю кто писал, конфа была перепахана внутренним отделом разработки. Замеряли производительность, искали запросы в топе по времени, выясняли причину, давали советы.

Там база более 100 Гигов весила, некоторые таблицы по 30 млн. записей содержали. Запросы по 5-10 секунд выполнялись. При этом работники с ТСД все это время стояли и смотрели на экран в ожидании когда появятся следующие данные...

(96) Таблица итогов - одна.
Она - плоская, гигантская.
Даже чтобы получить текущие (на 5999 год) итоги - надо выбрать из всего гигантского количества.

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

(98) Гигантская это сколько? Сотни миллионов записей?

(98)
геометрически-> логарифмически.

(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

(99) Почитайте про вычислительную сложность, деревья поиска, b+ деревья (на них ms sql строит свои индексы, на них же построены заголовки NTFS). Это полезно.

(102) вот что значит человек сдал на эксперта :)))

(103) Это мелочи в сравнении с экспертом.

(101) Понятно, т.е. значительное замедление мы получим только на огромных объемах данных. К счастью, 1С позаботилась о нас, и для регистров накопления можно оставить использование только текущих итогов, и тогда действительно проблемы с использованием РН в WMS мы можем получить только засчет роста числа одновременно работающих пользователей.

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

(32) я просто совмещал оборот товаров и выемку из ячеек. и обнаружил такой факт. это говорит о вообще никаком взаимодействии офиса и склада. одни смотрят в КИС (УТ) другие в ВМС и собственно на стеллажи, и думают что на другом конце итак все знают.

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

наш ИТ-директор верно говорит: "ИТ-отдел = высшая нервная система компании. мы видим все. другие видят только свое а на остальное кладут болт. и начинается *опа."

(106) Я так скажу, без поддержки собственников бизнеса на ИТ все положат болт...

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

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

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

(36) аналог документа - справочник. аналог ТЧ - подчиненный справочник СтрокаДокументаБлаБлаБла.

(49) какая у вас ВМС, если не секрет?

(54) C# итак по идее скриптовый язык. ибо под .НЕТ.
сам .НЕТ - фреймворк, как JRE или платформа 1С.
программа на C# - п-код исполняемый фреймворком.
как то так...

(110) Пока проект не закончен, не хочется публично озвучивать. Но никому не порекомендую, очень много проблем при внедрении...

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

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

(107) пытаемся учить правильному пониманию, процесс со скрипом, но идет вроде...

(113) как ты настроишь порядок обхода без координат??
я сразу не смог придумать...
как я писал как у СЕВКО - не вариант, у нас склад - 74 ряда стеллажей, 2 ричтрака разъезжаются спокойно.

(111) Не совсем так, .NET - не интерпретатор, а JIT-компилятор. Так что и от JRE и от 1С он сильно отличается в лучшую сторону по производительности.

(116) Поясни, что ты в виду под координатами имеешь?

(116) Да, кстати склад у нас примерно такойже..

(118) X,Y - координаты рядов на полу, Z-высота ячейки (хотя по моему лишнее - т.к. уровень яруса итак есть)
(119) такой же - как я у СЕВКО описал?

+ (120) если интересно - могу схему топологии из Арены в почту кинуть.

(121) Скидывай gennayo собачка на яндекс.ру. Склад у нас такойже как у вас.

(120) Не очень понятно, зачем это если есть идентификатор ячейки вида Ряд-Стеллаж-Номер яруса-Номер ячейки...

(108)  ячейкам присваиваются рейттинги всякие или порядки обхода и эти числа никак не связаны с номерами ячеек
И маршрут строится исходя из этих рейтингов/порядков обхода

Это типа универсальность

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

(122) выслал.
(123) вот на картинке посмотрит верхний ряд у стенки - там есть пролеты.

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

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

(124) это как например??
у нас задача - еще и рассчитывать оптимальный маршрут, типа мини-ТМС по площади склада.
я уже вроде писал ранее почему...

хотя, вроде начинаю догадываться, но лучше если пояснишь ))

(108)  все зависит от частностей
Рассмотрим пример
Допустим товарооборот таков что в одном заказе почти всегда присутствует почти весь ассортимент
В этом случае совершенно пофиг как строить маршрут
Его вообще можно не строить
Сборщик все равно тупо подойдет к каждой ячейке
Поэтому просто идет подряд по ячейкам

(125) Ну понятно, это в общем специфика вашего склада. В большинстве случаев хватает порядка обхода.

(114)  долбодятлы они везде
Одна из проблем это найти вменяемый персонал
И я всегда говорю если начали автоматизацию склада то сразу заранее искать новый персонал
У меня при наведении порядка в результате все раздолбаи и нераздолбаи но топырящие пальцы ушли со склада
Из первоначального состава осталось 2-3 человека
И как раз ребята из азии
Очень хорошие как работники
Они и на новом складе хорошо работают
И тсд освоили быстро нормально
А свои русские берешь на склад
Вроде нормальный
До первой получки
В понедельник приходишь он трезвый но никакой ваще
С него проблем больше чем пользы
В итоге человек пять пройдет один ктото закрепится

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

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

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

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

(121)  скинь мне если можно на почту [email protected]

(130) Тут соглашусь на 100%, если имеем нестандартную топологию, то такой подход гибче.

(127) этот пример слишком частный...
у нас до 100 позиций в заказе редко доходит.

хотя - идея интересная, посчитать такую статистику.

(133) А у вас один наборщик собирает только один заказ?

(130) совершенно верно!
и я так понимаю, вариант когда товар А лежит в начале ряда, а товар Б лежит в конце ряда, и в соседнем ряда за проходом по середине - версия 1.0 пошлет после А - в конец, а 2.0 - через проход в соседний ряд?

(131) ты мне в почту не ответил какая у вас ВМС ))
ответь, и можешь вашу схему кинуть - вышлю свою.

(134) в теории - один наборщик может сразу несколько собирать (в разные ПЕ) могут сразу несколько - один большой.

на практике с этим *опа, не всегда правильно проходит...

(137) А если один заказ на одну ПЕ не помещается, куда полная ПЕ должна приехать? И учитывается ли это при планировании маршрута?

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

(139) Я так понял, на твоей схеме они обозначена как ячейки сборки?

вот кусочек моего склада - тут номера ячеек и есть по сути координаты
http://s015.radikal.ru/i332/1011/ab/cfcce08ec9fd.jpg

(140) да.
(141) ну у нас практически также, и даже тоже 7 ярусов.
у вас чтоли четные ряда нумеруются в одну сторону - а нечетные в другую?

(125) на некоторых рядах у нас была тоже нерегулярность
например в мезонине нижний ряд паллеты а верхние более мелкие ячейки - нижний ряд нумеровался паралельно с верхними рядами например второй ярус номера 1-2-3-4-5-6, нижний ряд 2-5 - при сборке такая нумерация позволяла просто по порядку номеров  ячеек и ярусов строить нормальный маршрут

(142) у меня нет рядов
у меня ПРОХОД
когда у тебя "ряд" - то проге как-то надо говорить что ряд 1 и ряд 2 - это напротив друг друга

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

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

(133) у меня заказы совершенно разные может в заказе и 300 строк быть а может и 30. совершенно спокойно заказы и в 600 и 700 строк есть. пару раз были и более тысячи. в среднем я считал по статистике получается в районе 110 строк. те же самые 100-120 строк в час - скорость сборки. на одну строку приходится в среднем 3-4 захвата единиц товара из ячеек отбора

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

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

(147) это мезонин, там мелкая высота - три яруса всего в рост чела

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

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

(150) И все-же, хочется услышать ваше мнение почему справочники для WMS предпочтительнее документов?

(117) "Так что и от JRE и от 1С он сильно отличается в лучшую сторону по производительности."

Вот жеж глупости пишите.
1С как правило не требуется производительность :-)
Кроме как в xdto сериализации. Все. Это почти единственная вещь, где требуется производительность.

Все задержки 1С связаны с тем, что документ пишет 100500 движений в разные регистры, которые тянут за собой таблицы остатков.
Будь на месте 1С та же Дельфи - она бы точно также "тормозила"

(152) Вообще не в тему. Я абсолютно не про то, что 1С тормозит. Я про то, что на C# можно написать скриптовый движок, и он вряд ли будет по скорости сильно уступать 1С, написанной на плюсах. А вот скриптовый движок на 1С самому 1С точно будет сильно уступать.

(153) И то, и другое никому не нужно, и смысл сравнивать?

(154) Смотри (54)

А насчёт "никому не нужно" - так это бабушка надвое сказала. Когда есть работающий аналог - конечно никому не нужно.

(156) Именно, без такой экосистемы, как у 1С, любая учетная система будет иметь в РФ очень узкое применение.

(157) Зачем вот в данном конкретном случае 1С? При том, что стандартные объекты не используются, а РС - это почти голые таблицы с ограничениями по индексам и ОРМ-обёрткой?

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

(159) А что, кроме 1С-а везде всё с нуля пишут? Насчёт дешевизны специалистов - то-то я не хочу слезать никуда, потому что за 1С платят в основном БОЛЬШЕ при прочих равных.

(160) не знаю... не знаю...

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

(162) Правильно, нужная привязка к координатам XYZ. Шаг может быть в любых единицах измерения - или реальных (мм, м) или в условных (1 у.е. ~ 1 м).

Далее нужно еще прописать маршрут движения, желательно отдельно для людей и машин (если они отличаются).

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

на картинке что я выслал - так и есть, все в условных рамерах ячеек.

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

(144) ты скажи уже наконец - какая у вас ВМС? с такой нумерацией. как партизан, мля...

+ (164) перепутал кому отвечал ))

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