Автоматизация системы учета заказов на предприятии

Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто.

Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Как нетрудно заметить, все сконструированные нами ранее исходные таблицы БД учета заказов на ООО «Кортереал» заведомо находятся в первой нормальной форме.

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

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

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

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

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.

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

Рассмотрим таблицу Поставщики. Очевидно, что, поскольку все содержащиеся записи относятся к конкретному поставщику, которому присвоен уникальный КодПоставщика, то эта таблица находится во 2НФ, а так как каждое поле однозначно определяется этим уникальным кодом, то таблица находится и в НФБК. Аналогичные замечания полностью применимы к таблицам Клиенты и Сотрудники, которые, следовательно, также находятся в НФБК.

Рассмотрим далее таблицу Товары. Она находится в 1НФ. Первичным ключом таблицы является поле КодТовара. Зная значение ключевого поля, мы однозначно находим значения всех других полей таблицы. Это означает, что таблица в 2НФ. Заметим также, что все поля таблицы функционально зависят от поля КодТовара (ключевого), все поля функционально зависят от полей Наименование и КодПоставщика, но, поскольку по коду товара эти поля определяются однозначно, до данные зависимости сводятся к полной функциональной зависимости от первичного ключа. Следовательно, таблица также находится в НФБК.

Наиболее сложными для анализа являются таблицы Заказы и Заказано. Отметим сразу же, что поле Цена в таблице Заказано (отражающее отпускную цену товара покупателю) не совпадает с полем Цена в таблице Товары, где указывается закупочная цена товара.

Ключевым полем в таблице Заказы является поле КодЗаказа, оно действительно однозначно определяет все другие поля таблицы. Следовательно, таблица находится в 2НФ. Но, совершенно очевидно, что все другие поля (кроме КодКлиента и КодСотрудника) содержат только сведения о получателе заказа и дате его оформления и функционально зависят от ключевого поля. Поля же КодКлиента и КодСотрудника находятся в прямой функциональной зависимости от ключевого поля в силу самой конструкции рассматриваемой таблицы. Следовательно, она находится в НФБК. Что касается таблицы Заказано, то её ключевое поле является составным (КодЗаказа - КодТовара). Поскольку исключены повторения товаров водном и том же заказе, а цена каждого наименования товара оговаривается в каждом отдельном случае и однозначно определена этими двумя полями, то и эта таблица находится в НФБК.

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

2.3 Разработка форм для обработки информации в базе данных

автоматизация учет заказ информационный

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

Рисунок2.2. - Схема данных базы учета заказов ООО «Кортереал».

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

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

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

Таблица Клиенты формируется менеджерами по работе с клиентами. Все они должны иметь неограниченный доступ к данным этой таблицы.

Таблица Заказы также формируется менеджерами по работе с клиентами.

Наконец, таблица Заказано формируется также менеджерами по работе с клиентами, но полный доступ к данным должны иметь сотрудники склада.

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

Рисунок 2.3. - Главная кнопочная форма базы данных ООО «Кортереал»

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

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

Рисунок 2.4. - Форма Сотрудники базы данных ООО «Кортереал»

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

Рисунок 2.5. - Форма Товары базы данных ООО «Кортереал»

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

Рисунок 2.6. - Форма Клиенты базы данных ООО «Кортереал»

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

SELECT DISTINCT Клиенты.Страна

FROM Клиенты;

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

Возможность ввода для данного поставщика нового товара (эту работу будет выполнять менеджер склада на основании предоставляемой администрацией ООО информации - договоров и прайс-листов контрагентов). Информация о новом товаре должна заноситься в таблицу Товары для выбранного поставщика.

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

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

Рисунок 2.7. - Форма Поставщики базы данных ООО «Кортереал»

Теперь для правильной работы кнопки Ввод товаров необходимо корректно написать процедуру обработки событий нажатия этой кнопки на языке Visual Basic в отладчике VB для базы данных ООО «Кортереал». Соответствующий листинг с комментариями имеет вид:

Private Sub ВводТоваров_Click()

On Error GoTo Err_ВводТоваров_Click

Dim strDocName As String

strDocName = "Товары"

' Открытие формы "Товары" в режиме ввода данных.

' Сохранение значения поля КодПоставщика в аргументе OpenArgs формы.

DoCmd.OpenForm strDocName, , , , acAdd, , Me!КодПоставщика

' Закрытие формы "Список товаров".

DoCmd.Close acForm, "Список товаров" ' Передача фокуса элементу "Название".

Forms![Товары]!Название.SetFocus

Exit_ВводТоваров_Click:

Exit Sub

Err_ВводТоваров_Click:

MsgBox Err.Description

Resume Exit_ВводТоваров_Click

End Sub

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

Рисунок 2.8. - Форма Список товаров в режиме конструктора.

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

Private Sub ПросмотрТоваров_Click()

On Error GoTo Err_ПросмотрТоваров_Click

Dim strMsg As String, strTitle As String

Dim intStyle As Integer

Dim strDocName As String, strLinkCriteria As String

' Если элемент "Название" пуст, выдается сообщение.

If IsNull(Me![Название]) Then strMsg = "Перейдите на запись поставщика, чьи товары нужно просмотреть, и вновь нажмите кнопку ""Просмотр товаров""."

intStyle = vbOKOnly

strTitle = "Выберите поставщика"

MsgBox strMsg, intStyle, strTitle

Me![Название].SetFocus

Else

'Иначе форма "Список товаров" открывается для товаров текущего поставщика.

strDocName = "Список товаров"

strLinkCriteria = "[КодПоставщика] = Forms![Поставщики]![КодПоставщика]"

DoCmd.OpenForm strDocName, , , strLinkCriteria

DoCmd.MoveSize (1440 * 0.78), (1440 * 1.8)

End If

Exit_ПросмотрТоваров_Click:

Exit Sub

Err_ПросмотрТоваров_Click:

MsgBox Err.Description

Resume Exit_ПросмотрТоваров_Click

End Sub

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

Рисунок 2.9. - Результат просмотра товаров - пример

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

2.4 Разработка механизма оформления заказов в базе дынных

Наиболее ответственной работой является оформление заказов, поэтому соответствующая форма Заказы должна быть максимально удобной для пользователей. Основными требованиями при её разработке являются:

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

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

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

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

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

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

Для обслуживания кнопки Печать счета зарезервируем название для отчета - отчет Счет. В режиме Конструктора данная составная форма будет иметь следующий вид:

Рисунок 2.10. - Вид формы Заказы в режиме Конструктора

В режиме формы пользователь увидит следующую картинку:

Рисунок2.11. - Форма Заказы базы данных ООО «Кортереал»

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

1. Список заказов клиента с указанием даты размещения заказа

2. Для выбранного заказа в табличной форме открывается список всех позиций данного заказа.

Основными пользователями данной формы должны стать администрация ООО «Кортереал» и старшие менеджеры, использующие ей для контроля поступления заказов от клиентов и их выполнения. Данная форма (назовем её Заказы клиентов) также должна быть составной, включающей в себя две подчиненный формы: Подчиненная форма заказов 1 и Подчиненная форма заказов 2. Внешний вид формы:

Рисунок 2.12. - Форма Заказы клиентов базы данных ООО «Кортереал»

2.5 Разработка средств анализа в базе данных ООО «Кортереал»

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

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

Программа должна формировать список всех имеющихся на складе товаров - запрос Список имеющихся товаров.

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

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

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

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

Возможность формирования списка всех товаров с ценой, выше средней - запрос Товары с ценой выше средней.

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

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

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

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

Начнем построение требуемых запросов.

Запрос Список товаров в режиме конструктора будет иметь вид:

Рисунок 2.13. - Запрос Список товаров в режиме конструктора

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

Рисунок 2.14. - Запрос Список имеющихся товаров в режиме конструктора

Запрос по формированию полных сведений о размещенных заказах имеет вид:

Рисунок 2.15. - Запрос Запрос Заказы в режиме конструктора

Запрос Сведения о заказах представлен на рис. 2.16. Для вычисления графы Отпускная цена в запросе используется арифметическая конструкция виде

ОтпускнаяЦена: CCur(Заказано.Цена*[Количество]*(1-[Скидка])/100)*100

Здесь использована функция CCur, результатом применения которой является представление результата вычислений в денежной форме.

Рисунок 2.16. - Запрос Сведения о заказах в режиме конструктора

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

Рисунок 2.17. - Внешний вид формы Продажи по годам

Даня форма содержит два поля - Начальная Дата и Конечная Дата. При передаче управления кнопкой Выполнить запрос введенные в эти поля даты (для ввода дат установлены естественные ограничения - рассматривается период с 2005 по 2009 годы) передаются запросу Продажи по годам, конструкция которого имеет вид:

PARAMETERS [Forms]![Продажи по годам]![НачальнаяДата] DateTime, [Forms]![Продажи по годам]![КонечнаяДата] DateTime;

SELECT Заказы.ДатаРазмещения, Заказы.КодЗаказа, [Промежуточная сумма заказа].ПромежуточнаяСумма, Format([ДатаРазмещения],"yyyy") AS Год

FROM Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа=[Промежуточная сумма заказа].КодЗаказа

WHERE (((Заказы.ДатаРазмещения) Is Not Null And (Заказы.ДатаРазмещения) Between Forms![Продажи по годам]!НачальнаяДата And Forms![Продажи по годам]!КонечнаяДата));

В результате выполнения такого запроса будут выданы все оформленные заказы, дата регистрации которых находится между значениями Forms![Продажи по годам]!НачальнаяДата и Forms![Продажи по годам]!КонечнаяДата.

Для того, чтобы получить анализ продаж за предыдущий 2011 год, сформируем запрос Продажи товаров в 2011 вида:

SELECT Товары.Название, Sum(CCur(Заказано.Цена*[Количество]*(1-[Скидка])/100)*100) AS ПродажиТоваров, "Кв " & DatePart("q",[ДатаРазмещения]) AS КварталРазмещения

FROM Товары INNER JOIN (Заказы INNER JOIN Заказано ON Заказы.КодЗаказа = Заказано.КодЗаказа) ON Товары.КодТовара = Заказано.КодТовара

WHERE (((Заказы.ДатаРазмещения) Between #1/1/2011# And #12/31/2011#))

GROUP BY Товары.Название, "Кв " & DatePart("q",[ДатаРазмещения]);

Запрос Товары с ценой выше средней можно сформировать следующими инструкциями:

SELECT Товары.Название, Товары.Цена

FROM Товары

WHERE (((Товары.Цена)>(SELECT AVG([Цена]) From Товары)))

ORDER BY Товары.Цена DESC;

Здесь встроенная функция AVG формирует среднюю цену товаров на основании анализа всей графы Цена таблицы Товары.

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

PARAMETERS [Начальная дата] DateTime, [Конечная дата] DateTime;

SELECT Сотрудники.Страна, Сотрудники.ФИО, Заказы.ДатаРазмещения AS Выражение1, Заказы.КодЗаказа, [Промежуточная сумма заказа].ПромежуточнаяСумма AS СуммаПродаж

FROM Сотрудники INNER JOIN (Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа) ON Сотрудники.КодСотрудника = Заказы.КодСотрудника

WHERE (((Заказы.ДатаРазмещения) Between [Начальная дата] And [Конечная дата]));

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

Рисунок 2.18. - Запрос Счета в режиме конструктора

Более наглядное представление об этом запросе дает его SQL-код:

SELECT Заказы.НазваниеПолучателя, Заказы.АдресПолучателя, Заказы.ГородПолучателя, Заказы.ОбластьПолучателя, Заказы.ИндексПолучателя, Заказы.СтранаПолучателя, Заказы.КодКлиента, Клиенты.Название, Клиенты.Адрес, Клиенты.Город, Клиенты.Область, Клиенты.Индекс, Клиенты.Страна, Сотрудники.ФИО AS Продавец, Заказы.КодЗаказа, Заказы.ДатаРазмещения, Заказано.КодТовара, Товары.Название, Заказано.Цена, Заказано.Количество, Заказано.Скидка, CCur([Заказано].[Цена]*[Количество]*(1-[Скидка])/100)*100 AS ОтпускнаяЦена

FROM Товары INNER JOIN (Сотрудники INNER JOIN (Клиенты INNER JOIN (Заказы INNER JOIN Заказано ON Заказы.КодЗаказа = Заказано.КодЗаказа) ON Клиенты.КодКлиента = Заказы.КодКлиента) ON Сотрудники.КодСотрудника = Заказы.КодСотрудника) ON Товары.КодТовара = Заказано.КодТовара;

Наконец, построим запрос Клиенты и поставщики по городам, написав код запроса на объединение

SELECT Город, Название, "Клиенты" AS [Отношения]

FROM Клиенты

UNION SELECT Город, Название, "Поставщики"

FROM Поставщики

ORDER BY Город, Название;

Последний необходимый запрос Квартальные обороты по товарам. Это должен быть сложный перекрестный запрос. Его SQL-код:

TRANSFORM Sum(CCur(Заказано.Цена*[Количество]*(1-[Скидка])/100)*100) AS СуммаПоТовару

SELECT Товары.Название, Заказы.КодКлиента, Year([ДатаРазмещения]) AS ГодЗаказа

FROM Товары INNER JOIN (Заказы INNER JOIN Заказано ON Заказы.КодЗаказа = Заказано.КодЗаказа) ON Товары.КодТовара = Заказано.КодТовара

WHERE (((Заказы.ДатаРазмещения) Between #1/1/2005# And #12/31/2009#))

GROUP BY Товары.Название, Заказы.КодКлиента, Year([ДатаРазмещения])

PIVOT "Кв " & DatePart("q",[ДатаРазмещения],1,0) In ("Кв 1","Кв 2","Кв 3","Кв 4");

В режиме конструктора запрос будет иметь вид:

Рисунок 2.19. - Перекрестный запрос Квартальные обороты по товарам

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

SELECT DISTINCT Клиенты.КодКлиента, Клиенты.Название, Клиенты.Город, Клиенты.Страна

FROM Клиенты RIGHT JOIN Заказы ON Клиенты.КодКлиента = Заказы.КодКлиента

WHERE (((Заказы.ДатаРазмещения) Between #1/1/2005# And #12/31/2009#));

2.6 Разработка системы отчетов базы данных

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

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

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

Отчет Список товаров просто формирует в удобной форме список всех товаров, предлагаемых ООО «Кортереал». Фактически отчет формирует прайс-лист фирмы.

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

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

Отчет Продажи по сотрудникам строится на основе одноименного запроса.

Начнем конструировать отчеты. Отчет Итоги продаж по объему имеет наиболее простую структуру.

Отчет Список товаров также устроен довольно просто:

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

При запуске отчета происходит запрос к пользователю с просьбой ввести начальную и конечную даты анализа. Целесообразно ограничить эти показатели разумными пределами. Далее, данные в отчет Для того, чтобы непосредственно в отчете можно было оценить работу того или иного сотрудника, предусмотрена автоматическое выставление оценки - оптимальный результат в случае, если объем продаж сотрудника превышает 50000 руб. Для этого воспользуемся конструкцией на Visual Basic со следующим листингом:

Option Compare Database ' Сортировка базы данных для сравнения строк.

Option Explicit ' Обязательное описание переменных перед их применением.

Private Sub ЗаголовокГруппы0_Format(Cancel As Integer, FormatCount As Integer)

' Задание номера страницы 1 в начале новой группы.

Page = 1

End Sub

Private Sub ЗаголовокГруппы2_Format(Cancel As Integer, FormatCount As Integer)

' Отображение строк ОптимальныйРезультатНадпись и ПродавецНадпись,

' итоги продавца удовлетворяют условиям отбора.

If Me!ИтогиПродавца > 50000 Then

Me!ОптимальныйРезультатНадпись.Visible = True

Me!ПродавецНадпись.Visible = True

Else

Me!ОптимальныйРезультатНадпись.Visible = False

Me!ПродавецНадпись.Visible = False

End If

End Sub

Private Sub Report_NoData(Cancel As Integer)

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

Dim strMsg As String, strTitle As String

Dim intStyle As Integer

strMsg = "Необходимо ввести дату с 01 января 05 г. по 31 декабря 08 г."

intStyle = vbOKOnly

strTitle = "Данные отсутствуют"

MsgBox strMsg, intStyle, strTitle

Cancel = True

End Sub

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

SELECT DISTINCTROW Заказы.ДатаРазмещения AS Выражение1, Заказы.КодЗаказа, [Промежуточная сумма заказа].ПромежуточнаяСумма

FROM Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа

WHERE (((Заказы.ДатаРазмещения) Is Not Null))

ORDER BY Заказы.ДатаРазмещения;

В конструкции отчета мы используем функцию вида =DatePart("q";[ДатаРазмещения]) для определения квартала размещения заказа. Функция =Format(Date();"dd-mmm-yyyy") задает текущую дату.

Источником записей для отчета Продажи по годам является одноименный запрос. Для определения уровней группировки отчета воспользуемся функцией сортировка и группировка Microsoft Access:

Конструкция отчета имеет вид:



Наконец, структура отчета Счет имеет вид:

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

Рисунок 2.26. - Структура макроса, осуществляющего фильтрацию клиентов по алфавиту

Сама форму имеет следующий вид:

Рисунок 2.27. - Форма Телефоны клиентов в режиме конструктора

Глава 3. Оценка надежности и экономической эффективности системы учета заказов на ООО «Кортереал»

3.1 Выбор метода оценки надежности базы данных ООО «Кортереал»

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

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

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

Аналитическое моделирование НПС включает четыре шага [35, стр. 177-179]:

определение предположений, связанных с процедурой тестирования ПС;

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

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

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

Основными типами моделей при определении надежности программных средств являются динамические (рассмотрение появления отказов во времени) и статические (учитывают количество ошибок от числа тестовых прогонов). Из числа дискретных динамических моделей известны модели Шумана, La Padula, Шика-Волвертона. Непрерывные динамические модели представлены моделями Джелинского-Моранды, Муса, переходных вероятностей. Статические модели надежности представлены моделями Миллса, Липова, Коркорэна, Нельсона и другими [10, стр. 116-122]. Статические модели принципиально отличаются от динамических прежде всего тем, что в них не учитывается время появления ошибок в процессе тестирования и не используется никаких предположений о поведении функции риска.

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

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

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

Итак, следует ориентироваться на использованием модели Шумана и её развития: модели La Padula. Рассмотрим их более подробно.

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

Модель Шумана может быть использована при определенным образом организованной процедуре тестирования [22, стр. 46-51]. Использование модели Шумана предполагает, что тестирование проводится в несколько этапов. Каждый этап представляет собой выполнение программы на полном комплексе разработанных тестовых данных. Выявленные ошибки регистрируются, но не исправляются. По завершении этапа на основе собранных данных о поведении ПС на очередном этапе тестирования может быть использована модель Шумана для расчета количественных показателей надежности.

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

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

Скорость обнаружения ошибок пропорциональна числу оставшихся ошибок. Предполагается, что до начала тестирования в системе имеется Ет ошибок. В течение времени тестирования обнаруживается c ошибок в расчете на команду. Таким образом, удельное число ошибок на одну машинную команду, оставшихся в системе после т времени тестирования, равно:

, (3.1)

где IT -- общее число машинных команд, которое предполагается постоянным в рамках этапа тестирования. Будем предполагать, что значение функции частоты отказов Z(t) пропорционально числу ошибок, оставшихся в ПС после израсходованного на тестирование времени :

, (3.2)

где С -- некоторая константа; t -- время работы ПС без отказа.

Тогда, если время работы ПС без отказа 1 отсчитывается от точки t = 0, а остается фиксированным, функция надежности, или вероятность безотказной работы на интервале времени от 0 до t, равна:

; (3.3)

. (3.4)

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

. (3.5)

Предполагая, что интенсивность появления ошибок постоянна и равна , можно вычислить ее как число ошибок в единицу времени:

, (3.6)

где Аi -- количество ошибок на i-м прогоне.

. (3.7)

Имея данные для двух различных моментов тестирования a и b, которые выбираются произвольно с учетом требования, чтобы c(b)< c(A) можно сопоставить уравнения (3.4) и (3.7) при:

, (3.8)

. (3.9)

Вычисляя отношения (8) и (9), получим:

. (3.10)

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

. (3.11)

Получив неизвестные Е и С, можно рассчитать надежность программы по формуле (3.3).

Модель Lа Раdula является модификацией модели Шумана и ориентирован на использованием в системах, в которых уровень влияния ошибки в одном из модулей на другие модули программного комплекса минимален. По этой модели выполнение последовательности тестов производится в т этапов. Каждый этап заканчивается внесением изменений (исправлений) в программную систему. Возрастающая функция надежности базируется на числе ошибок, обнаруженных в ходе каждого тестового прогона. Надежность системы в течение i-го этапа:

, i = 1,2,3,…, (3.17)

где А--параметр роста; при i .

Эти неизвестные вычисляются путем решения следующих уравнений:

, (3.18)

, (3.19)

где Si. -- число тестов; mi, -- число отказов во время i-го этапа; т -- число этапов; i=1,2, ...,т. Определяемый по этой модели показатель есть надежность системы на i-м этапе:

, i = m+1, m+2 … (3.20)

Преимущество модели заключается в том, что она является прогнозной и, основываясь на данных, полученных в ходе тестирования, дает возможность предсказать вероятность безотказной работы программы на последующих этапах ее выполнения. Как легко видеть, модель Шумана для системы учета заказов ООО «Кортереал» является избыточной, а модель La Padula в полной мере отражает особенности функционирования программного комплекса. Поэтому именно эту модель целесообразно использовать для оценки уровня надежности системы учета заказов ООО «Кортереал».

3.2 Расчет надежности системы учета заказов на ООО «Кортереал»

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

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

Рисунок 3.1. - Система навигации в базе учета заказов ООО «Кортереал»

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

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

Таблица 3.1. - Ошибки программы по категориям и частоты их появления

Тип ошибки	Количество ошибок	Частота появления ошибки
Ошибки вычислений	5	0,10
Логические ошибки	11	0,23
Ошибки ввода-вывода	8	0,17
Ошибки манипулирования данными	9	0,19
Ошибки сопряжения	8	0,17
Ошибки определения данных	4	0,08
Ошибки в БД	3	0,06
ВСЕГО	48	1

Таким образом, в основном при разработке программного комплекса были допущены логические ошибки (в основном, неверная организация запросов), а также существенную долю ошибок составили некорректности при организации ввода и вывода данных (17%, в основном из-за неверного указания формата вводимых данных), ошибки сопряжения (опять же в основном при организации сложных запросов) и ошибки манипулирования данными в работе макросов.

По этапам тестирования обнаруженные ошибки распределились следующим образом:

1-ый этап: 9 ошибок

2-ой этап: 9 ошибок

3-ий этап: 8 ошибок

4-ый этап: 9 ошибок

5-ой этап: 6 ошибок

6-ий этап: 3 ошибок

7-ый этап: 2 ошибок

8-ой этап: 1 ошибок

9-ий этап: 1 ошибок

10-ый этап: 0 ошибок

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

Si - число тестов на этапе; mi - число отказов на i-ом этапе;

m - число этапов; Rf - предельное значение надежности;

A - параметр роста;

R(i)=Rf-A/i - надежность на i-ом этапе.

m:=10;

;

А: =1

Given

Rf=0.9846

A=0.485

Были получены следующие расчетные контрольные значения:

Шаг тестирования i	1	5	10	20	50	100
надежность	0,461	0,849	0,8975	0,92175	0,9363	0,94115

График надежности представлен на рисунке 3.2.

Рисунок 3.2. - График надежности

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

3.3 Оценка экономической эффективности внедрения системы учета заказов на ООО «Кортереал»

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

При внедрении на ООО «Кортереал» единой системы учета заказов система документооборота предприятия претерпела существенные изменения. Основными из них являются следующие:

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

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

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

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

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

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

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

-- принятие и оформление поступившего заказа

-- согласование заказа (проверка наличия товаров на складе, проверка возможности заказа товаров у поставщиков)

-- оформление товаров на склад

-- оформление (при необходимости) заказа на продукцию у поставщиков

-- выставление счета покупателям

-- контроль оплаты выставленных счетов

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

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

Единая система учета заказов позволяет заинтересованным пользователям совершать все вышеперечисленные элементарные действия просто путем выполнения запроса в базе данных - база данных ООО «Кортереал» как раз и разрабатывалась с целью унификации и автоматизации этих действий.

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

Таблица 3.2. - Затраты времени на формирование документации

Запрос	Кол-во в месяц	Время на обработку в отчетном году, мин	Время на обработку после внедрения БД, мин	Экономия живого труда за год, час
принятие и оформление поступившего заказа	1860	12	6	2232
согласование заказа	870	15	10	870
оформление товаров на склад	66	10	6	53
оформление заказа на продукцию у поставщиков	48	25	10	144
выставление счета покупателям	1620	8	2	1944
контроль оплаты выставленных счетов	1620	6	2	1296
ИТОГО за год	73008	11982	5443,2	6539

Таким образом, внедрение единой системы учета заказов на ООО «Кортереал» позволяет сократить затраты живого труда за год на 6539 час. С учетом общей численности сотрудников, выполняющих работы по обслуживанию и контролю заказов (сотрудники отдела продаж, менеджеры склада и сотрудники бухгалтерии), в 18 человек, общий фонд рабочего их времени составляет (средняя продолжительность рабочего дня принимается 7,8 часа, среднее количество рабочих дней в году 264) 18*7,8*264=37065 часов в год. Следовательно, экономия живого труда составит 17,64%. После внедрения компьютерной системы учета заказов сотрудники смогут меньше времени тратить на рутинные операции оформления и обработки документации, более эффективно заниматься своими непосредственными обязанностями: ведением переговоров с клиентами и поставщиками, аналитической работе и др. При необходимости также возможно сокращение численности работников и их перепрофилирование.

По данным бухгалтерии, совокупная заработная плата сотрудников отдела продаж, бухгалтерии и складских работников за отчетный 2011 год составила 2678,4 тыс. руб. Следовательно, экономия в денежном выражении за счет сокращения затрат живого труда при внедрении системы учета заказов на ООО «Кортереал» в плановом году составит 472,4 тыс. руб.