v8: Замена регистра накопления регистром сведений, минус к производительности? #645920

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не всегда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А на РН?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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