Есть обработка, которая из ГМ запускается по расписанию 1 раз в час. Сохраняет в CSV остатки товара для дальнейшей выгрузки в интернет-магазин.
На форме есть элемент список, в котором склады, по которым получаем остатки.
Почти всегда отрабатывает штатно:
Процедура ПриОткрытии()
    Если Форма.Параметр="ЭкспортНочью" Тогда
        ВыбСклад.УдалитьВсе();
        ВыбСклад.ДобавитьЗначение(константа.ОсновнойСклад);
        ВыбСклад.ДобавитьЗначение(константа.Склад1);
        ВыбСклад.ДобавитьЗначение(константа.Склад2);
        ВыбСклад.ДобавитьЗначение(константа.СкладТранзит);    
        ЭкспортВсехТМЦ();        
        СтатусВозврата(0);
        конецесли;
КонецПроцедуры

но раз в несколько дней или в неделю, остатки получаются не по всем четырём складам, а по двум или по одному.
Т.е. в процедуре добавление значений както не отрабатывается.

И получаем большую проблему, что в магазине после глюка не полный список товаров /или вообще пустой/

Чтото никак не могу понять, где искать проблему.
http://prntscr.com/q4kl1q

Кие-то блокировки на _1sconst?

Вообще - лучше один раз в глобальную переменную (знаю, что зло) при начале работы системы зафигачь этот список и не дёргай базу лишний раз

Както влияет не может, что у меня есть для этой формы разные настройки ?
http://prntscr.com/q4kqgd

(2) А еще можно прямым запросом с nolock дергать

почему не один список складов ?

в ЭкспортВсехТМЦ() запихнуть при начале выполнения перечень складов из СЗ с указанием времени в ЖР. потом смотреть.

Раз сохраняет в CSV, то может и список ВыбСклад в лог вывести.
Если действительно пропадают, смотри в ЖурналеРаботы кто эти Константы дергал.
Я при подобных выгрузках жестко зашиваю параметры через ЗначениюИзСтрокиВнутр, и таких чудес становится значительно меньше.

(7) А в СтрокуВнутр - где делаешь?

(8) В параметрах обработки пишу "Регламентное", по Регламентому заполняю все отборы на ЖЕСТКО зафиксированные параметры.
Это потому что вот с такими приколами, однажды взяли и слили вообще все продажи не тому поставщику.
Ну... вреда то особо не было, и никто ухом даже не повел, но решил для себя - "фиксировать параметры жестко".
Не так много времени занимает такое заполнение, меняется редко, обычно НЕ универсально.
Поэтому больше не рискую полагаться в таких вещах на пользователей.

(9) "на ЖЕСТКО зафиксированные" - где-то в константах хранятся или в настроечном справочнике каком-нить?

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

(5) не совсем понятен вопрос

(6) ЖР - это?

(13) Журнал Регистрации штатный

еще в ЖР писать имя пользователя 1С под которым выполняется обработка

В справочнике складов сделать флаг "Выгружать в инет-магазин". Или хранить настройки в внешнем файле. Как вариант.

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

(0) Ок, это нормальное поведение программы.
Когда у вас возникают ТРАНЗАКЦИИ, то 1С-ные (черные) запросы, некорректно возвращают данные, т.е. вообще не возвращают :)

Переходи на прямые запросы, там этого нет, используй 1С++, в качестве бесплатного интерфейса. А то SP... RG.... и RA... трудно воспринимаются человеком :)

+(0) Ты хоть людям код запроса покажи, им многое станет ясно :)

+(0)Версия 1С, SQL или DFB?
Объем базы?
Объем файлов БД? (интересует таблица регистра, на котором вертятся остатки по складам)
Объем документооборота за СУТКИ (примерно 10000 док. или сколько там у вас)?
Количество строк в одно запросе?

>>> Количество строк в одно запросе?

Количество результата, по одному из складов (нужен максимум)

.... Нам нужно больше данных, для анализа вашей ситуации :)

+ (0) Есть только предположение:

1. У вас файловая версия БД.
2. Файл остатков по сладу уже превысил 1 Гб, уже близок 2-ум или вы воспользовались расширением для файлового варианта БД :)

(19)
    ТекстЗапроса =
    "с ВыбКонПериода по ВыбКонПериода;
    |Обрабатывать НеПомеченныеНаУдаление;
    |Склад = Регистр.Остатки.Склад;
    |Остаток = Регистр.Остатки.Остаток;
    |Сумма = Регистр.Остатки.Сумма;
    |ТМЦ = Регистр.Остатки.ТМЦ;
    |Ед_изм_ = Регистр.Остатки.Карточка.Владелец.Ед_Изм;
    |Функция ОстатокКонОст = КонОст(Остаток);
    |Функция СуммаКонОст = КонОст(Сумма);
    |Группировка ТМЦ без групп упорядочить по ТМЦ.Сортировка, ТМЦ.Наименование;
    |Группировка Склад без групп;
    |Условие(Ед_изм_ <> Константа.ЕдИзмНеПроводимая);
    |Условие (Склад в ВыбСклад);
    |Условие (ТМЦ в ВыбТовары);";

(22) Да, файловая БД.
Размеры файлов:
http://prntscr.com/q4vffs

(20) Документооборот очень маленький. В сутки 50-100 документов по 10 строк

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

Давно уже нужно резать базу, но всё никак руки не доходят.

(18) "Когда у вас возникают ТРАНЗАКЦИИ, то 1С-ные (черные) запросы, некорректно возвращают данные, т.е. вообще не возвращают"
__________
Вот на это может быть похоже.
Нужно будет помониторить этот момент.

(24) дык, эта - бухитоги почти джва гига (ой-ой!), а проводки четверть гига - что-то очень криво не закрывается у вас по итогам. и смотрю дбфки видятся как адвантейджевские - зойчем вам ADS? - в смысле - а не hogik'овская ли ADS-вундервафля это?

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

    |ТМЦ = Регистр.Остатки.ТМЦ;
    |Ед_изм_ = Регистр.Остатки.Карточка.Владелец.Ед_Изм;

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

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

(29) "и смотрю дбфки видятся как адвантейджевские - зойчем вам ADS? - в смысле - а не hogik'овская ли ADS-вундервафля это?"
_______________________
хотелось бы понять это предложение. Можно его попроще? )

(31) "в базе - итого - бардак ;-)"
не спорю, 15 лет назад её создавал, варясь в собственном соку. думаю ошибки допускал не только здесь

(33) ошибки в (0) - из-за незакрытых регистров и бух итогов.
Там всегда будет ошибка по чтению. Можно конечно, от hogik поставить временную заплатку и ошибка уйдёт, но это не выход. Нужно закрыть все остатковые регистры и файло итогов по счетам

(32) http://catalog.mista.ru/public/all/?st=t&sort=postsd&public-filter%5Bsearch%5D=Advantage
третья сверху

http://catalog.mista.ru/public/15577/

если что, временно поможет только это.

А так, следующий период, уже не откроется , скорее всего.

по бухии, так точно

пока тьфу-тьфу ещё открывается. в этом месяце обязательно займусь.
по закрытию итогов БУ: как быстро и правильно найти в базе этот самый бардак?
тупо руками просмотреть остатки по счетам в разрезе субконто? и найти те счета, которые не закрыты корректно?

правильно ли я понимаю, что корректное закрытие остатков в следующем периоде не исправит предыдущие "излишки" данных?

и ещё вопрос: если закрытие остатков идёт уже ПОСЛЕ открытия периода - это не правильно? Закрывать итого нужно ДО открытия периода или это не важно?

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

и это г..но летит из периода в период

В регистрах - аналогично, по некоторым наборам измерений нет закрытия, смотрится отчетами и глазками

Правильно ли я понимаю, что закрытие счетов ПОСЛЕ открытия нового периода ничего не даёт и нужно закрывать остатки именно ДО открытия нового периода?
Если есть желание чтобы объём базы не рос

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

для быстрого удобного просмотра остатков можно юзать либо типовые отчеты конфиги (что не всегда удобно) или универсальный отчет по регистру (из ИТС). Если и это сложно то можно взять готовый http://catalog.mista.ru/public/14794/
https://www.screencast.com/t/AEmtCM1uzEgG
https://www.screencast.com/t/sDSXXYC4
на последнем скрине четко видно что регистры незакрыты - общий итог "в куче"=0, но по фирмам висят взаимоперекрывающиеся остатки. Такой вариант очень широко распространен как причина незакрытых остатков (контроль остатков "по компании в целом" а дальше - пофиг)

(0) Сохраненные настройки формы могут перебивать  настройки в ПриОткрытии()

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

(47) не знаю, может я с восьмёркой путаю.
Но в 7.7 мне кажется как то пришлось использовать послеоткрытия() от формекс для исправления похожих косяков.

(48) мне кажется, путаешь...

(46) Вот и я предполагал о такой возможности. Но странно, что это происходит 1 раз из 50ти

(44)  "в общем случае пофиг. закроешь остатки после открытия нового периода - они закроются ДО открытия нового периода+1"
____________________________
так в том то и дело, что практически каждый месяц 1го числа нужно открывать новый период, а бухгалтер ещё работу по закрытию месяца не сделал / сложно это делать вечером 31го/
Вот и получаем что каждый новый месяц остатки накапливаются

не "тьфу-тьфу"-кай.
без kernel3x у тебя УЖЕ ЛЮБАЯ ОБРАБОТКА ВЫБОРКИ ПРЕРЫВАЕТСЯ если кто угодно в это время "неожиданно" пытается получить из базы (или положить в нее) что угодно.
не веришь - сделай следующее: запусти длинный отчет (длинную выборку) - а любым вторым пользователем в это время запиши что угодно. обработка выборки в этот момент "тихо" оборвется.
выводы относительно правильной оценки остатков при проведении чего угодно - сам сделаешь?..
режб до менее 1Г - и до тех пор крестись чтобы ни приыеди будда никакое файло не вылезло за 2Г - потому что тогда никакой кернел не поможет.

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

сворачивай, закрывай, режь. СРОЧНО.

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

(52) Принял. Спс. Уже работаю над свёрткой базы.
В планах сделать так: создавать на требуемую дату два документа "Остатки по бух счетам" и "Остатки по регистрам"
Далее расспровожу все документы до этой даты.
Далее удаляю табличную часть этих документов.

Вроде самый простой способ?
Это необходимой минимум.

Дополнительно ещё в ыслях: создать новую пустую базу и в неё выгрузить всю базу которая получилась. Чтобы избавится от всяких ошибок в dbf файлах /битые ссылки и т.д./.  Это не помешает?

(50) лабуда. более чем уверен. ищи ошибку в чем-то другом.

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

(56) У меня самописная конфа. В ней только два регистра остатков ТМЦ

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

физически всего 3. использую реально только два:
http://prntscr.com/q632nt

все 3 регистра - регистры остатков

При таком количестве документооборота - база до таких размеров лет 5-7 должна расти, а то и больше. у меня на порядок больше и то - основным затыком файлы документов а не регистров.
возьми по ссылке отчет по регистрам или универсальным отчетом по регистрам - посмотри остатки по всем измерениям, у тебя что-то КАРДИНАЛЬНО не закрывается имхо (может конечно и ошибаюсь). если что - могу и помощь оказать - все таки две головы лучше чем одна - позырим вместе, вдруг что увидим.
Разверни на картинке регистры остатков по измерениями и ресурсам

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

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

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

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

(59) покажи измерения этих регистров.
План счетов, тоже самописный ?

(61) база с 01.01.2005

(61) http://prntscr.com/q65vgv (63) план счетов был взят типовой

не развернул реквизит: http://prntscr.com/q65xc1

(62) "документы лучше делать по каждому регистру свой, т.е. тип регистра выносить в шапку, значит их будет на два, а больше...
заранее предусмотреть в регистрах очистку от ненужных (зависших) записей...."
____________________________
пытаюсь понять, но не доходит.
Мои регистры остатков ТМЦ двигаются табличной частью документов. Шапка документа к ним отношения не имеет.
Партия=Карточка

(62) "и делается так: сначала заполняются документы свертки, записываются, потом отменяется проведение всех документов до свертки, проводятся свертки, перепроводятся от созданных сверток до сейчас, потом уже можно помечать на удаление и чистить....."
______________________________________
со всем согласен, только не пойму, зачем перепроводить от даты свёртки до сейчас?
Рисковая это операция - тотальное перепроведение

(0) сколько ща зп у хоккеистов?

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

(61) "посмотри остатки по всем измерениям, у тебя что-то КАРДИНАЛЬНО не закрывается имхо (может конечно и ошибаюсь)"
__________________
Толком не могу понять, что в этих остатках может не закрываться. Это ведь обычные остатки на складах в разрезе Склад/ТМЦ/Карточка.
Если товара нет на остатке, то и по регистру он будет нулём.

(67) ты хочешь свернуть только три регистра, а остальное все оставить?
сколько у тебя остатков в каждом из регистров? общее количество строк в документе сколько будет?

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

(70)+: а, ну и бух.итоги правильно будет - аналогично как ТА двинуть: вернули взад - сформировали документы свертки - отменили проведение всего что до документов свертки - провели документы свертки - двинули на место ТА и вернули на место период БИ.

(68) мое дело предложить, твое отказаться)))) я после свертки всегда восстанавливаю последовательность....


(71) не все что нет на остатке, в регистре будет нулем... тем более при наличии 4 ресурсов...

(74): "восстанавливать последовательность" не то же самое что "перепроводить".
перепроведение меняет движение, восстановление последовательности возможно без пере-проведения (и это в данном случае - правильно!)

(72) Нет. Я удалю все документы например до 01.01.2017
База полегчает раз в 5-7

(75) не соглашусь, что "это в данном случае правильно", на мой взгляд правильно - перепровести, т.к. кроме свертки регистров, их надо чистить от висящих хвостов...

(76) и сколько строк ты планируешь в одном документе? )

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

(72) "проще отладку делать и исправления вносить, когда один регистр - один документ..."
______________
у меня так и есть. Второй регистр специфический - Сукарточка = "подчинённый справочник карточки". это есть серийный номер канкретной карточки - используется редко /например приём на гарантии, где мы указываем конкретный серийник партии/

(78): ты так говоришь, как будто побить на порции подокументно - невозможная вещь и все итоги надо непременно в один док.свертки пхать...

(79) "Будь готов, что от удаленных документов в документы сверкти попадет туева хуча незакрытых итогов"
______________________
Это как?
На 01.01.07 я просто получу остатки товаров на складах. Откуда  там не закрытые итоги?

(78) "и сколько строк ты планируешь в одном документе? )"
Остатки ТМЦ на конкретное число это копейки. Ну пусть 3000 строк

(81) я говорю в (62): "документы лучше делать по каждому регистру свой"
бить каждый регистр на документы - смысла не вижу...


(83) я предупредил... дальше дело твое )))

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

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

(85) (62)
Я просто не могу понять вашу мысль по свертке итогов.
Мой план такой: на 01.01.2017 получить в разрезе складов, ТМЦ и карточек  остатки товаров и создать например через документ "Инвентаризация" остатки на это число.
Я не понимаю, откуда тут возьмутся ненужные (зависшие) записи?
Остатки товаров - это ведь реальная вещь. В базе нет не правильных остатков

(86) зная твою конфу, я бы не был так уверен это раз...
а во вторых, Инвентаризация создаст партией себя, нет?

+87, а что будет с Резервом?

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

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

(85): ... и перекосили нахрен итоги и иобороты в уже закрытых периодах... ну маладес чо...

(65) Карточка и СубКарточка - какого типа измерение ?

И что в них хранишь ?

(92) справочник партий товаров

(91) но остатки ведь не с листика а из регистров будут читаться . Не должно быть перекоса.

В Созданном документе инвентаризация ведь будут по факту реальные ставки на 1 января они будут проверятся с бумажными и после этого будет понятно что обрезка прошла правильно

(91) что молодец я и так знаю...

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

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

потому для свертки, не используют документы типа вводОстатков и/или инвентаризация/оприходование....

(99) Инвентаризация не будет делать партией себя.
В моём документе Инвентаризации /или создадим новый тип документа, это не важно/ вводятся ТМЦ и карточки /элементы справочников/. И при проведении данного документа /по теории/ он должен получить остатки по регистрам на 01.01.2017 такиеже, как они есть сейчас .
Это я так предполагаю

(100) ну смотри сам ))))

http://prntscr.com/q67l54 как то так

(101) Так что смотреть то ? ) Практики у меня нет. Теорию я высказал. Теория не правильная? Или по практике будут какие-то нюансы? Какие?

(103) сделай на копии и посмотри )

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

не тереби гондурас.
давай я тебе дам универсальный двигатель регистров - им свертку с ходу делается как заполнение остатками. заполняешь остатками. потом распроводишь все документы до свертки. помечаешь на удаление. все что не используется - удалится. те что не удалились - висят в ссылках где-то - их тупо оставляешь (от них скорее всего шапка только нужна будет).
.
если есть возможность - заверни базу со всем необходимыми для старта базами ВК в архив, на файлообменник, ссылку и пароль - мне в скайп Zlopun или на мыло [email protected]. Посмотрю мельком на регистры на выходных.

(105) стопудово там незакрытые

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

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

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

Это не сильно страшно. Все зависит от частностей. Избыточность обычно для ускорения. А регистры - проведение - узкое место. При проведении для получения например партий по номенклатуре расхода тебе нужна будет номенклатура итогов чтобы фильтр наложить - как ты без номенклатуры в регистре фильтр положишь на регистр?

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

Я так мыслю

(108) у вас именно так ти есть: приход по одним наборам измерений, расход по другим.
Если смотреть в разрезе склад-номенклатура, то на остатке 0, если в разрезе карточек, то +N-количество и -N-количество

и в остатке...типа 0

а на самом деле, вы эти + и - из периода в период тащите с каждым открытием.

Это всё наглядно видно, если просто выгрузитьИтоги.

(114) чуток не так.
Злопчинский подсказал его скачать /спасибо/.
Он сразу показал проблему: у меня Измерение есть "СуммаДок". По приходу это себестоимость а по Расходку - это уже сумма с наценкой.
Естественно при списании всего количества на этом товаре по остатку остаётся прибыль.

Я до позавчера вообще не задумывался о необходимости закрывать регистры /про балансовые счета ещё акто знал, про регистры вообще не думал/

Злопчинский подсказал скачать отчёт "Универсальный отчет по регистрам". Да -  по нему сразу всё стало мне понятно.
Буду анализировать и исправлять минусы структуры

Выход или себестоимость вообще выводить в отдельный регистр, или закрывать её в конце месяца

Вот: http://prntscr.com/q6gmo9
Ну и с Измерением "Резерв" нужно тоже поработать. Его реализация у себя мне никогда не нравилась. Сейчас какраз и егопроанализирую

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

(118) У вас нет ИЗМЕРЕНИЯ суммаДок, это ресурс. Если что, остатки есть только в разрезе измерений.

А свои СуммаДок перенесите в реквизит регистра

и всё.

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

и резерв туда же, по ним не нужны остатки

(123) да, опечатка
(126)  чтозначит "прибить табличку итогов" ?

(126) я так понимаю после изменений структуры регистра "пересчёт итогов" не сильно уменьшит размер dbf файла?
Просто по нему уже остатков станет в тысячи раз меньше чем на сейчас. Верно?

(129) Уменьшится размер RG. Размер RA не изменится.

(128) del rg*

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

Чтоб 1с-ина не занималась реструктуризацией, на такой базе она может и не закончится.
Потом подменить словарик и мд, прибить файло итогов и сделать пересчет итогов.

Ну и с бух иттогами смотреть оборотку.. там поди, такая же петрушка

на 41 поди ад и израиль (хотя в Белоруссии, там свои счета)

Да, как-раз о них сейчас думаю
1SBKTTL.DBF = 1959 Мб
есть вероятность в декабре не закрыться? и что тогда делать? сейчас уже тчото можно предпринять?

(135) 41й и в РБ 41й )
Да, не исключаю, хотя в теории должен закрываться. Сейчас гляну

Хотя скорее себестоимость проблемная:
http://prntscr.com/q6h6xf
она закрывается всегда уже ПОСЛЕ  открытия нового периода

Документ.. что в это субконто пишется при приходе и при расходе ?

и покажите 41 счет как выглядит в плане счетов

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

(139) Тот документ, который создаёт провдки
(140)  http://prntscr.com/q6hja0
41й счёт создан не в конфигураторе, а в базе. Это не критично?

(142) Выкиньте это субконто к едрени фени. ОНО и так ВСЕГДА есть в операциях.

(141) Больше волнует что сейчас предпринять, чтобы в декабре закрыться. Над свёрткой базы работаю, но если 31.12.19 не закрыться, она будет с большего бесполезна.
Сейчас пока на копии делаю: Выгрузить данные/Загрузить данные.
Затем - "тестирование и исправление"

документ движения и так есть в операции и в проводках, не нужно под него отдельное субконто, у вас НИКОГДА счет не закрывается из-за этого.

(143) Понял )

(144) свёртка для такой мелкой базы нафик не нужна, нужно исправить то, что есть

(147) И dbf файлы сами уменьшаться ? После какой операции? Перепроводить все документы - очень не хочется. Итоги 100% изменяться - очень сложно будет их потом сводить

Можно еще не 41 счете выкинуть субконто ТМЦ, ибо себестоимость в разрезе ТМЦ у вас дублируется в регистре.
При проведении , в 41 -90 пихать тупо общую сумму, без деталицации по ТМЦ (для бухов, это более чем достаточно)

И ваших проводок, будет кот наплакал, а база при проведении/перепроведении будет летать, и за ночь будет перепроводится вся, за всё время.

(148) перепроводить не обязательно при этом

(145) "документ движения и так есть в операции и в проводках, не нужно под него отдельное субконто, у вас НИКОГДА счет не закрывается из-за этого."
о каком счёте речь?
если по себестоимости: 46.3.2, то в нём Документ - есть "расходная накладная" и по дебету и по кредиту.
Пока не вижу по какому счёту Субконто "Документ" не закрывается.
А к нему я привык, удобно в стандартных отчётах "Журнал ордер по субконто" смотреть прибыль в разрезе документов

дбф ну в разы уменьшаться, rg и файло итогов по счетам должны быть намного меньше чем ra и 1sentry

(152) 46

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

(152) да-да-да.. в приходе у вас там Поступление по дебету и кредиту, а в расходе Расходная накладная, у вас не вызывает это когнитивный диссонанс ?

(154) 46й счёт у меня закрывается. И по документам тоже. Другой вопрос - что уже после открытия периода.

(156) нет. 46й счёт двигается только Расходом. Приходные накладные ен меняют себестоимость. Поэтому по 46му и в ДТ и в Кр толкьо расходная наклданая.
Тут всё ок

(157) как оно может закрываться, если субконто РАЗНЫЕ ?

(159) Они не разные. Ранее в ответе (142)  я ошибся.
По 46му счёту в Субконто Документ пишется всегда только расходная накладная. и в ДТ и в КР

Поэтому я пока не нашёл проблемное место в проводках. По логике, все счета закрываются более менее нормально /висящих долгиграющих остатков пока не нахожу/.
41й счёт товары, всегда списываются, в разрезе Склад/ТМЦ. тут никаких карточек нет. и с этим сётом более менее ок. Ну пусть 5000тыс позиций на конец каждого месяца в остатке. Это наверное не много.

46й счёт себестоимость в разрезе Отделение/Документ/Пользователь - этот счёт закрывается после открытия периода. Может это приводит к критическому росту?

Пока не совсем понимаю, как найти проблемное место по проводкам

(161) не, 46 явно самодельный счет, да ? Еще и количественный

каки проводки по нему и какие документы делают ?

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

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

Выгрузка загрузка данных ожидаемо не изменила размер dbf сейчас запустил полное тестирование и исправление за исключением нижней птички

(164) как это не количественный? - на картинке стоит +

а вижу, валютный..

http://prntscr.com/q6ivem
да

ТиИ не поможет

только зря время потеряешь

на 46 .. у тебя у субконто, хоть выставлены галки - "только обороты " ?

особенно у субконто Документы

(172) нет. как же я буду остаток получать и перекидывать его на Прибыль?

(174) :)

какой остаток, если по логике, там только оборот ?

(161) Скачай 1sqlite с консолью, и выполни

SELECT
ACCS.SCHKOD
,BKTTL.DATE
,BKTTL.SC0 [Субконто0 :Субконто]
,BKTTL.VSC0 [Субконто0_Вид :ВидСубконто]
,BKTTL.SC1 [Субконто1 :Субконто]
,BKTTL.VSC1 [Субконто1_Вид :ВидСубконто]
,BKTTL.SC2 [Субконто2 :Субконто]
,BKTTL.VSC2 [Субконто2_Вид :ВидСубконто]
,BKTTL.SD [Сальдо :Число.15.2]
,CURRID [Валюта :Справочник.Валюты]
FROM __1S_BKTTL AS  BKTTL
LEFT JOIN __1S_ACCS ACCS ON ACCS.ID=BKTTL.ACCID
WHERE BKTTL.DATE > :НачДата
AND BKTTL.OBDT1+BKTTL.OBDT2+BKTTL.OBDT3+BKTTL.OBKT1+BKTTL.OBKT2+BKTTL.OBKT3 = 0
AND BKTTL.KIND IN(1,2,3)
ORDER BY BKTTL.ACCID,BKTTL.VSC0,BKTTL.SC0,BKTTL.VSC1,BKTTL.SC1,BKTTL.VSC2,BKTTL.SC2,BKTTL.KIND,BKTTL.DATE
LIMIT 10000

Полистаешь результат и увидишь, где у тебя не закрывается. Примерно вот так будет:

https://gyazo.com/2a75b91d0975c202f19fd9e9e39ac921

(176) по детебету пришла себестоимость товар. в момент списания спсиываем по кредиту дороже. на счёте остаётся остаток - наша прибыль.
этотостаток мне важен и его легко и удобно подучать в стандартном отчете ЖОС в разрезе отделений/менеджеров/документов

(178) ты ж говорил, что только документ Расходная накладная пишет туда проводки, не ?

(179) По дебету 46го счёта пишется приход (46<-41) =100руб
Расход пишет по кредиту 46го (62<-46)=120 руб

на 46м остаётся остаток 20 руб, который является заработком. Вот это и есть результат работы, который мне нужен и который в конце месяца закрывается на прибыль /в разрезе отделений, сотрудников, документов/.

Насколько я понимаю, этот счёт не может быть только оборотным из-за этого

(180) и 20 руб потом каким документом закрываешь ?

(181) в конце месяца обработка закрывает все остатки по 46му счёту на счёт прибыли

http://prntscr.com/q6nuge

(170) Прикол, но после Выгрузки и загрузки а затем ТиИ dbf файлы похудели /кроме проводок/
http://prntscr.com/q6nxbf

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

(124) О! точно!
получится оборотные продажи\прибыль

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

(185) у него там основные файл регистров - 1084 и 100 МБ и 870 и 32 мб (итоги-движения) в исходно базе, так что если закрыть все как полагается там всего-ничего будет

(187) в скайп выйди

(187) прибыль по сторуднику? это что за новхав?

(127) не факт. зависит что и как сделано

(155) " Но так уж есть, чтото по регистрам идёт, чтото по проводкам"
наоборот должно быть. Первичный учет - оперативный, он обычно на регистрах. Вторичный - бухгалтерсикй, он или паралельно с формированием по регистрам идет или по данным регистров отдельно..

(190) ну как нохав. Менеджер продаёт товар, приносит прибыль. От суммы прибыли зависит его зарплата

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

Начал пробовать обрезать базу по проводкам через WRAP.ERT
И вылетает ошибка:
http://prntscr.com/q71gs3

Хотя бух итоги свернулись до 03.06.2020 и только следующая свёртка выдавала ошибку

(195) через  WRAP.ERT нужно сделать только Операции по начальным вводам остатков.
Всё остальное там заремить или сделать Возврат.
Документы метить на удаление прямым запросом, операции и проводки удалять тоже.

Хотя бух итоги свернулись до 30*.06.2020 /вродебы, помню что несколько раз открывал период, помоему дваждый получилось а на 3й раз затык/.
В обработке пробовал "удалить документы" - ошибка выше на скрине
если "удалить проводки" - выдало ошибку кода , помоему "не уникальный код операции", - нужно будет с эти разобраться ещё

Сейчас пробую 3й вараинт "сделать не проведёнными документы"

(196) Понял, буду пробовать

(196) там возможно уже предел по размеру файла проводок или по количеству записей. и любая запись в проводки - уже аут. я не помню как там врап работает что создает и куда пишет.
.
если не получаться будет то можно попробовать так - тупо сделать документ ввода нач.остатков по БУ. счет-ск1-ск2-ск3-сумма-количество-вал.сумма. Заполнить остатками. не проводить. Кильнуть документы-проводки, сжать таблицы и потом тупо провести документ ввода остатков.

(196) Что-то не хочет WRAP.ERT у меня работать на этой базе:
http://prntscr.com/q7b2vv
При этом на похожей по структуре базе, но существенно меньшего объёма - всё работает /в том числе и если делать только по одному счёту а не по всем/.
Как-то мне сомнительно, что обработка не может создать операцию по свертке одного счёта из-за большого размера базы

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

(24) База на издыхании.При такой таблице Ra работа идёт только вашем честном слове.Режьте базу немедленно.

(200) тебе ЕПРСТ то же самое что и я в (199) говорит.
сначала готовишь данные для свертки. не проводишь - потому что не влезут. убираешь лишнее (что уже в данные для свертки пошло). сжимаешь таблички обязательно. Проводишь подготовленное.

(201) В копии апрельской базы таже самая ошибка. А после этого было две свёртки бух итогов. Значит дело дело не в файле итогов?

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

Разобрался. Ошибка идёт на попытке удаления документов

Не понимаю, что может быть, обычный код:
Процедура УдалитьПроводки2()
        Документ = СоздатьОбъект("Документ");
        Документ.ОбратныйПорядок(0);
        Документ.ВыбратьДокументы(ДатаНач, );
        Пока Документ.ПолучитьДокумент() = 1 Цикл
            Документ.СделатьНеПроведенным();
            Сообщить(Документ+"  "+Документ.ДатаДок);
        КонецЦикла;    
КонецПроцедуры

http://prntscr.com/q7ho7w
иногда справляются с первыми 5-10 документами и потом ошибка вываливалась.
Сейчас уже ни одного документа не может распровести /и удалить тоже/

п.с. Руками удаляется и распроводится

Таже проблема и на базе 2017 года, в которой файл проводок 1,2Гб:
http://prntscr.com/q7hq3z

Щас буду гуглить, как прямым запросом удалять документы

(208): ня. http://1cnik.by/reducefile1sbkttldbf.php

(210) Я думал то уже прямой запрос ), а что полезного в статье?

Выше писал, Выугрузка/Загрзука и далее ТиИ - не изменело файл БИ

(208) Извиняюсь, на базе 2017 года WRAP вроде работает, чуток запутался в копиях

(207) Попробуй подменить dbeng32 на этот: https://cloud.mail.ru/public/4iqh/2i5FfEoDX
Я до 4х гигов раздувал dbf`ки. Насколько корректно будет работать в твоем случае я не в курсе.
Но Wirth писал эту штуку и проверял на тех файлах, когда стандартный движок уже падал.
Прямой ссылки увы, уже нет, и даже в архиве интернета ничего не сохранилось.

(214) дбф не может быть физически больше 2 гигов по стандарту.

И там уже, не дбф- ки будут

(214) Спасибо, дождался вечера и попробовал. Процесс распроведения пошёл, ошибок вроде нет

На вот.. развлекайся

https://cloud.mail.ru/public/3pdW/4QnZKFKqQ

скачать только надо vfp oledb
http://www.microsoft.com/download/en/details.aspx?id=14839

да, после удаления, удалить все rg*, 1SBKTTLC,1SBKTTL,*.cdx
зайти монопольно, пересчитать итоги (двигая та взад вперёд)  и бух итоги (через меню операции- пересчет итогов)

И это, если созданы доки ввода остатков, лучше их создать не на дату удаления, а то и их прибьёт.
ЗЫ: доки можно как прибить насовсем, так и пометить на удаление (пометка быстрее, ибо не удаляются шапка и ТЧ доков)

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

Занимайся, вроде, все вспомнил

(220) Спс, принял. Вроде и dbeng32.dll (214) помогло удалять доки, но после создания операций остатков запустил ТиИ и всю ночь выполняется, до сих пор не закончилось.
Сейчас параллельно и вашу обработку буду пробовать

(215) Так то по стандарту, а в движке от Wirth вот так вот: https://gyazo.com/622763c039b65907291289f4c9ec1206
Но, да vfp и аналоги уже не прочитают. Не уверен, вроде avantage такие dbf должен открывать.

(221) Перед ТИИ rg* удалил?

(223) Тупанул - нет. Но например над позавчерашний копией ТиИ выполнялось 1-2 часа. Возможно созданные остатки стали лишней каплей

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

И если 1С не в терминале, dbeng32 от 1С назад вернуть не забудь. Этот, дополнительно еще и пропатчен на отключение сброса файлового буфера, по сети будут чудеса. У меня он больше 5 лет стоит - проблем не было. Ну и патч Ромикса на загрузку процессора при транзакции с ним тоже не нужен. Могу не пропатченный выложить, если понадобится.

(225) Помоему да, позавчеар я перед ТиИ сначала сделал Выгрузку/Загрузку. Может поэтому прошло ТиИ быстро.
1с - в терминале.

[Ну и патч Ромикса на загрузку процессора при транзакции с ним тоже не нужен. Могу не пропатченный выложить, если понадобится."]

не знал про этот патч.
vk_TerminalSleep.rar - сейчас скчал, буду знакомится. Там без нюансов ? - и его желательно поставить?

(225) [Ну и патч Ромикса на загрузку процессора при транзакции с ним тоже не нужен]
Вроде понял мысль, при использовании нового "dbeng32.dll" патч от Ромикса не нужен? Блокировок процессора с новым dbeng32.dll и так не будет?

Т.е. если у меня 1с работает в терминальных сессиях, то я могу оставить новый dbeng32.dll навсегда?
Или лучше не рисковать?)

(227) Я же писал, 5 лет стоит. Причем и на линуксовке с wine@etersoft и на еще 2х конторах с виндой. Проблем не было.
Wirh писал, что делал движок под микроскопом, т.е. в двух базах проводил одни и те же действия, а потом бинарно сравнивал dbf и cdx.
Так что оснований подозревать этот движок в больших багах, чем стандартный, у меня нет.

Ещё параллельно вопросик: пусть у меня счёт 60 "Поставщики" ведётся в разрезе двух субконто: Контрагент и Документ. Сейчас я понял что в учёте могу обойтись без второго субконто и было бы не плохо от него отказаться.
Но база действующая.
Каких-то простых способов решения нет?
Если его тупо удалить - то придётся все документы перепроводить, что очень не хотелось бы.

Ну и тогда ещё один, ранее задавал но так и не получил ответа:
Очень часто свёртка итогов по балансовым счетам происходит уже после открытия нового периода, а значить уже свормированы в БИ "излишние" остатки в разрезе субконто.
Решение этой проблемы только одно? - закрывать остатки по счетам ДО открытия периода?

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

(213)+: есс-но "закрепить его ..." для каждого контрика - и код проведения по взаиморасчетам "подпилить".

(230): не парьте мозги. в периоде - никаких удалений. надо подправлять - формируйте бух.операцию (сопровожнайте бух.справкой). "аудиторский след" - наше всё!

(231) понял.
(232) "код проведения подпилить" - да, в классической конфигурации проще. Мне будет сложнее, логика проведения у меня не в конфигураторе, а в 1с через справочники, придётся заморочиться, чтобы для каждого документа создать новую логику проведения по счёту 60 ( и остальным где нужно убрать Субконто2 = Документ)
(233)  либо я не понял либо меня. Пусть есть счёт себестоимость - в разрезе трёх субконто, по нему очень много итогов. Его на конец периода нужно свернуть по остаткам, /остатки перекинуть на синтетический счёт/, тогда при открытии нового периода остатков по бухитогом будет не много.
Если же открывать новый период ДО свертки остатков - остатков будет много лишних на счёте себестоимость. И свёртка их задним числом при открытом новом периоде не исправит ситуации в плане излишних данных в dbf файле бухитогов.

(228) Странно, на изменённом dbeng32.dll обычная операция создания документа на основании /или некоторые другие операции/ - вываливается 1с. /на родной dll такое бывает раз в 5 дней/. Вернул родную dll  - всё ок.

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

(234): тю. ну засуть в финальный документ закрытия месяца эту байду со сверткой аналитики.

(235) Действительно странно, у меня никогда такого не было.
Ну главное что помогла свернуть базу...
А что из ВК подключено? И в какой последовательности? Может что-то вклинивается?

(236) у меня самописка: http://prntscr.com/q7tzzx
(237) да, нужно будет написать перед свёрткой
(238)
    Попытка
        ЗагрузитьВнешнююКомпоненту("1cpp.dll");
        Сообщить("Компонента 1С++ загружена!");
    Исключение
        Сообщить("Пытались, но не загрузили компоненту 1С++ :(");
    КонецПопытки;    
    Путь = КаталогИБ() + "TurboMD.dll";     ЗагрузитьВнешнююКомпоненту(Путь);    
    Путь = КаталогИБ() + "FormEx.dll";

после подключения 1cpp.dll вылеты стали чаще, примерно раз в 5 дней

(238) [Ну главное что помогла свернуть базу...]
___
Да, база вроде сворачивается, прямой запрос от Ёпрст по удалению доков - тоже быстро отрабатывает.

Теперь остаётся перед окончательной свёрткой навести порядок - посворачивать в итогах висящие, не закрыте не нужны остатки (тот же второй субконто Документ по счетам 60/62)
И тогда можно будет финально обрезать базу

(239) А версии то какие? У меня 1с++ 3.2.4.3, formex 2.0.5.147, TurboMD.dll не использую.
Видимо вылеты из-за нее, хотя судя по отреверсированным исходникам она не лезет в dbeng32.
TurboMD.dll точно отсюда? http://www.1cpp.ru/forum/YaBB.pl?num=1160630298/0

(241) TurboMD.dll - по версиям одинаковы. http://prntscr.com/q7un7f
1с++ 3.2.2.0 http://prntscr.com/q7unmr
formex 2.0.5.101 http://prntscr.com/q7uo1e

(242) На 3.2.2.0 много всяких проблем http://www.1cpp.ru/forum/YaBB.pl?num=1281717242/0
Особенно эпичен глюк при свертке тз!!!
Лучше меняй на 3.2.4.3 http://www.1cpp.ru/forum/YaBB.pl?num=1332077808
Там только усовершенствования и багфиксы, ничего поломаться не должно.

Очень похоже на системный глюк Винды. Попробуй осмыслить ее работу. Там несколько параметров.

(244) В винде несколько параметров? Это точно?

Нашел хоть, по каким счетам не закрывается в разрезе субконто ?

(246) 60й и 62й . ведутся в разрезе Клиент Документ
Их в разрезе документов - не закрываю . Нет смысла. Изначально Документ был не нужен.

Вроде остальные "большие" счета закрываются

"Вроде" - потомучто сложновато сделать анализ, какой процент объёма данных в файле 1SBKTTL.DBF занимает каждый счёт за эти 16 лет эксплуатации базы.
Да и не нужно сильно.
Подправить план счётов - это да, можно /но не уверен что буду делать, не очень хочется в одной базе иметь разные структуру плана счетов/.

(248) А что тут сложного то? Это легко выясняется.

SELECT
ACCS.SCHKOD Счет
,count(*) Счетчик
FROM __1S_BKTTL AS  BKTTL
LEFT JOIN __1S_ACCS ACCS ON ACCS.ID=BKTTL.ACCID
GROUP BY ACCS.SCHKOD
ORDER BY ACCS.SCHKOD


(248) анализ - осв по счету с разворотом по всем субконто.

(247) ну дак вырежи документ оттуда и свертка не нужна будет

и в регистрах поправь, как раньше писал.. делов то

(251) Удалить субконто можно. Но тогда либо перепроводить документы с 2017 года - что не хочется. Либо будут какието битые ссылки? /сейчас попробую/

(250) понятно что стандартным отчётом можно в разрезе субконто просмотреть не закрытые итоги. Это не сложно.
Сложнее выяснить, есть ли какойто счёт (счета), который кардинально виноват в размере dbf файла 2Гб.

Сейчас я не знаю, либо это счета 60 и 62 , по которым второе субконто не закрывались никогда, либо более емкйи счёт 46й /себестоимость в разрезе ТМЦ/ Отделение Пользователь Товар.
По этому счёту я закрываю каждый месяц - но уже После открытия периода.

Скорее всего в большей степени росту БИ способствует именно 46й счёт /хоть по факту они и закрыт/, чем не закрытые 60 и 62

Но повторюсь - выяснять какой счёт максимально виновен в 2Гб - не очень важно. Вырезав из базы 14 лет и соатвим только 2 года - проблема забудется ещё на 10 лет.
А если план счетов оптимизировать - то и на всегда

Не могу чтото разобраться. Пусть например я по счёту 60 убрал в плане счетов второе субконто.
По идее рассчитанные итоги должны стать меньше. Каким образом ужать файл 1SBKTTL.DBF ?
Пробовал в 1с "полный пересчёт итогов", не помогло: http://prntscr.com/q9a2fu

(254) Теперь оттуда нужно удалить "нулевые" записи и сжать таюличку, если не умеешь, то или выгрузка загрузка (что долго) или тупо удалить 1SBKTTL и 1SBKTTс и пересчитать бух итоги

(255) http://prntscr.com/q9cm8m
Даже базу можно не резать. По 62му счёту удалил второе субконто Документ /которое не закрывалось и которое мне ненужно/ и после выгрузки-загрузки dbf стал 320Мб

судя по файлу проводок, что-то еще не закрывается

итоги должны быть меньше чем 1srntry

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

Тот же 411 счёт, остатки по ТМЦ для меня важны только по регистрам. Возможно по проводкам коегде не верно списывается количество и на остатке повисает, и изза них растут итоги.

(259)в этой ветке 2 раза выкладывали код с решением, там примитивный запрос и сортировка, через sqllite

(261) Като сомнительно, что запрос (а не глаза) может отловить "не правильные" остатки.

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

Ну а дальше, да, уже "глазами" разбираться надо. Запрос покажет "где", но не объяснит "почему".

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

Нужно ли этим заморачиваться, если ТиИ выдаёт такие ошибки: http://prntscr.com/q9osvt
Наверное они не критичные?

(265) всего лишь есть дубли по id в этих справочниках

перенести, можно этим, например..http://catalog.mista.ru/public/102101/
только, зачем ?

Режу базу на 01.01.18. Всё ок.
Но проблемка: после данной операции, ТА стало почему-то на 01.01.2020 а не на последний документ, и регистры остатков по номенклатуре товаров не верные после этой даты.
Каким образом можно пересчитать эти регистры, не проводя сами документы?
Двигать ТА в ручную через "Управление итогами" - не пересчитывает