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

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

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

Чтото никак не могу понять, где искать проблему.
http://prntscr.com/q4kl1q
169 evgpinsk_
 
05.12.19
13:06
170 Ёпрст
 
05.12.19
13:14
ТиИ не поможет
171 Ёпрст
 
05.12.19
13:15
только зря время потеряешь
172 Ёпрст
 
05.12.19
13:25
на 46 .. у тебя у субконто, хоть выставлены галки - "только обороты " ?
173 Ёпрст
 
05.12.19
13:25
особенно у субконто Документы
174 evgpinsk_
 
05.12.19
13:27
(172) нет. как же я буду остаток получать и перекидывать его на Прибыль?
175 Ёпрст
 
05.12.19
13:56
(174) :)
176 Ёпрст
 
05.12.19
13:57
какой остаток, если по логике, там только оборот ?
177 Djelf
 
05.12.19
14:00
(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
178 evgpinsk_
 
05.12.19
14:18
(176) по детебету пришла себестоимость товар. в момент списания спсиываем по кредиту дороже. на счёте остаётся остаток - наша прибыль.
этотостаток мне важен и его легко и удобно подучать в стандартном отчете ЖОС в разрезе отделений/менеджеров/документов
179 Ёпрст
 
05.12.19
14:19
(178) ты ж говорил, что только документ Расходная накладная пишет туда проводки, не ?
180 evgpinsk_
 
05.12.19
17:31
(179) По дебету 46го счёта пишется приход (46<-41) =100руб
Расход пишет по кредиту 46го (62<-46)=120 руб

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

Насколько я понимаю, этот счёт не может быть только оборотным из-за этого
181 Ёпрст
 
05.12.19
17:48
(180) и 20 руб потом каким документом закрываешь ?
182 evgpinsk_
 
05.12.19
17:49
(181) в конце месяца обработка закрывает все остатки по 46му счёту на счёт прибыли
183 evgpinsk_
 
05.12.19
17:50
184 evgpinsk_
 
05.12.19
17:56
(170) Прикол, но после Выгрузки и загрузки а затем ТиИ dbf файлы похудели /кроме проводок/
http://prntscr.com/q6nxbf
185 Ёпрст
 
05.12.19
17:59
(184) нет там никакого прикола, всего лишь нулевые итоги с табличек ушли и сжатие таблиц сделало тии.
Вот только, это можно было сделать за 5 минут простым запросом и без тии
186 Злопчинский
 
05.12.19
21:04
(124) О! точно!
получится оборотные продажи\прибыль
187 evgpinsk_
 
05.12.19
21:10
(186) мне прибыль желательно в бухгалтерском учёте видеть, а в регистрах придется добавлять и отделение и сотрудника
188 Злопчинский
 
05.12.19
21:15
(185) у него там основные файл регистров - 1084 и 100 МБ и 870 и 32 мб (итоги-движения) в исходно базе, так что если закрыть все как полагается там всего-ничего будет
189 Злопчинский
 
05.12.19
21:16
(187) в скайп выйди
190 Злопчинский
 
05.12.19
21:24
(187) прибыль по сторуднику? это что за новхав?
191 Злопчинский
 
05.12.19
21:30
(127) не факт. зависит что и как сделано
192 Злопчинский
 
05.12.19
21:34
(155) " Но так уж есть, чтото по регистрам идёт, чтото по проводкам"
наоборот должно быть. Первичный учет - оперативный, он обычно на регистрах. Вторичный - бухгалтерсикй, он или паралельно с формированием по регистрам идет или по данным регистров отдельно..
193 evgpinsk_
 
05.12.19
21:53
(190) ну как нохав. Менеджер продаёт товар, приносит прибыль. От суммы прибыли зависит его зарплата
194 Злопчинский
 
05.12.19
22:02
менеджер не продаст существенно отклоняясь от рыночной цены. и почему моя зарплата менеджера должна зависеть от того что сейчас акция и продаем товар на -20% ниже. и почему моя зарплата менеджера должна зависеть от того, что закупы такой закуп делают что прибыль на нем мизерная? далее эту тему развивать не будем тут холиварили в свое время знатно.
195 evgpinsk_
 
06.12.19
13:09
Начал пробовать обрезать базу по проводкам через WRAP.ERT
И вылетает ошибка:
http://prntscr.com/q71gs3

Хотя бух итоги свернулись до 03.06.2020 и только следующая свёртка выдавала ошибку
196 Ёпрст
 
06.12.19
13:13
(195) через  WRAP.ERT нужно сделать только Операции по начальным вводам остатков.
Всё остальное там заремить или сделать Возврат.
Документы метить на удаление прямым запросом, операции и проводки удалять тоже.
197 evgpinsk_
 
06.12.19
13:13
Хотя бух итоги свернулись до 30*.06.2020 /вродебы, помню что несколько раз открывал период, помоему дваждый получилось а на 3й раз затык/.
В обработке пробовал "удалить документы" - ошибка выше на скрине
если "удалить проводки" - выдало ошибку кода , помоему "не уникальный код операции", - нужно будет с эти разобраться ещё

Сейчас пробую 3й вараинт "сделать не проведёнными документы"
198 evgpinsk_
 
06.12.19
13:15
(196) Понял, буду пробовать
199 Злопчинский
 
06.12.19
13:20
(196) там возможно уже предел по размеру файла проводок или по количеству записей. и любая запись в проводки - уже аут. я не помню как там врап работает что создает и куда пишет.
.
если не получаться будет то можно попробовать так - тупо сделать документ ввода нач.остатков по БУ. счет-ск1-ск2-ск3-сумма-количество-вал.сумма. Заполнить остатками. не проводить. Кильнуть документы-проводки, сжать таблицы и потом тупо провести документ ввода остатков.
200 evgpinsk_
 
06.12.19
23:58
(196) Что-то не хочет WRAP.ERT у меня работать на этой базе:
http://prntscr.com/q7b2vv
При этом на похожей по структуре базе, но существенно меньшего объёма - всё работает /в том числе и если делать только по одному счёту а не по всем/.
Как-то мне сомнительно, что обработка не может создать операцию по свертке одного счёта из-за большого размера базы
201 Ёпрст
 
07.12.19
00:24
(200) ясен пень, видать созданый документ операции провести пытается и естественно болт, ибо файло итогов в пределе. Надо править врап, чтобы она только создала файлы операций и все, без их проведения. Потом удалить проводки и операции по условию, сжать таблички и провестм операции по вводу остатков.
202 bolder
 
07.12.19
00:35
(24) База на издыхании.При такой таблице Ra работа идёт только вашем честном слове.Режьте базу немедленно.
203 Злопчинский
 
07.12.19
04:56
(200) тебе ЕПРСТ то же самое что и я в (199) говорит.
сначала готовишь данные для свертки. не проводишь - потому что не влезут. убираешь лишнее (что уже в данные для свертки пошло). сжимаешь таблички обязательно. Проводишь подготовленное.
204 evgpinsk_
 
07.12.19
09:26
(201) В копии апрельской базы таже самая ошибка. А после этого было две свёртки бух итогов. Значит дело дело не в файле итогов?
205 evgpinsk_
 
07.12.19
09:32
Да дело не в нём. Сейчас более внимательно буду изучать, что обработка делает.
п.с. даже для мелкого счёта 01 /у которого аналитики очень мало/ всё-равно вываливается
206 evgpinsk_
 
07.12.19
11:58
Разобрался. Ошибка идёт на попытке удаления документов
207 evgpinsk_
 
07.12.19
13:43
Не понимаю, что может быть, обычный код:
Процедура УдалитьПроводки2()
        Документ = СоздатьОбъект("Документ");
        Документ.ОбратныйПорядок(0);
        Документ.ВыбратьДокументы(ДатаНач, );
        Пока Документ.ПолучитьДокумент() = 1 Цикл
            Документ.СделатьНеПроведенным();
            Сообщить(Документ+"  "+Документ.ДатаДок);
        КонецЦикла;    
КонецПроцедуры

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

п.с. Руками удаляется и распроводится
208 evgpinsk_
 
07.12.19
13:49
Таже проблема и на базе 2017 года, в которой файл проводок 1,2Гб:
http://prntscr.com/q7hq3z
209 evgpinsk_
 
07.12.19
14:21
Щас буду гуглить, как прямым запросом удалять документы
210 Cthulhu
 
07.12.19
15:37
211 evgpinsk_
 
07.12.19
16:12
(210) Я думал то уже прямой запрос ), а что полезного в статье?
212 evgpinsk_
 
07.12.19
16:13
Выше писал, Выугрузка/Загрзука и далее ТиИ - не изменело файл БИ
213 evgpinsk_
 
07.12.19
16:52
(208) Извиняюсь, на базе 2017 года WRAP вроде работает, чуток запутался в копиях
214 Djelf
 
07.12.19
17:49
(207) Попробуй подменить dbeng32 на этот: https://cloud.mail.ru/public/4iqh/2i5FfEoDX
Я до 4х гигов раздувал dbf`ки. Насколько корректно будет работать в твоем случае я не в курсе.
Но Wirth писал эту штуку и проверял на тех файлах, когда стандартный движок уже падал.
Прямой ссылки увы, уже нет, и даже в архиве интернета ничего не сохранилось.
215 Ёпрст
 
07.12.19
21:22
(214) дбф не может быть физически больше 2 гигов по стандарту.
216 Ёпрст
 
07.12.19
21:23
И там уже, не дбф- ки будут
217 evgpinsk_
 
07.12.19
21:47
(214) Спасибо, дождался вечера и попробовал. Процесс распроведения пошёл, ошибок вроде нет
218 Ёпрст
 
08.12.19
00:12
На вот.. развлекайся

https://cloud.mail.ru/public/3pdW/4QnZKFKqQ
219 Ёпрст
 
08.12.19
00:17
скачать только надо vfp oledb
http://www.microsoft.com/download/en/details.aspx?id=14839
220 Ёпрст
 
08.12.19
00:24
да, после удаления, удалить все rg*, 1SBKTTLC,1SBKTTL,*.cdx
зайти монопольно, пересчитать итоги (двигая та взад вперёд)  и бух итоги (через меню операции- пересчет итогов)

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

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

Занимайся, вроде, все вспомнил
221 evgpinsk_
 
08.12.19
09:44
(220) Спс, принял. Вроде и dbeng32.dll (214) помогло удалять доки, но после создания операций остатков запустил ТиИ и всю ночь выполняется, до сих пор не закончилось.
Сейчас параллельно и вашу обработку буду пробовать
222 Djelf
 
08.12.19
09:47
(215) Так то по стандарту, а в движке от Wirth вот так вот: https://gyazo.com/622763c039b65907291289f4c9ec1206
Но, да vfp и аналоги уже не прочитают. Не уверен, вроде avantage такие dbf должен открывать.
223 Djelf
 
08.12.19
09:49
(221) Перед ТИИ rg* удалил?
224 evgpinsk_
 
08.12.19
10:00
(223) Тупанул - нет. Но например над позавчерашний копией ТиИ выполнялось 1-2 часа. Возможно созданные остатки стали лишней каплей
225 Djelf
 
08.12.19
10:14
(224) Там кажется что-то в геометрической прогрессии клинит.
Значительно быстрее либо выгрузить/загрузить, либо снести rg*, а то так и два дня пересчитываться может...

И если 1С не в терминале, dbeng32 от 1С назад вернуть не забудь. Этот, дополнительно еще и пропатчен на отключение сброса файлового буфера, по сети будут чудеса. У меня он больше 5 лет стоит - проблем не было. Ну и патч Ромикса на загрузку процессора при транзакции с ним тоже не нужен. Могу не пропатченный выложить, если понадобится.
226 evgpinsk_
 
08.12.19
10:20
(225) Помоему да, позавчеар я перед ТиИ сначала сделал Выгрузку/Загрузку. Может поэтому прошло ТиИ быстро.
1с - в терминале.

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

не знал про этот патч.
vk_TerminalSleep.rar - сейчас скчал, буду знакомится. Там без нюансов ? - и его желательно поставить?
227 evgpinsk_
 
08.12.19
10:23
(225) [Ну и патч Ромикса на загрузку процессора при транзакции с ним тоже не нужен]
Вроде понял мысль, при использовании нового "dbeng32.dll" патч от Ромикса не нужен? Блокировок процессора с новым dbeng32.dll и так не будет?

Т.е. если у меня 1с работает в терминальных сессиях, то я могу оставить новый dbeng32.dll навсегда?
Или лучше не рисковать?)
228 Djelf
 
08.12.19
10:30
(227) Я же писал, 5 лет стоит. Причем и на линуксовке с wine@etersoft и на еще 2х конторах с виндой. Проблем не было.
Wirh писал, что делал движок под микроскопом, т.е. в двух базах проводил одни и те же действия, а потом бинарно сравнивал dbf и cdx.
Так что оснований подозревать этот движок в больших багах, чем стандартный, у меня нет.
229 evgpinsk_
 
08.12.19
10:33
Ещё параллельно вопросик: пусть у меня счёт 60 "Поставщики" ведётся в разрезе двух субконто: Контрагент и Документ. Сейчас я понял что в учёте могу обойтись без второго субконто и было бы не плохо от него отказаться.
Но база действующая.
Каких-то простых способов решения нет?
Если его тупо удалить - то придётся все документы перепроводить, что очень не хотелось бы.
230 evgpinsk_
 
08.12.19
10:43
Ну и тогда ещё один, ранее задавал но так и не получил ответа:
Очень часто свёртка итогов по балансовым счетам происходит уже после открытия нового периода, а значить уже свормированы в БИ "излишние" остатки в разрезе субконто.
Решение этой проблемы только одно? - закрывать остатки по счетам ДО открытия периода?
231 Cthulhu
 
08.12.19
11:08
(229): есть. по каждому контрику собрать полный разворот сальдо - и сделать операцией свертку со всех (имеющих ненулевое сальдо) субконто-документов на один (и закрепить его навечно на будущее для проводок). безо всякого ковыряния в прошлых периодах и перепроведений.
232 Cthulhu
 
08.12.19
11:10
(213)+: есс-но "закрепить его ..." для каждого контрика - и код проведения по взаиморасчетам "подпилить".
233 Cthulhu
 
08.12.19
11:11
(230): не парьте мозги. в периоде - никаких удалений. надо подправлять - формируйте бух.операцию (сопровожнайте бух.справкой). "аудиторский след" - наше всё!
234 evgpinsk_
 
08.12.19
11:24
(231) понял.
(232) "код проведения подпилить" - да, в классической конфигурации проще. Мне будет сложнее, логика проведения у меня не в конфигураторе, а в 1с через справочники, придётся заморочиться, чтобы для каждого документа создать новую логику проведения по счёту 60 ( и остальным где нужно убрать Субконто2 = Документ)
(233)  либо я не понял либо меня. Пусть есть счёт себестоимость - в разрезе трёх субконто, по нему очень много итогов. Его на конец периода нужно свернуть по остаткам, /остатки перекинуть на синтетический счёт/, тогда при открытии нового периода остатков по бухитогом будет не много.
Если же открывать новый период ДО свертки остатков - остатков будет много лишних на счёте себестоимость. И свёртка их задним числом при открытом новом периоде не исправит ситуации в плане излишних данных в dbf файле бухитогов.
235 evgpinsk_
 
08.12.19
13:50
(228) Странно, на изменённом dbeng32.dll обычная операция создания документа на основании /или некоторые другие операции/ - вываливается 1с. /на родной dll такое бывает раз в 5 дней/. Вернул родную dll  - всё ок.
236 Cthulhu
 
08.12.19
14:00
(234): в смысле - в справочниках? проводки-то "в конфигураторе" именно кодом формируются.
ну и - да, ковыряй тогда справочники хоз.операций И код. там логику-то подпилить - час работы.
237 Cthulhu
 
08.12.19
14:01
(234): тю. ну засуть в финальный документ закрытия месяца эту байду со сверткой аналитики.
238 Djelf
 
08.12.19
14:05
(235) Действительно странно, у меня никогда такого не было.
Ну главное что помогла свернуть базу...
А что из ВК подключено? И в какой последовательности? Может что-то вклинивается?
239 evgpinsk_
 
08.12.19
14:16
(236) у меня самописка: http://prntscr.com/q7tzzx
(237) да, нужно будет написать перед свёрткой
(238)
    Попытка
        ЗагрузитьВнешнююКомпоненту("1cpp.dll");
        Сообщить("Компонента 1С++ загружена!");
    Исключение
        Сообщить("Пытались, но не загрузили компоненту 1С++ :(");
    КонецПопытки;    
    Путь = КаталогИБ() + "TurboMD.dll";     ЗагрузитьВнешнююКомпоненту(Путь);    
    Путь = КаталогИБ() + "FormEx.dll";

после подключения 1cpp.dll вылеты стали чаще, примерно раз в 5 дней
240 evgpinsk_
 
08.12.19
14:18
(238) [Ну главное что помогла свернуть базу...]
___
Да, база вроде сворачивается, прямой запрос от Ёпрст по удалению доков - тоже быстро отрабатывает.

Теперь остаётся перед окончательной свёрткой навести порядок - посворачивать в итогах висящие, не закрыте не нужны остатки (тот же второй субконто Документ по счетам 60/62)
И тогда можно будет финально обрезать базу
241 Djelf
 
08.12.19
14:32
(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
242 evgpinsk_
 
08.12.19
15:30
(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
243 Djelf
 
08.12.19
15:54
(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 maxile
 
08.12.19
22:48
Очень похоже на системный глюк Винды. Попробуй осмыслить ее работу. Там несколько параметров.
245 evgpinsk_
 
09.12.19
10:52
(244) В винде несколько параметров? Это точно?
246 Ёпрст
 
09.12.19
11:14
Нашел хоть, по каким счетам не закрывается в разрезе субконто ?
247 evgpinsk_
 
09.12.19
13:34
(246) 60й и 62й . ведутся в разрезе Клиент Документ
Их в разрезе документов - не закрываю . Нет смысла. Изначально Документ был не нужен.

Вроде остальные "большие" счета закрываются
248 evgpinsk_
 
09.12.19
13:37
"Вроде" - потомучто сложновато сделать анализ, какой процент объёма данных в файле 1SBKTTL.DBF занимает каждый счёт за эти 16 лет эксплуатации базы.
Да и не нужно сильно.
Подправить план счётов - это да, можно /но не уверен что буду делать, не очень хочется в одной базе иметь разные структуру плана счетов/.
249 Djelf
 
09.12.19
14:46
(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
250 Злопчинский
 
09.12.19
14:51
(248) анализ - осв по счету с разворотом по всем субконто.
251 Ёпрст
 
09.12.19
14:54
(247) ну дак вырежи документ оттуда и свертка не нужна будет
252 Ёпрст
 
09.12.19
14:54
и в регистрах поправь, как раньше писал.. делов то
253 evgpinsk_
 
09.12.19
15:44
(251) Удалить субконто можно. Но тогда либо перепроводить документы с 2017 года - что не хочется. Либо будут какието битые ссылки? /сейчас попробую/

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

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

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

Но повторюсь - выяснять какой счёт максимально виновен в 2Гб - не очень важно. Вырезав из базы 14 лет и соатвим только 2 года - проблема забудется ещё на 10 лет.
А если план счетов оптимизировать - то и на всегда
254 evgpinsk_
 
11.12.19
14:26
Не могу чтото разобраться. Пусть например я по счёту 60 убрал в плане счетов второе субконто.
По идее рассчитанные итоги должны стать меньше. Каким образом ужать файл 1SBKTTL.DBF ?
Пробовал в 1с "полный пересчёт итогов", не помогло: http://prntscr.com/q9a2fu
255 Ёпрст
 
11.12.19
14:31
(254) Теперь оттуда нужно удалить "нулевые" записи и сжать таюличку, если не умеешь, то или выгрузка загрузка (что долго) или тупо удалить 1SBKTTL и 1SBKTTс и пересчитать бух итоги
256 evgpinsk_
 
11.12.19
16:51
(255) http://prntscr.com/q9cm8m
Даже базу можно не резать. По 62му счёту удалил второе субконто Документ /которое не закрывалось и которое мне ненужно/ и после выгрузки-загрузки dbf стал 320Мб
257 Ёпрст
 
11.12.19
16:53
судя по файлу проводок, что-то еще не закрывается
258 Ёпрст
 
11.12.19
16:53
итоги должны быть меньше чем 1srntry
259 evgpinsk_
 
11.12.19
19:36
(258) насколько я понимаю, нет какого-то механизма, который отловит эти моменты. Только както руками смотреть ЖОпоС по каждому счёту в разрезе субконто и анализировать количество строчек отчёта, если оборотов нет а остатков много - счёт возможно проблемный
260 evgpinsk_
 
11.12.19
19:38
Тот же 411 счёт, остатки по ТМЦ для меня важны только по регистрам. Возможно по проводкам коегде не верно списывается количество и на остатке повисает, и изза них растут итоги.
261 Ёпрст
 
11.12.19
20:12
(259)в этой ветке 2 раза выкладывали код с решением, там примитивный запрос и сортировка, через sqllite
262 evgpinsk_
 
12.12.19
09:15
(261) Като сомнительно, что запрос (а не глаза) может отловить "не правильные" остатки.
263 Djelf
 
12.12.19
10:10
(262) Почему сомнительно? Элементарный счетчик количества остатков проводок по счетам сразу же выявит счета с аномальным количеством. Это в (249).
Можно расширить этот запрос  группировкой по периодам, тогда будет видно какие счета не закрываются. В них количество итогов будет не примерно одинаковое в каждом периоде, а нарастающее.
264 Djelf
 
12.12.19
10:16
Ну а дальше, да, уже "глазами" разбираться надо. Запрос покажет "где", но не объяснит "почему".
265 evgpinsk_
 
12.12.19
10:26
Проскакивала ли гдето обработка, которая переносит в пустую конфигурацию документы из действующей конфигурации за какойто последний период времени, плюс все справочники и константы.
или это нужно делать через копирование данных из dbf в dbf?

Нужно ли этим заморачиваться, если ТиИ выдаёт такие ошибки: http://prntscr.com/q9osvt
Наверное они не критичные?
266 Ёпрст
 
13.12.19
11:09
(265) всего лишь есть дубли по id в этих справочниках
267 Ёпрст
 
13.12.19
11:10
перенести, можно этим, например..http://catalog.mista.ru/public/102101/
только, зачем ?
268 evgpinsk_
 
20.02.20
08:50
Режу базу на 01.01.18. Всё ок.
Но проблемка: после данной операции, ТА стало почему-то на 01.01.2020 а не на последний документ, и регистры остатков по номенклатуре товаров не верные после этой даты.
Каким образом можно пересчитать эти регистры, не проводя сами документы?
Двигать ТА в ручную через "Управление итогами" - не пересчитывает