Помощь в написании студенческих работ
Антистрессовый сервис

Деятельность товароведа продуктового магазина

КурсоваяПомощь в написанииУзнать стоимостьмоей работы

Рисунок 6. Объект «Накладная» и его свойства Поля «Номер_накладной» и «Название_фирмы» на рисунке 6 однозначно идентифицируют нужную накладную, так как в рассматриваемом продуктовом магазине номер накладной изменяется в пределах одного поставщика. Это также означает, что два поставщика могут иметь накладные с одинаковым номером. Поэтому выделение в качестве части составного ключа поля… Читать ещё >

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

1.

Введение

Профессия товароведа по сравнению с такими профессиями, как повар, продавец и другие, — молодая.

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

Всё это делает товароведа продовольственных товаров незаменимым специалистом каждого торгового предприятия.

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

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

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

2. Изучение и построение организационной структуры

3. Моделирование деятельности магазина в нотации IDEF0

4. Выделение информационных объектов и построение инфологической модели

5. Построение даталогической и ER-модели Каждая из моделей позволит лучше понять структуру предметной области — продуктового магазина — и организацию деятельности его сотрудников, в частности, товароведа. Это позволит спроектировать наиболее полно отражающую деятельность товароведа информационную систему.

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

3. Описание предметной области В рамках данной курсовой работы в качестве предметной области рассматривается розничный продуктовый магазин.

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

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

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

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

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

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

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

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

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

У директора есть заместитель, который отвечает за тактическое (1−2 года) планирование деятельности магазина, проведение акций и скидочных кампаний.

Бухгалтер ведет учет материальных запасов, операций с денежными средствами и т. д.

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

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

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

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

Подробнее структура магазина представлена на рисунке 1 (страница 7).

Рисунок 1. Организационная структура продуктового магазина

4. Моделирование деятельности продуктового магазина

4.1 Деятельность магазина в нотации IDEF0

IDEF0 (ICAM DEFinition language 0) — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы.

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

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

1. Верхняя сторона имеет значение «Управление» (Control);

2. Левая сторона имеет значение «Вход» (Input);

3. Правая сторона имеет значение «Выход» (Output);

4. Нижняя сторона имеет значение «Механизм» (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком — Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит — родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 — модели.

Модель IDEF0 всегда начинается с представления системы как единого целого — одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

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

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

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

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

Рисунок 2. Контекстная диаграмма

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

Для нашей предметной области (деятельность товароведа) можно выделить три информационных объекта:

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

2. Товар — товаровед заказывает и принимает его у поставщиков, следит за наличием на складе и в магазине;

3. Накладная — основной документ для товароведа после нормативных документов, направленных на контроль качества товаров.

Связаны эти объекты так, как показывает рисунок 3, а отношения между объектами показаны на рисунке 4.

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

Свойства информационных объектов могут быть постоянными, то есть их значения не могут меняться с течением времени, или непостоянными. Постоянные свойства называются статическими (S), а изменяющиеся — динамическими (D).

На рисунке 4 представлен информационный объект «Поставщик» со свойствами.

Рисунок 5. Объект «Поставщик» и его свойства Поле «Название_фирмы» однозначно идентифицируют конкретного поставщика, так как согласно российскому законодательству, у двух компаний не может быть одинаковых названий. Остальные поля дают дополнительную информацию о поставщике. Это показано на рисунке 5.

Рисунок 6. Объект «Накладная» и его свойства Поля «Номер_накладной» и «Название_фирмы» на рисунке 6 однозначно идентифицируют нужную накладную, так как в рассматриваемом продуктовом магазине номер накладной изменяется в пределах одного поставщика. Это также означает, что два поставщика могут иметь накладные с одинаковым номером. Поэтому выделение в качестве части составного ключа поля «Название_фирмы» помогут найти нужную накладную даже в случае, если ёе номер присутствует еще в чьей-либо накладной (другого поставщика). Остальные поля дают дополнительную информацию об объекте «Накладная».

Рисунок 7. Объект «Товар» и его свойства На рисунке 7 поле «Артикул» однозначно идентифицирует товар, в то время как остальные поля дают дополнительную информацию о нём.

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

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

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

· Поставщик

· Накладная

· Товар

· Поставщик_Товар

· Товар_Накладная Таблица 1. Даталогическая модель объекта «Поставщик»

Поле

Тип данных

Размер

Индексированное поле

Пояснение

Название_фирмы

Текст

Да (без совпадений)

Ключ

Тип

Текст

Нет

Выпадающий список

Телефон

Текст

Нет

Маска ввода

Индекс

Текст

Нет

Город

Текст

Да (с совпадениями)

Улица

Текст

Нет

Дом/офис

Текст

Нет

Номер л/с

Текст

Нет

Номер р/с

Текст

Нет

ИНН

Текст

Нет

Наименование банка

Текст

Нет

Таблица 1 содержит данные о поставщике. Ключом таблицы является поле «Название_фирмы». Телефон вводится с помощью маски ввода, а тип поставщика выбирается из выпадающего списка.

Таблица 2. Даталогическая модель объекта «Накладная»

Поле

Тип данных

Размер

Индексированное поле

Пояснение

Номер_накладной

Текст

Да (без совпадений)

Ключ

Название_фирмы

Текст

Да (без совпадений)

Ключ

Дата

Дата/время

Нет

Сумма_по_накладной

Денежный

Нет

Таблица 2 содержит даталогическую модель объекта «Накладная». Ключ у таблицы составной: сюда входят поля «Номер_накладной» и «Название_фирмы».

Таблица 3. Даталогическая модель объекта «Товар»

Поле

Тип данных

Размер

Индексированное поле

Пояснение

Артикул

Текст

Да (без совпадений)

Ключ

Наименование_товара

Текст

Да (с совпадениями)

Производитель

Текст

Да (с совпадениями)

Категория

Текст

Да (с совпадениями)

Выпад. Список

Вес/объем 1 ед.

Текст

Нет

Цена розничная

Денежный

Нет

Наличие на складе

Текст

Нет

Наличие в магазине

Текст

Нет

Продано за сутки

Текст

Нет

Таблица 3 содержит даталогическую модель объекта «Товар». Ключом таблицы является поле «Артикул». Категория товара выбирается из выпадающего списка.

Таблица 4. Связующая таблица «Поставщик_Товар»

Поле

Тип данных

Размер

Индексированное поле

Пояснение

Название_фирмы

Текст

Нет

Артикул

Текст

Нет

ID_Поставщик_Товар

Счётчик

Да (без совпадений)

Ключ

Таблица 4 требуется для отображения связи «Многие-ко-многим» объектов «Поставщик» и «Товар». Ключом таблицы является поле «ID_Поставщик_Товар».

Таблица 5. Связующая таблица «Товар_Накладная»

Поле

Тип данных

Размер

Индексированное поле

Пояснение

ID_Товар_Накладная

Счётчик

Да (без совпадений)

Ключ

Артикул

Текст

Да (с совпадениями)

Название_фирмы

Текст

Да (с совпадениями)

Номер_накладной

Текст

Да (с совпадениями)

Наименование_товава

Текст

Да (с совпадениями)

Количество, единиц

Текст

Нет

Цена за единицу

Денежный

Таблица 5 требуется для отображения связи «Многие-ко-многим» объектов «Товар» и «Накладная»., а также дает информацию о товарах в конкретной накладной. Учитывается тот факт, что по одной накладной поставщик может поставить несколько товаров. Ключом таблицы является поле «ID_Товар_Накладная».

Связи между таблицами представлены на рисунке 8 (страница 18). Ключевые поля таблиц выделены курсивом.

Рисунок 8. Общая схема данных и отображение связей между таблицами

5.

Заключение

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

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

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

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

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

6. Список литературы

1. Автоматизация магазина — EasyBOX [Электронный ресурс] / - Режим доступа: http://www.pos74.ru/shop.htm

2. Джен Л. Харрингтон, «Проектирование реляционных баз данных», изд. «Лори», 1997 г.

3. Диго С. М, «Базы данных. Проектирование и создание», ЕОИ, 2008 г.

Показать весь текст
Заполнить форму текущей работой