Файл: Проектирование реализации операций бизнес-процесса (Аналитическая часть).pdf

Развитая система помощи позволяет изучить язык в достаточно короткие сроки. Кроме этого язык 1С имеет инструменты определения синтаксических ошибок и логики работы программы. При возникновении ошибки система оповещает о месте и характере ошибки [7].

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

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

После этого можно получать данные [12].

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

2 глава. Проектная часть

2.1. Информационная модель и её описание

Выполним построение информационной модели (рис.8).

Выделим логические уровни модели [3]:

1. источники информации – справочник «Номенклатура», справочник «Места хранения»;
2. первичные документы или файлы – документ «Приходная накладная», «Расходная накладная», «Накладная на перемещение», «Продажа товара (счет)»;
3. таблицы с первичными документами – реестр документов;
4. таблицы с результатной информацией – справочники «Контрагенты», «Сотрудники»;
5. результатные документы или файлы – отчеты по количеству товара на складе, обороту товара, взаиморасчетам, проданному количеству товара по заданной цене, сумме проданного товара;
6. получатели информации – менеджер предприятия, продавец.

На рисунке 8 представлена информационная модель проектируемой системы.

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

• справочник «Контрагенты»;
• справочник «Места хранения»;
• справочник «Сотрудники»;
• справочник «Номенклатура»;
• документ «Расходная накладная»;
• документ «Приходная накладная»;
• документ «Накладная на перемещение»;
• документ «Продажа товара».

Затем отображаются действия пользователя:

• заполнение справочников;
• выполнение движения по операциям;
• формирование отчетности.

Следующим шагом определяются выходные документы:

• остатки товаров;
• оборот товаров;
• взаиморасчеты;
• количество проданного товара;
• сумма проданного товара.

Рисунок 8 – Информационная модель проектируемой системы

2.2. Характеристика нормативно-справочной, входной и оперативной информации

Для разработанной в дальнейшем системы «Взаиморасчеты контрагентов» нормативно-справочной, входной информацией будут [8]:

• справочник «Контрагенты»;
• справочник «Места хранения»;
• справочник «Сотрудники»;
• справочник «Номенклатура»;
• документ «Расходная накладная»;
• документ «Приходная накладная»;
• документ «Накладная на перемещение;
• документ «Счет».

Представим макеты входных документов и справочников на рисунках 9-15.

Рисунок 9 – Макет справочника «Контрагенты»

Рисунок 10 – Макет справочника «Номенклатура»

Рисунок 11 – Макет справочника «Места хранения»

Рисунок 12 – Макет справочника «Сотрудники»

Рисунок 13 – Макет документа «Расходная накладная»

Рисунок 14- Макет документа «Приходная накладная»

Рисунок 15 – Макет документа «Накладная перемещения»

Выполним построение макетов форм элементов результатной информации.

2.3. Характеристика результатной информации

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

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

• отчет «Остатки товаров»;
• отчет «Обороты товаров»;
• отчет «Взаиморасчеты»;
• отчет «Количество проданного товара»;
• отчет «Сумма проданного товара».

На рисунке 16 – 20 представлены макеты отчетов системы.

Рисунок 16 – Макет отчета «Остатки товаров»

Рисунок 17 – Макет отчета «Обороты товаров»

Рисунок 18 – Макет отчета «Взаиморасчеты»

Рисунок 19 – Макет отчета «Количество проданного товара»

Рисунок 20 – Макет отчета «Сумма проданного товара»

Разработанные формы позволяют определить состав объектов, которые будут затем программно реализованы.

2.4. Общие положения (дерево функций и сценарий диалога)

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

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

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

На рисунке 21 представлены функции системы.

Рисунок 21 – Функции системы

На рисунке представлены следующие функции [13]:

1. Служебные функции:

• обработка запросов к БД;
• хранение данных в БД;
• построение диалоговых форм;
• разделение прав доступа.

2. Ключевые:

• обработки данных контрагента;
• обработка данных по номенклатуре
• формирование прихода;
• формирование расхода;
• формирование перемещения;
• формирование счета;
• формирование статистических отчетов.

Выполним построение сценариев диалога при работе с системой анализа спроса на товары. На рисунке 22 представлен сценарий диалога при формировании заказа поставщику. Сценарий следующий [9]:

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

Рисунок 22 – Сценарий диалога при формировании заказа поставщику

На рисунке 23 представлен сценарий при доставке поставщиком товара на торговое предприятие.

Рисунок 23 – Сценарий диалога при приеме товара от поставщика

Сценарий имеет следующую последовательность [9]:

1. Доставка товара поставщиком.

2. Формирование поставщиком документа «Акт сверки»

3. Согласование и начало приема товара.

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

4. Если все согласовано, то формируется приходная накладная, в ней указывается:

• поставщик, выбирается из справочника «Поставщики»;
• кто принял товар, выбирается из справочника «Сотрудники»;
• место хранения, выбирается из справочника с соответствующим названием – «Места хранения»;
• указывается дата документа;
• выбирается товар из справочника «Номенклатура»;
• отображается цена закупки – данные подтягиваются из справочника «Номенклатура»;
• указывается количество товара;
• происходит расчет суммы товара и итоговая стоимость документа;
• документ сохраняется.

2.5. Характеристика базы данных

CA ERwin Data Modeler (CA ERwin DM), инструмент проектирования базы данных что повышает уровень качества данных в транзакционных и хранилищах данных.

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

В данном пакете можно создавать и поддерживать графические модели, представляющие базы данных. CA ERwin DM обеспечивает платформу, где требования к корпоративным данным и соответствующие проекты баз данных могут быть определенными, управляемыми и реализованными во множестве баз данных [15].

Графический пользовательский интерфейс на базе Windows сочетается с мощным инструменты привязки объектов (ER), с пользовательскими редакторами для определения физических объектов базы данных, с моделью Explorer для текстового представления объектов модели и с поддержкой ведущих баз данных SQL.

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

Логическая схема БД представлена на рисунке 24.

Рисунок 24 – Логическая схема БД системы

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

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

Выделим следующие группы модулей:

• модули управления;
• функциональные модули;
• модули сервиса.

Описание модулей представлено в таблице 2.

Таблица 2 – Описание модулей системы