Файл: Проектирование реализации операций бизнес-процесса «Продажи» (Методы автоматизации предпринимательской деятельности).pdf

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

3.2.1.1Константы

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

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

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

3.2.1.2Документы

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

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

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

3.2.1.3 Отчеты

В разработанной конфигурации используются два отчета: "Прибыль по районам" и "Рейтинг товаров". Оба отчета используют внешний источник данных "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, установленной на основной сервер, и параметрами используемой базы данных:

В поле Data Source Name указывается имя подключения;
Поле Description можно описать подключения;
В поле TCP/IP Server нужно указать адрес сервера. Например, localhost, если СУБД расположена на том же компьютере, где установлен и сам драйвер подключения;
Поле Port указывает номер порта, через который будет идти подключение;
В поля User и Password записываются, данные пользователя, которому будет позволено подключаться к базе удаленно;
В последнем поле Database требуется указать имя базы данных, с которым приложение будет работать.

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

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

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

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

Для проверки не обязательно запускать режим отладки[1 c144]. Компонент 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.с.132].

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