![](/stc/img/evkova.png)
Проектирование информационной системы по взаимодействию с поставщиками
Содержание:
Введение
Управление поставками и поставщиками достаточно трудоёмкий процесс. Так как требуется обработка большого количества документов и анализа полученных результатов для определения надёжности поставщиков.
Внедрение автоматизированной системы – это способ оптимизации бизнес-процессов. Эти системы позволяют автоматизировать учёт информации для различных бизнес-процессов. Системы могут иметь разный масштаб от автоматизации одной простой задачи до комплексной автоматизации всех процессов компании. В первую очередь, в качестве мест автоматизации выбираются трудоёмкие бизнес-процессы.
Повышения эффективности трудоёмких процессов неразрывно связано с обеспечением информационной поддержки, именно с этим связана необходимость построения и внедрения новых информационных систем поддержки. Данный факт не вызывает сомнений у организаций любой направленности и масштаба.
На данный момент в России существует заметный рост интереса к информационным автоматизированным системам (АИС), как в государственных и коммерческих структурах.
Автоматизированная информационная система позволяет решить ряд вопросов:
- снижение материальных затрат;
- снижение времени обработки документов;
- снижение вероятности возникновения ошибки при обработке документов;
- повысить эффективность учёта в процессах;
- сделать бизнес-процессы более прозрачными;
- повысить контроль за исполнением задач сотрудников.
Объектом исследования является отдел снабжения.
Целью работы автоматизация процесса управления поставками и взаимодействия с поставщиками.
Задачи работы:
- анализ выбранного комплекса задач;
- изучение систем аналогов для поставленной задачи;
- постановка задачи;
- спроектировать логическую модель;
- спроектировать физическую модель базы данных;
- спроектировать интерфейс системы;
- спроектировать программные модули ИС;
- провести разработку и тестирование системы.
Обоснование разработки системы
Описание существующих систем автоматизации снабжения
Были рассмотрены некоторые существующие системы, позволяющие автоматизировать управление поставками и поставщиками.
Система «ЛотЭксперт SRM».
ЛотЭксперт SRM – это передовое программное решение, предназначенное для комплексной автоматизации управления закупками и процессами материально-технического снабжения в коммерческих и государственных предприятиях, организациях, холдинговых структурах (SRM – Supplier relationship management).
Специальная версия системы предлагается для организаций, осуществляющих закупки по Федеральному закону от 18.07.2011 №223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц».
ЛотЭксперт SRM автоматизирует полный цикл управления закупками, от планирования расходов до контроля исполнения договоров, аналитики и отчетности. В составе программного комплекса предусмотрено также решение для построения корпоративной электронной торговой площадки.
При внедрении в организации процессов планирования закупок, подразделения формируют в системе планы закупок (потребностей) в привязке к классификатору закупаемых товаров, работ, услуг и статьям расходов. Планы (планы-графики) закупок проходят необходимые процедуры согласования через электронный документооборот, по результатам формируется сводный план закупок предприятия, может осуществляться консолидация по однотипным потребностям.
Помимо закупок, ЛотЭксперт позволяет проводить реализацию на электронных торгах невостребованных товарно-материальных ценностей, неликвидов, б/у техники, складских остатков, отходов производства, продукции и пр.
Система позволяет автоматически формировать извещения, типовую часть документации о закупке, протоколы, уведомления, договора, иные печатные и электронные документы в форматах офисных приложений: Microsoft Word, Adobe PDF, OpenOffice. Это позволяет снизить объемы рутинной работы при осуществлении закупок.
Система «iTender SRM».
Система управления закупками на предприятии, iTender SRM — это набор современных инструментов, применяемых на разных этапах процесса управления закупками и взаимодействия с поставщиками:
- планирование закупок;
- управление качеством поставщиков;
- рейтинг поставщиков;
- корпоративный сайт закупок;
- проведение закупочных процедур;
- корпоративный электронный магазин;
- управление договорами.
Модуль iTender Планирование закупок отвечает за регистрацию, согласование, ревью, консолидирование заказов, анализ и прогнозирование потребностей, формирование плана-графика закупок, коммуникацию заказчика с поставщиком, позволяя в оперативном режиме получать важную информацию, например, об изменениях в условиях поставок, новинках производства и так далее.
Для минимизации рисков при заключении договоров с поставщиками эффективным инструментом является рейтинг поставщиков.
Подобная система (рейтинг) – это единая база данных, которая содержит информацию о контрагентах предприятия и историю работы с ними при исполнении договоров. Индекс деловой репутаций вычисляется по определенной методике для каждого поставщика на основании фактов, которые можно документально подтвердить. При расчете дается оценка в баллах наиболее значимым негативным и позитивным фактам поведения участника закупки при исполнении им обязательств по заключенным договорам. Используя специальную методику оценки влияния факта на репутацию контрагента определяется интегральный числовой показатель (показатели), который и является рейтингом репутации контрагента.
Этот индекс в дальнейшем может учитываться в процессе проведения закупочных процедур, в частности при определении победителя тендера.
В iTender SRM может быть установлена финансовая система iTender Финанс, предназначенная для оптимизации работы заказчика и его поставщиков в рамках процессов, связанных с внесением-возвратом обеспечения участия в торгах и обеспечения исполнения контракта.
Система «APS SMART».
SRM-система управления закупками APS SMART — продукт, превосходящий потребности клиентов для решения задач закупок в разных отраслях. Система прекрасно себя зарекомендовала в работе как коммерческих, так и государственных компаний. Обеспечивает лучшие практики электронных процедур для автоматизации закупочной деятельности как для Закупщиков, так и для Поставщиков с учётом отраслевой специфики электронных торгов через внешние площадки.
Основная задача системы APS SMART — создать единую информационную среду для всех этапов и процессов закупочной деятельности компании, от прогнозирования потребности до приёмки и учёта поставок, внутри компании и при работе с внешними контрагентами-поставщиками. Автоматизация отдела закупок – только часть общего процесса операционного управления компанией.
Полная автоматизация и контроль бизнес-процесса закупок на предприятии обеспечивается комплексной работой всех модулей системы: управления заявками, тендерами/редукционами, контрактами и поставками.
Модульная система обеспечивает гибкую настройку моделей рабочих процессов в соответствии с внутренней политикой и процедурами компании, что делает её универсальной для любого бизнеса. При этом система выступает консолидатором данных всех информационных потоков и имеет возможность автоматически генерировать аналитику и отчётность в разных разрезах.
Каждый модуль стандартизирует процедуры и упрощает взаимодействие и контроль на одном из этапов закупочного процесса. Кроме того, отдельные модули обеспечивают работу в «едином окне» с раздельным доступом к документам, интеграцию с учётными системами предприятия и возможность самостоятельного администрирования системы.
Основные модули системы:
- заявка;
- тендер;
- контракт;
- платёж;
- заявка и приёмка;
- аналитика и KPI;
- управление поставщиками;
- календарь поставок;
- управление проектами;
- прогнозирование;
- планирование;
- бюджетирование;
- интеграция;
- администрирование.
Модель процессов взаимодействия с поставщиком
IDEF – это целый набор аналитических средств, применяемых не только в управлении бизнесом, но и во многих других сферах [8]. IDEF0 представляет собой модель функций, причем сложные функции делятся на более простые составляющие, а затем различные блоки логически объединяются посредством стрелок [4].
Был проведён анализ процессов управления поставками. На рисунке 1 представлена контекстная диаграмма процесса управления поставками и взаимодействия с поставщиками в базовом варианте.
Рисунок 1 – Контекстная диаграмма процесса управления поставками и взаимодействия с поставщиками
Входящие потоки:
- данные о поставщике;
- данные об МТО;
- список поставляемого МТО от поставщика;
- требования на МТО.
Выходящие потоки:
- журнал поставщиков;
- журнал МТО;
- журнал заказов МТО;
- отчёты.
Исполнители и ресурсы:
- отдел снабжения.
Управляющие потоки:
- должностная инструкция;
- надёжность поставщика.
Декомпозиция процесса управления поставками и взаимодействия с поставщиками выявляет его составляющие процессы:
- учёт МТО;
- учёт поставщиков и поставляемого ими МТО;
- регистрация требования МТО и формирование заказов;
- ведение заказов и формирование отчётов.
Структурно-функциональная диаграмма процесса представлена на рисунке 2.
Рисунок 2 – Структурно-функциональная диаграмма процесса управления поставками и взаимодействия с поставщиками
Проанализировав рассмотренные бизнес-процессы можно заметить следующие недостатки ведения информации в базовом варианте:
- долгий поиск информации о заказах и поставщиках;
- сложность отслеживания требований на МТО;
- сложность ведения списков поставляемого МТО;
- сложность определения надёжности заказчика.
Была проведена декомпозиция процесса регистрация требования МТО и формирование заказов – рисунок 3.
Составляющие процессы:
- регистрация требования МТО;
- выбор поставщика;
- регистрация заказа;
- формирование списка, заказанного МТО.
Рисунок 3 – Структурно-функциональная диаграмма процесса «регистрации требования МТО и формирования заказов»
Была проведена декомпозиция процесса ведения заказов и формирования отчётов – рисунок 4.
Составляющие процессы:
- учёт результатов заказа;
- формирование отчёта о требованиях;
- формирование отчёта о заказах;
- формирование отчёта о поставщике.
Рисунок 4 – Структурно-функциональная диаграмма процесса «ведения заказов и формирования отчётов»
В результате выявлено, что автоматизация данного процесса приведёт к следующему:
- уменьшится время обработки документов;
- снизятся трудозатраты;
- уменьшаться ошибки, связанные с ручным вводом и неточным поиском информации;
- быстрое и точное формирование отчётов;
- прозрачность и управляемость процесса снабжения организации;
централизованное хранение информации.
Определение требований к ИС
Выявлены следующие функциональные требований к ИС управления поставками и поставщиками:
- учёт МТО;
- учёт поставщиков;
- учёт требований на МТО;
- учёт поставляемого МТО;
- ведение заказов и заказанного МТО;
- ведение справочной информации
Требуется реализовать систему, которая будет хранить следующую информацию:
- МТО;
- поставщик;
- поставляемое МТО;
- требования МТО;
- заказ;
- заказанное МТО.
МТО определяется следующими реквизитами: название, категория, бренд, единица, описание.
Поставщик определяется следующими реквизитами: название, ИНН, адрес, телефон, надёжность, комментарий.
Поставляемое МТО определяется следующими реквизитами: МТО, поставщик, цена.
Требуемое МТО определяется следующими реквизитами: МТО, количество, создан, закрыто.
Заказ определяется следующими реквизитами: создан, поставка, поставщик, стоимость, статус.
Заказанное МТО определяется реквизитами: заказ, МТО, количество, цена.
Также, в базе потребуются следующие, более простые справочники: категория, бренд, статус.
Система должна формировать отчёты:
- отчёт о требованиях МТО;
- отчёт о заказах по статусу за период;
- отчёт о поставщике.
Потребуется спроектировать и разработать систему, которая будет удовлетворять всем перечисленным требованиям.
Проектирование и разработка системы
Специалист по снабжению получает описание МТО от производственного сектора. Получает требования на МТО. Ищет поставщиков, составляет базу поставщиков. Формирует список поставляемого МТО поставщиком.
Специалист регистрирует заказ и формирует список заказанного МТО. Отслеживает статус заказа. От результатов заказа зависит надёжность поставщика.
По журналу заказов формируется отчёт о заказах по статусу за период, который передаётся руководству.
Также, для внутреннего использования и для руководства составляется отчёт о требовании МТО.
Для анализа надёжности поставщика составляется отчёт о поставщике, который отражает выполненный заказы, который сгруппированы по статусу. Отображает общую сумму заказов, выполненных поставщиком.
Выделены следующие сущности:
- МТО;
- поставщик;
- поставляет;
- требование;
- заказ;
- заказанное;
- категория;
- бренд;
- статус.
В таблице 1 представлено описание связей между выявленными сущностями.
Таблица 1
Описание связей
Сущность 1 |
Сущность 2 |
Тип связи |
Идентифицирующая |
Бренд |
МТО |
Один-ко-многим |
Нет |
Категория |
МТО |
Один-ко-многим |
Нет |
МТО |
Требование |
Один-ко-многим |
Нет, обязательная |
Поставщик |
Поставляет |
Один-ко-многим |
Да |
МТО |
Поставляет |
Один-ко-многим |
Да |
Поставщик |
Заказ |
Один-ко-многим |
Нет, обязательная |
Статус |
Заказ |
Один-ко-многим |
Нет, обязательная |
Заказ |
Заказанное |
Один-ко-многим |
Да |
МТО |
Заказанное |
Один-ко-многим |
Да |
В результате, была составлена логическая модель базы данных, которая представлена на рисунке 5.
Рисунок 5 – Логическая модель базы данных
В базу данных для ИС управления поставками и поставщиками входят следующие таблицы:
- поставщик;
- МТО;
- требование;
- поставляемое;
- заказ;
- заказанное;
- категория;
- бренд;
- статус.
Рассмотрим подробнее состав таблиц базы данных (таблицы 2 – 10).
Таблица 2
«Поставщик»
Поле |
Тип поля |
Ограничения |
Код_поставщика |
Int |
PK |
Название |
Varchar |
50, not null |
ИНН |
Varchar |
12 |
Адрес |
Varchar |
50 |
Телефон |
Varchar |
30 |
Надёжность |
Int |
- |
Комментарий |
Varchar |
200 |
Таблица 3
«МТО»
Поле |
Тип поля |
Ограничения |
Код_МТО |
Int |
PK |
Название |
Varchar |
50, not null |
Код_категории |
Int |
FK |
Код_бренда |
Int |
FK |
Описание |
Varchar |
100 |
Единика |
Varchar |
10 |
Таблица 4
«Поставляемое»
Поле |
Тип поля |
Ограничения |
Код_поставщика |
Int |
PK, FK |
Код_МТО |
Int |
PK, FK |
Цена |
Money |
Not null |
Таблица 5
«Требование»
Поле |
Тип поля |
Ограничения |
Код_требования |
Int |
PK |
Код_МТО |
Int |
FK, not null |
Создано |
Datetime |
Not null |
Количество |
Int |
Not null |
Закрыто |
Bit |
Таблица 6
«Заказ»
Поле |
Тип поля |
Ограничения |
Код_заказа |
Int |
PK |
Код_поставщика |
Int |
FK, not null |
Код_статуса |
Int |
FK, not null |
Создан |
Datetime |
Not null |
Поставка |
Datetime |
|
Стоимость |
Money |
Таблица 7
«Заказанное»
Поле |
Тип поля |
Ограничения |
Код_заказа |
Int |
PK, FK |
Код_МТО |
Int |
PK, FK |
Количество |
Int |
Not null |
Цена |
Money |
Not null |
Таблица 8
«Категория»
Поле |
Тип поля |
Ограничения |
Код_категории |
Int |
PK |
Название |
Varchar |
50, not null |
Таблица 9
«Бренд»
Поле |
Тип поля |
Ограничения |
Код_бренда |
Int |
PK |
Название |
Varchar |
50, not null |
Таблица 10
«Статус»
Поле |
Тип поля |
Ограничения |
Код_статуса |
Int |
PK |
Название |
Varchar |
50, not null |
Получившаяся физическая модель базы данных представлена на рисунке 6.
Рисунок 6 – Физическая модель базы данных
Физическая модель базы данных была преобразована в базу данных в MS SQL Server 2017 и на рисунке 7 представлена схема данных.
Рисунок 7 – Схема базы данных
Проектирование структуры приложения
Был спроектирован интерфейс системы в сценарии диалога, который представлен на рисунке 8.
Рисунок 8 – Сценарий диалога
Главное окно системы содержит главное меню с пунктами:
- поставщики и МТО;
- справочники;
- отчёты;
- настройки.
Поставщики и МТО содержит следующие пункты:
- поставщик;
- МТО;
- Закрыть.
Пункт поставщик открывает окно, в котором доступно меню со следующими действиями: добавить; редактировать; удалить.
Окно МТО содержит таблицу с всплывающем меню:
- добавить;
- редактировать;
- удалить;
- поставляют;
- требования.
При формировании списка, поставляемого МТО доступно следующее меню:
- добавить;
- редактировать;
- удалить.
При оформлении требований доступно следующее меню:
- добавить;
- редактировать;
- удалить.
Пункт справочники содержит:
- категории;
- бренды;
- статусы.
Каждый из пунктов открывает окна с таблицей, в которой доступны пункты:
- добавить;
- редактировать;
- удалить.
Пункт «отчёты» содержит:
- отчёт о требованиях МТО;
- отчёт о заказах по статусу за период;
- отчёт о поставщике.
Настройки: подключение к БД.
Также, в главном окне содержится всплывающее меню таблицы заказов, которое содержит: добавить; редактировать; удалить.
Таблица заказанного МТО содержит всплывающее меню с пунктами:
- добавить;
- редактировать;
- удалить.
В результате, выделены следующие окна системы:
- главное окно;
- окно работы с МТО;
- окно редактирование записи МТО;
- окно работы с поставляемым МТО;
- окно редактирования списка, поставляемого МТО;
- окно работы с требованиями на МТО;
- окно редактирование записи требования МТО;
- окно таблицы поставщиков;
- окно редактирование записи о поставщике;
- окно таблицы справочника категорий;
- окно редактирования записи справочника категорий;
- окно таблицы справочника брендов;
- окно редактирования записи справочника брендов;
- окно таблицы справочника статусов;
- окно редактирования записи справочника статусов;
- окно работы с записью заказа;
- окно работы с записью заказанного МТО.
Также, для выбора МТО в заказ потребуется реализовать окно выбора МТО из действующих требований, которые может доставить выбранный поставщик для заказа.
Были спроектированы программные модули, из которых состоит клиентское приложение. Схема взаимодействия программных модулей представлена на рисунке 9.
Рисунок 9 – Схема взаимодействия программных модулей
Всего, система состоит из следующих модулей: uMain; uZakaz; uZakazannoe; uMTO; uMTOOne; uPostavlyaemoe; uPostavlyaemoeOne; uTrebovanie; uTrebovanieOne; uPostavshik; uPostavshikOne; uSetLink; uCategory; uCategoryOne; uBrand; uBrandOne; uStatus; uStatusOne; uFrameOne; uFrameGrid; uDM.
Описание программных модулей представлено в таблице 11.
Таблица 11
Описание программных модулей
Модуль |
Описание |
uMain |
Содержит описание главного окна |
uZakaz |
Содержит описание окна редактирования записи заказа |
uZakazannoe |
Содержит описание окна редактирования записи заказанного МТО |
uMTO |
Содержит окно таблицы МТО |
uMTOOne |
Содержит описание окна редактирования записи МТО |
uPostavlyaemoe |
Содержит окно таблицы поставляемого МТО |
uPostavlyaemoeOne |
Содержит описание окна редактирования записи поставляемого МТО |
uTrebovanie |
Содержит окно таблицы требований на МТО |
uTrebovanieOne |
Содержит описание окна редактирования записи требований на МТО |
uPostavshik |
Содержит окно таблицы поставщиков |
uPostavshikOne |
Содержит описание окна редактирования записи поставщика |
uSetLink |
Содержит окно настройки подключения к БД |
uCategory |
Содержит окно таблицы категорий |
uCategoryOne |
Содержит описание окна редактирования записи справочника категории |
uBrand |
Содержит окно таблицы брендов |
uBrandOne |
Содержит описание окна редактирования записи справочника бренда |
uStatus |
Содержит окно таблицы статусов |
uStatusOne |
Содержит описание окна редактирования записи справочника статуса |
uFrameOne |
Содержит описание фрейма для окон редактирования записи |
uFrameGrid |
Содержит описание фрейма для окон редактирования табличных данных |
uDM |
Содержит описание доступа к данным |
Работа в системе начинается с главного окна, которое содержит таблицу заказов и таблицу заказанного МТО. На рисунке 10 представлено окно работы со справочником статусов заказов. Для открытия данного окна в главном меню требуется выбрать пункт справочники и выбрать тип – «статусы». Для редактирования записи в справочнике требуется вызвать контекстное меню таблицы статусов и выбрать один из пунктов. Данные можно сохранить или отменить изменения в базе.
Рисунок 10 – Окно справочника категорий
Далее, добавим данные о поставщиках. В главном меню выбираем пункт «поставщики и МТО». Выбираем подпункт «поставщики». Откроется окно таблицы поставщиков – рисунок 11.
Рисунок 11 – Окно таблицы поставщиков
Можно вызвать окно редактирования записи о поставщике через контекстное меню таблицы поставщиков – рисунок 12.
Рисунок 12 – Окна редактирования записи о поставщике
Для работы с МТО, требуется в главном меню выбрать пункт «поставщики и МТО» и выбрать «МТО». Откроется окно таблицы МТО, которое представлено на рисунке 13. Для редактирования записи об МТО, требуется вызвать контекстное меню таблицы МТО.
Рисунок 13 – Окно таблицы МТО
Для редактирования данных о поставляемом МТО требуется в контекстном окне таблицы МТО выбрать пункт «поставляемое МТО». Окно представлено на рисунке 14.
Рисунок 14 – Окно поставляемого МТО
Для редактирования данных о требованиях на МТО требуется в контекстном окне таблицы МТО выбрать пункт «требования МТО». Окно представлено на рисунке 15.
Рисунок 15 – Окно требований на МТО
На рисунке 16 представлено главное окно системы. Откуда доступно ведение заказов. На рисунке 17 представлено окно редактирования записи о заказе. На рисунке 18 представлено окно редактирования записи о заказанном МТО.
Рисунок 16 – Главное окно
Рисунок 17 – Окно работы о записи заказа
Рисунок 18 – Окно работы о записи заказанного МТО
Специалисту по снабжению доступно формирование отчётов:
- отчёт о требованиях МТО
- отчёт о заказах по статусу за период;
- отчёт о поставщике.
На рисунках 19 – 21 представлены примеры сформированных отчётов.
Рисунок 19 – Приме отчёта о требованиях МТО
Рисунок 20 – Пример отчёта о заказах по статусу за период
Рисунок 21 – Пример отчёта о поставщике
Разработанное приложение позволяет управлять данными в базе и выводить отчёты, необходимые в работе. В приложении представлен текст программы.
Заключение
В работе стояла задача автоматизации управления закупками и поставщиками. Была составлена SADT-модель процесса управления поставками и поставщиками. Выявлены проблемы в данном процессе в базовом варианте:
- долгий поиск информации о заказах и поставщиках;
- сложность отслеживания требований на МТО;
- сложность ведения списков поставляемого МТО;
- сложность определения надёжности заказчика.
В ходе работы с темой были изучены следующие системы: «ЛотЭксперт SRM»; «iTender SRM»; «APS SMART».
Выявлены следующие функциональные требования:
- учёт МТО;
- учёт поставщиков;
- учёт требований на МТО;
- учёт поставляемого МТО;
- ведение заказов и заказанного МТО;
- ведение справочной информации;
- формирование отчётов.
Определено информационное обеспечение задачи. Построена логическая модель БД. Спроектирована физическая модель БД, определены таблицы БД:
- поставщик;
- МТО;
- требование;
- поставляемое;
- заказ;
- заказанное;
- категория;
- бренд;
- статус.
Был спроектирован сценарий диалога. Определены программные модули ИС.
Проведено тестирования ИС. Составлен контрольный пример работы в ИС. Система соответствует поставленным требованиям.
Список использованной литературы
- Амбалова З.А. Сравнение методологий разработки интеллектуальных систем в сфере управления комплексными проектами // В сб.: Инно-вационные механизмы решения проблем научного развития сборник статей по итогам Международной научно-практической конференции. 2017. С. 139-141.
- Буренин А.Н., Легков К.Е., Нестеренко О.Е. Методический подход к организации обработки оперативной информации распределенными вычислительными комплексами специального назначения // Наукоемкие технологии в космических исследованиях Земли. 2016. Т. 8. № 6. С. 18-30.
- Вендров А.М. CASE – технологии. Современные методы и средства проектирования информационных систем – М.: Финансы и статистика, 2017 г. - 230 с.
- Галас В.П. Вычислительные системы, сети и телекоммуникации. Часть 2. Сети и телекоммуникации. Учебник. В 2 ч. – Владимир: Изд-во ВлГУ, 2017. – 284 с.
- Грекул В.И. Проектирование информационных систем / Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. – М.: Интернет-университет информационных технологий, 2018 г. - 321 с.
- Добжинская М.А. Обзор существующих систем электронного документооборота // Научное сообщество студентов XXI столетия. Технические науки: сб. ст. по мат. XLIII междунар. студ. науч.-практ. конф. № 6(42). [Электронный ресурс]. – URL: https://sibac.info/archive/technic/6(42).pdf (дата обращения: 04.06.2020)
- Дубейковский В.И. Эффективное моделирование с CA ErwinProcessModeler (BPwin; AllfusionProcessModeler). 2-е изд., исправлен-ное и дополненное / В.И. Дубейковский. – М.: Диалог-МИФИ, 2015. – 384 с.
- Дунаев В.В. Базы данных. Язык SQL для студента – М.: БХВ, 2015. – 196 с.
- Иришкова К.Д., Найдис О.А. Исследование вариантов разработки и дальнейшей поддержки автоматизированных систем обработки информации // АНИ: экономика и управление. 2018. №1 (22). URL: https://cyberleninka.ru/article/n/issledovanie-variantov-razrabotki-i-dalneyshey-podderzhki-avtomatizirovannyh-sistem-obrabotki-informatsii (дата обращения: 03.06.2020).
- Кириллов В.В. Введение в реляционные базы данных. Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов - СПб.: БХВ-Петербург, 2015 г. - 464 c.
- Коваленко В. Проектирование информационных систем. - М.: Форум, 2018. - 320с.
- Культин Н.Б. Основы программирования в Embarcadero / Н.Б. Культин - СПб.:БХВ-Петербург, 2015. - 416с.
- Култыгин О.П. Администрирование баз данных. СУБД MS SQL Server – М: Московская финансово-промышленная академия, 2016. – 232 с.
- Липин Ю.Н. Разработка ПО (Delphi) – М.: LAP Publishing, 2017. – 300 с.
- Пирогов В.Ю. Некоторые особенности преподавания языка управления базами данных // Мир науки. – 2018. Т.6. №6. С.55.
- Стафиевская М.В., Петрова В.О. Моделирование бизнес-процессов как инструмент повышения эффективности деятельности организаций // Вестник Марийского государственного университета. Серия: Сельскохозяйственные науки. Экономические науки. 2018. № 2 (14). С. 126-134.
Исходный код приложения
unit uMain;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Data.DB, Vcl.StdCtrls, Vcl.Buttons,
Vcl.Menus, Vcl.DBCtrls, Vcl.Grids, Vcl.DBGrids, Vcl.ExtCtrls;
type
TfrmMain = class(TForm)
mm: TMainMenu;
miMain: TMenuItem;
miLibrary: TMenuItem;
miReport: TMenuItem;
miSettings: TMenuItem;
miPostavshiki: TMenuItem;
miMTO: TMenuItem;
miClose: TMenuItem;
miBlank: TMenuItem;
miCategory: TMenuItem;
miBrand: TMenuItem;
miStatus: TMenuItem;
miReport0: TMenuItem;
miReport1: TMenuItem;
miReport2: TMenuItem;
miLinking: TMenuItem;
pnlFilter: TPanel;
pnlMain: TPanel;
pnlSub: TPanel;
grdMain: TDBGrid;
grdSub: TDBGrid;
cbStatus: TDBLookupComboBox;
cbPostavshik: TDBLookupComboBox;
Label1: TLabel;
Label2: TLabel;
pmMain: TPopupMenu;
pmSub: TPopupMenu;
btnSearch: TBitBtn;
btnCancel: TBitBtn;
miAddMain: TMenuItem;
miEditMain: TMenuItem;
miDeleteMain: TMenuItem;
miAddSub: TMenuItem;
miEditSub: TMenuItem;
miDeleteSub: TMenuItem;
procedure miLinkingClick(Sender: TObject);
procedure miCloseClick(Sender: TObject);
procedure miAddSubClick(Sender: TObject);
procedure miEditSubClick(Sender: TObject);
procedure miDeleteSubClick(Sender: TObject);
procedure pmSubPopup(Sender: TObject);
procedure pmMainPopup(Sender: TObject);
procedure miReportClick(Sender: TObject);
procedure miMTOClick(Sender: TObject);
procedure miDeleteMainClick(Sender: TObject);
procedure btnSearchClick(Sender: TObject);
procedure btnCancelClick(Sender: TObject);
procedure FormShow(Sender: TObject);
procedure miAddMainClick(Sender: TObject);
procedure miEditMainClick(Sender: TObject);
procedure miPostavshikiClick(Sender: TObject);
procedure miStatusClick(Sender: TObject);
procedure miBrandClick(Sender: TObject);
procedure miCategoryClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
frmMain: TfrmMain;
implementation
{$R *.dfm}
uses
uDM, uZakazano, uMTO, uReport, uZakaz, uPostavshik, uStatus, uBrand, uCategory;
procedure TfrmMain.btnCancelClick(Sender: TObject);
begin
DM.tblStatus.First;
DM.tblStatus.Last;
DM.tblPostavshik.First;
DM.tblPostavshik.Last;
grdMain.DataSource.DataSet.Filtered:=false;
grdMain.DataSource.DataSet.Filter:='';
grdMain.DataSource.DataSet.Filtered:=true;
end;
procedure TfrmMain.btnSearchClick(Sender: TObject);
var
str: string;
begin
str:='';
if cbStatus.Text<>'' then
str:='([Код_статуса]='+DM.tblStatus.FieldByName('Код_статуса').AsString+')';
if cbPostavshik.Text<>'' then
if str<>'' then str:='('+str+') and ([Код_поставщика]='+DM.tblPostavshik.FieldByName('Код_поставщика').AsString+')'
else str:='([Код_поставщика]='+DM.tblPostavshik.FieldByName('Код_поставщика').AsString+')';
grdMain.DataSource.DataSet.Filtered:=false;
grdMain.DataSource.DataSet.Filter:=str;
grdMain.DataSource.DataSet.Filtered:=true;
end;
procedure TfrmMain.FormShow(Sender: TObject);
begin
btnCancel.Click;
end;
procedure TfrmMain.miAddMainClick(Sender: TObject);
var
frm: TfrmZakaz;
begin
Application.CreateForm(TfrmZakaz,frm);
frm.Tag:=0;
DM.tblZakaz.Append;
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.miAddSubClick(Sender: TObject);
var
frm: TfrmZakazano;
begin
Application.CreateForm(TfrmZakazano, frm);
frm.Tag:=0;
DM.tblZakazano.Append;
frm.ShowModal;
if frm.ModalResult=mrOk then DM.CalcSum;
frm.Free;
end;
procedure TfrmMain.miBrandClick(Sender: TObject);
var
frm: TfrmBrand;
begin
Application.CreateForm(TfrmBrand, frm);
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.miCategoryClick(Sender: TObject);
var
frm: TfrmCategory;
begin
Application.CreateForm(TfrmCategory, frm);
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.miCloseClick(Sender: TObject);
begin
Application.Terminate;
end;
procedure TfrmMain.miDeleteMainClick(Sender: TObject);
begin
if MessageDlg('Вы действительно хотите удалить запись?',mtWarning,mbOkCancel,0)=mrOk then
grdMain.DataSource.DataSet.Delete;
end;
procedure TfrmMain.miDeleteSubClick(Sender: TObject);
begin
if MessageDlg('Вы действительно хотите удалить запись?',mtWarning,mbOkCancel,0)=mrOk then
begin
grdSub.DataSource.DataSet.Delete;
DM.CalcSum;
end;
end;
procedure TfrmMain.miEditMainClick(Sender: TObject);
var
frm: TfrmZakaz;
begin
Application.CreateForm(TfrmZakaz,frm);
frm.Tag:=1;
DM.tblZakaz.Edit;
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.miEditSubClick(Sender: TObject);
var
frm: TfrmZakazano;
begin
Application.CreateForm(TfrmZakazano, frm);
frm.Tag:=1;
DM.tblZakazano.Edit;
frm.ShowModal;
if frm.ModalResult=mrOk then DM.CalcSum;
frm.Free;
end;
procedure TfrmMain.miLinkingClick(Sender: TObject);
begin
DM.LinkedBase;
end;
procedure TfrmMain.miMTOClick(Sender: TObject);
var
frm: TfrmMTO;
begin
Application.CreateForm(TfrmMTO, frm);
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.miPostavshikiClick(Sender: TObject);
var
frm: TfrmPostavshik;
begin
Application.CreateForm(TfrmPostavshik, frm);
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.miReportClick(Sender: TObject);
var
frm: TfrmReport;
begin
Application.CreateForm(TfrmReport, frm);
frm.Tag:=(Sender as TMenuItem).Tag;
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.miStatusClick(Sender: TObject);
var
frm: TfrmStatus;
begin
Application.CreateForm(TfrmStatus, frm);
frm.ShowModal;
frm.Free;
end;
procedure TfrmMain.pmMainPopup(Sender: TObject);
begin
miEditMain.Visible:=grdMain.DataSource.DataSet.RecordCount>0;
miDeleteMain.Visible:=grdMain.DataSource.DataSet.RecordCount>0;
end;
procedure TfrmMain.pmSubPopup(Sender: TObject);
begin
miAddSub.Visible:=grdMain.DataSource.DataSet.RecordCount>0;
miEditSub.Visible:=grdSub.DataSource.DataSet.RecordCount>0;
miDeleteSub.Visible:=grdSub.DataSource.DataSet.RecordCount>0;
end;
end.
unit uZakazano;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.Mask, Vcl.DBCtrls,
Vcl.Buttons, Vcl.ExtCtrls;
type
TfrmZakazano = class(TForm)
pnlMain: TPanel;
pnlButton: TPanel;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
btnSave: TBitBtn;
btnCancel: TBitBtn;
btnSelect: TBitBtn;
txtNameMTO: TDBText;
edtPrice: TDBEdit;
edtCnt: TDBEdit;
procedure btnSelectClick(Sender: TObject);
procedure btnSaveClick(Sender: TObject);
procedure btnCancelClick(Sender: TObject);
procedure FormShow(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
frmZakazano: TfrmZakazano;
implementation
{$R *.dfm}
uses
uDM, uSelectMTO;
procedure TfrmZakazano.btnCancelClick(Sender: TObject);
begin
DM.tblZakazano.Cancel;
ModalResult:=mrCancel;
end;
procedure TfrmZakazano.btnSaveClick(Sender: TObject);
begin
DM.tblZakazano.Post;
ModalResult:=mrOk;
end;
procedure TfrmZakazano.btnSelectClick(Sender: TObject);
var
frm: TfrmSelectMTO;
begin
Application.CreateForm(TfrmSelectMTO, frm);
frm.ShowModal;
DM.tblZakazano.FieldByName('Код_МТО').AsInteger:=DM.tblViewSelectMTO.FieldByName('Код_МТО').AsInteger;
DM.tblZakazano.FieldByName('Цена').AsCurrency:=DM.tblViewSelectMTO.FieldByName('Цена').AsCurrency;
DM.tblZakazano.FieldByName('Количество').AsCurrency:=DM.tblViewSelectMTO.FieldByName('Количество').AsCurrency;
frm.Free;
end;
procedure TfrmZakazano.FormShow(Sender: TObject);
begin
btnSelect.Visible:=Tag=0;
end;
end.
- Становление финансовой системы России
- Комбинированного дома из арболитовых блоков 500х300х250 мм и профилированного брус 190х150 мм
- Теоретические основы изучения денег (Сущность денег и их история развития)
- Разработка мебельного интернет-магазина
- Современная система мотивации персонала в организациях (Управление мотивацией и стимулированием труда на предприятиях ресторанного бизнеса)
- Особенности формирования проектной команды инновационного проекта ООО «Пенмак РУС».
- Организационно – правовые формы предприятий (организаций): преимущества, недостатки (на примере акционерного общества)
- Процессуальные теории мотивации и их применение в практике управления
- Логистическая сервисная система на предприятии и пути ее совершенствования
- Малые предприятия: преимущества, недостатки, перспективы развития.
- Разработка Web-сайта с использованием технологии PHP и MySQL
- Проектирование информационных систем