Автоматизация деятельности торгового предприятия

Автоматизация деятельности торгового предприятия

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение

Высшего профессионального образования

КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

(ФГБОУ ВПО КубГУ)

Кафедра прикладной математики

ДИПЛОМНАЯ РАБОТА

АВТОМАТИЗАЦИЯ ДЕЯТЕЛЬНОСТИ ТОРГОВОГО ПРЕДПРИЯТИЯ

Краснодар 2012

СОДЕРЖАНИЕ

Введение

1. Методы и средства автоматизации предпринимательской деятельности

.1         Методы автоматизации предпринимательской деятельности

1.2  Бесплатные Open-Source СУБД

.3 Технологии удаленного доступа к базам данных

.4 Электронная коммерция

2. Анализ оптово-розничной торговли в сфере флористики. Определение требований к разрабатываемой системе

.1 Общие сведения

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

.3 Требование к CMS

2.4 Требование к ПО для отдела управления торговлей и складов

2.5 Требования к ПО на розничных торговых точках

. Проектирование базы данных. Разработка и настройка необходимых программных продуктов

.1 Проектирование баз данных основного и архивного сервера

.1.1 Описание предметной области

.1.2 Построение реляционной модели данных

.2 Разработка конфигурации 1С: Предприятие

3.2.1 Выбор платформы 1С

3.2.2 Доступ к данным через объект "Внешние источники данных"

3.2.3   Создание подключения к базе данных для управления данным

.2.4 Организация объектов информационной базы

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

.2.4.2 Константы

.2.4.3 Документы

.2.4.4 Отчеты

3.3 Разработка ПО для торговых точек

3.3.1 Выбор среды разработки и обоснование выбора

.3.2 Настройка удаленного соединения с базой данных

.3.3 Приведение некоторых форматов представления данных в Delphi к форматам MySQL

.3.4 Автоматизация работы с несколькими кассирами

.3.5 Импорт номенклатуры из базы данных

.3.6      Совершение операций продаж. Запись в базу данных информации о совершенных продажах и поступивших заказах

.3.6.1 Использование и настройка компонента StringGrid для размещения данных

.3.6.2 Форма указания количества заказываемого или покупаемого продукта и расчет суммы

.3.6.3   Контекстное меню объектов TTreeView в TStringGrid

.3.7 Организация автономного режима

.3.8 Подключение и работа с фискальным регистром. Выдача товарного чека. Настройка фискального регистра

.3.9 Разделение пользователей на группы. Разделение формы приложения на вкладки

.4 Запуск Интернет-магазина

.4.1 Установка OpenCart

.4.2 Изменение внешнего вида и настройка функциональности

Заключение

Список использованной литературы

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

- Запуск и отладка, под нужды предприятия, системы управления содержимым интеренет-магазина;

- Организация единого места хранения информации и доступа к ней, для любого элемента торговой сети;

- Разработка ПО для оптовой торговли;

- Разработка ПО для розничной торговли;

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

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

СУБД MySQL 5.1;

Web-сервер Apache;

PHP 5.3;

CMS OpenCart 1.5.2;

Технологическая платформа 1С: Предприятие 8.2.14;

Среда разработки Borland Delphi 7;

Технология удаленного доступа к базам данных "ActiveX Data Objects" (ADO);

Драйвер MySQL Connector/ODBC 5.1.

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

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

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

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

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

1. Методы и средства автоматизации предпринимательской деятельности

1.1 Методы автоматизации предпринимательской деятельности

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

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

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

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

  Усредненный метод автоматизации: внедрение адаптируемого решения и оплата услуг по настройке автоматизированной системы.

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

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

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

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

Не последнюю роль при автоматизации деятельности предприятий занимают такие вещи как выбор СУБД, используемой системой, и средства разработки. Чем распространенней СУБД, тем проще с ней работать и тем независимей пользователь от разработчика системы, ему легче найти специалиста, который бы смог установить и настроить ее. На многих современных СУБД могут реализовываться несколько программных продуктов, а это еще один плюс в пользу их выбора. То же справедливо и в отношении средств разработки. Чем они известнее и распространеннее, тем больше специалистов, которые им владеют и смогут разрабатывать дополнительные компоненты и, тем меньше стоимость таких услуг. Очень важной является способность программы к интеграции с другими продуктами.

1.2 Бесплатные Open-Source СУБД

Бесплатных СУБД существует немало, но особого внимания достойны два представителя этого вида с открытым исходным кодом (как наиболее распространенные): MySQL. и PostgreSQL. Обе СУБД довольно динамично развиваются и повсеместно используются, так как не просят за себя денег. Продолжаются и еще не скоро утихнут бурные споры о том, какая СУБД лучше. Обе системы очень стабильны, гибки и производительны. У каждой есть свои плюсы и минусы.- быстрая, но немного ограниченная СУБД. Хорошо подходит для проектов, не требующих сложных баз (например, для web-проектов). Первоначально сервер MySQL разрабатывался для управления большими базами данных с целью обеспечить более высокую скорость работы по сравнению с существующими на тот момент аналогами [7]. И вот уже в течение нескольких лет данный сервер успешно используется в условиях промышленной эксплуатации с высокими требованиями. Несмотря на то, что MySQL постоянно совершенствуется, он уже сегодня обеспечивает широкий спектр полезных функций. Благодаря своей доступности, многопоточности процессов, скорости и безопасности MySQL очень хорошо подходит для доступа к базам данных в сети Интернет. Также MySQL поддерживает больше стандартных функций ODBC, чем PostgreSQL.- мощная и тяжелая система, отвечающая всем современным стандартам СУБД. Больше всего подходит для серьезных проектов, требующих сложных баз данных. По скорости работы PostgreSQL уступает MySQL. К тому же администрирование PostgreSQL - тяжелая работа. PostgreSQL - это реляционно-объектная СУБД, в которой есть некоторые расширения для работы с таблицами, на которые можнёо легко отображать иерархии объектов. Но это еще не чисто объектная СУБД.

1.3 Технологии удаленного доступа к базам данных

Существует несколько распространенных технологий удаленного и локального доступа к базам данных. Самыми распространенными из них являются Data Access Objects (DAO), Remote Data Objects (RDO) и ActiveX Data Objects (ADO). - объекты доступа к данным.

RDO - объекты удаленных данных.

ADO - ActiveX-объекты работы с данными.и RDO известны уже достаточно давно, и появление двух разных механизмов было связано с необходимостью оптимизации решения двух отдельных задач: доступа к локальным и удаленным базам данных соответственно. Однако естественное развитие вычислительных систем привело к необходимости создания единого механизма, который обеспечил бы единый подход при работе с БД различных классов.

В результате несколько лет назад Microsoft предложила в качестве единого интерфейса для доступа к локальным и удаленным данным новую технологию ADO [8], которая сегодня является частью архитектуры Microsoft Universal Data Access (MUDA).

Основой MUDA является OLE DB - низкоуровневый программный COM-интерфейс доступа к данным, который представляет собой развитие идеологии ODBC. Однако, если ODBC предназначен для работы с реляционными базами данных (Access, DBF, SQL и др.), то OLE DB предлагает единообразный метод доступа к данным, хранящимся в разных источниках информации, в том числе и в нереляционных БД (например, в папках систем электронной почты или в простых файлах), обеспечивая при этом поддержку работы с наборами данных и иерархическими наборами записей, неподключенными постоянно к сети.

Поставщиками таких данных (OLE DB Provider) могут быть любые источники (в том числе приложения), написанные в соответствии со спецификациями OLE DB. Так, доступ к базам данных ODBC выполняется с помощью OLE DB Provider for ODBC.представляет собой прикладной объектный интерфейс более высокого уровня, который упрощает доступ к средствам OLE DB разработчикам, использующим языки высокого уровня

При работе с удаленными данными быстродействие ADO и RDO примерно одинаково. Что же касается локальных баз данных, то скорость ADO в 3-5 раз ниже, чем у DAO. Это, конечно, не очень хорошо, но следует учитывать, что универсальный механизм всегда уступает специализированному, имея в качестве преимущества упрощение процесса разработки. (Современный стиль разработки заключается именно в таких приоритетах: главное - сократить трудоемкость разработки, а уже потом думать о повышении эффективности приложений. Можно осуждать подобный прагматизм, но факт остается фактом.)

Более важным является другой момент: Microsoft объявила, что будет совершенствовать и обновлять только модель ADO (что соответствует общей стратегии корпорации на унификацию разных технологий на базе ActiveX), то есть DAO и RDO постепенно должны сойти со сцены.

1.4 Электронная коммерция

Своим рождением первые системы и методы электронной коммерции обязаны появлению технологий автоматизации продаж и внедрению автоматизированных систем управления корпоративными ресурсами. В 1960 американские компании American Airlines и IBM приступают к созданию системы автоматизации процедуры резервирования мест на авиарейсы. Таким образом, система SABRE (Semi-Automatic Business Research Environment) делает воздушные перелёты более доступными для рядовых пассажиров, помогая им ориентироваться в тарифах и рейсах, число которых постоянно растет. За счёт автоматизации процесса расчёта тарифов при резервировании мест снижается стоимость услуг. Это являет собой самый первый опыт создания системы электронной коммерции.

Наиболее динамично рынок электронной коммерции развивается в течение последних 20 лет, что обусловлено стремительным ростом количества интернет-пользователей, увеличением влияния социальных сетей и других интерактивных онлайн платформ, динамичным развитием систем электронных платежей, и переходом ведущих веб-сервисов от технологической платформы Web 1.0 к Web 2.0

Преимущества электронной коммерции:

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

2  Электронная коммерция предоставляет поставщикам маркетинговые услуги в режиме реального времени и позволяет им совершать сделки без открытия представительств или найма зарубежных агентов;

  Быстрая и гарантированная доставка предоставляет возможность оптовой и розничной торговле уменьшить объем и номенклатуру необходимых запасов;

  Это, помогает компаниям, и, прежде всего малым и средним, снижать свою себестоимость.

2. Анализ оптово-розничной торговли в сфере флористики. Определение требований к разрабатываемой системе

2.1 Общие сведения

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

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

  Вид деятельности - оптовая и розничная продажи;

  География бизнеса - Краснодарский край и республика Адыгея;

  По краю и республике имеется несколько складов;

  На каждом складе используется программа 1С: Торговля и склад;

  Информация о новом товаре заносится в информационную базу (далее ИБ) вручную работником склада, при поставке;

  Обновление ИБ осуществляется вручную работником склада;

  Каждый склад снабжает несколько торговых розничных точек;

  На торговых розничных точках не имеется программных продуктов, автоматизирующих работу продавца;

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

  Предприятие не имеет электронных средств информирования о своем существовании и деятельности;

  Организация не в состоянии эффективно анализировать ситуацию на рынке из-за разрозненности необходимой информации;

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

  Постоянную циркуляцию информации с минимальными задержками;

  Централизованное место сбора и хранения данных;

  Целостность и достоверность данных;

  Использование единого источника информации, для всей торговой сети предприятия;

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

  Автоматизированное обновление ИБ на складах;

  Автоматизированное обновление информации на торговых розничных точках;

  Бесперебойный сбор информации о совершенных сделках купли-продажи;

  Хранение данных в надлежащем виде, для последующего анализа;

   Возможность организации электронной коммерции.

Для организации такой информационной модели требуется три сервера:

  Основной сервер СУБД, допускающий подключение к ней удаленных программных продуктов предприятия, и являющийся в данном случае единым источником информации;

2  Web-сервер, для запуска и администрирования интернет-магазина. Должен иметь общественный уровень доступа;

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

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

  Отдел управления торговлей;

  Склады;

  Розничные торговые точки;

  Интернет-магазин.

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

Рисунок 1 - Схема информационной модели

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

2.2 Требования к программным продуктам на серверах

Минимальные требования к web - серверу:

1  Скриптовый язык PHP 5.2 или выше;

2  СУБД Mysql 5.0 или выше;

  Служебная программа командной строки Curl и поддержка его в PHP;

  HTTP-сервер Apache 2;

  Любая Операционная система (далее ОС).

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

Установка СУБД MySQL на web-сервер не требуется, не смотря на указанные минимальные требования. Данное ПО, вместе с используемой на web-сервере ОС, будут установлены на основной и архивный сервера. А в настройках HTTP-сервера Apache достаточно будет просто указать адрес основного сервера с параметрами подключения к СУБД MySQL.

2.3 Требования к CMS

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

Требования к интернет-магазину:

  Иметь понятный и легко усваиваемый интерфейс;

  Интерфейс должен быть модульным;

  Отображать самый ходовой продукт;

  Наличие модуля интерфейса рекомендуемых товаров;

  Неограниченная глубина вложенности каталогов;

  Группировка продукции по производителям;

  Наличие справочной информации с возможностью ее пополнения;

  Возможность загружать документации по продукциям;

  Поддержка нескольких языков;

  Поддержка нескольких валют;

  Наличие поисковой системы;

  Иметь администраторскую панель с широким набором функций управления магазином;

  Иметь систему регистрации, аутентификации и авторизации пользователей;

  Иметь удобную и быструю систему заказа продукции;

  Иметь несколько разных способов оплаты продукции;

  Наличие системы скидок для постоянных покупателей;

  Возможность деления покупателей по группам;

  Наличие адресной книги для пользователей имеющих несколько точек доставки;

  Позволять зарегистрированным пользователям просматривать истории заказов;

  Возможность оставлять отзывы о товарах;

  Возможность редактирования покупателями личных данных;

  Иметь систему восстановления пароля;

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

  Обеспечивать конфиденциальность информации о покупателях и заказах;

2.4 Требования к ПО для отдела управления торговлей и складов

Работу на складах и в отделе управления торговлей, необходимо автоматизировать, внедрив технологическую платформу 1С: Предприятие 8.2.14 и, разработав общую для них конфигурацию с двумя соответствующими ролями: управляющий и кассир-кладовщик.

Роль конфигурации для отдела управления торговлей обязательно должна удовлетворять требованиям:

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

  Данные в ИБ должны в точности соответствовать данным на основном сервере;

  Добавление новых записей в ИБ должно сопровождаться обязательным добавлением соответствующих данных на основной и архивный сервера;

  Редактирование любых данных в ИБ должно, обязательно, сопровождаться редактированием соответствующих данных на основном сервере и только;

  Удаление записей из ИБ должно, обязательно, сопровождаться удалением соответствующих данных с основного сервера и только;

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

  Возможность анализа прибыльности складов и розничных торговых точек;

  Возможность анализировать доходы от реализуемой продукции;

Перечень необходимых функций роли для работы на складах:

  Удаленное подключение к основному серверу;

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

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

  Учет количества продукции на складе;

  Проведение документов "Расходная накладная" и "Приходная накладная";

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

  Подключение фискального регистратора и выдача чеков при проведении документа "Расходная накладная";

  Обрабатывать заказы от розничных торговых точек;

  Наличие формы настройки фискального регистратора;

  Наличие формы настройки соединения с СУБД MySQL.

2.5 Требования к ПО на розничных торговых точках

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

  Удаленное подключение к основному серверу;

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

  Работа с несколькими кассирами;

  Наличие системы авторизации;

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

  Записывать удаленно на основной сервер данные о совершенных продажах и поступивших заказах;

  Возможность работать в автономном режиме. Данная функция отсутствует для роли "Кассир-кладовщик", поскольку обеспечить склады надежным постоянным интернет-соединением будет проще и выгоднее, в отличие от торговых розничных точек. Это объясняется тем, что торговые точки могут часто менять местоположение или вовсе закрываться (например, не приносящие прибыли);

  Подключение и работа с фискальным регистратором. Выдача товарного чека;

  Панель настроек соединения с основным сервером СУБД.

3. Проектирование базы данных. разработка и настройка необходимых ПО

3.1 Проектирование баз данных основного и архивного серверов

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

3.1.1 Описание предметной области

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

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

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

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

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

О каждом реализованном товаре должно быть известно: номер сделки купли-продажи (зависит от места реализации), сотрудник отпустивший товар, склад/торговая точка на котором отпущен товар, наименование реализованной продукции, количество проданного товара, цена проданного товара, точное время реализации и итоговая сумма.

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

Сотрудники предприятия делятся на несколько групп. Каждая группа имеет свой уровень доступа к базе данных: для кассиров предназначен самый низкий уровень, а для программистов самый высокий. О каждом сотруднике должно быть известно: ФИО, имя пользователя, пароль, склад/торговая точка на котором работает, адрес, контактный номер и уровень доступа.

Поставка продукции на склады осуществляется непосредственно самими производителями. О каждом производителе должно быть известно: наименование, ИНН, ОГРН, ФИО представителя, юридический адрес и контактный номер. Построение реляционной модели данных

3.1.2 Построение реляционной модели данных

В данном проекте используется реляционная модель данных [6]. Поскольку на сегодняшний день реляционные СУБД стали доминирующим типом программных продуктов для обработки данных. В реляционной модели все данные логически структурированы внутри отношений (таблиц). Каждое отношение имеет имя и состоит из именованных атрибутов (столбцов) данных. Каждый кортеж (строка) данных содержит по одному значению каждого из атрибутов. Большое преимущество реляционной модели заключается именно в этой простоте логической структуры. Хотя, конечно же, за этой простотой скрывается серьезный теоретический фундамент, которого нет у моделей первого поколения (т.е. у сетевых и иерархических моделей). В проектируемой базе данных используются следующие отношения: "l_product" отношение сущности "Товар"; "l_category" отношение сущности категориях товар; "l_stock" и "l_store" отношения сущностей "Склад" и "Торговая точка"; "l_sale", "l_delivery" и "l_zakaz" отношения связей "Реализует", "Поставляет" и "Заказывает"; "l_staff" отношение сущности "Сотрудник"; "l_manufacturer" сущности "Производитель". Структуры отношений проектируемой базы данных:

Таблица 1 - Структура отношения "l_manufacturer"

Таблица 2 - Структура отношения "l_product"

Таблица 3 - Структура отношения "l_category"

Таблица 4 - Структура отношения "l_stock"

Таблица 5 - Структура отношения "l_stores"

Таблица 6 - Структура отношения "l_staff"

Таблица 7 - Структура отношения "l_count_to_stock"

Таблица 8 - Структура отношения "l_sale"

Таблица 9 - Структура отношения "l_zakaz"

Таблица 10 - Структура отношения "l_delivery"

.2 Разработка конфигурации 1С: Предприятие

.2.1 Выбор платформы 1С

Эффективность работы с СУБД во многом зависит от версии платформы 1С, на котором будут, собственно, реализовываться задачи по управлению данными. Передо мной, как и перед многими разработчиками, стоял выбор между платформами версий 7.х и 8.х. С одной стороны проверенная временем версия, наличие обильной справочной информации в сети и множество готовых решений. А с другой стороны новая версия, предоставляющая новые возможности, которые не использовать в данной дипломной работе было бы глупо.

Я, конечно же, выбрал последнее. Следует напомнить, так же, что используемый в проекте "движок" интеренет-магазина, в скором времени, возможно, предоставит возможность обмена данными с 1С. Данный модуль пишется для платформ версии 8.2.

Больше всего меня заинтересовал новый объект конфигурации в редакции 8.2.14: "Внешние источники данных". Именно эта версия платформы будет использоваться в нашем проекте.

Объект "Внешние источники данных" позволяет подключаться к внешним источникам данных и использовать эти данные при формировании отчетов [1]. Внешними источниками данных могут быть:

  SQL Server

  MySQL

- Microsoft Access (*.mdb)

- Microsoft dBase (*.dbf)

  Microsoft Excel (*.xls)

  Microsoft Paradox (*.db )

  Microsoft Text (*.txt; *.csv)

  Microsoft Visual FoxPro (*.dbf)

  SQL Server Native Client 10.0

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

3.2.2 Доступа к данным через объект "Внешние источники данных"

В разработанной конфигурации используется объект "Внешние источники данных" с именем MySQLDB. На вкладке "Данные" (Рисунок 4), данного объекта, задается список таблиц соответствующих выбираемым таблицам базы данных (Рисунок 3). Список таблиц был задан с через прямое подключение к источнику данных, то есть к базе данных, с использованием строки соединения (Рисунок 2). Объект MySQLDB используется только для формирования отчетов.

Рисунок 2 - Параметры подключения к источнику данных

Рисунок 3 - База данных "Lora_BD"

Рисунок 4 - Добавленные таблицы в информационную базу

3.2.3 Создание подключения к базе данных для управления данными

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

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

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

В модуле обычного приложения так же следует написать строки, которые закрывают соединение при выходе из 1С. Обычно соединения закрываются автоматически при выходе из приложения, однако лучше закрывать соединения явным образом, когда приложение завершает доступ к базе данных, чтобы занятые ресурсы могли использовать и другие программы. Что бы данная операция запускалась автоматически при выходе из программы, код закрытия соединения будет записан в тело предопределенной процедуры "ПриЗавершенииРаботыСистемы".

3.2.4 Организация объектов информационной базы

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

Всякий справочник информационной базы соответствует одному или нескольким отношениям базы данных. Все реквизиты справочников имеют тип данных соответствующих им атрибутов отношений. В информационной базе имеются следующие справочники: "Производители", иерархический справочник "Номенклатура", "Склады", "ТорговыеРозничныеТочки" и "Сотрудники" [2].

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

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

3.2.4.2 Константы

Основными объектами, разрабатываемой информационной базы, индивидуализирующие работу складов, являются константы. Значения многих констант, как и список элементов справочников, обновляются при запуске приложения [3]. Константы "Идентификатор", "НомерПоследнегоРасхода" и "НомерПоследнейПоставки" не обновляются и связанны с определенными задачами. Группа констант так же хранят настройки подключения к базе данных, и имеют свою форму.

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

Константы "НомерПоследнегоРасхода" и "НомерПоследнейПоставки" хранят общее количество совершенных операции расхода и прихода, и так же являются последними номерами данных операции. Значение константы "НомерПоследнегоРасхода" увеличивается на единицу, при каждом совершении сделки купли-продажи, а значение константы "НомерПоследнейПоставки" увеличивается на единицу при каждой поставке продукции.

3.2.4.3 Документы

В информационной базе фигурируют три объекта типа "Документы": "Приходная накладная", "Расходная накладная" и "Обработка заказов" [4].

Первые два документа заносят записи в таблицы "l_delivery" и "l_sale". Формы данных документов соответствуют этим таблицам по структуре и типам данных. Записи документов при завершении работы полностью удаляются. Это связанно с тем, что справочник "Номенклатура", информационной базы, обновляется при каждом запуске системы, после чего ссылки на объекты номенклатуры становятся недействительными. Все же возможно и обновление поля "товар", в проведенных документах, ссылающегося на объект Справочники.Номенклатура, посредством поиска элемента по коду, но данная операция потребует неоправданных затрат ресурсов интернет-соединения, при передачи больших объемов информации. Так же проведение документов "Приходная накладная" и "Расходная накладная" меняют записи таблицы "l_count_to_stock", для учета количества продукции на складе.

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

3.2.4.4 Отчеты

В разработанной конфигурации используются два отчета: "Прибыль по районам" и "Рейтинг товаров". Оба отчета используют внешний источник данных "MySQLDB". Причем для соединения с архивным сервером используются методы объекта Внешние источники данных и строка соединения, используемая экземпляром объекта ADODB. В отчете "Прибыль по районам" для отображения результатов используется диаграмма (Рисунок 5). Каждый серия диаграммы соответствует одному району, и показывает уровень прибыли, за указанный период.

Рисунок 5 - Отчет о прибыльности по районам

Отчет "Рейтинг товар" показывает количество каждого проданного товара за установленный период времени, в виде диаграммы (Рисунок 6).

Рисунок 6 - Отчет по рейтингам товаров

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

3.3 Разработка ПО для торговых точек

3.3.1 Выбор среды разработки и обоснование выбора

Для разработки приложения, автоматизирующего работу продавца, использовался императивный, структурированный, объектно-ориентированный язык программирования Borland Delphi 7 (далее BD7), являющийся одним из самых распространенных на сегодняшний день. Данная среда разработки имеет ряд преимуществ:

  Быстрота разработки приложения.

  Высокая производительность разработанного приложения.

  Низкие требования разработанного приложения к ресурсам компьютера.

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

  Возможность разработки новых компонент и инструментов собственными средствами BD7 (существующие компоненты и инструменты доступны с открытым исходным кодом)

  Удачная проработка иерархии объектов

  Наличие большого объема литературы и множества готовых решений в сети интернет.

В BD7 так же имеется множество компонентов, упрощающих работу с базами данных.

3.3.2 Настройка удаленного соединения с базой данных

BD7 имеет достаточное количество инструментов для установления соединения с базой данных. Для решения этой задачи использовался набор объектов ADO, работающих с большинством СУБД через Activex Data Objects.

Установка соединения с БД осуществляется через компонент ADOConnection. Данный компонент имеет множество свойств, для указания всех необходимых параметров процесса соединения с БД. Самыми важными из них являются свойства Active и ConnectionString. Свойство Active указывает текущее состояние соединения, а ConnectionString содержит строку соединения с параметрами подключаемой СУБД. При использовании некорректной строки соединения, свойству Active невозможно присвоить значение True.

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

Рисунок 7 - Первое окно построителя

Поскольку файла, необходимого для первого варианта, еще не было, использовался второй вариант. При этом в поле "Use Connection String" ничего писать не нужно. Для продолжения необходимо нажать кнопку "Build…", после чего открывается новое окно с несколькими вкладками (Рисунок 8). Для создания строки соединения достаточно только указания значений параметров на вкладках "Поставщик данных" и "Соединение".

Рисунок 8 - Свойства канала передачи данных. Поставщик данных

На первой вкладке необходимо из списка выбрать используемый поставщик данных, в данном проекте используется MicroSoft OLE DB Provider for ODBC Drivers, и продолжить настройку. На следующей вкладке, список имен источников данных не будет содержать имя требуемого источника данных. Включить его в данный список можно, воспользовавшись панелью управления операционной системы. Но тогда процесс установки, разрабатываемого приложения, усложнится и, к тому же, будет зависеть от типа операционной системы. Поэтому в первом пункте, необходимо переключиться на параметр "Использовать строку соединения" и нажать кнопку "Сборка".

Рисунок 9 - Свойство канала передачи данных

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

Рисунок 10 - Создание нового источника данных

На панели настроек драйвера необходимо заполнить все поля в соответствии с настройками СУБД MySQL, установленной на основной сервер, и параметрами используемой базы данных:

1  В поле Data Source Name указывается имя подключения;

2  Поле Description можно описать подключения;

  В поле TCP/IP Server нужно указать адрес сервера. Например, localhost, если СУБД расположена на том же компьютере, где установлен и сам драйвер подключения;

  Поле Port указывает номер порта, через который будет идти подключение;

  В поля User и Password записываются, данные пользователя, которому будет позволено подключаться к базе удаленно;

  В последнем поле Database требуется указать имя базы данных, с которым приложение будет работать.

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

Рисунок 11 - Панель настроек драйвера

Если тестирование соединения прошло успешно, то есть было выдано сообщение "Connection Successful", то создание строки соединения заканчивается на данном шаге, подтверждением введенных параметров и согласием на созданную строку (Рисунок 12).

Рисунок 12 - Строка соединения, сформированная построителем

Для проверки не обязательно запускать режим отладки. Компонент ADOConnection может устанавливать соединение и в ходе разработки. Для этого в окне инспектора объектов, устанавливается значение свойства "Connected" в true. Если строка соединения была собрана правильно, откроется форма авторизации пользователя базы данных (Рисунок 13). Если попробовать войти, значение свойства "Connected" установится в true. В случаи ошибки значение остается равным false.

Рисунок 13 - Окно авторизации для базы данных

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

3.3.3 Приведение некоторых форматов представления данных Delphi к форматам MySQL

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

Поскольку в данном проекте СУБД MySQL является элементом структуры, который связывает все остальные элементы, данные представляются в форматах привычных для него.

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

Следующая ошибка возникала при записи в базу данных даты сформированной кодом Delphi. Причем сообщение об ошибке генерировалось при обработке запроса СУБД MySQL, а не в ходе работы программы. Оказалось, что Delphi представляет дату в виде "hh:nn:ss dd.mm.yyyy" (может быть разным, в зависимости от настроек даты и времени в операционной системе), в то время как MySQL, воспринимает только формат "yyyy-mm-dd hh:nn:ss". В отличие от случая разделителя вещественных чисел, для смены формата даты не используется никаких параметров, значения которых можно было бы изменить. В этом случае необходимо в явном виде указывать формат даты при каждой записи в базу данных, используя функцию FormatDateTime(<Формат>,<Дата>) [13].

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

  Переводить код, сгенерированный функцией Delphi, в нижний регистр.

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

  Сравнивать коды без учета регистра.

В этой работе реализован первый вариант.

3.3.4 Реализация системы авторизации и работы с несколькими кассирами

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

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

Рисунок 14 - Форма авторизации

Код обработчика нажатия на кнопку "Авторизация" (листинг), выполняет подключение и запрос к базе данных на получение записи из таблицы "l_kassir" по введенному логину. Если введен верный пароль, запоминаются данные работника и выполняются инициализация формы для работы кассира и скрытие формы авторизации. При вводе неверных данных выдается предупреждающее сообщение (Рисунок 15).

Рисунок 15 - Форма авторизации с неверно введенными данными

3.3.5 Импорт номенклатуры из базы данных

Импорт номенклатуры одна из важных задач, которую требуется реализовать для кассового приложения. Необходимо что бы список продукции и услуг отображался в программе именно в том виде, в каком она представлена в справочнике "Номенклатура", конфигурации, разработанной ранее. Что бы решить эту задачу, были использованы объекты TTreeView и TADOQuery. Компонент TreeView служит для иерархического отображения данных в виде дерева, в котором можно выбрать нужный узел или узлы. Он будет отображать номенклатуру из базы данных. Объект TADOQuery предоставляет собой механизм работы с базой данных, позволяющий получать, модифицировать, удалять или добавлять данные. С помощью него будет извлекаться информация о номенклатуре.

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

Размерность массивов указывается не сразу, так как эта величина будет периодически меняться с изменением объема номенклатуры. Она указывается после подсчета суммы записей таблиц "l_category" и "l_product".

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

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

При запуске программы процедура выстраивает дерево в соответствии с содержимым номенклатуры, правильно воссоздав иерархию элементов, и не потеряв при этом ни одного из них (Рисунок 16).

Рисунок 16 - Номенклатура отображаемая приложением

3.3.6 Совершений операций продаж. Запись в базу данных информации о совершенных продажах и поступивших заказах

Розничные точки, как и склады, записывают информацию о продажах в таблицу "l_sale", а информацию о заказах в таблицу "l_zakaz". На форме имеется кнопка "Провести".

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

  Использование объекта StringGrid, для размещения данных.

  Формы, указания количества заказываемого или покупаемого продукта.

  Контекстное меню объектов TreeView и StringGrid.

3.3.6.1 Использование и настройка компонента StringGrid, для размещения данных

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

Первые колонка и строка таблицы зафиксированы. Первая строка содержит наименование полей ("№", "Id", "Наименование", "Количество" и так далее). Первая колонка отображает номера записей. Так же в свойстве "ScrollBars" установлено значение "ssVertical", что бы использовалась только вертикальная полоса прокрутки (Рисунок 17).

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

Рисунок 17 - Визуальное отображение объекта "StringGrid"

.3.6.2
Форма указания количества заказываемого или покупаемого продукта и расчета суммы

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

Рисунок 18 - Форма указания количества товаров

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

Рисунок 19 - Процесс добавления товара в таблицу

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

Рисунок 20 - Таблица "StringGrid" с одной записью

3.3.6.3 Контекстное меню объектов TTreeView и TStringGrid

При двойном нажатие левой кнопки мыши на элементе дерева, по умолчание будет выставляться операция "Продажа". Для реализации выбора типа операции воспользуется экземпляр объекта "TPopUpMenu" (контекстное меню) [10]. Контекстное меню дерева номенклатуры содержит две команды: "Продажа" и "Заказ". Каждая из команд контекстного меню, как и компоненты, имеет некоторый набор свойств и событий, представляемых в окне инспектора объектов (Рисунок 21).

Рисунок 21 - Редактор команд контекстного меню

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

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

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

Рисунок 22 - Вызов контекстного меню вне области дерева

Рисунок 23 - Вызов контекстного меню в области элемента дерева, обозначающего каталог

Рисунок 24 - Вызов контекстного меню в области элемента дерева, обозначающего реализуемую единицу продукции.

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

Рисунок 25 - Процесс заполнения таблицы нескольким записями

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

Эта задача решена, использованием еще одного экземпляра объекта "TPopUpMenu", который связан с элементом "StringGrid". Для контекстного меню таблицы используются три команды: "Редактировать", "Удалить" и "Удалить все". При выполнении команды "Редактировать", промежуточная итоговая сумма пересчитывается.

Строки таблицы, как и в случае дерева, невозможно выделить нажатием правой кнопки мыши. Поэтому при вызове контекстного меню отлавливаются координаты курсора, относительно действующей формы и проверяется, наличие ячейки в полученных координатах [9]. Если в полученных координатах ячеек не имеется, команды контекстного меню деактивируются (Рисунок 27). В противном случае, выделенная ячейка проверяется на наличие данных. Если она не пуста, команды контекстного меню активируются, а вся строка выделяется (Рисунок 26).

Рисунок 26 - Вызов контекстного меню в области заполненной строки

Рисунок 27 - Вызов контекстного меню вне области заполненных строк

3.3.7 Организация автономного режима работы

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

Рисунок 28 - Предупреждение об отсутствии соединения

Рисунок 29 - Форма авторизации при отсутствии соединения

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

Рисунок 30 - Предложение автономного режима работы

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

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

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

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

3.3.8 Подключение и работа с фискальным регистратором

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

В данной дипломной работе используется драйвер бюджетного фискального регистратора "500М" от компании Штрих-М. Компания поставляет свою продукцию с примерами на разных языках программирования, с программным обеспечением для теста и настройки фискального регистратора. Так же на официальном сайте можно доступны последняя версия драйвера и полное руководство программиста с описанием всех свойств и методов драйвера. Перед использованием фискального регистратора, необходимо установить драйвер (В данной дипломной работе используется драйвер версии 4.2), а затем подключить в коде разрабатываемого приложения. Процедура подключения выполняется при инициализации основной рабочей формы. После чего проверяется состояние подключения аппарата. Поскольку драйвер не имеет методов, автоматически определяющих свободный доступный COM-порт, в приложение реализован перебор всех COM-портов компьютера [5], останавливающийся в случаях, если порт найден или уже перебраны все порты.

3.3.9 Разделение пользователей на группы. Разделение формы приложения на вкладки

Для реализации данной задачи, основная рабочая форма приложения была разделена на две вкладки: "Касса, которая содержит все ранее созданные элементы и "Сервис", которая разделена двумя панелями: "Импорт/экспорт данных" и "Параметры подключения" (Рисунок 31).

Рисунок 31 - Вкладка для пользователей группы "Программисты"

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

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

Поскольку две имеющиеся вкладки, "Касса" и "Сервис", рассчитаны на разные профили работников, то есть кассир не должен заниматься настройками, а программист не должен работать с кассой, приложение распознает группу авторизовавшегося пользователя. Если идентификатор вошедшего пользователя состоит в группе кассиров, приложение обязательно будет проверять наличие соединения с фискальным регистратором и скрывать вкладку "Сервис". При отсутствии подключения к контрольно кассовой машине [15] будет выдано сообщение с описанием ошибки (Рисунок 32), а работа приложения завершится.

Рисунок 32 - Сообщение об ошибке работы фискального регистратора

Если же пользователь состоит в группе администраторов, программа перешагнет через этап проверки фискального регистратора и сделает доступным только вкладку "Сервис".

3.4
Запуск интернет магазина

3.4.1 Установка OpenCart

Установка OpenCart не составляет большого труда, но следует относиться к данной процедуре ответственно. Так как при установке необходимо производить первоначальные настройки. После установки OpenCart, при первом посещении интернет-магазина, открывается первая страница настроек с условиями лицензии GNU с которыми необходимо. На следующей странице OpenCart проверяет версию и параметры настроек PHP и наличие необходимого программного обеспечения. При наличии недостатков, желательно прервать установку, и устранить проблему. Еще одна отличительная черта OpenCart от большинства других CMS, заключается в том, что позволяется продолжать установку, даже если имеются несоответствия нужных параметров с параметрами системы.

Рисунок 33 - Анализ системы установщиком CMS

Следующая страница уже потребует настроить подключение к базе данных. Параметру Database Host присваивается IP адрес основного сервера. Поля User и Password заполняются в соответствии с настройками СУБД MySQL. В Database Name указывается имя подключаемой базы данных, а в качестве префикса используется латинская буква "l".

Рисунок 34 - Настройка подключения к базе данных

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

Рисунок 35 - Стандартный вид магазина, работающего на OpenCart

.4.2 Изменение внешнего вида и настройка функциональности

Были произведены изменения, касательно внешнего вида интернет-магазина, связанные с изменением цветов схем. Как видно на рисунке, в шаблоне, используемом в CMS по умолчанию, преобладает синий цвет. Поскольку автоматизируемое предприятие занимается, по большей части, реализацией цветочной продукции и декоративных растений, использовались оттенки красного и зеленого цветов. Причем были выбраны мягкие оттенки, что бы при просмотре страниц не напрягались ни зрение, ни внимание посетителя. Для изменения текущих цветов сайта можно воспользоваться любым редактором изображений, позволяющий менять цвет и насыщенность изображения [11]. Изображения, используемые движком, расположены в каталоге \catalog\view\theme\default\image.

Так же были изменены некоторые надписи интернет-магазина и функционал. На рисунке 36 продемонстрирован вид интернет-магазина на движке OpenCart, после изменений.

Рисунок 36 - Вид магазина после изменений.

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

Список использованной литературы

1 Тишбаев А.М. 1С:Предприятие 8.Версия для обучения программированию. URL:http://devtrainingforum.v8.1c.ru/forum/.

  Гончаров Д.И., Хрусталева Е.Ю. Технологии интеграции 1С:Предприятия

  Радченко М.Г. 1С:Предприятие 8.2. Практическое пособие разработчика

  Сергей Кашаев. 1C:Предприятие 8. Учимся программировать на примерах

  Форум программистов и сисадминов. URL:http://www.cyberforum.ru/programming/.

  Паутов А.В. MySQL: руководство профессионала. URL:http://lib.rus.ec/b/328368/read.

  Виктор Гольцман. MySQL 5.0. СПб., 2009.

  Людоговский Александр. Использование библиотеки ADO (Microsoft ActiveX Data Object). URL:http://www.script-coding.com/ADO.html.

9 Самоучитель по Delphi для профессионалов. URL:http://www.computerbooks.ru/books/Programming/Book-Delphi-for-professionals/index.html.

  Любаев Владимир. Delphi: уроки и примеры. URL:http://www.delphiexpert.ru/.

  Прохоренок Н.А. HTML, JavaScript, PHP и MySQL. Джентльменский набор Web-мастера. СПб., 2010.

  Джен Харрингтон. Разработка баз данных, СПб., 2005.

  Марат Ильмаз. OpenCart 1.4 Гид Новичка. Бирмингем, 2010.

  НТЦ "Штрих-М. Руководство программиста. Штрих-М: Драйвер

ФР. НН., 2004.