Добрый день! База клиент-серверная, 100 Гигов. ГБ не удовлетворяет то, что при некоторых перерасчетах сбиваются показатели в отчетах. Ну, грубо говоря, восстановили последовательность, провели по партиям, рассчитали себестоимость - сбилось. Вот и призадумались наши, а ну эти прошлые периоды. Прошлые оставить для справки в другой базе, а потом еще каждый год туда доливать по окончании. Спросили меня, сказал - можно, но не нужно. Не подействовало. База сильно допилена франчем, сервер работает впритык - загруженность ОП 90 процентов, я боюсь, что даже чисто технически он загнется при свертке. Посоветуйте!

(13) Да дело не в жирности, размер их мало волнует.
(14) (11) Не знаю проще ли переносом.

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

Также вероятны варианты того, что остатки в принципе кривые и, например, на складе числятся партии товаров 5-ти, 6-ти летней давности, которые тоже либо будут свернуты, либо останутся, но зачем тогда такая свертка, если половина данных будет на месте?

(0)  сворачивал как то пере писанную десятилетнюю ут 10.3, 150 гиг

Типовым триммингогом от 1с дней 18 на тестовом  серваке заняло. Пришлось часть процедур на скуль переписать . Итого три дня.

(17) УТ, не УПП))
(16) "И получаешь неработающие отчеты, которые ориентировались на дату регистратора, или незакрывающиеся авансы по НДС, которые висят уже три года, а платежка внезапно была "свернута" во ввод начальных остатков. "
Вот что-то типа этого мне и надо им предоставить.
Плюс наш админ думает, что свертка не должна много времени занять, поэтому на долговременность не могу аргументировать их.

(15) Тогда неясно, как свертка спасет от необходимости править прошлые периоды?
(16) Я про технический аспект больше имел в виду. На логику конфигурации - да, смотреть нужно. Теперь, наверное, стало яснее, о чем говорилось ранее...

(19) Согласен, не спасет, думаю придется вникать конкретнее в проблему.

Как правильно делать:
1. Формируешь остатки не проведенные
2. Отключаешь итоги
3. Удаляешь движения до
4. Включаешь итоги
5. Проводишь остатки

Так можно делать по каждому регистру отдельно

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

Для еще большего ускорения можно удалять через скуль

Могу продать такую обработку

(23) Или через Shift+Del )))

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

(15) что там сложного - делаешь базу, содержащую только справочники. ЭТо достаточно просто делается путем TRUNCATE TABLE всего, что не нужно. Потом в нее любым доступным способом затягиваешь начальные остатки.

(27) Те же ос ввести остатками далеко не тривиальная задача.
Там миллиард полей на каждый ос

(15) объясню, почему проще. В первую очередь потому что вы будете сами контролировать процесс и понимать, что у вас в новой базе есть, чего нет, и почему. Ни одна свертка от стороннего разраба вам этого не даст, это всегда черный ящик. Она обмахается на каких-нибудь не совсем верных данных, а вы потом замучаетесь объяснять, что откуда взялось. Только ввод остатков. Это единственный рабочий вариант.

(21) Спасибо
(24) Нашел богача))
(22) Про свертку они не знали, пришли и сказали - хотим чтобы "записи" о том и о том перенеслись на начало периода, а остальное все удалилось. Я им и говорю - это же свертка)

после небольших переделок, типовая свертка упп, работающая трое суток, стала укладываться в 17 часов..

(21) и пипец:
ОС-ам
авансам
НДС с авансов

(27) (29) Спасибо, буду иметь ввиду.

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

(30) я б на твоем месте купил

(32) почему пипец? регистры сведений не трогаем так

(31) типовая это которая basetrimming с диска ИТС? Укладываться-то она укладывается, если ее запускать на сервере. А вы потом смотрели, что получается с тем же НДС? Там каша, реально каша.

Можно не все регистры чисить, а только некоторые. Но тогда нужно в модуле регистра принудительно ставить отказ раньше даты

(5) Может тогда каждый день сворачивать или каждый час?
ИМХО. Если нарушают технологию работы с данными, то никакие технические решения не помогут.

(7) "проблем с ней быть не должно" - ключевое это "не должно",  но будут!

(39) +1. Причем даже с типовой проблем может быть преизрядно, если принять к сведению, что абсолютно "прямого" учета в УПП практически нигде не бывают и всегда в той или иной степени присутствует непонятно что в некоторых регистрах.

а если еще и ЗП в ней ведется... это отдельная песня

(41) Все ведется и ЗП в том числе.

(42) ЗП лучше всего вообще не трогать. В смысле не сворачивать. Благо она взаимодействует со всем остальным достаточно опосредованно.

А ЗП тут причем? ЗП не надо "сворачивать"

(40)[то абсолютно "прямого" учета в УПП практически нигде не бывают]
брехня

(43) Да вы наверное "гений" который умеет "сворачивать" ЗУП?

(44) нет. Но не все знают, что ее трогать не надо. Вот и написал про это.

(17) Зачем удалять данные из такой огромной базы? Я бы создал новую и туда остатки перенес через КД.

(48) уже теплее
но сначала надо восстановить учёты

(49) Не понятно "но сначала надо восстановить учёты" можно объяснить?

(0) Тебе, в принципе, надо им объяснить, что перед сверткой необходимо навести порядок в базе. Конкретный порядок, чтобы копеечка в копеечку сходились и партия в партию.

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

(50) устранить косяки "провели по партиям, рассчитали себестоимость - сбилось"

Поверь по времени это экономичней, чем писать свою свертку

+(51) Пойми, они попросту хотят на тебе выехать, не желая самим решать проблемы кривого учета.

(51) Они начальство - я дурак, я начальство - они дураки, но пока я подчиненный. Скажут надо и все. А проверить все после переноса/свертки пока моих знаний не хватит.

(52) Спасибо.

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

(36) 1с не рекомендует сворачивать регистры ндс.. так в хелпе и написано..

(57) в таком случае как вы будете удалять реализацию? А реализация нередко 90% базы

(58) Зачем удалять реализацию - удаляются только движения

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

я пробовал на 50-гиговой базе не сворачивать НДС и не удалять реализацию - ну и вышло из 50 гигов 30 или 35. Смысл такой свертки?

(0)Не отговаривай. Скажи что для определения времени нужно проведение экспериментов. Либо пусть обращаются во франч. Это будет "дешевле". Ты не отказываешься от работы. Просто говоришь что другие сделают ее дешевле.

(62) Куда уж дешевле, если ТС на окладе сидит в любом случае :)

+(63) А вот "быстрее, но дорого" - то да.

(62) (63) Дело в том, что нет понятия у ГБ проблем переноса, меня убил ее вопрос - а это кто сможет сделать, администратор?
Дело в том, что я принят фикси на производство, исполняю минимальные фунции по доработке внешних отчетов/обработок, консультаций, решению не глобальных проблем. За свои 17 т.р. в месяц я все это делаю, но у меня уговор с франчем, что я не лезу в основную конфигурацию, т.к. за качество работы отвечает он. Меня это вполне устроило и я потихоньку изучаю УПП. Вопрос в том, что чтобы сделать свертку/перенос надо знать все нюансы и тонкости и если я во всем этом разберусь - нафига нам тогда франч. Тут двояко.

(65) А, в твоем случае однозначно делегируй франчу, сам даже не ввязывайся.

(65) даже думать нех, сразу на франч отправляй

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

(6)
// - - -
Меня несколько пугает высказывание авторитетного товарища на форуме, я не буду говорить кого.
"я как то две недели с 50 Гбайтной УПП мудо.хался, пытаясь свернуть типовой обработкой по частям,
оказалось проще уволиться, что и сделал"
// - - -

больной? типовой обработкой насиловать базу, в которой наверняка есть переделки.

Обрезать можно. Но придется действовать осторожно, отсекая лишние данные избирательно. А так же выписывать придется механизмы, чтоб пропавшие в прошлом данные не привели к падениям в настоящем. Делать это можно очень-очень-очень разными способами. Это обсуждение в формате форума будет ни о чем.

(66) (67) (68) Ну это прибавка к опыту с другой стороны и устройство на работу с более высокой оплатой, расти-то надо. (69) Я вот так в принципе и думаю, сделал копию, выбрал несколько регистров, обмозговал на что они влияют, обрезал, посмотрел отчеты - все ровно, все на месте - дальше, если нет - восстановил копию. В принципе это минимальный риск. Проблема в том, что если возьмешься уже не открутишься и нужно идти будет до конца.

(0) Какой-то бред получается.

По версии бухов:
Свёртка нужна для того, чтобы изменение документов прошлых периодов не влияло на показатели.
Но после свёртки документов прошлых периодов не будет существовать в базе данных как таковых вообще.
То есть изменять будет нечего.

Этот момент вообще никого не смущает?...

Какая-то борьба с ветряными мельницами. Свёртка не решает проблему кривизны мозгов пользователя. Вообще никак. И даже ввод начальных остатков вручную не всегда ставит мозги на место.

(48) о, кд.. тут на сцену вышел я с таблицами эксель и обработкой загрузки из табличного документа!!

(0) я думаю ничего там не загнется... смелее!

(70) Если потратишь кучу времени и не справишься (а опыта в таких делах у тебя нет, так что шанс на это большой), впечатление у ГБ о твоей профпригодности упадет ниже плинтуса. Лучше заранее открестись от этого дела, чтобы лицо не потерять. А насчет опыта - посмотри, как это будет делать франч.

(72) Просим, просим, наслышаны))

(75) про консоль запросов забыл))

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

"меня в известность не ставят, а пользователи потом ко мне бегут" // А кого заботит твоя эффективность? Раз никого, то терпи пока не треснешь :)

(78) Терплю)) Работу тяжело найти увольняют толпами.

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

(0) Не выделывайся и сворачивай. Понятно с объяснением как это тяжело и что быстро не получится, но "все сделаю, зуб даю"

(80)[как успешно свернули 300-гиговую базу вусмерть перепиленного УПП какой-то обработкой "из интернета"]
за такой совет могут и жизненноважного органа лишить

(80) "слегка допиленной" - напрягает)
(81) Мнения разделились...

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

(83) Без опыта лучше не соваться. С другой стороны - все с чего-то начинали. В вашем случае результата типовой свертки можете не дождаться. И, ессно, база должна быть на SSD во время свертки.

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

(85) У нас ГБ с полными правами и пофиг ей на периоды.

Консоль запросов+табличный документ+загрузка из табличного документа+универсальная выгрузка загрузка xml+ две недели = чувство выполненного долга и всякие другие плюшки))

(86) Тогда она поправит "начальные остатки" или влезет до них. И смысл от свертки?
Так и скажи: "Давайте представим, что мы сделали свертку. Теперь в базе жесткий запрет трогать документы до 01.01.NNNN!"
И еще попроси премию за экономию денег (предварительно у франча запросите стоимость свертки).

(86) так выдайте мозг еще к полным правам то, а то не взлетит

сворачивал базу 120гб, только не упп а укф, суток хватило на домашнем не самом мощном компе, если вопрос в этом

(86)
Закрой ДЛЯ ВСЕХ в том числе и для Полных прав.
И не делай себе лишнего геморроя.
Размер базы данных и прочая тех информация - это не компетенция главбуха, посылай лесом.

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

Логика, ты где? Приди к ГБ ТС

(92) Это да, но без пинков на фикси тяжело)

(91) "Закрой ДЛЯ ВСЕХ в том числе и для Полных прав. " - а это как?

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

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

(97) Ну пусть тогда франч сделает это, какая разница? Надо исходить от задач.

прикольно.. и так каждый квартал свертку делать? а то вдруг в прошлый период залезут)

(99) Я точно не знаю, у них, допустим, договоренность, что вот эту себестоимость оставляем, потом появляется потребность изменить или внести какую-то поправку в приход, внесли. Они не хотят уже восстанавливать последовательность и пересчитывать себестоимость. Так тот период считается табу. А потом начинают восстанавливать последовательность, проводить по партиям, рассчитывать себестоимость и у них с n-го года все пересчитывается. Вот они и хотят те n-ые года отсечь.

(100) "потом появляется потребность изменить или внести какую-то поправку в приход, внесли" . А в свернутой базе это как будет? один хер будут править документы остатков, и надо будет перепроводить все

(101) "надо будет перепроводить все" - в рабочем году - на здоровье, а в старой базе они просто внесут документ и ничего не будут пересчитывать.

(102) эмм. а зачем в старую базу вносить?

(17) 3 дня многовато.. 60 Гб УТ 10.3 свернулась за 17 минут.. + 1,5 часа удаление помеченных..

(103) Что-то должно пройти по бух учету, например, не знаю.

(105) Что-то - это что, например?

Походу у вас там у всех каша в голове - и у бухов в первую очередь.

(0) как вариант сворачивай регистры по одному. В свое время закрытие месяца шло 4 часа. Свернул регистр НЗП - ускорилось до 15 минут (очистил, оставив остаток на дату). Найди узкое место и устрани проблему сперва в нем.

(104) 3,14-шь. Либо у тебя ,5 заказа в день

(106) каша у тебя. По бухучету ВСЕ  должно проходить. А если нет - ну, каша у тс

(107) как вариант "сверни"

(82) ну так надо всегда свою голову на плечах иметь.

(92) самый дельный совет в топике.

Автор, ну как там, ты обсудил с заказчиком, как он будет действовать в случае свертки? Как будет править прошлые периоды при отсутствии в том периоде документов?
Можно же просто не двигать последовательность, раз их удручает потом долгая актуализация этой последовательности...

(113) Пока отстали, а сам не тороплюсь спрашивать.
"Как будет править прошлые периоды при отсутствии в том периоде документов? " - править прошлые периоды он будет уже в другой базе - архиве прошлых периодов.