Бытрое получение остатков регистра накопления в табличном поле #27107

Проблема заключается в получении наискорейшим образом всех остатков регистра накоплений на текущую дату (на дату расчета итогов) в табичном поле ! Есть ли встроенные средста типа связи РегистраНакопленияСписок с табличным полем ?

ИМХО - лучший метод - запросом получить таблицу значений остатков.

К сжалению далеко не самый быстрый...А проблема еще и в том, что это надо для подбора номенклатуры. И главное требование заказчика - обновление остатков один раз в секунду.Запрос такого дать точно не может. Еще идеи есть у кого ? У меня тока идея сделать доп. регистр сведений и связать его с Табличным полем. В нем хранить тока текущие остатки. Работает чрезвычайно быстро, но...Проблемемы с поддержкой актуального состояния этого регистра... Вообще не понятно - должна же быть таблица остатков в 1С ! Почему ее нельзя связать с табличным полем ?

Для подбора просто используют в запросе фильтр по текущей открытой группе. Желание "Раз в секунду" - определенно результат мании величия. Сколько пользователей ? Сколько номенклатуры ?

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

Нет, нет! Мания величия не причем !!! Так действительно надо для бизнеса! Пользователей 100, номенклатуры активной 1000000. 18 операторов принимают заказы клиентов и им действительно необходимо видеть актуальные остатки. Так что запрос не прокатывает. Так идей нету ?

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

Однако все это надо видеть в разрезе серий и характеристик! Это чрезвычайно актуально !

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

Все равно будут ситуации, когда один оператор провел документ, а другой только собирается, 1-й уже продал товар, а 2-й получил сообщение о недостаточности. Можно конечно в самом справонике хранить - но это страшное извращение.

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

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

Даже штатными средствами получение остатков по правильно заданному условию, которое включает примерно 50-100 элементов, отработает меньше секунды. Еще расскажи про конфигурацию сервера и сети. Как насчет того, чтобы разнести сервер 1С:Предприятия и SQL-сервер по разным компьютерам?

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

Мы пробывали запрос 5000 актуальных остатков. запрос отрабатыает 0.3 секудны..Но вот вывод результата в ТабличноеПоле - гораздо дольше. Сервер очень хороший 2 ксенона 4 Гига памяти скази и все такое. Абсолютно понятно, что запрос для данного случая не применим. Это не проблема - речь идет только о заказах, а не о продажах. Даже если возникла такая ситуация что товара не хватило - на складе это скоректируют, но по теории вероятности это будет очень редко. Склад большой - конвеер и все такое.Логистика, оптимизация - прочие фишки. Это не у нас - я франчайи, а это мой клиент, так к сведению.

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

Ясно - сервер хороший. А станции ? Ведь вывод в ТабПоле станция делает. Как вывод делали ?

Спасибо. Попробую. Ну что-то мне подсказывает, что на 100.000 и когда база вырастет - все равно запрос не потянет (

То 0. Существуют несколько технологий по данной проблеме.   1)Реализация в 1С. Там и так все остатки хранятся в ТА. Не устраивает сокрость получения объединения по этой таблице и справочнику товара? - Сделать дополнительную агрегацию. - Доп таблица в которую будут писатся остатки и в которой будет наименование товара в явном виде.При правильной реализации не так много будет тормозов. 2) Реализация опповещения на сокетах. Т.е. при изменении остатков по определенным позициям происходит оповещение заинтересованных клиентов. Есть еще механизмы. Нужно также отметить что необходимо как правило селективно отображать остатки... Механизм 1С для этого не совсем подходит в плане навигации и графического интерфейса. Я в свое время аналогичные задачи решал через внешние компоненты с помощью прямого доступка к SQL. А вообщем если это действительно очень нужно то обращайтесь - обсудим , реализовать это возможно.

делали на станции - П3 800 512 ОЗУ. Сам запрос выполнялся на сервере приложений. А выгрузка результата запроса - на станции.

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

Да мысль хорошая - действительно объеденение таблиц типа Номенклатура, Серии и тд. в запросе занимает чрезвычайно много времени. Например при отключении таблиц. Ед.Измерения и СерииНоменклатуры запрос стал выполнятся 0.3 секунды, хотя до этого выполнялся 2.4 с.

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