Коллеги, добрый день!

Стоит задача: необходимо разработать документ, в котором в разрезе Организация, Контрагент, Договор будут предзаполняться некоторые числовые значения, а некоторые пользователи могут их переопределить, некоторые должны накладывать резолюции, с хранением истории.
Специфика задачи такова, что итоговое количество строк по документу может превышать 20000.

Хранение данных предполагается в регистре сведений, чтобы было удобно отчетом выводить данные.
Возник вопрос, как лучше реализовать ввод изменений - создать ТЧ, чтобы пользователь с ней взаимодействовал и при проведении документа делать движения в этот регистр, или же разместить на форме сразу Объект.Движения.<ИмяРегистра>, чтобы дважды не хранить одно и то же.
Предполагается, что пользователи могут пользоваться поиском по контрагенту и договору. Важен вопрос производительности. RLS присутствует.

Подскажите, как лучше реализовать

регистр, но на форме список, а не Объект.Движения.

(0) в случае регистра сведений непосредственно можно быстрее изменять - необязательно ведь все 20000 строк перезаписывать

Задача непонятна. Но надо пересмотреть текущую реализацию, уйти от гигантских ТЧ. Например, можно завести справочник, организовать хранение "1 контрагент = 1 элемент"

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

(2) Вы предлагаете дать доступ непосредственно к РС? Чтобы правили непосредственно в нем?

(0) можете реальный пример привести, когда нужно 20000 строк в документ фигачить? На моей памяти лишь документ ввод остатков и док расчета себестоимости. В первом случае все логично, более 20000 SKU на каждый своя строчка в вводе остатка. Второй вариант РасчетСебестоимостиТоваров - у него нет ТЧ со 100500 строками, он хранит лишь проводки по всем товарам где рассчитана себестоимость, этих строк тоже может быть много.

(4) ну сделай форму "всё видеть, всё править", а само хранение более компактным

я так и не понял от ТС какую задачу он решает, какой бизнес-процесс пытается реализовать. Но чуйка подсказывает, что пихать в документ 20к строк в тч, еще и историю в нем вести - не правильно.

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

(8) Например, тендеры. У меня подобное есть от предыдущего ведущего спеца. Всё никак не дойдут руки доделать нормально...

(5) да. Историю рс можно вести платформенными методами

(4) п-ж. они НИКОГДА не будут интерактивно взаимодействовать со всеми строками ТЧ, кроме ситуации ввода начальных остатков. да и те поделят на смысловые группы.
(0) ещё ни разу не видел реализации такого "концепта", которая не привела бы к про..у данных. всегда найдется дыра, благодаря которой движения регистратора где-то потеряются.

просто примите как аксиому - движения документа это результат анализа и обработки введенных В ДОКУМЕНТ данных.

(6) Это кастом: даны формулы, нужно агрегировать данные, по формулам выполнить расчеты и вывести результат.

(13) а зачем вам история в документе? Док это первичка, которая может создать проводки. Анализ уже производится на основании регистров. Например:
Дана формула, для клиента ООО Вася и КО с 1 июля переоценить товары из матрицы ценовых групп, предоставив определенную скидку 5% по соглашению БезналПеродплата100%. Так же нужно видеть историю изменения цен для клиента.
По вашей логике нужно создать документ, вхерачить туда портянку всех цен и кто их менял и переоценить текущие на определнную дату. Я вас правильно понял?

вывести на форму документа набор записей и пусть пользователи в нем шарашат.

(12) а как же документ "бухгалтерская операция"? бухгалтера постоянно им пользуются, а еще изменяют движения в существующих документах, где процессы не автоматизированы должным образом.

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

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

Я понимаю, что просят не самое оптимальное решение с точки зрения пользовательского опыта и т.д.

Но на данный момент нужно понять, что будет работать быстрее при большом количестве строк: через ТЧ, через объект.Движения.<ИмяРегистра>

Я смотрел реализации типовых конфигураций, потому и призадумался о подобном механизме как в документе "бухгалтерская операция", но здесь в полный рост будет стоять проблема производительности поиска

(12) Я с Вами полностью согласен с тем, что из 20000 строк будет изменено от силы 250.
Проблема в требованиях - просят реализовать именно так и не иначе.
Какие бы ухищрения я не предлагал.
Хотим видеть все большим списком - и точка

(18) делай АРМ, который будет создавать и записывать документ с порцией изменений\фиксаций.

(19) А из типовых пример-аналог наиболее подходящий можете подсказать?

(18)

Видеть -- это отчет
Менять -- это отчет или обработка.
Фиксировать -- это документ

Долбо.. (нужен эвфемизм) -- это обычно дорого.
Когда они упёртые -- еще дороже.

Если они хотят странного за обычный деньги -- машем ручкой.

P.S.
Вы изобретаете ЦеныКонтрагента ?

P.P.S.

А потом, потом они захотят всё это порно выгрузить в КПК, вот где будет смех
И прикрутить сверху еще пару измерений, чтобы колво записей было 1кк или больше.

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

С вас же потом спросят, а почему 1ска тупит, почему столько места занимает, раньше то 20гигов хватало, а сейчас за 500 перевалила.

(21) Вы изобретаете ЦеныКонтрагента ?

Нет, но к сути вопроса это отношения не имеет.

По всем прикидкам и оценкам строк максимум будет 20к +-.

Загрузка однократная, далее корректировка загруженного.
Что потом будет - не знаю.

У меня вопрос был только в том, как бы это все более-менее шевелилось, кто с чем сталкивался на личном опыте, какой подход был наиболее производительным.

Потому что задача очень специфичная

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

(25)

Просто нагенери 20к записей и попробуй

(25)

Я бы
1) Сделал отчет на СКД, с возможностью редактировать колонки с "некоторыми числовыми значениями"
Либо опять таки отчет на СКД (оставив от него отборы), но с выгрузкой в таблицу значений

2) В форме отчета две страницы. На одной сам отчет, на второй табличная часть со столбцами "Организация, Контрагент, договор, "некоторые числовые значения""
3) Формируем отчет с отборами по неким критериям, меняем данные в колонках. Измененные строки отражаем в таб.части
Заодно в этой же таб.части смотрим чего наменяли за сеанс

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

Если пользователи меняют вручную -- то этот вариант годный, ибо натыкать вручную более 1000 записей имхо подвиг.
Если пользователи будут хотеть спец. кнопки "а-ля поменять всем 20к такой-то ресурс на +20, а такой-то на -70",
тогда я бы смотрел в сторонку идеологии обработки "Групповое изменение реквизитов".


P.S.

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

(25) ну так сделай операцию бух на 20к записей и попробуй её раз 5 открыть-поменять-закрыть.
вряд ли ты сможешь написать что-то сильно лучше.

(20) в ут11.5 работа с ценами.

(24) "Загрузка однократная, далее корректировка загруженного" так сколько будет по "Организация, Контрагент, Договор" ? 200? ну и о чем спич?