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

А просто свернуть - не вариант?

Не

глупо.

глупо что?

(4) что не вариант.

(4) Глупо резать старые периоды. Скорости это сильно не добавит (если конечно вы не на файловой сидите расшаренной по сети)

(0) Добавлю к (5) и (6). Если база серверная, то ее резание не принесет повышение скорости работы. Максимум в чем выиграете - время обслуживание базы (создание бэкапов и т.д.).
Если база файловая, то чем свертка отличается от переноса остатков?
Делаем копию базы. Ее сворачиваем. Получаем тоже самое что если б делали перенос в пустую базу.

"если конечно вы не на файловой сидите расшаренной по сети"
На файловой в терминале.
База более 5 Гб.

"Получаем тоже самое что если б делали перенос в пустую базу."
Э-э-э... не совсем
В базе 55000 помеченных на удаление объектов. Удаляется только 4000. После свертки помеченных объектов становится более 130000, удаляется только небольшая часть. Есть сильное желание избавиться от всего этого.

Есть подозрение, что свёртка неправильная.
Или в базе учёт ведётся через то место... Ну в общем, известное всем место

(9) тогда получается, что была старая база на 2.0, у вас ее конвертнули в 3.0, теперь собрались удалить мусор и не получается... надо удалять мусор. Перенос остатков готовый отсутствует. Ну разве что в КД сделать какие-то свои правила.

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

(11) за такие советы обычно бьют. Молотком. По пальцам.

(12) Ну а что им еще советовать, если они сначала перепрыгнули в новую конфигу, без наведения порядка в прежнем/старом формате, а теперь начинают выеживаться???

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

"тогда получается, что была старая база на 2.0, у вас ее конвертнули в 3.0"
С чего Вы взяли? Была 7.7, с нее перешли на 8 ред. 3.0.

Ставь мини сервер 1С. Дешевле обойдётся.

(11) Очень простой и действенный способ который поможет прикончить базу ТС. Под таким советом надо писать большими буквами НЕ ПОВТОРЯТЬ! ОПАСНО ДЛЯ ЖИЗНИ!!!

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

"то так и пишите"
Так и пишу: ежели по сути вопроса сказать нечего - лучше не тратить свое драгоценное время на сотрясание клавиатуры.

(18) ты бы в топике клавиатуру сотрясал, при постановке вопроса.... ценитель драгоценного времени...

Кроме совета в 11 тебе что-то конкретно посоветовали уже?
Ну да, в (13) есть совет через КД перетащить и кто еще по сути высказался?

"при постановке вопроса"
При постановке вопроса все сформулировано предельно кратко и понятно. Тех, кто в танке прошу не беспокоиться.

(20) По сути вопроса:
Если при удалении помеченных объектов после свертки базы часть документов не удаляется, значит на них есть ссылки.
И высока вероятность, что все эти объекты по ссылкам уедут в новую базу, которая будет отличаться от старой только на те 4000 документов, которые можно было удалить и в старой...

Элементарно - сверни базу и выгрузкой-загрузкой XML перенеси проводки (документы ввода остатков)

Только учти, что БП не любит свертки по ОС и документам расчета с контрагентами

(22) Остатки не будут ссылаться на старые документы, которые делали проводки по регистрам?

(24) если документы сидят в значениях субконто, то естественно будут

Т.е. 95% гомна перетащится. Я правильно понимаю?

(26) У этого "гомна" не будет движений, в отличие от таковых в текущей базе

Если же надо, чтоб "гомна" и вовсе не было, то тут либо умную свертку, где каждый вид "гомна" надо конвертировать ("сажать") на некий агрегатор / агрегаторы, либо вводить остатки с "гомном" вручную

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

(28) А ты видел когда нибудь такую умную свертку?

(30) не видел, сам делал при переносе остатков товаров и взаиморасчетов ("сажал" партии на один документ и взаиморасчеты на один "документ расчетов с контрагентом")

(31) Ясно. Эксклюзивчик однако.

(30) а чего там видеть? там садиться и делать надо

(33) делать обработку умной свертки?

(34) ага

(35) Странно, и что же за последние 5 лет никто не додумался до столь гениального решения проблемы.

(9) А анализ делался - почему не удаляются объекты? Может при переносе их опять придется тянуть в новую базу.

(36) еще раз, для тех кто в танке... см. (33) тут додумываться не надо, надо садиться и делать. Провести анализ базы, что, откуда, почему и зачем. Определить что из этого надо в новой базе, как и зачем. Написать свою свертку (через КД и еще 100500 способов), свернуть.

Плюсы: ты точно знаешь что ты делаешь, ты получаешь тот результат, который хотел.
Минусы: долго, дорого.

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

(39) Кэп, конечно подумать стоит, и я об этом в (38) написал

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

Зачем КД? Сворачиваем, переносим документы ввода остатков обработкой ВыгрузкаЗагрузкаДанныхXML83.epf она за собой тянет нужные справочники.

(0) Расширте железо. Скуль . Продолжайте работать .

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