Разработка регламента выполнения процесса «Контроль поставок товара. »

Содержание

Введение 

Глава 1. Описание предметной области 3

Глава 2. Выбор средства моделирования 8

Глава 3. Построение диаграмм 12

Диаграмма вариантов использования системы 12

Диаграмма деятельности системы 13

Диаграмма последовательности системы 15

Диаграмма классов 17

Диаграмма состояния: 20

Заключение 22

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

Введение

Закупка товаров предприятием или торговой организацией – наиболее проблемный этап схемы обеспечения материальными ресурсами. В статье про выбор оптимальной схемы обеспечения предприятия материальными ресурсами мы описали своё видение идеи организации учета, общую концепцию. Чтобы максимально сократить издержки при хранении ТМЦ, но при этом гарантировать обеспеченность материалами производственного или торгового процесса, необходимо часть закупок ТМЦ осуществлять адресно (надо -› купили), а часть – для восполнения запасов, которые можно оперативно использовать, снижая зависимость от возможных задержек поставок (надо -› берем с запаса на складе -› покупаем -› восполняем запас).

Целью данной работы является Разработка регламента выполнения процесса «Контроль поставок».

Задачи работы – построить:

- развернутое (подробное) описание предметной области;

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

- диаграмму деятельности;

- диаграмму последовательности;

- диаграмму состояний;

- диаграмму классов

Глава 1. Описание предметной области

Контроль и учет поставок

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

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

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

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

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

• счет-фактура — выписывается поставщиком на имя ' покупателя при отгрузке товаров, в нем должны быть
указаны дата выписки, номер, наименования, ИНН и адреса продавца и покупателя, наименования продуктов, количество, цена, стоимость, ставка и сумма НДС по каждому товару и общая стоимость товаров с учетом НДС, а также страна происхождения товара, если товар выпущен не в РФ; счет-фактура имеет особое значение в учете, так как является основанием для исчисления НДС;

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

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

При доставке товаров железнодорожным или водным
транспортом транспортная организация выписывает железнодорожную (водную) накладную, при перевозке грузов морским путем выписывается коносамент, которые являются товаросопроводительными документами.

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

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

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

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

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

Акты приемки товаров по количеству и качеству являются основанием для предъявления претензий поставщику.

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

В претензионной работе с поставщиками необходимо:

• обеспечивать защиту своих коммерческих интересов;

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

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

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

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

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

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

Глава 2. Выбор средства моделирования

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

Язык UML объединил наиболее известные методы OOA/OOD и очень быстро приобрел широкую популярность среди разработчиков программного обеспечения.

Основными «строительными блоками» UML являются диаграммы, которые условно можно разделить на две категории:

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

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

Моделирование бизнеса с помощью UML предполагает по-следовательное построение двух видов моделей:

прецедентной модели (аналога модели поведения), описывающей функциональность — бизнес-процессы (прецеденты), их взаимодействие с окружением;

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

Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

• диаграммы поведения системы (behavior diagrams):
• диаграммы взаимодействия (interaction diagrams):
• диаграммы последовательности (sequence diagrams) и
• кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
• диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;
• диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; – диаграммы реализации (implementation diagrams):
• диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
• диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В данном учебном пособии для примера моделирования системы выбран программный инструмент моделирования StarUML [7]. Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML [7]. StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (модельно- настраиваемая архитектура), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.

Инструмент поддерживает возможность добавить плагины к базовой системе. Несмотря на то, что записано на языке Delphi, эти плагины могут быть записаны на любом COM-совместимом языке, таком как C++, Delphi, C# и VB.

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

Из прочих достоинств можно выделить:

- Генерация кода в языки: C#, Java, С++

-Поддержка работы с фреймворками

-Удобный графический редактор

-Полное соответствие стандарту UML 2.0

- Возможность расширения функционала (про это написано отдельное руководство разработчика)

-Экспорт документации в форматы: DOC, PPT, TXT, XLS…

- Поддержка паттернов

- Импорт проектов Rational Rose

- Приятный размер дистрибутива

Глава 3. Построение диаграмм

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

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

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

• Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

.

Рисунок 1 – Диаграмма вариантов использования для системы «Салон красоты»

Диаграмма деятельности системы

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

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

Диаграммы деятельности важны не только для моделирования динамических аспектов поведения системы, но и для построения выполняемых систем посредством прямого и обратного проектирования.

Рисунок 2 – Диаграмма деятельности системы

Диаграмма последовательности системы

Диаграмма же последовательностей отображает взаимодействие объектов в динамике. Что значит "в динамике"? Как раз с этим нам и предстоит разобраться.

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

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

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

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

.

Рисунок 3 – Диаграмма последовательности системы

Диаграмма классов

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

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

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

В результате анализа предметной области были выявлены следующие классы (рис 4.):

Рисунок 4 – Классы системы

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

Рисунок 5 – Атрибуты классов системы

Установим отношения между классами (рис.6):

Рисунок 6 –Диаграмма классов системы

Диаграмма состояния:

Диаграмма состояний (state machine diagrams) – это известная технология описания поведения системы. В том или ином виде диаграмма состояний существует с 1960 года, и на заре объектно-ориентированного программирования они применялись для представления поведения системы. В объектно-ориентированных подходах вы рисуете диаграмму состояний единственного класса, чтобы показать поведение одного объекта в течение его жизни.

Рис. 7. Диаграмма состояний системы

Заключение

В результате выполнения курсовой работы была выполнена разработка регламента выполнения процесса «Закупка сырья и материалов». Были изучены и построены следующие диаграммы:

• диаграмма вариантов использования;
• диаграмма деятельности;
• диаграмма последовательности;
• диаграмма состояний;
• диаграмма классов
• диаграмма прецедентов.

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

1. Кознов Д.В Языки визуального моделирования: проектирование и визуализация программного обеспечения. Учебное пособиеСПб.: Изд-во СПбГУ, 2004, 143 с
2. Буч Г., Якобсон А., Рамбо ДжUML 2.0СПб.: Питер, 2006, 735 с
3. UML 2.0 Infrastructure SpecificationMarca D.A., McGowan C.LSADT Structured Analysis and Design Technique McGraw-Hill, 1988
4. Якобсон А., Буч Г., Рамбо Дж Унифицированный процесс разработки програмСПб.: Питер, 2002, 492 с
5. Фаулер М., Скотт К UML. ОсновыСПб.: Символ, 2006, 184 с
6. Леоненков А.ВОбъектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006, 319 с
7. Павлинов А., Кознов Д., Перегудов А., Бугайченко Д., Казакова А., Чернятчик Р., Фесенко Т., Иванов АО средствах разработки проблемно-ориентированных визуальных языков. Сб. «Системное программирование», Вып. 2
8. Гамма Э., Хелм Р., Джонсон Р., Влиссидес ДжПриемы объектно-ориентированного проектированияИзд-во Питер, 2005, 368 с