Я прошлый раз (по файлу RG1051.DBF) получил квалифицированную помощь (и, надеюсь, исполнитель удовлетворен работой со мной).

Сейчас проблема с 1SBKTTL.DBF.

И он растет с непонятной динамикой.
Например:
1) Тестовая база, сделанная 12.02.22 (но для работы точка актуальности стояла на 26.05) размер файла 1797 МБ.
2) копия базы за 30.04.22 (точка актуальности установлена на 1.06.22) размер файла 1864 МБ.
3) копия базы за 18.06.22 (точка актуальности установлена на 3.07.22) размер файла 1932 МБ.
4) актуальная база на 5.07.22 (точка актуальности установлена на 3.08.22) размер файла 1934 МБ.

Не ясно почему так. Вроде как, между базами 1 и 2 - 1 месяц по ТА и разница в размере файла -  67 МБ. Между базами 2 и 3 - 1 месяц по ТА и разница в размере файла - 68 МБ.
Так почему между базами 3 и 4 тоже 1 месяц по ТА, а разница всего 2 МБ?

Как бороть? С одной стороны - есть задача остановить такой бешеный рост (68 МБ в месяц. 1 год - 0,8 гига). С другой стороны - скоро 2 ГБ и все, база встает.

Обращу внимание на тот факт, что при пересчете итогов база зависает на 4 дня и ни разу (за последние 7 лет) такой пересчет не проводился.
Кроме того, в конце прошлого года "хирургически" резались некоторые регистры (и исправлялись некоторые проводки). При пересчете они могут опять "всплыть" (могут и не всплыть, так как проводки, все же, корректировались).

Надо, как всегда, вчера.

Это бух подсистема вроде.
#==TABLE no 422    : Остатки
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=1SBKTTL |Остатки                       |A          |1SBKTTL    |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=DATE      |Period              |D   |8     |0        
F=ACCID     |AccountDt Id        |C   |9     |0        
F=CURRID    |Currency Id         |C   |9     |0        
F=KIND      |Total kind          |C   |1     |0        
F=OBDT1     |Total turnover DT   |C   |15    |0        
F=OBKT1     |Total turnover KT   |C   |15    |0        
F=OBDT2     |Total turnover DT   |C   |15    |0        
F=OBKT2     |Total turnover KT   |C   |15    |0        
F=OBDT3     |Total turnover DT   |C   |15    |0        
F=OBKT3     |Total turnover KT   |C   |15    |0

я в этм не осбо силен.

Этот файл содержит рассчитанные бухгалтерские итоги остатков и оборотов по синтетическим счетам и объектам аналитики

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

https://koder.by/reducefile1sbkttldbf.php

Это что за конфига?

(5) Для чего там делается Выгрузка - Загрузка. Достаточно было в Тестирование-исправление запустить Упаковку таблиц.

Не закрытые остатки по счетам. когда остаток вроде бы и 0 а развернутый до всех субконто где то -1 а где то +1. Все тоже самое что и с регистром.
А скачкообразный рост может быть связан что когда выросла на 2 мд. кто то этот месяц перепроводил и все закрылось красиво. а в остальные месяца забили на это.

RG1051 - это регистр !!! WRAP.ert на сколько я знаю только для бух итогов по счетам ...
на ИС куча универсальных которые могут свернуть на дату ....

перейдите на СКЛ -))

к (5) и (7): Выгрузка-Загрузка и ТИИ-Пересчет итогов запустят помимо пересчета бухитогов 1SBKTTL.DBF ещё и пересчеты оперативных итогов запустятся.
Прошлый раз Злоп занимался, базу уже знает, значит ждём его - ему виднее.

к (0) - 1SBKTTL.DBF от точки актуальности не зависит, это поквартальные бух.итоги, и если у тебя в "Операции-Бухгалтерские итоги - Расчет итогов установлен по" стоит что-то кроме "3 квартал 2022 года" - это плохо. Некоторые нелюбители ежеквартального открытия бух.итогов могут двинуть на годы вперёд, что приводит к тормозам и росту объёма.
Так как у тебя проблема  с 1SBKTTL.DBF, а не с 1SENTRY.DBF, то скорее всего регулярно не закрываются какие-нибудь объёмные счета - типа 10 или 41 в России, какие у вас - не знаю.

https://infostart.ru/public/100646/

https://infostart.ru/public/65228/

Свертку надо делать. Скорее всего не закрываются полностью счета. А при увеличении бух периода этот файл и растет.

(0) 1SBKTTL.DBF это не регистры, а остатки плана счетов.

>>>Обращу внимание на тот факт, что при пересчете итогов база зависает на 4 дня и ни разу (за последние 7 лет) такой пересчет не проводился.

Это п...ц

Если есть RA и бухитоги, то поди ПУБ или комплексная, и там и там нужно выкинуть аналитику на 41 счете к еб..ям, и твой 1SBKTTL будет метров 100 от силы или меньше.

Комплексная там база.

(7) Выгрузка/Загрузка бывает раз в 10-100 быстрее Упаковки, тем более что при Загрузке идет пересчет условно говоря "пустых" таблиц.

(0) Не сильно нервничай, проблема 2Гб решаема:
Для увеличения памяти 1С больше 2Gb: 4Gb Patch NTCore https://ntcore.com/?page_id=371
Для загрузки и выгрузки dt больше 2Gb: ConfigSpy от АЛьФ http://www.dorex.pro/?projects&configspy&download
Для работы 1C с файлами dbf больше 2Gb: dbeng32 от Wirth https://cloud.mail.ru/public/3mVX/4trK45on8

Возможно после Выгрузки/Загрузки что да изменится.

А вот парадоксальное распухание проводок это что-то не так у вас в учете, совсем что-то не так, но не силен в бух учете...
Тут вариантов навалом, первое что вспоминается так это учет в 2х валютах, в 7ке сделано очень плохо - копейки не закрываются, ну и вообще копейки выплывают то там то сям и "отравляют" остатки...

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

(17) тогда отключи аналитику по номенклатуре на 41 счете, она там нафиг не сдалась

(20) я не имею отношения к автору. помню по его декабрьской теме.

Мне когда-то миста помогла. Когда файл близок к 2гб., то свертка уже не поможет. Точнее, поможет, но сворачивать надо чуть ли не по неделе-две. Потому что когда делаешь свертку полностью, то 1С-ка СНАЧАЛА пишет итоги в тот же файл, потом типа начинает очищать старые (собственно, а иначе то как). И для "потом" уже места в файле не находится. Я сворачивал раза три подряд. Сначала 2012-й год (база была с 2011-го), затем с 2012-го по 2018-й и потом уже окончательную сколько там осталось (буху нужны были доки за последний год и все).

(22) (18) (14) (11) (7) (4) Свертка и загрузка-выгрузка не работают. На загрузке-выгрузке безбожно зависает. Свертка периода невозможна из-за огромного  размера кода, который ДОПИСАН к 1-С (называется "технологический учет"). Там есть текущие процессы, которые не режутся (в отличие от фиксированных, одномоментных бухопераций). Плюс, есть куча регистров. Попытка обрезать базу была сделана на 1.01.2016. Не совсем успешно (многие регистры не изменились вообще, а многие документы остались помеченными на удаление, но не удалились из-за кучи перекрестных связей). Хотя тогда с десяток гигабайт из базы ушло (обрезчику реальное спасибо).

(11) спасибо. Бухитоги глянул. стоит 3кв 2022 года.

(11) (20) В балансе 41-й счет отсутствует.

(23) На загрузке-выгрузке безбожно зависает - ну так нужно ждать. Процедура не быстрая. Попробуй для начала просто сжать "Тестирование-исправление запустить Упаковку таблиц."
(25) Ну другой какой то счет видимо.

(25) и?

(23) Нуу, тогда переход на SQL вам поможет. Мне советовали и такой метод.

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

(25) очень интересно.  А вообще, проводки то хоть кто-то смотрит у вас ? Если бух итоги не еперсчитываются, то поди и в отчетах ад и Израиль и циферкам веры нет. Может, ну его на такую базу ?

Украинская комплексная ИМХО вообще худшая конфигурация из мне известных. А когда ее еще и переписывают как попало то получается вообще темный лес. у нас товары не на 41 счета а на 281 сидят. не должно там быть 41

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

По прошлому ремонту регистров там тупо двойной учёт по финансовым и упр учёту как в тис 8.7 плюс тупо не закрывались регистры. Когда ремонтировал по регистрации - после подчистки ненужного там от двух гиг почти с гулькин нос остался мегабайт 200, точно не помню.
По проводкам тогда не смотрел только глазом цеплял - имеется мне что там тоже аналогичная хрень. Надо смотреть. ТС для начала тупо построить ща последний месяц осв с максимальной разверткой по всём субсчетам по всём аналитикам и посмотреть.

А с учётом что украинский Worksection забанил все российские аккаунты... Встаёт аналогичный моральная проблема...

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

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

(29) очень похоже на то. Как-то в прошлом году пробовал запустить сжатие таблиц. Результат - почти нулевой.

(30) Проводки смотрим. Но смотрим так... вяло. Основное - контроль счетов 20.7 (остатки запчастей), 30 (кассы), 31 (счета), 36.1 (клиенты), 37,2 (подотчеты), 63.1 (поставщики), 70 (доходы) и 80 (затраты).
Еще в проводках используются другие счета, но мы их не очень контролируем.

Эта бухгалтерия - неофициальная и не используется для отчетности. Это СРМ на базе 1-С. Но с учетом прибылей и убытков (по нескольким субъектам деятельности).

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

с учетом написанного в (38) - там просто тупо куча висящих остатков

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

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

Мне чисто любопытно, если час программиста 1С стоит условно говоря 2000 руб., то сколько стоит час клинера 1с? Больше? Меньше? Сравнимо? Ну, зв отношение к клинеру мы не говорим, отношение к уборщику оно везде отношение к уборщику, но вот оно хоть того стоит?

(8) (11) подтверждаю, что выяснил, что этот файл "растет" при переводе бухгалтерских итогов (там переход поквартальный). Сейчас я экспериментирую с копией базы за 12.02.22. И при переходе с 1-го квартала на 2-й и со 2-го на 3-й происходит рост файла на 63,5 МБ. А при переносе точки актуальности - размер не изменяется.

Купите уже БП3

(41) Уважаемый гость из Мариуполя.
Не понимаю почему Вы считаете это троллингом?

Если бы у меня было предприятие типа Сбербанка или Аэрофлота - я бы взял миллион долларов и купил бы хорошую, настроенную программу. Но когда предприятие на грани закрытия, то ресурсов хватает только на какие-то полу-меры (и это касается не только бухгалтерии).

С официальной бухгалтерией у нас проблем нет. Все работает, ничего не глючит. Красота. Я туда вообще не вмешиваюсь.

Но конкретно эта программа досталась в наследство и в ней 1-С - это базис, к которому прикручен специальный технологический учет (CRM). И тот человек, который это писал (лет 20 назад), возможно, не все учел. А после него было несколько специалистов (еще до моего присутствия), которые отключали куски кода. Но как отключали и где - никто не знает. Я получил в наследство некоторую программу, у которой что-то работает хорошо, что-то - не очень, а что-то вообще не работает. И мне, директору, приходится вникать в суть программирования и как-то править этот механизм.
При этом, я не соглашусь с Вами, что я нанимаю просто клинера. Я вместе с программистом изучаю код и исправляю его так, чтобы ошибки не накапливались. Вот я за последние 9 месяцев разбирался с 2 регистрами и не просто порезал их, а добился того, чтобы эти файлы больше не собрали мусора. И все путем.

(42) точка актуальности - это оперативный учет, регистры. а бухгалтерские итоги поквартальные - это бухкомпонента.

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

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

(46) согласен. Меня самого не устраивает вариант затыкания дырок. Главное - чтобы для реализации правильного варианта было время. Следующий переход на 4 квартал может быть критичным.

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

(47) мусор убирать просто когда понято что есть мусор а что нет...

(47) я не совсем понял - что Вы имеете ввиду.

(43) Если это новая платформа, то вариант не подходит. 1-С - только базис. В моей конфигурации основная ценность - дописанная СРМ. Чтобы перейти на другую платформу - надо взять код СРМ и интегрировать с новой 1-С. При этом - еще перенести остатки, незаконченные процессы СРМ. Я пару раз показал программистам задачу - они просто отказались. Даже цену не называли.

(26) (39) Только что запустил Упаковку таблиц информационной базы. Файл как был 1924533 кБ так и остался.

(51) Извиняюсь но CRM это не "специальный технологический учет"
И 1С пишется слитно

(51) >Я пару раз показал программистам задачу - они просто отказались. Даже цену не называли.

Вероятно вы попросили сделать на новой платформе 1С в некой типовой конфе "точно так же как в старой".
За это не возьмутся ибо нет смысла.

Есть множество готовых типовых и отраслевых конфигураций.
На 110% уверен что ваш уникальный лисапед он нифига не уникальный и аналогичные бизнесы давно уже что то готовое используют.

(49) хм.. база 20-летней давности.. Зачем? документы 20-детней давности никакой ценности, кроме ностальгической, не имеют. Даже документы 5-летней давности. Все это - мусор. Все, что старше 5-лет, в нынешних условиях значения не имеет. Даже для налогового кодекса.

взять копию базы и удалить в ней из последних 20 лет 15 все документы. Я не думаю, что у вас на складе остались автозапчасти, приобретенные 5 или более лет назад. Я не думаю, что у вас актуальны какие-то остатки 5-летней давности.
Но на всякий случай оставить в базе последние 5 лет можно. Остальное - удалить.Все приходы-расходы-заказы, все документы и все движения, которым больше 5 лет.
То есть как вариант я говорю вам не страдать ностальгией, а обрезать базу. И тогда еще лет 10-15 протянете. А там - или ишак, или падишах..
для истории и ностальгии исходную копию, разумеется, оставить.

(53)+ CRM это Customer Relationship Management
- система управления отношениями с клиентами
https://solutions.1c.ru/catalog/crm-prof/features

(55) Именно.
Нет смысла дольше 3 лет хранить.

(53) По поводу 1С - спасибо, учту.
Технологический учет - это наше внутреннее название. Так как этот кусок кода описывает процесс выполнения ремонта. (грубо - этапы техпроцесса)
(54) Именно так и просил. Это низкорентабельный вид деятельности и большинство участников рынка обходятся экселом. Некоторые используют отдельные СРМ (специализированные, от производителей). Но такие СРМ не решают задач бухучета (пусть и в урезанном виде).
Я не горжусь этой программой. Она просто есть. Но относительно уникальная.

Не надо упаковок никаких, это же рассчитанные итоги.
В (33) всё сказано.
Выводишь общую ОСВ с разверткой по субсчетам за период 01.07.2022 - 01.07.2022. С забалансовыми!
Тыркаешь в расшифровку каждого счета/субсчета, чтобы вывести оборотно-сальдовую ведомость по этому счету/субсчету (так в типовой), если в АВТ этого нет - то просто выводишь оборотки по каждому своему счету, в том числе забалансовым, также за один день - начало квартала.
Смотришь в каких из них будет больше, ну скажем 5000 строк (можно включить отображение заголовков строк (Меню Вид-Заголовки), чтоб было видно номер последней строки).
Разбираешься - есть ли там реальные остатки или это просто незакрытая аналитика по субконто. По результату уже можно будет давать советы.

>процесс выполнения ремонта
https://solutions.1c.ru/catalog/service-center/features

ммм.. чуток уточню, а то вдруг, все-таки не специалист. Не просто удалить документы, а именно СВЕРНУТЬ и обрезать базу. А то вдруг вы сейчас возьмете и просто удалите документы.

(61) Это бесполезно.
Чтобы решить проблему свертки нужен хороший специалист по 77.
А их сейчас уже хрен найдешь дешево.

Имхо выгрузить в эксель нужные данные по НСИ, остаткам/долгам
И загрузить в готовую отраслевую конфу
Текучку (незаконченные ремонты) дозабить руками
На все старое глубоко плевать, база 77 же остается для истории

А можно озвучить размер 1SENTRY.DBF? А то может он 20 Mb, а мы тут "свёртка", "переход"...

(55) Программе - 20 (или больше) лет. У нас на фирме она 16 лет. Вы не поверите. У меня нет никакой ностальгии по этому поводу. Стоял даже вопрос - экспортировать остатки в (например) Эксел. А потом - импортировать в новую, пустую базу. Но у программиста чет все умерло при экспорте. В 2016 году один программист попытался отрезать все, что было до 2016 года. Часть смог отрезать. Часть - не смог. Хоть отрезал около 10 гиг (уже не помню сколько). Но тогда, 6 лет назад, я еще не понимал, что проблема не в общем размере базы, а в размерах файлов таблиц и индексов на уровне 2 гиг. Это я сейчас знаю ))))

Но дело даже не в этом.

(61) вопрос в том, что у нас в этом технологическом учете (извините, буду так называть) кроме бухгалтерских операций (типа банковской выписки, кассового ордера, накладной) есть процесс (ремонт). Он распределен во времени (от одного дня до... 1 года). Он разбит на этапы. К каждому этапу привязаны разные бухгалтерские документы. В любой момент времени около 1500 процессов находятся... в процессе (сорри). И свертка в любой момент времени - нормальна для бухучета, но неприемлема для этих процессов. Не получается разрезать и перенести части процессов из старой программы в новую.

(64) файл 1SENTRY.DBF 480332 кБ

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

(59) Но наведение порядка может хорошо остановить рост файла. Но уменьшить-то не сможет.

(60) Спасибо! Попробую ознакомиться.

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

к примеру, приняли вы на ремонт мерседес в сентябре 2015, а в январе 2016 передали его в кузовной, покрасили и выдали заказчику. Пусть у него там была куча документов от приемки, выдачи запчастей, ремонт двигателя, ходовой и т.д. и .т.п. каждое телодвижение сопровождалось соответствующими документами, которые ссылались друг на друга по цепочке. Мы все это обрезали и на 1 января сделали ссылку на служебный документ ВВОД ОСТАТКОВ. (или как угодно обозвать). В итоге у нас документ передача в кузовной ссылается на ввод остатков, а все что до этого - покрыто мраком.

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

у вас желание сохранить процесс полностью, всю историю и это понятно. Но почему нельзя обрезать половину истории, половину процесса, кому  оно нужно спустя 5 лет?

Ссылку во всех хвостах всех процессов на дату обрезки сделать на служебный документ, который обозвать - "Есть ли жизнь на Марсе? Науке СИЕ НЕВЕДОМО..." и пусть хвосты этих обрезанных  процессов болтаются себе в CRM.

Правильно там программисты отказались.
Чтобы прог мог что-то вменяемо сделать - ему нужна не старая база как образец - а описание бизнес-процессов, причем вменяемое. А вот с таким вот описанием - в компаниях - беда. И описания нужны не отрывочные инструкции по участками что и как делается а общая связанная схем от входа до выхода по концепции зачем и почему. а уже пониже уровнем что и как...
.
делать мега-мега-заточку прям вот до мелочи-мелочи именно под свою контору - это надо взять на полгода-год в штат на постоянку прога, который еще и не прог, а в довесок еще и немножко аналитик. Тогда что-то получится.
.
а с учетом того что как написал в этой ветке ТС - он директор и разбирается в этом доставшемся ему наследстве - цельнйо системы там никогда не было. строилась постепенно костыль за костылем, сорри. Это даже по интерфейсу видно.
.
это не есть хорошо, это не есть плохо. это есть как есть, жизнь. Плохо только то, что за 20 лет это не удосужились привести во вменяемое состояние. То есть контора на развитие и поддержку бюджетов не выделяла. И приплыли к тому к чему приплыли.
.
и даже обрезка, которая была сделана по состонию на 2016 год - она сделана была технически, не убрав все "болезни левизны в коммунизмке"...
.
поэтому есть два вариант
1. забить и перейти на отраслевоей решение на 8-ке
2. взять хорошего прога семерочника - они еще остались (тут я почешу ЧСВ) - выделить дохера бюджета и провести тотальный рефакторинг и процессов и кода. Тогда на отрефакторенном варианте до 2037 года можно будет без проблем дожить...

Процессы нефига не уникальные и бизнес не везде низкорентабельный. Для того же обслуживания и ремонта техники была специализированная конфа МИФ в 2000 годах не знаю во что на сейчас переродилась. Авторемонт +/- те же техпроцессы и уж что он низкорентабельный язык не повернется сказать. И контор занимающимся им миллион.
Другой вопрос, что сейчас не совсем то время чтобы устраивать переходы на новые платформы. Бух учет и оперативный учет сами по себе не сильно связаны. Самое простое сейчас создать бух остатки на 31.12.17. запретить изменять документы до этой даты и выключить проводки в более ранних документах.

(72) Все попытки остаться на 77 это лишь временная заморозка ситуации
Вряд ли ТС до сих пор ездит на https://ru.wikipedia.org/wiki/Ford_Model_T не так ли

(74) ну в доме постройки 60х годов вполне можно жить. А есть еще дома вообще по несколько сот лет

Я чисто из интереса. А почему базу не перечти на SQL? Это проблему не решает? Я переводил семерку с данным приколом на скуль, все замечательно работало.

(74) В стране война в Мариуполе народ уже рисует русские печатные формы.
(76) По СКЛ железо не потянет. Нужно новый сервак покупать и все перенастраивать при том что в таких сервисах обычно 1-2 девочки на приемке сидят максимум и мастера иногда заходят заказы состояния ремонтов изменяют. Обычно там 20-30 документов в день вообще не объем при прямой базе.

Я бы для начала посмотрел на проблему незакрытых остатков. Можно накидать отчет вида: остатки по счету в целом и остатки по всем аналитикам этого счета. И уже вручную проаналитизовать, где развернутое сальдо.

(70) Вы сейчас мне подкинули одну идею насчет обрезки... Я над ней подумаю... ОГРОМНОЕ СПАСИБО!!! Только я чувствую, что обрезка - это, все равно, не полноценное решение. Ибо если что-то где-то неправильно делается из-за неправильной дисциплины учета (как Вы же правильно  и сказали!!!) то даже в новой, обрезанной базе начнут накапливаться новые проблемы. А их надо победить ПРИНЦИПИАЛЬНО!
Еще раз спасибо за подсказку. Вы меня натолкнули на интересное решение. Всегда важен взгляд со стороны.

Но пока я буду правильное решение реализовывать, могу упереться в 2-гиговый файл 1сбкттл. Вот тут бы я подстраховался бы как-то.

(76) сисадмин не тянет этот момент. Он приходящий и делает все по минимуму. А запускать скул - это для него ЗАДАЧА

Сейчас на работе в запаре. Смогу ответить вечером.

(78) Та вообще.
Прежде чем анализировать всякие развернутые сальдо, я бы для начала посмотрел вообще на всю аналитику по всем счетам, и, если она не нужна в принципе, то удалил бы лишние субконто у счетов нафик вообще. С ТИИ и пересчетом итогов, разумеется. Чтобы не анализировать и не сворачивать ненужные остатки и обороты по ненужной аналитике, проще их вообще убить. Нет тела - нет дела. :) нет субконто на счете  - нечего и анализировать.
А Если какая-то аналитика все-таки нужна, но не закрывается, то, следовательно, ему нужны не остатки в разрезе этой аналитики, а всего лишь обороты по этой аналитике. Такие субконто можно посмотреть и может быть сделать.. оборотными..
Ну и только та аналитика, которая ему нужна в разрезе остатков.. хм.. он и так говорит, что некоторые счета и аналитику по ним они контролируют. Видимо, как раз ту, которая ему и нужна в виде остатков.

(80) Вот это и будет ПРИНЦИПИАЛЬНОЕ решение. Убрать всю ненужную аналитику вообще.. из плана счетов..

Правда, придется очень внимательно все документы проверить и переделать их проведение только на предмет нужной аналитики. Что тоже работка ой-ей-ей немаленькая.

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

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

ну и где нужно, порядок субконто откорректировать..

Глянул файл автора. 65% первых 100 тыс записей этого файла это 24 счет "брак в производстве" который как понимаю никогда не списывали.
Еще 26% приходится на счет 29.1.1 это запчасти в готовых изделиях гарантия. Кто придумал гарантию на счетах хранить хз. как минимум сразу +/- делать и искать не по остаткам а по оборотом. Брак скорее всего достаточно с определенной периодичностью просто списывать. вряд ли вам нужно знать остатки брака за 15 год.
А по гарантии нужно менять логику и отчеты которые ее юзают.

(83) пересчет итогов у автора зависает и 7 лет никто не делал. там ручками придется файл вычищать.

(83)Лесть и править всю аналитику и править проведение ради оставшихся 9% объема смысла нет.

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

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

(90) Если я это буду делать гляну по базе, если будут вопросы стукнусь уточную.

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

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

(93) Может там и с кодом все нормально и просто нужно регламентные работы проводить регулярно и нормально документы вводить. Есть у меня клиент база нормально написана все ок должно быть, но полный бардак. Нужно править и заносить документы задним числом и все тут. Причем потрудиться и разобраться что приходную нужно внести 1 а не 2 числом никто не хочет. препроводить базу хоть иногда тоже. В итоге в отчетах видят полную фигню и говорят напиши нам базу так чтобы работала красиво и правильно. И удивляются, что я не хочу за это браться, мы же денег заплатим просто скажи сколько.

(66) Файл проводок должен быть раза в 2 больше файла итогов, ну или того же порядка. То есть 1SBKTTL.DBF раздут в 10 раз.

Ну и в целом понятно - проблемные счета выявлены, решения зависят от логики работы программы.
(92) Наверняка можно сделать субконто по 24 счету оборотными, если он под ноль ежемесячно списывается, а по субконто не закрывается. Тогда и проблема уйдет сразу.
Если да, тогда для быстрого пересчета можно на копии удалить 1SBKTTL.DBF и RG* RA*, потом сделать субконто оборотными, пересчитать бух.итоги и подсунуть уже в рабочую базу. Ну это уже надо код видеть.

Привезли внука. Это КАТАСТРОФА. Приношу извинения, что не отвечал и не реагировал. (((((((((((((((

(95) Изучаю проводки и оборотки по 24 счету.
Вижу явные бока именно по 24-му счету. Там и партия "теряется", и дата проводки неверно формируется при списании с 24-го...

Буду думать - как исправлять.

Можно попросить Вас пояснить: что значит "сделать субконто по 24 счету оборотными"?

Примечание: сч 24 под ноль ежемесячно не списывается. Там постоянно есть (должно быть) сальдо.
По одному документу (Внутренняя расходная накладная) запчасть списывается со склада (счет 20.7) в текущий ремонт (счет 24). А по факту окончания ремонта (документ "Ремонт" получает статус "готов") запчасть должна быть списана с 24 счета в 29.1.1. "Запчасти в готовых гарантийных ремонтах". При переходе с месяца на месяц есть большое количество ремонтов "в процессе". То есть, запчасть со склада выдана в производство, но производство еще не закончено и запчасть висит на 24-м счету.

В конфигураторе открываете план счетов клацаете по партиям и в открывшемся списке выбираете  только обороты. Только боюсь он уйдет в пересчет итогов после этого, а если они у вас не считаются...
По итогу конда вы смотрите оборот за период у вас будет
Склад Пети - шестеренка- Приходная ... -10 шт.- 300 грн.
А когда смотрите остатки
Склад Пети - Шестеренка - 10 шт -300 грн. В остатках партии свернулись

То что есть незакрытые ремонты и сальдо на счёте при переходе месяца не проблема если это в итоге закроется. А вот если не закрывается или остаётся какая-нить 1коп незакрытая из-за кривых рук костылестроителей то вот вам и жопа

100!

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

Второй вариант: сделать ежеквартальную закрывющую операцию со сверткой аналитики по закрытым партиям.
Д24 Пустая партия Д24 Закрытая партия

Третий вариант: не спеша по ночам или в фоновом режиме пробежаться по проводкам по сч.24 за старые года и занулить субконто "Партии".

Прелесть бух.компоненты в том, что в отличии от оперативных регистров можно без извращения с технологическим перепроведением или прямым лазанием в DBF в рабочем режиме штатными средствами менять проводки у проведенных документов как хочешь. Любые из вариантов лучше попробовать сначала на копии, потом попробовать "Операции-Бухгалтерский итоги-Полный пересчет итогов". Все три варианта по итогу должны сильно ужать 1SBKTTL.DBF
Но всё равно без анализа конфигурации я бы не стал рекомендовать ничего делать, любые варианты всё-таки требуют определённой квалификации.
Больше наугад невозможно - стоит поискать спеца в доступности (uno-group?)

Тогда субконто партии вообще убрать если оно в оу есть

Средневзвешенная цена рулит. Партии буквоеды придумали.

(99) я так понял, что там вообще не закрывается ни один гарантийный ремонт правильно. Списание с 20.7 (склад) на 24-й счет идет с указанием партии. А с 24-го списывается не по партии, а по строке < > (я не понимаю что это, но похоже на партию по умолчанию). В результате, по всем закрытым гарантийным ремонтам на 24м счете есть +1 и -1 по двум разным строкам (по партии и по < >). Более того, списание с 24-го счета делается не в момент окончания ремонта, а задним числом (когда ремонт создан). Не понимаю логики такого. Ведь у документа "Ремонт" есть конкретное поле - "Дата готовности" и очевидно, что списание с 24-го счета должно быть датой готовности. А сейчас по учету деталь с 24 счета списывается раньше, чем выдается (хотя реально операция списания проводится позже). И вот это плодится и размножается с момента начала работы. Даже те ремонты, что уже попали под обрезку, оставили после себя это "счастье". И очень прикольно это выглядит для ремонтов,  которые были созданы до даты обрезки (1.01.16), а запчасти по ним выдавали после даты обрезки. По таким ремонтам списание со склада на 24-й счет есть (так как накладная создана после 1.01.16), а списания с 24 нет, потому что дата создания ремонта - до 1.01.16. (где тут смайлик "рука-лицо"???)))))

(98) Спасибо огромное! Попробую на копии. Все пробую на копиях. Их уже как собак нерезанных ))))

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

Строка субконто со скобками - это незаполненное субконто или заполненное субконто но заполнен на карточка субконто неверно, например не введено наименовпние

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

(98) Значит ли это, что партии (субконти) пропадут по всем счетам? Или можно сделать, что партий (субконто) не будет на каком-то конкретном счете?

(106) у меня не отражаются сообщения 101-102-103

(106) Именно когда курс скачет как бешённый средневзвешенная цена и рулит. У тебя себестоимость плавно растет и плавно снижается И фин результат твоей деятельности нормальный и цены нормальные и продажи не скачет вслед за курсом. сегодня грузим фурами завтра курим бамбук.

(110) клацнули не по 2 странице а по треугольнику при заходе в тему

(109) на конкретном

(104) Кстааати. Не все так однозначно плохо. Есть еще хуже. ))))
По тем ремонтам, которые попали под обрезку, ситуация очень неоднозначная. На 24 счету:
По ряду ремонтов есть +1 -1.
По ряду ремонтов только -1 (с ссылкой на <  > или на Авансовый отчет или на Приходную накладную)
По ряду ремонтов только +1 (с ссылкой на Приходную накладную)
По ряду ремонтов сумма зачисления на 24-й отличается от суммы списания (хотя количества совпадают).

КРАСОТА )))))

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

(103) мы до сих пор должны отчитывать перед производителями использованные в гарантиях запчасти в привязке к партии. В отчетах указываем номер их отгрузочного документа. Только сегодня переуточнял. Все именно так. Поэтому пока от партий отказаться не можем.

(116) Причем тут одно к другому. Пишите эту информацию в документ серийный номер используемой при ремонте запчасти. строите черный запрос по документам для своего отчета производителю. Я начинал свою карьеру в дилерском центре Canon лет 12 отработал без всяких партий все работает. В партии у вас есть только приходная накладная а по 1 приходной может прийти 100 запчастей с разными серийными запчастями и производителю одной приходной все равно мало они просят еще и номера. Так что с 1 счета вы все равно инфу не вытащите только документ потом начинается перебор строк документа или подчиненного документа.

По хорошему там не партия должна быть а серийный номер.

(118) у наших запчастей нет серийного номера. Вы правильно говорите: есть немало ситуаций, когда приходит несколько одинаковых запчастей. И у них нет серийника (подшипник, сальник, термостат, амортизатор, тен и т.п.). Мы в отчет вписываем только номер документа отгрузки поставщика, который привязан к нашему номеру партии. Этот номер документа и вытягивается в отчет через наш номер партии. Пока у нас так оно работает. И боюсь, что я не готов как-то пересмотреть текущую схему. Вынужден пока работать с партиями (при том, что в другом бизнес-проекте по торговле мы замечательно работали без партий и я видел как это делалось).

(117) бренды у себя ведут некоторый виртуальный склад каждого АСЦ, отслеживая отправки и списания. Возможно, так они стараются избежать злоупотреблений, когда отправили на АСЦ 3 запчасти, а АСЦ списывает 5 (и требует за это оплату). Проверка неидеальная, но она возможна. И это не наши правила игры.

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

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

(121) в самом документе, который отгружает запчасть со склада в производство (на ремонт), есть указание партии. Документ называется "Внутренняя расходная накладная". И там партия выбирается. И она же проводится по счету 24 с указанием партии (и там зависает). А вот списание с 24-го проводится без указания партии (почему-то). Вот так сейчас и возникает "пересортица" на 24-м.

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

в 2016 году выловил еще одну красоту.

По внутренней расходной накладной запчасть списывалась со счета 20.7 (склад) на 24-й счет, а по факту постановки в готовность стоимость запчасти списывалась на счет 29.1.1 с.... 23-го счета.

Просто нет слов.............

а причем тут 24 и отчет о гарантийных запчастях?. Я так понимаю, информация о гарантийных хранится на счете 29.1.1 и оттуда по идее и должна браться в отчет, не? вот там на 29.1.1 партии и нужны. Раз у вас там гарантийные ремонты хранятся.

а на 24 у вас же списываются не только гарантийные, но вообще все ремонты? вся сборная солянка.
и опять же, вашему поставщику неинтересно, по какой цене (с какой наценкой/накладными расходами) вы оприходовали запчасть на склад и потом списали в производство, его интересует цена, по которой он вам запчасть поставил. Может, отсюда на 29.1.1 и тянется цена не с 24, а с 23 счета?

(125) А я и не утверждаю, что счет 24 напрямую связан с отчетом о гарантийных запчастях. И я не готов сказать, что ВСЯ информация о гарантийных запчастях хранится на 29.1.1
Но судя по проводкам с 24 (23) на 29.1.1 идут проводки без указания партий. И как-то оно пока работает (в отчет попадает информация про партии). Пока не готов сказать - как.

Вы правы: поставщику не интересно какие были накладные расходы. Но компенсирует нам он цену из своей накладной. Если по одной накладной запчасть пришла за 100 грн и мы ее поставили, то в отчет попадет (и будет компенсировано 100 грн). А если по второй накладной запчасть пришла за 90 грн, а мы попытаемся подать в отчет за 100 грн, то нам скажут: "не шалите ребята. Мы вам запчасть по 100 уже компенсировали." Поэтому они и следят за складами АСЦ (и судя по всему, у себя тоже ведут партионный учет наших складов).  

Я сейчас пришел к выводу, что база где-то бочинит. Так как одни и те же ремонты проводит по-разному. Вот я только что взял 2 ремонта с разницей в месяц. В каждом ремонте проводка Дт 29.1.1. Кт 24 (то есть, запчасть списывается с 24 счета). Но в одной внутренней расходной накладной запчасть закидывается на 23 счет,  а во второй - на 24. Вот и буду разбираться - что заставило базу так поступить.

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

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

та в бюджетке вообще легко (в БГУ1) :) там, к примеру,  как только начинают ныть, что у них 737 "не идет", так первым делом смотри кассовые поступления/выбытия с видом операции "прочие поступления/выбытия" сто процентов в табличной части забалансовый 17/18 тиснули, да еще убрать не умеют (Shift F4 нажать). :)))

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

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

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

(132) следует уточнять про какой пересчет итогов идет речь - про БУ или ОУ.
ОУ - у ТС пересчет итогов запускать не следует. так как движения за прошлые периорды у ТС кривые по ОУ и при пересчете итогов слетит нафиг леченное прошлый раз. писал об этом выше.

(133) ТС вроде на БУ жалуется. В 77 оба учета можно пересчитывать по раздельности.

Следующим этапом ускорения пересчета, это запускать это все на виртуальном диске, включая временные папки. Очень существенно ускоряет процесс, даже относительно SSD. Память сейчас не так дорога, как в прежние времена. Я когда-то пользовался RAMDrive (или RAMDisk?).

А вообще, смысл лечения ОУ, если итоги в результате кривые? И не путаете ли Вы перепроведение, с пересчетом итогов? Я кривые итоги ОУ лечил созданием спец.документа корректировки остатков, который закрывал все не нужные итоги, хоть каждый месяц. Алгоритм расчета лишнего смотрится персонально. Очистку и перепроведение типовые в нем отключать, чтобы случайно после не запустить.

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

Что-то я увлекся, я 77 больше не занимаюсь. Не за разумные деньги.

(126)         Если (Квитанция.Гарантия = 1) И (Квитанция.Гарантия_Повтор = 1) Тогда
            Проводка(Контекст,"24",ТМЦ.Счет,СуммаУчет,"Выдача детали на повторку",Кво, Склад,ТМЦ,Партия,
            Склад,ТМЦ,Партия, ,,"РМ");
            Проводка(Контекст,"91","24",СуммаУчет,"Списание детали на произв. затраты",Кво, Константа.БазВидЗатрат,,,
            Склад,ТМЦ,Партия, ,,"РМ");
        Иначе
            Проводка(Контекст,"23",ТМЦ.Счет,СуммаУчет,"Выдача детали",Кво,Константа.БазВидЗатрат,,,
            Склад,ТМЦ,Партия, ,,"РМ");
        КонецЕсли;
Как понимаю в документе есть галочка какой это ремонт гарантийный или нет и он соответственно проводится или на 23 или на 24 счет.

Отчет жесть жестокая выглядит как то так.
        ДокКв=СоздатьОбъект("Документ.Квитанция");
        ДокКв.ВыбратьДокументы(НачДата,КонДата);
        ДокРасх=СоздатьОбъект("Документ.ВнутренняяРасходная");
        ДокРасхОбщ=СоздатьОбъект("Документ.ОбщаяВнутренняяРасходная");
        ДокРем=СоздатьОбъект("Документ.Ремонт");
        ДокВыд=СоздатьОбъект("Документ.ВыдачаАппарата");
        ДокЗак=СоздатьОбъект("Документ.ЗаказНаОтправку");
        ДетЗап = СоздатьОбъект("Справочник.ТМЦ");
        ТМЦЗап = СоздатьОбъект("Справочник.ТМЦ");
        ПарЗап = СоздатьОбъект("Справочник.Партии");
                
        к=0; ОбщаяСумма=0;
        Пока ДокКв.ПолучитьДокумент()=1 Цикл

                        Иначе
                            Если ФлагОтборДатаПолучения=1 Тогда
                                Перейти ~r1;
                            КонецЕсли;
                            
                            Если ФлагОтборПост=1 Тогда
                                Перейти ~r1;
                            КонецЕсли;
                            
                            Если ФлагОтборДатаВыдачи=1 Тогда
                                Перейти ~r1;
                            КонецЕсли;  
                            
                            Кол=Строка(ТекРем.НужноеКоличество);
                        КонецЕсли;
                        Если ДокВыд.НайтиПоНомеру(ДокКв.НомерДок,Дата(0))=1 Тогда
                            ДатаСпис=Строка(ДокВыд.ДатаДок);
                            Если ФлагОтборДатаСписания=1 Тогда
                                Если ДокВыд.ДатаДок <> ДатаСписания Тогда
                                    Перейти ~r1;
                                КонецЕсли;
                            КонецЕсли;
                            Если ФлагОтборСписан=1 Тогда
                                 Если ((ДокВыд.ДатаДок < ДатаСпис1) ИЛИ (ДокВыд.ДатаДок > ДатаСпис2)) Тогда
                                     Перейти ~r1;
                                 КонецЕсли;    
                            КонецЕсли;
                            СостояниеДетали="Списана";
                        Иначе
                            Если ФлагОтборСписан=1 Тогда
                                 Перейти ~r1;
                            КонецЕсли;
                            Если ФлагОтборДатаСписания=1 Тогда
                                 Перейти ~r1;
                            КонецЕсли;
                        КонецЕсли;
Какие нафик счета, регистры о чем вы говорите. Черные запросы по документам в самом жестоком исполнении.

(135) Да, такая галочка есть. Там даже 3 галочки есть. Если не стоит галочка "гарантия" - аппарат платный. Если галочка "гарантия" стоит - то проверяется еще 2 галочки: если стоит галочка "по фирме", то тогда эту гарантию оплачивает производитель (и такой ремонт имеет тип "гарантия по фирме" или "Предторговый"). Если стоит галочка "по предприятию", то тогда эту гарантию оплачивает сам СЦ (и такой ремонт имеет тип "повторный").

(136) А тут я ничего не понимаю ВООБЩЕ ))))))

А еще не понимаю - что значит ЧЕРНЫЕ ЗАПРОСЫ В САМОМ ЖЕСТОКОМ ИСПОЛНЕНИИ ))))))

(133) поддерживаю. ОУ пересчитывать нельзя. Ибо тот аппендицит, который качественно вырезали ранее, вырастет опять и положит базу (более 2ГБ).

(134) А как пересчитывать БУ отдельно от ОУ - не подскажете? Буду очень благодарен.

(127) Я, почему-то уверен, что дело не в менеджерах. Менеджер имеет перед глазами документ Ремонт (определенного типа) и делает одни и те же действия (формирует Внутреннюю расходную накладную на основании документа Ремонт) независимо от того - какой тип документа.
Я сейчас посмотрел этот документ - там никаких галочек нет. И 3 менеджера (разного уровня стажа) подтвердили, что внутренняя расходная накладная формируется одинаково для любого типа ремонта.

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

(134) спасибо за идеи с рамдрайвом. Промониторю этот вариант.

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

(134) "Я кривые итоги ОУ лечил созданием спец.документа корректировки остатков, который закрывал все не нужные итоги"
- осталось написать формальные правила для автоматического определения "не нужных итогов"

(136) "Черные запросы по документам в самом жестоком исполнении."
я в этом практически был уверен, ибо строить что-то по той кривизне что в ОУ - страшно...

(142) Дают, существенный. И не только для пересчетов итогов. Если у Вас не получалось, значит Вы не то делали.

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

(139) Оно там точно есть, но детали вспоминать это нужно открывать программу. Смотрите в тестировании в конфигураторе, и кнопка пересчет бух.итогов в предприятии.

Как интересно :-)

А в ускоренной с помошью рам-диска 7.7 только один пользователь работал или как это было организовано?

(146) Это по желанию. У меня не было желания сажать несколько десятков пользователей на рамдиск, когда еще и сервер раз в Н месяцев вылетал (не от меня зависило). Ну а сам в рамках конфигурирования очень регулярно так делал, если было не лень подготавливать копию - оно же до ближайшей перезагрузки.

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

(148) ну так Злопчинский, скорей всего, имел ввиду, что при многопользовательском доступе по сети эффект от использования рамдиска не получится заметить

А вот в терминальных сессиях эффект заметный, когда оперативы в избытке :-)

(149) хм. Это удивительно, что 77 еще гоняют по сети. Конечно это будет узким местом. Я думал у всех уже давно терминалы. Надеюсь, там пересчет итогов делали не по сети?)

Появился вот еще какой дилетантский вопрос:
Решили мы ПОПРОБОВАТЬ вручную закрыть некоторые "висяки". Нашли 10 незакрытых (на 1.01.2016) балансов по 36.1. Создали операцию 1.01.2016 и позакрывали эти балансы в ноль. После этого посмотрели на 1сбкттл. Он вырос на 7 кБ. То есть, мы обнулили несколько балансов, которые висели с 1.01.2016, но обнуление не уменьшило 1сбкттл. Даже увеличило. Есть предположение, что либо я что-то не так понял, либо для того, чтобы был эффект от этого закрытия - надо сделать пересчет итогов.

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

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

(153) (152) у меня были похожие мысли

(151) конечно, после того, как вы что-то закрыли 01.01.2016, после этого надо пересчитать итоги. БУХГАЛТЕРСКИЕ!!!
и упаковать таблицы.

но, честно сказать (несколько у вас это сколько? пусть будет десяток). за 6 лет это 72 помесячные записи на каждый итог. на десяток 720 записей. пусть у вас свернулись все ПЯТЬ субконто (хотя вряд ли) (что такое баланс? в вашей терминологии)
итого - максимум 3600 записей.
сколько там у вас записей в таблице? к миллиону приближается? ну вот три тысячи из миллиона сократили.
или  0.3%
Капля в море.

БУХГАЛТЕРСКИЕ!!!

(155) зато научится понимать, что внутри происходит.

(152) ну, вообще то 27 релиз пользует "зеленые технологии" (то есть повторно использует помеченные на удаление записи), но фишка в том, что у него и так все таблицы максимально упакованы, то есть помеченных на удаление записей  особо то и нет, так что не разгуляешься.

(145) "значит Вы не то делали."
- расскажи что надо сделать, можно повторить...

(149) я хз, по сети у меня в основной компании никто лет 20 не работает, все в терминалке.

(158) Я не знаю, что Вы делали не то. Может временные файлы оставили на хдд. Как устанавливать рамдиск, Вы можете найти в интернете, я его не устанавливал лет 10. Относительно хдд прирост очень существенный.   Смотрите, если процесс 1св77 занимает не 100% от ядра при расчетах, значит значит упирается в дисковые операции, и на не достающие проценты ускорится при применении рамдиска.

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

(145) Когда прошлый раз делалось было нужно на вчера и так чтобы оно за выходной отработало. там по другому не сделать было в установленный срок и ограничения.
Вы перекосы за 16 год в 16 году закрыли или в текущем времени? Если в настоящем то все записи итогов так и должны были остаться если в 16 должно было бы уменьшиться только после того как их убрали нужно делать сжатие таблиц без этого она не уменьшится там просто записи пометились как удаленные и все.

(155) Я прекрасно Вас понимаю! Речь шла про эксперимент, который должен какой-то индикатор засветить. Конечно эти 10 сальдо - капля в море!!!

Я думаю, что это даже не 0,3%, а намного-намного меньше, так как бухгалтерские итоги (вроде) поквартальные и за год - это 4 итога, а не 12.

(161) перекосы  (10 субконто) закрыли 1.01.2016 года. Но сжатие (или пересчет итогов) не делал. Просто оценил размер файла 1сбкттл.

(151) если вы там реально что то закрыли в 16 году, то будут нулевые записи в табличке итогов за все периоды что после этой даты. Их или прибить прямым запросом и сжать табличку итогов потом, или делать пересчет бух итогов, и желательно, прибить 2 таблички бух итогов перед этим. Вот тогда, размер должен уменьшиться.

(164) я понял Ваш тезис, что остались нулевые записи после этой записи.

Но не понял - что значит "прибить прямым запросом". Но думаю, что специалист, который будет мне помогать, понимает о чем речь.

Спасибо за подсказку!

(165) "прибить прямым запросом" это типа
Удалить все записи в таблице итогов где значения всех ресурсов = 0

(166) Ага!!! Тогда это точно не я.))))


Вчера вечером удалил 1сбкттл дбф и сдх. Запустил реиндексацию и пересчет итогов. Реиндексация прошла за минут 15. А потом начался пересчет бухгалтерских итогов. И как в 23-00 зависло на дате 8.08.2017 - так до сих пор и висит.

"И как в 23-00 зависло на дате 8.08.2017 - так до сих пор и висит."
это просто строка статуса не обновляется, смотрите как размер дбф файла растет

(168) На современном железо и оси оно часто именно виснет
Мне приходилось в виртуалке на winxp/win2k3 это делать на 77

(169) занятно

(166) А какой смысл пересчитывать итоги не исправив косяк?
Всё ж сказали уже:
1) спец
2) Двинуть бух.итоги на начало периода (чтобы перезапись операций происходила быстро) - все спецы это знают
3) 20 строк кода: - спец без проблем справится
а) Опер.ВыбратьОперацииСПроводками(,'31.12.2021',"24,23"); - текущий год пусть будет корявым, может вам обороты по партиям дорогои
б) Если среди проводок операции есть проводки с 24 или 23 счетом и субконто (третье же?) "партия" заполнено - то зануляем субконто: Опер.Дебет/Кредит.Субконто(3,0);
в) Если в операции были зануления - то Опер.Записать;
г) Запись операций делать порциями 200-1000 штук в транзакции (опытным путём посмотреть, с индикацией скорости обработки в строке состояния);
4) Двинуть бух.итоги на конец периода (вот теперь после исправления косяков с незакрытыми итогами пересчет пойдет быстрее)
5) Для контроля строки состояния использовать ConfStat.exe и все спецы это знают - ничего там не виснет, просто строка статуса не обновляется в современных виндах.
Не надо никаких прямых запросов, это не RG-RA.

ЛИБО
Оборотное субконто - спец знает.

НО
Стоит же минимальный рефакторинг кода делать - завязано ли что-то в проведения документов или в отчетах на САЛЬДО по сч.24,23 в разрезе партий.
Всё.

Всем - по пирожку!

А злопы, которые экономили на спецах - должны страдать...

(171) Спасибо!
Это просто эксперимент, который крутится параллельно основному процессу. Запустил и кручу (заодно проверяю - не зависнет ли пересчет итогов).

Основной процесс будет такой:
Делать будет СПЕЦ. С одним из исполнителей уже договорено. Выбираю между вариантами, про которые Вы пишете. Есть ощущение, что сальдо на счетах 23 и 24 не дороги от слова "совсем". И, скорее всего, переделка проводок будет такая что ВСЁ будет сливаться на 23-й счет без субконто и оттуда - на 29-й (и тоже без субконто). Тем более, что я поднял архивную базу (до обрезки) и выяснил, что в самом раннем периоде и платники, и гарантии проводились через 23-й без субконто. 24-й использовался только для повторных ремонтов (2-3% от общего количества ремонтов). Как потом это распространилось на гарантийные ремонты - мрак, покрытый тайной.

А что такое рефакторинг кода в данном контексте (а то я имею только очень общее понимание этого термина)?

(167) а второй файл итогов оставили? Ну п..ц

(175) ))))) так я же дилетант. Вы уж извините. ))))

а что я забыл?

(175) поэтому я реальные задачи поручаю специалистам. Сам ничего не делаю кроме экспериментов на копиях.

(176)
1SBKTTLC Содержит рассчитанные бухгалтерские итоги оборотов между синтетическими счетами.
1SBKTTL Содержит рассчитанные бухгалтерские итоги остатков и оборотов по синтетическим счетам и объектам аналитики.

(178) Спасибо!!!

(168) Есть же специальные приблуды, чтобы читать статус когда 1с замерзает - я использую Abadonna'вский ConfMessages.
(169) Хм, у меня не виснет ни на 7-ке, ни на 10-ке, ни на 11, на самом современном железе - скорее падает, но не виснет никогда.

Я догадываюсь, как специалисты улыбаются, когда видят мои потуги что-то сделать. Но (как сказал Уважаемый БигБаг) только так я смогу лучше понять работу 1С (или меньше непонимать).

Провожу новый эксперимент на копии.

Начал вчера вечером.
0) переместил бухитоги на 1 кв 2016
1) Нашел и пометил на удаление операции, которыми на 1.01.16 создавались остатки на 24-м счету. Это был 351 документ по 100 строк в каждом (в последнем - меньше).
2) удалил 1сбкттл (дбф и сдх) и 1сбкттлс (дбф и сдх).
3) сделал полный пересчет итогов через (вот не помню - через конфигуратор или через меню переноса бухитогов)
4) сделал оборотку за 1 кв 2016. Убедился, что стартовое сальдо на 24-м - нулевое.
5) последовательно, по 2 квартала, двигал бухгалтерские итоги к 1 кв 2022 (копия - по 12.02.22) и наблюдал, как растет 1сбкттл.
6) файл 1сбкттл вырос до уровня 1234689 кб (тогда как в стартовой копии - 1792890 кБ). Разница - 558201 кБ.
7) сделал ОСВ за период 1.01.16-31.03.22 в исходной копии и в пересчитанной копии. Разница составила только по счетам 24 и 00 (на одинаковую сумму с разным знаком). Судя по всему, на ОСВ повлияло только отключение вноса остатков по 24-му счету.

Все это заняло время с 20-00 до 24-00.

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

Сейчас, утром, база продолжает считать. Но внизу висит сообщение "пересчет регистров". Посмотрел на 1сбкттл. Размер  1235053 кБ. (где-то подтянулось еще 400кБ). Последняя запись по файлам 1-С в 1:32 (ночи). То есть, с тех пор ни один файл не перезаписывался.

Предвижу замечание Уважаемого Злопчинского по поводу ранее леченных регистров.

Но у меня есть такое соображение:
Мне надо осознавать особенности того или иного пути решения. Для вас, профессионалов, они очевидны. Но не для меня. И то, что вы видите "между строк", - я не вижу. Вот я пытаюсь расширить свое понимание, чтобы осознаннее сделать выбор.

Сейчас я вижу, что ЛЮБОЕ решение по 24-29 счетам и файлу 1сбкттл не предполагает в будущем использования функции "полного пересчета итогов". Не смотря на то, что проводки по регистрам "вылечены" и не создают новых "хвостов", полный пересчет итогов все равно вернет "старые проблемы". Единственный вариант этого избежать - обрезать базу на 1.01.22. И уже в новой базе можно будет использовать полный пересчет итогов без риска "достать из архива" раздутые леченные регистры.

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

Еще раз - СПАСИБО ОГРОМНЕЙШЕЕ всем, кто помогает, и прямо или косвенно подталкивает к более качественному пониманию 1С, а значит и более качественному ее использованию.

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

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

Кому он там непроданных слонов-то продает?... Грустно это все, на самом деле.

И то, что база у него не с РФ расположением - в принципе, это видно по упоминаемым в обсуждении бух-счетам.

(184) дык он еще в прошлой ветке или еще где-то упоминал Винницу, вроде бы?

(183) >> Кому он там непроданных слонов-то продает?... Грустно это все, на самом деле.
ну, в Виннице все-таки не так, как в ДНР/ЛНР. Там все-таки обычная мирная жизнь. И дилерские автоцентры вроде как работают и вроде как что-то продают. И предпродажную и гарантийные ремонты осуществляют.

Мне вот, к примеру, в этой связи любопытно, автосалон Лада там в Виннице еще функционирует?

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

(182) (183) Это очень небольшой бизнес. По сути - не бизнес, а самозанятость (с коллективом). Это ремонт бытовой техники. "И будь проклят тот день, когда я сел за баранку этого пылесоса." Если бы я знал 17 лет назад как обернутся дела - я бы ни за что его не начал. Но уже ничего не изменишь. Буду доживать жизнь в этом проекте. Из-за того, что он неприбыльный, приходится многое делать самому. Из-за того, что он встроен в процессы больших производителей, он требует сложных (в том числе - IT) решений. Развивать его некуда. Поэтому все усилия направлены на поддержание. Вот такая ситуация.

(186) Про автосалон Лада не знаю. Не слышал. У нас был официальный дилер по Ладе (и мы у него купили в 2007 году нашу первую машину). Но в прошлом году там проезжал - там был пустая площадка (может переехали).

(182) И если говорить Вашей аналогией, то слон продается. Но не целиком, а кусками, на вес. Но тут весы могут сломаться. ;-)

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

"Неприбыльный бизнес" - это что-то новое ;-)
.
- привет, Вася!
- привет, Петя!
- Вася, я тут такой бизнес замутил, офигеешь!!! Продаю рубли по 90 копеек!
- ...??????!!!!!!
- что "????!!!", зато движуха дикая!

(188) "он требует сложных (в том числе - IT) решений."
- из того что видел, особо сложного в данном ИТ-решении не увидел. Что видно: видно что лепили на ходу, не продумывая толком. По принципу - "надо сюда галочку чтобы.." - нате вам галочку...

(181) Полный перечет итогов в конфигураторе - это полный пересчет бухгалтерских итогов и полный пересчет итогов по регистрам оперативного учета. Полный пересчет бухгалтерских итогов после обнуления 24 счета идёт относительно быстро и без особых проблем - не четверо суток. А вот полный пересчет итогов по регистрам Вам был запрещен в прошлом декабре предыдущим лечащим врачом - Злопчинским. Поэтому не
>>ЛЮБОЕ решение по 24-29 счетам и файлу 1сбкттл не предполагает в будущем использования функции "полного пересчета итогов".
А
ЛЮБОЕ решение по 24-29 счетам и файлу 1сбкттл никак не влияет на возможность использования функции "полного пересчета итогов"  - он Вам категорически противопоказан по причинам не связанным с бухгалтерским учетом.

Если есть возможность начать базу с чистого листа, зачем тогда вся эта тема?

(193) Исправить ОУ можно без заведения новой базы. Делать ли новую базу, это отдельный вопрос.

Для исправления ОУ делается обработка:

Считываются текущие остатки, они фиксируются в таблице документа коррекции остатков. Этот документ должен действовать по принципу, какие бы не были остатки до него, он их выправляет на остатки в его таблице. Но пока его не проводим. Если нужно много регистров, с разной структурой и много данных, то может имеет смысл это просто сохранять в файле в каталог базы, например с помощью ВК ValTable: http://telnov-vs.narod.ru/valtable.html

Теперь удаляем таблицы итогов ОУ и переводим ТА до самых первых данных.

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

Затем изготавливается еще один документ коррекции остатков, который проводится в каждом свернутом периоде, который будет сторнировать все движения месяца, что бы остаток на любой свернутый месяц был нулевым. Конечно свернутыми движениями. Если движений много, что ТЗ не тянет, то можно воспользоваться опять же ValTable. Сохранять в себе этот документ ничего не должен, просто считал движения месяца и записал итоговые сторно.

И затем обработкой двигаем ТА, и в конце каждого свернутого периода заводится док свертки, и в нужные периоды проведя документы корректировки остатков.

В общем, просто правильно организовать свертку базы.

Очень может быть даже, что в каких-нибудь архивах обработок можно отыскать подобное, т.к. операция существенно типовая.

(194) Вот меня ваабще не надо учить как исправлять ОУ. Во-первых, я в теме. Во-вторых, я люблю БУ и Расчет, а ОУ отвергаю. В-третьих, ТСу ОУ лечил Злоп год назад, можно с ним обсудить, как правильно надо было лечить ОУ. А в-четвертых, уже всё 100500 раз обсудили и в  этой теме, и в предыдущей.
Ну ладно, оставим тогда ТС осознавать особенности того или иного пути решения и экспериментировать, благо путей решения накидали десяток, экспериментов можно провести множество.

Спокойней, коллеги

Прошу вас не вводить политику в эту ветку.

(196) Извените, Вам только первое предложение. К остальному я забыл приписать (0) - типа это для ТС.

(199) Подумал что со смайликами будет старомодно ¯\_(ツ)_/¯, а без смайликов получилось грубо))

(194) "например с помощью ВК ValTable"
А почему не через Индексированную Таблицу 1С++?

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

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

(193) (194) (195) (196) (199) (200) Спасибо, Уважаемые Профессионалы! Главное - не ссорьтесь из-за меня. ))))

Я очень постараюсь переварить все то, что написано. И выбрать по возможности - самый правильный путь. Только прошу понять, что для меня это не все так очевидно, как для Вас и, как написал Уважаемый Харлампий Дымба, мне нужно осознавать особенности того или иного пути. И для этого требуется время. Но иногда и Ваши подсказки. Поэтому и задаю здесь вопросы (время от времени). Эти вопросы для Вас являются мелкими и незначительными. Но не для меня.
Еще раз извините за такую медлительность и примитивность.

А что тут понимать, у вас есть программист 1с пусть и низкой квалификации. Пусть он заходит и задает вопросы если хотите решить проблему его руками.
Хотите вылечить чужими вам зачем опять же в это вникать. Ставите задачу получаете результат. 1128753 кб финальный размер и пересчет бух итогов в конфигураторе работает. Вечером в пятницу прислали базу в воскресенье утром получили исправленную. Тестируйте проверяйте. Наводите потихоньку порядок силами своего программиста.
Вы же не лезете капиталку двигателя делать в своей машине обращаетесь к спецу и он все делает.

(203) Я в машине даже масло сам не меняю (хоть уровень посмотреть могу). Вот не мое это совсем. ))))

А по наведению порядка руками программиста - в чем-то так и делаем. Но он не самый активный человек в этой жизни + интраверт. Мне с ним нелегко. Но это мой крест. Не уверен, что он тут будет эффективно общаться. Он готов выполнять задачу. Но задачу надо поставить. А чтобы поставить - надо разобраться. Я ему предложил самому разобраться с 1сбкттл. Он развел руками. А когда я с ним обсуждаю - какие проводки надо подправить - он за это берется. Специфика.

(201) >А почему не через Индексированную Таблицу 1С++?

Я эту не смотрел, не знаю. А ту, знаю, что она с очень большими объемами умеет работать и быстро их сохраняет в файл. В поисковиках упоминается еще какая-то ValTable, но я так и не понял, это та же или нет.

(205) Пора, пора посмотреть на ИТЗ!