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

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

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

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

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

1.2 Ограничения предметной области

При создании проекта были выявлены следующие ограничения:

- на складе храниться несколько наименований продукции;

- количество продукции измеряется целым числом;

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

- номер договора неизменен и уникален;

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

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

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

- номер товарно-транспортной накладной уникален для предприятия;

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

- одной товарно-транспортной накладной может соответствовать несколько платежных поручений.

2. Проектирование модели в ERWin

2.1 Методология проектирования IDEF1x

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

В данной методологии различают два типа сущности:

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

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

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

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

Атрибуты и группы атрибутов должны:

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

- не использовать NULL значений.

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

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

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

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

Если сущности в IDEF1х диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими.

2.2 Выделение сущностей и атрибутов.

При рассмотрении данной предметной области, я выделил следующие сущности и атрибуты:

ТОВАР СКЛАД ДОГОВОР ПОСТАВЩИК ВИД ТОВАРА

2.3 Связи между сущностями

Связи между сущностями бывают трех типов: один-к-одному, один-ко-многим и многие-ко-многим. В ERWin используются связи один-ко-многим и многие-ко-многим.

Получившиеся в работе сущности, между собой связаны так:

2.4 Переход на физический уровень

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

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

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

3. Описание MS Project

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

Основные особенности пакета:

- иерархические коды структур для задач и ресурсов;

- расходуемые материалы как вид ресурсов;

- месяц как единица длительности работ;

- индивидуальные календари для задач;

- графические индикаторы для наглядного представления "проблемных" задач;

- поля с формулами вычислений, определяемыми пользователями;

- две шкалы времени (основная и вспомогательная);

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

- создание шаблонов проектов.

3.1 Описание WBS

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

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

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

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

3.2 Правила разработки WBS

При разработке WBS необходимо принимать во внимание следующие основные правила:

1. Каждый элемент WBS должен обеспечивать достижение ощутимого результата.

2. Каждый элемент WBS должен являться агрегатом всех подчиненных элементов, перечисленных непосредственно под ним.

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

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

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

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

7. Все результаты в явном виде должны быть включены в WBS.

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

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

10. Результаты должны быть четко определены так, чтобы исключить дублирование объемов работ внутри элементов WBS, в целом по организации или отдельными ответственными за выполнение работ.

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

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

3.3 Иерархия работ

В этом разделе описывается иерархия работ, необходимых мне для выполнения и защиты ВКР бакалавра.

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

Организационные работы по проекту

Выбор руководителя

Выбор темы

Утверждение темы у зав. Кафедрой

Подготовительные работы

Сбор информации

Анализ информации

Постановка задачи и целей работы

Выполнение первой части работы

Оформление введения

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

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

Внесение исправлений и дополнений

Выполнение второй части работы

Описание CASE-средства

Построение моделей и диаграмм

Выполнение поставленных задач

Подготовка выводов

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

Внесение изменений и дополнений

Выполнение презентации

Заключительные работы

Утверждение работы у руководителя

Рецензирование

Подача зав. Кафедрой на утверждение

Подготовка речи

Защита ВКР

Заключение

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

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

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

Также я составил расписание работ, необходимых для написания ВКР бакалавра, и которому я следую.

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

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

Приложение 2 Диаграммы ERWin.

2.1 Логический уровень

2.2 Физический уровень

Приложение 3 Microsoft Project.

Диаграмма Ганта.

Литература

1. Рогозов Ю.И., Стукотий Л.Н., Свиридов А.С. Моделирование систем, ТРТУ, 2004.

2. Рогозов Ю.И., Стукотий Л.Н., Свиридов А.С. Лабораторный практикум по курсу «Моделирование систем», ТРТУ, 2004.

3. Маклаков С.В. CASE-средства разработки информационных систем. BPwin и Erwin -М.: ДиалогМифи, 2001.

Страницы: 1, 2