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

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

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

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

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 а не на последний документ, и регистры остатков по номенклатуре товаров не верные после этой даты.
Каким образом можно пересчитать эти регистры, не проводя сами документы?
Двигать ТА в ручную через "Управление итогами" - не пересчитывает