• Начало

• Hare.ru @ дикое место
  • Лирика
  • Политика
  • Хай-тек
  • Синема
  • Лирика 2
• Hare.ru @ коллективный разум
  • Бухгалтерия и прочий учёт
  • Концептуальные работы
  • Полезные технологии
  • Собственные руки TM
• О проекте
• Информация
  • Реклама
  • Телеканал Россия 1 на компьютере

Концептуальные работы

Все статьи раздела

Групповое проведение документов. Ускоряемся?

Павел Шемякин (toypaul) (июль 2002)

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

Довольно часто при решении задач в системе 1С:Предприятие возникает необходимость в групповом проведении документов. Одна из основных причин – исправление ошибок, которые могут возникнуть за какой-либо прошлый период. Иногда это является частью алгоритма работы. Например, в течение одного месяца ведется только количественный оперативный учет, а затем, в конце месяца, формируются бухгалтерские проводки и суммовой учет в оперативной подсистеме. Есть еще много причин, но статья посвящена не этому.

Цель статьи – разобраться, как можно ускорить выполнение этой задачи в системе 1С:Предприятие 7.7 (версия для SQL). Довольно часто приходится слышать, что в этой версии групповое проведение работает значительно медленнее, чем в DBF-версии.

Сразу хочу заметить, что групповое проведение в 1С можно реализовать несколькими способами: своей обработкой, через меню «Операции – Проведение документов». При этом второй способ, как вы наверное могли заметить, работает быстрее, нежели проведение документов с помощью обработки (по сути это перепроведение документов с помощью метода Провести).

Дело в том, что, как мне кажется, в этом случае система оптимизирует расчет остатков при проведении документов. Во всяком случае, наблюдения за системой через Profiler, подтверждают такой вывод. Я не обнаружил сложных вычислений остатков, а также увидел некоторые «подозрительные» манипуляции с таблицей остатков. Долго разбираться не хватило сил – при проведении всего двух документов список сообщений в Profiler состоял из нескольких десятков страниц.

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

На этом закончим рассмотрение стандартных способов оптимизации. Перейдем к основной части статьи – оптимизация с использованием собственных алгоритмов. Почему слово «ускоряемся» стоит под знаком вопроса? Да потому, что это всего лишь теоретические выкладки, которые нужно проверять на практике и, что самое главное – произвести сравнение со стандартными методами. Если вдруг случится такое невероятное событие, что у меня появится неделька свободного времени, то вполне возможно, что я проведу такие испытания и при их успешном завершении (то есть если будет получен значительный выигрыш производительности) включу данную возможность в свою компоненту ToySQL.

Итак, (наконец-то ;-) сам алгоритм.

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

Хотя можно внести изменения в алгоритм так, чтобы лишние данные удалялись – проще всего это будет делать, если проведение документов идет в одном направлении (по времени). Обычно это так, но пока оставим рассмотрение данного момента на потом.

Остатки будем хранить только по тем позициям, для которых они рассчитываются в текущем документе. Этот момент очень важен. Например, если документы проводятся только по определенным позициям или если случилось так, что в этом периоде по документам «прошло» только какое-то подмножество измерения регистра, то расчет остатков существенно ускорится. Таким образом, достигается высокая гибкость алгоритма. Также важный момент алгоритма в том, что не обязательно проведение документов производить в одном направлении, так как остатки хранятся и за предыдущие дни.

Рассмотрим работу алгоритма на одном регистре.

Алгоритм

Алгоритм будет выглядеть так:

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

Пояснения для математически неграмотных ;-):

Таблица остатков и движений суть функции по измерениям и периоду (дате). Значение функции в общем случае числовой вектор. В моем случае ресурс один. Документ рассматриваем как множество кортежей, то есть реляционная таблица. Считаем, что все значения реквизитов и значение даты документа хранятся в одной таблице. Промежуточная таблица итогов похожа на таблицу остатков с той лишь разницей, что периодичность их хранения один день. Функция расчета остатка – понятно без объяснений (так считает остатки сама V7). На выходе мы должны получить функцию аналогичной Ф, результат вычисления которой для последовательности документов ДП будет более оптимальным с точки зрения производительности.

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

Пояснения к самому алгоритму. Для каждого документа мы находим множество измерений (НадоСчитать), которые отсутствуют во временной таблице. Затем в таблице итогов выбираем остатки, которые максимально близки к необходимым для расчета, содержащимся в множестве НадоСчитать. Добавляем во временные итоги вновь рассчитанные остатки. Первая часть по множеству измерений, которые «отталкиваются» от таблицы временных итогов, вторая часть рассчитывается с помощью «неоптимизированной функции». В конце считаем остатки на документ – из остатка на дату документам, которые берутся из временных итогов, вычитаем лишние движения.

Вот и все. Остается произвести оценку алгоритма, как было описано выше, и затем подтвердить ее на практике.

Приложение. Реализация на T-SQL

Здесь я рассмотрю некоторые шаги алгоритма, реализованные на T-SQL. Структура таблиц (похожа на 1С, но не совсем):

Регистр

Итоги (rg)
izm0
izm 1
Period
Res

Движения (ra)

Izm0
Izm1
Datedoc
Time
Debkred
Res

Остальные таблицы имеют структуру аналогичную итогам регистра. @DateDoc – дата текущего документа, @Timedoc – время текущего документа, @BegMonth – начало месяца для @DateDoc.

Определение множества НадоСчитать:

Определение множества Втаблице:

Расчет остатков по множеству Втаблице:

Расчет остатков, которых нет в таблице временных итогов:

И наконец получение самого остатка:

P.S.

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

Партнеры: