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

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

(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