Сразу предупреждаю: я не программист 1-С. Я ее пользователь. И все, что я делал - делал по советам программистов или по информации из форумов. Так что оценивать мой уровень знаний нет смысла ))) .
Прошу экспертное заключение профессионалов по моим действиям.

База 1-С Предприятие 7.7 АБТ 3 ПРОФ (3.5.4) (база ДБФ и переход на скул не предвидится).

Не переносится точка актуальности. Пишет ошибку записи в файл RG1051 и выбрасывает из базы. Файл достиг 2 ГБ.
Сжатие в конфигураторе (поиск и справление) не дало результата. Свертка не проводится - выбрасывает ошибку.

Поискал решение в инете. Нашел на этом форуме идею: "подрезать" вес регистров по остаткам.
В конфигураторе залез в Регистры-Остатки-Ресурсы и для двух ресурсов уменьшил разрядность. (все делаю в копии, чтобы не убить оригинал).
Для "Кво" было 13,3 - сделал 11,1
Для "СуммаГрн" было 13,3 - сделал 12,2.
Дальше - конфигуратор за 1 час внес изменения.
Результаты:
файл RG1051.DBF был 2 086 812 кВ стал - 2 012 283 кВ
файл RG1051.CDX был 387 664 кВ , стал 857 775 кВ

Запустил переиндексацию. Файл RG1051.CDX стал 387 664 кВ.
ТА перенеслась на 2 месяца.
Но не дальше. Потому что RG1051.DBF стал 2 091 957 кВ.

Потом подумал и еще раз уменьшил разрядность. Но уже по всем 5 индексам. Установил:
количество - 8,1
все остальные - 10,2
Опять же переиндексировал.
Теперь
файл RG1051.DBF - 1 898 258 кВ
файл RG1051.CDX - 402 617 кВ

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

Я понимаю, что это временное решение. Но теперь у меня есть время на нормальное.

Вопрос к экспертам - насколько я все сделал плохо? Не будет ли теперь проблем с работой базы?
Если это решение нормальное - то можно ли проводить в основной базе?

Буду признателен за быстрые ответы, так как до 1.10.2021 осталось совсем мало времени.

(139) ну хотя бы подрежутся по фирме "Сепециалист"

(142) Вариант с реанимацией, но опять копиться будут движняки
Надо дорабатывать базу - или вырезать эту "пустую" фирму в приходе или во внутрянке, в движениях, ее добавлять
Соответственнно логику поднимать - накой она там вообще такая

Чтобы это все нормально закрыть - это надо в весь процесс въехать, там таких регистров распухших - десяток

(144) ну да.

(145) Три регистра и таблица проводок

(144) пустая фирма, это типа УПР учет, "по всем фирмам в целом" - насколько я понял.

(147) остальные регистры не такие большие, но точно такие же распухшие.

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

(148) Никогда не понимаю этот "упр" учет реализованный через жопито
Убрать его нафиг а отчеты строить по всем юрлицам

(150) Рухнула по памяти на момен формирования таблицы выходной, за период 01.07.21 по 30.09.21 он 450к+ записей запросом прожевал у меня

(151) не, имеет смысл, сразу консолидированные данные получаются.

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

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

(154) не столь существенно. при нормальных записях движений позволяет легче всякие вещи получать, без вычитания межфирменных движений. то бишь можно и так и так. Вобщем с тобйо согласен, на моей памяти консолидированный учет по холдингу не пригождался. да и в типовых на 77 он после ТиС 8.7 отвалился, в 9.2 его уже не было.

(155) так решение то комплекское должно быть а не только по этому регистру остатков
надо шерстить логику работы базулины, править ее
приводить в порядок итоги по регистрам и накатывать обновление правленное

и фообще непоняоно по этому РГ1051. мне цвиамшуц показл больше 19 млн записей. ограничение вроде на 16 млн...

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

(158) там codebase движок, который 1с перезватила у не помню кого для управления базой 7ки после 16 млн уже не гарантирует работоспособность
а как оно там будет по факту ... может и на 17 свалиться и до 20 дотянуть

(159) Ну посмотрим сколько ТС готов отмусолить за ... ;)

из 19 млн записей в итогах тупо хирургически 7.6млн с колво=0

плюс надо смотреть какими доками этот регистр двигается на приход/расход.

(161) смотри, 500 тыс тебе, 400 тыс мне, за 100 тыс - немца наймем...

(164) Ништяк !

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

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

этот еще, с диванами, блин... УТ 11. Купили диваны...

блин, надо было эти пустые записи вырезку - базу на ссд положить...

(166) Забухали чтоль ? ))))))
Я в свое время писал обработку спецуевую и правил модули проведения, на момент лечения
Обработка тупо в файлы в raw выгружала движения документов, типа как файл обмена если есть риб, движения в файлах правились, и документы проводились считывая данные с файлов и формируя движения по ним
потом эта заглушка убиралась, оставалось дернуть ТА взад вперед

(169) ;DDD есть чем заняться в волвторого ночи

(171) не, заради интереса. ща пустые колва зарежу, потом эту пустую фирму.
бухпрводки по разделителю "Фирма" формируются.

(172) эммм ... щас так реанимируешь базу )))

не, все-таки клюшки - зачетная система.
ТиС 9.2 смотришь - ну блин все же понятно. код няшный.
даже тот же самый ПУБ в одной конторе был мне как-то раз попался - тоже в целом все понятно.

по уму надо вопрос с 400, 500 и немцем решить сначала

(174) ПУБ исковеркан по сравнению с Тисом, один общий ЖР что стоит с отборами

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

(175) хз, как воспримет это папаша Дорсетт ;-)

(174) у снеговика код лучше, но вот типовые....

Со всей это галиматьи хоть один плюс точно есть - я на рабочий стол себе Rainlendar повесил, давно собирался...

(179) Лучше - в смысле "больше" ;-)

(179) правда и в ТиС типовой есть ошибки, которые за 20 лет не поправили ;-) Одна из них - отчет по остаткам если включить показ остатков у комиссионеров- там кусок кода отсутствует для пересчета юазовые/основные (кривые цифры будут при задании отчета в основных единицах)

(182) клюшечные типовые никому в 1С не сдались... через несколько лет и УПП скоро снимут с поддержки.

Ситуация примерно такая. https://postimg.cc/t1m3pDfW. База не резанная с 2016 года. Обрезана с очисткой 0 количества или нет. Не знаю, видел только мдшник базы и остатки на сейчас. Не сильно вникая и разбираясь с логикой проведения для начала решил просто обнулить суммы там где количество = 0 стандартными 1с-ными методами.
Заполнил такой документ на 31.06.16. документ начал заполняться и проводиться в 20-30 успел он это сделать до 00 не знаю. в 22-30 еще что то считал.
Вижу как минимум, что еще можно схлопывать позиции типа яяя_щеткиремонт_221172 которые приходовались на склад платный, а списывались со склада платные услуги.
Непонятно почему так долго думает или сервак медленный или копия базы лежит на обычном винте, а не ссд.

ну, если тупо почистить записи где колво=0, как я выше описывал, то размер стал 1.2Гб

(185) правда я не особо представляю что при этом будут давать отчеты по остаткам/движениям (?), по идее д.б. все норм...

Плюс к этому остатки тупо жутчайше не закрыты по партиям, типовая картина
https://content.screencast.com/users/Che66/folders/Capture/media/ac977f6e-fb61-4daf-a58f-9d58c1e420fd/LWR_Recording.png
и это не только по группе "удаленные", это (бегло глянул) по всем так, приход на партию, списание с "кривой" партии "по умолчанию"....

(187) ну и сделай update таблички RA на партию по-умолчанию и пересчитай итоги, делов то, один хрен не пользуются партионкой

(188) Это типа комплексная база они там и бухию ведут, могут вести. Хотя если автор на вопрос можете назвать позицию по которой известен остаток говорит, что нужно провести инвентаризацию... То впечатление такое, что они там просто документы печатают и можно не только партии но и склады и фирмами на ноль помножить... сжатие до 1,2 метров даст им возможность спокойно доработать до конца года. А так в целом им нужен постановщик учета на месте который наведет порядки и расскажет, что и как нужно вести и отражать в базе. Основная проблема не в базе, а в том, что документы оформляются как хочется правой пятке.

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

Проводки по пустой фирме и фирмам настраиваются в базе константой и реквизитом в справочнике фирма. Аналогично партии до средневзвешенных сворачиваются. Но там есть нюансы если это делать заложенными в платформе механизмами за тронутся и взаиморасчеты. А там точно при любом учете нужно знать, что компания "А" холдингу должна 10 тыс. из них 3 тысячи фирме "Х" и 7 фирме "У". Реальные минуса ТМЦ в любом случае закрываются, надо просто пользователей заставить такие документы вводить не когда им хочется, а когда надо. Дав им инструмент помогающий с этим.

(136) Регистр Приемка вообще только в 1 документе используется и выполняется движение приход по нему. Внутри конфигурации отчетов по нему не увидел, может какие то внешние есть. Его тупо в оборотный надо переводить или удалять если нет отчетов по нему то смысл в нем, ну или эти отчеты поправить на оборотном регистре или тупо по 1 документу который его двигает отчеты строить. С учетом, что там у всех реквизитов длинна 1 уже поле 9 документа, по каким то ресурсам он уходит в переполнение и тупо отражает факт Приемки.

(192) Видимо недопиленная попытка вести учет принятого чужого товара

(184) >>Непонятно почему так долго думает

А что там непонятного? Помимо того, что сам код проведения может занять большое время, так ещё твое обнуление надо протянуть через ~60 последующих месяцев с пересчетом итогов по каждому из них. Это если у тебя период итогов "месяц", а если "5 дней" так и все 360.
Если уж типовыми средствами, то сначала ТА на документ лучше было двинуть.

(194) Потом его вперед все равно с пересчетом итогов за тоже самое время в наше время двигать.

(195) Да. Только руками - 60 пересчетов. А автоматом: 60+59+58+...=1770 пересчетов (или типа того). А вот что оптимальнее в твоем случае - это уж смотри. Я попытался объяснить в чем может проблема с долгим проведением.

А вообще возможны же неочевидные варианты: помимо периода итогов, неоптимального кода, железа, незакрытых регистров - есть ещё и галки "Быстрая обработка движений", "Отбор движений" и "Отбор итогов".
И, не знаю, как в ОУ, а у клиента было: 1000 проводок у документа "Начисление амортизации" записывалось за пару минут, а 10000 за 12 часов.

Чувствую все ограничится типа (185) и все. Думать некогда, трясти надо!

(197) Согласен. Или поднять на виртуалке 2003 сервак накатить на него 2000 скл. и базу в скл переделать и забыть. За оставшиеся 36 часов до начала нового месяца, править логику проведения и разобраться как оно должно быть при нормальном учете проблемно.

(198) с учетом что за 10 лет не поправили - провести рефакторинг за оставшиеся 3 месяца - маловероятно.

...база ДБФ и переход на скул не предвидится
---------------------------------------
...То есть, вопрос не в деньгах.
========================================
Точно?

(200) Вы думаете там лицензионный софт, очень сомневаюсь. 1с может и покупали если внедрял кто то из принципиальных франей, винда очень сомневаюсь. У нас лицензионный софт скорее редкое исключение чем правило.

Хотя возможно когда то была попытка и из-за не ровного кода не взлетело.

(161) (175) (175) (200)


1. На бесплатно я не рассчитываю.
2. Прошу написать Ваши предложения на почту.
3. В предложениях прошу дать пару вариантов на выбор по цене. Причем, учитывая Ваш высочайший уровень профессионализма, я понимаю, что полное лечение мне может быть не по зубам (а может даже и частичное).
4. Из всего, что Вы написали, мне почти ничего не ясно (да и не должно быть ясно, наверное), но обращу внимание на то, что у нас партионный учет и мы от него пока не готовы отказаться, так как это требование партнеров. Мы отслеживаем какую запчасть (из какой партии) установили в конкретный ремонт.
5. Насколько я понимаю наш учет - у нас нет "многофирмовости". Расчетных счетов разных ФОПов-ООО - да, несколько, но весь этот учет (как я уже писал) - в первую очередь CRM-ка. И у нас нет процессов, где мы анализируем движения по разным ФОПам-ООО. Только деньги заходят по разным расчетным счетам, чтобы видеть в базе актуальные остатки на счетах. Все остальное - единый процесс и привязки к конкретной фирме в учете - не нужны.
6. Поскольку я не мог рисковать, я уже скорректировал индексы Кво и СуммаГРН. И мы работаем в такой базе. Перенос ТА сделал на 30.11. Поэтому времени немного есть. Буду искать компромиссное решение по сложности, правильности, срокам и бюджету.
7. А также, понимаю, что этим РГ1051 вопрос не ограничится. Поэтому буду рассматривать варианты решения и по другим регистрам.
Скорее всего - поэтапно (поскольку не Газпром и не Сбер).

Жду Ваших предложений (или отказа - как Вы решите). Только очень прошу - дайте знать, чтобы я понимал - чего мне делать дальше.
Спасибо.

С Уважением, ТС

(203) "4. Из всего, что Вы написали, мне почти ничего не ясно (да и не должно быть ясно, наверное), но обращу внимание на то, что у нас партионный учет и мы от него пока не готовы отказаться, так как это требование партнеров. Мы отслеживаем какую запчасть (из какой партии) установили в конкретный ремонт."
.
нету у вас никакого партионного учета судая по отчету по остаткам с разворотомпо партиям. М.б. какие-то товары комплектующмие вам партионка не нужна, поэтому такая кривизна. Выискивывать в отечте наобум где норм, где криво (а по моему беглому осмотру криво ВЕЗДЕ где есть расход) - так себе удовольствие.

(203) "Из всего, что Вы написали, мне почти ничего не ясно"
- что именно неясно, например. из того скрина по отчету по партионке , что я опубликовал?

(203) "5. Насколько я понимаю наш учет - у нас нет "многофирмовости...".
а зачем у вас в справочнике фирм заведеноа куча фирм (причем каких-то физиков)..?

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

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

Поэтому лично у меня только одно предложение - оперативно купировать проблему - обрезать внештатно заведомо кривые данные по остаткам по регистру RG1051 (с ним более-менее понятно). Это даст время - если вам будет нужно - разбираться со всем ворохом проблем.

"..обрезать внештатно заведомо кривые данные по остаткам по регистру RG1051" - как я сделал в (185)

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

ну и судя по чисто интерфейсным вещам - формы документов выглядят ужасающе - вряд ли стоило ждать что внутри будет что-то аккуратное ;-)

проще всего перейти на sql и не мучатся

(213) угу.
а там или ослик умрет или падишах сдохнет

Обрезать как в (185) - возьму с учетом потраченного времени здесь и на тест - 200$.

Я сейчас перечитаю что Вы написали и попробую осознать (сквозь истерику внука ))).

А сейчас - просто информация.

Это какая-то жесть!!
Я посмотрел историю запчастей яяя_щетки_218191 и яяя_щетки_213731.  
Получается, что даже если пересорта по складу или партии нет, то в регистрах СуммаГрн и СуммаОсн остается НЕНУЛЕВОЙ остаток. И такой остаток возникает при КАЖДОЙ отгрузке. (регистры Кво и СуммаБезНДС - закрываются нормально).

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

Сейчас осознАю Ваше предложение. )))) Спасибо за него - в любом случае.

(215)
Еще раз - спасибо за предложение!
Сумма вполне подъемная. И, в принципе, можем сойтись на этом варианте.

Но хочу кое-что уточнить (сорри за дилетантизм, но прошу понять).

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

И если я правильно понял, есть, как минимум, 3 причины почему это происходит:
1) Наши сотрудники косячат и выбирают не ту партию. То, что разрешены отрицательные остатки, очень этому попустительствует. Эта проблема у нас известна давно и я вижу что нет другого пути, чем запретить отрицательные остатки. Это достаточно частая проблема, но это больше ошибка, чем правило.
2) Наши сотрудники косячат и выбирают не тот склад. Также связано с разрешенными отрицательными остатками. Но есть и другая причина. Замечено, что при выборе неосновного склада в Расходной накладной происходит следующее: По бухучету запчасть списывается со склада, указанного в накладной, а по регистрам, почему-то, она списывается с основного склада. Эта проблема чуть менее частая.
3) Самая большая проблема, что при КАЖДОЙ отгрузке запчасти на платный ремонт (есть ее гарантийный) в индексах СуммаГрн и СуммаОсн подменяются данные. В результате: индексы Кво и СуммаБезНДС закрываются нормально, а в индексах СуммаГрн и СуммаОсн происходит накопление (на сумму наценки, по ходу). И это - не ошибка сотрудников. Это такой код написан. Почему - сложно сказать. Но ведь, если было получено 100 тыс деталей и потом отгружено 100 тыс деталей (на платный ремонт), то получается, что на каждой отгрузке
возникает запрограммированное накопление на двух индексах.

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

У меня теперь есть такие вопросы по варианту "185" (ну, если тупо почистить записи где колво=0, как я выше описывал, то размер стал 1.2Гб)
1) почему останется так много (1,2Гб)?
2) Это значит, что все ненулевые остатки останутся в том же состоянии? (со спрятанными внутри незакрытыми накоплениями)? В том числе по позициям, в которых общее количество равно 0, но есть пересорт по партиям и сами партии ненулевые?
3) Как будет происходить процесс физически? Сколько времени он займет? При условии, что доступа на сервер нет и мы можем действовать только так: я архивирую базу, кидаю Вам, Вы фиксите проблему, архивируете базу, возвращаете мне. Если успеваем - я заливаю ее в актуальную директорию на сервере. Так можно? за 1,5 дня выходных (пол-субботы-воскресенье до 23:59) успеем? Вы работаете в выходные?



Для справки: Партионность у нас отслеживается не по учету, а в реальности. То есть: мы берем на складе запчасть, которая пришла по конкретной партии и ее же списываем по учету. Так делается не со всеми запчастями, но с бОльшим их числом. Так как нам на запчасть дают определенную гарантию. И в случае проблемы с этой запчастью устраиваются разборки. При разборках поднимается информация о партии.
Кроме того, некоторые бренды ведут у себя партионный учет (внимание!) НАШЕГО СКЛАДА. И мы в их учете (имеем доступ и обязаны) выбираем партию для запчасти, которую списываем. Поэтому вынуждены у себя в учете списывать ту же партию. Чтобы наш учет и учет бренда был синхронизирован по партиям.

Осознавать это не обязательно. Просто я не могу отказаться от партионного учета. (((

(216) "(регистры Кво и СуммаБезНДС - закрываются нормально)"
.
в большинстве случаев - да.
но у вас есть и отрицательные остатки по количеству, они тоже зависают незакрытыми (скорее всего таких мало и это некритично, т.е. это проблемы собственно не самого учета а дисциплины учета, или где-то мелкий косяк)
.
СуммаБезНДС - толде не всегда закрывается корректно (по беглому осмотру - в большинстве случаев - норм, но есть и кривые).
.
плюс к этому есть суммы зависшие в размере 0.001 - это уже конкретно косяк алгоритма.

(217) Для исправления, нужно создать с нуля цепочку документов -  весть процесс: приёмка-че там у вас еще- расход/выбытие. дЛя одной детали/одного склада/одной партии.
на примере этой цепочки исправить код модуля проведения этих доков.
Затем прибить итоги и движуху и перепровести базу. Усё.
И оно само станет как надо.
+исправить доки ввода останков от прошлой обрезки, выкинув лишнюю аналитику и зависший мусор

(216) "Им присваевается значение отпускной суммы из Внутренней Расходной Накладной. И по этим регистрам появляется плюсовой остаток "
- об этом я написал выше.

А кастрировать - это половинчатое решение, на пол года- два..

(217)
п.1 запретит работу без контроля остатков. иначе вы никогда не поймете - вот есть отрицательный остаток - это ошибка или так надо. работа с запретом "не контролировать остатки" - это всего лишь вопрос административно-организационной дисциплины и воли руководства. Выстраивается и лечится достаточно быстро. У меня (в онлайне) обычно на это уходит где-то неделя (с учетом того, что сами алгоритмы работают правильно). Т.е. включается нормальный режим работы. и все. ни вот сеголдня чуть-чуть, завтра -чуть-чуть, воттут вот срочно один раз можно без контроля - нет, так не катит. работать сразу правильно постоянно. Всё. Проблема исчезает. И это параовозом за собой тянет улучшение в связанных процессах.

(217)
п.2 - можно сразу сказать что это ошибка программы. но кто вас знает какие принципы у вас в процессы заложены, может так и надо/был такой замысел, только его не доработали? итого: - как выше я и другие писали - нужен нормальный рефакторинг/пересмотр/просмотр процесов и исправление алгоритмов. и нормализация работы. По тем объемам движенйи которые есть у вас - база у вас до гигабайта не дотянет СУММАРНО. а у вас там дестяток гигабайт. имеено из-за расхлябанности учета.

(217) п.3 - аналогично как п.2 - надо смотреть и понимать/разбираться что у вас задумано было, как оно должно быть (на ваш взягля) и править/делать как надо.

+219 ваш размер базы, перепроведётся весь, за пару часов, или меньше, если все регистры будут правильно закрываться

(217) "1) почему останется так много (1,2Гб)?"
- потому что вглубь не смотрел. 800 МБ - это заведомо неправильные данные, обнаруженные одним взглядом по которым понятно что их не должно быть (должен быть ноль). еще как минимум половина из оставшегося, а может и больше исчезнет, когда будет выправлен партионный учет (см. мой скрин). Плюс к этому еще куча уйдет когда будет исправлено движение по расходу по торговому учету (приход по торговоум есть, по расходу по торгвооум нет - но это навскидку осмотрено было - смотрите осбужденяи выше)

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

(217) "Как будет происходить процесс физически?"
как и происходил, даже базы скорее всего не понадобится. Обрезка по (185) будет сделана достаточно быстро. да, я работаю тогда когда это надо. и полтора дня мы тянуть не будем. Починим оперативно. С этим регистром проблема временно будет снята.
А дальше - как писал я про рефакторинг и как пишет здесь и сейчас Ёпрст - если вам нужно будет приводит в порядок чтобы это всегда работало нормально - это уже все отдельно, это другая работа, потому что там куча всего неприятного, все как писал я и Ёпрст.

(217) "Для справки: Партионность у нас отслеживается не по учету, а в реальности....."
Партионку сейчас не трогаем. Потому что то что вы говорите - это нормально, но то что я видел в базе - это не соответствует тому что вы говорите (возможно ясмотрел кривые варианты ну вот так на них попал почему-то, просто тупо потому что без обрезки мне дажне не удалось получить ваш штатный отчет по остаткам до партий - прога тупо падала из-за нехватки памяти, поэтому я взял часть котоая подвернулась под руку и смотрел по ней - а поней все криво. скорее всего криво и по остальным). Поэтому надо разбираться. Как я выше написал чтобы вы протянули всю цепочку обслуживания по какому/либо материалу/запчасти по партионному учету начиная с прихода и заканчивая полным списанием с торгового баланса. (Епрст в принипе чуть выше то же самое написал).

(217) Вполне возможно, что по основному массиву учета ваших запчастей партионка норпмальная, но это надо смотреть и это отдельная задача.

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

Общий процесс "рефакторинга" описан учитиелем (да продлятся его годы на благо клюшечников) в (219)

(219) (225)

понимаю всю правильность и согласен с таким подходом. Но есть 2 "но": 1 - бюджет, 2 - негде взять еще полгода жизни. Так как кроме меня никто в этом разбираться с программистом не будет. Но, вполне возможно, через какое-то время напряги попустят и я смогу этим заняться. Я на прошлую обрезку потратил месяца три на осознание и сотрудничество со специалистом. А тут задача явно покруче. Хотя... может я ошибаюсь.

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

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

(222) (223) (224)
согласен с идеологией. Но до этого надо дозреть и по времени, и финансово. Я даже не понимаю бюджета этой задачи (даже если исправлять только баг№3).

(227)
понял

(228)
не понял. Что значит не нужна база? А как же резать? Сорри, я дилетант и не понимаю.

(236) нужен один файлик, его и "порежем".. ;-)

(135) (136)

подскажите, пожалуйста, если это бесплатно: каким отчетом смотреть регистры? А то у Вас так красиво видно состояние регистров....

REGPRINT.ERT

ЛУЧШИЙ ВЫХОД ПЕРЕХОД В SQL

(240) Эстонец ?

Да порезал я ему в декабре ещё если не раньше, там с этого регистра пшик мизерный в итоге остался, плюс он сам с прогом по подсказкам поправили ошибки алгоритма и убили контур упр. Учёта. Там конфига наподобие тис 8.7. Нормально у него всё должно быть, повторно не стучался