Всем добра.
ТиС, в меру переписанная, регистр "поставщики" (вроде не трогали - типовой). Пользователи жалуются на отчет по взаиморасчетам = долго. Сеть 15 магазинов - каждый магазин свое юр.лицо. товароборот - по каждому магазину как по отдельной фирме, а вот оплаты поставщикам - почти всегда с одной. Вчера попробовал решить "по быстрому", убрал запись в измерение "фирма" и проапдейтил регистр через SQL - заполнил пустой фирмой. Пересчет итогов. Отчет формируется быстро :) , но не правильно :(
Почему "чуда" не произошло - не разбирался еще. Хотел спросить - какие еще варианты?
Сам думаю пока так: завести в базу документ, через который "закрыть" взаиморасчеты. И отключить фирму с этой даты. Все это провернуть на периоде, куда уже точно никто не полезет менять. Может еще что подумать можно?

(0) Отлчный план Уолтер! Надежный, как швецарский нож.

И будет у тебя, останки с пустой фирмой, рамход с 15 - ю непустыми и приход с одной.

(1) С какого перепою?
"И отключить фирму с этой даты. "

(2) он уже это сделал проапдейтив табличку

(3) Я так понял, он хочет в коде не писать фирму с этой даты

(4) проще уж вообще это измерение убрать, ну или в реквизит кинуть, чтоб видно было на какую фирму деньги кидали изначально.. хз

(5) Ага. Убираем измерение. И начинаем лопатить код на предмет .Остатки() и .СводныеОстатки()...

ну и ..помимо этого регистра, надо еще Покупатели исправлять. Его он не проапдейтил вот и в отчете радугу получил

(6) это не долго, там всего одна проца в глобальнике

(8) Ты телепат (это не вопрос). А где ещё это может встретиться?

(9) в ТисЕ вроде больше нигде, отчеты там все на запросах чорных.. ну разве что может быть сделан показ долгов в форме списка клиентосов или в поделке по кнопке долги (я не помню за тис, было ли там такое)

(10) "в меру переписанная"

(3) Это копия базы... В рабочей я еще ничего не поломал :)
Убирать реквизит чего и не хотел, что бы не лезли грабли при обращении.
(7) Смотрел не штатным отчетом - смотрел только свой регистр. Почему то не закрылось ровно, но еще не разбирался почему.

(12) штатный отчет по взаиморасчетам использует 2 регистра - Покупатели и поставщики.
Проапдейть оба и пересчитай оба

(13) Спасибо. Попробую.

Хотя могу и ошибаться.. там вроде галка была - отчет только по поставщикам\покупателям и полный.. че то в этом роде.
В любом случае, я бы пересчитывал оба.

пересчет итогов прямым запросом не так и долго в скуле

Да, там переключалка есть. Да в принципе и штатный пересчет справляется быстро.
Меня только смущает, что после пересчета у меня ТА на начало года откидывает и база просит открытие периода...

(0) Если штатно - то можно через Корректировка долга сделать - перебросить долг магазинов на платежную главную организацию и все должно закрыться

А можно фирму переставить на второе место в регистрах Покупатели и Поставщики, чтобы Договор в индексе была на первом месте. Тогда после реструкторизации и пересчета итогов останется только поискать Остатки() и .СводныеОстатки() по конфигурации.

Или кстати может тебе вообще ничего не надо делать. Просто у реквизита Договор поставь флажки Отбор движений и Отбор итогов на закладке Дополнительно. Просто добавятся дополнительные индексы.

(0) Скажите а у Вас много переписано на прямые запросы? Дело в том что я вот пробую под скуль тоже ТИС и отчеты и особенно групповое перепроведение документов начинает тормозить сильно. Правда тестовый сервер скуль слабенький относительно. просто не пойму - так должно быть или у меня криво что-то сделано?

(17) пересчет делай обработкой

(21) так может быть только для SQL2000. Там известная проблема, решенная в т.ч. в 1с++. Ну а в SQL2005 и далее это уже исправлено

(21) Нет. Я тут недавно. Прямые запросы только стал применять... Пока только для отчетов. Проведение все штатное.

(21) Да ничего подобного. Мы поставили правда скуль2008 на вин сервер 2008. И проблема есть. А как она решена в том числе в 1С++ - подскажите если не трудно

(25) рекконект натив, но этой проблемы на скуле >2005 нету.

(23) Это я вам на ваш пост ответил. серверочек слабенький ибо тестовый. Один проц 16 ГБ ОЗУ правда есть SSD, настроили вроде все как у Гилева и у Тавалик в методичках

(26) Может все-таки что-то не так настроили хотя там не так уж много этих настроек на самом деле. Просто хочу понять - откуда у проблемы ноги растут. И как с ней сбороться без прямых запросов?

(28) проблема в чем ?

(25) Обработку надо смотреть. В типовой все выполнялось в одной транзакции и соответственно на скуле образовывалось такое количество блокировок что ему уже не до остального было. Нужно через какое-то количество документов ФиксироватьТранзакцию и начинать новую.

(30) он видать про Операции-перепроведение говорит..

(31) Да, именно про нее

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

Тобишь тут самое узкое место будет именно журнал транзакций. Я вообще когда-то заводил себе ram-диск и помещал журнал транзакций на него для таких операций. Заметно быстрее все выполнялось.

(27) Ну у нас на примерно таком и крутилось все. покупали в 2007 году, тогда 16Г оперативы было скорее нормой, чем недостатком.
(26) ага
(32) напиши свое восстановление  последовательности. ну просто и тупо - выбратьПоПоследовательности-провести-(проверить флаг завершения - завершить)-и далеее по циклу

+(35) последнее, есссно, со сдвигом ТА на док, и с восстановлением при досрочном завершении.

(35) Я последовательностями вообще не пользуюсь - просто делею групповое проведение уже проведенных докмуентов за весь квартал. В дбф-ном варианте вполне себе шустро. В скульном - раз в 10 медленнее.
И потом пытался выгрузить через правила в БП3 и столкнулся с тем что выгрузка авансовых отчетов вообще застряла в начале базы (01.01.2016)

(31) То есть через Операции-проведение сделать не получится? Будет долго и упорно тупить

(38) А какие проблемы написать цикл и через каждые 100 или 1000 доков (экспериментально) фиксировать транзакцию и начинать новую?

(39) Я так в дбф-ном варианте пробовал со сдвигом ТА на текущий проведенный докмуент. Но групповое проведение штатное работает намного быстрее.

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

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

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

(42) И можно код прямо в тему?

(43) Это только для скуль или для дбф тоже они годдятся?

(42) ща. как раз с домашним сервером админ помог

(42) https://yadi.sk/i/e82dKW6CJflw-A

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

(46) спасибо огромное. попробую.

(47) А код в студию можно? А то интересно, а файла уже нет

(49) Получил?

(49) https://yadi.sk/i/JJKxe4kYLsKUDg

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

(50) (51) Спасибо посмотрел. Симпатично.

(0) А у вас розница магазина на каком режиме налогообложения?
Ведь вмененку с нового года убирают совсем

ТиС?.. дык там же тово, "все уже украли до нас" (с).
фин.учет - движения пишутся с фирмой как надо для магазинов,
упр.учет - движения пишутся без фирмы как надо для оплаты.

(55) это в старой, которая 8.*
ее уж года с 2002 нет