PC Magazine/RE - Журнал PC Magazine/RE №12/2009

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

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

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

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

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

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

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

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

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

• Аналитическая отчетность. Состав отчета и периодичность его формирования зависят только от сотрудника, занятого вдумчивым анализом деятельности предприятия. В поисках ответов на вопросы «почему упали продажи?» или «как повысить отдачу на инвестиции?» аналитик может многократно «прокручивать» одни и те же исходные данные в разных разрезах и группировках.

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

Агрегат может быть создан одним из двух способов.

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

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

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

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

• справочники пользователей и физических лиц, управление правами пользователей, хранение контактной и адресной информации;

• справочник валют, хранение курсов, получение курсов валют из Интернета;

• работа с внешними файлами, хранение внешних файлов в информационной базе;

• настройка и использование полнотекстового поиска;

• первоначальное заполнение информационной базы и модификация данных при обновлении конфигурации;

• управление блокировкой доступа к информационной базе, принудительное завершение пользовательских сеансов;

• вывод документов на печать и их отправка по электронной почте;

• создание и хранение дополнительных свойств объектов информационной базы, в первую очередь – документов и элементов справочников;

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

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

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

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