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

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

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

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

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

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

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

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

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

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

Краснодар 2012

СОДЕРЖАНИЕ

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.4.1 Справочники

3.2.4.2 Константы

3.2.4.3 Документы

3.2.4.4 Отчеты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4.1 Установка OpenCart

3.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 Усредненный метод автоматизации: внедрение адаптируемого решения и оплата услуг по настройке автоматизированной системы.

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

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

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

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

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

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

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

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

PostgreSQL - мощная и тяжелая система, отвечающая всем современным стандартам СУБД. Больше всего подходит для серьезных проектов, требующих сложных баз данных. По скорости работы PostgreSQL уступает MySQL. К тому же администрирование PostgreSQL - тяжелая работа. PostgreSQL - это реляционно-объектная СУБД, в которой есть некоторые расширения для работы с таблицами, на которые можнёо легко отображать иерархии объектов. Но это еще не чисто объектная СУБД.

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

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

DAO - объекты доступа к данным.

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

ADO - ActiveX-объекты работы с данными.

DAO и 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.

ADO представляет собой прикладной объектный интерфейс более высокого уровня, который упрощает доступ к средствам 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 Электронная коммерция предоставляет поставщикам маркетинговые услуги в режиме реального времени и позволяет им совершать сделки без открытия представительств или найма зарубежных агентов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 Склады;

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

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

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

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

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

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

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

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

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

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

4 HTTP-сервер Apache 2;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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"

Наименование атрибута	Описание атрибута	Тип данных
Manufacturer_id	ID производителя	INT(11)
Name	Наименование	VARCHAR(255)
Juristic_person	Юридическое лицо	VARCHAR(255)
Address	Адрес производителя	VARCHAR(255)
OGRN	ОГРН	INT(20)
INN	ИНН	INT(20)
Contact	Контактная информация	VARCHAR(255)

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

Наименование атрибута	Описание атрибута	Тип данных
Product_id	ID продукта	INT(11)
Manufacturer_id	ID производителя	INT(11)
Name	Наименование	VARCHAR(255)
Price	Цена	DECIMAL(15,4)
Date_available	Дата вступления в продажу	DATETIME
Status	Статус активности	INT(1)
Cost	Закупочная цена	DECIMAL(15,4)
Main_category_id	ID родительской категории	INT(11)
Description	Описание	TEXT

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

Наименование атрибута	Описание атрибута	Тип данных
Category_id	ID категории	INT(11)
Parent_id	ID родительской категории	INT(11)
Name	Наименование	VARCHAR(255)
Date_added	Дата добавления	DATETIME

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

Имя атрибута	Описание атрибута	Тип данных
Stock_id	ID склада	INT(11)
Name	Наименование	VARCHAR(255)
Zone	Район	VARCHAR(255)
Address	Адрес	VARCHAR(255)
Markup_wholesale	Процент оптовой надбавки	DECIMAL(15,4)
Markup_retail	Процент розничной надбавки	DECIMAL(15,4)

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

Наименование атрибута	Описание атрибута	Тип данных
Store_id	ID торговой точки	INT(11)
Stock_id	ID снабжающего склада	INT(11)
Name	Наименование	VARCHAR(255)
Address	Адрес	VARCHAR(255)
Markup_retail	Процент розничной надбавки	DECIMAL(15,4)

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

Наименование атрибута	Описание атрибута	Тип данных
Staff_id	ID сотрудника	INT(11)
POE_id	ID склада/торговой точки	INT(11)
UserName	Имя пользователя	VARCHAR(255)
Password	Пароль	VARCHAR(255)
FirstName	Имя	VARCHAR(255)
LastName	Фамилия	VARCHAR(255)
Contact	Контактный номер	INT(11)
LOA	Уровень доступа к БД	INT(3)

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

Наименование атрибута	Описание атрибута	Тип данных
Stock_id	ID склада	INT(11)
Product_id	ID продукта	INT(11)
Count	Количество	INT(11)

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

Наименование атрибута	Описание атрибута	Тип данных
Sale_id	ID продажи	INT(11)
Order_num	№ сделки купли-продажи	INT(11)
Product_id	ID продукта	INT(11)
POS_id	ID склада/торговой точки	INT(11)
Staff_id	ID сотрудника	INT(11)
Time	Время и время продажи	DATETIME
Price	Цена	DECIMAL(15,4)
Count	Количество	INT(11)
Summa	Сумма	DECIMAL(15,4)

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

Наименование атрибута	Описание атрибута	Тип данных
Zakaz_id	ID заказа	INT(11)
Order_num	№ заказа	INT(11)
Product_id	ID продукта	INT(11)
POS_id	ID склада/торговой точки	INT(11)
Staff_id	ID сотрудника	INT(11)
Time	Дата и время заказа	DATETIME
Price	Цена	DECIMAL(15,4)
Count	Количество	INT(11)
Summa	Сумма	DECIMAL(15,4)

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

Наименование атрибута	Описание атрибута	Тип данных
Delivery_id	ID поставки	INT(11)
Delivery_num	№ поставки	INT(11)
Date	Дата поставки	DATE
Provider_id	ID поставщика	INT(11)
Stock_id	ID склада	INT(11)
Product_id	ID продукта	INT(11)
Count	Количества	INT(11)

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

3.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 Организация объектов информационной базы

3.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 можно описать подключения;

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

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

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

6 В последнем поле 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, в нижний регистр.

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

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