Поэтому с базовой версией 2.4.0 можно использовать только версию надстройки MS Office 2.2.5 Patch_1.

В сообщении об обратной записи в истории листа возвращается ID сформированного по результатам обратной записи пакета на расчет куба.

Из этого следуют две особенности:

1)  Обратная запись производится быстрее.

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

Пакеты обратной записи создаются с высоким приоритетом.

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

10.1.9  Требование на расчет

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

(0) Обратная запись/запись данных;

(1) Изменение классификатора/таблицы;

(2) Изменение сопоставления;

(3) Запуск расчета пользователем;

(4) Запуск расчета закачкой.

В поле «Модуль» записывается модуль системы, от которого поступило сообщение о необходимости расчета куба.

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

НЕ нашли? Не то? Что вы ищете?

10.1.10  Расчет кубов по источнику при закачке

При запуске расчета кубов из закачки данных в случае, если куб разделен на разделы по годам и месяцам (например кубы по 28н, ежемесячная отчетность, некоторые блоки данных УФК), то закачка отправляет на расчет только нужные разделы куба (по которым выполнялась закачка или обработка данных):

1)  Создается пакет на расчет;

2)  Закачка передает требования на расчет разделов куба. Передается имя куба и ID источника данных;

3)  Если в кубе есть раздел с именем, равным имени куба, то выполняется расчет именно этого раздела;

4)  Если такого раздела нет, то по ID источника данных определяются параметры источника «Год» и «Месяц» и производится поиск раздела с именем «Год» или «Год_Месяц» и данный раздел отправляется на расчет;

5)  Пакет отправляется на расчет системой расчета кубов.

10.1.11  Обновление хеша сервера

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

При выполнении операции:

1)  Очищается хеш-таблица «Многомерные объекты» в памяти сервера;

2)  Хеш-таблица заполняется данными из реляционной базы;

3)  Выполняется синхронизация данных хеш-таблицы со структурой объектов многомерной базы. Устанавливается признак рассчитан/не рассчитан и дата расчета. Если в многомерной базе появились новые объекты, то они добавляются в хеш-таблицу и сохраняются в реляционной базе;

4)  Данные считываются из хеш-таблицы с сервера и передаются клиенту.

Обновление хеша сервера автоматически выполняется при запуске сервиса.

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

Внимание! В обычных ситуациях не требуется выполнение операции «Обновление хеша сервера». Пример ситуаций, когда требуется обновление серверного хеша:

1)  Куб рассчитывается руками в Analysis Manager. Для того, чтобы результаты расчета отобразились в Workplace, необходимо запустить операцию обновления серверного хеша;

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

3)  Если в ходе сеанса работы сервера добавлен или удален куб или измерение (например, применялся патч). Чтобы новые объекты отразились в списке кубов/измерений, необходимо обновить серверный хеш;

4)  Если многомерная БД перезапускалась во время работы сервера, то сервер теряет с ней связь. Связь переинициализируется при выполнении операции обновлении серверного хеша.

Вместо обновления хеша сервера во всех этих случаях можно перегрузить сервер приложений.

11.  Блок «Протоколы»

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

В области навигации блока «Протоколы» есть кнопка «Архивировать протокол»

Рисунок 95 Кнопка "Архивировать протоколы"

При нажатии на кнопку архивируются все протоколы за указанный интервал дат.

Протоколы сохраняются на сервере в папку «Archive». В этой папке создаются подпапки в формате:

«ГодМесяцДень Час-Минута-Секунда Архив протоколов <Интервал дат>»

Протоколы сохраняются в формате xml.

Если за указанный интервал дат в базе данных отсутствуют те или иные протоколы, то xml-файл по этому протоколу не создается.

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

Напоминаем: для того чтобы протоколы сохранялись в папку «Archive» необходимо:

1.  На сервере, в репозитории схемы, создать папку с именем «Archive» и открыть ее для общего доступа, прописав имя общего ресурса.

2.  Настроить конфигурационный файл сервера Krista. FM. Server. FMService. exe. config, прописав относительный путь к папке «Archive». Например:

<add key="ArchiveShare" value="\\<Имя машины-сервер>\Archive"/>

12.  Блок «Источники данных»

12.1  Блокировка источников

В блоке «Источники данных» существует функция блокировки источника данных.

При нажатии на кнопку «Закрыть\Открыть источник от изменений» источник блокируется вместе с зависимыми данными (классификаторы данных, таблицы фактов).

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

Это сделано, чтобы защитить данные прошлых лет от изменений.

Заблокированный источник отображаются иконкой , если источник открыт для изменений – иконкой .

Рисунок 96 Блокировка источника

В блоках «Классификаторы данных» и «Таблицы фактов» в поле «Выбор источника данных» заблокированные источники отображаются аналогично.

12.2  Удаление источников вместе с зависимыми данными

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

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

Рисунок 97 Список удаляемых объектов и число зависимых записей по ним

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

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

Рисунок 98 Права на удаление источника

13.  Блок «Задачи»

13.1  Введение

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

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

Рисунок 99 Система задач

Рассмотрим пример формирования доходной части бюджета.

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

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

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

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

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

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17