Всем привет!
Для некоторых задач требуется перенести все продажи всех товаров за всё время из одной базы в другую. Это нужно для определенной статистики.
Не нужно никаких документов, чисто информацию по дате продажи, какой товар, кол-во, сумма, себестоимость на дату продажи.
Будет требоваться получить себестоимость на определенную дату, а также продажи товара за период.
Планирую перенести всё это в один регистр, но вот не знаю, какой лучше выбрать.
Строк в регистре будет около 200 тысяч (столько примерно продаж было).
Мне было бы проще использовать регистр сведений. Сделать его периодическим и на любую дату можем получить себестоимость товара. Но вот справится ли он с задачей получения продаж за период? Т.е. насколько быстро он выберет продажи конкретного товара за определенный интервал. Ведь он не предназначен для получения оборотов, и придется делать запрос с условием "Период МЕЖДУ Дата1 и Дата2" и последующей группировкой. Не будет ли слишком больших тормозов при таких объемах? (Регистр увеличиваться не будет со временем, т.е. всегда будут эти 200 тысяч строк).
Если делать регистр оборотов, то во-первых проблемно получить себестоимость на дату, а во-вторых придется делать документы, хранящие эти 200 тыщ строк. Это вобщем-то ни к чему.
Два регистра делать не хочется, т.к. себестоимость нужна на каждую продажу и получится два регистра по 200 тыщ строк.

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

Почему РС?

"Себестоимости на дату" не существует в природе.

А по задаче - не нужно хрень всякую придумывать. Это оборотный регистр.

(2) смотря какой метод оценки, бро! у меня благодаря хотелкам от бухов - есть :)

А база то файловая или нет?

рс

(4) Бухи приняли новое ПБУ?

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

(8) Это средняя за период. А никак не "на каждый день".

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

(10) "На начало" здесь только один из элементов формулы. В полном виде таки за период.

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

(11) ну так она на каждую дату своя, вот и получается "на дату"

(0) + в сторону РС.

(12) На каждый документ или на каждую дату? Если в середине дня у Вас новый приход меняет себестоимость, то с этим Вы что делаете?

(14) на дату

(0) Из соображений симметрии сделай справочник "Продажи".

(16) Лучше в регистр расчета, стоподово

(0)При таком подходе только блокнотик и бумажные копии... в 3-х экземплярах. А если всерьез то, только регистр накопления.

(17) Точно! И каждый отчет - запись в нем, а продажи - база :)

(19) Типа того :)

при подключении флешки она будет не диском а папкой на диске. Это точно можно сделать начиная с ХР , у меня такое было. Посмотрите в инете , сейчас уже не помню как. Работало почти 2 года. Причем монтировалась так только какая одна флешка, остальные как диск.

сорри не туда

(3) Себестоимость на дату уже есть.В той программе, откуда это будет перекачиваться, уже есть табличка продаж и себестоимость при каждой продаже.
(5) База файловая, но это пока.
(16) Что за симметрия? По справочнику выборка дат ещё дольше будет идти наверное
(18) "только регистр накопления" - почему?

Поясню: бухов никаких нет. Программа чисто торговая, бухгалтерия ведется в отдельной 1С бухгалтерии. В этой торговой программе при продаже товара нужно знать, по какой партии списание и цену этой партии. Это и есть себестоимость, т.е. цена закупки товара. По каждой продаже видно цену закупки и цену продажи.
Табличка, которую нужно перенести, имеет все эти данные. Их нужно одноразово перенести, потом использовать какое-то время в паре обработок, после чего вообще удалить этот регистр. Т.е. данные нужны будут может быть в течении года, потом надо удалить. Я поэтому и хотел регистр сведений, с ним проще в этом плане, не надо регистраторов. Данные вноситься в него не будут, как загрузятся, так и останутся до решения о их удалении.
В чем тут минус регистра сведений? Такой объем данных не потянет? Выборка по датам будет очень долго идти?

(23) Если реквизит Дата будет индексированным - все нормально будет. А соображение симметрии такое: если не можешь решить РН или РС - то надо использовать что-то другое. Опять же, нет никаких проблем создать регистр, заполнить его записями и провести натурные испытания.

(23)Это исходит из постановки задания. "Так учит партия"©
Мне не понятно, чем использование регистров накопления сложнее регистров сведений.

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

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

(26) Итоги можно добавить и в РС - просто сформировать записи с признаком Итоговая ;)

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

(29) Зачем? Данные же меняться не будут. Впрочем - пишется без проблем в модуле набора записей.

(24) "Если реквизит Дата будет индексированным - все нормально будет."
Да, я вообще думал периодический регистр сделать, и период и будет той датой продажи. По периоду регистра наверное быстрее всё будет делаться
(25) "Мне не понятно, чем использование регистров накопления сложнее регистров сведений".
В конфигурацию придется добавлять ещё документ-регистратор, который вобщем-то не нужен, делать его проведение.  Причем в программе одним документом не обойтись, т.к. строк очень много. В итоге будем иметь документы с общим кол-вом строк 200 тысяч, и регистр, дублирующий эти строки, с кол-вом записей 200 тысяч.
Можно конечно сделать фиктивный документ, без табличной части, и обработкой запихать ему движения. Но мало ли кто его отменит, распроведет, в общем лишние заморочки.
Ну и во-вторых, как я уже писал, из оборотного регистра проблемно вытащить цену закупки, по которой прошло списание.

С учетом того, что явление это вообще временное, и в будущем будет всё удалено, хотелось бы обойтись малой кровью, пусть и в ущерб скорости. Люди потерпят, если обработка вместо 10 секунд будет "думать" 1 минуту. Но если регистр сведений с 200 тысячами записей будет на полчаса зависать, то конечно не вариант.
Но тут наверное надо в самом деле пробовать.

(31)Если задача временная и используется "в паре обработок", то помести таблицы в макеты этих обработок. Тогда вообще обойдешься без регистров.

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

(32) Ну как вариант. Правда в макете будет 200 тысяч записей, прикольно. И при открытии обработки придется всегда эти записи в ТЗ помещать, и потом с ТЗ работать.
В общем с регистром удобнее, его почистим потом и всё.
(33) Ок, понял.
Попробую РС, а там посмотрим что получится.