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

Очевидно, что при создании конфигурации 1С:Предприятия, как и при разработке любой системы автоматизации в сфере экономики все решения принимаются как компромисс между удобством работы пользователей, функциональной сложностью конфигурации и быстродействием системы. Причем, при увеличении объемов обрабатываемой информации и количества одновременно работающих пользователей следует внимательнее подходить к оценке необходимости предоставляемых пользователю сервисных функций и искать пути к оптимизации разрабатываемой конфигурации. Заметим, что оптимизация конфигурации далеко не всегда сопровождается снижением уровня сервиса. В этом разделе мы дадим несколько рекомендаций по разработке конфигураций 1С:Предприятия предназначенных для использования с большими объемами данных и в многопользовательском режиме.

Прежде всего, заметим, что работа системы в многопользовательском режиме выполняется медленнее, чем при монопольном запуске. Эта разница существенна для версии, работающей с базой данных в формате DBF. Замедление работы системы объясняется тем, что механизм работы с базой данных учитывает возможные изменения данных другими пользователями. В связи с этим в производительности многих режимов, например, формировании отчетов или заполнении документов, при многопользовательской работе более существенную роль начинает играть именно доступ к данным, а не отработка алгоритмов встроенного языка. То есть при проектировании конфигурации,

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

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

Интерактивные и пакетные режимы

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

Предоставляемые средства системы 1C:Предприятие ориентированы на то, чтобы интерактивные режимы работали с приемлемой производительностью при любых объемах данных. Этим объясняется, например, отсутствие возможностей просмотра журналов документов и списков справочников с произвольным фильтром по некоторому условию, так как эти режимы просматривают данные непосредственно в информационной базе, без предварительной выборки. Предоставленные возможности отборов в журналах документов опираются на специальные механизмы, позволяющие просматривать документы интерактивно с определенной выборкой. Однако заметим, что чем больше обычно объем информационной базы в экономической системе, тем меньше предусматривается режимов динамического просмотра информации.

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

Использование "длинных путей"

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

ЦенаТовара=Накл.Товар.Цена;

Если такое обращение выполняется многократно (например, в цикле) или выполняется обращение к нескольким атрибутам и методам одного атрибута агрегатного объекта, то целесообразно вначале запомнить атрибут в переменную, а затем использовать запомненное значение. Например:

Тов=Накл.Товар.Цена;

ЦенаТовара=Тов.Цена;

Это объясняется тем, что при обращении к атрибуту объекта, если атрибут имеет тип "документ", "справочник" или "счет", то выполняется поиск объекта в информационной базе. Если такое обращение происходит многократно, то поиск выполняется каждый раз. Если выполняется обращение к одной и той же к запомненной переменной, то поиска в информационной базе не происходит.

Использование длинных строк в индексируемых данных

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

При большом объеме справочника можно рекомендовать ограничить наименование справочника 30 символами, а полное наименование записывать в отдельный реквизит. Для реквизитов, по которым устанавливается отбор и для разделителя учета не рекомендуется использовать строки больше 20 символов.

Использование преобразований типов во встроенном языке

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

Приведем пример. Необходимо выполнить некоторые действия в модуле для непустых значений атрибута или переменной типа справочник. Иногда для этого используется проверка типа:

Если ПустаяСтрока(Запрос.Товар)=1 Тогда

…

или

Если СокрЛП(Запрос.Товар)="" Тогда

…

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

Для проверки такого значения следует использовать функцию "ПустоеЗначение", которое выполнит проверку без считывания данных элемента справочника.

Если ПустоеЗначение (Запрос.Товар)=1 Тогда

…

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

Определение производительности конфигурации

При возникновении проблем с производительностью работы конфигурации для определения возможных путей оптимизации следует произвести замер времени выполнения тех или иных алгоритмов для выявления "узких мест".

Разумеется, идеальным способом измерения производительности является тестирование конфигурации непосредственно в процессе работы пользователей. Однако, конфигурирование (отладка) часто выполняется на тестовой информационной базе или в нерабочее время. В этом случае при выполнении замеров производительности необходимо правильно воссоздать реальные условия работы системы. В противном случае соотношения временных затрат на различные операции может абсолютно не соответствовать "боевым" условиям. Прежде всего, необходимо, чтобы информационная база располагалась на сервере локальной сети, а не на той же машине, на которой выполняется программа. Разумеется, формат хранения (DBF/CDX или SQL) тестовой базы

должен совпадать с форматом хранения "боевой" информационной базы. Желательно, чтобы по характеристикам сервер и локальная сеть были теми же, что и при работе пользователей или аналогичными. Запуск программы должен производиться не в монопольном режиме, так как монопольный режим существенно отличается по производительности от разделенного. Кроме того, при работе с базами данных в формате (DBF/CDX), следует выполнять дополнительный запуск программы с той же информационной базой с другого компьютера, так как отсутствие второго соединения позволяет системе оптимизировать доступ к данным. Наконец для более полной имитации можно рекомендовать на втором компьютере запустить длительный отчет, который будет имитировать нагрузку пользователей или обработку, выполняющую в цикле запись некоторых данных в информационную базу. При таком наборе условий производимые замеры будет приближены к реальным условиям, и позволят получить адекватную оценку соотношения длительности различных операций.

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

Заметим, что основные проблемы, связанные с производительностью, возникают при многопользовательской работе с большими объемами данных. Причем основные затраты времени приходятся именно на доступ к данным информационной базы. Поэтому, очевидно, что при анализе результатов замера производительности, прежде всего, будут выделяться обращения к данным. Для того, чтобы лучше выделить эти операции можно рекомендовать отключать флажок "Для вызовов процедур и функций включать время выполнения". Это позволит получить чистое время выполнения различных методов объектов встроенного языка 1С:Предприятия. По результатам проведенного замера следует предпринимать меры к оптимизации алгоритмов. Механизм "Замер производительности" предоставляет возможность сохранения результата замера, что позволяет после внесения изменений в конфигурацию выполнить повторный замер и сравнить с предыдущим для оценки эффективности сделанных изменений.

Оптимизация работы Справочников

Справочники

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

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

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

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

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

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

- Периодическим реквизитам. Размещение в колонках списка большого количества периодических реквизитов замедляет просмотр списка.

- Строкам неограниченной длины. Наличие в колонках таких реквизитов так же замедляет просмотр.

- Реквизитам типа "Справочник", "Документ", "Счет". Отображение таких реквизитов требует выборки представлений их значений из информационной базы.

- Формулам, осуществляющим выборку данных из информационной базы.

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

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

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

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

Оптимизация работы документов

Документы

Общие реквизиты.

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

Общие реквизиты с признаком "Отбор".

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

Строковые реквизиты неограниченной длины.

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

Номера документов.

Использование нумераторов в документах никак не влияет на производительность. Однако, не рекомендуется задавать в метаданных слишком длинные номера документов даже у редко встречаемых документов. Ресурсы системы, используемые для поддержки номеров документов, зависят от максимальной длины номера среди документов всех видов.

Реквизиты типа "Документ".

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

Формы ввода документов

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

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

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

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

Разумеется, ввод товаров существенно ускоряет использование сканеров штрих-кодов. При использовании сканера вместо разворачивания спискасправочника происходит всего один поиск товара по считанному коду.

Если заполнение накладной может быть выполнено на основании счета, то это также существенно уменьшит количество обращений к информационной базе, да и упростит работу оператора.

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

Например, это могут быть поля, предназначенные для вывода текущего количества товаров на складе, текущего состояния взаиморасчетов и т.д. Важно учитывать, что их значения часто пересчитываются при вводе информации в форме документа. Для снижения влияния таких полей на скорость работы системы можно привести следующие рекомендации: Если вычисляемые элементы диалога типа "Текст", предназначенные для вывода справочной информации при заполнении документа обращаются к данным информационной базы, например, получают текущие остатки товара, то рекомендуется помещать их не в табличной части, а непосредственно в диалоге. В этом случае, например, текущий остаток будет выдаваться не по каждой строке, а только по той, на которой находится курсор и обращений к данным будет значительно меньше.

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

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

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

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

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

Журналы документов

Обычные журналы.

К обычному журналу прикрепляются документы различных видов в окне настройки документов. Документ может принадлежать только к одному из таких журналов. То есть все документы разделены между созданными обычными журналами. Количество таких журналов не влияет на производительность системы и размер информационной базы.

Общие журналы.

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

Дополнительные журналы.

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

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

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

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

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

Проведение документа (отмена проведения)

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

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

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

момент документа или выполнив запрос с конечной границей указанной вкачестве текущего документа. При большом объеме операций временный расчет может выполняться достаточно долго. В связи с этим крайне не желательно частое проведение документов задним числом. Типичной ошибкой пользователей является ввод и проведение документа завтрашней датой. После этого все сегодняшние документы проводятся задним числом.

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

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

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

Следует учитывать, что при выполнении запроса или временного расчета объекта "БухгалтерскиеИтоги" с конечной границей заданной в качестве текущего документа программа будет обрабатывать все проводки от конца месяца до данного документа. Следовательно, для документов, обращающихся к данным бухгалтерских итогов, последовательный ввод и проведение, будет выполняться эффективнее, чем проведение документов задним числом. Метод "ЗаписатьПроводки" следует использовать только в том случае, если в последующем алгоритме необходимо обращение к итогам с учетом уже внесенных в операцию проводок, если такие обращения не выполняются, то метод

"ЗаписатьПроводки" использовать не нужно, так как проводки будут автоматически записаны при записи операции.

Разумеется, из-за особых требований к производительности алгоритма проведения с для его оптимизации следует максимально использовать приведенные в данной рубрике рекомендации по увеличению производительности всех используемых в процессе проведения механизмов. Прежде всего, имеет смысл обратить внимание на оптимизацию работы объектов "Запрос" и "БухгалтерскиеИтоги", возможности настройки отборов регистров и бухгалтерских данных, а также на общие рекомендации по использованию встроенного языка.

Графы отбора

Определение граф отбора является одним из наиболее ответственных моментов с точки зрения производительности системы.

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

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

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

В отличии от общих реквизитов документов, которые также позволяют организовать отбор по некоторому значению, графы отбора допускают вхождение одного документа к нескольким значениям графы отбора. Например, создана построена графа отбора "Склад". Для накладной на внутреннее перемещение к графе отбора прикреплены реквизиты "СкладОткуда" и склад "СкладКуда". Данный документ попадает в два отбора по данной графе – по обоим выбранным значениям склада. Если к графе отбора прикреплены реквизиты табличной части документа или, например, данные регистров, то

один документ может быть отнесен к достаточно большому количеству значений

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

Очевидно, что большое количество вхождений документов в графы отбора повлечет существенное увеличение объема информационной базы и увеличения времени затрачиваемого на запись и проведение документа. Еще раз заметим, что объем ресурсов определяется суммарным количеством вхождений документов в графы отбора, которое зависит от количества значений реквизитов, данных регистров и бухгалтерских операций, которые в документах определены для включения документа в графы отбора. Так, в приведенном примере, графа отбора "Склад" вызовет по одному вхождению на приходные и расходные накладные и два вхождения на накладную на внутреннее перемещение. Тогда, как графа отбора "Товар" вызовет столько вхождений, например, расходной накладной, сколько различных товаров она будет содержать, то есть это может быть несколько десятков и несколько сотен записей в списке отбора. Это означает, что при проектировании графы отбора следует также учитывать и предполагаемое среднее количество строк в основных документах. Само количество граф отбора практически не влияет на производительность системы. Так, например, можно сделать одну графу отбора: "Организации" или две графы отбора: "Покупатели" и "Поставщики". При условии, что каждый реквизит документа, который был бы отнесен к графе "Организации" будет отнесен к одной из двух граф отбора, затраты ресурсов системы будут практически одинаковыми.

Теперь рассмотрим использование граф отбора. Можно выделить два основных назначения граф отбора:

1) Отбор документов при просмотре журнала документов.

2) Оптимизация выборки информации в отчетах, обработках и других алгоритмах.

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

1) Графа отбора может быть автоматически использована системой для оптимизации выполнения запроса (объект "Запрос"). Это происходит в случае, если указано условие запроса, определенное равенством переменной запроса конкретному значению (переменной, элементу диалога) и все данные определенные для данной переменной запроса определены также в графе отбора. Например, если запрос строится по регистру взаиморасчетов и условие ограничивает выборку данных одним значением измерения регистра (организацией) и данное измерение регистра включено в некоторую графу отбора, то при выполнении запроса будет использована графа отбора и будут обрабатываться только документы относящиеся к данной организации. Если существует более одной графы отбора которая может быть использована для оптимизации выполнения запроса, то система пытается самостоятельно выбрать графу отбора, разброс значений которой будет максимальным. Существует возможность принудительно указать запросу использование конкретной графы отбора. Она будет использована только в случае соответствия условия запроса структуре графы.

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

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

4) Графа отбора может быть использована для перебора документов по конкретному значению отбора из встроенного языка методом объекта типа "Документ".

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

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

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

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

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

Следует заметить, что в версии 7.7 существует возможность устанавливать отборы движений в свойствах измерений и реквизитов регистров. Установка этих отборов не предоставляет возможности выборки документов при визуальном просмотре, однако их использование существенно ускоряет выборки движений регистров, временные расчеты и выполнение запросов по регистру в случае, если устанавливается условие запроса или фильтр объекта "Регистр" по конкретному значению измерения или реквизита. Эти отборы система использует автоматически, если они установлены в метаданных. Использование для оптимизации выборки движений отборов движений обычно эффективнее использования граф отбора, так как отбираются непосредственно движения, а не документы. Кроме того, поддержание отборов в движениях регистров не столь существенно увеличивает объем базы данных, так как ведется не с помощью отдельной таблицы, а с помощью построения дополнительных индексов.

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

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

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

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

Производительность выборки документов

При необходимости оптимизации выборки (перебора) документов можно учитывать следующие особенности реализации механизмов 1С:Предприятия.

Перебор документов с помощью объекта "Документ" выполняет последовательный обход документов за указанный интервал.

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

Если применять метод "ИспользоватьЖурнал", то при выборке будет использоваться индекс, отбирающий документы определенных видов, входящих в указанный журнал.

Применение методов "ВыбратьПодчиненныеДокументы", "ВыбратьПоЗначению" и "ВыбратьПоПоследовательности" оптимизирует выборку за счет использования индексов и специальной системной таблицы.

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

Применение метода "УстановитьФильтр" ограничивает выборку документов, но практически не ускоряет выполнение выборки, по сравнению с проверкой в алгоритме модуля.

Получение списка документов с помощью объекта "Запрос" с соответствующей группировкой, может выполняться несколько медленнее, при небольшом количестве документов, входящих в интервал. Кроме того, некоторое замедление будет наблюдаться, если затем обращаться к данным документа, так как при этом будет выполняться повторное считывание документа, тогда как объект типа "Документ" считывает часть информации документа непосредственно в процессе перебора.

При работе с базой данных в формате SQL применение запроса будет существенно эффективнее, чем перебор с помощью объекта "Документ" в том случае, если выполняется отбор документов по некоторому условию. Выборка документов объектом "Запрос" будет производиться средствами SQL-сервера. Разумеется, для этого должны быть учтены рекомендации по составлению условий запросов оптимизируемых при работе с базами данных в формате SQL.

Оптимизация работы с Константами

При обращении в алгоритме модуля к константе 1С:Предприятие извлекает значение константы из информационной базы. Причем это касается и периодических и непериодических констант. Если обращение к константе выполняется в алгоритме многократно, то использование конструкции "Константа.ХХХХХ" может существенно сказываться на производительности выполнения модуля. Поэтому целесообразно запомнить полученное значение в переменной и использовать в алгоритме запомненное значение.

Оптимизация работы компоненты “Бухгалтерский учет”

Проектирование документов

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

При проектировании документов конфигураций ориентированных на большой объем данных следует рассмотреть вопрос о целесообразности записи операций по тем документам, которые не формируют бухгалтерских проводок. В типовой конфигурации 1С:Бухгалтерии 7.7 (редакции 3.1) предусмотрена возможность записи операции для всех документов, в том числе и для тех, которые никогда не формируют проводок (платежных поручений, доверенностей и т.д.). Такое решение принято для удобства просмотра бухгалтером всех документов в едином журнале операций, то есть для упрощения освоения программы и работы с небольшой информационной базой.

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

Для документов, которые относятся к оперативному учету, но формируют также проводки можно рекомендовать использовать вариант параметра "Создавать операцию": "Только при проведении". Это позволит исключить хранение избыточной информации по конкретным документам, которые не должны отражаться в бухгалтерском учете. При их проведении алгоритм модуля документа может не создавать операцию и не записывать проводки.

Проектирование плана счетов

При проектировании плана счетов не следует устанавливать максимальное количество субконто больше, чем реально необходимо для организации аналитического учета по счетам. Установленное максимальное количество субконто влияет на общую производительность системы. Собственно количество видов субконто для конкретного счета не оказывает сильного влияния на время отражения проводки в учете, однако объем хранимых итогов зависит от количества используемых комбинаций значений субконто счетов. Кроме того, увеличение количества видов субконто указанных для конкретного счета влияет на скорость формирования отчета по отдельным значениям субконто. Так, например, если по счету товаров велся учет в разрезе номенклатуры и вводится второе субконто "склады", то количество хранимых итогов несколько увеличится и скорость формирования отчета по остаткам товаров в целом (на всех складах) будет немного ниже, за счет того, что будут суммироваться хранящиеся остатки товара на разных складах. Разумеется, замедление будет зависеть от среднего количества складов, на которых хранятся различные товары.

При проектировании аналитического учета рекомендуется придерживаться правильного использования механизма субконто. Субконто должны использоваться для учета остатков и оборотов по счетам в разрезе объектов аналитики. Не следует использовать субконто в качестве комментариев к проводкам не отражающих структуру остатков или оборотов. Для комментирования проводок рекомендуется использоваться реквизиты проводок или операций.

Заметим, что если вид субконто для конкретного счета используется для хранения остатков, то есть, не включается признак "Только обороты", то суммы по счету должны и дебетоваться и кредитоваться по всем используемым объектам аналитики. Если использовать субконто по счету, например, только для отражения кредитовых проводок, а для дебетовых использовать другие значения субконто или не указывать их вовсе, то объем хранимых итогов будет расти от периода к периоду, и доступ к итогам по аналитике будет замедляться.

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

Введение дополнительного плана счетов практически не сказывается на производительности конфигурации.

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

Работа с бухгалтерскими итогами

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

Для оптимизации получения бухгалтерских итогов в наиболее типовых ситуациях система хранит и динамически обновляет при записи проводок следующие виды итогов:

- остатки по счетам и объектам аналитики;

- обороты по счетам и объектам аналитики;

- обороты между счетами.

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

При использовании объекта "БухгалтерскиеИтоги" в режиме временного расчета или запроса следует обращать внимание на возможность ограничения с помощью различных параметров объема обрабатываемых данных. Это касается и расчета только по синтетическим счетам и расчета данных по остаткам и оборотам и оборотам между счетами. В критичных по времени алгоритмах рекомендуется максимально сузить объем данных обрабатываемых этими режимами. Кроме ограничения обрабатываемых данных по отдельным видам итогов существует возможность указать системе список значений для обрабатываемых счетов и субконто. Это позволяет уменьшить объем обрабатываемой информации и соответственно увеличить производительность.

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

Заметим, что выполнение запроса и временного расчета объекта "БухгалтерскиеИтоги" оптимизировано для получения данных на момент последних введенных операций месяца. То есть при последовательном вводе и

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

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

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

Получение развернутых сальдо может потребовать достаточно продолжительного времени, при большом количестве итогов по объектам аналитики или по субсчетам.

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

Аналогично итоги по субконто типа "Справочник" хранятся только по элементам. Поэтому получение итогов по группам справочника может выполняться значительное время при большом количестве элементов в группе. При получении итогов объектом "БухгалтерскиеИтоги" в режиме "Запрос" формирование итогов по счетам-группам и группам справочников не сильно замедляет выполнение операции, так как обычно извлекаются не только итоговые, но и детальные данные.

При использовании в конфигурации разделителя учета получение итогов с помощью объекта "БухгалтерскиеИтоги" может выполняться заметно дольше, если не указать конкретное значение разделителя учета, то есть получать итоги по всем значениям. Система хранения бухгалтерских итогов оптимизирована для получения данных по отдельным значениям разделителя учета, так как такие обращения выполняются значительно чаще. Рекомендуется указывать объекту "БухгалтерскиеИтоги" конкретное значение разделителя учета во всех случаях, кроме тех, когда действительно необходимо получить данные по всем значениям разделителя учета.

При использовании объекта "БухгалтерскиеИтоги", часто существует возможность получения одной и той же информации как с помощью непосредственного обращения к итогам, так и с путем выполнения запроса. Разумеется, чаще всего решение принимается, прежде всего, с точки зрения оптимизации производительности. Обычно, если необходимо получить большое количество итогов, например остатки по всем материалам, то выполнение запроса и обход его результатов будет эффективнее, чем обход справочника и обращение к методам получения итогов по каждому элементу справочника. Разумеется, сравнение этих двух вариантов в конкретном алгоритме следует проводить в "боевых условиях", то есть в разделенном режиме (при использовании сетевой версии), на реальной нагрузке системы и на реальных объемах информации. Заметим, что если необходимо получение итогов по отдельным значениям, а не по всему списку, то при использовании запроса существует возможность с одной стороны ограничить выборку списком значений (счетов или объектов аналитики), а с другой стороны в уже сформированном запросе не перебирать все значения подряд, а выбирать итоги по отдельным значениям. При работе с версией 1С:Предприятия для SQL использование запросов может быть еще более эффективно по сравнению с обращением к отдельным итогам в связи с тем, что большинство запросов оптимизируется средствами MS SQL Server.

В отдельных случаях использование объекта "БухгалтерскиеИтоги" может быть оптимизировано с помощью применения метода "Акутальность". Прежде всего, он применяется в монопольном режиме для оптимизации группового перепроведения документов средствами встроенного языка. В типовой конфигурации 1С:Бухгалтерии 7.7 такая оптимизация реализована в обработке "ОбработкаДокументов".

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

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

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

Если в настройке планов счетов в конфигурации установлен разделитель учета, то при использовании объекта "БухгалтерскиеИтоги" существует возможность указывать конкретный разделитель учета (с помощью метода "ИспользоватьРазделительУчета") или получать итоги по всем значениям разделителя учета. Механизм компоненты "БухгалтерскийУчет" оптимизирован для получения итогов по конкретным значениям разделителя учета. Обращение к итогам по всем значениям производится существенно медленнее. На практике в большинстве случаев обращение к бухгалтерским итогам выполняется именно по конкретным значениям разделителя учета. Рекомендуется во всех случаях использования объекта "БухгалтерскиеИтоги" устанавливать конкретное значение разделителя учета, кроме тех случаев, когда получение итогов по

всем значениям действительно необходимо.

Заметим, что часто из-за особенностей решаемой задачи в алгоритме, в котором не указан конкретный разделитель учета, данные формируются вполне правильно. Например, в информационной базе реально введено только одно значение разделителя учета. В этих случаях тот факт, что конкретный разделитель учета не задан, будет сказываться только на производительности, и может быть не обнаружен при тестировании. Таким образом, при работе с конфигурациями, в которых используется разделитель учета, следует внимательно следить за использованием объекта "БухгалтерскиеИтоги" в разрабатываемых алгоритмах.

Бухгалтерские отборы

При разработке конфигурации с использованием компоненты "Бухгалтерский учет" весьма важным моментом с точки зрения производительности является установка режимов отбора для бухгалтерский объектов. Существует несколько режимов отборов, которые можно установить в конфигурации для объектов метаданных, специфичных для компоненты "Бухгалтерский учет":

· Отборы по данным операции (сумме операции, содержанию, реквизитам операции)

· Отборы по данным проводки (сумме, количеству, валютной сумме, валюте, реквизитам проводки)

· Отбор по счетам (в целом, с ограничением по уровням, по дебету/кредиту)

· Отбор по видам субконто.

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

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

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

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

Отбор по счетам играет особую роль среди бухгалтерских отборов. В отличие от отборов по данным операции и проводки, отбор по счетам требует больше ресурсов, так как одна проводка может относиться к нескольким счетам. Для поддержания отбора по счетам ведется специальная таблица вхождения проводок в отборы по конкретным счетам. В зависимости от установок отбора по счетам туда могут включаться, в том числе, и вхождения проводок в счета-группы в случае, если в проводке используется субсчет. В этом случае ресурсы системы расходуются тем больше, чем больше средний уровень вложенности счетов, используемых в проводках. Отдельный режим включает возможность использования отбора отдельно по дебету и кредиту проводки. Он также увеличивает время записи проводки. С другой стороны отбор по счетам не только обеспечивает удобный режим выборочного просмотра проводок, но и активно используется системой при получении различных данных объектом "БухгалтерскиеИтоги". Например, при получении карточки счета или анализа счета по датам.

При проектировании конфигурации следует соотнести частоту формирования таких отчетов и затраты ресурсов системы (как по объему данных, так и по времени записи операции). Например, можно предложить следующее компромиссное решение. Отбор по счетам включается, но не включается отбор по дебету/кредиту. При этом отключается режим "для всех" и устанавливается параметр "количество уровня" равным 1. В этом случае доступным будет отбор проводок только по счету в целом, то есть не будет возможность просмотра проводок в дебет или кредит конкретного счета, а только всех проводок с данным счетом. Кроме того, отбор в журнале проводок можно будет установить только по счету верхнего уровня, и нельзя будет отобрать проводки по отдельному субсчету. Однако возможность отбора проводок по некоторому счету 1го уровня в большом количестве случаев будет вполне удобна. С другой стороны для большинства обращений к объекту "БухгалтерскиеИтоги" по конкретному счету данный отбор позволит существенно оптимизировать получение необходимых данных, даже в случае если происходит обращение к

итогам по субсчету.

Аналогично следует рассмотреть установку отборов по видам субконто. Как и отбор по счетам отбор по субконто используется не только для удобного просмотра проводок по конкретному объекту аналитики, но и используется объектом "БухгалтерскиеИтоги" при обращении к бухгалтерским итогам и операциям по конкретному субконто, например, для получения карточки субконто. Так как каждая проводка может включать разные объекты аналитики, то для поддержания такого отбора ведется специальный список, в котором отмечаются все вхождения проводки в отборы по тем видам субконто, в которых включен отбор в конфигурации. То есть количество записей в этом списке будет зависеть от частоты использования в проводках значений субконто тех видов, для которых в конфигурации установлен режим отбора. При проектировании конфигурации следует соотнести необходимость быстрого получения отчетов по отдельным объектам аналитики конкретных видов с затратами ресурсов системы на поддержание отбора по субконто. При

отсутствии необходимости быстрого формирования отчетов по отдельным объектам аналитики можно рекомендовать не включать отборы по субконто. Очевидно, что не имеет смысла включать отбор по тем видам субконто, количество значений которых невелико, например, по перечислениям. Значительный эффект при построении отчета может быть получен по тем видам субконто, которые имеют большой разброс значений в проводках, например, по организациям-контрагентам или товарам. Рекомендуется включить отбор только для тех видов субконто, для которых это действительно необходимо и дает ощутимый результат. Если отбор по субконто не дает существенного выигрыша при работе с бухгалтерскими итогами, то при большом объеме проводок можно рекомендовать не использовать данный отбор для визуального просмотра проводок и отключить его в конфигурации. Это уменьшит время записи проводок.

Следует заметить, что при работе с базами данных в формате SQL существенно меняется производительность выборки данных объектом "БухгалтерскиеИтоги" и выборки проводок объектом "Операция". Поэтому для этих информационных баз, часто, отпадает необходимость в использовании бухгалтерских отборов для

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

Использование "длинных путей" при записи операции

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

Оптимизация работы Регистров оперативного учета

Регистры остатков

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

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

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

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

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

Одним из важных вопросов, которые приходится решать при проектировании структуры регистров является вопрос об измерениях, которые используются не во всех движениях. Например, при создании структуры регистров для учета различных материальных ценностей можно создать один регистр с измерениями "ТМЦ" и "Партия". В этом случае для тех видов ТМЦ, по которым не ведется партионный учет, данное измерение будет оставаться пустым. С другой стороны можно создать два отдельных регистра, в одном из которых измерение "Партия" будет отсутствовать. В этом случае движения по тем видам ТМЦ, по которым ведется партионный учет, будут записываться в один регистр, а по тем, по которым не ведется - в другой. Создание двух регистров в данном примере позволяет несколько снизить размер информационной базы, так как записи по видам ТМЦ без партионного учета будут короче. Однако, существенного выигрыша в быстродействии при этом не будет. Разумеется, при большом количестве неиспользуемых измерений разница в быстродействии при обращении к регистру будет более заметна. Использование одного регистра вместо двух в данном примере имеет ряд преимуществ с точки зрения технологичности написания самой конфигурации, особенно в том случае, если в зависимости от различных настроек по некоторым видам ТМЦ может включаться и отключаться ведение партионного учета.

На практике, выбор осуществляется более чем из двух вариантов. Отрицательными можно считать, как стремление поместить все возможные виды учета в один регистр, так и сделать очень большое количество регистров для различных комбинаций измерений. Разумеется, не следует объединять в один регистр данные, по которым состав используемых измерений в разных движениях вообще никогда не пересекается, например, объединять в один регистр учет взаиморасчетов и учет товаров.

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

Следует учитывать, что приведенная аргументация справедлива в основном для конфигураций работающих с базами данных в формате DBF/CDX. При работе с базами данных в формате SQL доступ к итогам регистров существенно ускоряется и не так сильно зависит от структуры регистров.

Оборотные регистры

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

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

С другой стороны введение оборотного регистра, разумеется, требует дополнительных ресурсов. С точки зрения движений оборотный регистр полностью аналогичен регистру остатков. А в части итогов объем хранимой информации зависит от выбранного периода оборотного регистра. В периодах с "дня" до "месяца" объем информации будет пропорционален количеству данных периодов в месяце при постоянном наборе значений. Разумеется, если каждый день продавать товары разным клиентам, то объем информации при периоде день и месяц будет практически одинаковым. То есть объем хранимых записей в итогах оборотного регистра за период будет равен количеству реально встретившихся в данном периоде сочетаний значений измерений регистра. Заметим, что периоды "квартал" и "год" по используемым ресурсам несколько превосходят период "месяц", так как для обеспечения возможности переноса ТА реально хранятся итоги и за каждый месяц тоже.

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

снижается.

Использование реквизитов регистров

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

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

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

Периодичность сохранения итогов

Существенным инструментом регулирования производительности регистров при проведении документов задним числом является управление периодичностью хранения итогов. Заметим, что установка периодичности выполняется не в конфигурации, а собственно в информационной базе. Это позволяет на конкретном предприятии подобрать ту периодичность, которая обеспечивает наилучший компромисс между объемом хранимой итоговой информации с одной стороны, и скоростью расчета итогов не некоторый момент времени с другой. Уменьшение периода сохранения итогов пропорционально увеличивает объем хранимой информации, но позволяет в среднем быстрее рассчитывать итоги на некоторый момент времени.

Получение итогов на некоторый момент времени обычно требуется в двух случаях.

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

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

Таким образом, ориентация компоненты "Оперативный учет" на работу с текущими итогами требует построения конфигурации с минимальным обращением к расчету итогов на произвольный момент. То есть, не всегда следует начинать "борьбу" за производительность с уменьшения периодичности хранения итогов. В начале целесообразнее рассмотреть случаи выполнения временных расчетов на некоторый момент времени и постараться уменьшить частоту их возникновения.

Заметим, что настройка периодичности хранения итогов используется в основном для конфигураций работающих с базами данных в формате DBF/CDX. При работе с базами данных в формате SQL процедура временного расчета существенно ускоряется и не так сильно зависит от периодичности хранения итогов.

Обращение к данным регистров

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

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

Приведем некоторые сведения касающиеся производительности системы при получении данных регистров.

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

Обращение к движениям регистра, как из запроса, так и методами объекта "Регистр" выполняется последовательным обходом всех движений данного регистра всех документов, которые имеют движения по данному регистру. Использование условий запроса или фильтра с точки зрения объема выбираемых данных из информационной базы может ускорить выполнение операции только при наличии соответствующих граф отбора или отборов измерений или реквизитов регистра. Оптимизация с помощью граф отбора подробно описана в разделе "Графы отбора". Оптимизация с помощью отборов измерений и описана в разделе "Использование отборов регистра". Если подходящей для оптимизации графы отбора или отбора самого регистра нет, движения регистра выбираются системой последовательно. При этом использование условия запроса или фильтра уменьшает только количество выполняемых строк встроенного языка, но не количество данных выбираемых из информационной базы.

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

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

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

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

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

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

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

Использование отборов регистра

В версии 7.7 в свойствах регистров появилась возможность устанавливать признаки отбора для измерений и реквизитов.

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

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

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

Установка отборов по измерениями и реквизитам влияет на производительность объектов типа "Запрос" и "Регистр". Причем оптимизация происходит только в том случае, если при обращении указывается конкретное значение соответствующего измерения или реквизита. Система не использует отборы при выборке по группе справочника и при выборке по списку значений.

При использовании объекта "Запрос" оптимизация выполняется системой при обработке данных регистра, если существует условие равенства переменной запроса, относящейся к измерению или реквизиту регистра, для которого установлен признак "Отбор".

Признак "Отбор итогов" будет оптимизировать получение функций "НачОст" и "КонОст". Признак "Отбор движений", соответственно, будет оптимизировать получение функций "Приход" и "Расход". Если запрос выполняет получение остатков не на начало периода и не на ТА, то признаки "Отбор движений" будут также использоваться для оптимизации получения остатков на нужный момент.

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

Признак "Отбор итогов" будет оптимизировать выполнение методов "ВыбратьИтоги" / "ПолучитьИтог", а также "ВыгрузитьИтоги". Признак "Отбор движений", соответственно, будет оптимизировать выполнение методов "ВыбратьДвижение" / "ПолучитьДвижение", "ВыбратьДвижениеСОстатками", а также выполнение временного расчета (выполнение функций "РассчитатьРегистрыНа" и "РассчитатьРегистрыПо").

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

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

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

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

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

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

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

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

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

Заметим, что использование отборов регистров целесообразно в основном для конфигураций работающих с базами данных в формате DBF/CDX. При работе с базами данных в формате SQL доступ к движениям и итогам регистров существенно ускоряется, и применение отборов может не оказать влияния на производительность.

Использование признака "Быстрая обработка движений"

Для регистра в целом может быть установлен признак "Быстрая обработка движений". Этот признак оптимизирует обработку движений регистров при выполнении запросов обращающихся к движениям регистра, методов объекта "Регистр" выбирающих движения, а также выполнение временного расчета.

При обращении запроса или объекта "Регистр" к движениям регистра система анализирует все документы, выбирая движения по тем документам, по которым они записывались. Установка признака "Быстрая обработка движений" создает дополнительный индекс и расширяет структуру регистра дополнительными полями. Это позволяет системе выбирать сами движения регистра без анализа документов.

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

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

При работе с базами данных в формате SQL применение данного признака не будет оказывать существенного влияния на производительность.

Оптимизация работы запросов

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

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

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

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

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

Например:

Неправильно:

Если Запрос.Товар.ЭтоГруппа()=1 Тогда

...

Правильно:

Если Запрос.ЭтоГруппа("Товар")=1 Тогда

...

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

Данная рекомендация особенно актуальна при работе с базами данных в формате SQL.

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

Например:

Неправильно:

Пока Запрос.Группировка(1) = 1 Цикл

Сообщить("Товар"+Запрос.Товар.Код + " ВидТовара =

"+Запрос.Товар.ВидТовара );

КонецЦикла;

Правильно:

Пока Запрос.Группировка(1) = 1 Цикл

Тов=Запрос.Товар;

Сообщить("Товар "+Тов.Код + " ВидТовара = "+Тов.ВидТовара);

КонецЦикла;

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

В условиях запроса целесообразно использовать оператор "В" применяемый для определение вхождения значений переменной запроса в группу справочника или счета, а также вхождения в список значений, который может содержать отдельные значение и группы справочников или счетов. Использование этого оператора существенно увеличивает производительность по сравнению с вызовом в условии метода "ПринадлежитГруппе". Оператор "В" в ряде случаев целесообразно также использовать для сравнения переменной запроса с несколькими значениями вместо отдельных выражений объединенных оператором "ИЛИ".

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

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

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

Кроме использования метода "Получить" многократное использование результатов запроса может достигаться при помощи выгрузки запроса в таблицу значений (метод "Выгрузить").

Использование запросов в алгоритмах расчетов

Обычно, объект "Запрос" применяется для формирования отчетов. В то же время, достаточно часто он используется также для выборки различных итогов при выполнении расчетов в процессе проведения документов или регламентных обработок. Например, с его помощью могут выбираться текущие итоги для списания ТМЦ по средней себестоимости или по методам LIFO, FIFO. Особенно роль использования запросов в таких алгоритмах в версии 7.7 возрастает при работе с базами данных в формате SQL. Однако, действия выполняемые запросом по умолчанию ориентированы именно на формирование отчетов.

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

Обычно в расчетах имеет смысл отключить формирование итогов по группам справочников и счетов. Для этого в описании группировки используется конструкция "Без Групп".

Кроме специальных случаев, когда это действительно необходимо, рекомендуется отключить упорядочивание значений группировки. Для этого в описании группировки используется конструкция "Без Упорядочивания".

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

Оптимизация формирования отчетов

Отчеты в 1С:Предприятии формируются обычно либо путем обхода объектов определенного типа (элементов справочника, документов, операций, проводок, движений и остатков регистра, записей журнала расчетов), либо путем предварительной обработки информации при помощи специальных средств (объекта "Запрос", объекта "БухгалтерскиеИтоги" или объекта "Операция") и последующем обходе полученных промежуточных информационных массивов.

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

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

Заметим, что в отличие от алгоритмов выполняемых при проведении документов, отчеты, как правило, формируются вне транзакции. Это означает, что выполнение большинства операций в отчете будет происходить существенно медленнее, чем при проведении документа. Это касается версий 1С:Предприятия работающих в базой данных в формате DBF. При работе с базами данных в формате SQL выполнение операций вне транзакции и внутри транзакции не отличаются по производительности. Однако, очевидно, что при работе в архитектуре клиент-сервер количество обрабатываемой информации полученной из информационной базы также весьма существенно влияет на производительность, поэтому и при работе с базами данных в формате SQL следует оптимизировать, прежде всего, обращения к информационной базе.

Таким образом, при написании алгоритма отчета следует учитывать не столько количество выполняемых строк встроенного языка, сколько объем обращения к информационной базе. Для такой оценки следует использовать описанные в разделе, посвященном вопросам производительности, принципы работы конкретных средств языка с точки зрения обращения к данным. Приведем несколько практических примеров.

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

Аналогично обстоит дело и с обращением к данным бухгалтерских итогов.

Например, крайне нежелательно организовывать получение итогов по двум субконто счета при помощи вложенных циклов, то есть обходить, например, справочник материалов, и на каждый материал обходить справочник складов, выбирая остаток по каждой комбинации "товар-склад". Значительно эффективнее будет выполнение запроса объекта "БухгалтерскиеИтоги" и вывод его результатов в отчет.

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

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

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

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

При работе с бухгалтерскими итогами также целесообразно не допускать циклической обработки объектом "БухгалтерскиеИтоги" данных в режимах временного расчета и запроса. Более целесообразно выполнять запрос, на основании которого в дальнейшем получать различную информацию. Разумеется, данный принцип следует использовать с учетом приведенной в разделе "Работа с бухгалтерскими итогами" информации описывающей оптимизацию выборки бухгалтерских данных по отборам счетов и субконто.

В некоторых случаях при формировании отчетов в качестве промежуточных массивов данных можно рекомендовать использовать объекты типа "СписокЗначений" и "ТаблицаЗначений". Например, если в ходе выполнения отчета приходится многократно перебирать значения справочника, то его можно вначале внести в список значений, а затем обходить уже не сам справочник, а список значений. В этом случае будет уменьшено количество обращений к информационной базе.

При формировании больших отчетов не следует выводить большого количества строк в окно сообщений. Его динамическое обновление может существенно затормозить формирование отчета. Если нужно получить большого размера текстовый протокол можно рекомендовать заносить строки в объект типа "Текст" а в конце формирования отчета вывести его на экран методом "Показать".

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

Оптимизация конфигураций при работе с базами данных в формате SQL

Одним из основных принципов архитектуры 1С:Предприятия является одинаковое функционирование конфигурации при работе с базами данных в формате DBF/CDX и базами данных в формате SQL. Это необходимо для широкого распространения единых прикладных решений и обеспечения плавной масштабируемости. Идентичность работы конфигураций в полной мере относится к их функциональной части, но, разумеется, не относится к производительности конкретных режимов и алгоритмов.

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

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

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

Список таких объектов и режимов в которых они дают серьезные преимущества приведен в документации поставляемой с версиями 1С:Предприятия для SQL в разделе "Производительность системы".

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

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

В алгоритме проведения существует возможность обрабатывать каждый товар документа отдельно или выполнить один запрос (или обращение к регистру) для получения итогов по всем товарам документа, выгруженным предварительно в список значений. В запросе будет использован оператор "В", а при работе с объектом "Регистр" установка фильтра.

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

Обработка текущих итогов по списку товаров при использовании обычных версий 1С:Предприятия будет не вполне эффективной, так как время обработки будет зависеть от общего количества итогов по товарам в информационной базе. В то же время, при использовании версий 1С:Предприятия для SQL более производительным будет вариант единовременной выборки всех итогов по товарам документа с помощью запроса с условием или метода "ВыгрузитьИтоги" объекта "Регистр" с установкой фильтра. Это объясняется тем, что оба эти механизма будут использовать для отбора необходимой информации возможности SQL-сервера и на клиентском компьютере будет выполняться обработка только необходимой информации.

Другим примером может являться алгоритм, выполняющий выборку списка документов по некоторому признаку, например, получение реестра приходных накладных, по выбранному складу. При работе с базой данных в формате DBF/CDX выборка может осуществляться как перебором документов объектом "Документ" (с поверкой реквизита в алгоритме модуля) так и с помощью объекта "Запрос" с соответствующим условием. Причем скорость выполнения обоих алгоритмов будет различаться не существенно (разумеется, если не существует подходящей графы отбора). При использовании версий для SQL использование запроса будет существенно эффективнее, разумеется, если количество выбираемых документов значительно меньше их общего количества в выбранном интервале.

При работе с базой данных в формате DBF/CDX объект "Запрос" редко используется для выборки элементов справочника. Однако, при использовании версий для SQL применение запроса для отбора элементов справочника по некоторому критерию будет весьма эффективным.

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

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

При обращении к итогам регистров рекомендуется использовать метод "ВыгрузитьИтоги" вместо методов "ВыбратьИтоги" и "ПолучитьИтог", так как метод "ВыгрузитьИтоги" выполняет получение всей необходимой информации с использованием возможностей SQLсервера.

При необходимости получения некоторой выборки бухгалтерских проводок рекомендуется использовать объект "Операция" в режиме "ВыбратьОперацииСПроводками" с максимальным указанием критериев отбора в параметрах метода и методами "ИспользоватьСубконто" и ИспользолватьКорСубконто". Такая выборка будет существенно эффективнее, чем фильтрация проводок проверками в алгоритме модуля.

Работа пользователей

Администрирование работы пользователей

Специалисту, осуществляющему администрирование 1С:Предприятия, следует обращать внимание на состав программного обеспечения, работающего на компьютерах пользователей.

Зачастую, жалобы пользователей на медленную работу 1С:Предприятия (особенно на компьютерах с невысокой производительностью и небольшим объемом оперативной памяти) объясняются тем, что параллельно с работой 1С:Предприятия запущено одна или несколько задач, сильно влияющих на производительность. Это могут быть задачи DOS или другие не 32-разрядные задачи. Заметим, что некоторые задачи, работающие в фоновом режиме и оказывающие существенное влияние на производительность могут запускаться помимо желания пользователя (например, сервисные программы MS Office, автоматически включаемые при установке в группу запуска). Другой причиной снижения производительности может быть недостаточный размер файла подкачки (Swap-файла) установленный в настройках Windows или отсутствие достаточного места на диске, необходимого для функционирования системы.

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

Позиционирование в журналах на вводимые документы

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

В этом случае можно воспользоваться параметром "Переходить в журнале на записанный документ" (режим "Сервис - Параметры - Журналы"). Этот параметр позволяет отключить позиционирование на введенный документ.

Кроме того существует определенная особенность при использовании версий 1С:Предприятия для SQL. Она заключается в том, что при работе с журналами с большим количеством документов (в текущем интервале) позиционирование на введенный документ занимает некоторое время.

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