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

18

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

Курсовая работа

На тему:

Проектирование информационной системы магазина



СОДЕРЖАНИЕ

• Введение
• 1. Описание предметной области
• 2. Моделирование предметной области
• 3. Моделирование данных IDEFL, UML
• 4. Моделирование приложения
• 5. Реализация информационной системы
• Заключение
• Список используемой литературы
• Приложения


ВВЕДЕНИЕ

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

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

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

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

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

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

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



1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

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

размер занимаемой памяти строкового типа (именно так определены атрибуты "Наименование" и "Цвет") больше чем у целочисленного поля "Код товара";

скорость поиска по целочисленному полю существенно больше, чем по строковому;

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

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

"Поставщики" (Код поставщика);

"Склады" (Номер склада);

"Клиенты" (Код клиента);

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

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

Сущность "Товары" связана идентифицирующими связями:

"Один к 0 или 1" с сущностью "Цена";

"Один к 0, 1 или бесконечности" с сущностью "НаСкладе";

"Один к 0, 1 или бесконечности" с сущностью "Бронь";

"Один к 0, 1 или бесконечности" с сущностью "КнигаСчетов";

"Один к 0, 1 или бесконечности" с сущностью "КнигаОпераций";

Идентифицирующая связь используется потому, что ключевой атрибут сущности "Товары" ("Код товара") переносится в состав ключа дочерних сущностей. Для сущностей "НаСкладе", "Бронь", "КнигаСчетов" и "КнигаОпераций" это необходимо поскольку они являются ассоциативными и реализуют связь "Многие ко Многим".

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

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

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

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

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

Аналогично сущности "Поставщики" сущность "Склады" связана теми же видами связей по типу и кардинальности с теми же сущностями "НаСкладе" и "Операции".

Ассоциативная сущность "НаСкладе" не имеет собственных ключевых полей в первичном ключе и формально, обеспечивает связь "Многие ко Многим" между сущностями "Товары", "Поставщики" и "Склады", однако фактически, именно она является ключевой для данной модели. Сущность "НаСкладе" отражает текущее состояние всей системы складирования на предприятии, то есть сколько и какого товара, от какого поставщика есть на данный момент на каждом из складов. Для отображения количества хранимой продукции, в сущность добавлен неключевой атрибут "Остаток". Исходящих связей из этой сущности нет. Все входящие связи от сущностей "Товары", "Поставщики" и "Склады" описаны выше. Они не могут быть не идентифицирующими и принимать null-значения поскольку на складе не может находиться неизвестный товар, так же как и товар от неизвестного поставщика. И естественно, никакое количество определенного товара не может находиться на неизвестном складе. Вполне допустимо, наличие единиц товара не на складах непосредственно а в магазине, однако эта проблема решается путем добавления в таблицу "Склад" базы данных записи со значением поля "Описание" равным "торговый зал магазина".

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

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

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

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

Вторая неидентифицирующая связь кардинальности 1:М к сущности "Счет" обусловлена следующими факторами:

Родитель не может иметь значение null так как счет не может быть открыт сам по себе, без какого-либо владельца. Также у одного счета не может быть несколько владельцев одновременно;

У клиента может быть множество счетов, один счет, или вообще пока не быть счета;

Сущность "Счет" использует "Клиенты" как справочник и внесение внешнего ключа в список ключевых атрибутов сущности "Счет" было бы избыточным;

Идентифицирующая связь сущности "Клиенты" к "Бронь" является реализацией связи "Многие ко Многим" между сущностями "Клиент" и "Товар".

Ассоциативная сущность "Бронь" отражает количество товара, забронированное клиентом. В список ключевых атрибутов сущности добавлено поле "Тип бронирования", которое может принимать значения: "Бронь под будущую реализацию", "Технический осмотр", "Дефектный товар", "Ответственное хранение" и "Минимальный складской резерв". Это обеспечивает клиенту возможность, к примеру, оплатить часть товара и оставить его на складе под ответственное хранение и параллельно забронировать другую партию товара с целью последующей оплаты и загрузки. Для учета количества бронируемых единиц товара в сущность добавлен атрибут "Количество".

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

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

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

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

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

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

Сущность "КнигаОпераций" - ассоциативная, соединяющая связью "Многие ко Многим" сущности "Товары" и "Операции". Используется в модели для сопоставления операции по первичному ключу "Номер операции; Дата операции" и товаров по ключу "Код товара", которых эта операция касается. Количество товара, проведенное по операции, отражается в неключевом поле "Количество". В паре с сущностью "Операции", эта конструкция позволит оформлять действия над партиями из любого количества товаров в таблице "Операции" одной записью, что значительно облегчит хранение, поиск и восприятие этой информации.

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

Графически, логическая и физическая модели системы представлены на рисунках 1 и 2 соответственно.

Рисунок 1 - Логическая концептуальная модель "сущность-связь"

Рисунок 2 - Физическая концептуальная модель "сущность-связь"

2. МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

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

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

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

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

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

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

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

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

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

Штат сотрудников составляет 15 человек. Под руководством директора и его заместителя находятся бухгалтер-кассир, 3 водителя, 4 продавца, 2 сборщика мебели, 3 кладовщика. Водители, продавцы, сборщики и кладовщики частично подчинены бухгалтеру-кассиру, однако основное управление централизованно осуществляется заместителем директора и директором.

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

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

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

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

Рисунок 3 - Структура ООО «Стройка века»

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

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

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

1) покупателю - для оприходования товаров вместо приходного ордера;

2) поставщику - для списания ценностей;

3) для начисления заработной платы водителям автотранспорта;

4) для предъявления в банк на оплату.

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

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

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

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

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

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

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

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

информационный система дистрибьюторский учет



3. МОДЕЛИРОВАНИЕ ДАННЫХ IDEFL, UML

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

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

18

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

Рисунок 4 - Алгоритм обработки данных системы складского учета в общем виде

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

Процедура 1:

create procedure Считать_Клиент_Остаток

returns (Клиент char(30), Счет integer, ОбщийОстаток float, Статус char(2))

as

declare variable номер integer;

declare variable стат integer;

begin

for select Наименование, КодКлиента from Клиенты into :Клиент, :номер do begin

for select НомерСчета, ТипСчета from Счет where КодКлиента=:номер

into :Счет, :стат do begin

if (стат=1) then Статус = 'A'; else

if (стат=2) then Статус = 'B'; else Статус = 'C';

select sum(Остаток) from КнигаСчетов where НомерСчета=:Счет

into :ОбщийОстаток;

if (ОбщийОстаток is null) then ОбщийОстаток = 0;

suspend;

end

end

end;

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

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

Запрос 1: SELECT * FROM Операции_полн

Представление:

create view Операции_Полн

(Номер, ДатаОперации, ИмяКлиента, НомерСклада,

ИмяПоставщика, Цель, Фаб.код, Товар, Цвет, Количество, Ед.изм.)

as

select o.НомерОперации, o.ДатаОперации, c.Наименование, s.НомерСклада, p.Наименование, o.ЦельОперации, t.Фабр.код,

t.Наименование, t.Цвет, x.Количество, t.Ед.изм

from Операции o, Клиенты c, Склады s, Поставщики p, Товары t, КнигаОпераций x

where (o.КодКлиента = c.КодКлиента and o.НомерСклада = s.НомерСклада and o.КодПоставщика = p.КодПоставщика

and o.НомерОперации = x.НомерОперации and o.ДатаОперации = x.ДатаОперации and x.КодТовара = t.КодТовара)

group by o.НомерОперации, o.ДатаОперации, c.Наименование, s.НомерСклада, p.Наименование, o.ЦельОперации, t.Фабр.код,

t.Наименование, t.Цвет, x.Количество, t.Ед.изм;

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



Запрос 2: SELECT * FROM Товар_и_Цена

Представление:

create view Товар_и_Цена

(ФабричныйКод, Товар, Цвет, Вес, Длина, Высота, Ширина, Кол-воПачек,

Поставщик, НомерСклада, Остаток, Ед.изм)

as

select distinct t.Фабр.код, t.Наименование, t.Цвет, t.Вес, t.Длина, t.Высота, t.Ширина,

t.Кол-воПачек, p.Наименование, s.НомерСклада, o.Остаток, t.Ед.изм

from НаСкладе o, Товары t, Склады s, Поставщики p

where (o.НомерСклада = s.НомерСклада and o.КодТовара = t.КодТовара and o.КодПоставщика = p.КодПоставщика)

group by t.Фабр.код, t.Наименование, t.Цвет, t.Вес, t.Длина, t.Высота, t.Ширина,

t.Кол-воПачек, p.Наименование, s.НомерСклада, o.Остаток, t.Ед.изм;

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

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

Запрос 3:

SELECT НомерСклада, Наименование, Остаток, КодПоставщика

FROM НаСкладе о, Поставщики р, Склады s

WHERE о.КодТовара=:tnum and р.КодПоставщика

=о.КодПоставщика and s.НомерСклада=о.НомерСклада;

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



Запрос 4:

SELECT sum(Количество)

FROM Бронь

WHERE КодТовара=:tnum

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

Запрос 5:

SELECT НомерСчета, ТипСчета

FROM Счет

WHERE КодКлиента=:cnum

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

Запрос 6:

SELECT Цена А, Дисконт В, Дисконт С

FROM Цена

WHERE КодТовара=:tnum

Запрос 7:

SELECT ТипСчета

FROM Счет

WHERE КодКлиента=:cnum and НомерСчета=:anum



Данные запросы запускаются при пополнении остатка на выбранном лицевом счете клиента. В зависимости от типа счета, определяемого запросом 7, количество товара или просто умножается на базовую цену товара из запроса 6, или происходит дополнительное умножение на соответствующий дисконтный коэффициент. Итоговый результат заносится в поле "Остаток" таблицы "КнигаСчетов". Схожими с отпуском товара алгоритмами также являются алгоритмы обработки данных при поступлении и бронировании товара.

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

При просмотре и редактировании информации о счетах клиентов используется запрос 8:

SELECT Фабр.код, Наименование, Цвет, Остаток

FROM Товар t, КнигаСчетов a

WHERE а.НомерСчета=:anum

and а.КодТовара=t.КодТовара

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

В случае корректировки статуса счетов, в алгоритме обработки используется хранимая процедура 2:

create procedure Ecnfyjd_Nbg_Cxtnf (UhfybwfD integer? UhfybwfC integer? CElfktybtv smallint)

as

declare variable ОбщийОстаток integer;

declare variable ном integer;

declare variable ном2 integer;

begin

for select КодКлиента from Клиенты into :ном do begin

for select НомерСчета from Счет where КодКлиента=:ном into :ном2 do begin

select sum(Остаток) from КнигаСчетов where НомерСчета=:ном2 into :ОбщийОстаток;

if (ОбщийОстаток is null) then ОбщийОстаток = 0;

if (ОбщийОстаток>=ГраницаC) then

update Счет

set ТипСчета = 3

where НомерСчета = :ном2;

if ((ОбщийОстаток>=ГраницаВ) and

(ОбщийОстаток<ГраницаC)) then

update Счет

set ТипСчета = 2

where НомерСчета = :ном2;

if (ОбщийОстаток<ГраницаВ) then

update Счет

set ТипСчета = 1

where НомерСчета = :ном2;

end

end

if (СУдалением=1) then

update КнигаСчетов

set Остаток = 0;

end;

В качестве входных параметров "ГраницаВ" и "ГраницаС", в процедуру заносятся пороговые значения для перевода лицевого счета клиента в ту или иную ценовую группу. Параметру "Судалением", в зависимости от выбора пользователя, присваивается значение 0 (без обнуления счетов) или 1 (после размещения счетов по ценовым группам, суммы накопленных денежных остатков на них обнуляются). Подобная процедура требуется, например, в случае, когда по внутренним правилам организации клиентским счетам присваивается тип "В" если ежемесячный объем закупок превышает 15000 руб., и тип "С" если объем свыше 50000 руб. В этом случае процедура должна запускаться ежемесячно с входными параметрами:

EXECUTE PROCEDURE Установ_Тип_Счета (15000, 50000, 1);

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

4. МОДЕЛИРОВАНИЕ ПРИЛОЖЕНИЯ

Модель процессов предметной области (ППО) выполнена на основе стандарта IDEF0, с использованием case-системы BPWin компании Logic Works. Целью модели является более полное понимание взаимодействия составляющих системы складского учета, схемы проведения операций, рассмотрение их видов и стадий осуществления.

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

Точка зрения модели: руководитель предприятия.

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

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

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

Таблица 1

Стрелки диаграмм процессов предметной области

Название	Описание	Тип
Нормативные правовые акты РФ	Бухгалтерские, налоговые и прочие юридические правовые акты касающиеся складского учета	Управление
Внутренние правила организации	Регламентирование процедуры проведения операций согласно соглашениям внутри предприятия	Управление
1-е число месяца	Проведение плановой ревизии в начале каждого месяца	Управление
Входящая документация	Товарно-транспортная накладная, кас-совый чек, приходный кассовый ордер поступающие из бухгалтерии	Входная
Продукция	Вся мебельная продукция поступающая, отпускаемая, находящаяся на складе	Входная Выходная
Внутренние регистры учета	Внутренняя информация организации, изменяемая складскими операциями	Входная Выходная
Книга учета товаров	Информация об остатках товаров, регистрация проведенных операций	Входная Выходная
Регистр клиентов	Информация о клиентах, бронь, индивидуальные лицевые счета	Входная Выходная
Регистр поставщиков	Информация о поставщиках	Входная Выходная
Исходящая документация	Отметки о получении товара, заявка на пополнение в бухгалтерию, руководству	Выходная
Поручение	Инициирование начала пересчета, отпуска товара клиенту на складе	Внутренняя
Отчеты	Информация со склада о результатах пе-ресчета, подтверждение приемки товара	Внутренняя
Результат сверки	Сверка подтверждения приемки со склада с товарно-транспортной накладной	Внутренняя
Конечные корректировки	Выявленные расхождения в поставке согласуемые с поставщиком	Внутренняя
Сотрудники фирмы	Сотрудники ведущие дистрибьюторский учет и работники склада	Механизм

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

1) Оформить приемку товара;

2) Выбрать место хранения;

3) Оформить отпуск товара;

4) Произвести ревизию;

5) Выдать заявку на пополнение склада.

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

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

1) «Внутренние регистры учета» состоящий из книги учета товаров, регистра поставщиков и регистра клиентов;

2) «Отчеты» состоящие из подтверждений приемки товаров на склад и результатов пересчета товаров;

3) «Входящая документация» представляющая собой товарно-транспортные накладные, кассовые чеки, приходные ордера.

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

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

Диаграмма на рисунке Е.1 (приложение Е) представляет собой декомпозицию активности «Оформить отпуск товара» и отражает действия сотрудников при отпуске продукции. Функция «Проверить остатки складов» имеет входные информационные потоки «Склады» и «Клиент», поскольку отпуск продукции проводится постоянно (через управляющий поток «Внутренние правила организации») при недостатке той или иной продукции выполняется оформление заявки поставщику а при ее наличие на складе заказ ставится в очередь на доставку, которая упорядочивается. Выходным информационным потоком данной активности явится «транспортный маршрут.

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

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

Данная модель процессов предметной области является существующей (as-is).

5. РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

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

Для создания приложения, организующего доступ и работу с базой данных, оптимально подходит интегрированная среда разработки Delphi 7 Object Pascal компании Borland (Inprise). Delphi 7 позволяет разработать современную многофункциональную программную оболочку базы данных под операционную систему Windows 9x/NT которая сможет удовлетворить потребности всех групп пользователей данной информационной системы.

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

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

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

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

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



ЗАКЛЮЧЕНИЕ

Сегодня наиболее актуальным направлением развития бизнеса является создание спрос-ориентированных сетей поставок (Demand Driven Supply Networks, DDSN), для которых характерна интеграция данных о спросе и процессов внутри цепи поставок с целью достижения баланса между уровнем затрат на них и уровнем доходов. AMR Research дает определение DDSN как <системы технологий и процессов, которая чувствует и реагирует на спрос в режиме реального времени благодаря сети потребителей, поставщиков и сотрудников>. Остановимся на ключевых аспектах чуть подробнее:

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

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

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

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

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

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

Сегодня многие компании понимают, что дистрибуция является той пограничной областью, в рамках которой, с одной стороны, должны быть максимально удовлетворены потребности клиентов, а с другой, учитывая, что на этом этапе формируется добавленная стоимость, постоянно вестись работа по снижению затрат. Правильно спроектированная и внедренная модель дистрибьюторской сети за счет полноты и своевременности выполнения заказов обычно дает существенное сокращение логистического бюджета и повышение уровня клиентского сервиса. Специалисты компании Tompkins Associates приводят следующие цифры, характеризующие переход на оптимальную модель дистрибуции: инвестиции в недвижимость и оборудование сокращаются на 10-25% от первоначальных планов; затраты на транспортировку снижаются на 10-20%; запасы сокращаются на 5-40%; возврат на инвестиции увеличивается на 20%.



СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Аведьян Э.Д., Башлай Д.М., Лебидько Л.М. Система заказа цифровых снимков - Кремлевская медицина. Клинический вестник, №4, 2004.

2. Аведьян Э.Д., Лебидько Л.М., Лямин А.В., Мартынихин А.В. Вопросы применения и адаптации стандарта электронных медицинских документов CDA - Кремлевская медицина. Клинический вестник, №1, 2006.

3. Емелин И.В., Лебидько Л.М. Стандартизация представления электронных медицинских документов - Информационное общество, №1, 2006.

4. Емелин И.В., Лебидько Л.М., Федоров В.Ф. Обеспечение проведения телемедицинских мероприятий с помощью Интернет-портала - Кремлевская медицина. Клинический вестник, №3, 2006.

5. Лебидько Л.М. Адаптация стандарта архитектуры клинических документов - Информационные технологии моделирования и управления, №5, 2006.

6. Лебидько Л.М. Математическая модель телемедицинских систем - Кремлевская медицина. Клинический вестник, №4, 2005.

7. Лебидько Л.М. Стандарт CDA в условиях Российского здравоохранения - Системы управления и информационные технологии, №3.1, 2006.

8. Тарасов В.В., Платицын И.В., Лебидько Л.М., Строганов П.А., Поткин С.Б. Стандартизация протоколов магнитно-резонансных исследований в информационной системе службы лучевой диагностики - Кремлевская медицина. Клинический вестник, №1, 2004.