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

Понимаю, что перезаписывать элементы справочников каждые 5 секунд - это плохо, но...

(0) наверно ты криво сделал "поиск по виртуальной таблице остатков", вот и тормозит. А они хорошо сделали, вот у них и летает.

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

с учетом понимания погрешности, конечно.

1-2 ошибки несоответствия в неделю проблему не вызывает, а задача бизнеса решена.

(1) Как можно криво сделать?
Нет, ну я не спорю, у них перезаписываются не все элемента справочника, а только измененные.

+(3) Вернее, только те, у которых остаток поменялся )

(3) нет таких вещей, в которых 1с-ник не смог бы накосячить...

В УНФ в общем-то аналогично сделано.

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

И в итоге - очень быстро работающий список с остатками.

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

(6) Вот! Я и хотел предложить им сделать регистр сведений. Не знал, что это уже есть в типовых.

(7) Подожди, а чем резон переделывать? Я что-то прочитал и не понял. Остатки немного разняться? За 5 минут существенно меняются?

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

(9) булевый реквизит дольше писать. Там ведь еще дополнительно проверка, сравнение с нулем.

(10) НеВпрайсе = (0 = текОстаток); - разве так не отработает? к тому же по булевому проще для индексации

Если не изменился то надеюсь не перезаписывается элемент?

(0) минусы реализации

1. если включить версионирование номенклатуры - будет треш
2. практически не возможно по логам определил кто менял номенклатуру
3. записывается сам объект а не одно поле

в любом случае
1. раскраска по остаткам - выкинуть в отчеты, не в динамическом списке а в ОТЧЕТАХ
2. фильтр по наличию - можно сделать и в динамическом списке ПОДБОРА а не списке номенклатуры

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

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

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

(15) ну ты ж понимаешь - "да у нас склад всегда был один, и будет!" :-))
ну а потом "мы ничего не делали, а остатки пропали [или задвоились]"...
классика жанра...

(17) к сожалению да, люди не могут моделировать ситуации

задача была про хранение одного товара в разных ячейках
вопрос: у вас бывает такое?
ответ: ну очень редко, давайте мы не будем такое рассматривать
результат: по факту оказалось около 10% товара лежит в нескольких ячейках

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

(0) Это называется денормализация.

С т.з. архитектуры это конечно плохо, но в 1С есть правило: если помогает бизнесу, то можно.

(0) Для конфигурации Розница Аптека у меня сделан "Прайс-Лист" - своя форма подбора номенклатуры по остаткам в РМК
Глянь как https://github.com/Garykom/1C_Roznica_Apteka/blob/master/Аптека_2020_06_24_01.cfe
И оно не тормозит если индекс полнотекстовый не сглючил

(0) Имхо это решение вам придумали и сделали 7чники, в которой иначе было нельзя (сам там такое делал и юзал неоднократно)
В 8-ке и тем более УФ все намного проще

(20) это уже не "денормализация", это попытка изобразить кэширование...
(22) в клюшках тоже можно нормально писать.

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

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

(25) я прекрасно знаю, что такое кэширование и как оно делается.
а в (23) я ж написал про (0)- "попытка изобразить кэширование".

(0) как-то такое видел для печати ценников. ;-)

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

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

(26): я об этом не спрашивал.

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

* "добавить поля"

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

Ага, нормальное решение🙄
А потом попросят сколько заказано, а потом дату поступления, а потом сколько в головном офисе и тд

(34): такой разработчик на клиппере: "ага, а потом попросят чтобы им в одном отчете остатки и резервы выводило и т.д."

ЗЫ: а вообще - если еще один реквизит под время актуализации, и доступную "быструю кнопку" обновления... вполне себе норм решение. даже с учетом (34).

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

(36) "быструю кнопку" обновления...
Принудительно обновлять при открытии формы списка... Не?

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

(39) непонятно... РН Остатки без даты берет непосредственно из физической таблицы остатков на какую-то там дату 3999 года (могу путать)
И в чем выгода писать еще в РС?

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

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

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

а что там в (0) автор "сделал поиск по виртуальной таблице остатков" - это оно такое, можно было динамический запрос нормально написать, а можно и событие ПриПолученииДанныхНаСервере использовать и дергать в цикле остатки (как любит делать гений 1с)

(0) Если все это перенести из справочника в регистр, то это будет рекомендованной реализацией от 1С для динамических списков, в которых нужны данные из виртуальных таблиц регистров (исключение с ньюнасами для срез последних и остатки)
https://its.1c.ru/db/v8std/content/732/hdoc

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

(0) Это называется кэширование. Я бы делал через регистр.

(7) "Я и хотел предложить им сделать регистр сведений." - юзеры и слов таких знать не должны. Сделай и всё.

(0)
Формы наверняка не управляемые.
Так что тебя тогда удивляет?

Я *каюсь* на неуправляемых формах даже реквизиты в документы добалял типа "есть подчиненный документ". Исключительно для отборов и оформления в списках.

на всякий случай(для УФ): https://wonderland.v8.1c.ru/blog/obrabotka-i-oformlenie-dannykh-dinamicheskogo-spiska/ собственно, плюсы подхода расписаны в самой статье пятилетней(!) давности

(50) угу я так примерно и делаю обычно
и нахер не надо каждые Х минут номенклатуру перезаписывать
что когда ее много выливается в дикие тормоза

(35) На клиппере это делалось очень просто - получить остатки и резервы. В любом месте, хоть на форме хоть в отчёте... Любой каприз за деньги клиента ! :-)

(0)  "Я сделал поиск по виртуальной таблице остатков"  - давай запрос твой посмотрим