Файл: Разработка конфигурации «Складской учет» в среде 1С:Предприятие 8.3 (Реализация ИС на платформе «1С: Предприятие»).pdf
Добавлен: 25.04.2023
Просмотров: 3159
Скачиваний: 167
СОДЕРЖАНИЕ
§1.1 Анализ предметной области
§1.2 Функциональные требования к разработке проекта системы складского учета
§1.3 Разработка моделей бизнес-процессов системы складского учета
§1.4 Разработка модели базы данных системы складского учета
§2.1 Реализация ИС на платформе «1С: Предприятие»
§2.2 Создание справочников информационной системы
§2.3 Создание документов информационной системы
§2.4 Создание регистров накопления и отчетов информационной системы
§2.5 Создание пользователей, ролей и настройка рабочих столов пользователей информационной системы
Рисунок 1.4 Диаграмма декомпозиции блока «Система складского учета»
После описания контекстной диаграммы проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема, при необходимости, разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции.
Весь процесс деятельности склада можно подразделить на этапы:
- Подсистема приема товара (принятие товара по сопроводительным документам и передача его на хранение).
На данном этапе товар с сопроводительными документами поступает на склад и подвергается подсчету (сверка фактического наличия с документами). Но, каким бы ни был результат подсчета товара (положительным либо отрицательным), он после этого вместе с сопроводительными документами передается на хранение.
- Подсистема приема возврата (прием товара от покупателей).
Товар может поступать на склад не только от поставщиков, но и от покупателей, желающих вернуть товар по каким-то причинам.
- Подсистема отгрузки товара (выдача скомплектованного товара клиенту, либо возврат поставщику).
Данный этап подразумевает отгрузку клиенту товара, скомплектованного по отгрузочным документам либо отгрузка товаров поставщикам (если произошла ошибка при получении товаров).
- Хранение (основная и самая сложная функция склада, подразумевает все остальные действия с товаром, не описанные выше, например, комплектование, оформление документации на товар, списание).
Этап «Хранение» возьмем для последующей декомпозиции (рисунок 1.5).
Рисунок 1.5 Диаграмма декомпозиции блока «Подсистема хранения»
Процесс хранения, в свою очередь подразделяется на простые функции (или действия), осуществляемые работниками склада:
- Формирование отгрузочных документов (согласно оплаченному счету клиента).
На данном этапе формируются отгрузочные документы (расходные накладные), а также документы, согласно которым будет производиться комплектация товара для дальнейшей отгрузки клиенту, либо возврата поставщику.
- Складирование (непосредственное размещение товара на складе)
В зависимости от характера товара товар размещается на соответствующем складе. Предприятие может использовать основной склад и, например, дополнительный.
- Комплектование (комплектация товара согласно отгрузочным документам для дальнейшей выдачи клиенту, либо возврата поставщику)
На данном этапе, при комплектации товара производится внешний осмотр товара и выявляется брак, который, при его обнаружении, передается на списание.
- Списание товара (списание и дальнейшая передача на утилизацию брака или испорченного товара с формированием документов о списании).
Этап «складирование» является наиболее интересным для дальнейшего рассмотрения (рисунок 1.6).
Рисунок 1.6 Диаграмма декомпозиции блока «Складирование»
Диаграмма складирования, в свою очередь подразделяется на пункты:
- Хранение на временной площадке (товар, прибывший от поставщика или возвращаемый клиентом).
На данном этапе производится сверка поступившего товара с принятыми на него документами (приходные документы по поставке или документы на осуществление возврата товара от клиента). После сверки делается вывод о соответствии документов и фактическом наличии товара. В случае выявления нарушений отправляется запрос в офис с целью уточнения данных, и товар продолжает оставаться на временном хранении.
- Складирование на основной склад (товары, прошедшие качественно – количественную проверку).
На данном этапе производится непосредственное складирование поступившего товара на хранение. В будущем необходимый товар проходит комплектацию и передается на выдачу (отгрузку).
- Формирование документов по принятому товару (выходные документы).
На данном этапе производится документальное подтверждение по факту прихода товара на склад, внесение изменений в базу наличия товаров.
Следующая диаграмма, которую следует рассмотреть – диаграмма дерева узлов (рисунок 1.7). Диаграмма показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами.
- Диаграмма «Система складского учета» – первый уровень дерева узлов (top level activity);
- Диаграммы «Подсистема приема товара», «Подсистема приема возврата», «Подсистема отгрузки товара» и «Подсистема хранения» – второй уровень дерева узлов;
- Диаграммы «Формирование отгрузочных документов», «Складирование», «Комплектование» и «Списание товара» – третий уровень дерева узлов;
- Диаграммы «Хранение на временной площадке», «Складирование на основной склад», «формирование документов по принятому товару» - четвертый уровень дерева узлов.
Данного уровня декомпозиции достаточно для выполнения данной курсовой работы.
Рисунок 1.7 Диаграмма дерева узлов
Так же, для более наглядного восприятия роли работников склада в деятельности организации, а так же определения места склада в CA Process Modeler была создана организационная диаграмма (рисунок 1.8). Для этого были созданы:
- Словарь групп ролей;
- Словарь ролей;
- Словарь ресурсов.
Организационная диаграмма представляет собой традиционную древовидную структуру, во главе которой находится единственный блок, который разделяется вниз на блоки подсистем. Каждый блок является графическим представлением конкретной роли. На организационной диаграмме можно так же увидеть иерархию подчинения на нашем складе (Заведующий складом, Кладовщик, Грузчик).
Рисунок 1.8 Организационная диаграмма
§1.4 Разработка модели базы данных системы складского учета
ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако, ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).
В ERwin существуют два уровня представления и моделирования - логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.
Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin. ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне.
Объекты модели на данном уровне называются сущностями и атрибутами. Диаграмма сущность – связь (рисунок 1.9) содержит сущности и взаимосвязи, которые отражают основные закономерности предметной области.
Данные о сущностях разработанной модели данных представлены в таблице А.1 (Приложение А). Данные о выявленных связях между сущностями представлены в таблице А.2 (Приложение А). Связи «многие ко многим» в таблице А.3 (Приложение А).
Рисунок 1.9 ER – диаграмма модели базы данных
Модель данных, основанная на ключах (KB – модель), кроме сущностей и связей, включает в себя ключевые атрибуты сущностей: первичные (PK) и внешние (FK). Для определения первичных и внешних ключей были выявлены следующие закономерности:
- Каждый сотрудник обладает своим уникальным кодом.
- Каждый сотрудник может быть закреплен на выдачу товара по нескольким накладным.
- Каждая накладная обладает своим уникальным кодом.
- Каждая накладная может содержать несколько строк, указывающих на товары по накладной.
- Каждая накладная содержит информацию о клиенте, на которого производится выдача товара.
- Каждый клиент вносится в базу под своим уникальным кодом.
- Каждый клиент может оформлять несколько накладных.
- Каждый склад обладает уникальным кодом.
- Один склад может быть прописан в нескольких накладных.
- Каждая строка входит в состав определенной накладной.
- Каждая строка содержит информацию о товаре по коду товара.
- Каждый товар обладает своим уникальным кодом.
- Каждый поставщик обладает своим уникальным кодом.
- Каждый поставщик может поставлять множество товаров.
В результате формируем KB-модель (рисунок 1.10).
Рисунок 1.10 KB – диаграмма модели базы данных
Полная атрибутивная модель предполагает наиболее детальное представление структуры проектируемой базы данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Каждая из наших сущностей будет обладать своими атрибутами. Соответствие атрибутов и сущностей проведено в таблице А.4 (Приложение А). В таблице А.5 (Приложение А) отображены функциональные зависимости.
В результате формируется FA – модель, представлена на рисунке 1.2.8.
Рисунок 1.11 FA – модель базы данных информационной системы склада
Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Для построения трансформационной модели необходимо определить домены атрибутов сущностей, области их допустимых значений, а также типы данных (таблица А.6 (Приложение А)).
В результате сформирована трансформационная модель (рисунок 1.12), ориентированная на формат выбранной СУБД и включает все сущности, атрибуты, их типы данных, а так же ограничения.
Рисунок 1.12 T – модель базы данных информационной системы склада
Далее была разработана DBMS-модель в виде SQL-кода, представленного в приложении Б. Его интерпретация позволила получить схему базы данных в формате СУБД MS SQL Server на физическом уровне.
§2.1 Реализация ИС на платформе «1С: Предприятие»
На сегодняшнем рынке программного обеспечения существует множество информационных систем, различных по своим характеристикам, масштабам автоматизации производства, соотношениям цены и качества. Но ко всем из них, как правило, применяются стандартные требования, как простота внедрения и использования, возможность быстрого обучения работе с продуктом, адекватность цены, соответствие электронного документооборота требованиям законов.
Продукт «1С: Предприятие» представляет собой платформу, используя которую можно сконфигурировать необходимое решение для автоматизации деятельности определенных отделов или предприятия в целом. 1С так же предлагает различные готовые решения. Хранение данных для ИС так же возможно в различных СУБД: Microsoft SQL Server, IBM DB2, Oracle и т.д.
Русскоязычный интерфейс, возможность программной доработки процессов автоматизации, а так же расширения масштабов автоматизации одним продуктом являются решающими факторами при выборе информационного продукта.
Для разработки ИС на платформе 1С: Предприятие предусмотрены различные инструменты, которые позволяют проектировщику создавать необходимые объекты информационной базы.
Основной инструмент, с которым работает разработчик в «1С: Предприятие» - дерево конфигурации. Дерево конфигурации содержит в себе практически всю информацию о том, из чего состоит конфигурация (рисунок 2.1).