Стали долго проводиться доки реализации по определенному контрагенту. Посмотрел взаиморасчеты - в 2009 году выбирали неправильную фирму в реализации и ПКО. Попробовал закрыть долги корректировкой долга, не помогло, переправлял документы вручную тоже не помогло. В чем загвоздка?

Это загадка такая? Подсказки будут?

и при чем тут "незакрытый регистр"?

@Попробовал закрыть долги корректировкой долга, не помогло@

Значит, неправильно пробовал...

Попробуй более детально понять, что тут надо проанализировать измерение "КредДокумент"

Делал отчет по взаиморасчетам на текущую дату по КредДокументам, там висят куча документов за 2009 год.

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

Может помимо фирмы, еще что то не совпадает. Там вроде данных других больше нету.

У кого есть время может посмотрит, уже нету идей, поиск до дыр затер.

бамп

посмотри замер.

смотрел, проблемные места:

ПроведениеПоРегистрам();
глДвижениеДолгов(Контекст,Договор,ТаблСписПартий,СписокПараметров,ВремПокупатели);

на каких именно строках в %?

не понял.
обе эти строки по 44% от общего времени занимают.

regprint что показывает по этому регистру?

даже не знаю, что нужно то смотреть?

из-за чего "пухнет" регистр.

размеры RA и RG таблиц твоего регистра огласи

(16) я же по взаиморасчетам это уже увидел, не?

(17) RA4335 25 - RG4335 314  покупатели
    RA4343 19 - RG4343 185  книга продаж
    RA4314 0.6 - RG4314 6.5  поставщики
    RA3549 0.6 - RG3549 6   книга покупок

у тебя, похоже, все не закрываются )
но тупит скорее всего
>RA4335 25 - RG4335 314  покупатели

dbf?
А то я проверялку закрытия для SQL почти написал.... Могу доделать, ибо другое делать что-то лень....

да dbf.

дык распечатать regprint ом остатки на ТА с группировкой по всем измерениям
если краснота есть - значит 99% не закрывается

(19) ну я выписал те, у которых RG>RA, видимо не только реализацию и пко криво вводили.

(23) стукнись в аську

(24) еще будешь в сети?

update raXXXX set spФирма =  нужный ID where spФирма= ненужный ID
идея понятна?
аналогично фирму в 1sjourn обновить, чтобы в доках не было расхождений с регистрами
после - сделать ТИИ, таблицы итогов уменьшатся в разы

там у него каша. в регистрах

( 20) а какая разница дбф или скл? отличия только в именах нескольких таблиц, код один и тот же

>>отличия только в именах нескольких таблиц

эта пять!

(27) ну и что? ее уже начали разгребать. а так - (26) - очень быстро получится

(30) там не только в фирмах дело скорее всего

(10) десять! давай зачетку.
драйвер vfpoledb почти все команды mssql понимает. и 1С++ тоже работает на ура

в смысле (32) было написано для (29)

(33) ага. А попробуй вытащить остатки из регистра прямым запросом к SQL и к DBF. Почувствуешь разницу ещё кое в чём

(0) Извиняюсь, конечно, но когда спрашивают про незакрытые долги документов, то у меня первый вопрос: а восстановление последовательностей регулярно делаете?

(32) Разница небольшая, но есть.
а тестировать - нет файловых баз....

+(35) А то пугает фраза - "... заходил в пко, выбирал там нужную фирму, перепроводил ...", и это "... в 2009 году ...".

(34) а что такого? я себе написал функцию для временного расчета итогов регистра для DBF базы, иногда пользуюсь.
(36) там делов на пару минут - предусмотреть разные имена полей, например date_time_iddoc вместо 3-х полей в dbf
делается примерно так: ?(ЭтоSQL=1, "date_time_iddoc", "iddoc")

(38) а оно мне надо? :-)

(39) а я и не тебе это советовал :-Р

хотя если ТС не умеет прямыми запросами пользоваться, то выбора у него нет - выбирать нужную фирму и перепроводить :)

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

(42) не факт что у (0) это есть

(43) Штатный алгоритм закрытия...

а я писал выше, что надо ТИИ сделать

(35) восстановление последовательностей не делают вообще, ГП стоит на 2009 году. Перепроведение, я так понимаю, ни на что не влияет.

(46) Ошибочное мнение.

(47) Перепровел тот период полностью, картина не изменилась.

(48) Как-то грустно у вас совсем. Может пора пригласить 1С-ника?..
Я б непарился если там 2009 год еще. Пореж базу на 1 января и дальше пусть все делают правильно.

(0) стучись в сбт/вск на известное мыло-скайп - поправим...

прошлый раз посмотрел, но не сильно внимательно (ибо бесплатно), пришлось п омочь еще раз.
.
у ТС все просто - реализация = КупляПродаджа, а ПКО = "розничная выручка", соответсвенно ТЗ долгов при проведении куча строк, на которых все тормозит...
.
итого: штатными возможностями в ПКО подменить вид оплаты = "оплата от покупателя", перепровести базу... и будет ок. что собственно и пробуем на копии

протренировали на 2009 годе - все ок.