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


Аннотация

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

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

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

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

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

Весь материал изложен в виде 4 глав:

  1. Расчетно-теоретическая часть
  2. Технологическая часть
  3. Организационно-экономическая часть
  4. Безопасность и экологичность проекта


Содержание


Введение

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

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

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


  1. Расчетно-теоретическая часть

  1. Требования к программному продукту

  1. Наименование программного продукта

База данных «Аптека».

  1. Назначение разработки

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

  1. Область применения

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

  1. Общие требования к программному продукту

Данный программный продукт должен обеспечивать:

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

  1. Требования к надежности

Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:

  • организация бесперебойного питания технических средств;
  • использование лицензионного программного обеспечения;
  • регулярное выполнение рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении № 28 от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
  • регулярное выполнение требований ГОСТ 51188-98 «Испытания программных средств на наличие компьютерных вирусов».

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

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

  1. Требования к составу и параметрам технических средств
  2. Удовлетворение требованиям выбранных программных средств.
  3. Минимальная стоимость.

  1. Требования к программным средствам
  2. Ориентирование на модификацию и расширение.
  3. Высокая эффективность и надежность.
  4. Обеспечение целостности данных.
  5. Обеспечение ограничения доступа к данным.
  6. Удобство пользовательского интерфейса.


  1. Требования к функциональным характеристикам

Основными функциями, которые должна нести проектируемая база данных, являются:

  1. Ведение необходимых для полноценной работы справочников с возможностью их дополнения, редактирования и удаления записей.
    1. Ведение базы приходных накладных с указанием номера накладной, датой ввода, номера документа поставщика, даты формирования накладной; информацией о номенклатуре поступившего лекарственного средства или изделия, его серии, сертификате, цене и количестве, сумме без НДС и сумме с НДС по каждой номенклатуре; итоговая сумма без НДС и с НДС по всем номенклатурам, указанным в приходной накладной.
      1. Ведение базы расходных документов с указанием номера документа, даты ввода, типа расходного документа, затребовавшего подразделения ЛПУ, затребовавшего лица, основания; информацией о номенклатуре, серии, сертификате, поставщике, цене поставки; данных о текущем остатке отпускаемой номенклатуры, её цене и количестве, сумме без НДС и сумме с НДС; итоговая сумма без НДС и с НДС по всем номенклатурам, указанным в расходном документе.
        1. Получение информации об остатках препаратов в количественном и денежном выражении на определенное число, в т.ч. с возможностью просмотра по видам источников финансирования, а также с указанием остатка на первое января текущего года, суммы прихода и расхода на текущее число.
        2. Получение информации о движении препарата в аптеке стационара ЛПУ за определенный период с указанием данных о препарате (наименование, форма выпуска, серия, сертификат, срок действия сертификата, производитель, срок годности, единица измерения) и текущем остатке.
        3. Формирование отчетной документации:
  2. Книга протаксированных накладных.
  3. Приход.
  4. Расход:
    • Отпущено отделениям и кабинетам.
    • Списано по актам, счетам и другим документам.
    • Всего расход. Остаток с учетом расхода.
  5. Остатки на первое января:
    • Вся информация.
    • Прайс-лист.
  6. Остатки по группам предметно-количественного учета (ПКУ).
  7. Остатки по группам учета.
  8. Приход с остатками.
  9. Расход с остатками.
    1. Формирование ведомостей за определенный период в разрезе источников финансирования, групп препаратов, позиции по номенклатурному номеру.

  1. Требование к графическому интерфейсу
  2. Система должна иметь интуитивно понятный графический пользовательский интерфейс.
  3. Панель меню главного окна системы (главное меню) должна предоставлять доступ с помощью клавиатуры или манипулятора типа «мышь» ко всем инструментам настройки и управления системы.
  4. Меню главного окна должно содержать следующие пункты:
    1. Движение – данный пункт предназначен для работы пользователя с приходными и расходными документами, а также для контроля за остатками аптечных товаров. Содержит следующие подменю:
      • Карточка – просмотр данных о движении каждой номенклатуры, сроке годности и текущем остатке; осуществление печати карточки.
      • Приход – ввод, просмотр и редактирование приходных документов; возможность печати товарной накладной и счет-фактуры.
      • Расход – ввод, просмотр и редактирование расходных документов; возможность печати товарной накладной.
      • Остаток на дату – просмотр остатков по номенклатурам; возможность печати данных об остатках.
      • Ввод остатков прошлого года – начальная установка остатков номенклатур (функция администратора).
        1. Отчеты – пункт меню предназначен для работы с отчетными документами. Содержит следующие пункты подменю:
          • Ведомость – осуществляется формирование ведомости, а также печать стеллажной карточки (по Форме № АП-73, утвержденной приказом Министерства здравоохранения СССР от 8 января 1988 г. №14) и сличительная ведомость (по Форме № АП-43, утвержденной приказом Министерства здравоохранения СССР от 8 января 1988 г. №14).
          • Отчет – формирует книгу протаксированных накладных (по Форме № 7-МЗ, утвержденной приказом Министерства здравоохранения СССР от 30 декабря 1987 г. №1337), отчет по приходным накладным, по расходным накладным, остаткам на первое января текущего года, формирует прайс-лист, отчеты по остаткам по группам предметно-количественного учета, по остаткам групп учета, по приходу с остатками, по расходу с остатками.
  5. Справочники – предназначен для просмотра и редактирования справочных данных.
    • Отделения – справочник отделений по каждому ЛПУ.
      • Банки – справочник банков для контрагентов.
        • Контрагенты и производители – справочник наименований контрагентов и производителей, также содержит реквизиты их банковских счетов.
          • Группы предметно-количественного учета – справочник групп ПКУ.
          • Фармакологические группы – справочник фармакологических групп.
          • Номенклатура – справочник номенклатур.
          • Дозировки – справочник дозировок.
          • Единицы измерения – справочник единиц измерения.
          • Источники финансирования – справочник видов источников финансирования.
          • Органы сертификации – справочник наименований органов сертификации.
          • Виды расходных операций – справочник видов расходных операций.
          • Страны – справочник стран- импортеров.
  6. Сервисные функции – пункт меню предназначен для начальной настройки программы (функция администратора).
  • Реквизиты аптеки – заполнение данных об аптеке.
  • Настройка – настройки аптеки «по умолчанию».
  1. Выход – выход из программы.

  1. Требования к техническим средствам
  2. Наличие сети между сервером и клиентской станцией.
  3. Типовая конфигурация сервера представлена в таблице 1.1:

Таблица 1.1 - Типовая конфигурация сервера

Шасси

Intel 5500 чипсет, QPI 4.8 / 5.86 / 6.4 GT/sec,
до 2 CPU Multi-Core Intel® Xeon® 5500/5600 семейства,
до 24GB DDR3-1066 / 1333 ECC Unbuffered / Registered SDRAM, по 3 канала памяти на процессор (6 DIMM слотов, по 3 на процессор),
2 слота полной высоты PCI-E 2.0 x8
1 слот полной высоты PCI-E 2.0 x4
1 слот полной высоты PCI-E x4
2 слота полной высоты PCI 32bit / 33MHz (3.3 V)

Процессор

Quad-Core Intel Xeon E5506, 2,13 GHz, cache 4 Mb, QPI 4.8 GT/sec

Видеоконтроллер

Интегрированный Matrox G200eW, 16MB DDR SDRAM

Сетевой адаптер

Интегрированный 2-канальный Intel PRO/1000 T Server Adapter (i82574L), 10/100/1000 Mbit/s

SATA-контроллер

Интегрированный 6 портов SATA 3 Gbps, поддержка уровней RAID 0, 1,5,10(программный)

Оперативная память

RAM 2 GB DDR2-667 Fully Buffered ECC

Жесткие диски

HDD SATA 500GB 7200 rpm

Операционная система

Microsoft Windows Server 2003 R2 Standard x64 Edition RUS c 5-ю клиентскими лицензиями (OEM)

Терминальные лицензии

RUS, CAL(Win2008)*5

Корпус

Настольный

Источники питания

865W, фиксированный

Гарантия

1-3-ий год OS 4-5-ый год Std

Клавиатура

Windows PS/2, черная

Мышь

Оптическая 2-кнопочная с колесом, PS/2, черная

  1. Типовая конфигурация клиентской станции представлена в таблице 1.2.

Таблица 1. 2 - Типовая конфигурация клиентской станции

Корпус

Ego Корпус DEPO MN

Операционная система

Windows 7 Pro 7 32-bit Russian Single packageDSP OEI DVD

Процессор

Intel Core i3 Processor 530 (2-Cores, 2.93GHz, 2.5 GT/s, 4Mb)

Оперативная память

2GB DDR3-1333 Single Channel (1 x 2GB)

Жесткий диск

500GB SATA hard drive (7200rpm)

Накопитель 5.25"

DVD+RW/CD-RW/DVD 16x4x/5xDL/16x4x/16x/48x/24x/48x

Видеокарта

Видеокарта ATI RadeonT HD 5750 (1024Mb, PCI-E DVI+HDMI+DP)

Звуковая карта

Интегрированный восьмиканальный звук

Сетевая карта

Интегрированная Gigabit Ethernet 10/100/1000Base-TX

Клавиатура

Keyboard Black PS/2 Russian

Мышь

Mouse Optical USB Black

Монитор

Acer V173

Рекомендуемая конфигурация клиентской станции:

  • процессор не хуже Intel Pentium Dual Core E5400 (2.7 GHz, 2Mb, 800MHz);
  • оперативная память не менее 512 Mb;
  • жесткий диск не менее 1 GB.

  1. Требования к климатическим условиям эксплуатации

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

  1. Требования к квалификации и численности персонала

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

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

  1. Информационная модель

  1. Выбор способа организации данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует три принципиальных отличия между системами управления реляционными базами данных (СУРБД) и программами электронных таблиц:

  1. Все СУРБД разрабатываются с целью обеспечения эффективной обработки больших объемов информации, намного больших, чем те, с которыми справляются электронные таблицы;
  2. СУРБД может легко связывать две таблицы так, что для пользователя они будут представляться одной таблицей. Реализовать такую возможность в системах управления электронными таблицами сложно, а иногда просто не возможно;
  3. СУРБД минимизирует общий объем базы данных. Для этого таблицы, содержащие повторяющиеся данные, разбиваются на несколько связанных таблиц.

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

На сегодняшний день существует большое количество СУБД, однако наиболее популярными, являются MySQL, Interbase, MS Access, PostgreSQL, DB/2, MS SQL Server, XML, Oracle.

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

  • позволяет создавать базы, состоящие из гигабайтов данных;
  • может поддерживать работу сотен пользователей;
  • платформа Windows (или Linux);
  • позволяет проектировать сложные системы;
  • сильная защита данных;
  • большая мощность языка SQL, развитые возможности базы данных.

  1. Моделирование данных

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

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

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

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

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

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

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

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

  1. Анализ таблиц базы данных

База данных для учета лекарственных средств и изделий медицинского назначения в аптеках стационаров содержит в себе 24 таблицы. Таблицы - это основные объекты любой базы данных, они построены на основе следующей ER-диаграммы:

Рисунок 1.1 - ER - диаграмма

Основные объекты системы.

В системе имеются следующие объекты:

Аптека – объект, соответствующий реальной аптеке стационара.

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

Контрагент – объект, соответствующий контрагенту – изготовителю, продавцу или покупателю.

Номенклатура – объект, предназначенный для хранения данных о номенклатурах.

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

Расход – объект, предназначенный для хранения данных обо всех расходных операциях аптеки.

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

Рассмотрим таблицы подробнее.

Данные об аптеке стационара описаны таблицей Apteka, представленной таблицей 1.3:

Таблица 1.3 – Таблица Apteka

Поле

Тип данных

Описание

1

2

3

AptID

Числовой

Идентификационный номер аптеки стационара

SkladID

Числовой

Идентификационный номер склада аптеки

FamOfKlad

Текстовый

Фамилия кладовщика

FamOfTov

Текстовый

Фамилия товароведа

FamOfBuh

Текстовый

Фамилия бухгалтера

FamOfGlVrach

Текстовый

Фамилия главного врача

DolzhOfOtv

Текстовый

Должность ответственного лица

FamOfOtv

Текстовый

Фамилия ответственного лица

FamOfPerv

Текстовый

Фамилия первого лица

DolzhOfPerv

Текстовый

Должность первого лица

NamePredpr

Текстовый

Псевдоним предприятия

AdresPredpr

Текстовый

Адрес предприятия

UrNamePredpr

Текстовый

Юридическое наименование предприятия

UrAdress

Текстовый

Юридический адрес


Продолжение таблицы 1.3.

1

2

3

INN

Текстовый

ИНН

KPP

Текстовый

КПП

OKONH

Текстовый

ОКОНХ

OKPO

Текстовый

ОКПО

MFO

Текстовый

МФО

RKC

Текстовый

РКЦ

OGRN

Текстовый

ОГРН

PhonePredpr

Текстовый

Телефон предприятия

Fax

Текстовый

Факс

BankID

Числовой

Идентификационный номер банка

OsnSchet

Текстовый

Основной счёт предприятия

KorrSchet

Текстовый

Корреспондирующий счет предприятия

License

Текстовый

Лицензия

DataLicense

Дата

Дата лицензии

DataLastInvent

Дата

Дата последней инвентаризации

Данные о настройках по умолчанию для аптеки содержатся в таблице Nastroiki, вид которой представлен в таблице 1.4:

Таблица 1.4 - Таблица Nastroiki

Поле

Тип данных

Описание

AptID

Числовой

Идентификационный номер аптеки

DefDateOfZapret

Дата

Дата запрета редактирования

DefNDS

Числовой

Ставка НДС

NamePredpr

Числовой

Псевдоним предприятия

KontragID

Числовой

Идентификационный номер поставщика

OrganSertID

Числовой

Идентификатор органа сертификации

EdIzmID

Текстовый

Идентификатор единицы измерения

IstFinansirID

Числовой

Источник финансирования

DefYear

Числовой

Текущий год

Nacenka

Числовой

Наценка при продаже

Таблица DicOtdelenie содержит данные об отделениях ЛПУ, которому принадлежит аптека. Вид таблицы DicOtdelenie представлен таблицей 1.5:

Таблица 1.5 - Таблица DicOtdelenie

Поле

Тип данных

Описание

OtdelenieID

Числовой

Идентификатор отделения

AptID

Числовой

Идентификационный номер аптеки

NameOfOtdelenie

Текстовый

Наименование отделения

FamOfOtdelenie

Текстовый

Фамилия материально-ответственного лица

Таблица DicBank является справочником банков и показана в таблице 1.6:

Таблица 1.6 - Таблица DicBank

Поле

Тип данных

Описание

BankID

Числовой

Идентификатор банка

NameOfBank

Текстовый

Наименование банка

GorodOfBank

Текстовый

Отделение банка (город)

Таблица DicCountry является справочником стран-импортеров. Ее вид представлен таблицей 1.7:

Таблица 1.7 - Таблица DicCountry

Поле

Тип данных

Описание

CountryID

Числовой

Код страны

NameOfCountry

Текстовый

Наименование

Таблица DicKontragent содержит данные о контрагентах (изготовителях, поставщиках, покупателях) и имеед вид, показанный в таблице 1.8:

Таблица 1.8 - Таблица DicKontragent

Поле

Тип данных

Описание

1

2

3

KontrID

Числовой

Идентификатор контрагента

NameOfKontr

Текстовый

Полное наименование контрагента

KorotkoNameOfKontr

Текстовый

Сокращенное наименование предприятия

TypeOfKontragent

Числовой

Тип контрагента

PriznakPostav

Числовой

Признак принадлежности к поставщикам


Продолжение таблицы 1.8.

1

2

3

PriznakPokup

Числовой

Признак принадлежности к покупателям

PriznakIzgot

Числовой

Признак принадлежности к изготовителям

KontrINN

Текстовый

ИНН

CountryID

Числовой

Код страны

KontrAdress

Текстовый

Адрес

KontrPhone

Текстовый

Телефон

KontrFax

Текстовый

Факс

KontrEmail

Текстовый

E-mail

KontrContact

Текстовый

Контактное лицо

KontrKPP

Текстовый

КПП

KontrOKONH

Текстовый

ОКОНХ

KontrOKPO

Текстовый

ОКПО

Таблица BankSchetOfKontr содержит данные о банковских счетах контрагентов. Вид таблицы представлен таблицей 1.9:

Таблица 1.9 - Таблица BankSchetOfKontr

Поле

Тип данных

Описание

KontrID

Числовой

Идентификатор контрагента

BankID

Числовой

Идентификатор банка

SchetOfKontr

Текстовый

Счет контрагента

KorrSchetOfKontr

Текстовый

Корреспондентный счет предприятия

KontrBIK

Текстовый

БИК

Таблица DicFarmGruppa является справочником фармакологических групп и имеед вид, показанные в таблице 1.10:

Таблица 1.10 – Таблица DicFarmGruppa

Поле

Тип данных

Описание

FarmGrID

Числовой

Идентификатор фармакологической группы

NameOfFarmGruppa

Текстовый

Наименование фармакологической группы

KratkoFarmGruppa

Текстовый

Краткое наименование

Таблица DicGruppaPKU является справочником групп предметно-количественного учета. Таблица 1.11 представляет вид DicGruppaPKU:

Таблица 1.11 - Таблица DicGruppaPKU

Поле

Тип данных

Описание

GruppaPKUID

Числовой

Идентификатор группы учета

NameOfGPKU

Текстовый

Полное наименование

KratkoGPKUName

Текстовый

Краткое наименование

PriznakMed

Числовой

Признак медикамента

Таблица DicFarmPreparat, показанная в таблице 1.12, является справочником фармакологических препаратов:

Таблица 1.12 – Таблица DicFarmPreparat

Поле

Тип данных

Описание

FarmPrepID

Числовой

Идентификатор фарм. препарата

NameOfFarmPrep

Текстовый

Наименование

MezрdNameOfPrep

Текстовый

Международное наименование

FarmGrID

Числовой

Фарм.группа

GruppaPKUID

Числовой

Группа ПКУ

ObschPerechenZhizn

Числовой

Общий перечень жизненно важных преп.

RegPerechenZhizn

Числовой

Региональный перечень жизненно важных

VenAnaliz

Текстовый

Вен.анализ

Таблица DicDozirovka является справочником дозировок и имеет вид, представленный таблицей 1.13:

Таблица 1.13 - Таблица DicDozirovka

Поле

Тип данных

Описание

DozirID

Числовой

Идентификатор дозировки

NameOfDozir

Текстовый

Дозировка

Таблица DicEdIzmereniya является справочником единиц измерений. Ее вид представлен таблицей 1.14:

Таблица 1.14 - Таблица DicEdIzmereniya

Поле

Тип данных

Описание

EdIzmID

Числовой

Идентификатор единицы измерения

NameOfEdIzmereniya

Текстовый

Единица измерения

KratkoEdIzmereniya

Текстовый

Краткое наименование

Таблица DicOrganSertif, вид которой показан в таблице 1.15, является справочником органов сертификации:

Таблица 1.15 - Таблица DicOrganSertif

Поле

Тип данных

Описание

OrganSertID

Числовой

Идентификатор органа сертификации

NameOfOrganSert

Текстовый

Наименование органа сертификации

Таблица 1.16 представляет собой вид таблицы DicFormVipuska, являющейся справочником форм выпуска:

Таблица 1.16 - Таблица DicFormVipuska

Поле

Тип данных

Описание

FormVypID

Числовой

Идентификатор формы выпуска

FormVypID

Текстовый

Наименование

Таблица Nomenklatura содержит данные обо всех номенклатурах. Вид таблице представлен таблицей 1.17:

Таблица 1.17 - Таблица Nomenklatura

Поле

Тип данных

Описание

1

2

3

NomenklID

Числовой

Идентификационный номер номенклатуры

NumOfNomenkl

Текстовый

Номенклатурный номер

NameOfNomenkl

Текстовый

Наименование

FarmPrepID

Числовой

Идентификатор фарм.препарата

FormVypID

Числовой

Идентификатор формы выпуска

DozirID

Числовой

Идентификатор дозировки

Fasovka

Текстовый

Фасовка

EdIzmID

Числовой

Идентификатор единицы измерения

Продолжение таблицы 1.17.

1

2

3

NumOfSertif

Текстовый

Номер сертификата

RegNumOfSertif

Текстовый

Рег. номер сертификата

SertDate

Дата

Дата выдачи сертификата

SrokDeistvSertif

Дата

Срок действия сертификата

OrganSertID

Числовой

Орган, выдавший сертификат

PriznakIspolzovaniya

Числовой

Признак использования

PriznakKolichUch

Числовой

Признак количественного учета

PriznakObyazAsortim

Числовой

Обязательный ассортимент

PriznakReceptUch

Числовой

Признак рецептурного учета

PriznakVnutrProizv

Числовой

Признак внутреннего производства

Таблица Seria содержит данные о сериях номенклатур и имеет вид, представленный таблицей 1.18:

Таблица 1.18 - Таблица Seria

Поле

Тип данных

Описание

SeriaID

Числовой

Идентификатор серии

NumSeria

Текстовый

Номер серии

NomenklID

Числовой

Идентификационный номер номенклатуры

ProizvID

Числовой

Идентификатор производителя

SrokGodnosti

Дата

Срок годности

IzyatayaSeria

Числовой

Изъятая серия

Таблица DicIstFinansir, вид которой показан в таблице 1.19 является справочником источников финансирования:

Таблица 1.19 - Таблица DicIstFinansir

Поле

Тип данных

Описание

IstFinansirID

Числовой

Идентиф. номер источника финансирования

NameOfIstFinansir

Текстовый

Наименование источника финансирования

Таблица PrixodDoc содержит данные о приходных документах. Вид таблицы указан в таблице 1.20:

Таблица 1.20 - Таблица PrixodDoc

Поле

Тип данных

Описание

PrihID

Числовой

Идентиф. номер приходного документа

NumPrih

Текстовый

Номер приходного документа в аптеке

DatePrih

Дата

Дата приходного документа в аптеке

NumPrihPost

Текстовый

Номер приходного документа поставщика

DatePrihPost

Дата

Дата приходного документа поставщика

IstFinansirID

Числовой

Идентиф. номер источника финансирования

PostID

Числовой

Идентификатор поставщика

Year

Числовой

Текущий год

Таблица PrixodDannie содержит данные обо всех пришедших номенклатурах по каждому приходному документу. Ее вид представлен таблицей 1.21:

Таблица 1.21 - Таблица PrixodDannie

Поле

Тип данных

Описание

PrihID

Числовой

Идентиф. номер приходного документа

NomenklID

Числовой

Идентификационный номер номенклатуры

SeriaID

Числовой

Идентификатор серии

Vozvrat

Числовой

Возврат

PrihDocCount

Текстовый

Количество по документу

PrihFaktCount

Текстовый

Количество фактическое

PrihCenaIzgot

Текстовый

Цена изготовителя

PrihCena

Текстовый

Цена поставщика без НДС

PrihCenaNDS

Текстовый

Цена поставщика с НДС

PrihStavkaNDS

Текстовой

Ставка НДС

PrihSummaNDS

Текстовый

Сумма НДС

PrihProcent

Текстовый

Процент

PrihAkciz

Текстовый

Акциз

Таблица DicVidOperacii - справочник типов расходных операций. Вид данной таблице показан в таблице 1.22:

Таблица 1.22 - Таблица DicVidOperacii

Поле

Тип данных

Описание

RashOperID

Числовой

Идентификатор расходной операции

NameOfRashOper

Текстовый

Наименование операции

Таблица RashodDoc содержит данные о расходных документах и имеет вид, показанный в таблице 1.23:

Таблица 1.23 - Таблица RashodDoc

Поле

Тип данных

Описание

RashID

Числовой

Идентификац. номер расходного документа

AptID

Числовой

Идентификационный номер аптеки

NumRashDoc

Текстовый

Номер расходного докуммента

DateRash

Дата

Дата ввода расходного документа

RashOperID

Числовой

Идентификатор расходной операции

OtdelenieID

Числовой

Идентификационный номер отделения

PokupID

Числовой

Идентификатор покупателя

DopInfo

Текстовый

Дополнительная информация

Year

Числовой

Текущий год

Таблица RashodDannie, показанная в таблице 1.24, содержит данные о каждой отпущенной номенклатуре в каждом расходном документе:

Таблица 1.24 - Таблица RashodDannie

Поле

Тип данных

Описание

1

2

3

RashID

Числовой

Идентиф. номер расходного документа

NomenklID

Числовой

Идентиф. номер номенклатуры

SeriaID

Числовой

Идентификатор серии

Vozvrat

Числовой

Возврат

IstFinansirID

Числовой

Идентиф. номер источника финансирования

PostID

Числовой

Идентификатор поставщика

PrihCena

Текстовый

Цена поставщика без НДС

RashDocCount

Текстовый

Количество по документу

RashCena

Текстовый

Цена отпуска без НДС


Продолжение таблицы 1.24.

1

2

3

RashCenaNDS

Текстовый

Цена отпуска с НДС

RashStavkaNDS

Текстовый

Ставка НДС

RashSummaNDS

Текстовый

Сумма НДС

RashAkciz

Текстовый

Акциз

Таблица OstatkiDoc содержит данные об общих остатках аптеки во временном разрезе и представленная таблицей 1.25:

Таблица 1.25 - Таблица OstatkiDoc

Поле

Тип данных

Описание

OstID

Числовой

Идентификационный номер документа

AptID

Числовой

Идентификационный номер аптеки

MonthOfOst

Числовой

Месяц остатка

YearOfOst

Числовой

Год остатка

Таблица OststkiDannie содержит данные об остатках по каждой номенклатуре. Вид таблицы показан в таблице 1.26:

Таблица 1.26 - Таблица OststkiDannie

Поле

Тип данных

Описание

OstID

Числовой

Идентификационный номер документа

IstFinansirID

Числовой

Идентиф. номер источника финансирования

PostID

Числовой

Идентификатор поставщика

NomenklID

Числовой

Идентификационный номер номенклатуры

SeriaID

Числовой

Идентификатор серии

KolichOfOst

Текстовой

Количество фактическое

PrihCenaIzgot

Текстовой

Цена изготовителя

PrihCena

Текстовой

Цена поставщика без НДС

PrihCenaNDS

Текстовой

Цена поставщика с НДС

PrihStavkaNDS

Текстовой

Ставка НДС

PrihSummaNDS

Текстовой

Сумма НДС

PrihProcent

Текстовой

Процент

PrihAkciz

Текстовой

Акциз
  1. Типы отношений

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

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

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

Отношение «многие-к-одному» - это отношение противоположно типу «один-ко-многим». Если выбор отношения «многие-к-одному» или «один-ко-многим» не играет большой роли, то отношение между таблицами называется рефлексивным.

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

  1. Схема данных

В разработке автоматизированной системы управления деятельностью компании используется база данных GDB СУБД Interbase. Ее таблицы служат хранилищем всех данных системы. Схема данных показана на рисунке 1.2.


Рисунок 1.2 - Схема данных

  1. Диаграмма форм

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

Рисунок 1.3 - Диаграмма форм

  1. Регистрация - форма, которая открывается при загрузке базы данных. После удачного ввода пароля данная форма закрывается и открывается доступ к главной форме.
    1. Главная форма - главная форма, открывается после удачной авторизации в системе и содержит меню, по которому пользователь выбирает направление работы.
      1. Карточка – форма для работы с карточками товаров.
        1. Приход – форма для работы с приходными накладными.
        2. Расход – форма для работы с расходными документами.
        3. Остаток на дату – форма для работы с документами об остатках препаратов, находящихся на складе аптеки.
        4. Ввод остатков прошлого года – форма, необходимая для начальной настройки системы, а именно установки остатков, находящихся на складе аптеки на начало отчетного года.
        5. Ведомость – форма для формирования ведомостей и стеллажной карточки товара.
        6. Отчет – форма для формирования различных отчетов и книги протаксированных накладных.
        7. Реквизиты аптеки – форма, необходимая для установки юридических данных об аптеке ЛПУ.
        8. Настройка – форма для установки значений по умолчанию для некоторых полей.
        9. Отделения – справочник отделений ЛПУ.
        10. Банки – справочник банков.
        11. Контрагенты и производителей – справочник, содержащий данные о контрагентах и производителях, включая реквизиты их банковских счетов.
        12. Группы предметно-количественного учета (ПКУ) – справочник групп ПКУ.
        13. Фармакологические группы – справочник фармакологических групп.
        14. Номенклатуры – справочник номенклатур.
        15. Дозировки – справочник дозировок лекарственных средств.
        16. Единицы измерения – справочник единиц измерения лекарственных средств.
        17. Источники финансирования – справочник источников финансирования закупок и продаж.
        18. Органы сертификации – справочник органов сертификации лекарственных средств и препаратов медицинского назначения.
        19. Виды списания – справочник видов списания.
        20. Виды расходных операций – справочник видов расходных операций.
        21. Страны – справочник стран, в которых могут быть зарегистрированы производители.

  2. Технологическая часть

    1. Архитектура базы данных

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

Клиент-серверная информационная система состоит в простейшем случае из трех основных компонентов:

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

Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер – это специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных. Формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети передаются только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами.

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

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

  • посылка к серверу запросов;
  • интерпретация результатов запросов, полученных от сервера, и представление их пользователю в требуемой форме;
  • реализация интерфейса пользователя.
  • SQL-сервер - это программа, расположенная на компьютере сетевого сервера. SQL-сервер должен быть загружен на момент принятия запроса от клиента. Функциями сервера БД являются:
  • прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;
  • управление целостностью БД, обеспечение системы безопасности, блокировка неверных действий приложений-клиентов;
  • обеспечение одновременно безопасной и отказоустойчивой многопользовательской работы с одними и теми же данными. В архитектуре «клиент-сервер» используются так называемые «удаленные» СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.

Использование архитектуры «клиент-сервер»:

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

Блок-схема работы разрабатываемой базы данных представлена на рисунке 2.1.

Рисунок 2.1 - Блок-схема работы базы данных

  1. Описание клиентской части программного продукта

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

  1. Начало работы с приложением

При запуске приложения появляется окно «Регистрация», представленное на рисунке 2.2.

Рисунок 2.2 - Окно «Регистрация»

После корректного ввода пользователем своего логина и пароля, ранее выданных системным администратором, откроется окно «Аптека», являющееся главным окном программы. Данное окно показано на рисунке 2.3.

Рисунок 2.3 - Окно «Аптека»

В верхней части окна находится меню, состоящее из следующих пунктов:

  • Движение;
    • Отчеты;
  • Справочники;
  • Сервисные функции;
  • Выход – выход из программы.

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

  1. Движение

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

  • Карточка;
    • Приход;
      • Расход;
      • Остаток на дату;
  • Ввод остатков прошлого года.

Вид меню «Движение» с подменю представлен на рисунке 2.4.

Рисунок 2.4 - Меню «Движение» с подменю

        1. Карточка

Вид окна «Выбор карточки» представлен на рисунке 2.5.

Рисунок 2.5 - Окно «Выбор карточки»

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

Верхнее меню окна состоит из следующих частей.

- показать карточку товара. По нажатию кнопки откроется окно «Карточка товара», показанное на рисунке 2.6. Также это окно можно вызвать, дважды щелкнув на нужной строке таблицы.

Рисунок 2.6 - Окно «Карточка товара»

В верхней части окна расположены следующие кнопки:

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

Рисунок 2.7 - Вид карточки товара, подготовленной к печати

- кнопка «Сформировать». Формирует список карточек за определенный период. Отчетный период выбирается в полях, находящихся слева от кнопки. Дата выбирается из выпадающего по нажатию кнопки календаря, имеющего вид, показанный на рисунке 2.8.

Рисунок 2.8 - Выпадающий календарь.

- кнопка «Ведомость». Описание работы с ведомостями находится в пункте 2.2.3.1.

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

  • по номенклатурному номеру;
  • наименованию препарата;
  • производителю.

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

- кнопка «Выход».

  1. Приход

Окно «Приходная накладная» изображено на рисунке 2.9.

Рисунок 2.9 - Окно «Приходная накладная»

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

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

Рисунок 2.10 - Окно «Приходные накладные»

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

Кроме вышеописанных, в верхней части окна «Приходная накладная» находятся следующие кнопки.

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

- сохранить документ. Становится активной после нажатия кнопки или открытия документа на редактирование.

- кнопка выбора номенклатуры. Открывает справочник номенклатур. Вид окна представлен на рисунке 2.11.

Рисунок 2.11 - Окно «Приходные накладные» с открытым справочником номенклатур

Работа с данным окном аналогична работе с окном «Приходные накладные», описанным выше.

- кнопка печати. Позволяет вывести подготовленную для печати товарную накладную или счет-фактуру. Вид товарной накладной представлен на рисунке 2.12, вид счет-фактуры соответствует рисунку 2.13.

Рисунок 2.12 - Товарная накладная

Рисунок 2.13 - Счет-фактура

  1. Расход

Окно «Расход» представлено на рисунке 2.14.

Рисунок 2.14 - Окно «Расход»

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

Принцип работы с данным окном схож с окном «Приход». Отличие состоит в том, что по нажатию на кнопку открывается окно «Расходные накладные», схожее с окном «Приходные накладные». Атрибутами поиска в этом окне являются: дата ввода, номер документа, покупатель, вид операции.

Кроме этого в окне «Расходные документы» присутствует кнопка , назначением которой является вывод окна «Остатки на указанную дату», описанного в пункте 2.2.2.4.

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

  1. Остаток на дату

Вид окна «Остаток на дату» представлен на рисунке 2.15.

Рисунок 2.15 - Окно «Остатки на указанную дату»

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

- кнопка «Сформировать». Формирует список номенклатур в соответствии с критериями отбора, указанными в правой части окна.

- кнопка печати. Выводит список остатков на предпечатный просмотр, показанный на рисунке 2.16.

Рисунок 2.16 - Предпечатный просмотр списка текущих остатков

  1. Ввод остатков прошлого года

Вид окна «Ввод остатков прошлого года» представлен на рисунке 2.17.

Рисунок 2.17 - Окно «Ввод остатков прошлого года»

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

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

- кнопка «Корректировка». Позволяет откорректировать указанную запись.

- кнопка «Удалить». Служит для удаления выбранной записи.

  1. Отчеты

Пункт меню предназначен для работы с отчетными документами. Содержит следующие пункты подменю:

  • Ведомость;
  • Отчет.

Вид меню «Отчеты» с подменю представлен на рисунке 2.18.

Рисунок 2.18 - Меню «Отчеты» с подменю

    1. Ведомость

Вид окна «Формирование ведомости» представлен на рисунке 2.19.

Рисунок 2.19 - Окно «Формирование ведомости»

Предоставляет пользователю возможность формирования ведомости, а также печати стеллажной карточки (по Форме № АП-73, утвержденной приказом Министерства здравоохранения СССР от 8 января 1988 г. №14) и сличительной ведомости (по Форме № АП-43, утвержденной приказом Министерства здравоохранения СССР от 8 января 1988 г. №14).

- кнопка «Сформировать». Позволяет сформировать ведомость в соответствии с указанными критериями.

- кнопка «Остатки». Выводит окно «Ведомость. Остатки», представленное на рисунке 2.20.

Рисунок 2.20 - Окно «Ведомость. Остатки»

- кнопка «Сумма». Отображает окно с информацией о суммах, представленное на рисунке 2.21.

Рисунок 2.21 - Вид окна, вызываемого кнопкой «Сумма»

- кнопка печати. Позволяет производить предпечатный просмотр сличительной ведомости и стеллажной карточки. Вид данных документов показан на рисунках 2.22 и 2.23 соответственно.

Рисунок 2.22 - Предпечатный просмотр сличительной ведомости

Рисунок 2.23 - Предпечатный просмотр стеллажной карточки

  1. Отчет

Окно «Формирование отчета» изображено на рисунке 2.24.

Рисунок 2.24 - Окно «Формирование отчета»

Позволяет сформировать книгу протаксированных накладных (по Форме № 7-МЗ, утвержденной приказом Министерства здравоохранения СССР от 30 декабря 1987 г. №1337), отчет по приходным накладным, по расходным накладным, остаткам на первое января текущего года, прайс-лист, отчеты по остаткам по группам предметно-количественного учета, по остаткам групп учета, по приходу с остатками, по расходу с остатками.

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

Вид книги протаксированных накладных показан на рисунке 2.25.

Рисунок 2.25 - Окно «Книга протаксированных накладных»

Окно «Приход», отображающее информацию о пришедших номенклатурах по различным критериям отбора, показано на рисунке 2.26.

Рисунок 2.26 - Окно «Приход»

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

Рисунок 2.27 - Окно «Отпущено по отделениям»

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

Рисунок 2.28 - Окно «Списано по актам, счетам и другим документам»

Окно «Прайс-лист» позволяет просматривать данные о цене и текущем остатке той или иной номенклатуры с различными критериями отбора. Вид окна представлен на рисунке 2.29.

Рисунок 2.29 - Окно «Прайс-лист»

С помощью окна «Остатки по группам ПКУ», показанного на рисунке 2.30, пользователь может получить информацию о количестве и стоимости товаров, объединенных по группам предметно-количественного учета.

Рисунок 2.30 - Окно «Остатки по группам ПКУ»

Окно «Остатки по группам учета» содержит информацию о стоимости товаров, объединенных по группам учета. Вид окна представлен на рисунке 2.31.

Рисунок 2.31 - Окно «Остатки по группам учета»

  1. Справочники

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

  • Отделения – справочник отделений по каждому ЛПУ.
    • Банки – справочник банков для контрагентов.
      • Контрагенты и производители – справочник наименований контрагентов и производителей, также содержит реквизиты их банковских счетов.
        • Группы предметно-количественного учета – справочник групп ПКУ.
          • Фармакологические группы – справочник фармакологических групп.
          • Номенклатура – справочник номенклатур.
          • Дозировки – справочник дозировок.
          • Единицы измерения – справочник единиц измерения.
          • Источники финансирования – справочник видов источников финансирования.
          • Органы сертификации – справочник наименований органов сертификации.
          • Виды расходных операций – справочник видов расходных операций.
          • Страны – справочник стран-импортеров.

Вид меню «Справочники» с подменю представлен на рисунке 2.32.

Рисунок 2.32 - Меню «Справочники» с подменю

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

    1. Работа со справочниками на примере справочника «Фармакологические группы»

Вид справочника «Фармакологические группы» представлен на рисунке 2.33.

Рисунок 2.33 - Справочник «Фармакологические группы»

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

Рисунок 2.34 - Вид формы для добавления новой записи в справочник «Фармакологические группы»

- кнопка «Редактирование». Позволяет отредактировать указанную запись справочника.

- кнопка «Удалить». Служит для удаления выбранной записи.

  1. Работа со справочниками на примере справочника «Контрагенты и производители»

Вид справочника показан на рисунке 2.35.

Рисунок 2.35 - Справочник «Контрагенты и производители»

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

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

Рисунок 2.36 - Вид формы для добавления новой записи в справочник «Контрагенты и производители»

Форма ввода новой записи имеет две вкладки. Вторая вкладка показана на рисунке 2.37.

Рисунок 2.37 - Вид вкладки «Расчетный счет» справочника «Контрагенты и производители»

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

- кнопка «Редактирование». Позволяет отредактировать указанную запись справочника.

- кнопка «Удалить». Служит для удаления выбранной записи.

  1. Сервисные функции

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

  • Реквизиты аптеки;
  • Настройка.

Вид меню «Сервисные функции» с подменю представлен на рисунке 2.32.

Рисунок 2.38 - Меню «Сервисные функции» с подменю

    1. Реквизиты аптеки

Вид окна «Реквизиты аптеки» показан на рисунке 2.39.

Рисунок 2.39 - Окно «Реквизиты аптеки»

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

  1. Настройка

Окно «Настройки» представлено на рисунке 2.40.

Рисунок 2.40 - Окно «Настройки»

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


  1. Организационно-экономическая часть