Файл: Проектирование ИС по управленческому учету в ООО «ТД БЕРУ».pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 01.04.2023

Просмотров: 57

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

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

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

Как показано на Рисунке 17 следующий модуль программы гораздо сложнее и обширнее предыдущего, ибо предусматривает три потока действий:

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


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

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

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

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

3. Дальше идет последний поток действий, который определяет список документов на подпись. Система учитывает вид подписи (электронный или классический).

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


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

На Рисунке 18 представлена Блок – схема модуля формирования окон.

Контрольный пример реализации проекта и его описание

Работа с модулем начинается с авторизации пользователя.

Существуют два пользователя:

1) Коммерческий директор – права не ограничены;
2) Менеджер — права ограничены;
3) Бухгалтер – права ограничены;
4) Системный Администратор – права не ограничены.

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

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

На рисунке 25 показана форма редактирования справочника Виды товаров.

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

Вид таблицы «Продажи» после обновления показан на рисунке 26.


Кнопка «Обновить доставку» открывает форму редактирования доставки.

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

Для анализа Коммерческий директор открывает форму Анализ (рис. 28).

Кнопка «Выручка» открывает набор кнопок для вывода отчета с диаграммой динамики выручки за выбранный период и таблицей выручки по товарам на определенную дату (рис.30).

Расчет глобальных показателей приводится в отчете на рисунке 31. Глобальные показатели рассчитываются на определенную дату.

Для оценки рентабельности продаж отдельных товаров открывают отчет Показатели по товарам (рис. 32).

Как видно из рисунка 32, рентабельность второго товара очень низкая.

Для анализа возможных выходов из этой ситуации используется модуль Что Если. На рисунке 33, показана форма для ввода анализируемых реквизитов.

После нажатия на кнопку «рассчитать» открывается отчет с ожидаемыми показателями (рис. 34).

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

Заключение

В представленной курсовой работе на тему “Проектирование ИС по управленческому учету в ООО «ТД БЕРУ» была рассмотрена проблема управленческого учета предприятия. Обнаружилось, что учет ведется нерегулярно. Что тем самым приводит к неэффективному управлению, приводящему к упущенной выгоде или прямым убыткам. Была разработана программа, цель которой является автоматизировать управленческий учет. Созданная программа полностью соответствует поставленной задаче. В аналитической части проведен комплекс работ,направленных на обоснование необходимости автоматизации: определена сущность задачи, описаны основные свойства системы, дано описание всем существующим бизнес-процессам, рассмотрены вопросы, связанные с анализом существующих разработок в этой области. 

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

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