Нужен совет. Перед мной поставили задачу, к новому году подготовить план или обработку для свертывания нетиповой УТ релиза этак 2016 года. Одной из проблем являются документы заказов, которые могут висеть месяцами, а значит их не удалить все подряд, а как-то организовать процесс. Можете что-нибудь посоветовать для подобной задачи? Раньше делал только "псевдосвертку", удалив документы, кроме документа инвентаризации и последующего ввода остатков на основании инвентаризации. Времени впереди до НГ - так что можно попробовать изучить какую-нибудь книгу или курс, если такой можно пройти, не привязываясь к определенным датам начала-завершения.

Буду рад любым предложениям

(0) типовые свёртки так и работает
берут остатки по Рг и заменяют КЗР или документамии ввода начальных остатков

не видно проблем

(1) База нетиповая, доработана не мной, сейчас изучаю доработки. И что делать с заказами?

(2) Позакрывать ненужные. Например, по дате заказа.

(2) реши как ты запретишь редактировать заказы прошлого года и все станет понятней

(2) [И что делать с заказами?]

есть по Заказу остаток в Рг  - нужен заказ, нет остатка - не нужен

Забей. Тебе она не нужна.

(5) Я в первый раз делаю свертку, поэтому не понимаю. Там почти никаких настроек нет. Типовая свертка поругалась, что не сделаны оприходования излишков и на денежные средства в пути, а дальше только кнопка дальше. И всё, крутит.

(7) Конфигурацию нетиповая, а свёртку берёшь типовую. Странно это.
(0) Возьми типовую свёртку и изучи по шагам. На её основе подготовь свою. Доработка будет связана только с изменившейся структурой при сравнении с типовой конфигурацией.

(8) Вот потому и задаю вопросы, почему-то гугол ничего вразумительного не выдает. Да и тут ты первый, кто хоть что-то посоветовал

(9) Не всё рано встают )) Гугл как любая помойка не всегда выдаст нужное

(10) Ну вчера весь вечер висел мой вопрос ) И ответы ты видишь)
Единственное, что успокаивает - времени еще много, если не тупить, можно докопаться до ответов

Тут еще такой вопрос, что лучше - обновить до последнего релиза, и потом делать свертку, или свернуть, а потом обновлять?

Обрезать по когда будешь? Обычно последний год-два оставляют чтобы если есть вопросы по докам не лесть в копию базы и потом не колдовать с исправлением ввода остатков.
ИМХО вряд ли в 19 году кого то будут интересовать не выполнение заказы 17 года. Как вариант заставить менеджеров заранее исправить даты чтобы нужные заказы были после даты обрезки.

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

(12) Сначала понять как работает свёртка. Остальное потом.

(14) КЗР в снеговике был ещё тшорт знает когда...

(15) Потому и ищу какие-нибудь книги или курсы по этой теме. Просто по коду лазить - тоже можно, но менее эффективно

Богачев утверждает что он может свернуть базу за 4 часа, попробуй посотрудничать

(18) Моя задача - научиться делать это. Потому что нетиповая УТ не одна, и со временем может понадобиться делать свертки и для них - а для этого нужно понять, как эту свертку настраивать самостоятельно. Возможно, он сможет свернуть базу за 4ч, но вряд ли в эти 4 часа войдет обучение меня). Потому буду рад любой ссылке на книгу или курс или топик на инфостарте, которая поможет мне разобраться в данной проблеме

(7) Логика в типовой простая (в 2-х словах):
- РС (срез последних) переносятся по флагам в настройке;
- РН оборотные - не переносятся;
- по РН остаточным делается КЗР.
Поищите в модуле обработки места, где "ругается" и попробуйте понять причину (излишки и ДС в пути).

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

(21) Вряд ли дело в том, что нетиповая: обработка бегает по метаданным. Посмотрите в настройке, есть ли "нетиповые" регистры.
На худой конец прогоните несмотря на "ругань" и посмотрите, какие КЗР были созданы. В частности, есть ли по "ругабельному" регистру.
Ну и остатки в источнике и свертке проверить.

(22) Ну сейчас как раз крутит потихоньку. точнее уже 3 часа крутит примерно. Посмотрю, насколько все плохо будет после свертки.
Из регистров нетиповой только регистр сведений (который по логике не надо сворачивать), все остальные доработки внутри существующих документов и влияет на рассчеты, а проводки вроде как типовые. Там кнопка, тут процедура к событию, которого нет в типовой. Надеюсь за пару дней хоть как-то смогу разобраться. Ну а нет - еще месяц есть минимум на доведение до ума.

(9)[почему-то гугол ничего вразумительного не выдает]
брехло

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

(22) речь про семерку. Там нет ни РС, ни штатных КЗР.

а, нет, все-таки восьмерка. Тогда извиняюсь

В общем, не могу один момент понять. Свернуть свернул базу, только почему-то не все документы получается удалить. Почему-то некоторые документы ввода начальных остатков ссылаются на документы, которые надо удалить. В частности ввод остатков задолженности подотчетных лиц имеет 60 записей и в каждой ссылается на документ списания безналичных ДС. Вопрос: так и должно быть? Я думал, что свертка сформирует документы начальных остатков, которые будут абсолютно независимы от документов прошлых периодов. А тут недосвертка какая-то.
И тут же рядом он формирует больше тысячи документов "оптовые продажи за прошлые периоды", для КАЖДОГО контрагента. Неужели нельзя было сделать контрагента - в табличной части? Хотя этот момент еще могу понять - проще контроллировать корректность свертки, так как у каждого контрагента свои документы. Но вот то, что документы ввода остатков ссылаются на документы удаляемого периода - это как-то странно по моему мнению.

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

(29) Спасибо, значит буду шаманить

(29) только он еще не решил и даже не подумал а нужен ли документ заглушка, нужно ли ставить дату закрытия периода, нужно ли заменять и насколько оправдана замена ссылок на документы "закрытых периодов"

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

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

Спасибо за критику и советы, буду учиться

(32) Из личного опыта свертки. Сразу озаботьтесь и обсудите с ГБ перенос "задолженностей" контрагентов, перенос платежного календаря, перенос НДС.
Надежный способ удаления документов - это перенос данных в чистую базу через создание документов ввода начальных остатков НДС и взаиморасчетам, корректировки записей регистров, нужных РС, документов, без которых не обойтись, и всех справочников, использовав обработку ВыгрузкаЗагрузкаДанных.
Считаю, если и резать базу, то месяца через 2-3 после начала нового года и оставлять в базе документы за 3 предыдущих года

(32) > Из ожидаемых эффектов - уменьшение размеров ИБ

Только учтите, что достичь значимого эффекта, скорее всего не получится. Безусловно результат будет зависеть от особенностей вашего учета и конкретной базы. Однако при сокращении периода в два раза (например, учёт ведётся всего 6 лет, свёртку делаете за 3 первых года из них) базу сможете сократить в лучшем случае на 20%. А скорее всего, на 10-15%%.

> ... что должно избавить от зависаний,
Ошибочное мнение. С высокой долей вероятности, сокращение БД (даже если удастся уменьшить размер значительно) не даст ожидаемого прироста производительности. В лучшем случае кратковременный эффект, который быстро сойдёт на нет.

> ... после свертки планируется нагнать оставшиеся релизы,
Каждое очередное обновление делает конфигурации всё более неповоротливыми и тормозными (если только речь не идёт о снятых с развития конфах на обычных формах). Так что обновление принесёт только дополнительное падение производительности. От этого конечно никуда не деться. Но к вопросу о борьбе с тормозами и зависаниями это учитывать надо. Даже если базы ускорятся на свёртке (во что я лично не верю), после обновления вы этого эффекта не заметите - обновление его нивелирует.

PS В 90% случаев свёртка является бесполезной тратой времени и труда (причём не только технического спеца, но и пользователей, которые вынуждены проверять корректность данных после свёртки). А кроме того вносит значительные неудобства в работу пользователей т.к. лишает их возможности пользоваться данными за свёрнутые периода в единой БД (приходится лазить в копию).
И только в 10% случае свёртка действительно оправдывает своё предназначение.
Любовь к сворачиваю - тяжёлое наследие клюшек (7.7), которое никак не вытравить из травмированного ими сознания разработчиков и некоторых пользователей.

ИМХО.

(34) Например, когда база УТ10 за 6 лет под 20 Гб (файловая) + РИБ по нескольким узлам + постоянно работает в базе 15-20 пользователей - по неволе будешь искать решения по "ускорению"

(34) После пробной свертки другой базы размер уменьшился на 40%. Оставлял хвост в пару месяцев.
Обновление УТ - необходимость из-за ввода в БК новой системы Виртуальный Склад. Так как приходы и реализации регистрируются в УТ, если не обновить до актуального релиза, то данные по виртуальному складу будут теряться. Если было бы возможно - не свертывали бы, но законодательство неумолимо. Дорабатывать самостоятельно желания нет

(0) цели свертки какие?

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

(36) > После пробной свертки другой базы размер уменьшился на 40%. Оставлял хвост в пару месяцев.

Что означает "хвост в пару месяцев"?
Обрезали базы под корень, оставив только последние два месяца учета? А вы это согласовали с кем-либо? Пользователей точно устроит, что в базе не будет никакой информации за прошлые периоды? Что динамику продаж анализировать будет нельзя (кроме как вручную, склеивая банные из разных баз)? А как вы собираетесь отражать корректировки поступлений и реализаций (если таковые возникнут)?
Если при почти что полной свёртке (2 месяца - это считай "ничего") удалось добиться только 40%-ного сокращения, то что же будет, если оставить в базе хотя бы весь последний год...

(36) Проб обновления я и не спорю. Практика показывает, что в большинстве случаев лучше их всё таки ставить. Если только конфа не в хлам переписана.

(39) К счастью или к сожалению, но некоторые пользователи не умеют пользоваться типовыми возможностями конфигурации. Анализа динамики считай нет, их интересуют только остатки. По поводу "целесообразности" такой свертки вопрос не ко мне. У меня это вообще первый блин комом, а вы задаете хоть и интересные, но на данный момент абсолютно бесполезные для меня вопросы - мне бы сначала разобраться в том, что и как делать, а потом уже по поводу организационных вопросов задумываться

(41) некогда точить пилу, пилить надо!(с)

(42) Ну времени еще месяц до часа Х, главное чтобы текучка и более срочные задачи оставили время на изучение.
Проблема в том, что до сих пор никто не подсказал ни курсов, ни книги, где можно было бы почитать про свертку. Руководство конфигурации про свертку написала меньше 2 страниц, в интернете примерно то же самое есть, потому я немного в замешательстве - неужели все вот так методом проб и ошибок приходит к пониманию что и как надо сворачивать?

(41) год назад сам озадачивался Перенос данных в чистую базу УТ 10.3 В итоге сделал и довольно удачно методом, который описал выше. Мануалы искать бесполезно - т.к. в каждой организации свои заморочки по поводу учета. Самое главное - на тему свертки держать контакт с ответственным и понимающим учет бухгалтером. Делать пробные свертки и давать тестировать, что не понравилось исправлять. Ну и думать и понимать, что делаешь, конечно, чтоб потом - месяца через 2  - вопросов к тебе поменьше было.
Мне помогли вот эти обработки http://catalog.mista.ru/public/100525/ - на их основе переделал чуток под себя

(44) Ну то есть ты использовал не типовую обработку свертки, а стороннюю?

(43) вот! ты постиг дзен

И все-таки очень интересно, каких результатов ты хочешь достичь, свернув базу, ибо

1. Тормозить она меньше не станет
2. Размер её также не станет меньше

(47) Еще интереснее причина, почему захотелось сворачивать

(48) Причины он описал в (32). Но никак понять не может, что свёрткой он поставленных целей не достигнет. Или достигнет, но с гораздо меньшим эффектом, чем ожидает.

(41) Я не спроста задаю свои вопросы.
Если всем на*рать на старые данные, а нужны только остатки, то вполне возможно, что целесообразнее будет не сворачивать существующую базу, а взять новую, пустую базу актуального релиза и перенести туда нужные справочники и остатки из текущей.
За счет переноса только тех элементов справочников, по которым есть остатки, сокращение будет ещё более значительным, чем 40%.
Кроме того не нужно будет заморачиваться с последующим обновлением конфигурации.

(41) Если пользователей интересуют только остатки, то и надо создать чистую базу и перенести туда только остатки товаров и взаиморасчетов, а остатки по банкам и кассам пусть сами введут.

(49) и правда, все описал. я не заметил.

ТС, а ты не хочешь с файлового варианта на SQL перейти?

(52) Вопрос не ко мне. Для этого надо обрабатывать Глав Буха, чтобы он обрабатывал директора, заставить потратиться на оборудование, саму СУБД, желательно еще админа вменяемого хоть на удаленке, Сервер 1С, возможно еще что-нибудь. И выйдет это скорее всего дороже, чем их траты на 1С за весь последний год, даже с учетом того, что в течение года были небольшие доработки.
Вообще это решило бы многие проблемы, но стоит ли брать SQL, если в базе около 10 пользователей?

(43) > никто не подсказал ни курсов, ни книги, где можно было бы почитать про свертку.

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

> Руководство конфигурации про свертку написала меньше 2 страниц, в интернете примерно то же самое...

Потому что можно сказать только общие слова, которые вполне укладываются в 2 страницы. Всё что больше и подробнее - либо очень индивидуально (зависит от того как настроен и ведётся учет), либо быстро устаревает.

> неужели все вот так методом проб и ошибок приходит к пониманию что и как надо сворачивать?

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

(45) использовал и стандартные и сторонние обработки + свои "костыли"

(54) Мой уровень понимания 1С пока что не позволяет представить последствия свертки) так что видимо буду пока что набивать шишки)

Два момента, о которых надо думать при разработке, это:
- свертка регистров
и
- закрытие периода
.

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

(53) > И выйдет это дороже, чем их траты на 1С за весь последний год

А сколько стоит твоя работа по свёртке, кто-нибудь считал?... Всё время потраченное на изучение проблемы, тестовые/пробные свёртки, финальную работу?
А работу пользователей, которые будут принимать готовый результат и сверять остатки?

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

+(57) Это Я к (56). Последствия определяются прикладным кодом конфигурации. Вот у тебя в регистре были обороты, а вот их и не стало, вот и все.

(58) А чем гарантированно поможет скуль и новое железо? Месяц назад смотрел базу на скуле, которая за месяц выросла на больше чем 15 гигов, не закрывающимся регистрам "нетиповых" попараллельны потуги админа сервера добавить железа. Без изучения базы ничего сказать нельзя конечно, но всё же легче создать чистенькую новую типовую и перенести откорректированные остатки, а потом железной линейкой бить по ручонкам тянущимся в конфигуратор.

(59) > были обороты, а вот их и не стало, вот и все

А потом в книге покупок записи не появятся при зачете счетов-фактур на аванс. Потому что оборотов по книге продаж за тот период, когда был аванс, вдруг не стало.

Пример конечно немного не из УТ, но не исключено, что в УТ могут быть похожие "нюансики".

(61) У них идет выгрузка в БП, т.ч. УТ явно чисто в качестве набивки документооборота, обычная схема.

(60) У тебя какая-то каша из различных причин просадки и методов решения проблемы производительности.

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

> базу на скуле, которая за месяц выросла на больше чем 15 гигов

Такой рост это конечно плохо. И за это надо наказывать разработчиков. Однако 15Гб для клиент-серверной базы не критично. А для файловой смертельно (если это одна таблица).


> параллельны потуги админа сервера добавить железа.

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

> А чем гарантированно поможет скуль и новое железо?

Тем, что не надо будет тратиться на регулярную свёртку. Клиент-серверной базе хоть 5Гб, хоть 15Гб, хоть 50 - особой разницы не будет.
Это работа спеца, работа пользователей по выверке остатков.
Свёртка отнюдь не такое уж и дешевое удовольствие, как может показаться на первый взгляд. Даже если процесс идеально отлажен и не требует последующего исправления ошибок свёртки (почти чудо, но иногда бывает).

(61) Это все уже последствия, о чем Я и написал в том посте, на который ты отвечаешь, так что осталось не ясным, к чему ты это написал

(20) есть в 10.3 как минимум 1 момент в котором такой подход выходит боком

(63) "Клиент-серверной базе хоть 5Гб, хоть 15Гб, хоть 50 - особой разницы не будет." - в описываемом мной случае 1 база полностью забила саташный диск и всё красиво встало :)