Как ускорить проводку СФ?

[ATimTim]

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

P.S. Искал на форуме по ключевым словам ускорить проводку , оптимизировать обработку ... но не нашел.
Хотя помню, что что-то подобное видел на форуме.

[George Nordic]

1) Доработки были?
2) Да, даже в стандарте, это русская функиональность. Довольно тормозная - накладная раза в 3 быстрее разноситься, нежели СЧ-Ф.
3) Попробуйте добавлять в пакет. Или СЧ-Ф сразу нужна?

С Уважением,
Георгий

[ATimTim]

Цитата:

1) Доработки были?

Доработки были, конечно. как же без них =)

Цитата:

2) Да, даже в стандарте, это русская функиональность. Довольно тормозная - накладная раза в 3 быстрее разноситься, нежели СЧ-Ф.

Вот-вот, мониторинг SQL запросов при обработке СФ показал, что самое большое время выполняется запрос

PHP код:

select * FROM FACTURETRANS_RU A,CUSTINVOICETRANS B,CUSTINVOICEJOUR C,CUSTTRANS D,LEDGERTRANS E  where ...... 


, потом - работа с номер. сериями .... и последний в хитпараде SalesPamLine

Цитата:

3) Попробуйте добавлять в пакет. Или СЧ-Ф сразу нужна?

Нужна сразу.

[ATimTim]

Никто не решал такую задачу?

[George Nordic]

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

С быстродействием - так пока и не удалось победить. Нам обещали помочь, так что, если удасться победить, расскажем, как там да что.

Очень не нравяться тормоза из-за номерных серий. Процессор не нагружен ни на АОСе, ни на БД. В чем дело - не понимаем. sleep(1000) тоже не нашли пока.

С Уважением,
Георгий.

[ATimTim]

Да, неутешительно ...

[bio_unit]

Найдите метод document на таблице FactureJour_RU, замените тело метода на
return ["", dateNull()];
вместо того лютого запроса который там есть
и будет вам счастье

[ATimTim]

А что это за волшебный такой метод?
Почему его так безболезнено можно "отключить" ?

[AndyD]

Этот метод формирует запрос который у вас фигурирует под номером 1 в хит-параде.

Вызов его находится в методе insertJournal класса FactureJourCreate_RU. Возвращаемые им значения (Номер последнего сопоставления и его дата) в дальнейшем используются при печати счета-фактуры (строка "К платежно-расчетному документу" "№:" и "от:"). Если верить перекрестным ссылкам, то эти значения ни в каких обработках не участвуют

Ну и если уж править, то, по-моему, лучше закоментарить вызов метода document в FactureJourCreate_RU.insertJournal

[ATimTim]

Спасибо.

[MironovI]

Была такая же ситуация, накладная быстро, СФ ну очень долго.. все что можно заоптимизил, выборку лишних полей и т.д.. на этом работа мониторинга SQL закончилась но тормоза остались, запускаю профайлер кода и вижу - строка SetPrefix('блабла'); Занимает 700000 милисекунд, каково? Убрал, пока все оки.. вот такая вот история..
Да, а по поводу номерных серий - для тех что НЕ непрерывные можно использовать предварительное выделение номеров, тоже оч помогает..

[DreamCreator]

Цитата:

Сообщение от MironovI

запускаю профайлер кода и вижу - строка SetPrefix('блабла'); Занимает 700000 милисекунд, каково? Убрал, пока все оки.. вот такая вот история..

А можно узнать место?

[MironovI]

Вроде как класс PurchFormLetter, метод run там setPrefix("@SYS25781");

[DreamCreator]

Спасибо!

[Алексей Контев]

При обработке с/ф по накладной очень долго вызывается форма "Обработка счета-фактуры".
При анализе выяснилось, что максимальная задержка в методе
FactureEditLinesEngineVend_RU\dsExecuteMarkup
Там стоит такой загадочный код:

    select markupCursor
        where   markupCursor.CustVendPosted_RU                         &&
                  ! markupCursor.ItemPosted_RU
    exists join tTrans
        where (markupCursor.TransTableId  == tTrans.TableId            &&
                  markupCursor.TransRecId    == tTrans.RecId              &&
                  tTrans.PurchID             == tJour.PurchId             &&
               tTrans.InvoiceId           == tJour.InvoiceId           &&
               tTrans.InvoiceDate         == tJour.InvoiceDate         &&
               tTrans.NumberSequenceGroup == tJour.NumberSequenceGroup &&
               tTrans.InternalInvoiceId   == tJour.InternalInvoiceId
              )              ||
              (
               markupCursor.TransTableId  == tJour.TableId             &&
               markupCursor.TransRecId    == tJour.RecId
              );

После изменеия его на

    select markupCursor index TableRecIdIdx
        where   markupCursor.CustVendPosted_RU                         &&
              ! markupCursor.ItemPosted_RU                             &&
               markupCursor.TransTableId  == tJour.TableId             &&
               markupCursor.TransRecId    == tJour.RecId;

    if (!markupCursor)
        select markupCursor
            where   markupCursor.CustVendPosted_RU                         &&
                  ! markupCursor.ItemPosted_RU
        exists join tTrans index InvoiceIdx
            where
                   markupCursor.TransTableId  == tTrans.TableId            &&
                   markupCursor.TransRecId    == tTrans.RecId              &&
                   tTrans.PurchID             == tJour.PurchId             &&
                   tTrans.InvoiceId           == tJour.InvoiceId           &&
                   tTrans.InvoiceDate         == tJour.InvoiceDate         &&
                   tTrans.NumberSequenceGroup == tJour.NumberSequenceGroup &&
                   tTrans.InternalInvoiceId   == tJour.InternalInvoiceId;

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