На сколько я знаю многие WMS на базе 1С уходят от регистров накопления в сторону регистров сведений. И в принципе это логично поскольку например хранить резервы в регистре остатков особого смысла нет. История по движениям с резервами как правило никому не нужна. Есть срез на текущий момент и всё. Минусы которые я вижу это необходимость траты ресурсов на группировку записей, лишаемся таблицы итогов что явно не ускорит поиск записей, хотя учитывая что есть индексы и общее количество записей будет не велико может расходы и минимальны. Но наибольшие непонятки как это ударит производительности при записи наборов при увеличении количества пользователей?

Акселотовцы на сколько я знаю в свое время ушли на Регистры сведений. Как там у них сейчас дела в последних версиях?

В 8.3 к регистру сведений добавят таблицу "итогов"
так что опаздал

(2) а смысл? Или там можно будет сразу задать по каким измерениям сворачивать?

если неправильно сделать структуру регистра - то будет долго производится запись-обновление.

у нас используется это дикое извращение от того, что РН перестал помещаться в файловые базы (итоги), и предыдущий программист сделал РН оборотами. Остатки считались оборотами за весь период. Пришлось эмулировать таблицу текущих итогов на РС, вместо того, чтобы в свое время отключить итоги месячные, и оставить только текущие.

(3)
Это к 1С
Смысл - более оптимальное получение результата
На данный момент рег сведений - это просто таблица с наборами индексов.

http://v8.1c.ru/overview/release_8_3_1/
>>
В регистрах сведений реализовано хранение итогов, за счет чего ускорено получение среза первых и среза последних регистра сведений,
<<

Полюбасу тема уже из за этого смысла не имеет

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

Представь что тебе в принципе не нужны остатки на вчера. Только на "сейчас". А нужен ли тогда регистр накоплений?

(1) У них дела хорошо. Тема к чему создана?

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

(8)
А где ты будешь хранить остатки на сейчас ?
И что будет если вдруг оператор ошибся ?

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

Вообще уже проходили еще в 7.7 - многие умельцы актуальные остатки на справочниках держали. Потом появилось 1С++ и как то это все ушло

(9) мнение интересно тех кто заморачивался.

(11) Как раз все будет хорошо. РС независимы, каждая запись атомарна. А что ты будешь делать с РН?

(12) Я заморачивался. Или ты хотешь до арзитектора решения Акселота достучаться?

(13) не всегда

Кстати, могу подсказать как

(11) РС и есть остатки на сейчас. Миллион записей - да. Но с другой стороны в итоговой таблице РН их было бы столько же.

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

(14) мне достаточно что ты заморачивался :)

(19) Тогда спрашивай. Что помню -- подскажу

(20) производительность при записи сильно падает? Даже субьективно?

(21)+ просто РС он же сначала DELETE делает а потом INSERT.

На РН я так понимаю DELETE только при перепроведении.

(21) Тут не в том дело. Дело в том, что "складская накладная" имеет несколько десятков сотен строк. Когда запись идет в РН, то она идет одной транзакцией. В то время, как запись в РС проводиться по каждой строке: т.е. транзакция идет на каждую строку, все это делается не в проведении, а в записи. Т.е. если мы не смогли провести 1 строку из 3000, мы не откатываем весь документ, мы одной строке ставим неуспешный статус.
Т.е. процесс проведения максимально выведен из-под платформы

Хотя, тут есть вопрос: о какой Логистике идет речь. Я прримерно про 3-ю рассказываю. 2-ая работает на типовом механизме проведения

Тут вопрос в невозможности записать тразакцию из 20 000 записей, если 1 из них не валидна. ПОтому и РС

(24) "мы не откатываем весь документ, мы одной строке ставим неуспешный статус"
Не совсем понимаю как так, ну да ладно. Видимо еще не дозрел.
Но в общем проблематика понятна, спасибо за наводку.

(26) Объясню: если ты ставишь Статус = Отказ при проведении доумента, который делает движения по РН, то у тебя ВСЕ движения откатываются.
Алгоритм расчета размещений долог. Т.е. ты ждал 4 часа, чтобы узнать, что у тебя все зафейлилось. Это неприемлемо.
Сейчас алгоритм проверяет (валидирует) каждую строку документа и записывает в документ (например "Приемка") статус строки "Ок", "Не ОК", "Еще что-то". За счет того, что у нас РС, то строки "Не ОК" не требуют отката строк "ОК". Но при перепароведении документа, ты должен чистить РС по регистратору (а "Регистратор" -- это пользовательское измерение в этом случае, а не системное)

(27) скока-скока у вас проведение документа занимает?

овер100к строк с контролем остатков (кстати, на том самом РС) проводится менее 3 минут

(29)+ в худшем случае

(29) А на РН?

Рн конечно не оптимальны.
На данный момент, то что читал по теории- самое оптимальное - сеть из узлов, где каждый узел сети хранит "свои" остатки и другие данные и отрабатывает запросы независимо от других узлов.
В случае уменьшения количества остатка на узле - данные перераспределяются по соседним узлам, или сливаются в один узел
Запросы "юзерам" по разным узлам запрещены(  точнее данные периодически сливаются в "общую" базу, с которой работают только аналитики)
wiki:BigTable

+31 Тут смысл в том, что "история" начинает тормозить после определенного периода. А она совсе-совсем ненужна. Мы решаем задачу Опертивного Остатка, а не того, как он образовался

Любой пример можно сделать абсурдным

ПыСы, я не сотрудник Акселота, я просто сталкивался с их решением. Моя трактовка этого решения -- это всего лишь моя трактовка.
Но я в нем вижу рациональное зерно. А может, лекторы Акселота донесли

(31) у нас нет >100к строк по РН с итогами. по РС - там не только РС, там еще + обороты по РН при проведении задним числом

(27) во, перепроведение. Это видимо из за привязки всех записей к одному родительскому документу (приемка, размещение). А нужно ли оно? Если брать размещение то да, время на расчет "куда что" наибольшее, но это зависит от сложности алгоритма. Перепроведение на мой взгляд как понятие тут вообще лишнее. Полюбому алгоритм будет работать с квантами данных (отдельными товарами) и если че-то где-то сбойнуло при записи то останется незаписанным то что неразмещено. Доформируют.

Я наверно просто пытаюсь натянуть на 1С логику работы с данными чуждую для 1С. Вот и бродят мысли всякие.

кстати если сталкивались, какой потолок по пользователям в Акселоте по терминалам когда начинают лезть блокировки/тормозить?

> На данный момент рег сведений - это просто таблица с наборами индексов
- чем это отличается от справочника?

(39) В справочнике нельзя указать составной уникальный ключ.

(36) какое "перепроведение" для реальных складских сотатков? Провелось 1 раз (то есть разместилось) - все, капец. Никакое перепровдение не может изменить уже свершившийся и зафиксированный факт. такое мое мнение.

(36) Не, смысл в атомарности транзакции (которую вряд ли можно обеспечить при работе с РН) и истории, которая не нужна в системе оперативного учета (и от которой РН отвязать нельзя)

(41) 9999 строк разместилось, 1 нет.
Как прогорамма должна реагировать?

(38) возможность тормозить только тогда, когда что-то хватается надолго. если в "регистр" писать атомарные операции то они, по идее, будут выполняться практически мгновенно. и возможно даже можно поставить тупо три-пять попыток. если одна "запись" делается в районе 0.001 сек, то можно в случае блокировки и 5 раз попробовать.. и даже 10.. (если это интерактивная работа через терминалы).
.
у меня работает куча терминалов, но под своей простой самопиской 7.7. блокировок - нет. Вернее, они есть - но там, где мне было влом думать ;-) - и они настолько редкие что хз.. когда дни там бывают...

(43) считается ПЛАН размещения?
мое простое мнение - 9999 строк зафикисровать как успешные, 1 строку поставить в очередь на очередное планирование.

(0)>>История по движениям с резервами как правило никому не нужна.

Что за бред?

Проведение задним числом пока никто не отменял.  Так что ты подумай еще раз над тем, что ты сказал.

(42) атомарность - это немного другое

(40)Да запросто. ЗначениеВСтрокуВнутр из скольки хочешь сущностей.

Ключ=ЗначениеВСтрокуВнутр(чтото1)+ЗначениеВСтрокуВнутр(чтото2)+ЗначениеВСтрокуВнутр(чтото3)

(46) все правильно сказал. В ряде случаев ИСТОРИЯ резервов - не волнует. волнует состояние РЕЗЕРВА на сейчас. и правится состояние резерва ВСЕГДА сейчас. Поэтому при проведении задним числом - РЕЗЕРВЫ ОСТАВЛЯЕМ КАК БЫЛО. У меня так и сделано - при проведении задним числом состояние заявок, резервов - не анализируется и не меняется. если в результате проведеняи задним числом ПО ОСТАТКАМ - что -то вылезер "криво" - это сразу же всплывет НА САЙЧАС. СЕЙЧАС и будет правиться.

несколько вопросов напрашиваются:
зачем для wms контроль остатков ?
зачем для wms План размещения ?

(45) В Логистике так и сделано. Но как это с РН сделать? С РС легко и просто и не надо взрывать мозг
(47) А ведь она непосредственно влияет на производительность. Почему это другое. Это просто обратная сторона медали. Хочешь производительности на "больших данных", давай "атомарность данных" реализуй. Или я не прав?

(46) а я тебе ответственно заявляюсь, что бред несешь ты.
Размещение задним числом не нужно!
В минус забрать с ячейки - невозможно!

Реально интересен только текущее количество.
Всякая там аналитика, движения товара и т.д. это не задача WMS.

(50)Да геморно все это:-)

(51) контроль остатков нужен, чтобы не отгрузили того, что нет

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

вообще странная тема...

у меня вопросы

1. ЗАЧЕМ ???
2. Как быть с единообразием и общими нотациями
3. Чего нельзя реализовать на регистре остатков того что есть на РС

(54) Все решаемо. Просто нужно отвязаться от РН. С РС все просто

(53)я конечно понимаю, что идеален вариант желателен:-)_

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

Народ, в все понимают, что KIS и WMS -- это две разные системы со своими задачами?

(55) если покупатель поднес к кассе товар, которого нет в остатках, то он его не получит ?

(51) мое мнение - нужен только контроль остатков НА СЕЙЧАС (ну чтобы тупо не выдать/выпрлнить количества больше чем есть на остатке ;-). все операции на складе проводить только реальным временем.

(62) плюсую. Остальное в этом разрезе управления не интересно

(61) Он его получит.
Но потом борльших киздюлей получит работник на складе.
Это искуственное ограничение. Спайс должен поступать

(63) тоже его плюсую, у меня уже 3 года так работают. Все отлично все довольны.

(62)я всегда убеждаю бухов все править текущим периодом ...Ты сам пробовал их в этом убедить?...Непробиваемо:-)
Хотим задним числом и все.

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

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

(66) ты путаешь бухгалтерский учет и складской учет.

Кстати, есть же документы "Корректировки". Почему их не может быть в актуальном решении. Все зависит от области допустимых значений

(69) Ну логистиков..один хрен они все для меня бухи.

буду я еще их делить на отряды и подвилы:-))

(66) Ты путаешь упр. и бух. учет
Упр. учет нельзя править -- он просто есть. И он такой, как он есть. Это есть сама компания
Бух. учет -- это хоз опреации компании в формальном виде. Конечно, правок быть не должно. Но если они есть, их надо согласовать с глав. бухом. Ему же потом отдуваться

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

(73)еще как можно править. Так как данные в него идут как раз в из бух базы с обменом.Только там внтри интрепретируются и дополняются по упровски

wiki:Атомарность

(67) Нет, в РС "Большие киздюли" будет сделана запись того, что подне  сканнер. Все хорошо

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

(71) я не понимаю тебя.
Причем исправление документа задним числом и остатки в конкретных ячейках?

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

(75) Погоди, т.е. ты скажешь:
"А давайте в этой накладной мы изменим склад поступления, и номенклатура тут дорлжна быть другой: вот вы 100 привезли, а мы приняли 95"?
Так что-ли или что ты имеешь в виду?

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

(78)Как это не меняет остатков?  Если клиент не принял товар, ты хочешь сказать на всю эту хренб они будут делать официальные возвраты??...Окстись. Они просто подправят расходную как будто так было с самого начала. Не с нашими объемами еще и врозвраты городить..и так обмен уже еле дышит

Блин, народ, вы все путаете

(82) еще раз, ты путаешь складской и бухгалтерский учет.
У меня, к примеру, списание товара с ячеек происходит ОБРАБОТКОЙ. отдельной. Которая получает ТЕКУЩИЕ данные по документу и оформляет выдачу (в несколько этапов). Если что-то изменить задним числом, как например в твоем случае, то просто делают размещение товара по ячейкам.
т.е. документ исправили задним числом, а непосредственно товар здесь и сейчас разместили куда-то. Причем не факт что туда где взяли

(83) всегда интересно было - за какое время wms создаст задания на ручную комплектовку заказа из 100 строк ?

Задача WMS -- дать текущий остаток на складе, желательно по ячейкам (а ячейки эти у вас есть физически)?
Задача KIS -- свести показатели всех составляюих систем воедино, сделать приемлемую отчетность

(85) ты про то чтобы подобрать товар из ячеек и выдать на сбор? миллисекунды

(74) не возражаю! все зависит от частностей и возможностей.
разместить одн упаллету - это не ворпрос. разместить 10 паллет так, чтобы размещение 100 следующих палет было оптимальным - уже гораздо интереснее. Но у себя с такой необходимостью - не свтречался.
.
если делать мегапоуму, то должно считаться квазиоптимальное размещениевсех имеющихся на данный момент паллет по критерию минимизации какого-то показателя (например минимизация среднего времени сборки заказов за месяц).
.
но зачастую такая оптимизация ненужна...

(85) намного интереснее задача оптимальной раскладки по ячейкам в соответствии с правилами и фрагментацией

(85) Как обычно, все нюансы не раскрыты:
- в заказ входят разные детали?
- у деталей как там с комплектацией/разупаковкой?
- есть ли требования к самим заказам

Это только с первого взгляда

(82) да не вопрос - подправляйте! только в какой ячейке лежит этот возвращенный товар? вы ведь правите состояние остатков, ане сделанные ране с этим товаром вээмэсные операции.

(87) т.е. от момента поступления заказа из 100 строк через 100 мс готовы задания на сборку 100 товарных позиций ?

(90) в заказе 100 разных товарных позиций, без всяких аналогов и комплектов

(84)Я вот тут как раз про складской.Ну я не в курсе твоей ситему:-)..Взял бы да выложил описание где-нить -  Хоть в книге знаний чтоли, если уж так хороша система...

Только у меня 47 филиалов в урибе на еле дышущей 77(срочно переводимой мной же на 8.2) с около 50 000 документов в день. в таких условия х сложно диктовать свой порядок. Сам ген дир подумал и встал на их сторону

(92) формирование листа сборки - вещь элементарная

(93) Производительность в этом случае ограничена регламентом обмена KIS и WMS

2 цикла, как я вижу

(92) а что, если вместо 100мс, задания на отбор будут спланированы через 500 мс - это сильно подломит физического сборщика комплектовщимка..? ;-)

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

(95) если просто товар отобрать - то совсем просто. если отобрать так, чтобы упаковщик все составные части шкапчика бпосле сборщика быстренько упаковал кучно - немножко сложнее... по всякому бывает..

(98) т.е. у тебя задание на сборку 100 товарных позиций создается за 0.5 сек ?

100 -- это мало. Причем нет всяких комплектов, это будет быстро. Если все, что хотел товарищ, он нам рассказал

(99) засечь за сколько у меня формируется листы отбора на 1000 позиций? - но уменя "тупо" сделано.

(101) сейчас вот специально засеку...

(102) мало это сколько? - 5 лет назад на курсах в УЦ1 100 товарных позиций было 500 сек, сейчас сколько ?

(91)>>только в какой ячейке лежит этот возвращенный товар?

вот уж чего нам еще не хваиало так это адресного размещения товара:))..

У нас товар лежит сам по себе на складе. За МОЛ. А он как то там размещает.

воруют конечно.Но мы боремся:)

(102) я читал про американскую wms манхетен, так для нее суточный предел 40 тыс товарных позиций

(106) отсутствие адресного хранения - зависимость от кладовщика и низкая скорость сборки

(105) на 7.7 самописная WMS как надстройка у ТиС выдавала моментально сборку практически любую. размещение да, могло несколько секунд считаться, но сборка - сразу.

(107) Максиальный предел не скажу -- я не разработчик.
Но 100 обрабатывае тся очень быстро. Быстрее только статус меняется

(108)Наши объемы ни один склад адресно не примет. Приходится валить чтоб хоть влезло.  к тому же организовать людей дистанционно очень трудно.А на месте они все уже спелись:-)

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

533 позиции - 3-4 секунды

(112) у меня заявок активных больших сейчас нет!

(112) ну хз, до полусекунды 1000 наименований...

на складе 50к ячеек, вот сколько обход циклом их занимал, ну + небольшой оверхед - столько формирование сборки и занимало

(116)+ это максимум, если все, что нужно лежит в первых 10к, то дальше, естественно, не шло

...у меня еще паралельно с заданием пеформы формируются

(116) много ячеек!

(113) т.е. 150 строк в сек получается

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

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

особо упоротые пишут резерв в реквизит товара
производительность на высоте

(120) можно сказать и так (параллельно с формированием печформ). при этом я еще считаю сколько коробок-блоков-штук про каждой позиции ббрать, вес и объем...

(123) тоже вариант! ;-)

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

проблемы все равно в другом - в несоблюдении регламентов.

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

(94) да все просто.
ты, видимо, считаешь, что списываться с ячеек должно при проведении документа, а это не так.

У меня (упрощенно, много этапов я убрал) происходит так:
1. Менеджер выписывает накладную
2. Логист видит все выписанные накладные и в зависимости от графика отправляет на сбор определенные документы
3. Операторский отдел с помощью обработки выдает товар на сбор (в этот момент товар с ячеек списывается и помещается в некий кэш).
4. После того как товар собран, делают расходные ордера (в этот момент товар списывается с остатков и обработкой удаляеется из кэша. В этот момент возможен частичный возврат товара обратно в ячейки)

Все товар уехал. Обращаю внимания, никакой прямой связи между документом и списание с ячеек нет! Если документ перепровести (изменив количество, отменив проведение и т.д.), то с ячейками вообще ничего не произойдет.

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

Если накладную исправили и решили таким образом не оформлять возврат товара (просто уменьшив реализацию), то при фактическом получении товара назад - делают операцию "размещения товара в ячейки" и все.

это сильно упрощенно.

(119) много SKU - много и ячеек. в одной ячейке один SKU, один SKU может лежать в нескольких ячейках...

(130) ячейка отбора  - одна?

(129) Как бы, в идеале, это -- две разные системы

(131) а? в сборке один SKU может браться из нескольких ячеек. или что имеется ввиду?

(129) у меня еще проще... за счет этого и плюсы и минусы...

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

(135) есть отчет, называется сравнение остатков.
Он складывает товар в ячейках и кэше и вычитает числящиеся остатки.

(133) "ячейка отбора" - доступная для сборщиков. из нее подбирается товар при сборке. "ячейки хранения" - складской запас 9оттуда тоже берется если коробочная сборка крупная).

(135) это очень просто.
Если товар в кэше, то значит что он СОБИРАЕТСЯ.
А раз он собирается, то проводить по нему инвентаризацию не совсем корректно, но можно.

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

(137) а... не, "складской запас" отдельно, ячеек отбора много

(132) в нашем случае это было бы не идеальным вариантом, а большим гемором. Я внимательно изучал этот вопрос.

(138) "СОБИРАТЬСЯ" заявка может достаточно долго... а считать надо сейчас..

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

(140) то есть ячеек отборана один товар - много?

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

(143) плоха система (с точки зрения быстродействия) значит.

(141) Это уже не проблема какой-то конкретной типовой, а необходимость создания собественно WMS. Всех карт у меня нет

Будь мужиком, блеать!

эх.. посмотрел статистику за дубабрь - 479 строк не хватило до 50'000 строк сборки. 92 строки/мин средняя скорость сборки.

(147) сферический конь в вакууме он идеален, но никому не нужен )

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

Т.е. из неполной информации невозможно собрать полный ответ.

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

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

(152) это ты про что?

(155) +1 я тоже не понял.

(155) я про (141)
Там явно не хватает инфы

(154) ты про адресное хранение?
если да, то я с тобой не согласен )

.. как только у персонала не заблокирована возможность сделать "не так" - все, капец... сделают "не так"...

(158) не только про адресное хранение.

(157) э... какой инфы?
почему в моем случае 2 разные системы было бы большим геморром?

(157) я НА ДАННЫЙ МОМЕНТ стою категорически против НЕСКОЛЬКИХ систем. если два участка могут работать в рамках одно йбазы - хочу чтобы сейчас это было именно так. Умрут у меня на обменах. и прочих косяках попутных.

(159) это следствие не правильных подходов.
Копьютер - это сложное устройство и использовать его должен квалифицированный персонал.

Движение по пути ограничений - это путь в никуда.
Необходимо двигаться по пути повышения квалификации персонала.
Сделал не так? будь добр - ответь. Ответственно очень мотивирует. А если можно свалить на программу, то тут тупик.

вот есть у меня в системе слабина - кол.учет по ячейкам не ведется. Все, капец. Изредка, но регулярно товар девается неизвестно куда. Как запилить без внедрения количественного учета по ячейкам - пока что представляю слабо.

А давайте прекратим спор, а то он напоминает детский:
"-Кто сильнее, Рембо или Шварцнеггер!
- Конечно Шварцнеггер!
- А если Рембо поможет Джет Ли!"

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

А вообще, я про то, что "Серебрянной пули" нет. И быть не может в этом вопросе. Каждое решение имеет сильные и слабые стороны. Наша задача в том, чтобы усилить сильные моменты и нивелировать слабые. Ведь так?

> Сделал не так? будь добр - ответь
- чтобы понять, кто должен ОТВЕТИТЬ - требуются эти самые ограничения.

(149) я тоже за декабрь посмотрел - непосредственно комплектация 447 772 строки, перебежки со скоростю 2.5 строки в минуту

(164) а в чем проблема?
Есть такое понятие, как материальная ответственность. Поверь, количественный учет по ячейкам (если ты про историю движения) ни разу тебя не спасет т.к. реально никакой дополнительной информации тебе не даст.
Ну вот был приход, вася туда положил 4 единицы, а теперь там 3. И что? Вася виноват? Или петя, который стырил?

(162) Складу складово, бухам бухово. В чем косность такого решения?
Задачи WMS и бухгалтерии не пересекаются. В чем-то даже противоречивы. Надо их разводить

(162) скажем так, твое утверждение истинно, но в ограниченном количестве случаев.

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

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

(169) эээ! не путайте бухов и отдел продаж. Бухию - стопудово с вээмэс мешатьне стоит. а вот продажников - очень даже возможно.

(171) еще раз, какую задачу ты хочешь решить с помощью количественного учета?

(170) > Если между подразделениям слабая связь,
- угу!!! именно как-то так...

(173) может голосом на скайп?

(173) может пнешь меня в нужном направлении...

(175) ministr30 сейчас зайду

на досуге ломаю башку - не получается без кол.учета. а делать его ну не прет меня реально.

ок. сейчас

такс... попробую запилить/ужесточить немного без количественного учета.. есть шанс...

всем спасибо за беседу

(181) и тебе спасибо.
Если честно, я про способ ведения ячеистого склада без количественного учета вообще не думал :)
По своему интересная идея и имеет свои плюсы.

(108) отсутствие адресного хранения в приципе возможно когда товар крупный, ассортимент мал и жестко закреплен за зонами, но на складах где около 1000 SKU и площадь более 5000 квадратов это равносильно остановке склада. Смешно и грустно было смотреть на поисковые бригады комплектовщиков которые за 4 часа не могли найти товар.

(123) резерв же по конкретной ячейке делается. В реквизит можно когда адресного хранения нет, но тогда и WMS не нужен.

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

(163) ну если все работает слаженно только за счет высокой квалификации персонала то это плохо. Сложнее/дольше натаскать замену, сложнее запускать новые объекты. Люди не дураки и понимают что если их сложно заменить то можно и повыпендриваться.

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

(171) единственный наверно более менее решающий эти проблемы вариант это на сколько я понимаю rfid метки. Датчики на все выходы и в проходах с камерами. Но говорят сложно и дорого. Зато все видно :)