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

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

Забей
Всемвмски с которыми я встречался общался на базе одинце декларируются как мощные и гибкие

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

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

Любые вмсники одноэсники на все вопросы проблемные отвечают одинаково типа такой возможности нет но это без проблем напишем под вас

На показ процессов положи большой болт
Основные процессы везде практически одинаковы и близки
Все заморочки начинаются когда хочется удобств и тонкостей именно под частности своих процессов
И тут начинается самое интересное
Так что полюбасику нормальный выбор вмсины займет просто нетмоверно дофигища времени что весьма проблематично

Так что тут надо смотреть базовые структуры метаданных ядра системы то есть грубо говоря как сделаны хранилища информации и насколько они объемлющи и разнообразноуниверсальны
Второе на что надо смотреть это на обеспечение и механизмы работы при больших нагрузках если для вас это критично то есть архитектуру системы

Все остальное строится по принципу сделано в какомто проекте может подойдет еще комуто

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

Вот так

имхо ясен пень
Севку бегло смотрел на выставках
Не впечатлился нисколько
При беглом осмотре они все примерно одинаковые

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

Удобство для юзеров в большинстве определяется продуманностью и дружелюбием интерфейсов

А на это разработчики вмс тратят силы в последнюю очередь
Это примерно как крутить гайки газовым или разводным ключом или плоскогубцами
Крутится? Крутится? Ну так значит зашибись!

также надо посмотреть насколько легко можно при программировании отойти от универсальных механизмов заложенных в решение

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

Резюмируя
Если ты не распишешь подробно всю свю цепочку процессов на складе
Если не попросишь продемонстрировать каждую рассматриваемую в кандидаты вмс как отрабатывается эта цепочка
Если не сравнишь все эти демки
То выбор вмс это на 80-90 процентов тычок пальцем в небо

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

Только тогда можно составить примерное мнение
А так как рынок вмс достаточно узок то найти такой склад это редкая удача

(2) дык вот же: http://www.arena-wms.ru/

а это выступление разработчика на инфостарте:
http://infostart.ru/public/78075/

и там некто CheBurator отметился ))

(1) не понял к чему столько много буков...

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

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

потому и спросил - видел ли кто эту СЕВКУ в реале. а несколько страниц пространных размышлений мне читать вообще не интересно и скучно...

(7) это типовое поведение ВМСников.
пусть проводят, только бесплаьно ;-)

(6) на сайте Арены в отличие от других ВМСных сайтов есть хоть какая-тио полезная инфа...

(7) было бы интересно полслушать что сейчас "плохо" на арене. если что - стучись в скайп Zlopun или мыло e.meil@mail.ru

(0) Приветствую.

В Арене появился встроенный модуль мини-TMS для расчета маршрутов.
http://www.arena-wms.ru/news/96-news.html

Возможно этот функционал покроет потребности в планировании маршрутов.

(11) у нас не столько в ТМС потребность, сколько во внутренних процессах.
подпитка, оптимизация маршрутов ричтраков, приоритеты отгрузки на 16и воротах и т.д.
мы можем в лично пообщаться? мои icq/email в профиле.

(12) странно, что юзавшие арену до этого не могли пообщаться с главным по арене... ;-)

(13) Есть несколько контор, которые решили сами поддерживать систему, 1С все же.

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

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

(15) Плюс часто проги меняются, поэтому каждый добавляет что-то от себя и когда приходит новый - смотрит на этот "бутерброд" и становится страшно :)

(16) ну раз от себя добавляют  значит не хватает чегото... или не научили как функционалом юзаться.

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

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

(17) Пообщался с автором, он пришел недавно на новое место. Там стоит самая первая версия 1.0 которая не обновлялась ни разу, до этого были другие программисты, кто как понимал дописывал. Склад процессы запустил т.к. в какой-то момент не мог договорится с ИТ.

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

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

Правильная WMS же не УТ и не БП, с наскока не понять, нужно время. Тем более когда в системе нет ни одного документа и регистра накопления, многие 1С-ники впадают в шок по началу :)

(18)  понятно
Я ваще не понимаю как можно нормально вмс выпилить если склад и ит не будут очень очень плотно работать
Вообще не представляю
Имхо какаято (__о__) получится
Склады тоже часто страдают по типу главное сейчас быстро сделать
А как оно потом будет мало думают

Опять же не на всех складах
А может и на большинстве нет настоящих логистов по складским процессам
И тут склад начинает изобретать то что кажется правильным
И дплеко не факт что низобретают то что действительно надо
Хорошо когда есть рядом ктото в теме и можно посоветоваться
А если нет?

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

А так отсутствие документов как таковых в классическом понимании одноэс меня не пугает

Я вполне себе представляю систему базирующуюся на атомарных принципах

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

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

Ну так даже лучше пооцессы болееменее обкатанные
Внедрять легче
Мне
А внедренцам. Со мной наверное тяжело смайл
Но тем не менее с конца мая в боевом режиме работаем и ок
Есть профиты даже
Но есть места которые напрягают
Одно из них планирование и перепланирование заданий
И некоторые проблемы с отбором при отсутствии учета по тарности
И пока непонятно лично мне (не по нашей вис а вообще) именно как принцип построения более правильный - как следует правильно реализовать многоступенчатую упаковку
Да и прочих мелочей всяких хватает
Работы есть всегда
Всякие сетки все время выибоны всякие подкидывают
И прочее

Кстати по отклику системы на тсд
У меня уже начинается дискомфорт когда отклик превышает где-то 0.3 сек
Одна секунда на регулярных операциях это уже дискомфорт вполне ощутимый

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

(17) какая у вас ВМС?

(18) да, как вы ушли - было 3/4 человека. причем некоторые, даже не касаемо ВМС, такой код писали, что я ох@#$аю когда начинаю разбирать.

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

в итоге, из 6500 SKU в остатке за 2014 г. всего 5900 отгружали, при этом в 2000 (!!!) ячеек стоят целые нетронутые (!!!) паллеты.

про инвентаризацию в этот НГ (сколько потеряли и сколько нашли) я вообще молчу...

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

(19) так и получается - последние 6 лет ит/склад/закупки/продажи жили в параллельных реальностях.

в как прошлой осенью стала начинаться *опа - верхнее руководство начало думать что надо как-то что-то оптимизировать...

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

+ допустимая длина около 100м на витую пару, когда сигнал тупо в сети тухнет. у нас примерно 250*100 осн.склад.

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

(25) на начальном этапе даже оптимизировать ничего не надо. хотя бы "заставить" жить связной жизнь разные системы

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

(28) ну первая задача по идее - быстро скинуть неликвид, и оптимизировать пополняемость - за счет чего поднять оборачиваемость = профит.
я не прав?

Я лично остановился на Акселоте. Как только ТСД закупим то пущу. Пилил очень долго. В основном упрощал процессы.

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

ну и тут смотри когда склад - обеспечивающее подразделение.

(31) угумс...
но зачем? (ехидно так) - это же гибкаонастраиваемя программа!!??

(33) Да нифига она не гибкая. 3-ка по крайней мере.

(34) Опередил :)
Задатки гибких настроек появились только в 4-ой версии.

Где-то стало хорошо, где-то еще не хватает, где-то совсем закостенело.

Например, метод отбора контейнеров - FIFO, LIFO, свободный. И все. Сортировка по датам партий только по FEFO и LEFO. И никак не привязана к контрагентам.

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

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

Но я надеюсь, что со временем все поправят ;)

(18) Если не секрет, что выступает аналогом документов? И что плохого в наличии документов и регистров накопления?

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

(37) Я какраз таки очень в теме, и мне реально интересен этот вопрос...

(36) А зачем какие-то аналоги объектов?

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

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

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

Документ как объект 1С имеет свои особенности, но важнее какие ограничения несет для себя регистр накоплений. Он содержит избыточную информацию и предназначен для ведения управленческого учета, но не особо удобен для высоконагруженных систем.

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

(39) Не знаю, как у кого, но у меня лично возник вопрос - зачем это на 1С делать? С тем же успехом можно было сделать на любой реляционной СУБД без всяких прослоек.

+(40) Ну что-то ещё легкое в качестве морды взять.

(40) Почему бы это не сделать на 1С?

1С - идеальная система для .... всего.
Я не шучу.

(40) Как минимум
1. 1С имеет очень высокую скорость разработки
2. Заказчики хотят снижение рисков, они не хотят закрытый продукт с непонятной поддержкой, многие хотят именно 1С
3. Лично я фанат 1С :)

Чего нет в 1С - можно дописать через ВК.
Для всего остального есть 1С :-)

Единственное - нельзя создавать свои индексы, рассово верные.

Вот, например мне анализ отсутствующих индексов часто талдычит об отсутствии в кластерном индексе таблицы движений РН поля "_Active". И тут я бессилен.

(43) Идеальная система - та, которую ты знаешь. Ты вон ещё и Дельфи любишь.
(44) @Ненавижу1С не хватает :))
1 и 2 пункт - очковтирательство. 3 - религия.

(46) Отсутствие возможности создать индексы - действительно сильное ограничение. Приходится выбирать между двумя простыми объектами - справочниками или регистрами сведения, которые отличаются построение индексов (включая primary key)

(39) Ну так в чем недостатки, расскажите. Ибо сейчас какраз имеется WMS с документами и регистрами, где ждать проблем?

(47) Я бы не стал ничего серьезного писать на Дельфи. Ни с нуля, ни с готовыми комплектами.
Учетные системы что на Дельфи, что на C# убоги.

Удел Дельфи - системные, мелкие вещи. Даже так. Удел Дельфи - НЕ учетные системы.

@Ненавижу1С - дятел, без него разберемся.

(47) Несколько лет назад WMS на базе 1С считалось "низшим сортом", приходилось даже скрывать платформу разработки на первых порах.
Сейчас, после того как люди поработали с западными продуктами, поработали с отечественными закрытыми продуктами, они идут в сторону 1С чтобы не быть зависимым от одной команды и не видеть табличек, требующих продлить лицензию, а иначе WMS перестанет работать...

(49) Не надо ждать проблем - если все работает, до здорово! Просто есть склады, где это может работать очень медленно

(49) Недостатки, в 95% - в программистах, которые в глаза не видали планов запроса.
Если напоритесь на 5%, которые на !каждый! свой запрос смотрят план на больших данных - все будет в порядке.

Я года 3 назад думал, что пишу хороший, годный код. Профайлер развеял мои заблуждения.

(50) >Учетные системы что на Дельфи, что на C# убоги.
Это так из-за убогости концепции. Ничто не мешает применить подход игростроя - движок написан на обычном языке общего назначения, на нём же написан интерпретатор встроенного скриптового языка. Юзаем встроенные объекты и описываем их поведение скриптами. И получаем... 1С. На C# или на Дельфи...

+(54) Проблема лишь в том, что движок будет долго писаться, с нуля-то.

(52) Ваша правда. У меня есть опыт восстановления быстродействия просто проанализировав запросы.
http://www.arena-wms.ru/news/89-news.html

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

(54) Проблема в том, что каждый отдел АСУТП пишет свою учетную систему. С шлюхами и блэкджеком. При 1С такого не было!

(37) а что делать если реально нужную инфу по крупицам собирать приходится

Это хорошо что rsergio пишет всякое полезное
Мало какие вмсники пишут чтото более подробное чем просто презентации
А уж чтобы чтото про внутренности какихто систем так это вообще можно сказать никогда нигде

(57) Почему-то в вебе себе такого безобразия никто не позволяет. Есть пачка фреймворков, на них всё ваяется. Просто 1С - высокоуровневый фреймворк.

(56) Хехехе.

TableScan по РегиструСведений.
Кластерный индекс снесли для красивой фоточки?

Вангую что типовые конфиги будут все больше и больше покрывать потребности большинства мелких и средних складов

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

А для всяких фирм свои одинэсники докрутят к типовому функционалу нужные плюшки и все

ТС, извини за небольшой офф..
(61) друже!..  у 1С на это действо "всё больше и больше" было лет этак 19-20..
и .. и ничего! потому, как сколько бухий, фирм, и пр.др., столько и вариантов учета, управления, представления данных и т.д...

На всех просто не угодить, затея заранее обречена на провал :)

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

А все разнообразие на более высоком уровне
На уровне создания рабочих мнст
Тсд
Расписаний и всяких поанировщиков

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

(51) Вот например такая архитектура - классические документы, только строками табличных частей выступает для всех документов специальный документ. Один регистр накопления, в котором хранятся остатки номенклатуры. На каких объемах начнутся проблемы (сейчас в сутки отгружается примерно 8-10 тыс. строк заказов)?

(64) Вторая строка в твоем посте - в самую точку! :)

(60) Никогда не видели TableScan на регистре сведений? Много пропустили :)

(65) Я не Ванга, надо смотреть способ использования. В простом и "прямом" использовании можно добиться хороших результатов.

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

(65) В правильной системе проблемы начинаются не на "объеме данных" а на "количестве пользователей".

(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)  скинь мне если можно на почту e.meil@mail.ru

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