|
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 с консолью, и выполни
Полистаешь результат и увидишь, где у тебя не закрывается. Примерно вот так будет: 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
|
(208): ня. http://1cnik.by/reducefile1sbkttldbf.php
|
|||
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
|
||||
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) А что тут сложного то? Это легко выясняется.
|
|||
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 а не на последний документ, и регистры остатков по номенклатуре товаров не верные после этой даты. Каким образом можно пересчитать эти регистры, не проводя сами документы? Двигать ТА в ручную через "Управление итогами" - не пересчитывает |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |