Автоматизация деятельности фармацевтических компаний на примере ООО "Шексна-Фарма"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

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

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

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

Целью данного проекта является модернизация существующей системы «Склад» на предприятии ООО «Шексна-Фарма».

Для достижения этой цели необходимо выполнить следующие задачи:

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

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

3. Выбрать наиболее выгодный путь решения проблемы.

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

5. Оценить результаты внедрения программного продукта на предприятии.

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

Глава 1. Описание существующей системы

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

1.1 Назначение и функции системы

С момента открытия (1990 г.) по настоящее время на предприятии используется разработанная сотрудниками АСУ система складского учета (далее «программа «Склад»). В самом начале своего развития программа «Склад» имела более узкое назначение и, соответственно, функционал, который сводился в основном к автоматизации исключительно бухгалтерского документооборота. В дальнейшем в течение нескольких лет программа «Склад» эволюционировала, что было обусловлено постоянно возникавшими новыми требованиями к функционалу и аналитике программы вследствие растущего интереса к использованию информационных технологий для управления предприятием. В настоящее время функционал программы значительно расширен. Общий размер исходных файлов достигает 3,1 Мб, а общий размер файлов данных составляет около 12 Гб. Среди самых основных задач программы можно выделить следующие:

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

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

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

1.2 Организация базы данных

Выполнение выше обозначенных функций в масштабе бизнес процессов предприятия ООО «Шексна-Фарма» не может обойтись без оперирования большим количеством данных, поэтому на заре эпохи автоматизации работы предприятия был седлан выбор в пользу передового по тем временам программного продукта FoxPro 2.0 for DOS от компании Fox Holdings © 1989-91.

FoxPro 2.0 - это файл-серверная СУРБД со всеми плюсами и минусами файл-серверных систем управления базами данных.

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

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

2.В версии 2.0 разработчики Fox включили поддержку SQL.

3.FoxPro 2.0 задействовал принцип WYSIWYG - разработка экранов и отчетов с помощью таких средств, как проектировщики (или мастера) экранов и отчетов (Screen Designer и Report Designer). Мастер экранов генерировал код, позволяя использовать метод разработки GUI в ориентированной на текст среде.

Текущая версия Visual FoxPro основана на COM, и Microsoft утверждает, что .NET-версии продукта не будет. Существует проект Sedna, который должен обеспечить возможность взаимодействия Visual FoxPro с .NET.

В настоящее время последней версией продукта является 9.0. Visual FoxPro 9.0 (VFP9.0) использует одноименный язык программирования FoxPro. Среда разработки версии 7.0 может работать в операционных системах Windows 9x и ядра NT, версии 8.0 и 9.0 - только в Windows XP, 2000, 2003. Среда исполнения (runtime) версий 8.0 и 9.0 работает под любой версией Windows, начиная с 98.

Программа FoxPro 2.0 в свое время стала достижением, удивительные возможности ее (сервис в разработке GUI, SQL и молниеносная быстрота доступа к данным) и сегодня не потеряли своей силы в Visual FoxPro. Все же в настоящий момент файл-серверные СУБД уступают клиент-серверным.

1.3 Организация многопользовательского доступа к данным

Будучи файл-серверной СУБД, FoxPro 2.0 предоставляет разработчику достаточно большой инструментарий, с помощью которого можно создать пользовательский интерфейс (правда, используя только текстовый режим видеоадаптера) и обеспечить доступ к данным. Сами же данные должны находиться в общедоступном месте, т.е. - на файловом сервере, для организации которого в 1990 году для ООО «Шексна-Фарма» была выбрана сетевая операционная система NetWare 4.11 от фирмы Novell.

Следует отметить, что NetWare 4.1 наследует ряд возможностей, ставших стандартом среди сетевых операционных систем фирмы Novell. Эти возможности включают в себя такие свойства, как зеркальное отображение (mirroring) и горячее фиксирование (hotfix), защищающие данные на файловом сервере. Принцип связывания (bindery-based) обеспечивает возможность того, что файловый сервер с NetWare 4.1 «видит» серверы с более старыми версиями NetWare.

Файловый сервер NetWare обладает тремя важными механизмами управления памятью:

- Пулы памяти.

- Постраничная организация.

- Защита памяти.

1.3.1 Пулы памяти

Управление памятью файлового сервера, используемое в NetWare 4.1, намного проще, чем в предыдущих версиях NetWare. Операционная система NetWare 2.x, например, была «связана» ограничениями процессора 80286. Хотя можно запускать NetWare 2.x на 80386 или 80486, но исходный код был разработан для 80286. NetWare 3.x вобрала несколько улучшений в управлении памятью. Характерной особенностью NetWare 3.x является набор пулов памяти. Пулы памяти (memory pools) - это подразделы RAM файлового сервера, которые в различных целях используются модулями NLM. Разработчики NLM должны следовать строгим правилам, указывающим, какая память в какой пул должна возвращаться.

NetWare 4.1 отличается упрощенной схемой управления памятью, содержащей только один пул памяти. Все NLM запрашивают память из пула, а по завершении возвращают ее. Чтобы посмотреть, как используется память, можно воспользоваться MONITOR.NLM, выбирая из трех элементов меню: Resource Utilization (Использование ресурсов), Cache Utilization (Использование кэша) и Memory Utilization (Использование памяти).

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

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

С точки зрения NetWare, память размещается в кэш-буферах. Каждый кэш-буфер имеет размер 4 Кб. Фрагментация происходит, когда память в несмежных буферах высвобождается несколькими NLM. Непрерывная свободная память - это память, которая доступна для использования и расположена в смежных буферах. Фрагментированная память разбросана по всей карте памяти.

Когда операционная система пытается разместить другой блок памяти, она не знает, какой буфер доступен и где он расположен. NetWare 4.1 использует процесс сборки мусора (garbage collection) для определения объема имеющейся памяти. В результате сборки мусора составляется перечень доступных буферов памяти в форме таблицы. Эта таблица используется NetWare при выделении памяти модулям NLM. Процессом сборки мусора можно управлять с помощью набора команд SET и задавать следующее:

-Периодичность проведения сборки мусора.

-Объем памяти, при превышении которого начинается сборка мусора.

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

1.3.2 Постраничная организация памяти

NetWare 4.1 в своей схеме распределения памяти использует механизм постраничной организации (paging mechanism) компании Intel. Такой механизм встроен в любой процессор типа 80386 и выше, произведенный Intel или по лицензии Intel. Эта схема позволяет NetWare разбивать память на страницы (pages). Каждая страница - это непрерывный блок памяти размером 4 Кб. Информация о распределенных страницах памяти записывается в страничные таблицы. Страничные таблицы (page tables) - это указатели на страницы памяти, которые разбросаны по всей карте оперативной памяти компьютера. Для отслеживания чрезвычайно больших распределений памяти сами страничные таблицы группируются в домены (domains).

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

1.3.3 Кольцевая защита памяти

Ring memory protection. На эту функцию также ссылаются как на уровень привилегий (privilege level). Память в сервере NetWare 4.1 разделена на четыре области или домена. Каждая такая область в спецификации уровня привилегий Intel называется кольцом (ring). Эти четыре кольца пронумерованы от 0 до 3. Ядро операционной системы NetWare 4.1 всегда выполняется в кольце 0. Другие модули NLM по умолчанию также выполняются в кольце 0.

Если модуль NLM назначается кольцу, отличному от кольца 0, то он не может получить доступ к ресурсам внутренних колец без выполнения того, что называется вызовом межкольцевого перехода (inter-ring gate call). Такой процесс защищает программы, выполняющиеся во внутренних кольцах, и для него требуется дополнительное время процессора. Если, например, известно, что NLM может завершаться аварийно, то для его отладки и для защиты других NLM его можно запустить в кольце 3. Когда NLM, выполняющийся не в кольце 0, завершается аварийно, он воздействует только на себя, а также, возможно, делает недоступным свое кольцо. На других кольцах это не сказывается. На рис. 1.1 представлен процесс выполнения NLM в кольце 3. Можно видеть, что в случае аварийного завершения другие NLM не повреждаются.

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

Рисунок 1.1 - Кольцевая защита памяти

Novell ссылается на домен, охватывающий кольцо 0, как на домен OS (сокращение от «operating system»). Домен, связанный с кольцом 3, называется OSP или OS Protected (от «operating system protected»). Функция защиты кольца-домена включается путем добавления команды LOAD DOMAIN.NLM к конфигурационному файлу сервера STARTUP.NCF. Между доменами можно переключаться, используя одну из следующих команд с консоли файлового сервера: DOMAIN OS или DOMAIN OSP.

Используя возможности операционной системой NetWare 4.11 сотрудниками технического центра компании была организована сетевая работа с использованием протоколов семейства IPX/SPX. Общая схема сети представлена на рис. 1.2.

Рабочие станции, на которых установлена СУБД FoxPro 2.0, вместе с файловым сервером образуют сеть посредством коммутатора и витой пары. Общие ресурсы файлового сервера представлены на рабочих станциях как сетевой диск. Количество рабочих станций достигает 100.



Рисунок 1.2 - Схема локальной сети

Данные в виде файлов двухмерных таблиц с расширением DBF размещены в нескольких директориях. Общее количество файлов таблиц, включая файлы индексов, достигает 70000, а сам размер данных - 30 Гб. Сами данные вступают в достаточно сложные отношения друг с другом, но общая идея организации данных может быть представлена на рис. 1.3.

Рисунок 1.3 - Схема существующей базы данных в общем виде

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

PRIXOD - содержит информацию о приходуемом товаре.

OSTATOK - содержит информацию о текущем наличии товаров.

RASXOD - содержит информацию об израсходованном товаре.

ISG - справочник изготовителей.

SKLAD - справочник способов размещения товаров.

TMC - справочник товарно-материальных ценностей.

ORGAN - справочник организаций, выдающих сертификаты на лекарственные средства.

CENNIK - номенклатурный справочник товаров. (исторически сложившееся название).

REESTR - справочник государственного реестра цен на жизненно важные лекарственные средства.

USERS - информация о пользователях программы «Склад».

POKUP - информация о клиентах компании.

1.4 Проблемы существующей системы и пути их решения

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

- Обеспечение удаленного доступа к перечню товаров на складе (остатки).

- Ограничение доступа к иным данным (кроме остатков)

- Обеспечение отправки накладных на удаленный компьютер.

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

-Возможность организации доступа пользователей через сеть Интернет.

-Возможность защиты от несанкционированного доступа.

-Возможности использования протокола TCP/IP.

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

Учитывая все достоинства и недостатки существующей системы, а также новые требования руководства, логично предположить 2 способа решения проблемы:

1.Полностью заменить существующую систему.

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

2. Аналитический обзор

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

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

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

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

- Гибкий интерфейс взаимодействия пользователем.

- Сложность адаптации к бизнес-процессам предприятия.

- Возможность самостоятельной организации данных.

- Полнота функционала.

- Избыточность функционала.

- Доступ ко всей информации в режиме реального времени.

- Клиент-серверная архитектура.

- Затраты на разработку и/или внедрение.

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

1. «Юнико» Оптовый склад. (Автоматизация оптовой торговли ЛС).

НТО Юнико, начиная с мая 1991г., занимается разработкой программного обеспечения для комплексной автоматизации деятельности предприятий малого и среднего бизнеса.

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

Учитывая специфику фармацевтической деятельности, компания Юнико ведет оперативную поддержку таких баз данных, как «Реестр цен» и «База фальсификатов», поддерживает в актуальном режиме модуль «Учет льготных рецептов» системы «Льготное обеспечение», прошедший проверку с 1999 по 2015 годы во всех муниципальных аптеках Московской области.

Основной функционал и аналитика данного ПО:

- Ведение оптового склада и розничных подразделений;

- Гибкий механизм ценообразования в зависимости от вида подразделения (опт или розница), типа операции (приход, внутреннее перемещение), типа и ценовой группы товара, группы покупателей;

- Контроль торговой наценки на превышение предельно допустимой;

- Резервирование товара;

- Выгрузка прайс-листа в Excel;

- Автоматизированный контроль фальсифицированных ЛС и сроков годности;

- Автоматическое разделение расходной накладной по ставкам НДС товара;

- Автоматическое формирование накладных на внутреннее перемещение, возврат поставщику, списание товара;

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

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

- Полный комплект первичных и отчетных документов в т.ч. согласно Приказу № 14 МЗ РФ: товарная накладная T-12, счет-фактура, счет, протокол согласования цен, сборочный и упаковочный лист, приложение к накладной, спецификация, журнал оптового отпуска АП-22, журнал регистрации по отпуску товаров АП-90, ведомость №11, журнал 41 счета, завозная книга, книги покупок и продаж, товарные отчеты разных видов;

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

- Наличие "Генератора отчетов", который позволяет самостоятельно составлять формы отчетов;

- Выгрузка данных по приходным и расходным документам в бухгалтерский комплекс «Юнико» и для «1С бухгалтерии»;

- Контроль расхода квотируемых ЛС;

- Анализ товародвижения: финансово-экономический, в графическом виде, АВС, ХУZ, рейтинговый по товару, поставщику, торговой наценке, прибыли, скорости продаж, сезонности и др.;

- Формирование заказа товара по результатам анализа минимального остатка, интенсивности расхода, времени исполнения заказа, АВС-групп, с учетом уже заказанного, но еще не поступившего или не оприходованного товара;

- Разграничение прав пользователей с многоуровневым доступом;

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

2. «М-аптека плюс» в конфигурации «Оптовый склад».

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

Компанией «Эскейп» разработан ряд автоматизированных систем управления фармацевтическими предприятиями, таких как: программный комплекс «М-аптека льгота» (1998 г.), автоматизированная система управления аптечными предприятиеми розничной торговли «М-аптека» (1998 г.), автоматизированный программный комплекс «М-аптека плюс» (2001 г.), комплексная система автоматизации управления движением лекарственных средств в регионе, включающая в себя дополнительные модули «М-аптека плюс ЦОД», «М-аптека плюс ДЛО» и «М-аптека плюс ЛПУ» (2007 г.). В настоящий момент программные продукты семейства«М-аптека»в различных версиях и конфигурациях имеют более 4500 инсталляций, охватывая практически все регионы России.

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

Функциональные возможности системы:

- прием товара по заводскому штрих-коду;

- ввод документов вручную или прием электронной накладной от поставщика;

- возможность работы как по заводскому, так и по внутреннему штрих-коду;

ведение контроля качества поступившего товара (проверка серий, сроков годности, сертификатов);

- оформление документов на проведение анализа в лаборатории сертификации;

- размещение товара по местам хранения;

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

- расценка товара;

- сборка товара для продажи (передачи в розничные подразделения);

- отгрузка товара покупателю;

- ведение учета оплаты за отгруженный товар;

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

- составление форм отчетности и других документов по результатам операций приемки-отгрузки товара.

Данная конфигурация позволяет:

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

- получать информацию о продолжительности выполнения операций на складе;

- получать информацию о количестве операций по исполнителям;

- просматривать историю движения товара по местам хранения;

- просматривать остатки товара по конкретным местам хранения;

- просматривать и распечатывать статус оплаты и историю платежей по всем документам;

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

Работа с поставщиками лекарственных средств:

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

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

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

3. «еФарма 2». (ЗАО «Спарго Технологии»).

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

ПО «еФарма 2» разработано на платформе Microsoft.NET Framework 2.0 ориентированной на создание распределенных систем и основанной на инициативе развития защищенных вычислений (Trustworthy Computing Initiative).

«еФарма2 - Центральный офис».

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



Рисунок 2.1 - Система «еФарма»

Возможности «еФарма 2 - Центральный офис»:

- организация единого информационного пространства между всеми точками аптечной сети;

- ведение нескольких складов;

- единое ценообразование для аптечной сети;

- отпуск ЛС населению;

- формирование всей необходимой первичной документации;

- получение статистической отчетности для каждой из аптек;

- обмен данными между подразделениями аптечной сети: складами и аптеками;

- предоставление всей документации и статистической отчетности в центральный офис;

- подключение дополнительных модулей расширения.

«еФарма2 - Аптека».

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

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

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

Основные возможности СПО «еФарма 2 - Аптека»:

- приход товара (вручную или загрузкой электронных накладных);

- формирование всей необходимой первичной документации;

- ценообразование в соответствии с местным и региональным законодательством;

- ведение нескольких складов;

- поддержка торгового оборудования;

- отпуск товаров населению;

- составление отчетности и аналитики по накопленной базе данных;

- возможность работы кассы в on/off-line режиме без потери данных.

4. РС-Аптека

Компания Регард Софт поставляет следующие версии программного комплекса РС-аптека: «Аптека 2007», «Аптека 2005», «Аптека 2002» и «Аптека 2000». Компания работает на рынке систем автоматизации аптечных сетей и аптек с 1995 года. На сегодняшний день число инсталляций систем «Аптека» превышает 1000.

Система поставляется в конфигурациях «Стандарт» и «Аптечная сеть». Конфигурация «Стандарт» предназначена для автоматизации отдельных аптек, не входящих в состав аптечных сетей. Соответственно, для автоматизации аптечных сетей используется конфигурация «Аптечная сеть». Основными элементами системы являются Офис, Управление ценами, Документооборот и Аптеки.

Офис

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

В системе «Аптека 2007» автоматизация этой функций офиса осуществляется модулями «Служба заказов» и «Электронные накладные».

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

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

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

После приема электронных накладных от поставщиков производится расценка товара (ценообразование) и отправка его по аптекам.

Управление ценами

В системе «Аптека 2007» предусмотрена возможность раздельного ценообразования по группам аптек.

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

При ценообразовании производится контроль предельной наценки для препаратов группы ЖНВЛС согласно ограничениям, установленным в конкретном субъекте РФ.

Документооборот

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

При этом документооборот делится на две составляющие: внутренний документооборот и внешний документооборот.

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

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

Аптеки

Автоматизация процесса розничной торговли в системе «Аптека 2007» осуществляется модулями «Аптечный склад», «Розничная торговля» и «Дисконт».

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

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

Модуль «Розничная торговля» настраивается для работы с различными типами контрольно-кассовых машин и периферийного оборудования.

Модуль «Дисконт» поддерживает неограниченное количество маркетинговых программ:

дисконтные программы с применением дисконтных карт, фиксированные скидки по карте сети, скидки от суммы покупки, скидки на отдельные группы товаров, скидки по накопительным данным, одновременное применение разных скидок (мультидисконт);

промо-применение скидок в заданном диапазоне дат на определенные товары;

рекламные и бонусные - при покупке система напоминает фармацевту о необходимости выдачи покупателю подарка.

5. 1С-Рарус: Управление аптекой. (На платформе «1С: Предприятие 8»)

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

Основные функциональные возможности программы:

· Учет лекарственных средств

· Учет фармацевтических групп, форм выпуска, ЕГК

· Указание международного непатентованного наименования, дозировки

· Вхождения в обязательный ассортимент, ЖНВЛС

· Учет различных единиц измерения

· Учет сертификатов и сроков годности, фальсификатов

· Возможность вести аналоги (взаимозаменяемость) товаров

Примечание

Программный продукт «1С-Рарус: Управление аптекой, редакция 1.5» разработан на платформе «1С: Предприятие 8» и является оригинальной конфигурацией. Для работы программы необходимо наличие установленной платформы «1С: Предприятие 8».

Конфигурация имеет защищенные программные модули, недоступные для изменения пользователем.

Основные отличия функционала «1С-Рарус: Управление аптекой» от «1С-Рарус: Управление аптекой Лайт»:

Посерийный учет лекарственных средств в разрезе партий

Автоматизированный контроль сроков годности и фальсификатов

Фронт кассира

Ценообразование и система штрихового кодирования

Система назначения скидок и наценок

Заказы поставщикам

Оприходование товаров и работа с электронными документами поставщиков

Ячеистые склады

Обмен с «1С: бухгалтерия 8»

Ордерные склады

Внутренние заказы и заказы покупателей

Комплектация и разукомплектация товаров

АРМ; закупка, кладовщик, продавец, коммуникатор

Удаленные кассы, обмен с удаленными кассами

Взаиморасчеты с контрагентами

Для подведения итога, можно представить достоинства и недостатки конкурирующего ПО в виде таблицы (Табл. 2.1):

Таблица 2.1 Сравнительный анализ существующих решений

Критерий	Решение, предлагаемое в дипл. проекте	«Юнико»	«М-АПТЕКА плюс»	«еФарма 2»	РС-АПТЕКА 2007	1С-Рарус: Управление аптекой
Гибкий интерфейс взаимодействия с пользователем	1	0	0	0	0	1
Легкость адаптации к сложивш. бизнес-процессам предприятия	1	0	0	0	0	1
Возможность самостоятельной организации данных	1	0	0	0	0	0
Полнота функционала	1	0	1	0	0	0
Отсутствие избыточности функционала	1	0	0	0	0	0
Доступ ко всей информации в режиме реального времени	1	1	1	1	1	1
Клиент-серверная архитектура	0	1	1	1	1	0
Минимальные затраты на разр. и внедрение	1	0	0	0	0	0
ИТОГ	7	2	3	2	2	3

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

3. Анализ требований к системе

3.1 Требования к функциональности

Основное назначение разрабатываемого программного продукта заключается в том, чтобы обеспечить передачу электронного прайса на удаленный компьютер пользователя, автоматизированное формирование заказа пользователем и отправку этого электронного заказа обратно в офис предприятия для дальнейшего оформления в существующей программе «Склад». Исходя из этого были сформулированы общие требования к функциональности программного продукта, которые можно представить в виде use-case диаграммы. (Рис. 3.1)

Рисунок 3.1 - Use-case диаграмма

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

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

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

3. Совместимость. Программа должна гарантировано запускаться в операционных системах семейства Windows (XP/7/8.1).

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

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

6. Скорость. Максимальное время отклика системы не более 5 секунд. Возможность быстрой загрузки электронного прайса по каналу через низкоскоростное модемное соединение.

7. Многопользовательский режим. Возможность одновременного подключения нескольких пользователей к системе. Гарантированная стабильность работы при одновременном подключении не более 100 пользователей.

8. Мониторинг. Возможность отслеживать действия пользователей.

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

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

3.2 Требования к интерфейсу

Интерфейс разрабатываемой программы должен удовлетворять следующим требованиям:

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

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

3. Использование строки состояния для организации обратной связи с пользователем (Вывод сообщений о статусе операции или об ошибках).

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

5. Восстановление предыдущих размеров и положения окна при последующих запусках программы.

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

7. Возможность фильтрования позиций по поставщикам, заказанным позициям и др. признакам.

8. Использование подсказки при вводе искомого наименования с целью ускорения поиска.

9. Постоянное отображение итоговой суммы заказа.

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

11. Выход их программы должен происходить стандартным для систем Windows способом: кнопка «закрыть» в правом верхнем углу окна, выбор команды «закрыть» в системном меню, нажатие Alt + F4.

12. кнопка «ОТМЕНА» должна служить отказу операции редактирования и закрытию окна.

13. должен быть выдержан строгий логический порядок обхода полей по клавише Tab или ENTER.

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

15. система должна обеспечивать наглядное представление на экране большого количества информации.

Требования к интерфейсу, предъявленные ООО «Шексна-Фарма, были тщательно проанализированы. В результате этого в редакторе Microsoft Office Visio 2003 был создан схематический внешний вид программы для пользователя. (Рис. 3.2.)



Рисунок 3.2 - Проектирование внешнего вида клиентского приложения

4. Проектная часть разработки

4.1 Выбор архитектуры

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

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

Из рисунка 4.1 видно, что программный комплекс, разрабатываемый в данной работе включает в себя серверное приложение - «сервер заказов» и клиентское приложение.

Основные задачи сервера заказов сводятся к следующему:

1. Принять запрос на подключение от удаленного клиента.

2. Провести аутентификацию пользователя.

3. После успешной аутентификации провести анализ запроса для формирования требуемой информации.



Рисунок 4.1 - Схема доработанной системы

4. Отправка файлов клиенту (операция скачивания прайса) или принятие файлов от клиента (операция отправки заказа).

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

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

1. Отправить запрос на подключение.

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

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

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

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

4.2 Организация сетевой работы

Основной задачей при проектировании сетевых приложений является задача выбора способа обмена данными между приложениями. Так как изначально заказчик ставил задачу обеспечения возможности работы через Интернет, нужно подобрать наиболее надежные инструменты. Из наиболее популярных способов следует выделить возможность обмена данными по протоколу FTP, HTTP, по почтовым протоколам POP3 и SMTP. Однако в данном случае возникает необходимость установки и соответственно администрирования дополнительного программного обеспечения. В частности, для поддержки FTP необходимо установить и затем администрировать дополнительный FTP-сервер, что делает проектируемую систему зависимой от другого ПО. Работа по HTTP требует установки WEB-сервера, более того возникает дополнительная задача обеспечения аутентификации многочисленных пользователей. Кроме всего такой WEB-сервер должен иметь возможность выполнять сценарии. Обмен данными по почте также требует установки почтового сервера и ведения электронных почтовых ящиков для всех пользователей. Задача осложняется еще и тем, что заказчик в число требований включил возможность настраивать пользователей из существующей программы «Склад». Для решения этой задачи лучше всего подойдет задействование сокетов.

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

Библиотека Winsock поддерживает два вида сокетов - синхронные (блокируемые) и асинхронные (неблокируемые). Синхронные сокеты задерживают управление на время выполнения операции, а асинхронные возвращают его немедленно, продолжая выполнение в фоновом режиме, и, закончив работу, уведомляют об этом вызывающий код. ОС Windows 3.x поддерживает только асинхронные сокеты, поскольку, в среде с корпоративной многозадачностью захват управления одной задачей «подвешивает» все остальные, включая и саму систему. ОС Windows 9x\NT поддерживают оба вида сокетов, однако, в силу того, что синхронные сокеты программируются более просто, чем асинхронные, последние не получили большого распространения. В этом проекте синхронные сокеты будут наиболее интересны.

Сокеты позволяют работать со множеством протоколов и являются удобным средством межпроцессорного взаимодействия, но в данном проекте речь будет идти только о сокетах семейства протоколов TCP/IP, использующихся для обмена данными между узлами сети Интернет. Все остальные протоколы, такие как IPX/SPX, NetBIOS по причине низкой популярности рассматриваться не будут.

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

Помимо потоковых и дейтаграммных сокетов существуют, так называемые, сырые (RAW) сокеты. Они предоставляют возможность «ручного» формирования TCP/IP-пакетов, равно как и полного доступа к содержимому заголовков полученных TCP/IP-пакетов, что необходимо многим сетевым сканерам, FireWall-ам, брандмаузерам и, разумеется, атакующим программам, например, устанавливающим в поле «адрес отправителя» адрес самого получателя. Однако в операционных системах семейства Windows поддержка сырых сокетов весьма ограничена.

4.3 Разработка структуры данных во внешней и оперативной памяти

Структура базы данных программы «Склад».

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

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

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

Таблица 4.1 Структура таблицы POKUP

Имя	Тип и размер	Назначение
NOMER	NUMERIC(6)	Код клиента. Первичный ключ.
NAIM	CHARACTER(50)	Наименование клиента.
LOGIN	CHARACTER(20)	Логин (Учетное имя).
PSWD	CHARACTER(10)	Пароль.
BILLFORMAT	NUMERIC(2)	Тип накладной

Таблица POKUP - единственный файл с расширением `DBF' к которому должен обращаться сервер заказов согласно разрабатываемой архитектуре. Другие таблицы (например, таблица остатков) не должны быть задействованы в работе сервера в целях снижения риска «травматического воздействия» на данные. Таким образом, все данные, которыми обменивается клиент и сервер, передаются в виде файлов. Файлы формируются самой системой «Склад». Например, файл прайса представляет собой текстовые файлы, упакованные в архив, который собственно и передается клиенту.

Серверное приложение может только читать данные из таблицы POKUP. Запрос к этой таблице очень прост: нужно из всех записей выбрать не более одной соответствующей единственному требованию (совпадение логина и пароля). В связи с этим нет необходимости выполнять некий сложный SQL-запрос, а значит и нет необходимости в драйверах на подобие ODBC. Структура и заголовок таблиц DBF достаточно просты и известны. Этой особенностью стоит воспользоваться, так как она дает возможность открыть таблицу DBF как простой файл. Для ускорения работы можно воспользоваться готовым кодом, которым изобилует Интернет. После тщательного изучения ресурсов Интернет можно выделить наиболее удачный компонент - TDBF.

Компонент TDBF Version 1.11 - 14.06.2004. (Copyright 2002-2004 Брусникин И.В.) Компонент предназначен для непосредственного доступа (без использования BDE или ODBC) к файлам формата DBF версий DBase III+, DBase IV, DBase V. Поддерживаемые типы данных: символьный, дата, числа с плавающей точкой, числа с фиксированной точкой, логический. Позволяет выполнять основные операции с DBF-файлами, а также создавать их. Набор доступных методов и свойств компонента максимально приближен к компоненту TTable, но компонент не является потомком TTable и взаимодействовать с визуальными компонентами TDBXXX «не умеет». Работает с Delphi 3.7 под Windows 9X/NT4/2000/XP. Но самое главное его достоинство - это то, что он бесплатный (freeware).