Я прошлый раз (по файлу 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 лет) такой пересчет не проводился.
Кроме того, в конце прошлого года "хирургически" резались некоторые регистры (и исправлялись некоторые проводки). При пересчете они могут опять "всплыть" (могут и не всплыть, так как проводки, все же, корректировались).

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

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

(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) Пора, пора посмотреть на ИТЗ!