Разбираюсь с кодом предшественников, и нашел там одну особенность. Для ускорения получения остатков и резервов номенклатуры, эти остатки и резервы хранятся в самом справочнике номенклатуры в виде реквизитов, и меняются регламентной процедурой каждые 5 минут. То есть каждые 5 минут в фоновом режиме строится запрос по регистру остатков, его результаты сверяются с этими реквизитами справочника номенклатуры, и если они отличаются, то получается НоменклатураОбъект, туда устанавливаются новые значения и объект перезаписывается. В связи с эти у меня возникло два вопроса:

1. Когда существующий элемент справочника перезаписывается в базу, то заново перезаписываются все реквизиты, или они сравниваются теми, что были ранее, и записываются только измененные? Просто запись почему-то идет очень долго...
2. Если я для хранения текущих значений остатков сделаю отдельные регистры сведений, понятно, что их запись будет ижти быстрее. А вот будут ли они читаться так же быстро, как и реквизиты номенклатуры?

(0) бугага
зачем их хранить где то еще, кроме как в регистрах остатков?

(0) Выпили это нахрен.

(0) Не надо хранить остатки в справочнике... У вас перезаписывается весь объект, а там полюбому 100500 различных проверок производится

Интересно, а как предшественники собирали остатки по дням отчет?)

(0) А зачем так хранится то? В отчете данные берутся каком то из реквизита? Или при проведении документов каких? В любом случае лучше брать данные по остаткам из виртуальной таблицы остатков

(0) будет примерно тоже самое, что брать их из текущих итогов;
имхо, лучше убрать нафиг

так в 7.7 раньше веселились. кто то видно на старых дрожжах в 8 заехал)

(7) там был вроде периодический реквизит)

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

>1. Когда существующий элемент справочника перезаписывается в базу, то заново перезаписываются все реквизиты, или они сравниваются теми, что были ранее, и записываются только измененные? Просто запись почему-то идет очень долго...
Вроде, это работает только для регистров накопления (движений документа).

>2. Если я для хранения текущих значений остатков сделаю отдельные регистры сведений, понятно, что их запись будет ижти быстрее. А вот будут ли они читаться так же быстро, как и реквизиты номенклатуры?
1С при обращении через точку делает внутреннее соединение с таблицей, так что в теории - будет также.

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

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

(12) осмелюсь заметить - для получения неактуальных остатков

# Здесь мем с Лавровым

(1)
Регистр накопления, состав индекса "Таблица остатков"
[ОРРХ | ОРНР1 +] Период + Измерение (Измерению "Измерение" задано свойство "Индексировать"(начиная со второго измерения).

Поэтому регистр сведений быстрее.

(15) Почему?

(9) Согласен - в этом случае хоть какая то польза от данного механизма

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

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

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

(20) в любой(ну наверно) типовой открываете справочник и видите внизу/сбоку/ с прискоком табличку, в которой выведены текущие остатки, рассчитываются приактивизации строки, проблем с получением не видно

(19) Им многого не надо - хотят видеть общий остаток по всем складам )

я вижу 2 варианта:
1) В дин списках получать остатки из виртуальных таблиц рег. накоплений и прочих условий и логик
2) Создать рег. сведений, с остатками и получать из него остатки. Регламентно его обновлять. Весь вопрос в быстродействии и оперативности данных. Либо 50 юзверов каждые несколько минут по 20 раз юзают таблицу, где по сложной логике получает 1с свободные остатки и резерв+еще какие-нибудь данные. Либо мы заранее регламентом получаем данные и пишем в табличку.
Вот только выбор в справочник был крайне не удачный, так как приходится весь объект перезаписывать. Плюс ко всему блокировка таблицы происходит.

(22) ну а подлежащие списанию, которые переместили на склад, с которого потом списывают? они тоже будут в этой куче

(22) Ведомость товаров на складах им в помощь)

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

на ИТСе пишут, что в УНФ все это есть
https://its.1c.ru/db/answers1c/content/1240/hdoc
может надо конфу немного изучить?

(21) В подборе такое тоже есть. Но вот именно, что получение остатков происходит при активизации каждой строки - а пользователь хочет видеть в отдельной колонке, и сразу, не активизируя каждую строку отдельно )

(28) Номенклатура + левоесоединение с оперативной таблицей остатков

(28) А у вас есть понимание, почему именно так было сделано в типовой?)

(0) это могло быть актуально в эпоху 8.0 или интенсивного роста 8.2 (когда были некие глюки в некоторых промежуточных подверсиях).
в 2022 году это невероятно древний и кривой костыль. это никак не может быть быстрее.
(20) на каком складе? на какой организации? какой состав измерений в РН остатков?

Хех. Посмотрел типовую. Выводят в отдельную колонку, берут через левое соединение с РС РаспределениеЗапасов.
ERP 2.5.7

(28) конфа какая?

(32) может у ТС отраслевка какая-нибудь на 8.1)

(28) "каждую строку отдельно" а все вместе, это что - документ, список справочника или что? ну в любом случае можно прикрутить куда угодно.
(33) ну да, я почему то решил унф, наверно тему перепутал

(33) Розница 2.3.

(0) СпрОбъект.ОбменДанными.Загрузка = Истина;

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

Для формы списка тянутся же данные только для Номенклатуры, которая отображается в списке + одна страница вверх и одна страница вниз? Или каждый раз для всей номенклатуры?

(36) В рознице иногда остатки вообще не важны при продаже - если товар на полке лежит. Что за товар?

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

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

Для анализа склада есть отчет Оценка склада, а для подбора в рознице нет смысла вообще остатки показывать в списке, если позиция интересует - ее сканируют, позиционируется строчка и показывается остаток на складах.

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

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

"ее сканируют, позиционируется строчка и" - а если сканируют что-то большое и не подъемное :-) Шутка.
Я к тому же. В рознице отказать покупателю в продаже, так как у тебя по остаткам показывает, что нет в наличии, когда покупатель в руках это держит..... Ну как бы...
А если продают оргтехнику, то тут в руках может и не держит, а получение на складе Ситилинк тот же. Тоже розница, но без зала.

(38) (43) Это Розница, но отраслевое решение - "Магазин автозапчастей". И сразу знать, что есть такой-то болт для конкретной тачки, или такая-то АКБ - никто наверное не сможет.

(45) В этом случае нужно будет допилить форму так как вам нужно с учетом комплектующих. Для этого дело есть и специализированные конфигурации. Так как там различные аналоги и т.д.

*дела

а блин, это же типовое решение на базе розницы)

(45) всё хуже, он подбирает аналоги. перед тем как сбежать попробуй со скоростью разобраться и забрать деньги

ну.. актуальные - они на сейчас, сейчас - оно одно. а неактуальные - это на когда?

на время отработки задания до 4:59
"я нажал, а оно а оно не показывает, а ему, ему нужен сранный ссальник" **показывает на чела с деньгами в руках, "плачет"

И такое бывает.

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

(18) >поставь индекс где хочешь
Ставьте, толку? Спереди будет Период.

Вы путаете с физической таблицей

Регистр накопления, "Основная таблица регистра"
[ОРРХ | ОРНР1 +] Измерение + Период + Регистратор + НомерСтроки
Измерению "Измерение" задано свойство "Индексировать".

(54) И? 1С вставит в запрос условие на период = 3999 году

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

(0) Выпили эту гадость!
Если уж сильно хочется именно так то.
1. Создай РС не периодический. Назовем это "ОстаткиТоваров". Измерение Номенклатура Ресурс остаток.
2. Обновляй остатки в нем хоть каждые 5 минут хоть каждую 10 минут При условии если остатки изменились.
3. Делай левое соединение номенклатуры м этим регистром.

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

Проанализировать через сервис Гилева из-за чего делается долго. Или хотя бы замером производительности.

Для ускорения
1) Записывать в режиме ОбменДанными.Загрузка. Убрать проверки.
2) В спр. номенклатура добавить Реквизит "ДанныеОстатков". В него писать текущие остатки. За счет этого не должно быть блокировок  
3) Вычистить планы обмена от спр. номенклатура.

Спорить о том правильно это или нет не буду, только замечу: принципе, чисто теоретически, остатки и резервы в справочнике можно актуализировать при записи в соответствующие регистры конфигурации, используя пресловутое "ОбменДанными.Загрузка = Истина" для скорости. Тогда вопрос тормозного регламентного задания отпадает за ненадобностью :)

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

Перезаписывается целиком, но сама запись справочника средствами СУБД занимает милисекунды. Тормоза идут из-за проверок, расчётов или блокировок. Плюс скажем есть у тебя 200 тысяч элементов справочника, и вот 200 тысяч раз в цикле сервер обращается к СУБД что бы найти и изменить запись... В теории можно ускорить, тут уже писали как.

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

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

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

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

(62) Даа это 5 ое колесо при уже существующем 4 нормальных.

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

(64) и прикрутить к нему последовательность, с измерением по номенклатуре.

(55)

Создал тестовую:
1. Регистр сведений (независимый)
Склад + Номенклатура (принудительно добавил индексирование)
Ресурс: Количество
2. Регистр накопления
Склад + Номенклатура (принудительно добавил индексирование)
Ресурс: Количество

3. Записал тестовые данные на 1 млн уникальных записей.

Выполнил запросы:
1. Справочник Номенклатура с левым соединением регистра сведений:
CPU = 1031, Reads = 10979, Duration = 1035

2. Справочник Номенклатура с левым соединением регистра накопления (без параметров виртуальной таблицы):
CPU = 1688, Reads = 13330, Duration = 1693

(59) ""ОбменДанными.Загрузка = Истина"" в (37) уже предлагалось. Не пробуют и не рассматривают такой вариант. :-)

(66) Ну и?

В РС кластерный индекс Склад+Номенклатура=16+16=32 байта на запись
В РН кластерный индекс Период+Склад+Номенклатура=6+16+16 = 38 байта на запись

РС/РН=32/38*100=84% оценочно

10979/13330*100=82% фактически. Никакой магии, влияние поля Период, вот и всё.