Предыдущая ветка
WMS на 1С - часть 2

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

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

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

И прочее по существу складских вопросов
В т.ч. как оно все живет на 1С...
и Вообще: выживут ли WMS или их вытеснит УТ11 с большой доли несильнонагруженных/извращенных складов

... потихоньку дозреваем до динамического размещения - позволит сэкономить процентов ~25% ячеек (по первым тупым грубым прикидкам).

Читаю очередную умную книжку по складам... есть полезности. был в Акселоте на минисеминаре на тему "Что должен знать руководитель ИТ про автоматизацию склада", как и предполагал - почти ничего полезного не рассказали, по сути был тривиальный ликбез про склад. По 10балльной системе - полезность=3, ходил больше с народом пообщаться...

(2) что за книжка?

выживут WMS ибо у УТ задача несколько иная

(4) http://www.nova-it.ru/products/sklad/index.php?gclid=CJKkr86B4skCFYHVcgodwhwLRg
Затащить в уг оттуда адресное хранение; и wms будет не нужна по сути

(0) Кстати я так и не посмотрел хорошо это адресное хранение в УТ 11. Что там за фишки, можешь вкратце пояснить?

(0) УТ 11 вытеснит? не смешите...

(2) имхо все эти "семинары" единственным смыслом имеют впарить свою систему.

(7) на них прекрасно отрабатывается второй смысл - общение, поиск единомышленников, расширение круга знакомств с коллегами, вопросы к более опытным, помощь менее опытным.
а сам "акселот" - лишь предлог :-)

(0) большинству WMS просто не нужно.
Большинство даже без адресного хранения обойдется...

(1) Динамическое размещение. У меня другого никогда не было. Когда склад в пиковые моменты забит до 110%, а обычно на 95%, никакого другого размещения не возможно.

Мы на запчастях практически внедрили WMS на трех магазинах и оптовом складе. Сейчас заканчивают инвентаризацию на складе. 200 тыс единиц хранения - это много.
Самое интересное, что удается обходиться без оператора WMS. Я даже немного удивлен.

(1) зависит от постановки целей (опыта складских) и продвинутости алгоритма

(11) 200+ тыс СКУ автозапчастей - это нормально. это только для JLR у нас столько было... а как вы аналоги учитываете?

SKU - 40 тыс.
Аналоги и замены прописаны в базе, а учет по реальным артикулам.
  В момент продажи переклеивание этикеток по артикулу, который просит покупатель :)

И все-таки, использование в WMS на 1С регистров накопления насколько большое зло? Померял сейчас производительность - запись в БД одной строки отбора занимает 0.6 сек, из них 0.5 - запись в регистры накопления, что ускорить проблематично. Ну и еще занимательная информация - пересчет итогов регистров накопления с последующей реиндексацией привело к уменьшению размера базы на 20%...

(15) 0.5 сек - скорость записи одной строки в регистр накопления. Это надо обратиться к разработчикам вашей WMS

  Я сейчас сделал замер производительности при проведении документа РасходныйСкладскойОРдер
время прведения << 1 сек
  Никаких проблем с быстродействием нет. Проблемы с быстродействием возникают при работе с большими списками и большими документами. Типа Установка цен номенклатуры для 40 тыс строк. Но это беда 8-ки.

(15) об этом предлагаю пообщаться с rsergio - Арена только на РС сделана.

(16) К разработчикам бесполезно, туповаты. Эта скорость правда на тестовом сервере, рабочий раза в два-три быстрее. В общем не критично, так как блокировок нет, параллельной работе не мешает...

(17) Ну он мне архитектуру не покажет, секрет :)

(19) нашел старое письмо ;)...

(18) Разработчики разработчикам рознь.

+ (20) ответил.

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

(6) на УТ11 - меня не хватает, специфика моей деятельности в несколько иной плоскости. Посмотри у меня в профиле на ИС группу http://catalog.mista.ru/community/groups/22/ - я в ней аккаммулирую всякое полезное по складскому делу - там же и статьи всякие по УТ11 и адресность в ней - есть дельные.

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

(15) "запись в БД одной строки отбора занимает 0.6 сек" - чето сильно много мне кажется... у меня вроде ок, персонал не жалуется - ниче не тормозит/не ждет, но у меня и объемы совсем не ваши... Например, тот же алгоритм на клюшках у меня запись вообще практически мгновенно идет... 0.6 сек - это просто нереально много я думаю, может там целый пакет пишется..? или еще что..? опять же посмотреть что занимает основное время - запись сама или модификация индексов..? где узкое место...?

(18) Если вы такие умные - хрен ли вы своим ит-отделом сами вмс не написали..? ;-)

(21) а мне?

(25) Может индексы, а может запись итогов. Сейчас в основных регистрах примерно по 25 млн записей, наверное свертывать пора... 0.6 сек это не много такто, общее время отклика всеравно меньше секунды на операцию, переход наборщика к следующей ячейке полюбому дольше происходит...

(15) ...запись в БД одной строки отбора занимает 0.6 сек
для планировщика заданий нормально генерация 25-30 строк в секунду на тех же регистрах накопления.

(29) Планировщик работает в несколько потоков, но такого результата даже близко нет... Испортили горе-разработчики, даже не удосужившиеся убрать из кода упоминания об ООО "Логитон"?

Для складов электротоваров (в т.ч. кабеля) можете чего-нибудь посоветовать?

(31) посоветовать могу Рубанова - его решение выросло на электротехнике

(30) хз, у мну на больших заказах по 200-300 строк планируется достаточно быстро, примерно как в (29). а может и быстрее.. может там у вас горе-железо, пень десятилетней давности водно ядро? ;-)

ради интереса посмотрел сейчас на клюшечном сервере: примерная средняя "производительность" при проведении документов составляет ~60 строк в секунду, а каждая проведенная строка генерит ~10 записей в регистры, то есть средняя производительность на клюшках составляет ~600 операций в секунду (причем существенную часть затрат составляет временной расчет регистров задним числом). И это у меня клюшечный сервер, который послабже WMS-восьмерочного...

на вмсине по идее при планировании overдофига чтений и запросов всяких для получения и перетасовки данных - может здесь где-то засада?

.. или тупо снеговик сам по себе тормозной...?

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

(36) Именно остатков или записей?

(37) желательно и того и другого - сколько записей в итогах по регистру и сколько записей в движениях

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

(39) движения проще простого Select Count(*) From РегистрНакопления.МойЛюбимыйРегистр

(40) мну еще надо посмотреть - где мне этот запрос выполнить - есть ли у меня там консоль хоть какая-нить.. ;-)

Можешь в скуле написать :)

главное знать имя таблицы с нужным регистром

(42) фигню ты мне какую-то подсунул, не работает в консоле пришлось напрячься и состряпать запрос с русскими Выбрать и прочее ;-) ужас...

3 228 500 - всего-то... я блин, считаю быстрее сервера ;-) еще в районе (35) сообщения я оценил кол-во записей по движениям в 3,5 млн - просто тупо зная среднедневную нагрузку, и ошибся всего 8.4% ;-) То есть, как учили нас учителя, настоящий инженер без всяких компьютеров может оценить с точностью не более 20% цифры в той области где он спец...

3.2 млн - это конечно не 25млн - при 25 млн может и у меня будет нещадно тормозить...

(44) Моя 8-ка считает . хз что там может быть не так

Тоже неплохо. У меня в БП 3.0
Select Count(*) From РегистрБухгалтерии.Хозрасчетный

9 966 981

Тормозит примерно одинаково что с 3 млн что с 9

(47)  гвозди поштучноуникально учитываете?

(48) Почему? Купи-продай. В базе 30 фирм. По некоторым данные с 2011 года, часть только в 2014 году начала работать в этой базе.

(33) На рабочем сервере при автоматическом планировании в 8 потоков получается около 20 операций в секунду, значит рабочий сервер не в 3, а примерно в 5 раз мощнее тестового. А может еще и SSD диски хороший прирост скорости записи дают...

Для просмотра размера и количества записей в таблицах я использую отчет https://yadi.sk/d/eSCqdvrOmJsb5

(51) Тьфу, не то. https://yadi.sk/d/fDSGMJiomJsqz

(49) у меня такое колво набежало за полтора года (это имено складская база)

Посмотрел в торговой клюшечной базе
Самый большой регистр по количеству движений это заявки
Порядка 12 млн движений
Итоги раз в 50-70 меньше

Возможен вариант вообще простой
Регистры накопления в части итогов вообще не нужны
Допустим самый простой вариант
Когда есть только остатки товаров
Достаточно только записей текущих итогов гдето (вроде в восьмерке даже есть такой вариант когда храняться только актуальные итоги и все)
все другие прошлые итоги абсолютно неинтересны
Их можно тупо рассчитать по текущим итогам и зафиксированным движениям
Как мне кажется такая задача для склада в общей канве работы является достаточно редкой и морочить ради нее региистр накопления с хранением промежуточных итогов в части обеспечения оперативной работы смысла нет

а вот что является основным ограничителем для планирования на уровне - 20-30 строк в секунду - было бы интересно узнать хотя бы в общих чертах от специалистов

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

(6) см. по УТ11
http://www.youtube.com/watch?v=f-B3XtPJTUs&list=PLCE0CD976C0A9507E&index=1
https://www.youtube.com/watch?v=f-B3XtPJTUs
https://www.youtube.com/watch?v=tD3FmkUOBu8
https://www.youtube.com/watch?v=wQNWAUoCMlc

УТ11 убивала меня своей тормознутостью. Там поиск по штрих коду занимал 1-3 секунды.
  Но с размещением/отбором там проблем нет. Скорость вполне приемлимая и алгоритмы красивые. Я их даже перенес в Рарус-Авто, правда с исправлением косяков.

20-30 строк планирование размещения или отбор - у меня сейчас наверное есть. Это в один поток. В понедельник гляну на что тратится основное время. Я думаю на запрос. Там как раз обрабатывается " рейтинги, типоразмеры вместимости, зоны размещения, заполненность ячеек, свободные объемы, совместимости" и прочая лабуда. К алгоритму подбора возвращается уже список    ячеек с приоритетами, куда надо все класть.

(58) а что оно там искало-то по 3 секунды?

Sasha_1CK что-то молчит, 2 меясца прошло - как у них там с внедрением Акселота...

Я думаю никак. Лично я в Акселот не смог пройти стандартную цепочку приемка-размещение-отбор-отгрузка. Впрочем в УТ11 тоже.
В этих системах малейшая ошибка приводит к необратимым последствиям. И развалу всего учета. При этом найти ошибку зачастую не возможно.
  А представьте что творится, когда работают 20-50 человек.

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

(56) Хороший ты вопрос задал. Полез смотреть отладчиком - и что я вижу, запрос, а в нем обращение к реквизитам измерений регистра накопления составного типа без ВЫРАЗИТЬ. Не удивительно, что была деградация производительности с ростом объема данных...