Ситуация такая: 7.7, комплексная для Украины,sql. учет взаиморасчетов ведется в разрезе расходных документов, т.е. дебиторка - это список всех расходных документов(товарных) с подчиненными им оплатами. если сумма оплат по конкретному документу совпадает с суммой самого документа, то такой документ в реестр НЕ попадает. то есть нужно сначала отобрать все документы, начать их в цикле просматривать, отбирать их подчиненные, суммировать и выводить или не выводить в реестр. проблема в том, что документов очень много - 3-5 тысяч в день. отсрочки по оплате есть до полугода, есть и паругодичные, есть старые долги, то есть каждый раз приходится просматривать абсолютно все расходники с начала времен, а база за 7 лет. т.к. нужны ссылки на документы, то и запросы по регистрам взаиморасчетов работают медленно и тупой просмотр документов в цикле тоже медленно. все что можно оптимизировать - сделано: и прямые запросы где только можно, и эсэсдешный рейд, и оперативка, и проц, и отдельный сервак со скулем, и тонкие настройки скуля.удалось уменьшить время формирования отчета с пяти часов до двух. но это все равно медленно - нужно чтоб за пару минут, ну максимум 10-15 минут. посоветуйте что можно сделать. я понимаю, что нужно менять сам подход, принцип учета, но не могу ничего придумать. сразу скажу - никакие взаиморасчеты по контрагентам не интересуют, нужны результаты именно по конкретным расходным товарным документам, именно в разрезе документов.
заранее благодарю за дельный совет.

Грамотные SQL-запросы написать и проиндексировать правильно - не предлагать?

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

очень непонятно.. если предоплата 70% то она привязывается к накладной, или накладная к ней..?

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

Картина знакомая - вместо организации грамотного регистра по документам тупо крутят дерево подчиненности с юрского периода до наших дней. То есть при каждом запуске отчета эмулируется перепроведение всех документов и построение этого регистра в оперативной памяти.

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

(5) да, именно так. к сожалению мне такое досталось  в наследство. что можно сделать?

(7) Или грамотно использовать имеющиеся взаиморасчеты по документам или создать свой регистр. Анализ дерева документов - путь в никуда. Вечные разборки и дописки. Хотя если есть цель обеспечить себя работой...

(8) наоборот, цель сделать и забыть, чтоб не приставали больше ;-)
НО...конфу менять нельзя. только отчет.

(7) Изучать программирование под 1с.Понять что перебор документов - не решение.Что в 1с есть регистры.И перейти на прямые запросы 1с++.

(6) Нет, неправильно.Читать (10) до просветления.

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

Вторая проблема: "удалось уменьшить время формирования отчета с пяти часов до двух" - я бы даже хвалится таким не стал. Уменьшили время выполнения в два раза?  Я только на "программной оптимизации" с 40-50 минут оптимизировал до 5 минут. Необходимо пересмотрел алгоритм работы программы. Скорей всего, это придется делать опираясь на п.1.

Ну и чтобы реально чем-то помочь - нужно иметь доступ к базе. В противном случае это будет не помощь - а пустые разговоры ни о чем.

(12) обычная комплексная для Украины. конфу менять НЕЛЬЗЯ. только внешний отчет. я все прекрасно понимаю - регистры, учет и т.д. конечно отчет по документам это не правильно,отчет должен строится по регистрам, но они УЖЕ не такие как нужно. потому и спрашиваю, как ускорить отбор и расчет из того что есть.

Если очень нужно вырезать гланды через опу, да еще и связанными руками:
1. заводим в скуле доп.табличку взаиморасчетов по документам - аналог регистра движений
2. добавляем в УРБД еще одну базу для фиксации изменений документов
3. пишем внешний отчет/обработку, которая будет "допроводить" документ по этому "регистру". Сведения о измененных документах берем из УРБД
4. периодически запускаем эту обработку
5. пишем отчет на основе нашего "регистра"
Все это, естественно, на 1С++ т прямых запросах.
Дешевле и методологически грамотнее разобраться в учете и научить юзеров.

(14) можно примерную структуру такого регистра? чтоб взаиморасчеты в разрезе документов. я никак не могу сообразить. спасибо.

(15) в любой свежей типовой

"все что можно оптимизировать - сделано"

от row_id  оказались, как от PK ?

учитывая скорость современных компов, если баз помещается в озу целиком. данные для отчета на скл сервере больше 10 сек собираться не будут.

присылайте свой отчет

рассказываю что к чему у автора.
учет в базе убит напрочь.
данные вводились не на основании учетно-регистрационно-итоговой инфы в базе а по принципы нам надо ввести вот такую цифру - мы знаем что она правильная! При это клался МПХ на договора, клиентов и прочие аналитики учета по регистрам.При этом очень хотелось вести подробный учет, но не хотеловь вести подрпобную аналитику и следить/контролировать ее правильность при заполнении доков. То есть вводились по принципу "абы что либо ввести". после ЭН-месяцев работы данные выдаваемые отчетами перестали соответствовать "ощущению прекрасного" у булгахтеров/манагеров/управленцев. на отчеты было решено наплевать. а УЧЕТ строить самим путем ввода на основании и подчиненных документов. Проводились попытки возможно попрограммить альтернативную схему построения системы учета взаиморасчетов. Безуспешно. Теперб оказалось что "записная книжка в виде подчиненности" - неудобна и не влазит в карман. - Встречался с такой ситуацийе не раз. Бесполезняк. Не лечится. Только возможно купировать на некоторое время техническими уловками. Единственный вариант - забить на все. провести инвентаризацию расчетов - текущих сальдовок - и НАЧАТЬ ВЕСТИ УЧЕТ ПРАВИЛЬНО ПО ШТАТНОЙ СХЕМЕ. - желательно поднанять вменяемого чела (не прогера 1С - они там непуганые в стаде идиотов)
.
При таком обилии документов сомнительно что количество ненулевых сальдовок с клиентами весьма велико. В первую очередьнадо оценить именно это. И не строить вавилонских башен с реестрами на пачку бумаги.
.
Вариант купирования, один из. возможно поможет
Берем существующий отчет (нам пофиг сколько он выполняется - запускайте в ночь). Из результатов отчета выцепляет клиентов с ненулевым сальдо. Запоминаем такой список на будущие запуски отчета. При очередном запуске отчета фильтруем документ-родители по клиентам такого списка. скорость уже увеличиться я думаю существенно.
.
с хожу могу предложить еще пару вариантов.
.
самый простой вариант, который надо было сделать изначально.
Регистр остатков "взаиморасчеты в куче".
Измерения
- Фирма
- Контрагент
- Договор
.
В качестве договора - использовать что угодно - хоть договор, хоть документ, образующий первоначальный долг (аналог документа основания - корень дерева), хоть устное указание ГД.
.
Итоги по такому регистру в подавляющем колве контрагентов-договоров будут нулевые. Расчеты по документам (определить какие именно документы не оплачены) - по ненулевым сальдовкам контрагентам - разворачивать по фифо назад. быстрый метод решения такой задачи (не тупым перебором) - описан на инфостарте (возможно у Ильдаровича). если сюда пристегнуть еще эмпирику малую типа если предварительно проанализировать наиболее частую глубину долгов - то еще все быстрее.

(20) учет только управленческий. нет никаких бухгалтеров. учет ведется так: выписывается Т_РасходнаяНакладная. в ней указан контрагент и торговый агент. когда агент сдает деньги, то вместе с баблом подает и реестр с указанием какая сумма за какой документ. сливает со смарта кассиру реестр, кассир его проводит и к накладным цепляются приходные кассовые. все. ничего никуда не теряется. все долги и остатки идут. всех все устраивает. проблема одна - долго формируется отчет о долгах в разрезе накладных. учетчиков не интересуют общие долги по контрагенту, их интересует только закрытость или незакрытость каждого конкретного расходнотоварного документа.

основание документа ищется быстрее чем выбираются подчинненые.
Если вы не можете менять правило работы. Идите от обратного - от денег. Т.е. 2 таблицы формируйте, в 1 деньги и к чему привязаны, во второй только реализации и сравнивайте их. Возможно быстрее будет.

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

в общем засел изучать 1с++. пока сделал так: прогнал за ночь подправленный отчет, и  проставил каждому расходнику признак закрыт/не закрыт. и теперь отбираю для анализа только незакрытые. 19 минут теперь. буду пока регулярно эту процедуру делать для актуализации признака.

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

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

(21)"когда агент сдает деньги, то вместе с баблом подает и реестр с указанием какая сумма за какой документ".
молодцы, чо... порадовали. Пятнично.
(25)" есть там на конторе один дядька, который дебил-дебилом, но замдиректора." - не один он там такой....
Злоп прав - у вас там питомник...

(26) добавить в регистр взаиморасчетов? так там есть такое измерение и оно заполнено.

(28) Ну так и собирай  одним запросом по нему. Какие там 19 минут-то???

(29) не могу вдуплить. можно пример?

(30) Структуру регистра "взаиморасчеты" в студию - будет пример.
Хотя я абсолютно уверен, что содержимое регистра и мозга замдиректора кардинально отличаются

регистр остатков ВзаиморасчетыПокупателей
Измерения: Фирма,Контрагент,Договор,СтавкаНДС,КредитныйДокумент,Валюта
Ресурсы: Долг,ДолгОсн
Реквизиты: КодОперации,СуммаСНДС_НУ,НДС,Влаг_НУ,Отклонение_НУ

(32) "КредитныйДокумент" - вот по этому реквизиту можно посмотреть остаток по определенному документу.

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

(34) Ну вот и останутся незакрытые. а у них уже можешь смотреть и отсрочку, и все остальное.

(34)  Смотришь остаток по этому документу. Вычисляешь количество дней между датой документа и текущей датой. Отнимаешь отсрочку. Вот тебе количество дней просрочки.  Это всяко быстрей, чем все доки перебирать.

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

если я добавлю новое измерение в регистр, можно ли его будет заполнить без перепроведения?

(38) Безопаснее свой регистр, так как скорее всего, ВСЕ последствия добавления измерения Вы не представляете.

(37) про что тебе и говорили - у кассовых/банковских  документов заполнятьто поле не по фифо, а подчиненным документом.

(37) насколько я помню в кассовом ордере МОЖНО выбрать накладную которую он закрывает. если не выбрана - тогда да, списывает по ФИФО.

(38) не надо измерение. добавь реквизит регистра, заполни его напрямую, и перепиши запрос на 1с++. И все будет летать.

(39) ну а заполнить его без перепроведения можно?

(41) "сделать можно все" вопос в том, что у ни.. впрочем, Злоп объяснил, что там у них....

(43) "сделать можно все". в данном случае - штатно не получитсчЯ, но у вас в руках SQL....

(42) "напрямую" - это примерно так?
    Запрос = СоздатьОбъект("ODBCRecordset");    
    ТекстЗапроса = "                          
    |Update     
    |    Рег
    |SET     
    |    $Рег.ДопИзмерение3 = Служ.КредДок
    |FROM     
    |    $Регистр.Взаиморасчеты as Рег
    |INNER JOIN     
    |(     
    |Select     
    |    Док.IDDoc,
    |    $Док.КредДок КредДок
    |From     
    |    $Документ.Т_Заказ Док
    |UNION ALL       
    |Select     
    |    Док2.IDDoc,
    |    $Док2.КредДок КредДок
    |From     
    |    $Документ.Т_РасходнаяНакладная Док2    
    |UNION ALL       
    |Select     
    |    Док3.IDDoc,
    |    $Док3.КредДок КредДок
    |From     
    |    $Документ.ПриходныйКассовый Док3
    |)     
    |Служ ON Служ .IDDoc = Рег.IDDoc";    
    ТЗ = Запрос.ВыполнитьИнструкцию(ТекстЗапроса);

(46) ну да, типо того (запрос не разбирал)

понял. всем спасибо. буду пробовать.

(48) бэкапы бэкапы бэкапы

(49) Ну все же делятся на две категории - те, кто еще де делал бэкапы, и тот, кто уже делает....

(37) если нужна дебеторка, разбитая по фифо - можно обойтись обычным отчетом. причем независимо от степени бардака в базе.
Мне приходилось делать такой отчет для базы с 60тыс клиентов и около 4 млн движений по регистру. Время формирования 2 минуты (полный скан регистра с начала работы). Если нужна помощь - мыло в личке.

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

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

(51) сделал отдельный регистр. теперь пытаюсь разобраться, как его заполнить без перепроведения документов.

(52) даже "штатно" можно разными способами.
а так, проще инсертить прямым запросом

(53) а как штатно?

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

(55) (53) плиз, дайте пример, как "инсертить прямым запросом". не волоку толком.

ты не инсерть, ты апдейть...

(54) ну так, например
http://catalog.mista.ru/public/79515/

(56) https://msdn.microsoft.com/ru-ru/library/ms174335.aspx

(57) дык у него новый регистр, там нечего апдейтить еще :)

(59) Дык добавил бы реквизит в регистр, и все...

(60) аа...

можно и так.

и все же пример инсерта можно?

(63) ??????????????????????????????="
|declare @SelectedId char(9)
|declare @SelectedDef int
|declare @SelectedSign char(3)
|declare @count int
|set @SelectedId=?
|set @SelectedDef=?
|set @SelectedSign=?
| set @count= (select count(*) from _1supdts (nolock) where typeid=@SelectedDef and objid=@SelectedId and dbsign=@SelectedSign)
|if @Count=0
|begin insert into _1supdts values ( @SelectedSign, @SelectedDef, @SelectedId, ' ', ' ')
|end
|else
|begin
|update _1supdts set dwnldid= '' where Typeid=@SelectedDef and Objid=@SelectedId and DBSign=@SelectedSign
|end";

ну вроде получилось. нужно ли пересчет регистров делать?

(65) если добавлял или инменял измерение, то нужно. если реквизит, то нет

пересчет делай поделкой..коих штук 5 есть разных модификаций

(37) стадо непуганных идиотов.. оказывается что там совсем не тот документ закрывается - а перед этим были фразы что все красиво и все как надо.

Понимайте разницу между тем КАК НАДО вести учет в программе, чтобы ПОЛУЧИТЬ НУЖНЫЕ ВАМ данные и тем что у вас там напридумано...

.

http://catalog.mista.ru/public/175550/

(37) а вы не вносите свои домыслы. в стройтную картину вселенной.

У вас там есть Измерение - ДОГОВОР - документы образования долгов ПО ДОГОВОРУ - однотипные - то есть с равными условиями (в т.ч. и равные отсрочки). в рамках договора - при наличии однотипных документов долга - в первую очередь гасится самый первый непогашенный документ. и этоправильно.

если у вас КОНТРОЛИРУЕМОЙ СДЕЛКОЙ является накладная (или заявка) - тогда в Договор (т.е в качестве договора) пихайте именно накладную (заявку) и все будет без всяких вымороченных структур подчиненности раскладываться по суммам правильно.

но вы так не сможете - ибо смотри ссылку в (68) - умрете...

http://catalog.mista.ru/public/71643/

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

(71) Это обычно требование: "как бы сделать так, что нельзя, но если очень хочется - то можно?".

нихрена там не взлетит.
что ыб там не говорили - на данный момент использование всяких товароучетныхуправленческих прог требует ПЕРВОНАЧАЛЬНОГО обучения. И желательно не только консультантами, но и практиками.

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

А товароучетные проги лучше юзать с заложенной в них концепцией.

Конечно, за вариант того, что в системе подчиненности рисуется одно, а внутрях учитывается по-другому - разработчикам такой концепции надрать бы уши.

Я юзверей в этой ситуации понимаю. Когда ПКО привязан к накладной - явно нигде не оговаривается что ввод на основании - ДЛЯ ОБЛЕГЧЕНИЯ заполнения документов по большей части...

(73) Что-то ты злой сегодня...

(74) я не злой, я - справедливый

Вы не много не понимаете специфики в (0). У них 3000 документов в день. Соответственно стандартные механизмы от 1С  организации взаиморасчетов убьют эту базу по быстродействию за 1 день.
  У меня примерно такая же логика реализации взаиморасчетов. Для 10 000 контрагентов и количестве документов порядка 500 тыс в год, время формирования отчета по взаиморасчетам при периоде анализа год - где-то час. Для десятка контрагентов отчет работает быстрее типовых, но в отличии от типовых все цифры всегда верные и не зависят от ГП. Плюс база летает.
  Реализовано все это не на дереве подчиненности, а на регистре Взаиморасчеты. При регистр пишется информация о взаиморасчетах, типа Сумма, Клиент, Договор, ДокументОснование, ВидОперации. Отчет все это анализирует.
Из плюсов базу сворачивать не надо. Сейчас эта база свернута по 2006 год. К слову время свертки базы порядка 30 мин. Ну и размер базы под 20 Гигов.

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

(77) ай, малацца! ;-)

(77) отжиг про "супербезопасные внешние отчеты в режиме рид-онли" - заценил....

(79)
(на тему "что ты не мой лопущок, а я не твой Андрейка" "Жуков")

В рассылке трафик с утра
усилился 100-кратно,
Я кинул фото туда,
Чтоб было всем приятно,
Мне модератор письмо
(Не знаю, правда, он ли?)
Прислал, его прочитав
Узнал, что я - READ ONLY!

Ай я-и я-и я-а-а-а... Я - READ ONLY,
Ай я-и я-и я-а-а-а... Я - READ ONLY,

Могу я только читать,
А мне писать бы лихо,
Свой острый ум показать,
А то в рассылке тихо -
Нет не попыток флеймить,
Ни матершинной кровли,
А потому все, етить!
Я сейчас - READ ONLY

Ай я-и я-и я-а-а-а... Я - READ ONLY,
Ай я-и я-и я-а-а-а... Я - READ ONLY,

Мне жарко не от жары,
Стал что-то вежлив трафик,
Все те же "будьте добры",
Все те же "Здрасьте" нафиг,
Все тех же слов оборот -
"Экскьюз" ли там, "Пардон" ли,
Но подождите, вот,
Я выйду из READ ONLY!

Ай я-и я-и я-а-а-а... Я - READ ONLY,
Ай я-и я-и я-а-а-а... Ты - READ ONLY,
Ай я-и я-и я-а-а-а... Он - READ ONLY,
Ай я-и я-и я-а-а-а... Мы - READ ONLY!

(76) 3000 документов в день - это 90 тыс в месяц.
У меня порядка 130 тысяч, используются практически типовые механизмы.
Отчет по взаиморасчеам за год в разрезе только контрагентов (6288 контрагентов)-1 минута 10 секунд.
Просрочка с разбивкой по периодам просрочки и документам - та будет около часа. в принципе, знаю как ускорить примерно на порядок - но лениво, ибо переходим таки на снеговика.

12

да....Вы таки были правы на все 150%. учет таки убит. вернее он не убит, он просто не такой, как у нормальных людей. куча условностей, куча правил левых, куча самодописаного, и написанного криво, хотя можно было тупо юзать штатные средства, но нет - изобретают велосипед. причем вместо имеющегося вполне приличного заводского - делают трехколесный калич, который еще три человека толкать и поддерживать должны. сегодня оказалось, что некоторые расходники закрываются приходным кассовым с пометкой "только регистрация", т.е. не делающим движений. сцууууууко.....

(83) "мы давно играем"©

(81) сколько строк суммарно в этих 130 тысячах документов в месяц?

(85) ну, на 15 умножь - не ошибешься.

дайте базопузомер у себя посчитать!

(87) напиши!
делов-то - три цикла....

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