Нужны рекомендации по обрезанию нескольких лет в УПП #768025

Добрый день. Работаем в 8.3 УПП 1.3 клиент-серверный вариант База ведётся с 2006-го года, dt-ник - всего 26 Гб. Но поставлена задача срезать 5-8 лет. Подскажите, как корректно это сделать, где почитать? Спасибо.

Рекомендация по вводу начальных остатков на ИТС.

Для чего клиент-серверному варианту dt?

зачем?

Типовая обработка свертки базы с ИТС. Пробовал обрезать базу СКЛ-ем.. но пришёл к типовой обработке...

Сейчас одна база или есть подчиненные узлы РИБ ?

Взбрело в голову генеральному Всё время наталкиваюсь на отзывы, что она нерабочая Одна

26 Г это ничего. Зря потратите время и силы начинайте думать когда будет 126

спроси какой результат хочет генеральный ? если уменьшить размер , то это одно, если обрезать то это уже другое

Рекомендация №1: не обрезать три предыдущих года.

не спасёт, кроме зарплаты есть ОС

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

вот тоже не думал её использовать. А оказалось - норм.

Не в размере дело. Именно убрать старьё. Запрет редактирования работает. Никто старые периоды не трогает. Сделали обработкой с ИТС? Какой период обрезали?

DTшник 26 - это много. Это приличная база должна быть, гигов 200, думаю, есть.

Старье убить не получится без замены старья на "агрегаторов", ибо все оно (документы) сидит в субконто или измерениях регистров

что тогда в тех периодах убирать? Если запретом редактирования они никак не меняются? Да, по умолчанию наверное нет такой функции, как ограничивать просмотр по дате. Но это можно сделать. Это будет проще, чем обрезать базу. Тут важно знать мотивацию, чем старье директору мешает. Может быть там много всяких глупостей и просто излишеств? Если все равно как далеть и все равно зачем резать, то пробуйте в тестовой копии резать как попало - авось получится так, как нужно.

пробовал, результат мне не понравился совершенно. У вас реализаций много? Если много, то практического смысла никакого - потому что там не рекомендовано трогать НДС, а она в этом случае оставляет вообще всю реализацию. В результате у меня выгадать получилось гига три.

5 гигов dt развернулось у меня когда-то в 160-гиговую базу

ну вот и я говорю - 26 DT это очень прилично должно быть

а после ввода остатков проводить 3 года?

зачем?

Переходите на ЕРП 2.1 Во-первых, там это все реализовано !!! Во-вторых, по трудозатратам сопоставимо. Начнете новую базу и будете копить очередные 26 гигабайт.

[Во-вторых, по трудозатратам сопоставимо. ] брехня

эммм... а в партиях за эти 3 года что будет?

предлагаете лечить запор с помощью динамитной шашки?

светка в ерп реализована?

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

:) и катька тоже

списываться откуда будет в самом начале периода после свертки?

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

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

Помню подводный камень. 1.У нас велась информация по размеру и сроку просроченной дебеторской задолженности. После среза долг был записан как входящий остаток на одну дату и исчезла инфа о сроке, пришлось допиливать. 2. надо выключать расчет итогов по всем регистрам, после срезания сделать полный пересчет

Пофиксил