Санаторий (Руководство разработчика)

Введение

Приложение «Санаторий» разрабатывалось специально для санатория «Берёзка» ОАО «Беларуськалий». То есть принцип работы ведомственного санатория изучался на примере работы «Берёзки». Впоследствии была разработана эталонная база по автоматизации работы санатория, где установлены все необходимые пространства имен (ПИ) (эти ПИ также можно найти здесь [1], ветка «Санаторий»).

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

Однако в процессе разработки были выявлены ситуации несоответствия терминологии и механизмов работы Гостиницы и Санатория. Поэтому было принято решение сделать эти приложения независимыми друг от друга и развивать их каждый в своем направлении. При этом общие моменты всё же остались (о таких объектах свидетельствует префикс «HT» - по названию ПИ Гостиница - Hotel). Объекты, удаленные из приложения Санаторий, которые характерны для Гостиницы, описаны в Приложение 1. Этот перечень может быть полезен при добавлении нового функционала в приложение: во-первых, если объект имеется в перечне, его всегда можно проанализировать в контексте Гостиницы (так как он там точно присутствует), а во-вторых, объяснение отсутствия данного объекта может убедить отказаться от него и в этот раз. В данном руководстве будет представлена структура ПИ «Санаторий» с описанием функционала и используемых объектов.

Общая структура ПИ «Санаторий»

ПИ GS.Санаторий зависит только от ПИ Общие данные. На рисунке 1 (Рисунок 1 – Общая схема ПИ «Санаторий») представлена общая схема ПИ GS.Санаторий.

Как видно из рисунка 1, «Санаторий» состоит из следующих подсистем:

• Подсистема «Общее» (содержит общие метаданные, общие справочники и документы, вспомогательные функции и пользовательские формы);
• Подсистема «Тариф» (содержит документ тарифа и справочники, необходимые для создания нового тарифа);
• Подсистема «Номерной фонд»(здесь собраны все справочники для номерного фонда);  
• Подсистема «Путевка» (содержит всё, что относится к созданию документа Путевки или Бронирования Путевки);
• Подсистема «Учет путевок» (содержит документы по манипуляциям над путевками);
• Подсистема «Медицинские услуги» (здесь всё, что касается медицинской части Санатория + связующая часть между Путевками и медицинской частью);
• Подсистема «Санаторное питание» (здесь всё, что связано со столовой в плане взаимодействия с отдыхающими, например, рассаживание в зале, назначения диет);
• Подсистема «Форма менеджера» (содержит основную форму приложения и обработчики её событий);
• Подсистема «Форма Администратора» (TODO! Опциональная подсистема, требует доработок)
• Подсистема «Импорт из Оракла» (содержит функции по импорту данных о сотрудниках предприятия из базы данных Оракл в Гедымин) – эта подсистема опциональна;
• Подсистема «Санаторный общепит» (здесь всё, что связано со столовой в плане калькуляций блюд, формирования заказов, составления меню и т.д.) – эта подсистема зависит от стандартного ПИ «Общепит»;
• Подсистема «Глобальные объекты» (TODO).

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

Подсистема «Общее»

Структура подсистемы представлена на рисунке 2 (Рисунок 2 – Структура ПИ GS.Санаторий.Общее).

На рисунке здесь и далее красными стрелками представлены зависимости внутри подсистемы, желтые блоки - группы объектов, которые отсутствуют как ПИ, но для наглядности выделены на схеме. Состоит из:

• GS.Санаторий.Общее.Метаданные;
• GS.Санаторий.Общее.Справочники;
• GS.Санаторий.Общее.Документы;
• GS.Санаторий.Общее.Скрипты;
• GS.Санаторий.Общее .Формы.

Зависит от: «Общие данные».

От данного ПИ зависят: все ПИ из приложения «Санаторий».

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

Ночной аудит

От приложения Гостиница сохранился функционал Ночного Аудита. Это функция, запускаемая менеджером в конце рабочего дня. Её основное предназначение – контроль над оплатой бронирований, контроль над выселением гостей, у которых подошёл день выезда и т.д. Только при выполненных действиях логическая дата системы может быть переведена на следующий день. Информация о логической дате и дате последнего аудита содержится в документе «Служебное» (HT_SETTING): поля LOGICDATE и LASTAUDITDATE соответственно. В приложении Санаторий возможность использования этого функционала сохранена, однако он не используется в данный момент. Логическая дата соответствует текущей дате, установленной на компьютере.

Настройки приложения

Окно настроек (форма ht_options) вызывается из Подсистема «Форма менеджера», раздел Менеджер. В настройках указываются основные объекты из справочников для правильной работы выпадающих списков в документах и правильного построения отчётов. Кроме того, настраиваются округления сумм (округляются все цены в приложении до указанных здесь значений), нумерация документов и права доступа. Для реализации прав доступа в событии формы настроек OnCreate в элемент управления usrg_clbRights добавляются записи с уникальными идентификаторами, которые описаны в файле констант htConst. Затем в скриптах, используя объект класса разграничения прав доступа (Класс THT_RightsHelper) и его метод CanExecuteAction, происходит проверка этого уникального идентификатора как возможность использовать ту или иную функцию. Если результат выполнения метода True – пользователю разрешается доступ к функции.

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

Описание всех классов – Приложение 3.

Описание всех хранимых процедур – Приложение 4.