Доброго всем времени суток.
На работе продвижение... Купили большое здание, оборудуют его под большой склад. Нужно выбрать программное решение для обслуживания склада. Пока склоняюсь к УТ и мне бы было приятно его использовать, но наше руководство дотошное и хочет иметь выбор. Отсюда и просьба к форуму подсказать какие-то грамотные решения складских вопросов. По хорошему многий функционал УТ в данном случае лишний (за это руководство и зацепилось). Нужна конфигурация максимально направленная именно на складские задачи с выгрузкой в УТ (желательно штатной) и возможностью взаимодействия с сайтом.
   Подскажите, то чем пользовались и это есть хорошо. Ну и большая просьба описать плюсы минусы (+/-) и дать ссылки где можно купить данную конфигурацию.
   Всем заранее спасибо

Нужен Злопчинский

(1) Брось... Серега клюшник. Мне снеговик нужен

На таких условиях - только самописка.

(2) зато он знает всё про склады

(1) Кстати, Станислав, пока ты здесь вопрос по сайту.... Есть ли на сайте общедоступный список пользователей? Могу ли я при необходимости с любой момент найти адрес почты того же Злопченского или Ёпрст?

(4) Это понятно, что не типовая. Есть какое-то решение от 1БИТ, "1С: Склад", но как глянул, так и ахнул... что-то вообще не в тему.

(0) Если функционал УТ лишний, то не очень понятно, что вам нужно, так как для нормальной работы большого склада функционала УТ недостаточно...

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

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

(5) глаерея

Сам ставил адресный склад как франч на УТ11, все конечно заработало, но сам бы работать с таким не хотел от слова СОВСЕМ... Для себя бы поискал, что-то вне 1С-ного поля...

(0) Дешево - это типовые от 1С + напильник. Дорого - брать отдельную WMS. Иногда стоит и склад проектировать под будущую WMS.

(5) нет так как наличие почты, это право пользователя, а не обязанность

(0)у Акселота издревле было решение для склад, посмотри
емнип что-то такое Рарус пилил (но могу ошибаться)

(13) терзаясь смутными сомнениями я кажется не знаю, что есть Акселот... это не дочка Раруса?

(0) ...кто чем пользовались... - думаю вопрос неправильный, правильно, кто что сам ставил и это заработало.

(14) Не потянете вы Акселот... Он на порядок сложнее УТ11 в части складского учета.

(7) УТ мы и так используем. Хочется облегченное решение по складу. То есть не надо никакой торговли, больше склада и с простеньким интерфейсом для не очень умных юзверей

(16) Зачем так? Или я не программист с 15 летним стажем или тот Акселот сборище криворуких )))

Вот одна из лучших WMS на 1С http://www.arena-wms.ru

"Готовое решение" для склада обычно не прокатывает, потому что требует менять все складские процессы под ПО а не наоборот.

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

(18) :)) Вы не представляете, о чем говорите :))

(17) так бы сразу и сказал, держи
http://old.mista.ru/tutor_1c/example_sklad.htm

(18) возможно ты и программист с 15 летним стажем, но о складе ничего не знаешь, совсем ничего :)

(17) возможно кортес вам подойдет, но это не точно

(18) Да, кстати, бюджет какой? А то насоветуем сейчас, а у вас тыщ 500 бюджету всего...

(18) Axelot кстати иногда даже работать можно заставить. Но на это надо иметь желание за них баги вычищать.

А так он много шустрее УТ11.

(23) флуд... что мы можем знать о собственных возможностях, а тем более о чужих. ©

(25) А ты думаешь зачем ветка? Бюджета хватает на полноценную УТ, но его хотят урезать.

(27) это не флуд
...кто чем пользовались... - думаю вопрос неправильный, правильно, кто что сам ставил и это заработало

будет очень интересно услышать того, кто Смог

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

(28) Так УТ самый дешевый вариант, дешевле ничего не найдете из приличного...

(30) Тебя ещё мама кормит? Малыш, я не Карлсон. Я задаю серьёзный вопрос, серьёзным умным людям, а ты мне (22) кидаешь.

(28) Тогда вот вам для начала: http://catalog.mista.ru/public/387546/ http://catalog.mista.ru/public/432418/

(31) УТ не приличный вариант, там от WMS почти что только слово

(34) Им не надо полноценную WMS с таким подходом...

Серьёзные люди тебе СРАЗУ сказали, кто может вам объяснить, что вам нужно.

(34) полноценная WMS для Омска начинается от 50k$
иначе оптимальный выбор это УТ

(37) иди уже теплого молочка попей, не флуди

WMS на 1С? Это новый анекдот такой?

Большой склад это как? Большая площадь? Большая номенклатура?

(38) ты какой-то странный Билли

вопрос был "Решение для большого склада на 1С"
тебе ответил:
- внедрение WMS будет от 50k$
- купить и самостоятельно внедрить WMS практически никому еще не удалось
- в условиях сжатого бюджета оптимально использование УТ
- если УТ избыточно, то можно использовать складскую программу Митичкина Станислава

только голая правда, и где osa1C узрел флуд ?

(18) Ты точно не программист. Акселот единственное вменяемое решение типа WMS на 1С однако. Но вам однако его явно не осилить. Бо что такое склад нихрена не знаете.

(39) Это Склады СосаСолы на 1С ;-)

На 20к квадратов

и эти данные на 2012 год

(0) Большой склад это что 100-200 или 15к квадратов?

(42) Прикалываешься?

(46) Я же работал в Акселоте, правда не долго

Хвастались

Тока не помню кто, главное это 20к квадратов

(0)ут 11 разве не поддерживает ордерный склад?

Это были большие склады

(42) Склады СосаСолы на 1С - это т.н. СУТЗ от Васи-Логиста ? :)

150 ТСД в режиме онлайна

(52) Я и спросил про большой склад?

(52)эээ, там развитой список номенклатуры?

(53) вопрос быстрой работы - это вопрос к оптимизации кода а не к организации работы/методологии

(47) А я три компании на нем поднял, две при фране, одну сам. На ворованном. Так та еще хрень. Но рабочая однако.

(53) Да ты монстр однако. Мой предел 80 был.

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

(39) Ну это метров 150. Которые после переезда с 25.

площадь склада и кол-во терминалов недостаточно для оценки WMS. любой фармсклад на 300 кв.м по уделает обычный склад на 20 тыс кв.м по функциональности и нагруженности

(61) Дык я о номенклатуре и спрашивал. Я как-то склад автозапчасти автоматизировал, вот то была жесть. 1С 7,7 умерла еще на загрузке справочника номенклатуры, тупо не влез однако. Брали тогда они что-то отраслевое не на 1С.

(39) Ты отстал от жизни... WMS на 1С реальность, причем достойных решений не одно и не два...

(62) 8-ка легко работает с автозапчастями

(64) Да, лично знаю компанию, в которой 19 складов автозапчастей в одной базе WMS  на 1С живут...

(63) Например? Я догоню.

(64) 8,3 в клиент-серверном режиме? Потянет. Согласен.

(67) был положительный опыт полноценных 20 тыс автозапчастей еще на 8.0
Естественно с переходом на 8.1 -8.2 стало ощутимо веселей

20 тыс, это мелкий магазин однако.

(2) Причем здесь то что клюшечник? Вы что собрались себе систему складскую писать? - смысла в этом нет. Есть вопросы - стучись в личку. Я работаю на внедрениях по складам на промышленной WMS на 1С на 8-ке (не как программер - там сидит своя отдельная команда разработки) - то что вам надо.

(69) 20 тыс кв м
Номенклатуры под 300 тыс
Мезонин на 1200 кв м

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

(39) большой склад - это большой склад.
это когда за сутки работы в системе регистрируется около милоиона складских операций, это когда более 100 человек бегают с ТСД. Это когда например не просто склад, а полный фуллфилмент.

ввиду того что упоминалась арена и акселот добавлю и Toplog
например http://www.toplogwms.ru/clients/project_45/

(41) несколько скоропалительное заявление ;-)

(66) Акселот, Арена, Пента, Топлог. Мало?

(70) Впишутся в бюджет на "полноценную УТ"?

(77) Смотря что им надо. Если даром, то есть безвозмездно, и все сразу - то флаг в руки и барабан на шею. УТ11 и собственного фикси - тогда что-то получится ДЛЯ НАЧАЛА

(78) Так им надо решение дешевле и проще УТ, судя по сообщениям ТС :))

(79) Блокнот вполне подходит

(79) Каждый клиент уверен что его процессы "проще не бывает".

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

(81) Вот тут не уверен - чем крупнее клиент, тем более он уверен, что его процессы уникальны :))

(83) Есть конечно заморочки, но потом оказывается что эти заморочки по большей части наследие тяжелого царского прошлого ;-)

(83) Угу, а когда делаешь при нём стандартный отчёт и тыкаешь по расшифровке строки, то он сидит с оловянными глазами и просит записать последовательность "тыков".
И конечно же у склада коки миллионны документов товародвижения в день, одну бутылку выпил грузчик, а другую погрузчик поранил вдребезг, верю.

а акселотовскую вмс 1С разве не выкупило?

(86) хз, не углублялся. достаточно знать что «1С:Предприятие 8. WMS Логистика. Управление складом» - это Акселот

(72) А что на складах такого супер-нового за последние 20 лет придумали?

(86) Разорились наконец :-)

(88) Ну придумали "перетяни канатик", типа "мы вам отправляли" - "мы не дополучили".

Внедрил акселот в одну каску на развивающемся предприятии. Сейчас уже пару сотен тыщ ячеек и несколько десятков тыс номенклатуры. Напильник нужен конечно, но костяк с проектирование норм.

(89) Это уже административка.  Я когда в свое время внедрял - так были приколы с обдолбанными гастробайтерами, которые в ячейках спали тупо.

Хм, (90) постов, а по делу традиционно немного
(0) А что сложного в УТ 11 для кладовщика?
3 АРМа же всего практически, на приход, на расход и на внутренние документы
Мы обычно клиентам затачиваем эти АРМы под специфику, расписываем процесс, проводим демо прототипа, дорабатываем функционал (чаще всего минимально), обучаем кладовщиков, запускаем эксплуатацию

Что за ТМЦ, сколько типов?
Сколько SKU?
Дубли SKU есть?
Сколько складов?
Характеристики есть?
Серии есть?
Штрихкодирование есть?
Адресный склад есть?
Отгрузочные документы печатаются на складе?
Резервирование есть?

К этому перечню можно ещё десятка полтора вопросов добавить...
Сроки годности?
Требования клиентов к срокам годности есть?
Коробочное и шиучное хранение совместное или раздельное?
Партионка есть? Уровень партионки?
В базе-поставщике данных порядок или как обычно бардак?
Кросс&докинг есть?
Упаковка, маркировка?
Предпродажная подготовка?
Пост-приемочное обслуживание?
И ещё куча всего...

а если найду?

Для начала надо задать вопрос, планируется ли работа с ТСД, и если да, то онлайн или оффлайн.

(0) Внедряли Axelot'овскую WMS 3-ку. Если говорить о 3-ке, там довольно интересная архитектура, но весьма проблемная, если захочется немного выйти за ее рамки (к примеру, вести остатки одновременно в шт и индивидуальном весе). Придется прикручивать велосипед "снаружи". Ну и плюс, готовьтесь увлекательно переписывать стандартные алгоритмы отбора, размещения и подпитки, т.к., при всем множестве настроек, они корректно не всегда работают (какие-то опции беспроблемные, какие-то нет). Обменов нормальных нет.
Потестили Axelot'овскую же 4-ку, там более современная архитектура и много дополнительных плюсов. Минусы сходу не обнаружились, не стали тратить время на моделирование процессов, но скорее всего так же алгоритмы могут "чудить".
С учетом, что вы пишите "возможностью взаимодействия с сайтом", то я бы смотрел в сторону УТ11.

Сначала надо определиться с основными параметрами WMS
1. Количеством номенклатурных позиций.
Мало - в районе 1 тыс
Много - несколько десятков тыс.
  Если ведется учет по сериям, срокам годности, тогда умножайте на соответствующий коэффициент
2. Нагруженность склада
  Мало - 0.1 операция в секунду  (до 10 тыс в день)
  Средне - 1 операция в секунду  ( 100 тыс в день)
  Много -  10 операций в секунду ( млн. в день)
3. Количество ячеек
  Мало - до 1000
  Среднейй - 10 тысяч
  Много - 100 тыс

  После этого можно определяться с продуктом 1С

(7) +100500.
Вообще УТ как бы модульная. Ненужный функционал можно просто отключить.
И да, для полноценного склада, с признаками WMS, функционала УТ зачастую не хватает, хотя там много чего есть.
Самому писать думаю смысла абсолютно нет. Либо УТ11, либо Акселот 3/4.

https://solutions.1c.ru/wms

Я за последние 5 лет испробовал/внедрил  несколько WMS. 1с77, Axelot, УНФ (переработанная), УТ11 (переработанная), Рарус Автозапчасти (УТ10) переработанная. И пришел к след. выводам:
А. Большое количество номенклатуры, большое движение, большое количество движений.  1С не подходит
B. Большое количество номенклатуры, малое количество движений.   РарусАвтозапчасти (УТ10) переработанная
C. Малое количество номенклатуры, среднее количество движений. 1с77, УНФ (переработанная). Axelot.
D. Малое количество номенклатуры, малое движение - УТ11 переработанная

(100) расскажите плиз про основные "боли" с которыми столкнулись

1. Если вы используете управляемые формы, тогда большое количество номенклатуры или большие движения вам не грозят
2. Если вы используете типовые конфигурации. То будьте готовы к тому, что 90% заявленного функционала по части WMS работает иногда не совсем корректно см (96). Доработка затруднена из за запутанности алгоритмов. Удобство работы в типовых конфигурациях стоит на последнем месте.  
Ну и стандартные проблемы Топология склада, Размещение, Отбор, Инвентаризации, ТСД. До этих "мелочей" у разработчиков руки обычно не доходят.
   И отдельная песня это УТ11. Мало того, что в отдельных алгоритмах было по несколько ошибок, который при определенном расположении звезд не появлялись, так там еще были большие проблемы с быстродействием, работой со  штрих кодами. Топология склада, Ввод начальных остатков, Инвентаризации, Отборы - для УТ11 это не нужные операции. По крайней мере так это было 3 года назад

Для типовых конфигураций проблема - функциональные опции.
Стандартные алгоритмы отбора, размещения и подпитки, при всем множестве настроек, они корректно не всегда работают (какие-то опции иногда беспроблемные, какие-то нет)  (96)

(100) Вам не повезло встретить нормальную WMS на 1С. Известная мне максимальная производительность - примерно 15 тыс. реализаций, в которых более 180 тыс. строк за сутки. Но не управляемые формы, да.

(102)
"Если вы используете управляемые формы, тогда большое количество номенклатуры или большие движения вам не грозят"
Почему? Что значит "не грозят"?

(0) Вот ссылка на правильное внедрение на УТ 11 http://catalog.mista.ru/public/702775/

(101) основные боли при внедрении WMS (если смотреть со стороны исполнителя проекта) - какое-то мутное отношение заказчика к построению нормальной ИТ-инфраструктуры для нормальной работы ВМС. Принтера этикеток не нестроены, терминальные сеансы не настроены, все валяй-шалтай-болтай. Отношение типа "ну оно как-то само образуется"... хрен там.

(104)  " 15 тыс. реализаций, в которых более 180 тыс. строк за сутки" - это в моей классификации средняя загрузка.
  У меня на УНФ примерно такая же загрузка в районе 100 - 200 тыс операций в сутки. Здесь нет ничего такого.
   А вот 1 млн операций в сутки. Это уже сила

(108) можно примеры потребности в 1 млн операций в сутки

(108) думаю даже Протек в свои жирные годы не имел 1 млн строк заказа в сутки

(108) 180 тыс это только строк реализаций, операций наверное тыщ 400 всего... мелочь, да...

одна строка заказа - порождает много складских операций.
вот, надысь, запустил склад небольшой.
1 строка заказа на отгрузку, порождаемые операции (регистрируемые по ТСД)
- отбор
- упаковка
- перемещение на контроль;
- контроль;
- перемещение в зону отгрузки;
- отгрузка.

и еще учесть что заказано м.б. 100 штук всего - а вышерперечисленные операции могуть "умножаться", так как 100 штук отбирается и обслуживается не единым пулом, а частями...
...и это еще нет операций подпитки, инвентаризации и пр.
..вдобавок операции просмотра остатков с ТСД (чисто сервисная функция) - операции не создает, но данные с базы дергаются на просмотр остатков.
..
вот и считай - 1 млн операций - это запросто.. а так строк заказов порядка 230 тысяч, например http://www.toplogwms.ru/clients/project_20/

Сам склоняюсь к УТ10.3 + напильник, а если брать готовую копро-поделку, то КОРТЕС

УТ10.3 (перепиленная под WMS) на платформе 8.3 + обмен с сайтом через REST-интерфейс, видел у пару клиентов, все работает, все довольны.

А так из готовых КОРТЕС имхо.

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

В свое время в организацию, где я работал нужна была WMS и именно на 1С. Я предварительно рассмотрел порядка полутора десятка написанных на 1С складских система, в том числе и перечисленные в (76), Акселот, Арена, Пента, Топлог. Первые 3 из перечисленных выбрал и приезжал в командировку в Москву, чтобы ознакомиться с системами на складах. После непосредственного ознакомления с этими системами на складах в работе была выбрана Арена, по причине редкого на тот момент (надеюсь цена остается также привлекательной) сочетания цена/качество. Под качеством я подразумеваю высокую производительность, низкую потребность к ресурсам и степень настраиваимости системы. Но сам разработчик Арены иногда ко мне обращался, чтобы я ему обозначал проблему и он лучше в системе будет добавлять специализированные доработки, чтобы ими пользовались все. А так получалось, что я Арену использовал как конструктор сам, т.е. не требовалось обращаться к разработчику и при этом не вносил коррективы в конфигурацию. Дело в том, что склад был с алкогольной продукцией и на тот момент это был первый такой склад для которого была выбрана Арена. Т.е. все что потребовалось, например, для точного партионного учета для работы с ЕГАИС с начала 2016 (спустя полгода после внедрения) мне удалось настроить без обращения к разработчику и без внесения дополнений в конфигурацию. Не скажу, что это было тривиально, но все же проще, чем если бы я полез разбираться в код системы что-то изменить/добавить.
В общем, по своему опыту, Арена - это система, которую не то что не стыдно порекомендовать, а почетно ИМХО.
PS: тем не менее после того, как я достаточно разобрался с кодом Арены стало понятно, почему разработчику удалось "выжать" из 1С требуемую производительность, причем с запасом. Дело не только в том, что в конфигурации не использовано ни одного регистра остатков и ни одного документа, а вместо регистров остатков использованы регистры сведений и вместо документов использованы справочники. Разработчик явно отлично владеет таким вопросом, как потом запросы и операции выполняются в самой БД на MS-SQL, в частности. Т.е. я бы не удивился, если бы Гилев оценил его подходы в решениях на 1С с оглядкой на обработку данных на уровне СУБД.
Но, пожалуй, остановлюсь. Это все ИМХО. Прошу, без холивара "Какая система лучше?!" :-).

(116) Это. Просто. Ахеренна, братан! Ахеренна!

(116) Вот отзывы других программистов, которые увидели учет на РС и справочниках:
https://youtu.be/6wRqRjVRx3U

(116) LOL
(117) В точку :)))

ТС что-то вообще пропал с поля зрения

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

Дело не в РС и справочниках, а в построении грамотной архитектуры хранения данных и запросов к ним.

Но это всё лирика, надо понять что же нужно автору ;)

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

Но то - такое...

(122) Так я это и отметил, что разработчик грамотно поработал над тем, как потом сама 1С будет работать с СУБД.
(123) Вы работали с Ареной? Можете позволить себе такие суждения?

(125) Я работал с системами, в которых было сделано вот такое вот извращение. Спасибо, не надо так.

(125) "что разработчик грамотно поработал над тем, как потом сама 1С будет работать с СУБД.

Лучше бы разработчик пилил бы что-нибудь на C#, ну или разобрался бы с внутренностями 1С.

(127) Ну, ясно, значит с Ареной не работали.
Вы мне этим напоминаете анекдотического персонажа, который изрек типа "Да, Сарочка, этот стриптиз - такая гадость", после того, как стриптиз ему показала его постаревшая, обрюзшая и нерасторопная в танцах супруга.
Вот поэтому лучше вы и пишите на C#, что-нибудь, раз не можете разобраться во внутренностях 1С.

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

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

(116) Акселот также устроен.
Вообще для WMS учет на РС это нормальная (и похоже единствено правильная тема).

(127) а сколько там в "правильной" архитектуре на регистрах накопления будет записей в виртуальной таблице остатков, где:

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

Сколько триллион? триллиард? доххх...ард?

(123) абсолютно поддержу - традиционному 1С-ку очень трудно перестроиться для работы с WMS
но сам подход с использованием РС вполне оправдан

(131) Да, и на РН можно сделать высокое быстродействие. Тут дело даже не в используемых объектах, а в проектировании архитектуры. И зачастую её так неумело делают, что уже не важно на чём именно.

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

(135) быстродействие на РН и РС вполне сравнимо, но есть существенная разница в возможности архивирования и срезки движений

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

(137)
Согласен. В той же 4-й WMS Акселот от своей архитектуры на РС отказались.

(138) у Акселота 1-я и 2-я версия на табличных частях и РН, 3-я версия на РС, 4-я версия на РН, думаю в 5-й версии придут к чему-нить окончательному :)

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

(140) имело место копирование архитектуры неотечественных WMS
а с производительностью РС как раз пришлось сильно бороться

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

(142) Нет, почему, расскажи - люди не в курсе, используют такое решение, и не знают, что оно скудоумное...

(142) Разрешаю! ;-)

(143) Я как-то видел, люди в бухгалтерии на 60 и 62 счетах под каждого нового контрагента в конфигурации новый субсчет заходили, до пары тысяч дошло
И тоже работало

(145) Тоесть ты опять сливаешься?

(143) С тобой мы уже помнится пообщались, я так и не понял, к чему пришли
Ордерной схемы нет?
Есть только в 1С?
Есть только в 1С, но как небольшая пришлепка к БУ?

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

(146) Нет, просто не вижу смысла с тобой о чем-то спорить

(148) Ну тоесть пукнуть в лужу, что решение WMS на 1С на РС скудоумие можешь, а обосновать нет?

(149) А я смотрю, логика не твое :))

(147) 1. Термин "ордерная схема" встречается только в решениях 1С.
2.То, что ты называешь "Ордерная схема" - это не параллельный складской и бухучет, а учет, состоящий из нескольких взаимодополняющих видов учета.

(150) (142) - это ничем не обоснованный пук в лужу.

(140) ответь  на (133)

(137) "WMS на РС - это не правильно" - скажи это каким нибудь Manhattan Assotciates или другим западным системам, где остатки тупо в плоской таблице лежат...
"по крайней мере для 1С." - оооо....  а у 1С должен быть какой то особенный WMS?

Не вижу противоречий между (116) и (123): если в системе сделано все ради того, чтоб ещё хоть немножко повысить производительность, то естественно про удобство программиста заботятся во вторую очередь. Тут - или код, который поймет даже не слишком умный человек, или нестандартные методы работы с объектами, которые дают экономию ресурсов и времени, но совершенно головоломные для разбора.

(151) >>1. Термин "ордерная схема" встречается только в решениях 1С.
И че? А в жизни этого нет что ли?

>>2.То, что ты называешь "Ордерная схема" - это не параллельный складской и бухучет, а учет, состоящий из нескольких взаимодополняющих видов учета.
Софистика и масло масляное

(152) Что обосновывать-то
Даже ОСВ по складу становится каким-то невероятным извращением, если все реализовано на РС

(154) Начинается старая песня о сто раз обсосанном

Пытаться радикально на порядок или два ускорить производительность 1С возможно только работая с SQL прямыми запросами
А повысить производительность на 20% или на 30%, при этом сделать все так, что без поллитра не разберешься, ну ХЗ, я бы такой системой пользоваться не стал точно

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

(157) ОСВ? А ты вообще понимаешь, что такое WMS?

(157) WMS - это не просто складской учет пришло/ушло/остаток

(160) (161) (162) Я вот ни секунды не сомневался, что молниеносно набегут доброхоты, объясняющие, что такое WMS
Жалко, никто еще не написал с умным видом, что номенклатуру и склады глупо хранить в РН
Правда я-то вообще конкретно про ОСВ по складу сказал, для примера, так сказать, но зачем говорить про нее, если можно прикинуть валенком и перевести разговор на то, что WMS - это не только ОСВ по складу, ага :))

РС используют из-за того что там есть составной индекс. Больше его нигде нет

(164) Не силен в индексах
Что за составной индекс, который есть только в РС?

PS: даже если это тако, это не отменяет всего вышесказанного

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

(166) Рукалицо

Прочитай (116), особенно внимательно прочитай "Дело не только в том, что в конфигурации не использовано ни одного регистра остатков и ни одного документа", возможно после этого ты перестанешь мне с умным видом писать то, про что я написал в (163)
Ясен пень, что скудоумие начинается не тогда, когда в складской конфигурации появляется РС, а когда в ней движения по складу хранятся все в тех же РС

(165) Эхх и это человек считает себя гуру 1С

+(167) Или если я тебя не понял и ты настаиваешь на том, что РС в качестве замены РН — это нормально, что бы и нет, то тогда собственно я уже все сказал выше по этому поводу

(167) если не нужны движения задним числом (только актуальные) то вплоне вариант (с WMS не знаком)

(168) PR это гуру 1С?

(167) Нет, это клиника. Ты некомпетентен в возможностях использования РС в WMS, но при этом считаешь, что можешь выносить свои суждения о продуктах, которые эти возможности используют.

(168) Я не люблю рвать рубашку на груди, когда не в теме
А ты раз уж сказал А, говори Б
А то я что-то пока в силу своих скудных знаний про индексы в 1С сомневаюсь в сказанном тобой
В любом случае уж точно как минимум хочу разобраться в вопросе

(171) Не, он гуру "ордерной схемы".

(173) Сначала разберись в вопросе, а потом рассказывай про скудоумие. Так все умные люди делают.

(161) Не ведитесь на троллинг PR.
Он не может понять главного, что заказчику "насрать" на чем сделана система WMS, хоть на справочниках, главное чтобы система приемлемо работала для бизнеса и выдерживала пиковые нагрузки. А уж мнение программистов 1С о системе ему фиолетово, мягко говоря. Тут же (0) интересуется WMS с точки зрения бизнеса, а не сточки зрения PR.
Я еще понимаю, если бы Злопчинский высказал свое мнение, там да, за плечами опыт, а тут просто .... без слов.

(171) Не сможешь работать в первобите, если считаешь иначе :)

(170) Не, ну это-то конечно да
Если мешает, а так норм, да
С помощью если можно до абсолютного идиотизма договориться

(172) А по делу что-то скажешь?

(178) когда у тебя 1млн строк в день, то все что угодно может мешать

(175) Я вроде не тебе же написал, к чему ты за Вафеля отвечаешь?

(176) Ага, ТС в (0) так и написал, видно же:
— Движений задним числом у нас нет и не будет
— Читабельность, интуитивная понятность и простота реализации метаданных решения не важна, лезть внутрь я не собираюсь

(180) Так ты на (165)-то ответишь?

(183) Я за тебя гуглить не буду )))

(184) Тю, понятно, брякнул знакомое слово

(182) разве можно что-то в WMSe сделать задним число. Хоть в одном?

(182) Это в цитатник мисты!!!

"Движений задним числом в WMS" (PR).

(186) А чо нет то?

(186) Не в курсе
Но я не понимаю, как можно обойтись без ОСВ по складу

(188) те чувак пошел собирать заказ. А потом кто-то исправляет его документ?

(189) складской учет - это немного другая тема. WMS - это сборка заказов

(190) Зачем исправлять?

(190) Ну да... А в чем техническая проблема сделать это? Другой вопрос, насколько целесообразна такая схема работы.

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

(187) Гражданин, у клиента будете с горящими глазами слюной брызгать, пока он будет 03 набирать :))
Я уже миллион таких героев повидал, которые сначала бьют себя пяткой в грудь типа да какие нахрен движения задним числом, ничего не понимающий в ситуации воодушевленный директор заодно стучит себя пяткой в грудь и роет копытом землю, победоносно смотря на своих тупорылых сотрудников, а потом через полгода фирма как-то вдруг совершенно неожиданно имеет совершенно непонятные проблемы, вроде мелочь, но аж процесс встал колом и все из-за того, что, смешно сказать, нужно задним числом что-то где-то переправить, ну это же типа несложно, да, а это, упс, не так уж и не сложно

(191) А, вон оно че, а я-то по простоне душевной думал, что https://ru.wikipedia.org/wiki/Система_управления_складом#Решаемые_задачи

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

(167) ...в складской конфигурации появляется РС, а когда в ней движения по складу хранятся все в тех же РС...

таким образом сделано у Акселота в 3-версии. необходимость такого решения действительно сомнительная.

но оптимальность использования РС для WMS это не отменяет :)

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

(195) Ого, как заносит на поворотах. В WMS понятие "поправить задним числом" не применимо. Если где-то чего-то не хватает или нужно переправить, есть на это регламент и точка. Надо разобраться почему и  что привело к тому что не хватает, а потом исправлять регламентными документами в онлайн. Если этого не делать, то PR будет приходить каждые полгода к клиенту, снимать с него приличную сумму за исправления задним числом, и потом опять ждать полгода.

Касательно индексов. Видимо, имеется ввиду, что у основной таблицы регистра накопления нет индексов вида [Измерение1+...+ИзмерениеN]. У основной таблицы регистра сведений такой индекс есть.

(198) ...какова будет производительность получения остатков по состоянию на неделю назад...

в WMS РС остатки на неделю назад получаются также как и на РН, только в обратном порядке :)

(199) Да, правильно работать правильно, а неправильно работать неправильно. Но при этом надо сравнить издержки на правильную работу с профитом от правильной работы и потерями от неправильной, если они есть. Догматизм без реальных обоснований вреден в любой области.

(176) ну я как бы высказывал и высказываю свой опыт. причем с точки зрения использования 8-ки - не как программист, а как внедренец (в разных ролях) WMS на 1С.

(186) как только в ВМС вешают учет какого-то "воздуха" (типа сумм) - сразу появляется необходимость или заднего числа для этих сумм или паралельного блока УЧЕТА (а не регистрации!!!) или других извращений.

(189) для ВМС - ОСВ по складу - вещь второстепенная, для расследования "траблов" всякого рода, но она - несомненно нужна. Причем ОСВ, в зависимости от детализации этйо самой ОСВ - может быть очень непривычной для "типовых" пользователей таких ОСВ, которые ожидают несложную ОСВ.

(177) Разве PR первобитный?

(206) Первобитно-Савеловский :))

(191) Чесно говоря, система сборки заказов это не WMS, а фуллфилмент
https://ru.wikipedia.org/wiki/Фулфилмент

Быструю WMS можно написать и на РС и на РН, сейчас в этом особых проблем нет.

Другое дело, что работа с РС намного интересней чем с закрытым объектом типа РН. У РС столько много плюшек, что я не готов от них отказаться :)

Если надо, то можно и на РН написать. И будет быстро. И можно на РС и будет все понятно.

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

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

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

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

Единственная проблема РН - это избыточная запись движений и только.

p.s. Озадачил Анатолий со своей уникальной структурой регистра.

... структурой индекса регистра сведений.

(211) У РН много разных проблем. Одна из них - это закрытая таблица(ы), к которой программист 1С не имеет доступа напрямую. Но и с этим как-то можно жить :)

(211) про уникальную структуру регистра по подробнее можно?

(214) "РС используют из-за того что там есть составной индекс. Больше его нигде нет"

(215) а зачем его еще используют?

(213) Ну кроме как "поменять одно из многих движений какого-то документа" я не могу придумать, когда это нужно. Как часто вам нужно поменять одно из движений документа?

(217) я не разработчик вмс - не могу за них говорить

(218) Анатолий, у вас измененное сознание, штоле?

(218) 217 пост был не вам.

Вот структура кластерного индекса таблицы остатков РН:
Период + Измерение1 + ... + ИзмерениеN (Кластерный) ) + Splitter

Вот структура кластерного индекса таблицы регистра

Измерение1 + [Измерение2 +...] (Кластерный)

Анатолий, возможно, хотел сказать, что РС могут использовать вместо СПРАВОЧНИКА, когда хотят допихать нужных полей в кластерный индекс.
Да, Анатолий?

(199) Сорри за занесение на повороте, да, немного переэмоционировал
Но всего сказанного мною по сути это не отменяет
Мы живем в России и у нас задним числом постоянно правят
И еще раз, говорю, ОСВ по складу по прежнему нужна

(217) Вопрос не в "поменять", а в "проконтролировать".

На РС можно навесить т.н. "триггер" и делать проверки остатков на лету и дополнительные полезные вещи, что в РН не сделать.

(222) Признаю, подловил ты меня

(200) Не знаю, Вафель слился без объяснения того, что именно он имел в виду

Использовать РС вместо РН это конечно, круто. Но я, как представлю, что надо самому реализовывать ОСТАТКИ, ОБОРОТЫ, а, потом они заходят разделение итогов. И все это покрывать правильно блокировками. Че там, Акселоты вернулись, говорите, на РН?

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

Надо просто немного напрячься и понять, что РН - это тот же РС, только уже с "триггерами" от 1С. Чтобы товарищь rsergio не имел ввиду под "триггером".

Мне чет тоже интересно стало, что под "триггером" подразумевалось)

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

(231) Если под пользователем понимать программиста, которому надо сделать еще один отчет, то да.

(209) ...Быструю WMS можно написать и на РС и на РН...

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

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

Акселот не пользовался и половиной возможностей РС, поэтому не поняв решили что лучше уж РН :)

(201) Ну то есть остатки на начало года я в декабре буду считать полгода или что?
Я в упор не понимаю, почему не использовать РН, заточенный под агрегаты, когда нужно получить ОСВ?
Зачем в этом случае использовать РС?

(230) https://ru.wikipedia.org/wiki/Триггер_(базы_данных)

(236) О, понеслось.

А что акселот реально делал ОСВ на РС?

Если нужен отчетный регистр, то можно в фоне перегонять данные

(225) Ой, как неудобно получилось-то

(233) Срезка не сложнее - делаем ввод остатков на дату, все движения до даты грохаем.

(240) Мне не сложно ошибки признавать

(237) Там хорошо расписано зачем нужен триггер в SQL. На 1С в РС его тоже можно сделать, а в РН нельзя.

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

(241) Ты не поверишь.

УстановитьМинимальныйПериодРассчитанныхИтогов()

(244) раньше такого не было. Может из-за этого?

(243) "На 1С в РС его тоже можно сделать, а в РН нельзя."

Примеры, а то не очень понятно.

(245) Этому "раньше" уже несколько лет.

(244) Оно все записи в основной таблице РН грохнет? Да ладно?

(242) Ну ладно хоть так
Опять, правда, в этом случае всплывает вопрос про то, нахрена РС и изобретение всяческих велосипедов...

(234) "Акселот не пользовался и половиной возможностей РС, поэтому не поняв решили что лучше уж РН :)"

Помня я ихнего спеца, преподавал на Эксперте, действительно, глупые-глупые Акселотовцы.

(248) Чем тебе записи в ОсновнойТаблице помешали? Может стоит попробовать разобраться в механизме 1С и понять проблемы ТаблицыОстатков, для начала?

(246) Ну самый банальный пример. На РС можно сделать так:

Если Запись.Количество < 0 Тогда
СообщитьОбОшибке("Нет нужного количества!", Отказ);
КонецЕсли;

И пофиг кто что пытается двинуть - отрицательных остатков не будет никогда.

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

(253) Вы были услышаны, взвешены, измерены.

(252) Офигеть, но на РН точно такое же можно сделать после записи к ВТ Остатки() и откатить транзакцию.

(255) Кроме этого на РС можно пользоваться реквизитами и хранить там дополнительную информацию для дальнейшей быстрой обработки.

У РН реквизиты только в движениях, к итогам их не пришьешь.

(256) Тут я с вами согласен.

(258) Вячеслав, на плоских таблицах cvs.

может вобоще NoSQL примениять?

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

А почему РН медленнее РС? Что то я такого не замечал.

(258) Применять готовые опробированные решения, а не писать WMS с нуля...

(195) пытаться что то "поменять в WMS задним числом" это пытаться провернуть фарш назад... Нечего там менять уже, понимаешь? Когда десятки-сотни тыщ ячеек на складе с бешенным оборотом размещения, перемещения, оптимизаций, пополнений, отборов. Там нет и не было "заднего" числа. Там есть текущая картина и есть история (архив движений).
Если что то нужно "вернуть назад", просто делается корректировка. Всё.

И тут построение этого всего на РС - это идеология подхода, а не выбранное техническое решение.

(198) "И не очень понятно, какова будет производительность получения остатков по состоянию на неделю назад"

А если в WMS налоговый период пытаться закрыть - вообще система убогая, никогда не получится это сделать там.

(262) Обновление итогов.

(223) Что у нас задним числом правят на складе?
на складе если пришло две недели назад в поставке 1000 шт - то пришло 1000 шт (или 900 - в зависимости от того ЧТО ФАКТИЧЕСКИ НАСЧИТАЛИ) - независимо от того что там впереди или взади поправят в ДОКУМЕНТАХ.

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

(268) +100

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

(269) спасибо, коллега!

(267) Наборщик отобрал 10 штук, но на ТСД отметил 12. Можно эти 2 штуки через корректировку в ячейку вернуть, а можно в отборе 12 исправить на 10. Или это не работа задним числом?

(252) Ужас какой-то
Даже не знаю, как воспринимать это всерьез

(272) Сборщик набрал 12 штук. то что регистрируется на ТСД - то и есть. нет никакого "сборщик набрал 10, а на ТСД отметил 12". есть только "сборщик набрал 12 шт".
.
при дальнейшем обслуживании товаропотока будет "зафиксировано" что недостача (на отдельном участке обработки) составляет 2штуки. эти 2 штуки упадут в "расхождения". точно также упадут в расхождения 2шт по ячейке с которой кто-то когда-то отбирал. в итоге все схлопнется в ноль. без всяких правок где-то там.

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

(259) Я думаю, это уже не модно, на png надо

(261) Рукалицо

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

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

(265) Хи-хи, ага

(267) В 99% случаев согласен, да

(279) Так и я о чем, вопрос в скорости и трудоемкости "актуализации" остатков разными способами...

(261) "Берем остатки из РС, берем движения из РС и считаем до нужного времени "взад"." - а откуда в РС остатки взялись? Или у нас подписка-триггер? Тогда чем это лучше РН? Боюсь представить как долго будет пересчет итогов идти в таком РС.

(283) "Тогда чем это лучше РН?"
Можно не заморачиваться созданием регламентного задания по установке МинимальногоПериодаИтогов(). Ну и хранить реквизиты в "таблице остатков".

(277) ну да, ну да. Я автоматизировал контору, которая сейчас на этих РС работает уже около 200 тыщ ячеек, десятки тыщ активной номенклатуры. До этого - несколько лет опыта с Manhattan, построенной по той же технологии.
Регистры накопления? ухххахаха Хахахаха!!!!!!!

А какой опыт с WMS у тебя?

А как остатки и оборотку получать из РС?
Скажем я создал РС "Остатки". Я так понял нужно делать его независимым периодическим и разрешать итоги по срез последним.

И потом делать вот так?

ВЫБРАТЬ
ОстаткиСрезПоследних.Номенклатура,
СУММА(ОстаткиСрезПоследних.Количество) КАК Количество
ИЗ
РегистрСведений.Остатки.СрезПоследних(&Дата2, ) КАК ОстаткиСрезПоследних
СГРУППИРОВАТЬ ПО
ОстаткиСрезПоследних.Номенклатура

(286) твои срезы на огромных объемах умрут

и будут говорить "ваша 1С тормозит"

(285) Десятки тыщ номенклатуры? 200 тыщ ячеек? Врешь небось, откуда столько много
Если действительно так, то да, понятно, что тут только РС вывезет такое безумное количество, РН конечно же загнется

Примерно так рассуждают колхозники, да

(286) Я имею ввиду как итоги то считать на какую-то дату.
Срез последних же по идее покажет не итог, а последнее движение.

(290) Да никак, по-человечески если
Говорят, что это редко нужная задача, плевать мол на нее по большому-то счету, как-нибудь посчитаем через задницу

Фишка в том, что РН - только и был по сути придуман для легкой возможности "исправить задним числом".
Самый что ни на есть элемент автоматизации бардака.

У всяких САПов этого нет, вот они и не тормозят.

(289) ну начиналось с одной тыщи, сейчас вот...

(287) Тогда получается нужно какие-то промежуточные итоги нужны?
Скажем период закрыли. Зафиксировали где-то ещё остаток на начало открытого периода и остаток на сейчас вычисляем как
Остаток открытого + оборот до нужной даты? Ну тоже наверное всё умрёт.

Или все операции можно делать только текущей датой. И в РС добавлять колонку  "текущий остаток".
В которую при записи писать "текущий остаток" прошлой записи + оборот по текущей?

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

(294) Внедри Арену ВМС, и все узнаешь :)))

(294) какой период, какие итоги???? WMS - это система управления складом. Система, которая опирается только на текущий остаток и обороты (для всяких там ABC и пр.). Не надо сюда бухгалтерский подход притягивать.

(297) Кстати, сколько, по твоему, будет строк остатков, если 200 тыс. ячеек? Ведь каждая номенклатура в каждой ячейке явно не хранится?

(295) Да, только в нашем случае картошку по два раза в день возят

(297) Ну WMS всё равно как-то должна отвечать на вопрос.
Сколько сейчас чайников на складе (выкинем пока адресное хранение), хотя бы чтобы не дать этот чайник продать. Ну или найти при инвентаризации, сколько чайников украли.

Или это должно быть в другой базе?
А в WMS без всяких остатков просто выполняются складские операции с выгрузкой в ту другую базу?

(298) может быть по несколько разных в одной, например в отборе

(301) Ну, допустим, миллион записей, это не много, в общем. Почему РН не потянет?

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

(302) Ну объективно записать что-то в РН медленнее чем записать что-то в РС. Пересчёт итогов там все дела.

Всегда есть некий предел по количеству операций в секунду, не важно насколько всё хорошо спроектировано.
Логично предположить, что у РС этот предел дальше чем у РН.

Но как это потом всё читать в отчёты, я с трудом представляю.

Я, если честно, вообще не понимаю всех этих стенаний по поводу количества остатков в РН, которые вполне себе неплохо проиндексированы
Думаю, что и миллион и сто миллионов прекрасно будут работать с приемлемой скоростью

Хоть заново замер производительности делай

(304) В WMS 99,9% операций атомарны - и запись будет по одной ячейке и одной номенклатуре, и при этом не задним числом.

(305) Если железо нормальное, и БД обслуживается как положено, то миллионов до 10 проблем быть не должно, а вот 100 уже тестировать надо...

Чуваки а если у РН выключить итоги и оставить только  итоги то разве при этом не будет то же самое что РС, только автоматически? и  при этом никаких затрат на обновление промежуточных итогов, не?

Оставить только текущие итоги

(307) Ну обсуждение же идёт о сравнительной характеристике учёта на РС. (лучше или хуже чем на РН), а не о том будет ли это работать без проблем до 10 миллионов операций.

(308) Запись в 2 таблицы обычно медленнее, чем запись в одну таблицу.

В 8.4 будут остатки в константах хранить)))

(310) Не сравнишь ты это впрямую никак... От архитектуры конкретных регистров все зависит.

(307) Я в свое время еще лет наверное семь назад заморочился вопросом, как объем регистра накопления влияет на скорость работы запроса получения остатков с отбором по индексируемым полям
У меня как-то явно линейной зависимости не получилось, а я вроде до 100 миллионов что ли дошел
У меня получилось, что если я в сто раз базу больше делаю, то практически ничего не меняется со скоростью
Не могу стопроцентно вспомнить, было ли у меня 100 миллионов разрезов или просто движений, нужно будет заморочиться, повторить опыт, скажем, с миллионом разрезов и со ста миллионами

(0) Миллионы, миллиарды... Про ТС уже забыли. Ему даже на УТ с трудом денег выделяют :)

(315) Будем надеяться, что он переваривает информацию, которую ему в избытке предоставили в этой теме...

(297) "которая опирается только на текущий остаток и обороты" - а как на РС грамотно организовать хотя бы текущий остаток?

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

Далеко ходить не надо, вон (253).

(317) угу. Что-то я не догоняю, какие могут быть итоги на РС? Ну есть ресурс и запись в ресурс = одно значение = один остаток. Откуда там появятся ИТОГИ ?

(319) Ты это о чем вообще?

(320) Да все просто, при каждой операции в РС пишется текущий остаток
То есть сейчас там 100, пришло 10, значит пишем 120 вместо 100
Идиотская система

Я же правильно понимаю, что в РС мы пишем в цикле? Ведь да, да?

(323) Ты плохой, плохой!
Все-равно РС лучше, потому что,... потому что,... потому что лучше, вот!

Расскажите мне про отборы набора записей Регистра...

Если в конфе нет документов то в какие еще регистры можно писать кроме РС?

(326) так там больше никаких и не будет, Ваш Кэп

(326) Так может ну ее, эту 1С?

Я хочу сказать что хранение текущ остатков в РС вполне рабочее решение. Если не нужны остатки на произвольный момент.

(282) не надо изобретать "разными способами". есть установленный регламент обработки товаропотока. вот по нему и действовать. Всяческие изобретения, особенно оперативнфм персоналом или АУПом без консультации с логистом или админом системы - потенциально опасны.

(329) видимо, что мы немного по разному оцениваем термин "Остатки". Мне как-то трудно называть остаткамИ текущее Количество, сохраненное в поле Ресурс.

(326) Я предлагаю пойти дальше
Если в конфе нет ничего, кроме констант, то куда можно писать движения ТМЦ?

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

(329) Почему?
Потому что "Если в конфе нет документов то в какие еще регистры можно писать кроме РС?"
Твоя логика просто рвет реальность в клочья

(323) там же строки в основном по отдельности обрабатываются (306)

(331) а какие проблемы?

есть таблица "остатков"
* Номенклатура-ТекущийОстаток
и все...

есть таблица "движений"
* номенклатура-датавремя-количестводвижения

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

текущие остатки - есть.
ОСВ - строим от текущих остатков разворотом движений назад.

всё...
минимальная рабочая система есть.

(336) собственно ты описал , то что у 1с внутри

Не так важно на чем будут сделаны остатки, гораздо важнее какую структуру они будут иметь!

Например, в 4-ой логистике в РН "ОстаткиТоваров" всего два измерения - "Контейнер" и "КлючАналитикиУчетаНоменклатуры".

"КлючАналитикиУчетаНоменклатуры" - это справочник, содержащий реквизиты "Номенклатура", "СтатусНоменклатуры" и "ПартияНоменклатуры". Также есть РС "АналитикаУчетаНоменклатуры" с точно такими же реквизитами.

А чтобы привязать контейнеры к ячейкам есть отдельный РН "ПоложениеКонтейнеров" с измерениями "Ячейка" и "Контейнер".

Вот теперь подумайте насколько удобно оперировать такой архитектурой. А потом я еще покажу как хранятся остатки товаров, которые хранятся в ячейках без контейнеров :)

(337) спасибо, я не знал

(323) в каком цикле?
Один пик на ТСД, наложили на запись блокировочку управляемую, записали, блокировочку сняли. А в цикле это как? Проведение по табличной части документа еще скажите, ага.

(338) меня эти акселотовские выморочки с контейнерами, не существующими в реальности - доставляют и ломают мозг ;-)
.
понятно, что это , скорее всего, позволяет решить ряд задач, но это как-то противоречит моему чувству прекрасного...
.
с другой стороны как ркасиво сделать фишку что есть три нумерованных стандартных евроячейки 120*80*H. И как КРАСИВО "нарисовать" чтобы можно было товар с известными габаритами - превышающими размер одной ячейки (например диван размером на две стандартные ячейки) положить в две ячейки сразу. чтобы эти две ячейки были "щзаняты"...

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

(341) область "диваны", в которой в тройке ячеек две заблокированы

(340) "Один пик на ТСД"

Без права на ошибку.

(342) ну да, с чтением конечно

(330) Конечно. Я имею в виду, что "работа задним числом" может являться частью регламентов работы.

Че, прям каждый пик является конечной операцией, выносящей товар с остатка? Без резервов, без буферов ошибок?

(347) Да, а в чем проблема?

Или все таки "пики" записывают в 2 регистр "Резерв" ?

(340) Вопрос блокировок интересный, конечно...

(349) В разных WMS реализовано по-разному, где-то резервирование делается прямо в регистре остатков...

(348) Раз у вам возникают такие вопросы - оно вам не нужно.

(352) Ты о чем?

(353) О проблемах с пиканьем на складе.

(343) и че, когда диванов нет - область будет простаивать? а когда двиан появится - совобождать ячейки из области диванов когда есть другие свободные ячейки не в области...
не годится...
опять же..
ячейки 1-2-3
перед появлением дивана размером с две ячейки
могут быть ситуации
- свободны все ячейки 1-2-3
- 1занято -2свободно -3свободно
- 1свободно -2свободно -3занято
- 1занято - 2свободно -3занято.

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

(354) О каких проблемах? Выражайтесь яснее пожалуйста.

(351) развивайте мысль... Собрали заказ, нарезервировали в РС.

И мы начинаем закрывать записи резерва...

(346) нахрен такой регламент. я стараюсь такое вообще не применять как регламент, а расматривать как форс-мажор.

(357) Почему в РС? Или вы сейчас чисто про WMS на РС разговариваете? Это к разработчику Арены rsergio тогда..

(347) в общем случае - да. Сборщик взял товар с ячейки - пик. в самом худшем случае 1. товар списался с хранения с ячейки и 2. товар записался на хранение на ячейку-сборщика.

(358) Не надо быть столь категоричным. Вы не все в этой жизни видели...

(356) Еще раз. Оно вам не надо. Раз задаете такие вопросы.

(359) Извиняюсь, перепутал.

(347) В WMS практически все операции атомарны - перемещение товаров из одного места в другое. Каждая операция фиксируется.

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

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

(361) согласен. но мириться с хренью и признавать это нормой - лучше такого избегать.

(365) Это бизнес, минимизация затрат и увеличение скорости работы рулят...

(362) Ладно, продолжайте разговаривать с тараканами в своей голове...

Занятно, никому не приходит мысль в голову сделать WMS используя только внешний источник данных. Никак психологически из объектов 1С вырваться не получается.

Но тема шикарная. Хотя вопрос с индексами РС не раскрыт.

(369) В 1С нельзя сделать составной индекс, по 2-м реквизитам справочника например. И чтобы обойти это ограничение, пишут эти реквизиы в измерения РС и добавляют последним ссылку на элемент. Таким образом создается используется кластерный индекс, соотв-щий порядку полей в условиях запроса, т.е. эмулируется составной индекс. Но это Вафель не в тему брякнул, к этой теме это никак не относится. Как говорится, слышал звон но не знает где он.

А у Печенюшки пукан взорвало от того что можно хранить остатки в РС. Ламеры кругом, хотя себя гуру считают, что один что другой.

(368) У Раруса есть система, где от 1С взята только оболочка, а хранение данных не на 1С.

Только зачем?!

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

(372) ну плюшки в виде триггеров на уровне БД и то что ои сделали возможность вызывать хранимки как функции из 1С очень заманчивы.

(373) большинство SQL-щиков уровня MVP относятся к триггерам скажем так прохладно, и только 1С-ники почему-то на них надрачивают...дались вам эти триггеры, вы все равно с ними работать не умеют

(373) + так получилось что мне довелось лепить 1С в качестве фронтенда поверх одной из греческих WMS. Правда без записи в БД но получилось интересно.

(374) таких чванливых в любой области можно найти. Детектятся по словечкам типа "моветон".

(374) да и че там уметь, on insert, on update. Довольно простая и понятная техника.

(377) мне за тебя погуглить почему триггеры зло?

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

(379) а зачем тебе триггеры при работе с 1С? пример практической задачи

(0) У меня тут контекстная реклама вылезла, как раз в тему (большой брат все же следит за нами:)))). Может вам пригодится, там как раз про склады и вмс.
http://kesoft.ru/vnedrenie-wms.html?yclid=3777169550967584387#content

Вот еще
http://wms.sfx-tula.ru/?_openstat=ZGlyZWN0LnlhbmRleC5ydTszNTgwNTQ5Nzs1OTEwMTQ0NTEyO3lhbmRleC5ydTpndWFyYW50ZWU&yclid=3777277920200374063

(375) ...одной из греческих WMS...
это к какой - мантис или LVS :)

(379) Ты же тупой 1С-ник, не найдешь ничего. Слился при простом вопросе (380)
триггеры ему нужны
https://www.osp.ru/winitpro/2015/02/13044724/

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

Но в 1С "триггеры" по другому используются - они обрабатываются до записи данных в SQL, ещё на уровне сервера 1С и на весь набор записей, поэтому никакой дополнительной нагрузки, кроме времени выполнения самого кода нет.

(385) а можно ссылку на документацию 1С, где сервер 1С делает... триггеры?

/*еле произнес этот бред

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

Смысл в том, что у РС есть модуль набора записей и процедура ПередЗаписью(), где набор записей - это и есть непосредственно остатки, соответственно можно выполнять любые проверки и любую другую дополнительную логику.

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

(368) А смысл? Для 99% складов возможностей 1С за глаза хватит...

(387)
>>В РН мы можем работать только с движениями, но не с итогами, которые скрыты от разработчика в недрах платформы.

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

(387) Тут какое дело - объективно особых преимуществ нет ни у РН, ни у РС (при правильной архитектуре), поэтому, ваши аргументы (как и аргументы сторонников РН)выглядят не очень убедительными...

(390) у тебя вообще нет никаких аргументов и один бред, помолчал бы лучше

(391) Так я видел высоконагруженные промышленные WMS как на РН, так и на РС, поэтому весь спор не имеет смысла.

(392) так нет никакого спора и rsergio так и говорит что без разницы на чем делать, это Вафель загнал в сторону и Печенюшка (PR) от скудоумия начал бычить

(392) Зачем ты споришь с Мишанькой Чебаркульским?
Фу фу фу :))

Печенюшка иди спи алень

Но сначала индексы подучи, деревня

(389) Хм... как еще объяснить, что таблица остатков скрыта от программиста?

В РС можно добавить реквизит, который не будет входить в основной индекс по измерениям, но мы можем туда записывать нужную информацию, которая поможет в дальнейшем в больших запросах экономить время.

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

В РС мы можем добавить реквизит "ТипЯчейки", что позволит обходится запросом к одной таблице.

Но в целом это мелочи, которые просто упрощают жизнь. По факту важнее сама архитектура построения системы, от которой больше зависит, чем от какой объект использовать.

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

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

(399) т.е. если мы проектируем данные под критичные запросы это долбоебизм? Ты вроде в 1с работал а такой бред несешь

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

И что значит пихать? Другие измерения пихать не западло?

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

(400) Я бы не стал включать в измерение РН и его кластерный индекс второстепенные данные. Их по факту нужно не один и не два, а больше. А РН с 15 измерениями, где только 5 основные - это через одно место.

С РС все гораздо проще. Добавил реквизит, добавил заполнение в ПередЗаписью() и осталось только запросы переделать, сами модули записи движений остаются нетронутыми.

И это только вершина айсберга, на РС есть еще много очень удобных вещей, которых никогда не сделать на РН.

Но если бы партия сказала бы сделать на РН - не вопрос, пришлось бы чуть по другому сделать. Залог быстродействия не в этом, а в проектировании архитектуры хранения данных и понимания работы SQL сервера. Большинство 1С-ников отдаленно понимают как их код работает на SQL.

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

Ничего себе Мишу бомбит :))

Ромка это тебе не про это философию УФ рассуждать, это реальный хайлоад, законспектируй мои посты пока их не удалили

(406) А кто это?

(407) Да не, я как-нибудь обойдусь без твоих шокирующих взрывающих интернет инфовыкидышей :))

(408) Да Миша Панюшкин из Чебоксар
Мой личный поклонник :))
Его банят, а он новые ники клепает каждый день :))

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

(414) >> в таких случаях вмс даже вообще не нужна

Кому не нужна?
Тем, кто получил откаты, и получит повторно за перевнедрение?
Еще как нужна, зря Вы так резко.

(416) это да, смотря с какой колокольни смотреть.. ;-)

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

(414) Вы еще скажите, что для весового товара надо запрет отгрузки "в минус" сделать...
Пессимист вы, Сергей :)) Если отклонения не являются системой, и впоследствии анализируются и корректируются, ничего страшного не произойдет.

(419) весовой товар - отдельная тема, у него свои заморочки по обработке.

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

я не пессимист, просто "каждый одинэсник-автоматизатор в душе - гестаповец" ;-)

(409) ты и без мозгов обходишься

(117) Видеоверсия, если кто не видел :))
https://coub.com/view/19r6d7