Автоматизация склада

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

Содержание

1. Анализ предметной области и разработка технического задания

2. Описание деятельности

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

4. Бизнес - объектная модель

5. Разработка пользовательского интерфейса

6. Выбор средств программной реализации

7. Технологические средства конфигурирования и администрирования системы 1С: Предприятие 8.0

8. Создание информационной системы

9. Технико-экономическое обоснование

Заключение

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

Введение

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

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

Руководство не может своевременно получить нужную информацию, работа персонала выходит из-под контроля, товар «загадочно исчезает», при этом не выходя за ворота склада. Таких сложностей у каждого предприятия может быть множество, и все вместе они приводят к значительным совокупным потерям компании, вынуждая ее руководство задуматься о путях их преодоления. Одним из них становится внедрение автоматизированной системы управления складом. Управление складом у многих ритейлеров и дистрибьюторов построено на основе ERP-систем (SAP, Oracle и т.д). Но эти системы нельзя назвать WMS (Warehouse Management System - системами управления складом).

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

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

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

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

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

1. Анализ предметной области и разработка технического задания

Основные понятия и их определения

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

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

Склад - обособленная структурированная область пространства, предназначенная для получения, хранения, внутренней переработки и отпуска товара.

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

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

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

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

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

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

Зона Склада - область склада (камера, пандус) предназначенная для хранения товара или для проведения приёмки/отгрузки товара на склад/со склада.

Ячейка - позиция зоны склада, непосредственный адрес хранения товара.

Ярус Ячейки - ряд ячейки по вертикали

Позиция в ячейки - ряд ячейки по горизонтали, в глубину.

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

Отгрузка товара - Процедура отгрузки включает в себя подборку товара формирование его в зоне отгрузки и отпуск товара со склада.

Перемещение товара - складской процесс по изменению места расположение товара на складе.

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

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

Паллета - под паллетой в системе может пониматься любая тара: поддон, коробка, контейнер, имеющая идентификатор

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

2. Описание деятельности

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

Каждая из заявок клиента на приёмку товара, проверяется на возможность принятия товара на склад

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

После прибытия транспортных средств клиента по заявке на приемку/хранение экспедиторы сдают документы (ТТН) в технический отдел. Далее сотрудники технического парка выполняют разгрузку товара из транспортных средств, и размещение товара на складе.

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

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

Система должна обеспечивать выполнение следующих функций:

Задание топологии складского комплекса:

Разделение на зоны

Разделение на ячейки

Разделение на ярусы

Приемка товара

Приемка товаров на склад в зону приемки

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

Размещение на места хранения

Задание условий хранения товара (температурный режим)

Задание правил размещения

Подбор товара для отгрузки

Отгрузка товара со склада

Возможность формирования аналитической отчетности

Отчет по движению товара

Отчет по остаткам товара на складе

Отчет по предоставленным услугам

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

В качестве средств проектирования, системы «Складская Логистика», обеспечивающая комплексную автоматизацию управления складскими процессами. Был выбран унифицированный язык моделирования UML (Unified Modeling Language) и Erwin -моделирование для БД.

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

Язык UML основан на некотором числе базовых понятий, которые могут быть изучены и применены большинством программистов и разработчиков, знакомых с методами объектно-ориентированного анализа и проектирования. При этом базовые понятия могут комбинироваться и расширяться таким образом, что специалисты объектного моделирования получают возможность самостоятельно разрабатывать модели больших и сложных систем в самых различных областях приложений. [7]

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

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

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

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

CASE-средство IBM Rational Rose со времени своего появления претерпело серьезную эволюцию, и в настоящее время представляет собой современный интегрированный инструментарий для проектирования архитектуры, анализа, моделирования и разработки программных систем. Именно в IBM Rational Rose язык UML стал базовой технологией визуализации и разработки программных систем, что определило популярность и стратегическую перспективность этого инструментария. [8]

Для проектирования логической модели данных было выбрано средство ЕRwin. ERwin - современный и распространенный метод моделирования для БД.

ERwin имеет два уровня представления модели - логический и физический. [2]

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

Логическая модель данных является универсальной и не связана с конкретной реализацией СУБД.

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

Разделение модели данных на логические и физические позволяет решить несколько важных задач.

Многие СУБД имеют ограничения на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т.п.).

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

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

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

Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели проектировщик может выбрать необходимую СУБД и ERwin автоматически создает соответствующую физическую модель. [2]

Интерфейс ERwin выполнен в стиле Windows - приложений, достаточно прост и интуитивно понятен.

Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Варианты использования можно представить с помощью диаграммы UML Use Case. Диаграмма Use Case (диаграмма прецедентов или вариантов использования) определяет поведение системы с точки зрения пользователя. Диаграмма Use Case рассматривается как главное средство для первичного моделирования динамики системы, используется для выяснения требований к разрабатываемой системе, фиксации этих требований в форме, которая позволит проводить дальнейшую разработку [3].

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

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

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

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

Опишем более подробно каждый из прецедентов, изображенных на диаграмме.

Актеры:

ь Банк;

ь Бухгалтерия;

ь Клиент;

ь Коммерческий отдел;

ь -сотрудник, который в свою очередь обобщает бухгалтерию и Коммерческий отдел;

Варианты использования:

ь Заключение Договора на ответственное хранение;

ь Предоставление услуг Ответственного хранения включающее, в себя Биллинг;

ь Оплата услуг;

ь Предоставление информации об оплате;

ь Анализ взаиморасчётов4

ь Учёт Оплаты имеющее расширение Учет Предоплаты;

ь Отчеты Бухгалтерские;

ь Анализ услуг Ответственного хранения;

В нее входят следующие бизнес - актеры и варианты использования:

Актеры:

ь Клиент;

ь Коммерческий отдел

ь ТехОтдел

ь Техпарк

Варианты использования:

ь Договор

ь Предоставление Товарного справочника

ь Биллинг

ь Составление Заявки на Приемку

ь Утверждение Приемки

ь Составление Задания на Приемку

ь Выполнения Задания на Приёмку

ь Составление Заявки на Отгрузку

ь Утверждение Отгрузки

ь Составление Задания на Отгрузку

ь Выполнение Задания а Отгрузку

ь Предоставление Аналитической Отчетности

Опишем более подробно каждый из вариантов использования, изображенных на диаграмме.

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

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

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

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

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

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

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

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

За каждой деятельностью может следовать другая деятельность. При этом они образуют простую последовательность.

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

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

ь решение (ромбик с одной входящей и несколькими исходящими стрелками);

ь начальное состояние (черный кружок);

ь конечное состояние (не закрашенный кружок, в котором размещен, черный кружок меньшего размера).

ь символ для разделения и слияния параллельных вычислений или потоков управления ( вертикальная или горизонтальная черта)

Вершина «решение» позволяет отобразить разветвление вычислительного процесса.

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

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

Разгрузка и приемка

Если товар паллетизированный:

a) Паллета/Паллеты выгружается в зону разгрузки (операция платная руб/паллета).

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

c) В случае обнаружения брака паллета распаллечивается и заново паллетизируется. Соответствующие отметки делаются в документах по приемке товара (операция платная руб/паллета (паллетизация + упаковка)). В программе ставится галочка, что было перепаллечивание. При перепаллечивании возможно предоставление наших поддонов - в программе ставится галочка, что используется наш поддон (паллета).

Если товар в коробках

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

b) Коробки укладываются на паллету, паллета выкатывается в зону разгрузки

c) Паллета упаковывается (данная операция платная руб/паллета (паллетизация + упаковка)). По умолчанию считается, что в случае коробок клиент использует наши паллеты (стоит галочка использование нашего поддона (паллета)). Предоставление паллеты -платная услуга руб/паллета.

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

Если в необходимо контрольное взвешивание при приемке товара, тогда пользователь считывает вес паллеты с электронных весов. Данный вес привязывается к паллете. В случае перепаллечивания пользователь должен будет указать новый вес паллеты. Данный вес НЕ используется для биллинга. В биллинге используется либо вес коробки (если единица прихода = коробка), либо вес товара (если единица прихода = кг).

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

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

Если пользователю необходимо отменить активное задание на транспортировку, тогда он в активном задании нажимает кнопку «Отменить активное задание».

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

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

Ш Был ли адрес зарезервирован. Если ДА, тогда если адрес был зарезервирован под другую заявку на приемку/хранение система не дает разместить товар. Если НЕТ, тогда система разрешает разместить товар, предварительно переместив с данного адреса резерв на адрес, который был рекомендован погрузчику.

Ш Если адрес свободен, тогда система считает адрес корректным

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

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

Ш Был ли адрес зарезервирован. Если ДА, тогда если адрес был зарезервирован под другую заявку на приемку/хранение система не дает разместить товар. Если НЕТ, тогда система разрешает разместить товар, предварительно переместив с данного адреса резерв на адрес, который был рекомендован штабелеру.

Ш Если адрес свободен, тогда система считает адрес корректным

Подборка товара в зонах хранения. После оформления задания на отгрузку система автоматически создает задания на подборки для каждой зоны хранения, где лежит указанный товар в задании на отгрузку. Задание на подборку содержит адреса и паллеты, которые нужно подобрать и адрес куда их нужно поставить - пакет. Штабелер на Pocket PC получает задание на подборку. Адреса куда нужно ставить определяются либо как привязанный к адресу хранения, либо как привязанный к номеру шлюза.

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

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

Штабелер отвозит паллету на указанный адрес (коридор), сканирует штрих код - считается, что подборка завершена.

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

Когда погрузчик подъезжает к указанной зоне он ее сканирует - считается, что транспортировка завершена.

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

Отгрузка товара клиенту и погрузка. При отгрузке по заданию на отгрузку пользователь сканирует штрих код паллеты, если данная паллета должна быть отгружена, тогда система выдает запрос: отгрузить, иначе выдает сообщение об ошибке. Повторное сканирование паллеты подтверждает ее отгрузку. Сканирование другого штрих кода или нажатие кнопки «Отмена» отменяет отгрузку паллеты. Пользователь до отгрузки может уменьшить/увеличить отгружаемое количество на паллете. Если требуется отгрузить только часть товара на паллете, тогда в систему вводится нужное количество к отгрузке, остальное остается на паллете, далее данная паллета транспортируется обратно в место хранения.

4. Бизнес - объектная модель

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

Бизнес-работник - абстракция человека, действующего в бизнесе. Бизнес - сущности являются «предметами», обрабатываемыми или используемыми бизнес - работниками по мере выполнения бизнес - элемента Use Case. Фактически бизнес - объектная модель отображается с помощью диаграмм классов.

Бизнес - объектная модель отражает внутреннее представление бизнес-процессов организации (с точки зрения ее сотрудников).

Опишем более подробно бизнес - объектную модель, отражающую внутреннюю структуру организации предоставляющей услуги

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

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

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

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

· Предметная область.

· Логическая модель данных.

· Физическая модель данных.

В ER-схемах вводится понятие нормальных форм. Аппарат нормализации отношений был разработан Е.Ф. Коддом. Кодд выделил три нормальные формы. Самая совершенная из них третья.

В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов.

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

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.

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

На логический уровне данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Номенклатура», «Заявка». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. В логической модели не имеет значения, какой конкретно тип данных имеет атрибуты.

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

· диаграмма сущность-связь (Entity Relationship Diagram, ERD);

· модель данных, основанная на ключах (Key Based model, KB);

· полная атрибутивная модель (Fully Attributid model, FA).

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

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

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

Основные компоненты ERwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.

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

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

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

На основе исследованной предметной области была создана логическая модель данных, при этом, для более удобного предоставления, был использован механизм Case-средства ERwin подмножества модели (Subject Areas). В которые можно включить тематически общие сущности. В подмножество модели может входить произвольный набор сущностей, связей и текстовых комментариев.

5. Разработка пользовательского интерфейса

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

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

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

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

В подразделе «журналы» можно посмотреть журналы вызовов за любой период времени работы: все вызовы, незавершенные вызовы, отложенные вызовы, неприбывшие на вызов.

В подразделе «отчеты» находятся отчеты, формируемые за отчетный период.

Подраздел «сервис» предоставляет резервную копию БД.

Подраздел «помощь» содержит справочную информацию по работе с программой.

6. Выбор средств программной реализации

В качестве среды реализации была выбрана среда 1С:Предприятие. Исторически со словом «1С» ассоциируется много различных решений, но, в первую очередь, это программа «1С:Бухгалтерия» для автоматизации бухгалтерского учета. Уже более 10 лет развивается это направление фирмы «1С». Компьютерные программы для бухгалтерского учета востребованы в предприятиях различных размеров, форм собственности, отраслевой направленности и фактически стали российским стандартом автоматизации бухгалтерского учета. Это исторически привело к более широкому пониманию фирмой «1С» реальных потребностей предприятий в автоматизации различных участков учета и управления.

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

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

7. Технологические средства конфигурирования и администрирования системы 1С: Предприятие 8.0

Функционирование системы делится на два процесса:

- конфигурирование (описание модели предметной области средствами, предоставляемыми системой)

- исполнение (обработка данных предметной области).

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

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

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

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

Данные в базе находятся в кодировке «UNICODE».

Объекты системы

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

В программном комплексе «1С:Предприятие 8.0» можно выделить две группы объектов:

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

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

Можно сказать, что в общем случае добавление одного объекта конфигурации приводит к тому, что во встроенном языке появляется «поддержка» нескольких «программных» объектов. Например, добавление справочника «Товары» приводит к тому, что можно в языке можно оперировать значениями следующих типов: «Справочник Ссылка. Товары», «Справочник Объект. Товары» и т.д.

Классификация объектов конфигурации

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

Кроме этого все объекты конфигурации можно подразделить на три основные группы:

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

Прикладные объекты. Их перечень можно увидеть на первом уровне дерева метаданных (исключая группу «Общие»).

Подчиненные объекты. К таким объектам относятся «Реквизиты», «Табличные части» и т.д.

Прикладные объекты

К объектам данной группы относятся объекты следующих видов:

Константы. Предназначены для хранения постоянных, условно-постоянных величин.

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

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

Документы. Служат для ввода информации о совершаемых операциях в системе.

Журналы документов. Служат для отображения списков документов различного вида.

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

Планы видов расчета. Предназначены для описания множеств однотипных объектов механизмов расчета.

Отчеты. Средство получения выходной информации.

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

Планы счетов. Совокупность синтетических счетов.

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

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

Регистры расчетов. Служат для накопления информации о периодических расчетах.

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

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

Табличные части - наборы дополнительной информации об объекте, представленные в виде таблиц.

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

Формы -- используются для ввода, просмотра и редактирования информации.

Макеты - табличные документы, предназначенные для формирования печатных форм объекта.

Графы - графы журнала документов.

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

Ресурсы - данные, учитываемые в регистре.

Типы данных

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

Различают три основных группы типов данных:

Примитивные типы (в их состав входят базовые типы данных)

Типы данных, появившиеся после определения в конфигурации объектов конфигурации.

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

К примитивным типам данных относятся:

Число (десятичное число)

Строка (строка фиксированной, переменной или неограниченной длины)

ь Дата (дата, время, дата+время)

ь Булево (истина или ложь)

ь Тип

ь Неопределенно

ь Null

Отдельно хочется сказать про такой тип как «Хранилище Значения». Если определить реквизиту такой тип данных, то в нем можно хранить «все что угодно» (включая двоичные данные, картинки, файлы).

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

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

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

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

Таблица значения - объект позволяющий строить динамические наборы значений и манипулировать ими. Он может быть наполнен значениями различных типов. Может иметь любое количество колонок и быть связанным с элементом «табличное поле».

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

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

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

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

Рисунок 1

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

Платформа «1С:Предприятие 8.0» сочетает в себе визуальные и языковые средства конфигурирования. Использование встроенного языка в системе имеет событийно-зависимую ориентацию, то есть языковые модули используются в конкретных местах для отработки отдельных алгоритмов, настраиваемых в процессе конфигурации. Программный код всегда помещается в «модули».

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

Существуют модули различных видов:

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

...