Отчет по практике в ООО «Антик»

Автор работы: Пользователь скрыл имя, 17 Марта 2014 в 13:35, отчет по практике

Краткое описание

Цель данной работы - изучение особенностей учета и контроля договорных отношений с заказчиками компании «Антик», а также возможность автоматизировать наиболее трудоемкие и рутинные операции документооборота, до сих пор выполняемые сотрудниками вручную.
В соответствии с поставленными целями на преддипломной практике рассматриваются следующие задачи:
 изучение предметной области;
 обзор литературы по данной теме;
 исследование особенностей учета и контроля договоров поставки товара;
 определение основных функций создаваемой информационной системы;
 анализ рынка аналогов автоматизированных информационных систем;
 обоснование среды разработки информационной системы;
 построение SADT-модели разрабатываемой системы;
 построение концептуальной модели базы данных разрабатываемой информационной системы.

Содержание

1 ВВЕДЕНИЕ 4
2 ОСОБЕННОСТИ УЧЕТА И КОНТРОЛЯ ДОГОВОРНЫХ ОТНОШЕНИЙ КОМПАНИИ ООО «АНТИК» 5
2.1 Общая характеристика компании ООО «Антик» г. Новосибирска 5
2.1.1 Цели, задачи и масштаб деятельности компании «Антик» 5
2.1.2 Номенклатура продаваемой продукции в «Антик» 5
2.1.3 Характер производственной деятельности 5
2.1.4 Степень автоматизации производства, проблемы и задачи дальнейшей автоматизации 8
2.1.5 Организационная структура и стратегия управления компанией 8
2.2 Цели, задачи и функции информационной системы 10
2.3 Постановка задачи 11
2.3.1 Описание входной информации 11
2.3.2 Описание выходной информации 14
2.3.3 Описание алгоритма решения задачи 15
3 АВТОМАТИЗАЦИЯ УЧЕТА И КОНТРОЛЯ ДОГОВОРНЫХ ОТНОШЕНИЙ 16
3.1 Обзор аналогов информационной системы 16
3.1.1 Респект: Учет договоров 16
3.1.2 Кларис – Учет договоров 17
3.1.3 Автоматизация учета и регистрации договоров 19
3.1.4 Е1 Евфрат - Управление договорами 20
3.1.5 АстроСофт: Учет договоров 22
3.2 Обзор инструментальных средств программирования и СУБД 24
3.2.1 Microsoft Visual Studio 24
3.2.2 Eclipse 25
3.2.3 1С:Предприятие 26
3.2.4 Microsoft SQL Server 29
3.2.5 MySQL 29
3.2.6 Oracle Database 30
3.2.7 Обоснование выбора среды разработки ИС 30
3.3 Проектирование SADT-МОДЕЛИ 31
3.4 Концептуальная модель базы данных 32
3.4.1 ER-диаграмма 33
3.4.2 KB-диаграмма 33
3.4.3 FA-диаграмма 33
3.4.4 Глоссарий модели 33
ЗАКЛЮЧЕНИЕ 36
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 37
1 ВВЕДЕНИЕ 4
2 ОСОБЕННОСТИ УЧЕТА И КОНТРОЛЯ ДОГОВОРНЫХ ОТНОШЕНИЙ КОМПАНИИ ООО «АНТИК» 5
2.1 Общая характеристика компании ООО «Антик» г. Новосибирска 5
2.1.1 Цели, задачи и масштаб деятельности компании «Антик» 5
2.1.2 Номенклатура продаваемой продукции в «Антик» 5
2.1.3 Характер производственной деятельности 5
2.1.4 Степень автоматизации производства, проблемы и задачи дальнейшей автоматизации 8
2.1.5 Организационная структура и стратегия управления компанией 8
2.2 Цели, задачи и функции информационной системы 10
2.3 Постановка задачи 11
2.3.1 Описание входной информации 11
2.3.2 Описание выходной информации 14
2.3.3 Описание алгоритма решения задачи 15
3 АВТОМАТИЗАЦИЯ УЧЕТА И КОНТРОЛЯ ДОГОВОРНЫХ ОТНОШЕНИЙ 16
3.1 Обзор аналогов информационной системы 16
3.1.1 Респект: Учет договоров 16
3.1.2 Кларис – Учет договоров 17
3.1.3 Автоматизация учета и регистрации договоров 19
3.1.4 Е1 Евфрат - Управление договорами 20
3.1.5 АстроСофт: Учет договоров 22
3.2 Обзор инструментальных средств программирования и СУБД 24
3.2.1 Microsoft Visual Studio 24
3.2.2 Eclipse 25
3.2.3 1С:Предприятие 26
3.2.4 Microsoft SQL Server 29
3.2.5 MySQL 29
3.2.6 Oracle Database 30
3.2.7 Обоснование выбора среды разработки ИС 30
3.3 Проектирование SADT-МОДЕЛИ 31
3.4 Концептуальная модель базы данных 32
3.4.1 ER-диаграмма 33
3.4.2 KB-диаграмма 33
3.4.3 FA-диаграмма 33
3.4.4 Глоссарий модели 33
ЗАКЛЮЧЕНИЕ 36
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 37
ПРИЛОЖЕНИЕ А Договор поставки 38
ПРИЛОЖЕНИЕ Б Заявка на приобретение продукции 41
ПРИЛОЖЕНИЕ В Банковское платежное поручение 42
ПРИЛОЖЕНИЕ Г Счет-фактура 43
ПРИЛОЖЕНИЕ Д Товарная накладная 44

Прикрепленные файлы: 1 файл

Moy_otchet.docx

— 5.26 Мб (Скачать документ)

3.2.4 Microsoft SQL Server

Тип: Реляционная СУБД

Разработчик Microsoft, Sybase

Последняя версия: SQL Server 2012.

Цена: от 27 000 р.

Цена версии для разработчика :  1800р.

Microsoft SQL Server — система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприяти.

Доступные редакции СУБД:

  1. Enterprise 
  2. Business Intelligence 
  3. Standard
  4. Express (ограничение : максимальный размер бд 10ГБ ,1 ЦП и не более 4-х ядер на один ЦП)

Express  версия является бесплатным выпуском SQL Server, идеально подходящим для обучения, а также для создания небольших серверных приложений, которые могут распространяться независимыми поставщиками программного обеспечения [2].

3.2.5 MySQL

ТИП : Реляционная СУБД

Разработчик Sun Microsystems (2008-2010),Oracle (с 2010)

Операционная система: Кроссплатформенное ПО

Последняя версия 5.5.27 (28 сентября 2012)

Цена: бесплатно.

MySQL — свободная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

MySQL является решением для малых и средних приложений. Входит в состав серверов WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей [2].

3.2.6 Oracle Database

Тип: Объектно-реляционная СУБД

Разработчик: Oracle

Операционная система: Кроссплатформенное ПО

Последняя версия: 11gR2 (1 сентября 2009)

Лицензия: Коммерческая, для разработчиков

Цена для разработчика: от $140

Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.

СУБД Oracle поставляется в четырех различных редакциях, ориентированных на различные сценарии разработки и развертывания приложений (а также отличающиеся ценой).

  1. Enterprise Edition.  
  2. Standard Edition - не может устанавливаться на системы, имеющие более 4-х процессорных разъёмов. 
  3. Standard Edition One - не может устанавливаться на системы, имеющие более 2-х процессорных разъёмов; не поддерживает кластеризацию (RAC). 
  4. Personal Edition - один пользователь. 
  5. Lite - для мобильных и встраиваемых устройств. 
  6. Express Edition - бесплатная редакция; используемая оперативная память — 1 Гбайт, а также используется только 1 процессор. Максимальный объем базы данных Oracle Database XE составляет 12 гигабайт (Гб). Из них от 0.5 до 0.9 Гб используются словарем данных, внутренними схемами и временным дисковым пространством. Поэтому остается 11.0 Гб для пользовательских данных. Только для установки на  Windows 32-bit Linux x86 [2].

3.2.7 Обоснование выбора среды разработки ИС

Для разработки информационной системы была выбрана среда «1С:Предприятие».

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

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

Преимущества использования 1С:Предприятия 8.2 для разработки проекта по сравнению с другими  программными средствами:

  1. Нет необходимости разрабатывать новую базу данных, т.к. конфигурация системы 1С:Предприятие  уже имеет определенную структуру – это справочники, документы, журналы, регистры и др. и связи между ними, соблюдены требования целостности данных. В 1С не нужно заботиться о целостности данных, это берет на себя сама система.
  2. Предотвращения дублирования информации хранящейся в справочниках.
  3. Взаимосвязь 1С:Предприятия с системой «Клиент-Банк», позволяет легко контролировать за платежной дисциплиной контрагентов без дополнительной передачи данных.
  4. Нет необходимости в дополнительном обмене данными, в конвертации данных.
  5. С помощью регистров накоплений и регистров сведений упрощается задача построения запросов по выполнению условий договоров.
  6. В установленной  в организации системе 1С:Предприятие уже разработано разграничение прав доступа для каждого пользователя.
  7. Интерфейс данной системы уже привычен и понятен сотрудникам организации.

3.3 Проектирование SADT-МОДЕЛИ

SADT (акроним от англ. Structured Analysis and Design Technique) — методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Этот процесс хорошо отлажен, потому что при разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь обеспечивает своевременный обмен информацией. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показывается с левой стороны блока, а результаты выхода – с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 3.7) [12]. Общая структура SADT-модели представлена в приложении Ж.

Рисунок 3.7 – Функциональный блок и интерфейсные дуги

Входная информация:

  1. Основные параметры договора (дата заключения – окончания и т.д.);
  2. Справочная информация (заявка на поставку, ответственные лица и т.д.);
  3. Счет-фактура; 
  4. Данные системы «Клиент-банк» (банковское платежное поручение);
  5. Основания для претензий (бракованная продукция, несвоевременная оплата).

Выходная информация:

  1. Договор поставки;
  2. Товарная накладная;
  3. Претензии;
  4. Отчеты о выполнении договора.

Механизм:

  1. Менеджер-экономист.

Управляющая информация:

  1. Прайс-лист;
  2. Форс-мажорные обстоятельства.

Декомпозированная диаграмма общей структуры SADT-модели состоит из трех подсистем. Декомпозиция общей структуры SADT-модели представлена в приложении З.

Первая подсистема «Регистрация договора».

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

Вторая подсистема «Регистрация и учет поставок по договору».

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

Третья подсистема «Учет и контроль платежей по договору».

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

3.4 Концептуальная модель  базы данных

Концептуальная модель — модель предметной области, состоящей из перечня взаимосвязанных понятий, используемых для описания этой области, вместе со свойствами и характеристиками, классификацией этих понятий, по типам, ситуациям, признакам в данной области и законов протекания процессов в ней [2].

3.4.1 ER-диаграмма

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

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

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

3.4.2 KB-диаграмма

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

3.4.3 FA-диаграмма

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

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

  • Различаются зависимые и независимые сущности, а также идентифицирующие/неидентифицирующие и обязательные/необязательные соединения.
  • Неспецифические соединения запрещены.

Информация о работе Отчет по практике в ООО «Антик»