Добрый день.
Стал смотреть размеры таблиц 1cv7 базы, которая работает уже 15+ лет. Есть регистр остатков ПродажиБух RGxxxx, в котором может быть хоть 9, хоть 90 одинаковых записей, но с разным значением PERIOD. Разумно ли удалить все дубликаты кроме последнего актуального периода изложенным ниже образом? Будет ли корректно работать 1cv7?

delete T from
(select Row_Number() Over(Partition By SP6604,SP6592,SP6593,SP6594,SP6614,SP6595,SP6596,SP6616,SP6605,SP6617 order by PERIOD desc ) As RowNumber, * From rg5555_2) T Where T.RowNumber > 1
за 44 сек из 3.5 млн строк скопированной табл осталось всего 80 тыс

И, если буду чистить _1SJOURN до 2020, можно ли удалять все записи из таких регистров с PERIOD<'2020-01-01' ? Таких 20 тыс из оставшихся 80 тыс. На фоне оптимизации 3500->80 в принципе роли не играет, но мне для понимания бизнес-логики 1cv7. Я в ней не особо разбираюсь

Описание регистров в DDS конфиге:

T=RG5555  |Регистр ПродажиБух            |RG5555     |          
#-----Fields-------
# Name                  |Descr               |Type|Length|Precision
F=PERIOD                |Period Registr      |D   |0     |0        
F=SP6604                |(P)Фирма            |C   |9     |0        
F=SP6592                |(P)Номенклатура     |C   |9     |0        
F=SP6593                |(P)Статус           |C   |9     |0        
F=SP6594                |(P)Документ         |C   |13    |0        
F=SP6614                |(P)Партия           |C   |9     |0        
F=SP6595                |(P)Количество       |N   |11    |3        
F=SP6596                |(P)Стоимость        |N   |18    |2        
F=SP6616                |(P)СтоимостьБезНДС  |N   |18    |2        
F=SP6605                |(P)ПродСтоимость    |N   |17    |2        
F=SP6617                |(P)ПродСтоимостьБезН|N   |18    |2  

T=RA5555  |Регистр (Дв.) ПродажиБух      |RA5555     |          
#-----Fields-------
# Name                  |Descr               |Type|Length|Precision
F=IDDOC                 |ID Document's       |C   |9     |0        
F=LINENO_               |LineNo              |S   |0     |0        
F=ACTNO                 |Action No           |I   |0     |0        
F=DEBKRED               |Flag Debet/Kredit   |L   |0     |0        
F=SP6604                |(P)Фирма            |C   |9     |0        
F=SP6592                |(P)Номенклатура     |C   |9     |0        
F=SP6593                |(P)Статус           |C   |9     |0        
F=SP6594                |(P)Документ         |C   |13    |0        
F=SP6614                |(P)Партия           |C   |9     |0        
F=SP6595                |(P)Количество       |N   |11    |3        
F=SP6596                |(P)Стоимость        |N   |18    |2        
F=SP6616                |(P)СтоимостьБезНДС  |N   |18    |2        
F=SP6605                |(P)ПродСтоимость    |N   |17    |2        
F=SP6617                |(P)ПродСтоимостьБезН|N   |18    |2        
F=SP6606                |(P)КодОперации      |C   |9     |0        
F=SP6609                |(P)СтатусДвижения   |C   |9     |0

(0) А свернуть базу не вариант?

Остатки полетят к хyям. Надо сворачивать.

Текущие остатки слетят или 3 летней давности (наверное они не важны)? Может есть вариант посчитать актуальные остатки?

Где-то давным давно я видел встроенный функционал сверток, но сейчас не могу найти. Или это платная внешняя обработка? Я тогда вместо свертки просто чистил _1sjourn и _1scrdoc от старых документов и вычищал эти iddoc в DH% таблицах. Сейчас понял, что еще куча старого мусора осталась в RG%, RA% и _1SCONST.

(0): Не разумно (если конечно интересует корректность работы 1с).
Не будет (точнее - если и будет то далеко не всегда).
Нельзя (если конечно интересует корректность работы 1с).
Ну и вообще, с учетом того, что (судя по всему) речь о клиент-серверном варианте (ms sql).

1) з.а.ч.е.м.??? (учитывая тот факт, что именно скл-версия обеспечисает стабильность и независимостьб скорости работы от объемов данных)

2) "позовите специалиста" (с) - пусть свернет вам базу грамотно раз уж припекло.

ну и вообще: "работает - не трогай!" (с)

(0)а какая цель у задуманного деяния?
И какой смысл у остаточного регистра "ПродажиБух"?
(3) "позовите специалиста"©

Спасибо за комментарии! Спеца позовем. "работает - не трогай" - правильный подход, поэтому проясняю все заранее.

Зачем? Чтобы уменьшить объем ежедневной выгрузки (бекап), длительнось самого РК и длительность потенциального восстановления. И есть подозрение, что работа SQL с таблицей из 80k строк капельку быстрее чем с 3500к строк, тем более что эти строки по сути избыточны либо orphan.

(6): Это решается правильным выбором модели бэкапа и ее настройкой, а также грамотной разработкой регламента резервного копирования.
Ваше подозрение (особенно в обсуждаемом контексте) беспочвенно. и безграмотно.
Нет, эти строки (упоминаемые в (0)) - НЕ "избыточны" (опять таки - если интересует корректность работы 1с)
Ещё раз. По слогам. П.о.з.о.в.и.т.е. с.п.е.ц.и.а.л.и.с.т.а! (с)

(3) я ТиС семерку чистил таким образом. Сохранял все нужные остатки на начало периода, с которого планировалось вести чистую базу. Подготавливал новую чистую базу со справочниками, но без документов и регистров (это сделать довольно просто). Заводил сохраненные ранее остатки путем разных документов ввода остатков. При необходимости перекидывал также некоторый массив документов по вкусу и проводил их, чтобы работа была не с полного "нуля", в частности, заказы покупателей - понятное дело, если делать так, нужно остатки перекинуть тоже соответствующим образом, чтобы они "достроилсь" проведением буферных документов. И все. Люди работали в чистой базе, при необходимости "посмотреть" - заходили в старую. Через какое-то время старая становилась не нужна.

"Сохранять все нужные остатки на начало периода" - это нужно 1с код писать или SQL запрос?

По изначальному вопросу. Лазил по таблицам RG%, RA%, в конфиг DDS смотрел, искал по конфигурации (поиск во всех текстах) - так и не понял, где применяются поля PERIOD регистров. Поэтому и спросил здесь.

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

(6) "объем" нынче дешев (дешевле работы человека), длительность восстановления решается выбором модели и планов, "подозрения на скорость работы" беспочвенны, ибо происходят от безграмотности.
(7) Ну, "избыточны" или нет - зависит от того, делают они отчеты за задний период, или нет.
(9)
1. хошь кодом, хошь запросом. можно и так и сяк, лишь бы соотношение радиусов было хорошее.
2. в конфигурации этого, естественно, нет.
3. тогда зови спеца "свернуть/обрезать базу" - это будет и дешевле, и проще - ибо аналитика за 15 лет "малому бизнесу" нафиг не нужна, да и оптимизация тоже.
(3) свои обработки по обрезке даже искать не буду, ибо они для вас - "заготовки", а для допиливания нужны знания. а давать обезьянам гранату - не в моих принципах.

Спасибо.

Последний вопрос: Если за отчетами/остатками за задние периоды готовы ходить в архивную базу, можно усекать регистры по PERIOD до самого последнего?

Ради интереса проверил Остатки ТМЦ за 30.12.2022 между оригиналом и усеченной копией - сошлись. А за 30.12.2021 не сошлись

(11)
1.тогда нужно не "усекать регистры", а просто "обрезать базу".
2. "остатки за" - само по себе забавно. примерно как "военная мысль".

(10) не так уж они и беспочвенны, особенно на семерке и особенно если она работает на штатных запросах, а не переписана вхлам.

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

(9) > "Сохранять все нужные остатки на начало периода" - это нужно 1с код писать или SQL запрос?

я на 1С обработку делал, которая собирала все, что нужно, в XML-файлики в старой базе и создавала требуемые документы в новой.

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

(9)Вы почитайте про процедуру свертки, на эту тему масса материалов. Посмотрите типовые конфигурации (ТИС, Бухгалтерия). В них есть штатные обработки свертки. Основной недостаток штатных обработок - низкая скорость удаления документов до даты свертки. В нетиповых конфигурациях бывает масса своих нюансов

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

Добился чтоб остатки (отчет/ведомость по остаткам ТМЦ, Контрагентам, Кассе) совпадали в оригинале и усеченной копии, если выбирать интервалы в пределах 2022.
mdf уменьшился 3.8->1.4 ГБ. Время РК уменьшилось вдвое, размер РК втрое. Ускорится или нет обычная работа будет видно после праздников.


DECLARE @TRUNCATEDATE VARCHAR(10) = '20211201'
DECLARE @TABNAME VARCHAR(100)
DECLARE @SQL NVARCHAR(300)
DECLARE CUR1 CURSOR FOR
  SELECT table_name
  FROM   information_schema.tables
  WHERE  table_name like 'RG%'
OPEN CUR1
FETCH NEXT FROM CUR1 INTO @TABNAME
WHILE @@FETCH_STATUS = 0
  BEGIN
DECLARE @COLS VARCHAR(300) = NULL
SELECT @COLS= COALESCE(@COLS + ',', '') + c.column_name FROM INFORMATION_SCHEMA.COLUMNS c WHERE TABLE_NAME = @TABNAME AND column_name!='PERIOD'
      SET @SQL = 'DELETE T FROM (SELECT Row_Number() Over(Partition By ' + @COLS + ' ORDER BY period DESC ) AS RowNumber, * From ' + @TABNAME + ') T WHERE T.RowNumber > 1 AND PERIOD<cast(' + @TRUNCATEDATE + ' as varchar)'
      PRINT @SQL
      EXEC Sp_executesql
        @SQL
      FETCH NEXT FROM CUR1 INTO @TABNAME
  END
CLOSE CUR1
DEALLOCATE CUR1

DECLARE @TRUNCATEDATE VARCHAR(10) = '20200101'
UPDATE _1sjourn SET ismark=1,closed=4 WHERE date_time_iddoc<@TRUNCATEDATE
DECLARE @TABNAME VARCHAR(100)
DECLARE @SQL NVARCHAR(300)
DECLARE CUR1 CURSOR FOR
  SELECT table_name
  FROM   information_schema.tables
  WHERE  table_name like 'RA%' OR table_name like 'DH%' OR table_name like 'DT%'
OPEN CUR1
FETCH NEXT FROM CUR1 INTO @TABNAME
WHILE @@FETCH_STATUS = 0
  BEGIN
      SET @SQL = 'DELETE FROM d FROM ' + @TABNAME + ' d INNER JOIN _1sjourn j ON d.iddoc=j.iddoc AND j.ismark=1 WHERE j.date_time_iddoc<cast(' + @TRUNCATEDATE + ' as varchar)'
      PRINT @SQL
      EXEC Sp_executesql
        @SQL
      FETCH NEXT FROM CUR1 INTO @TABNAME
  END
CLOSE CUR1
DEALLOCATE CUR1
DELETE FROM _1scrdoc WHERE child_date_time_iddoc<@TRUNCATEDATE
DELETE FROM _1sjourn WHERE ismark=1 AND closed=4 AND date_time_iddoc<@TRUNCATEDATE

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

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

(20) ну я вниматочно® его запрос не читал.  Вполне допускаю, что если юзвери не полезут в большой зад, то никто ничего и не заметит, и обойдется без пистонов.
Но, блин, тратить время из-за 4Г. Причем оно еще и бесполезно.

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

(22) ну, у меня "в клюшечные времена" регулярно (ежемесячно) подрезалась база (до 3 лет+1 месяц) именно запросами, причем именно прямыми - чтоб не останавливать работу 24/7. Так что "ничего невозможного нет"©.

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

(24) записи в RG на -37 месяц - они сами по себе начальные остатки, этого достаточно. Но для корректного отображения был один документ, к которому привязывались формируемые запросом движения за -37 месяцем. Т.е. я по сути "раскладывал остаток в движения", и привязывал их к пустому служебному  документу.
Но если не лазить отчетами за -36 месяц, достаточно записей в RG.

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

Я вообще ничего не понял, развели здесь игру престолов. Внедряешь документ типа "универсальный двигатель регистров". В него считываются остатки на дату документа. Записываешь. Удаляешь все доки (пометкой) до этого документа (со сдвигом та на начало базы). Проводишь документ-двигатель. Удаляешь все доки помеченный доки. Сдвигаешь та на сейчас. Всë.

(27): Ха! Штатно - не кошерно!
Надо скл-запросом в "кишках" (да и для самооценки пользительно)

(26)
1. Ну я ж сказал, что "раскатывал итоги в движения". Т.е. пересчет прошел бы нормально. Только ждать его задолбались бы.
2. Хотя я там был практически единственным клюшечником (постепенно переползали на снеговика), тем не менее "после меня" база успешно проработала еще почти 2 года.
3. база была большенькая, порядка 160, работа 24/7, даунтайм допускался час в неделю, по факту был чеверть часа в месяц. делать на ней "реструктуризацию с пересчетом итогов" или  манипуляции, описываемые Злопом - было не комильфо.

(27)Пришел, увидел, победил
Внедрить универсальный документ, но его надо где-то взять
В него считываются все остатки - кем считываются? Предположу, что обработкой свертки, которую тоже надо где то взять
Не приходило в голову, что автор ни разу не 1С-ник ? Он умеет запросы писать. И они реально помогут в реальной свертке, в сотни раз быстрее пометить на удаление, чем со сдвигои ТА на начало базы

(28)Нет ничего плохого в "нештатно". Просто делать надо грамотно. Чтобы, например, простая выгрузка-загрузка базы не приводила к обрушению результата

Как минимум (бывает и сложнее)
1 - должны быть созданы документы начальных остатков регистров и бухитогов на дату свертки (конец дня сворачиваемого периода).
2 - помечены на удаление все документы сворачиваемого периода, кроме документов начальных остаткоа
3 - удалены все документы сворачиваемого периода, на которые нет ссылок в оставляемом периоде
Вот грубая схема, а как делать каждый этап, это уже нюансы. Запросы, сдвиги ТА и тд
Ну потом еще по желанию всякие выгрузки-закгрузки, пересчеты итогов, упаковка

Описание структуры хранения данных в 1С 7.7:  http://www.script-coding.com/v77tables.html

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

(30) Да "универсальный документ" валялся на всех помойках, от инфостарта до проклаба. Просто о нем надо еще и знать.
(31) 3.ну там ссылки еще в CRDoc и периодике. Ну это уже нюансы, конечно.

(32) Смысл онлайн-сжатия при md в 4Г ?

(30) в "универсальном двигателе регистров" всë уже есть. И заполнение остатками (я ещё и фильтры простые по измерениям прикрутил шоб було, например,если надо по одной фирме свернуть), авто разбиение документа на части и прочее. Имхо у любого оставшегося в живых клюшечника подобный документ есть (это вам не восьмерочники-гаокорасстааляиели).
.
Тут конечно ещё посмотреть перед сверткой надо - может там регистры всё кривыеинапрочь и свертка/обрезка не особо поможет.
.
Смо реть придётся глазками через универсальный отчёт по регистрам (штатно типовой с итс) или тупо выгрузкой остатков в таблицу https://infostart.ru/public/14794/

(35) гаокорасстааляиели
а я расшифровал этот йцукен )

Можете пояснить?

В итоге остатки действительно разъехались, но очень хитро. Отчеты в почищенной базе показывали все ок (я их проверял и поначалу обрадовался). НО если БД выгрузить и загрузить снова - в отчете ТМЦ красные минуса.

Для чистки применял запросы (18). Разъехалось из-за свертки RG* по идентичным полям или (скорее всего?) из-за чистки RA* по старым документам?

При выгрузке/загрузке заново пересчитываются регистры.
Если лезет кривая краснота - значит порезал криво.
Бери по проблемному регистру ведомость движений в детализацией по всем измерениям и смотри.
Возможно полечить удастся малой кровью.
А что именно разъехалось/криво - нам отсюда не видно...

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

Я просто принципиально не понимаю, почему удаление сказалось на пересчете итогов. Мой запрос удалял в реестрах строки, у которых period<'2019-12-01' и все остальные поля идентичны(!), КРОМЕ(!) самой актуальной. Тем не менее в отчете остатков краснеют некоторые строки даже если запрашивать за последний месяц (2023) и не лезть глубже 2022. Может надо было оставлять не одну, а как минимум 2 идентичных строки регистра: с минимальным и максимальным period или последний и предпоследний..?

(39) мы не знаем вашей схемы учета, поэтому что либо отвечать по частностям - бессмысленно.
В общем - писал выше - порезали криво.
.
также написал, но ты, видимо на это забил. Сделай ведомость движения по проблемному регистру где у тебя краснота с детализацией по всем измерениям и с группировокой по всем измерениям (пример такого отчета - типовая ТиС "Ведомость по остаткам ТМЦ"). Будет сразу видно откуда у тебя идет краснота. Тогда же возможно можно будет понять и причину красноты, где что не учел при порезке.

Еще 1 глупый вопрос. Когда разлил новую БД из бекапа и 1й раз ее открываешь, вылезает окно "открыть период?". Если согласиться, какое-то время идет "перенос остатков на ..." (какую-то дату, отображается в статусной строке внизу). Результат моего кривого усечения и последующей выгрузки+загрузки зависит от нажатия на "открыть период" или не зависит?

(41) ну кто ж знает, что ты там "наусекал"
Но вообще, если ты не трогал итоги последних периодов, то не зависит.
Еще раз повторю: сделать можно всё, что угодно, несколькими способами.
Но чтобы что-то правильно сделать - нужно хорошо представлять себе то, что ты хочешь сделать.

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

(0) Делам на копии базы. Удаляем все файлы RG*. Заходим в программу монопольно. Управление итогами - ТА на самое начало. Далее ТА на сегодня, документы не перепроводить. Ждём, смотрим на результат. Если результат нравится - проводим операцию на рабочей базе.

(44) эммммм... и чего вы хотите достичь этими действиями?

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

(45) "пересчет итогов"

(44) управление бух итогами было не доступно даже в монопольном режиме, даже для роли Админ_1с. Попробовал трюк с оперативными итогами - не проканало, краснота не ушла. Копия базы была на 13/01, на нее во 2й раз и ставил ТА. Когда ставил ТА на начало (не по усеченке 1 дек 2019, а решил на начало года 1 янв 2020), документы перепроводить не предложила. Наверное это норм..?

(48) то есть настойчиво игнорируем, млин, рекомендацию посмотреть откуда рождается краснота простейшим отчетом "ведомость движения остатков"...? или я непонятно изьясняюсь - и все что непонятное - ну его нахрен....
.
если в базе движения дают типа  0+2-3=-1 - краснота в виде -1 никогда не уйдет, сколько бы ты итоги не пересчитывал и базу выгружал/загружал...

(48) ну если ты ТА сдвигал назад - то ничего перепроводится не будет.
а вперед ТА можно двигать по разному - с перепроведением документов (переформировываюьмя движения и пересчитываются итоги на основе движений) и без (доки не перепроводятся и тупо только итоги пересчитываются по существующим движенимя)

Не(!) перепроводи - иначе получишь тормоза, ошибки проведения и изменение движений(!).

До-удалялся ты, дружище. Хотя тебе советовали настоятельно - но не в коня корм.

Выпиливание "лишних" записей из RG* (остатки по-периодно) в принципе ничего не испортили (если выпилил только "старые") - потому что итоги все равно пере-рассчитываются (при двигании ТА совсемназад-вперед, или ТИИ с галкой "расчет итогов") по движениям RA*.

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

На текущий момент - диагноз прост и многократно повторен: ты криво порезал движения.

А также на текущий момент и рецепт многократно повторен: розовите специалиста (с).

Удач.

* позовите

(37) НО если БД выгрузить и загрузить снова - в отчете ТМЦ красные минуса.
А чего тут пояснять, итоги пересчитались.
В семерочном регистре есть таблица движений и таблица итогов. Итоги рассчитываются по движениям, но не постоянно, а время от времени.
Вы движения грохнули и ничем их не заменили, то есть тех записей, которые составляли итог, теперь нет.
Пока итоги не пересчитаны, все типа хорошо.
Пересчитали - получили кашу.

(53) "Итоги рассчитываются по движениям, но не постоянно, а время от времени." - эта пять!

(44) (47)
а в (18) вы не заметили этого:
DECLARE CUR1 CURSOR FOR
  SELECT table_name
  FROM   information_schema.tables
  WHERE  table_name like 'RA%' OR table_name like 'DH%' OR table_name like 'DT%'
OPEN CUR1
FETCH NEXT FROM CUR1 INTO @TABNAME
WHILE @@FETCH_STATUS = 0
  BEGIN
      SET @SQL = 'DELETE FROM d FROM ' + @TABNAME + ' d INNER JOIN _1sjourn j ON d.iddoc=j.iddoc AND j.ismark=1 WHERE j.date_time_iddoc<cast(' + @TRUNCATEDATE + ' as varchar)'

????
ну какой нахрен "пересчет итогов", если оно по*ерило и движения, и документы?

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

(49) Уважаемый Злоп, я не понимаю, как делать "ведомость движения по проблемному регистру" ( В винде, скуле немного соображаю, но 1с не мое.

(55) Могу из копии доналить удаленные строки и усечь по другому

(57) вам именно об этом и говорят - найдите того, кто "соображает".
(55) "доналейте", покормите собак, и больше руками ничего не трогайте®.

(0) Не надо лезть в таблицы напрямую. Надо аккуратно подрезать базу данных средствами 1С. Иногда сразу не получится обрезать, скажем, год, приходится резать кусками, помесячно. Долго, но легально и без ошибок.

+ (59) если регистр оборотный, то после обрезки он сократится сам собой.

(59) надо просто понимать, что делаешь. а "напрямую" или "средствами 1с" - это уже вторично.  Главное - это правильное отношение радиусов.
(60) а если остаточный - то удлиннится, чтоль? Открою вам страшную тайну: той таЙинственной "дупликации остатков", с которой боролся ТС, у оборотного регистра просто нет.

(62) Оно и понятно. Продажи одного и того же товара, в разные месяцы - и опа, пошли дубли! :)))))))

(62) -> (61)

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

(57) стукайся в скайп Zlop
Но предметно

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

"регистр остатков ПродажиБух"
- запросто может иметь 99% "мусора". Ибо продажи - обычно это ОБОРОТНЫЙ регистр, а не регистр остатков который заявлен у ТС