Групповое проведение документов. Штатные методы оптимизации.

автор статьи: Виктор Болбат (Enot)

Источник hare.ru

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

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

Действия, производимые при проведении документа, можно условно (как мне сейчас удобно) разбить на следующие части (которых может и не быть в реальных документах):

Установка периодических реквизитов справочника.
Запись бухгалтерских проводок. Напомню, что при этом происходит не только запись в журнал проводок, но и обновляются бухгалтерские итоги (далее БИ).
Запись движений регистров. Как и в случае с проводками, дополнительно обновляются итоги.
Запись записей журнала расчетов (по данной части я не имею глубоких познаний и поэтому далее рассматривать не буду).
Выполнение запросов для получения данных по оборотам и остаткам БИ.
Выполнение запросов для получения данных по оборотам и остаткам регистров.
Запись данных, за исключением предыдущих пунктов.
Чтение, анализ данных.

Что можно сделать со всем этим? Сразу можно откинуть п.8, оптимизировать здесь нечего.

Для оптимизации любой записи данных (в том числе и движений документа) можно воспользоваться механизмом транзакций. Для этого перед стартом групповой обработки выполняется команда НачатьТранзакцию(), а в конце ЗафиксироватьТранзакцию(). Именно так сделано в обработке "ОбработкаДокументов", в случае НЕ монопольного подключения к базе. Приблизительный смысл в том, что в процессе проведения запись данных в базу не производиться, а накапливается в буфере. После окончания проведения, все изменения записываются пачкой.

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

Есть и недостаток если документов проводиться очень много (или данных много), то буфер, в котором накапливаются изменения, сам становиться узким местом (деталей внутренней организации транзакций я не знаю, но на практике это выглядит именно так). Оптимальной является следующая тактика: разбить всю массу документов на пакеты (количество документов в пакете подбирается экспериментально, исходя из обЪёма данных, хранимых в документе) и проведение каждого пакета оформляется в виде транзакции.

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

Возможно несколько вариантов оптимизации:

Можно установить бухгалтерские итоги на начало всех времен. При этом обновление их происходить не будет. Максимальная скорость записи проводок. Но этот метод можно использовать только в специфических случаях, т.к. в процессе проведения часто (как правило) возникает необходимость получения данных БИ. Этот способ рекомендуется для документов, которые не обращаются БИ в модулях проведения.

Можно воспользоваться методом Актуальность() обЪекта БухгалтерскиеИтоги (можно подсмотреть реализацию в обработке "ОбработкаДокументов"). Смысл в том, что обЪект БухгалтерскиеИтоги будет поддерживать БИ в актуальном состоянии при проведении документов. При обновлении БИ, данные будут браться из обЪекта БухгалтерскиеИтоги,/tt> (здесь я не уверен, а если точнее не помню, сказывается ли это на скорости записи проводок, или нет).

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

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

Запросы r БИ при проведении документов, как правило, выполняются на дату документа (вернее, на "начало" документа). Например, чтобы рассчитать цену, исходя из текущих остатков. Для оптимизации скорости выполнения именно таких запросов (если запрос выполняется на произвольную дату, то ничего сделать не получится) можно воспользоваться рассмотренными выше методами: использование встроенного механизма "Проведение документов" или метода Актуальность() обЪекта БухгалтерскиеИтоги. БИ будут браться из временных данных (текущих итогов), а не рассчитываться с начала периода итогов (квартала).

Кроме того, если используется метод БИ.Рассчитать(ТекущийДокумент()) и, соответственно, далее пользовать функции СКД(), то можно воспользоваться функцией ИтогиАктуальны(), если она возвращает единицу, то выполнять метод БИ.Рассчитать(ТекущийДокумент()) не надо, можно сразу обращаться к итогам. Выигрыш в скорости проведения получается очень большой.

Оптимизация запросов к итогам регистров похожа на оптимизацию запросов к БИ. Если документ двигает ТА, то можно сразу же обращаться к итогам. Это проверяется точно так же, функцией ИтогиАктуальны()

Подведем итог. Что нужно в модулях проведения:

Для оптимизации записи движений никаких действий предпринимать не надо.
Для получения итогов регистров необходимо выбирать остатки или выполнять запросы на ТА. Перед этим всегда нужно проверять актуальность итогов.
Для получения БИ в случае выполнения запроса (в том числе при помощи обЪекта БухгалтерскиеИтоги) никаких действий предпринимать не надо. В случае прямого обращения к БИ без запроса, нужно предварительно проверять необходимость выполнения расчета (актуальность итогов).

Для группового проведения документов необходимо пользоваться:

Встроенным механизмом "ПроведенияДокументов". Это самый оптимальный и универсальный вариант.
Дополнительной обработкой с использованием транзакций и проведением пакетами. Например, "ОбработкаДокументов" НЕ в монопольном режиме (именно в этом режиме включаются транзакции в данной обработке). В некоторых случаях (незначительное использование регистров и проводок, отсутствие обращений к итогам) получается значительный выигрыш по сравнению с предыдущим методом.
Дополнительной обработкой, которая поддерживает итоги в актуальном состоянии с проведением документов. Например, "ОбработкаДокументов" В монопольном режиме (именно в этом режиме поддерживаются актуальными итоги). Работает медленнее первого варианта (хотя, существуют случаи, когда быстрее, из-за оптимизации БИ по счетам), но незначительно.
Дополнительной обработкой, которая использует п.2 и п.3. В обработке "ОбработкаДокументов" одновременно эти методы не используются. Почему, я не знаю. Практическая проверка показывает, что всё работает нормально. Но, на всякий случай, используйте этот метод с осторожностью.

Эффект сильно зависит от каждого конкретного случая, но, как правило, при грамотной оптимизации штатными методами производительность уведичивается в разы.