Тема: ИНФОРМАЦИОННАЯ СИСТЕМА ОБЕСПЕЧЕНИЯ УПРАВЛЕНИЯ В ПРЕДПРИЯТИИ «ЗОЛОТОЙ ВЕК»

• Вид работы:
  Дипломная (ВКР) по теме: ИНФОРМАЦИОННАЯ СИСТЕМА ОБЕСПЕЧЕНИЯ УПРАВЛЕНИЯ В ПРЕДПРИЯТИИ «ЗОЛОТОЙ ВЕК»
• Предмет:
  Информационное обеспечение, программирование
• Когда добавили:
  18.06.2014 15:14:16
• Тип файлов:
  MS WORD
• Проверка на вирусы:
  Проверено - Антивирус Касперского

Другие экслюзивные материалы по теме

• Полный текст:
  Содержание  
  Введение. 5
  1 Постановка задачи. 7
  1.1 Анализ предметной области. 7
  1.2 Анализ используемых программных средств. 9
  1.3 Анализ информационных потоков предметной области. 14
  1.4 Круг задач, подлежащих автоматизации. 16
  2 Проектирование информационной системы.. 18
  2.1 Разработка функциональной модели системы в нотации IDF0. 18
  2.2 Этапы проектирования базы данных. 24
  3 Разработка информационной системы.. 26
  3.1 Инфологическое проектирование. 26
  3.2 Даталогическая модель системы.. 29
  2.3 Физическая модель данных. 33
  4. Разработка программного обеспечения. 42
  4.1 Выбор средств реализации информационной системы.. 42
  4.2 Структура программных средств. 51
  4.3 Разработка пользовательского интерфейса. 66
  4.4 Руководство пользователя. 67
  4.5 Руководство программиста. 71
  Заключение. 75
  Список используемых источников. 76
  Приложение А. Схема базы данных. 78
  Приложение Б. Описание таблиц. 79
  Приложение В. Тексты SQL-запросов. 85
  Приложение Г. Тексты макросов. 91
  Приложение Д. Экранные формы.. 103
  Приложение Е. Макеты представления исходящей информации. 106
  Введение  
  Потоки информации в мире, который нас окружает, огромны. Во времени они имеют тенденцию к увеличению. Поэтому в любой организации, как большой, так и маленькой, возникает проблема организации управления данными, которая обеспечила бы наиболее эффективную работу. Некоторые организации используют для этого шкафы с папками, но большинство предпочитают компьютеризированные способы – базы данных, позволяющие эффективно хранить, структурировать и систематизировать большие объемы данных. И уже сегодня без баз данных  невозможно представить работу большинства финансовых, промышленных, торговых и прочих организаций.
  Существует много веских причин перевода существующей информации на компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле, чем на бумаге. Базы данных позволяют хранить, структурировать информацию и извлекать оптимальным для пользователя образом. Кроме того ЭВМ позволяет хранить любые форматы данных, текст, чертежи, данные в рукописной форме, фотографии, записи голоса и т.д.
  Для использования столь огромных объемов хранимой информации, помимо развития системных устройств, средств передачи данных, памяти, необходимы средства обеспечения диалога человек - ЭВМ, которые позволяют пользователю вводить запросы, читать файлы, модифицировать хранимые данные, добавлять новые данные или принимать решения на основании хранимых данных. Для обеспечения этих функций созданы специализированные средства – системы управления базами данных (СУБД). Современные СУБД - многопользовательские системы управления базой данных, которые специализируется на управлении массивом информации одним или множеством одновременно работающих пользователей.
  Одним из первых примеров подобного системного применения ЭВМ в мировой практике были так называемые административные системы обработки данных: автоматизация банковских операций, бухгалтерского учета, резервирования и оформления билетов и т.п. Решающее значение для эффективности систем подобного рода имеет то обстоятельство, что они опираются на автоматизированные информационные базы. Это означает, что в памяти ЭВМ постоянно сохраняется информация, нужная для решения тех задач, на которые рассчитана система. Хранение информации в памяти ЭВМ придает этой информации принципиально новое качество динамичности, то есть, способности к быстрой перестройке и непосредственному ее использованию в решаемых на ЭВМ задачах.
  Для разработки дипломной работы «Информационная система по обеспечению управления в ООО «Золотой век»  была выбрана СУБД MS Access. Работа ООО «Золотой век» связана с накоплением большого количества информации о движении спецтехники и запасных частей к ней. Традиционно информация в ООО «Золотой век» храниться на бумажных носителях, при этом трудно осуществить быстрый отбор нужных данных по тому или иному экземпляру спецтехники, отследить остатки запасных частей по номенклатуре и количеству. Это является одной из причин внедрения программы на рабочее место менеджера по координации работы подразделений организации, и для успешного достижения ее, при разработке программного продукта был использован MS Access как СУБД и SQL как стандартный язык базы данных.
  Сейчас на рынке программного обеспечения появляются все больше и больше программных средств автоматизированных рабочих мест. Стандартной программой для ведения учета товаров на предприятиях обычно является 1С: Предприятие, конфигурация: Склад или СБИС++ (от компании «Тензор»). Но работать с этими программами могут только специально обученные пользователи - люди со специальным бухгалтерским образованием, которые обучены работать с бухгалтерским программным обеспечением. Из этого следует, что для учета товаров на достаточно небольшом предприятии, где номенклатура используемых активов не доходит до астрономических цифр, разумно создать простое, но в тоже время, отвечающее всем потребностям грамотного учета спецтехники и материальных ценностей приложение, пользоваться которым может любой работник ООО «Золотой век», владеющий компьютером хотя бы на уровне пользователя.
  Целью дипломной работы является разработка информационной системы обеспечения управления, реализующую хранение данных, организацию доступа к ним, ведения справочной информации о спецтехнике, запасных частях и контрагентах, редактирования и удаления входящей и исходящей информации, отвечающей всем требованиям представленным ООО «Золотой век».
  Результатом работы является программа «ООО «Золотой век», которая будет использоваться на рабочем менеджера по координации работы подразделений организации.
  В данной работе представлены результаты анализа деятельности и информационного обмена в ООО «Золотой век» (анализ предметной области), выявлены недостатки, разработана информационная система, инструкция ее пользователя и экономически обосновано ее внедрение.
  Таким образом, автоматизация процесса работы руководства ООО «Золотой век» является перспективной разработкой.
  1 Постановка задачи  
  1.1 Анализ предметной области  
  ООО «Золотой Век» осуществляет свою деятельность с 1999 г. Данная организация работает на рынке услуг фронтальных телескопических погрузчиков «JCB» и гусеничных экскаваторов «JCB» в Московском регионе России.
  Шаг за шагом в течение этих лет предприятие развивалось - расширялся и обновлялся парк техники, осваивались новые сферы деятельности, формировался сплоченный коллектив профессиональных и дисциплинированных водителей и технических работников.
  Предприятие располагает собственной техникой. За техническим состоянием транспорта следят высококвалифицированные инженеры, механики, слесари, а управляют техникой опытные машинисты, профессионалы своего дела, хорошо знающие особенности транспортного сообщения г. Москвы и Московской области.
  Для осуществления стратегического и оперативного управления в ООО «Золотой век» была создана собственная структура управления (рисунок 1).
   
   
   
   
   
   
   
   
   
   
  Рисунок 1 – Организационная структура управления ООО «Золотой век»
   
  Организационная структура управления названных отделов ООО «Золотой век» представлена на рисунках 2-3.
  Как видно на рисунке 2, в сервисном отделе рассматриваемой организации осуществляется полный цикл обслуживающих и ремонтных работ. При этом, отдел структурирован по функциональному типу: в зависимости от вида выполняемых работ. Руководство каждым видом выполняемых работ осуществляется руководителями нижнего звена:
  - мастером электротехнических работ;
  - мастером кузовных работ;
  - старшим мотористом;
  - мастером по ходовому и топливному оборудованию.
  
     
   
   
   
   
   
   
   
   
   
   
   
   
   
  Рисунок 2 – Организационная структура сервисного отдела ООО «Золотой век»
   
  В обязанности этих руководителей, помимо технологических вопросов, входит координация материального, технического, методического и нормативного обеспечения деятельности соответствующих участков производства работ.
  В это обеспечение входит:
  - обеспечение запасными частями и материалами, используемыми в обслуживании спецтехники и для ее ремонтов;
  - обеспечение методической литературой и материалами по проведению обслуживающих и ремонтных работ, рекомендованными производителями спецтехники;
  - обеспечение нормативно-технической документацией проводимых обслуживания и ремонтных работ, предоставляемой производителями спецтехники, издаваемой государственными органами исполнительной власти и т.п.
  Информационный обмен между участками данного отдела осуществляется по горизонтальным информационным связям между руководителями соответствующих участков. Информационный обмен между отделами ООО «Золотой век» и сервисным отделом осуществляется руководителями соответствующих участков по вертикальной информационной связи через старшего мастера сервисного отдела.
  
     
   
   
   
   
   
   
   
   
  Рисунок 3 – Организационная структура управления складом ООО «Золотой век»
   
  Как видно на рисунке 3, общее руководство складом и информационным обменом между складом и другими отделами ООО «Золотой век» осуществляется по вертикальной информационной связи через заведующего складом. При этом, в комплекс всей передаваемой через него информации входит информация о:
  - потребности (количестве и стоимости) в запасных частях и материалах;
  - наличии (количестве и стоимости) запасных частей и материалов;
  - существующих поставщиках запасных частей и материалов (номенклатуре и альтернативной стоимости);
  - затратах на снабжение и складское хранение запасных частей и материалов.
  Информационный обмен по оперативному управлению внутри складского хозяйства ООО «Золотой век» осуществляется между работниками с координационным участием заведующего складом.
  Для более полного понимания технологии информационного обмена в сервисном отделе и на складе ООО «Золотой век» целесообразно произвести анализ существующей информационной системы рассматриваемой организации.
   
  1.2 Анализ используемых программных средств  
  Для обеспечения эффективного управления активами коммерческой организации необходимым условием является наличие оперативной и достоверной информации и состоянии и движении данных активов. Эта задача решается многими существующими в настоящее время средствами автоматизации учетной и управленческой деятельности. В частности, в ООО «Новый век» эксплуатируется автоматизированная система сопровождения бухгалтерского учета, разработанная фирмой «1С» - «1С: Предприятие» версии 7.7. Переход на более позднюю версию 8.1 был признан нецелесообразным, поскольку при прочей достаточной для ООО «Новый век» функциональности, равной возможностям версии 7.7, поздняя версия является более требовательна к аппаратным ресурсам. Кроме того, для перехода на позднюю версию необходимо дополнительное обучение бухгалтерии, что повлекло бы за собой неоправданное увеличение расходов.
  Конфигурация названного программного продукта, используемого в ООО «Золотой век» представляет собой типовое решение для автоматизации средних и малых предприятий, основными видами деятельности которых, является оказание услуг или оптовая торговля.
  Оперативный учет ведется с высокой степенью детализации и автоматизации учетных процессов.
  Производство с участием специальной техники ООО «Золотой век»:
  - ведение нормативов затрат на единицу и составление плановой калькуляции производимых работ;
  - нормирование затрат на производство включает в себя материальные затраты, возвратные отходы, полуфабрикаты, технологические операции, услуги сторонних организаций и косвенные затраты (общепроизводственные, общехозяйственные и другие);
  - разузлование сложных сметных работ;
  - дерево нормативных затрат;
  - произвольное количество спецификаций затрат для одного вида работ;
  - планирование объемов производства работ и контроль исполнения планов;
  - автоматический расчет фактической себестоимости произведенных работ по итогам месяца;
  - сравнение фактической и плановой себестоимости;
  - учет производственных затрат по местам возникновения, видам работ и видам затрат;
  - автоматический расчет остатков незавершенного производства (с возможностью ручной корректировки);
  - начисление зарплаты по индивидуальным и бригадным нарядам;
  - учет выполненных работ и оказанных услуг.
  Расчеты с контрагентами:
  - учет передачи специальной техники в аренду, реализации производимых собственными силами работ;
  - гибкий механизм ценообразования;
  - учет взаиморасчетов в разрезе договоров, а также отдельных поставок и оплат;
  - учет заявок на аренду специальной техники клиентам и контроль исполнения;
  - формирование заказов поставщикам и контроль поставок;
  - гибкая система отслеживания взаиморасчетов и зачета авансов;
  - проведение взаимозачетов;
  - детальные аналитические отчеты по взаиморасчетам.
  Складской учет
  - учет складских запасов и движения материальных ценностей;
  - партионный учет стоимости материальных ценностей, списание по методам LIFO, FIFO, «по средней».
  Как можно видеть из приведенного перечня функциональных возможностей используемой системы автоматизации учета в ООО «Золотой век», данная система в полной мере отвечает потребностям организации в части учетной работы, то есть:
  - фиксируется стоимостные и количественные показатели;
  - определяет фактическое наличие материальных ценностей;
  - контролирует исполнение управленческих решения в части использования материальных ценностей.
  Однако, для эффективного управления активами ООО «Золотой век» данного функционала недостаточно. Управленческие решения в данной организации принимаются не на основе статистических данных, а на основе аналитических данных, получаемых с помощью методов экономического анализа хозяйственной деятельности организации. В частности, такие данные включаю в себя:
  - определение норм запасов материальных ценностей в количественном, ценовом и временном измерении;
  - определение эффективности использования специальной техники, передаваемой в аренду, или же специальной техники, с использованием которой производятся работы силами ООО «Золотой век».
  Автоматизированная система от «1С» на позволяет получать названные типы данных и не удовлетворяет потребности руководства организации в соответствующих возможностях автоматизации экономико-аналитических вычислений.
  Другим средством автоматизации управления в ООО «Золотой век» является программный комплекс, произведенный ООО «Софтинком» - «Оборотный склад запасных частей. Версия 3.0», и предназначенный для автоматизации оформления складских документов.
  Как уже отмечалось, из заявок сервисного отдела ООО «Золотой век» вручную формируются заказы на запасные части на склад. С поставщиками заказы согласовываются по количеству и срокам.
  После отправки со склада поставщика запасные части переходят в последнее состояние системы. И завершается цепочка приходом запасных частей и агрегатов, с формированием приходных документов в складской программе, где идет прием и распределение запасных частей и агрегатов на складе.
  На каждом этапе возможна коррекция заказа (не нарушающая общей логики). В этом случае информация показывается с разбивкой по движению каждой единицы агрегатов или узлов специальной техники или же каждой транспортной единицы мелкосортных запасных частей.
  Следовательно, при наличии первоначальной заявки сервисного отдела ООО «Золотой век», связь с ней отслеживается до прихода запасной части.
  На заключительном этапе работы в складской программе можно создавать приходную накладная от конкретного поставщика (или несколько накладных, если в посылке соединены несколько инвойсов). При наличии первоначальной заявки сервисного отдела происходит резервирование доставленной запасной части под этот отдел.
  Кроме этого заведующий складом всегда имеет возможность отслеживать запасные части, находящиеся на различных этапах, а также видеть «Запасные части в пути», то есть, планируемые даты доставки конкретных партий запасных частей, что дает возможность поддержки принятия обоснованных управленческих решений на основе актуальных данных. И четкое информирование сервисного отдела о состоянии его заказа.
  Приемка начинается с получения извещения о прибытии запасных частей и агрегатов. Запасные части разгружаются и оставляются для размещения на складе. Он сканируется и инспектируется по количеству и качеству. На основании сравнения данных по приходу и документов от поставщика создается Акт приема груза (с недостачами и переизбытками, если они есть).
  Размещение на складе начинается с определения подходящего места хранения, которое свободно.
  При размещении запасных частей место хранения подлежит сканированию для записи его в базу.
  Распределение может осуществляться следующими способами:
  - автоматически с помощью алгоритма;
  - вручную специалистом по логистике складского хозяйства ООО «Золотой век».
  На основании распределения создается «Распоряжение на размещение», которое передается бригадирам бригад грузчиков склада для исполнения.
  Обработка заказов сервисного отдела осуществляется в разрезе сравнения заказов с наличием на складе, составление листа отбора запасных частей и формирование передаточных документов.
  Возможности названной выше системы управления складом, помимо контроля за перемещением материальных ценностей, позволять специалисту по складской логистике ООО «Золотой век» в ручном и автоматическом режиме (с помощью алгоритма) распределять заявки (наряды) на комплектацию заказов по зонам склада и по бригадирам бригад грузчиков - для выполнения; заведующему склада - отслеживать прохождение комплектации заявок (нарядов), контролировать время выполнения и качество работ по комплектации заказов на передачу в сервисный отдел организации.
  Список состояний заявок (нарядов) на подбор заказов позволяет отслеживать действия специалиста по складской логистике и бригадиров бригад грузчиков, а также состояние документов перемещения материальных ценностей внутри и вне склада.
  Таким образом, в ООО «Золотой век» система «Оборотный склад запасных частей» позволяет решать следующие задачи:
  - полная автоматизация контроля поставок;
  - полная автоматизация контроля потребности сервисного отдела в запасных частях и материалах;
  - предоставление руководству ООО «Золотой век» надежной и своевременной информации для планирования расширения складского снабжения;
  - снабжение рыночной информацией в реальном времени, которое обеспечивает быстрое и точное реагирование на изменение рыночных условий.
  Вместе с тем, как и в случае с программной «1С: Предприятие», используемая система автоматизации складской работы не позволяет получить аналитические данные для принятия экономически обоснованных и эффективных управленческих решений в сфере движения материальных ценностей, используемых ООО «Золотой век» для обеспечения бесперебойной эксплуатации специальной техники данной организации.
  В частности, система не позволяет автоматически получать информацию о:
  - размере оптимального заказа, с учетом нормативных сроков службы, срока фактической поставки запасных частей и материалов;
  - затратоемкости хранения различных видов запасных частей и материалов;
  - тенденциях в изменении спроса на запасные части и материалы со стороны сервисного отдела ООО «Золотой век».
  Таким образом, можно констатировать, что в ООО «Золотой век» применяются эффективные, но узкоспециализированные комплексы автоматизации управления деятельности организацией, в частности:
  - нацеленные на реализацию учетной и контрольной функций менеджмента аренды специальной техники;
  - нацеленные на реализацию учетной и контрольной функций менеджмента материального снабжения сервисного отдела ООО «Золотой век».
   
  1.3 Анализ информационных потоков предметной области  
  Информационные потоки предметной области показаны на рисунке 4.
   
  
     
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
  Рисунок 4 – Информационные потоки внутренней и внешней среды ООО «Золотой век»
   
  Как видно на рисунке 4, всю совокупность информационных потоков ООО «Золотой век» можно условно разделить на две группы:
  - внешние информационные потоки;
  - внутренние информационные потоки.
  Информационный обмен с внешними пользователями и поставщиками информации осуществляется с:
  - клиентами;
  - поставщиками техники и запчастей;
  - собственниками организации;
  - нормативными и контролирующими органами.
  Внутренние информационные потоки связаны с координацией деятельности подразделений ООО «Золотой век».
  Внешние поставщики информации обеспечивают информационный обмен по:
  - нормативной, технической и иной информации;
  - составе и объеме потребности на рынке аренды спецтехники от клиентов;
  - составе и объеме наличия техники и запасных частей на рынке от поставщиков;
  - объеме потребности в эффективности деятельности организации от собственников.
  Внешние же поставщики информации являются и ее потребителями:
  - контролирующие органы получают отчетность организации, содержащую сведения о соответствии фактических параметров состояния системы нормируемым параметрам;
  - собственники получают информацию об уровне своего дохода, достигнутого деятельностью организации;
  - клиенты получают информацию о возможности удовлетворения их спроса на технику силами ООО «Золотой век» и условиях арендных договоров;
  - поставщики техники и запчастей получают информацию о потребности ООО «Золотой век» в технике и запчастях.
  Внутри системы происходит обмен следующими видами информации:
  - о потребностях в ремонтах спецтехники;
  - о фактической степени готовности переданной в ремонт техники;
  - о потребности в запасных частях;
  - о фактическом уровне укомплектованности склада запасными частями.
  Таким образом, анализ среды внедрения системы автоматизации управления объектами основных средств ООО «Золотой век», передаваемыми в аренду третьим лицам, позволил выявить следующее:
  - деятельность данной организации по передаче в аренду объектов основных средств является в высокой степени динамичной;
  - существующая организационная структура управления в полной мере обеспечивает потребности ООО «Золотой век» по обеспечению и контролю качества реализуемых на рынке спецтехники арендных услуг;
  - в информационной системе управления арендными услугами отсутствует функциональная информация об эффективности аренды;
  - отсутствуют аналитические источники (бухгалтерский учет не в полной мере позволяет получать необходимую информацию) о факторах, оказывающих влияние на эффективность использования передаваемых в аренду объектов основных средств;
  - отсутствуют аналитические источники (бухгалтерский учет не в полной мере позволяет получать необходимую информацию) о факторах, оказывающих влияние на формирование расходов, связанных с содержанием и эксплуатацией объектов основных средств, передаваемых в аренду.
  - отсутствует система обработки информации об эффективности аренды объектов основных средств.
   
  1.4 Круг задач, подлежащих автоматизации  
  Анализ существующих недостатков в информационном обеспечении управления основными средствами, передаваемыми ООО «Золотой век» в аренду и материальном обеспечении бесперебойного функционирования этих основных средств, позволяет констатировать наличие потребности данной организации в совершенствовании сложившейся информационной системы управления.
  Основным направлением совершенствования, исходя из результатов анализа, является обеспечение автоматизации процесса выработки аналитической информации, характеризующей хозяйственную деятельность ООО «Золотой век» в следующих сферах:
  - реализации арендных услуг;
  - материальном обеспечении бесперебойного функционирования специальной техники, передаваемой ООО «Золотой век» в аренду сторонним организациям (контрагентам).
  Круг необходимой аналитической информации, автоматизация получения которой необходима, может быть очерчен следующим перечнем:
  1. В сфере реализации арендных услуг:
  - расчет коэффициентов рентабельности в разрезе по клиентам и видам передаваемой в аренду специальной техники;
  - расчет коэффициентов материалоемкости эксплуатации специальной техники в размере по видам специальной техники и контрагентам;
  - расчет коэффициентов затратоемкости эксплуатации специальной техники в размере по видам специальной техники и контрагентам;
  - расчет фактического наличия специальной техники в эксплуатации и в простое;
  - расчет уровня износа специальной техники в разрезе ее видов.
  2. В сфере материального обеспечения эксплуатации специальной техники (складской работы):
  - расчет нормативных остатков запасных частей и материалов на складе;
  - расчет оптимального объема заказов запасных частей и материалов у поставщиков;
  - учет фактического наличия запасных частей и материалов на складе, учет их поступления и передачи в сервисный отдел ООО «Золотой век».
  Кроме того, автоматизированная система, способствующая реализации управленческих функций по названным сферам, должна обеспечивать следующие потребности:
  - гибкость, с целью последующих изменений автоматизированной системы;
  - простота эксплуатации автоматизированной системы;
  - невысокая требовательность автоматизированной системы к аппаратным ресурсам;
  - простота и сжатые сроки обучения персонала работе с автоматизированной системой;
  - простота и сжатые сроки обучения персонала возможной модификации автоматизированной системы.
  Задание на проектирование, применительно к потребностям ООО «Золотой век», можно сформулировать следующим образом:
  «Требуется разработать автоматизированную систему сопровождения управления активами ООО «Золотой век» с использованием системы управления базами данных Microsoft Access, реализующие следующие функции:
  - расчет аналитических коэффициентов эффективности использования специальной техники, передаваемой в аренду сторонним заказчикам;
  - расчет аналитических коэффициентов эффективности использования специальной техники, задействованной в строительных работах, выполняемых силами ООО «Золотой век»;
  - учет наличия и движения специальной техники;
  - расчет оптимального объема заказа запасных частей и материалов;
  - учет наличия и движения запасных частей и материалов на складе и в пути.
  Автоматизированная система должна обеспечивать возможность:
  - ввода статистических данных;
  - обработки статистических и аналитических данных;
  - визуального представления статистических и аналитических данных».
  2 Проектирование информационной системы  
  2.1 Разработка функциональной модели системы в нотации IDF0  
  В целом, функционально совокупную систему ООО «Золотой век» можно разделить на два сегмента: арендный и сервисный.
  В общем виде, информационные процессы, реализуемые в деятельности сервисного отдела ООО «Золотой век» представлены на рисунке 5 и включают в себя:
  - получение заказов от производственного отдела;
  - руководство нормативно-технической документацией;
  - использование материально-технических, трудовых и финансовых ресурсов;
  - передачу выполненных работ производственному отделу.
  На рисунке 5 видно, что поступающая одновременно с заказом на ремонт техника подвергается диагностике с целью выявления неисправностей. При этом, на основе нормативно-технической документации осуществляется внешний осмотр и тестирование, при котором идентифицируются неисправности. Составленный перечень идентифицированных неисправностей является базой для составления задания на ремонт в виде акта осмотра спецтехники.
  На следующем этапе осуществляется планирование предстоящего ремонта, на котором по данным акта осмотра проводится анализ возможных способов и методов ремонта, согласно технической документации производителя спецтехники и разрабатывается ремонтная карта для, непосредственно, ремонтных участков с указанием видов и характеристик ремонтных работ.
  Для проведения ремонтных работ на основе ремонтной карты формируются бригады, руководствуясь нормами трудоемкости, осуществляется комплектация необходимыми запасными частями и материалами, согласно нормам материалоемкости и производится, непосредственно, ремонт спецтехники. По окончании ремонтных работ осуществляется контроль качества и объема их выполнения. При этом, осуществляется аналитическое сравнение заявки на ремонт спецтехники, разработанной ремонтной карты и фактического перечня выполненных работ.
  С использованием разработанных производителем допусков и иных параметров, осуществляется контроль степени соблюдения норм производителя для исправных узлов и агрегатов отдельного экземпляра спецтехники.
  Рисунок 5 – Этапы технологического процесса деятельности сервисного отдела
  Этап контроля осуществляется в присутствии представителя производственного отдела ООО «Золотой век». При соответствии всех требований производителя по характеристикам исправных узлов и агрегатов отдельного экземпляра спецтехники, подписывается акт выполненных работ и данных экземпляр спецтехники передается в эксплуатацию производственному отделу.
  На рисунке 6 представлены технологические процессы, реализуемые на складе ООО «Золотой век».
  Как видно на рисунке 6, технологические операции и информационный обмен в складском хозяйстве ООО «Золотой век» осуществляются в четыре этапа:
  - формирование заявок на снабжение;
  - поставка запасных частей и материалов, контроль их комплектности и качества;
  - складирование поступивших запасных частей и материалов на складе;
  - позаявочная комплектация и передача комплектов запасных частей и материалов в сервисный отдел.
  При этом, используются:
  - нормативная, техническая и иная руководящая документация;
  - складские материальные ценности;
  - трудовые ресурсы;
  - финансовые ресурсы (денежные средства);
  - материальные ресурсы (оборудование складского хозяйства).
  На этапе формирования заявок на снабжения осуществляется сбор, сортировка и группировка заявок по запасным частям, материалам, поставщикам. Производится выборка поставщиков и заключение соответствующих договоров на поставку. Одновременно контролируется полнота номенклатуры и количества запасных частей и материалов по заключенным договорам номенклатуре и количеству заказанных запасных частей и материалов.
  На этапе поставки и контроля качества осуществляется оценка соответствия договорным условиям:
  - количества поставленных запасных частей и материалов;
  - номенклатуры поставленных запасных частей и материалов;
  - соответствия поставленных запасных частей и материалов по качеству.
  В случае отсутствия отклонений поставленных запасных частей и материалов от условий договоров поставки производится принятие поступивших материальных ценностей к учету и их оценка.
  Рисунок 6 – Этапы технологического процесса складского обслуживания
  На этапе складирования определяются оптимальные для размещения складские места, перемещение материальных ценностей на склад и размещение их по выбранным местам.
  В процессе комплектации хранящихся запасных частей на складе осуществляется их позаявочный подбор, подготовка, сортировка, комплектное размещение на складской площади.
  После окончания процедур по созданию полного комплекта запасных частей и материалов, соответствующего каждой конкретной заявке, производится передача запасных частей и материалов в сервисный отдел с одновременным их списанием на себестоимость арендных услуг.
  В процессе осуществления складских технологических операций осуществляется руководство нормативной и правовой документацией, содержащей:
  - нормы площадей хранения;
  - нормы сроков хранения;
  - показатели качества запасных частей и материалов;
  - нормы трудоемкости складского персонала;
  - нормы материалоемкости складских технологических работ и т.д.
   
  2.2 Этапы проектирования базы данных  
  Основная цель проектирования БД заключается в том, чтобы обеспечить пользователя более точными данными, полностью удовлетворяющими их информационные потребности, за приемлемое время доступа. Для достижения этого необходимо, чтобы элементы БД наиболее полным образом отвечали потребностям пользователей организаций, основанным на их общих целях, внутренней организационной структуре и предполагаемых требованиях доступа к данным, при этом структура БД должна обеспечивать достаточно быстрый доступ к данным. Целью ранних этапов проектирования является разработка гибкой структуры БД, адаптируемой к изменениям пользовательской среды.
  Методология поэтапного проектирования БД может быть определена как построение структуры БД на основе множества информационных и процедурных требований пользователей. 
  Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, создаем обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных.
  Такая человек-ориентированная модель полностью независима от физических параметров среды хранения данных. Этой средой может быть и память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
  Остальные модели являются компьютерно ориентированными. С их помощью СУБД  дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
  Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое по инфологической модели данных, называют даталогической моделью данных.
  Сущность инфологического подхода к проектированию информационных систем заключается в установлении соответствия между состоянием ПО, его восприятием и представлением в БД. Согласно инфологическому подходу при проектировании необходимо различать:
  - явления реального мира;
  - информацию об этих явлениях;
  - представление этой информации посредством данных.
  В соответствии с этим в инфологическом подходе выделены три сферы:  
  - реальный мир или объектная система;
  - информационная система;
  - даталогическая сфера.
  Выделение этих сфер  и определяет содержание основных этапов инфологического проектирования.
  3 Разработка информационной системы  
  3.1 Инфологическое проектирование  
  Стандартным способом представления концептуальной модели базы данных являются диаграммы «сущность-связь» (ERD), предназначенные для определения данных и отношений между ними.
  Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
  Модель «сущность-связь» – неформальная модель предметной области, используемая на этапе концептуального проектирования. Лёгкость понимания и использование естественного языка позволяют её применять как инструмент общения с конечными пользователями для сбора информации в предметной области. Эта модель и нотация ERD была предложена П. Ченом в 1976 г. В дальнейшем она получила развитие в работах других авторов. Основное назначение ERD – семантическое описание предметной области и представление информации для обоснования выбора видов моделей и структур данных с целью использования на этапе логического проектирования.
  Описание предметной области включает существующие в ней объекты, их свойства и отношения. Соответственно модель сущность-связь строится с использованием трёх конструктивных элементов: сущность, атрибут и связь.
  Сущность (Entity) - это некоторая абстракция (модель) реально существующего либо воображаемого объекта, процесса или явления, имеющего существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. С сущностью связаны понятия: тип – набор однородных предметов, явлений, выступающий как единое целое, и экземпляр – конкретный элемент набора, определяющего некоторый тип. Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности.
  Различают сущности независимые, зависимые и ассоциированные. Независимая сущность представляет данные, которые всегда присутствуют в системе. Зависимая сущность представляет данные, зависящие от других сущностей в системе. Для существования зависимой сущности необходимо наличие сущностей, от которых она зависит. Ассоциированная сущность представляет данные, которые связаны с отношением между сущностями.
  Атрибут (attribute) – это поименованная характеристика сущности, являющаяся средством для описания её свойств, значимых для рассматриваемой предметной области (т.е. средством для моделирования свойств объекта). Атрибут предназначен для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности
  Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов. Экземпляр атрибута - это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и её значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута. Атрибут может быть одинаковым для различных сущностей, но для конкретного типа сущности все атрибуты должны быть различны. Атрибут может быть либо обязательным, либо необязательным. Обязательность означает, что атрибут не может принимать неопределённых значений.
  Связь (Relationship)- средство для представления отношений между сущностями, значимых для рассматриваемой предметной области. Каждая сущность может обладать любым количеством связей с другими сущностями модели. Семантически отношения могут объединять любое количество сущностей, но в ERD-модели используются только бинарные связи.
  Бинарные связи классифицируют по типу отношения между экземплярами сущностей следующим образом:
  - связь один-к-одному (1:1): каждому экземпляру сущности А соответствует один экземпляр сущности В и наоборот;
  - связь один-ко-многим (1:М): одному экземпляру сущности А соответствует несколько экземпляров сущности В, и каждому экземпляру сущности В соответствует один экземпляр сущности А;
  - связь многие-к-одному (М:1): обратная по отношению к связи один-ко-многим;
  - связь многие-ко-многим (М:N): каждому экземпляру сущности А соответствует несколько экземпляров сущности В и наоборот.
  Вся структура информационной системы ООО «Золотой век», для удобства описания, может быть условно разделена на два сегмента:
  - сегмент, обслуживающий потребности в информационном обеспечении управления процессом аренды (арендный сегмент);
  - сегмент, обслуживающий потребности в информационном обеспечении управления процессом сервисного обслуживания, ремонта и материального снабжения (сервисный сегмент).
  С точки зрения инфологической модели разрабатываемой системы, в ООО «Золотой век» можно выделить следующие сущности:
  - типы техники;
  - модели техники;
  - экземпляры техники;
  - поставщики техники и запасных частей;
  - арендатора техники;
  - технические системы транспортных средств;
  - запасные части;
  - процесс поставки техники;
  - процесс аренды техники;
  - процесс заказа запасных частей сервисным отделом на склад;
  - процесс поставки запасных частей на склад;
  - процесс передачи запасных частей со склада в сервисный отдел.
  Инфологическая модель арендного сегмента информационной системы выглядит следующим образом:
  1. Экземпляры спецтехники (сущность), помимо индивидуальных характеристик (атрибутов), обладают общими характеристиками (атрибутами):
  - принадлежат определенному типу техники;
  - являются определенной моделью техники;
  - поставлены определенным поставщиком.
  2. Каждый договор аренды (сущность) включает в себя следующие характеристики (атрибуты):
  - передачу определенного экземпляра техники, определенного типа и модели, поставленного определенным поставщиком;
  - договор заключен с определенным арендатором.
  3. Каждый заказ-наряд на ремонт техники (сущность) обладает следующими характеристиками (атрибутами: в ремонт передается определенный экземпляр техники, определенного типа и модели, поставленный определенным поставщиком.
  Бинарные связи, таким образом, существуют между сущностями и осуществляются с участием атрибутов.
  Инфологическая модель сервисного сегмента информационной системы выглядит следующим образом:
  1. Запчасти (сущность) соответствуют атрибуты:
  - собственное наименование;
  - принадлежность к определенной системе транспортного средства.
  2. Заказ запчастей (сущность) имеет следующие атрибуты:
  - осуществляется в отношении определенной запчасти, принадлежащей определенной системе;
  - предназначен для определенного экземпляра техники;
  - поставляется определенным поставщиком.
  3. Поставка запчастей (сущность) имеет следующие атрибуты:
  - осуществляется в отношении определенной запчасти, принадлежащей определенной системе транспортного средства;
  - предназначена для определенного экземпляра техники;
  - поставляется определенным поставщиком;
  - осуществляется в соответствии с определенным заказом.
  4. Передача запчастей (сущность) имеет следующие атрибуты:
  - осуществляется в отношении определенной запчасти, принадлежащей определенной системе транспортного средства;
  - предназначена для определенного экземпляра техники;
  - осуществляется после поставки определенным поставщиком;
  - происходит в соответствии с определенным заказом.
  5. В ремонт оправляется:
  - определенный экземпляр техники;
  - поставленный определенным поставщиком.
  Связь между сущностями осуществляется посредством атрибутов родительских сущностей.
   
  3.2 Даталогическая модель системы  
  Каждой из этих сущностей в разработанной информационной системе соответствует индивидуальная таблица базы данных.
  Концептуальная модель информационной системы в арендном сегменте представлена на рисунке 7.
  Рисунок 7 – Концептуальная модель арендного сегмента информационной системы
  Как можно видеть на рисунке 6, арендный сегмент информационной системы состоит из семи таблиц, каждая из которых соответствует своей сущности. При этом, сущности арендного сегмента можно разделить на три типа:
  - родительские;
  - родительские и зависимые;
  - зависимые.
  Родительскими сущностями являются: «типы»; «поставщики» и «арендаторы».
  Только зависимой сущностью являются «ремонты».
  Сущность «модели» является зависимой от сущности «типы» и родительской, по отношению к сущностям: «ос1», «аренда» и «ремонты». Связь между сущностями «типы» и модели» осуществляется первичным ключом сущности «типы» - «код типа», который является внешним для сущности «модели».
  Сущность «ос1», как уже отмечалось, является зависимой от сущностей «типы» и «модели» и содержит в себе два внешних ключа, соответствующих данным сущностям. Кроме того, сущность «ос1» является зависимой от сущности «поставщики» и, также, содержит в себе внешний ключ данной сущности. Сущность «ос1» является, так же, родительской, по отношению к сущностям «аренда» и «ремонты», которые содержат в себе внешний ключи от «ос1».
  Сущности «ремонты», помимо внешний ключей сущностей «типы», «модели» и «ос1», принадлежат внешние ключи сущности «поставщики».
  Сущность «арендаторы является родительской для сущности «аренда». Кроме того, сущность «аренда» включает в себя внешние ключи сущностей «типы», «поставщики», «модели», «ос1».
  Концептуальная модель информационной системы сервисного сегмента представлена на рисунке 8.
  Как можно видеть на рисунке 8, сервисный сегмент информационной системы состоит из восьми таблиц, каждая из которых представляет свою сущность. При этом, как и в арендном сегменте, сущности сервисного сегмента можно разделить на три типа:
  - только родительские или только зависимые;
  - родительские и зависимые.
  Только родительскими являются сущности: «системы» и «поставщики». Только зависимой является сущность «ремонты». Сущности: «запчасти», «заказы запчастей», «поставки» и «передача запчастей» являются и зависимыми от иных сущности и выступают родителями других сущностей.
  Рисунок 8 – Концептуальная модель сервисного сегмента информационной системы
  Так, сущность «запчасти» выступает в качестве родительской для сущностей: «заказы запчастей», «поставки» и «передача запчастей». Она же является зависимой от сущности «системы».
  Сущность «заказы запчастей» зависима от сущностей: «системы», «запчасти» и «ос1», в то же время, являясь родительской, по отношению к сущностям: «поставки» и «передача запчастей».
  Сущность «поставки» формируется и зависит от сущностей: «системы», «запчасти», «заказы запчастей», «ос1» и «поставщики».
  Она же является родительской для сущности «передача запчастей».
  Сущность «передача запчастей» является зависимой от сущностей: «заказы запчастей» и «поставки».
   
  2.3 Физическая модель данных  
  Физическая модель информационной системы, разработанной для ООО «Золотой век» описана в таблице 1 и показана на рисунках 9-10.
  Таблица 1 – Состав и характеристика полей таблиц, используемых в базе данных
  Наименование поля
  Тип данных
  Ограничения
  Описание
  тбл_аренда (таблица)
  код_аренды
  Текстовый ключевое
  Маска ввода «00-00-0000-0»
  Индекс договора аренды
  арендатор
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «арендаторы», поле «наименование_аренда-тора»
  объект_аренды
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «модель»
  количество
  Числовой
   
  Значение по умолчанию «1»
  стоимость_аренды
  Денежный
   
  Цена договора аренды
  дата_передачи_в_аренду
  Дата/ время
   
  Дата фактической передачи техники в аренду
  дата_окончания_аренды
  Дата/ время
   
  Дата окончания договора аренды
  в_аренде
  Логичес-кий
   
  «Да» - экземпляр передан арендатору; «Нет» - экземпляр не в аренде
  возвращено
  Логичес-кий
   
  «Да» - экземпляр возвращен от арендатора; «Нет» - экземпляр не возвращен от арендатора
  Продолжение таблицы 1
  Наименование поля
  Тип данных
  Ограничения
  Описание
  Тбл_арендаторы (таблица)
  инн_арендатора
  Текстовый (ключевое)
  Маска ввода «0000000000»
  ИНН арендатора, назначается ФСН
  офп_арендатора
  Текстовый
  Маска ввода «LLL»
  Аббревиатура организационно-правовой формы собственности арендатора из трех символов
  наименование_арендатора
  Текстовый
   
  Юридическое наименование арендатора
  адрес_арендатора
  Текстовый
   
  Юридический адрес арендатора
  телефон_арендатора
  Текстовый
  Маска ввода «+7(000)0000000»
  Телефон арендатора в международном формате
  контактное_лицо_арендатора
  Текстовый
   
  Ф.И.О. представителя арендатора
  тбл_заказы_запчастей
  код_заказа
  Текстовый ключевое
  Маска ввода «00-0000-0»
  Шифр накладной-требования
  система
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  код_ос
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «код_ос»
  дата_заказа
  Дата/ время
   
  Дата передачи заказа на склад
  заказано
  Логичес-кий
   
  «Да» - заказ передан; «Нет» - заказ не оформлен»
  поставлено
  Логичес-кий
   
  «Да» - запчасти по заказу поступили на склад; «Нет» - запчасти по заказу не поступили на склад
  передано
  Логичес-кий
   
  «Да» - запчасти по заказу переданы со склада в сервисный отдел; «Нет» - запчасти по заказу не переданы в сервисный отдел
  тбл_запчасти (таблица)
  код_запчасти
  Текстовый ключевое
   
  Артикул запчасти по каталогу производителя
  система
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  Продолжение таблицы 1
  Наименование поля
  Тип данных
  Ограничения
  Описание
  наименование_запчасти
  Текстовый
   
  Наименование запчасти по каталогу производителя
  норма_на_то
  Числовой
   
  Количество запчастей, необходимых на одно ТО, по рекомендациям производителя техники
  тбл_модели (таблица)
  код_модели
  Текстовый ключевое
   
  Соответствует наименованию модели по каталогу производителя
  тип_техники
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  наименование_модели
  Текстовый
   
  Наименование модели, в соответствии с каталогом производителя
  тбл_ос1 (таблица)
  код_ос
  Текстовый ключевое
  Маска ввода «000-0000-0000000000»
  Соответствует VIN-коду в международном формате
  модель
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «модели», поле «наименование_модели»
  поставщик
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «поставщики», поле «наименование_поставщика»
  дата_поставки
  Дата/ время
   
  Дата постановки экземпляра техники на учет
  срок_полезного_использования
  Числовой
   
  Срок полезного использования по нормам бухучета
  срок_фактической_эксплуатации
  Числовой
   
  Срок фактической эксплуатации
  коэффициент_амортизации
  Числовой
   
  Норма амортизации в коэффициентном выражении
  норматив_то
  Числовой
   
  Норма машиночасов, установленная производителем техники в межсервисной эксплуатации (между ТО)
   
   
  Продолжение таблицы 1
  Наименование поля
  Тип данных
  Ограничения
  Описание
  тбл_передача_запчастей
  код_передачи
  Текстовый ключевое
  Маска ввода «0000-00-00»
  Соответствует шифру акта передачи запчастей в сервисный отдел
  заказ_запчастей
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «заказ_запчастей», поле «код_заказа»
  поставка_запчастей
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «поставки», поле «код_поставки»
  дата_передачи
  Дата/ время
   
  Дата фактической передачи запчастей со склада в сервисный отдел
  тбл_поставки (таблица)
  код_поставки
  Текстовый ключевое
  Маска ввода «00-00-0000-00»
  Индекс договора поставки запчастей от поставщика на склад
  заказ_запчастей
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «заказ_запчастей», поле «код_заказа»
  объект_ос
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «код_ос»
  модель
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «модели», поле «наименование_модели»
  система
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  запчасть
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «запчасти», поле «наименование_запчасти»
  поставщик
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «поставщики», поле «наименование_поставщика»
  количество
  Числовой
   
  Количество поставленных запчастей по одному договору
  стоимость_поставки
  Денежный
   
  Цена договора поставки
   
  Продолжение таблицы 1
  Наименование поля
  Тип данных
  Ограничения
  Описание
  дата_поставки
  Дата/ время
   
  Дата фактической поставки запчастей от поставщика на склад
  тбл_поставщики (таблица)
  инн_поставщика
  Текстовый ключевое
  Маска ввода «0000000000»
  ИНН поставщика, назначается ФНС
  офп_поставщика
  Текстовый
  Маска ввода «LLL»
  Аббревиатура организационно-правовой формы собственности поставщика из трех символов
  наименование_поставщика
  Текстовый
   
  Юридическое наименование поставщика
  адрес_поставщика
  Текстовый
   
  Юридический адрес поставщика
  телефон_поставщика
  Текстовый
  Маска ввода «+7(000)0000000»
  Телефон поставщика в международном формате
  контактное_лицо_поставщика
  Текстовый
   
  Ф.И.О. представителя поставщика
  тбл_ремонты (таблица)
  код_ремонта
  Текстовый ключевое
  Маска ввода «00-00-0000-0»
  Шифр ремонтной карты
  ос
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «код_ос»
  дата_постановки_в_ремонт
  Дата/ время
   
  Дата передачи экземпляра техники в ремонт
  дата_окончания_ремонта
  Дата/время
   
  Дата фактической передачи экземпляра техники из сервисного отдела в производственный отдел
  в_ремонте
  Логичес-кий
   
  «Да» - экземпляр техники передан в ремонт; «Нет» - экземпляр техники не передавался в ремонт
  исправлено
  Логичес-кий
   
  «Да» - экземпляр техники передан из сервисного отдела в производственный отдел; «Нет» - экземпляр техники не передан в сервисный отдел или не находится в ремонте
   
   
   
  Продолжение таблицы 1
  Наименование поля
  Тип данных
  Ограничения
  Описание
  тбл_системы (таблица)
  код_системы
  Текстовый ключевое
  Маска ввода «LLLL»
  Аббревиатура технической системы транспортного средства из четырех символов
  наименование_системы
  Текстовый
   
  Полное наименование системы. в соответствии с классификацией производителя
  тбл_типы (таблица)
  код_типа
  Текстовый ключевое
  Маска ввода «0000-00-000»
  Код системы, соответствующий обозначению по каталогу ТН ВЭД РФ
  наименование_типа
  Текстовое
   
  Полное наименование типа техники, в соответствии с классификацией ТН ВЭД РФ
   
   
  Таблицы разработанной для ООО «Золотой век» базы данных выполняют две информационные функции:
  1. Для ввода данных.
  2. Для формирования справочников по:
  - типа техники;
  - моделям техники;
  - экземплярам техники;
  - поставщикам техники и запасных частей;
  - арендаторам техники;
  - техническим системам транспортных средств;
  - запасным частям;
  - фактах поставки техники;
  - фактах заказа запасных частей сервисным отделом на склад;
  - фактах поставки запасных частей на склад.
  Справочная функция таблиц реализована путем формирования соответствующих отчетов (рис. 3.3):
  - отч_арендаторы_спр;
  - отч_заказы_запчастей_спр;
  - отч_запчасти_спр;
   
   
  Рисунок 8 – Схема связей таблиц базы данных арендного сегмента (формат MS Access)
  Рисунок 9 – Схема связей таблиц базы данных сервисного сегмента (формат MS Access)
  - отч_модели_спр;
  - отч_ос1_спр;
  - отч_поставки_спр;
  - отч_поставщики_спр;
  - отч_системы_спр;
  - отч_типы_спр.
  Для обеспечения функциональности информационной системы, в базе данных предусмотрено формирование 39 запросов, доступ к информации которых осуществляется через 16 форм с элементами управления, связанными с 57 макросами.
  4. Разработка программного обеспечения  
  4.1 Выбор средств реализации информационной системы  
  Названные в параграфе 1.4 настоящей работы задачи могут быть решены тремя типами средств автоматизации:
  - специализированные экономико-аналитические программы;
  - электронные таблицы;
  - базы данных с инструментами экономического анализа.
  В качестве примера специализированных экономико-аналатических программ можно назвать программный пакет фирмы «Скип» - «Экономический анализ».
  Пакет программ «Экономический анализ», предоставляя максимальные возможности, не требует настраивания предприятия под программу. Наоборот, в продукте реализовано все, чтобы упростить процесс работы с пакетом. В частности для получения 200 показателей достаточен ввод всего лишь трех форм бухгалтерской отчетности: Баланса (форма №1), Отчета о прибылях и убытках (форма №2) и Отчета о движении денежных средств (форма №4)! Причем, при работе пользователя с такими бухгалтерскими программами как «1С», «Инфо-бухгалтер», «БЭСТ» и «Парус» ввод данных может осуществляться автоматически, с помощью импорта.
  Пакет состоит из двух программ: программы «База Данных» и программы «Анализ». Первая предназначена для ввода данных из финансовой отчетности организации, вторая для их обработки, получения необходимых показателей и работы с ними.
  Пакет программ позволяет осуществлять:
  - анализ финансового отчета по Европейской системе учета;
  - вспомогательные показатели;
  - анализ возможности банкротства;
  - анализ задолженности государства;
  - анализ структуры оборотных средств;
  - анализ имущественного положения;
  - анализ показателей ликвидности;
  - анализ финансовой устойчивости;
  - анализ деловой активности;
  - анализ рентабельности;
  - анализ себестоимости;
  - экономический прогноз;
  - анализ ценных бумаг;
  Пакет программ «Экономический анализ» позволяет осуществлять импорт данных из наиболее распространенных бухгалтерских программ, таких как «Парус», «Инфо-бухгалтер», «1С» и «БЭСТ».
  Кроме того, в пакете программ реализован целый комплекс дополнительных особенностей, облегчающих, но в тоже время углубляющих и расширяющих финансово-экономический анализ, проводимый на предприятии.
  При всем многообразии возможной аналитической информации, получаемой с помощью этого пакета программ, данная программа недостаточно эффективна для управления, с точки зрения внутренних пользователей аналитической информации.
  Во-первых, пакет программ «Экономический анализ» позволяет анализировать только данные итоговых форм финансовой отчетности организации, то есть, он лишен возможности проведения оперативного анализа в середине отчетного периода (например, ежедневного), поскольку его осуществление потребовало бы закрытие счетов бухгалтерского учета для составления соответствующих форм отчетности – что недопустимо, с точки зрения действующего законодательства и может повлечь привлечение должностных лиц организации к ответственности.
  Во-вторых, анализируемые с помощью пакета программ «Экономический анализ» данные являются консолидированными. Поскольку формы бухгалтерской отчетности организаций обладают слабой аналитичностью (они синтетические), получение информации, например, в разрезе видом материальных активов организации с помощью рассматриваемого пакета программ становится невозможным.
  Другую группу средств автоматизации представляют собой электронные таблицы, реализованные, например, в табличном процессоре MS Excel.
  Microsoft Excel является мощным средством, с помощью которого можно создавать и форматировать таблицы, анализировать данные и обмениваться ими с другими пользователями, что позволяет принимать более обоснованные решения. Благодаря интерфейсу, богатым возможностям графического представления данных и сводным таблицам стало проще создавать профессионально оформленные диаграммы и работать с ними. MS Excel в сочетании со службами и технологией, включенной в Microsoft Office SharePoint Server, предоставляет существенно расширенные возможности по обмену данными с повышенным уровнем безопасности.
  Организовав совместную работу с таблицами при помощи MS Excel со службами, можно перемещаться по таблицам, сортировать и фильтровать данные, задавать параметры, а также работать со сводными таблицами непосредственно в веб-обозревателе.
  Средства анализа данных и визуализации помогают выполнять анализ данных, выявлять тенденции, а также облегчают доступ к данным компании.
  Богатый набор схем визуализации позволяет обнаруживать и показывать важные тенденции, а также отмечать исключения в данных с помощью цветных градиентов (изометрические карты), столбцов данных и значков.
  Возможности сортировки и фильтрации, такие как выбор нескольких значений в автофильтрах, сортировка или фильтрация по цвету, а также «быстрые фильтры» для отдельных типов данных, делают MS Excel идеальным средством работы с большими объемами сложных данных.
  Быстрое изменение расположения данных с помощью полей данных облегчает анализ и поиск ответов.
  Реализована полная поддержка служб аналитики Microsoft SQL Server для получения наиболее свежих бизнес-данных. Функции для работы с аналитическими кубами позволяют создавать персональные отчеты на основе базы данных OLAP.
  Вместе с наличием значительного числа преимуществ электронных таблиц, они обладают двумя существеннейшими недостатками:
  1. Проектирование, разработка, гибкость и прозрачность внутренних процессов.
  Электронным таблицам не свойственна гибкость к внесениям изменений в структуру моделей, которые они описывают. Внутренние формулы, записанные в моделях электронных таблиц, не являются динамическими, поэтому, если формула изменена на одной странице, она не будет автоматически скорректирована на всех следующих страницах или в рабочих книгах. В результате, любое изменение модели, каким бы незначительным оно ни было, должно быть продублировано вручную на каждой связанной странице или рабочей книге.
  Помимо этого, невозможно отследить, какая методология используется для управления моделью в электронной таблице. Это связано с тем, что все формулы, которые используются для связи с данными и манипулирования ими, скрыты. Таким образом, базовая формула оказывается непрозрачной, следовательно, и методология, используемая для управления моделями.
  2. Целостность данных.
  Даже несмотря на серьезность изложенных выше проблем, все они в большей степени касаются количества времени, которое необходимо для разработки, сопровождения и изменения моделей электронных таблиц. Поэтому при наличии ресурсов нужно задуматься о продуктивности их использования. Более значимой является задача обеспечения целостности данных, которые представляются в отчете. Как правило, данные электронных таблиц хранятся в отдельных рабочих книгах, с которыми работают различные пользователи, удаленные друга от друга. Формулы в этих рабочих книгах связаны друг с другом. Эти связи, однако, разрывают цельность модели. Так, если данные в одной рабочей книге изменены, невозможно узнать, была ли скорректирована вся модель.
  Как было упомянуто выше, из-за того, что формулы в электронных таблицах скрыты, невозможно установить их корректность, не прибегнув к продолжительной ручной проверке. Кроме того, поскольку каждая рабочая книга - это отдельный объект, корректность одной книги не означает правильность всех остальных.
  Третьим возможным средством автоматизации получения в ООО «Золотой век» аналитической информации по рассматриваемым сферам управления могут быть признаны базы данных.
  База Данных (БД) - структурированный организованный набор данных, описывающих характеристики каких-либо физических или виртуальных систем. Организация структуры БД формируется исходя из следующих соображений:
  - адекватность описываемому объекту или системе - на уровне концептуальной и логической модели;
  - удобство использования для ведения учёта и анализа данных - на уровне так называемой физической модели.
  Базы данных, разработанные с применением существующих систем управления базами данных (СУБД), лишены тех недостатков, которые присущи специализированным экономико-аналитическим программам и электронным таблицам. В частности:
  - база данных может быть гибко адаптирована под потребности именно ООО «Золотой век»;
  - последующая модернизация базы данных разработанной с учетом потребностей именно ООО «Золотой век», является мене трудоемкой, чем модернизация специализированных программ и может быть осуществлена силами пользователей базы данных, без привлечения дорогостоящих услуг сторонних организаций;
  - в базах данных может быть обеспечена целостность данных.
  В настоящее время, наиболее популярными СУБД можно признать:
  - Oracle Database;
  - Microsoft SQL Server;
  - MySQL;
  - Microsoft Access.
  Oracle Database 11g - база данных, разработанная специально для работы в сетях распределенных вычислений Grid, предназначенная для эффективного развертывания на базе различных типов оборудования, от небольших серверов до мощных симметричных многопроцессорных серверных систем, от отдельных кластеров до корпоративных распределенных вычислительных систем. СУБД предоставляет возможность автоматической настройки и управления, что делает ее использование простым и экономически выгодным.
  Oracle Database характеризуется достаточной простотой эксплуатации, мощью и выгодным соотношением цены и производительности для приложений масштаба рабочих групп, отдельных подразделений или приложений, работающих в среде интернет или интранет. Работая в различных средах, начиная от односерверных конфигураций для малого бизнеса и заканчивая распределенными средами крупных филиалов, Oracle Database обладает всеми функциональными возможностями для обеспечения работы критических для бизнеса приложений.
  Используя Oracle Database, ООО «Золотой век» получит возможность управлять всей корпоративной информацией и глубже понимать свой бизнес, а также оперативно и уверенно адаптироваться ко все более изменчивой конкурентной среде. Чтобы предоставить такие возможности, в новом выпуске расширены уникальные механизмы Oracle, обеспечивающие кластеризацию баз данных, автоматизацию центров обработки данных и управление рабочими нагрузками. Используя защищенные, масштабируемые grid-инфраструктуры на базе недорогих серверов и систем хранения, обеспечивающие высокие уровни готовности, клиенты Oracle могут создавать OLTP приложения, хранилища данных и системы управления контентом с самыми высокими требованиями.
  Данный программный продукт позволяет приложениями для баз данных использовать весь спектр функциональных возможностей файловых систем. Возможность хранить корпоративную информацию различных типов, а также просто и быстро извлекать ее, помогает предприятиям лучше понимать свой бизнес и оперативно адаптироваться к изменениям.
  Oracle Database 11g предлагает значительно усовершенствованную технологию XML DB, позволяющую клиентам хранить XML-данные в своем собственным формате и умело управлять ими. Реализованная в этой версии поддержка бинарного XML позволяет клиентам выбирать варианты хранения XML в соответствии со специфическими потребностями. Кроме того, XML DB обеспечивает управление XML-данными с использованием стандартных для отрасли интерфейсов, благодаря поддержке стандартов XQuery, Java Specification Requests (JSR)-170 и SQL/XML.
  Oracle Database предлагает различные инструменты разработки, а также простой процесс создания приложений, максимально эффективно реализующий ключевые функциональные возможности Oracle Database.
  Функции обеспечения управляемости в Oracle Database призваны помочь организациями легко управлять корпоративными grid-инфраструктурами и отвечать ожиданиям пользователей, связанным с уровнями обслуживания. Oracle Database предлагает расширенные функции самоуправления и автоматизации, которые помогут клиентам сокращать затраты на управление системами, повышая производительность, масштабируемость, доступность и безопасности приложений для баз данных. Новые средства обеспечения управляемости в Oracle Database включают автоматическую настройку SQL и области памяти, новый компонент Partitioning Advisor, предлагающий администраторам рекомендации по секционированию таблиц и индексов для повышения производительности, а также улучшенные средства диагностики производительности для кластерных баз данных. Кроме того, Oracle Database включает новый компонент Support Workbench, который предлагает простой в использовании интерфейс, представляющий администраторам сведения о проблемах, возникающих при работе СУБД, вместе с информацией о том, как можно быстро решить эти проблемы.
  Microsoft SQL Server - система управления реляционными базами данных, разработанная корпорацией Microsoft.
  Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL, являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.
  Microsoft SQL Server также поддерживает Open Database Connectivity (ODBC) - интерфейс взаимодействия приложений с СУБД. Последняя версия (SQL Server 2005) обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.
  SQL Server поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL - это совокупность одинаково конфигурированных серверов; такая схема помогает распределить рабочую нагрузку между несколькими серверами. Все сервера имеют одно виртуальное имя, и данные распределяются по IP адресам машин кластера в течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов кластера доступен автоматический перенос нагрузки на другой сервер.
  SQL Server поддерживает избыточное дублирование данных по трем сценариям:
  - снимок: производится «снимок» базы данных, который сервер отправляет получателям;
  - история изменений: все изменения базы данных непрерывно передаются пользователям;
  - синхронизация с другими серверами: базы данных нескольких серверов синхронизируются между собой; изменения всех баз данных происходят независимо друг от друга на каждом сервере, а при синхронизации происходит сверка данных; данный тип дублирования предусматривает возможность разрешения противоречий между БД.
  В SQL Server 2005 встроена поддержка .NET Framework. Благодаря этому, хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NET Framework, включая Common Type System (система обращения с типами данных в Microsoft .NET Framework). Однако, в отличие от других процессов, .NET Framework, будучи базисной системой для SQL Server 2005, выделяет дополнительную память и выстраивает средства управления SQL Server вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQL Server.
  Вместе со всеми достоинствами MS SQL Server имеет существенные ограничения:
  - 1 поддерживаемый процессор (но может быть установлен на любой сервер);
  - 1 Гб адресуемой памяти;
  - 4 Гб максимальный размер базы.
  MySQL - свободная система управления базами данных. MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.
  MySQL является решением для малых и средних приложений. Входит в LAMP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.
  Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.
  MySQL имеет API для языков C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.
  Microsoft Access - реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, сортировку по разным полям, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.
  Microsoft Access является настольной СУБД реляционного типа, которая имеет все необходимые средства для выполнения функций управления базами данных. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать простые и сложные приложения.
  В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам. Имеется возможность создать сколько угодно таблиц, используя единые правила. Самым важным правилом, которое необходимо соблюдать, является то, что в базе данных нужно хранить только необходимую информацию, и при этом все данные должны храниться только в одном месте.
  На первый взгляд СУБД Access очень похожа по своему назначению и возможностям на программу электронных таблиц Microsoft Excel. Однако между ними существуют принципиальные различия.
  Таблица в базе данных Access отличается от таблицы Excel тем, что в ней для каждого поля записи определен тип данных, то есть, нельзя в один столбец таблицы в разные строки заносить данные разных типов.
  Access позволяет не только вводить данные в таблицы, но и контролировать правильность вводимых данных. Для этого необходимо установить правила проверки прямо на уровне таблицы. Тогда каким бы образом не вводились данные - прямо в таблицу, через экранную форму или на странице доступа к данным, Access не позволит сохранить в записи те данные, которые не удовлетворяют заданным правилам.
  Таблицы баз данных могут включать в себя неограниченное количество записей, и при этом СУБД обеспечивает удобные способы извлечения из этого множества нужной информации.
  Access позволяет хранить все данные в одном файле и осуществлять доступ к этим данным постранично, то есть, не превышая ограничений на ресурсы памяти компьютера.
  В Access возможно создание связей между таблицами, что позволяет совместно использовать данные из разных таблиц. При этом для пользователя они будут представляться одной таблицей. Реализовать такую возможность в системах управления электронными таблицами сложно, а иногда просто невозможно.
  Устанавливая взаимосвязи между отдельными таблицами, Access позволяет избежать ненужного дублирования данных, сэкономить память компьютера, а также увеличить скорость и точность обработки информации. Для этого таблицы, содержащие повторяющиеся данные, разбивают на несколько связанных таблиц.
  Access может поддерживать одновременную работу с базой данных 50 пользователей, при этом все пользователи гарантировано будут работать с актуальными данными.
  Access имеет развитую систему защиты от несанкционированного доступа, которая позволяет каждому пользователю или группе пользователей видеть и изменять только те объекты, на которые ему выданы права администратором системы, например можно запретить использование некоторых команд меню, открытие определенных форм, изменение данных в таблицах или формах. Электронные таблицы тоже позволяют защитить данные паролем или разрешить только просмотр данных, однако эти средства существенно проще.
  Таким образом, СУБД Access применяется в тех случаях, когда прикладная задача требует хранения и обработки разнородной информации о большом количестве объектов и предполагает возможность многопользовательского режима. В случае с ООО «Золотой век», примером может служить задача ведения складского учета.
  С целью принятия решения о выборе средств разработки автоматизированной системы получения аналитической информации для управления в ООО «Золотой век» было проведено экспертное исследование предпочтительности того или иного средства разработки. Результаты исследования представлены в табл. 2.
  Анализ проводился по пяти критериям по десятибалльной системе:
  - гибкости настройки и функциональности;
  - требовательности к аппаратным ресурсам;
  - цене;
  - трудоемкость обучения пользователя;
  - трудоемкость модернизации пользователем без привлечения сторонних организаций
   
  Таблица 2 – Экспертное исследование
  Средство реализации
  Гибкость и функцио-нальность
  Требова-тельность к ресурсам
  Цена
  Трудоем-кость обучения
  Трудоем-кость модерни-зации
  Итоговый рейтинг
  Специализи-рованные программы
  1
  8
  6
  6
  1
  22
  Электронные таблицы
  8
  5
  8
  6
  4
  21
  Oracle Database
  9
  7
  2
  4
  1
  23
  Microsoft SQL Server
  5
  6
  2
  3
  1
  17
  MySQL
  2
  6
  9
  1
  1
  18
  Microsoft Access
  9
  7
  8
  6
  4
  34
   
  Результаты проведенного исследования позволяют констатировать, что для целей внедрения в условия деятельности ООО «Золотой век» оптимальным решением является разработка базы данных с использованием СУБД Microsoft Access.
   
  4.2 Структура программных средств  
  На рисунке 10 показана принципиальная схема взаимодействия элементов разработанной системы.
  
     
   
   
   
   
   
   
   
   
   
   
   
  Рисунок 10 – Схема взаимодействия элементов системы
  На рисунке 10 сплошными линиями показаны структурные связи, а пунктирными – вызовы одних элементов системы из других элементов.
  Как уже отмечалось, для обеспечения функциональности информационной системы, в базе данных предусмотрено:
  - использование 12 таблиц с данными;
  - формирование 39 запросов;
  - 16 экранных форм с элементами управления для доступа к информации;
  - 57 макросов для обеспечения функциональности элементов управления экранных форм.
  Вся информационная система разделена на два логических блока, обслуживающие различные интересы управления: арендный и сервисный. Кроме того, функционально, система разделена на две части: ввод, исправление и удаление информации, а также – просмотр отчетов и аналитической информации.
  Доступ к работе с информационной системой осуществляется через оконный интерфейс с главной формы приложения – «фрм_главная».
  Пользователю предоставляется возможность выбора из двух функциональных блоков информационной системы: ввод данных и просмотр отчетов. Кроме того, предоставляется возможность просмотреть информацию о программе или завершить работу с программой. Просмотр информации о программе осуществляется через элемент управления (кнопка) «кнп_отк_фрм_о_программе», применение которого запускает макрос «mkr_open_frm_about_and_close_frm_main».
  Function mkr_open_frm_about_and_close_frm_main()On Error GoTo mkr_open_frm_about_and_close_frm_main_Err   DoCmd.OpenForm "фрм_о_программе", acNormal, "", "", , acNormal   DoCmd.Close acForm, "фрм_главная"mkr_open_frm_about_and_close_frm_main_Exit:   Exit Functionmkr_open_frm_about_and_close_frm_main_Err:   MsgBox Error$   Resume mkr_open_frm_about_and_close_frm_main_ExitEnd Function Результатом выполнения макроса является вывод на экран формы «фрм_о_программе».
  Единственным элементом управления этой формы является кнопка «кнп_переход_на_главную», нажатие которой запускает макрос «mkr_open_frm_main_and_close_frm_about», возвращающий пользователя на главную форму.
  Завершение работы с программой осуществляется с помощью элемента управления (кнопки) «кнп_выход», нажатие на которую запускает макрос «exit».
  Доступ к данным блока «ввод данных» осуществляется с помощью элемента управления (кнопки) «кнп_отк_фрм_ввод_данных», нажатие на которую запускает макрос «mkr_open_frm_input_data».
  Результатом выполнения этого макроса является вывод на экран формы «фрм_ввод_данных».
  Форма «форм_ввод_данных» содержит в себе три вкладки, соответствующие трем целям ввода данных:
  - ввод данных, относящихся к арендному сегменту информационной системы;
  - ввод данных, относящихся к сервисному сегменту информационной системы;
  - ввод справочных данных, относящихся к обоим сегментам.
  Элементы управления на вкладках формы соответствуют таблицам, используемым в базе данных.
  - на вкладке «Техника»: «тбл_ос1», «тбл_аренда», «тбл_ремонты»;
  - на вкладке «Запчасти»: «тбл_заказы_запчастей», «тбл_поставки», «тбл_передача_запчастей»;
  - на вкладке «Справочники»: «тбл_типы», «тбл_модели», «тбл_ос1», «тбл_арендаторы», «тбл_системы», «тбл_запчасти», «тбл_поставщики».
  Доступ к соответствующим таблицам осуществляется, путем нажатия соответствующего элемента управления, которое запускает соответствующий макрос:
  1. Открытие формы доступа к таблице «тбл_ос1» - макрос «mkr_open_frm_oc1».
  2. Открытие формы доступа к таблице «тбл_аренда» - макрос «mkr_open_frm_arenda».
  3. Открытие формы доступа к таблице «тбл_ремонты» - макрос «mkr_open_frm_remont».
  4. Открытие формы доступа к таблице «тбл_заказы_запчастей» - макрос «mkr_open_frm_zakaz_zapch».
  5. Открытие формы доступа к таблице «тбл_поставки» - макрос «mkr_open_frm_postavki».
  6. Открытие формы доступа к таблице «тбл_передача_запчастей» - макрос «mkr_open_frm_peredacha_zapchast».
  7. Открытие формы доступа к таблице «тбл_типы» - макрос «mkr_open_frm_types».
  8. Открытие формы доступа к таблице «тбл_модели» - макрос «mkr_open_frm_models».
  9. Открытие формы доступа к таблице «тбл_арендаторы» - макрос mkr_open_frm_arendators».
  10. Открытие формы доступа к таблице «тбл_системы» - макрос «mkr_open_frm_systems».
  11. Открытие формы доступа к таблице «тбл_запчасти» - макрос «mkr_open_frm_zapchast».
  12. Открытие формы доступа к таблице «тбл_поставщики» - макрос «mkr_open_frm_postavshiki».
  Результатом выполнения данных макросов является вывод на экран соответствующей формы доступа к данным используемых в базе данных таблиц, например, к данным таблицы «тбл_ос1».
  По окончанию ввода, изменения или удаления данных у пользователя имеется возможность перейти с любой вкладки формы «фрм_ввод_данных» на форму «фрм_главная». Осуществляется это с помощью элементов управления (кнопок), запускащих макросы, аналогичные описанному выше – «mkr_open_frm_main_and_close_frm_about».
  Основная информация и основной функционал разработанной информационной системы становится доступным в статистико-аналитическом блоке: «просмотр отчетов» из формы «фрм_главная». Доступ к этому блоку осуществляется через элемент управления (кнопку) «кнп_отк_фрм_просмотр_отчетов», нажатие на которую запускает макрос «mkr_open_frm_prosmotr_otchetov».
  Результатом выполнения макроса является вывод на экран пользовательской формы «фрм_просмотр_отчетов».
  Аналогично форме «фрм_ввод_данных», форма «фрм_просмотр_отчетов» функционально разделена на три вкладки: «Аренда», «Ремонты» и «Аналитика». Функции данного блока информационной системы ориентированы только не демонстрацию информации и не предоставляют пользователю вносить изменения в имеющуюся информацию, добавлять или удалять ее элементы. Внутри каждая вкладка разделена на логические блоки:
  1. Вкладка «Аренда»:
  - блок элементов управления для доступа к информации о структуре наличного фонда спецтехники (имеющихся в распоряжении ООО «Золотой век» и готовых к передачи в аренду, находящихся в аренде и находящихся в ремонте);
  - блок элементов управления для доступа к информации о продолжительности аренды и технике, которая не была возвращена по истечению срока договоров аренды;
  - блок элементов управления для доступа к информации о текущей стоимости спецтехники организации: накопленной амортизации и остаточной стоимости;
  - блок элементов управления для доступа к информации об эффективности арендной деятельности, в разрезе по: арендаторам, контрактам, моделям спецтехники, типам спецтехники и в целом по организации.
  2. Вкладка «Ремонты»:
  - блок элементов управления для доступа к информации о ремонтной нагрузке эксплуатируемой спецтехники: длительность ремонтов по моделям техники, длительности ремонтов по экземплярам техники и составе техники, находящейся в ремонте;
  - блок элементов управления для доступа к информации о себестоимости ремонтов: по экземплярам спецтехники, по типам спецтехники и по количеству текущих ремонтов, финансирование которых осуществляется;
  - блок элементов управления для доступа к информации, позволяющей контролировать эффективность и своевременность сервисной деятельности: о ремонтах, нормативный срок которых истек, удельная продолжительность пребывания экземпляров спецтехники в ремонтах (в пересчете на год) и о оставшемся времени до планового технического обслуживания каждого экземпляра техники;
  - блок управления для доступа к информации и контроля за процессом материального снабжения сервисной деятельности: информация о заказах, поставка запчастей по которым не осуществлена; о заказах, поставка по которым осуществлено, но запчасти хранятся на складе и не переданы в сервисный отдел для оприходования; о текущем количестве и составе запчастей на складе.
  3. Вкладка «Аналитика»:
  - блок элементов управления для доступа к аналитической информации о рентабельности: по контрактам и по видам техники;
  - блок элементов управления для доступа к аналитической информации об удельном весе затрат, необходимом для получения единицы (одного рубля) прибыли: по контрактам и по видам техники;
  - блок элементов управления для доступа к плановой информации о нормах складских запасов запасных частей и необходимом оптимальном размере текущих заказов запасных частей у поставщиков;
  - блок элементов управления для доступа к визуализированной информации по рентабельности и затратоемкости моделей техники.
  Необходимо отметить, что количество элементов управления может быть увеличено, тем более, что информационная система содержит в себе запросы, предоставляющие информацию с большей аналитичностью, однако, вкладка «Аналитика» формы «фрм_просмотр_отчетов», с целью ее разгрузки, не была снабжена соответствующими элементами управления.
  Доступ к соответствующей из перечисленной выше информации обеспечивается путем использования элементов управления (кнопок). Нажатие каждой кнопки приводит к запуску соответствующего ей макроса. Результатом выполнения макроса является последовательное формирования нескольких запросов с использованием данных имеющихся таблиц базы данных, осуществление расчетов по формулам экономического анализа и статистическая обработка данных.
  1. Активация элемента управления «кнп_отк_зпр_техника_в_наличии» (кнопки «В наличии» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_tech_v_nal».
  Результатом выполнения макроса является открытие запроса «зпр_техника_в_наличии» в режиме просмотра с запретом на исправление. Запрос «зпр_техника_в_наличии» использует данные таблиц: «тбл_ос1» (поля «модель» и «количество»), «тбл_аренда» (поле «возвращено») и «тбл_ремонты» (поле «исправлено»). Выборка осуществляется по записям, значение полей «возвращено» и «исправлено» соответствует «true». Связь между источниками данных для запроса реализована по полю «код_ос» таблицы «тбл_ос1», полю «объект-аренды» таблицы «тбл_аренда» и полю «ос» таблицы «ремонты».
  2. Активация элемента управления «кнп_отк_тбл_аренда» (кнопки «В аренде» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_v_arend».
  Результатом выполнения макроса является открытие запроса «зпр_техника_в_аренде» в режиме просмотра с запретом на исправление. Запрос «зпр_техника_в_аренде» использует данные таблицы: «тбл_аренда» (все поля). Выборка осуществляется по записям, значение поля «в_аренде» которых соответствуют «true», а поля «возвращено» - «false».
  3. Активация элемента управления «кнп_отк_тбл_ремонты» (кнопки «В ремонте» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_technika_v_remonte».
  Результатом выполнения макроса является открытие запроса «зпр_техника_в_ремонте» в режиме просмотра с запретом на исправление. Запрос «зпр_техника_в_ремонте» использует данные таблицы: «тбл_ремонты» (все поля). Выборка осуществляется по записям, значение поля «в_ремонте» которых соответствуют «true», а поля «исправлено» - «false».
  4. Активация элемента управления «кнп_отк_зпр_длительность_аренды» (кнопки «Длительность» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_dlit_arend».
  Результатом выполнения макроса является открытие запроса «зпр_длительность_аренды_по_контрактам» в режиме просмотра с запретом на исправление. Запрос «зпр_длительность_аренды_по_ос» использует данные таблицы: «тбл_аренда» (поля: «объект_аренды», «дата_передачи_в-аренду» и «дата_возврата_из_аренды»). Длительность аренды определяется в днях и часах:
  - в днях, путем определения между разницей дат возврата из аренды и передачи в аренду;
  - в часах, путем умножение предыдущего результата на 16 часов (двусменный график).
  5. Активация элемента управления «кнп_отк_зпр_просроченная_аренда» (кнопки «Просрочено» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_prosr_arenda».
  Результатом выполнения макроса является открытие запроса «зпр_просроченная_аренда» в режиме просмотра с запретом на исправление. Запрос «зпр_просроченная_аренда» использует данные таблицы: «тбл_аренда» (поля: «арендатор», «объект_аренды», «дата_передачи_в-аренду» и «дата_возврата_из_аренды», «в_аренде», «возвращено»). Запрос осуществляет выборку записей, значения поля «в_аренде» которых соответствует «true», а поля «возвращено» - «false». При этом, запрос использует информацию, вводимую пользователем в момент формирования запроса – дату, на которую определяется просрочка.
  6. Активация элемента управления «кнп_отк_запр_амортизация_за_год» (кнопки «Амортизация» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_amortiz».
  Результатом выполнения макроса является открытие запроса «зпр_амортизация_за_год» в режиме просмотра с запретом на исправление. Запрос «зпр_амортизация_за_год» использует данные таблицы: «тбл_ос1» (поля: «код_ос», «модель», «стоимость», «количество», «срок_фактической_эксплуатации» и «коэффициент-амортизации»). Расчет ведется по формуле (1):
  ,
  (1)
  где: Q – стоимость экземпляра спецтехники;
  Т – срок фактической эксплуатации;
  kА – коэффициент амортизации.
   
  7. Активация элемента управления «кнп_отк_зпр_остаточная_стоимость» (кнопки «Ост. стоимость» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_ostat_stoim».
  Результатом выполнения макроса является открытие запроса «зпр_остаточная_стоимость» в режиме просмотра с запретом на исправление. Запрос «зпр_остаточная_стоимость» использует данные таблицы: «тбл_ос1» (поля: «код_ос», «модель», «стоимость», «срок_фактической_эксплуатации» и «коэффициент-амортизации»), а также данные запроса «зпр_амортизация_за_год» (поле «амортизация»). Остаточная стоимость определяется путем вычитания из первоначальной стоимости суммы накопленной амортизации.
  8. Активация элемента управления «кнп_отк_зпр_прибыль_по_арендаторам» (кнопки «Арендаторы» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_prib_arendator».
  Результатом выполнения макроса является открытие запроса «зпр_прибыль_от_аренды_по_арендаторам» в режиме просмотра с запретом на исправление. Запрос «зпр_прибыль_от_аренды_по_арендаторам» использует данные таблиц: «тбл_ос1» (поля: «код_ос», «модель», «стоимость» и «коэффициент-амортизации») и «табл_аренда» (поля: «арендатор» и «стоимость_аренды»), а также запроса «зпр_длительность_аренды_по_контрактам» (поле «длительность_аренды_в_днях»). Расчет осуществляется по формуле (2):
  ,
  (2)
  где: С – стоимость аренды (цена договора аренды);
  t – длительность аренды по контракту в днях;
  365 – количество дней в году.
   
  Активация элементов управления: «кнп_отк_зпр_прибыль_по_контрактам», «кнп_отк_зпр_прибыль_по_ос» и «кнп_отк_зпр_прибыль_от_аренды_по_типам» приводит к аналогичным вышеописанному процессам и вычислениям. Формирование запросов имеет отличия лишь в следующем:
  - при расчете прибыли по контрактам не производится группировка итогов (в отличие от вышеописанного запроса) – информация представляется по каждому договору аренды;
  - при расчете прибыли по моделям производится группировка итогов по моделям;
  - при расчете прибыли по типам спецтехники производится группировка записей по типам спецтехники.
  9. Активация элемента управления «кнп_отк_зпр_прибыль_по_арендаторам» (кнопки «Арендаторы» на вкладке «Аренда») приводит к запуску макроса «mkr_open_zpr_prib_arendator».
  Результатом выполнения макроса является открытие запроса «зпр_прибыль_от_аренды_по_арендаторам» в режиме просмотра с запретом на исправление. Запрос «зпр_прибыль_от_аренды_по_арендаторам» использует данные таблиц: «тбл_ос1» (поля: «код_ос», «модель», «стоимость» и «коэффициент-амортизации») и «табл_аренда» (поля: «арендатор» и «стоимость_аренды»), а также запроса «зпр_длительность_аренды_по_контрактам» (поле «длительность_аренды_в_днях»).
  9. Активация элемента управления «кнп_отк_фрм_длительность_ремонта_по_ос» (кнопки «Длит. по ОС» на вкладке «Ремонты») приводит к запуску макроса «mkr_open_zpr_dlit_rem_po_oc».
  Результатом выполнения макроса является открытие запроса «зпр_длительность_ремонта_по_ос» в режиме просмотра с запретом на исправление. Запрос «зпр_длительность_ремонта_по_ос» использует данные таблицы: «ремонты» (поля: «код_ос», «модель», «дата_поставновки_в_ремонт» и «дата_окончания_ремонта»). Расчет длительности производится аналогично расчету длительности аренды.
  10. С большей аналитичностью информация о длительности ремонтов может быть получена путем активации элемента управления «кнп_отк_зпр_длительность_ремонтов_подробно», осуществляющего запуск макроса «mkr_open_zpr_dlit_rem_podrobno».
  В результате выполнения макроса «mkr_open_zpr_dlit_rem_podrobno» формируется запрос «зпр_длительность_ремонта_подробно», механизм работы которого аналогичен предыдущему, а информация, представляемая пользователю более широка.
  11. Активация элемента управления «кнп_отк_зпр_затраты_по_ос» (кнопки «Затраты по ОС» на вкладке «Ремонты») приводит к запуску макроса «mkr_open_zpr_zatrat_na_rem_po_oc».
  Результатом выполнения макроса является открытие запроса «зпр_затраты_на_ремонт_по_ос» в режиме просмотра с запретом на исправление. Запрос «зпр_затраты_на_ремонт_по_ос» использует данные таблиц: «тбл_ос1» (поле: «код_ос» и «модель») и «тбл_поставки» (поле: «стоимость-поставки». Связь между таблицами осуществляется по полю «код_ос» таблицы «тбл_ос1» и полю «объект_ос» таблицы «тбл_поставки», а группировка записей – по моделям спецтехники.
  12. Аналогичным вышеописанному образом производится получение информации о затратах на ремонт спецтехники по ее типам. Для этого активируется элемент управления «кнп_отк_зпр_затраты_по_типам» (кнопка «Затр. по типам» вкладки «Ремонты»), запускающий макрос «mkr_open_zpr_zatrat_po_types».
  Результатом выполнения макроса является формирование запроса «зпр_затраты_на_ремонт_по_типам», при этом. Группировка осуществляется по типам, а не по моделям.
  13. Активация элемента управления «кнп_отк_зпр_количество_ремонтов» (кнопка «Количество ремонтов» вкладки «Ремонты») запускает макрос «mkr_open_zpr_kolichestvo_remontov».
  В результате выполнения макроса осуществляется формирование запроса «зпр_количество_ремонтов», который использует данные таблиц: «тбл_ремонты» (поле: исправлено») и «тбл_ос1» (поля: «код_ос1» и «модель»). Связь между таблицами осуществляется по полю «код_ос1» таблицы «тбл_ос1» и полю «ос» таблицы «тбл_ремонты». Запросом осуществляется выборка записей, содержащих в поле «исправлено» таблицы «тбл_ремонты» значение, соответствующее «true» и подсчет количества таких записей. Группировка осуществляется по учетным единицам – экземплярам спецтехники.
  14. Информация о ремонтах, нормативный срок окончания которых истек, формируется аналогично информации о технике, которая не была своевременно возвращена от арендатора после истечения срока аренды. Для получения такой информации используется элемент управления «кнп_отк_зпр_просроченные_ремонты» (кнопка «Просрочено» вкладки «Ремонты», запускающий макрос «mkr_open_zpr_prosroch_remont». В результате запуска макроса «mkr_open_zpr_prosroch_remont» формируется запрос «зпр_просроченные_ремонты».
  15. Активация элемента управления «кнп_отк_зпр_удельные_ремонты» (кнопка «Удельные» вкладки «Ремонты) приводит к запуску макроса «mkr_open_zpr_ydeln_remont».
  В результате выполнение макроса «mkr_open_zpr_ydeln_remont» формируется запрос «зпр_удельные_ремонты», который использует данные таблицы «тбл_ос1» и запроса «зпр_длительность_ремонта_по_ос». Группировка производится по одноименным полям обеих таблицы – полям «код_ос1».
  Расчет удельной продолжительности ремонтов в общей продолжительности эксплуатации каждого экземпляра осуществляется по формуле (3):
  ,
  (3)
  где: tРЕМ – время, проведенное экземпляром спецтехники без деятельности, состоящее из времени, проведенного в ремонтах;
  Т – срок фактической эксплуатации экземпляра спецтехники с момента его постановки на учет в организации.
  16. Активация элемента управления «кнп_отк_зпр_наработка_до_то» (кнопка «Осталось до ТО» вкладки «Ремонты») приводит к запуску макроса «mkr_open_zpr_narabotka_do_to».
  Выполнение макроса формирует запрос «зпр_наработка_до_то», который использует данные двух запросов: «зпр_длительность_аренды_по_ос» и «зпр_плановая_норма_до_то». Группировка осуществляется по экземплярам спецтехники.
  В свою очередь, запрос «зпр_плановая_норма_до_то» формируется на основе данных таблицы «тбл_ос1» и итогов выполненного запроса «зпр_количество_ремонтов». Величина плановой нормы определяется, исходя из базового норматива на ТО, введенного пользователем в таблице «тбл_ос1» и умноженного на количество произведенных за все время эксплуатации ремонтов.
  В запросе «зпр_наработка_до_то» осуществляется сравнение фактического количества отработанных экземпляром спецтехники машино-часов с плановой нормой машино-часов и вычисляется коэффициент наработки по формуле (4):
  ,
  (4)
  где: tРАБ – фактическое время наработки;
  tНОРМ – плановая норма наработки в межсервисный интервал.
   
  17. При активации элементов управления:
  - «кнп_отк_зпр_заказано_но_не_поставлено»;
  - «кнп_отк_зпр_запчасти_на_складе»;
  - «кнп_отк_зпр_заказано_поставлено_но_не_передано»
  соответственно, запускаются макросы:
  - «mkr_open_zpr_zaka_ne_postavlen»;
  - «mkr_open_zpr_zapchesti_na_sklade»;
  - «mkr_open_zpr_zapchesti_na_sklade».
  Результатом запуска макросов является формирование простых запросов на выборку, соответственно:
  - «зпр_заказано_но_не_поставлено»;
  - «зпр_запчасти_на_складе»;
  - «зпр_поставлено_но_не_передано».
  В запросах используются таблицы: «тбл_запчасти», «тбл_заказы_запчастей» и «тбл_поставки». Критерием выбора соответствующих записей является комбинация значений двух логических полей в таблице «тбл_заказы_запчастей»:
  - «зпр_заказано_но_не_поставлено»;
  - «зпр_запчасти_на_складе»;
  - «зпр_поставлено_но_не_передано».
  18. Элемента управления «кнп_отк_зпр_рентабельность_контратктов» (кнопка «Контракты» логического блока «Рентабельность» вкладки «Аналитика») предназначен для запуска макроса «mkr_open_zpr_rent_po_contracts»:
  Выполнение этого макроса формирует запрос «зпр_рентабельность_контрактов». Данный запрос использует данные двух таблиц и двух запросов:
  - «тбл_ос1»;
  - «тбл_аренда»
  - «зпр_прибыль_от_аренды_по_контрактам»;
  - «зпр_длительность_аренды_по_контрактам».
  Рентабельность определяется по формуле (5):
  ,
  (5)
  где: С – стоимость аренды по договору;
  Q – стоимость экземпляра техники, переданного в аренду;
  kА – коэффициент амортизации;
  t1, t0 – соответственно, дата окончания аренды и дата передачи экземпляра спецтехники в аренду;
  365 – количество дней в году.
   
  Группировка записей в данном запросе осуществляется по отдельным контрактам (договорам).
  19. Аналогичным образом осуществляется работа по предоставлению информации о рентабельности по экземплярам техники (активация элемента управления «кнп_отк_зпр_рентабельность_моделей_техники» в логическом блоке «Рентабельность» вкладки «Аналитика»):
  - макрос «mkr_open_zpr_rentab_model_techniki»;
  - запрос «зпр_рентабельность_моделей_техники».
  20. Затратоемкость, принятая для целей управления в ООО «Золотой век» – сумма затрат, необходимая для получения одного рубля прибыли – является гораздо более аналитичным показателем, чем классическая затратоемкость, рассчитываемая как отношение суммы затрат к сумме дохода от продаж. Принятый для целей ООО «Золотой век» показатель затратоемкости позволяет одновременно определить и операционный рычаг, которые позволяет судить о том, на сколько изменится прибыль, если изменить затраты на одну единицу (6-7):
  (6)
  (7)
   
  Для получения информации о затратоемкости по контрактам и по экземплярам спецтехники служат, соответственно, элементы управления:
  - «кнп_отк_зпр_затратоемкость_по_контрактам»;
  - «кнп_отк_зпр_затратоемкость_по_технике».
  Данные элементы управления активизируют, соответственно, макросы:
  - «mkr_open_zpr_zatratoemkost_kontrakt»;
  - «mkr_open_zpr_zatratoemkost_po_techn».
  Выполнение названных макросов обеспечивается формирование, соответственно, следующих запросов:
  - «зпр_затратоемкость-контрактов»;
  - «зпр_затратоемкость_моделей».
  21. Получение информации о нормативном количестве складских запасов запчастей и оптимальном размере текущего заказа запчастей овсуществляется активацией, соответственно, элементов управления:
  - «кнп_отк_зпр_норма_запаса_запчастей»;
  - «кнп_отк_зпр_норма_заказа_запчастей».
  Данные элементы управления запускают на исполнение соответствующие макросы:
  - «mkr_open_zpr_norma_zapasa_zapchast»;
  - «mkr_open_zpr_norma_zakaza_zapchast».
  Макросы предназначены для формирования соответствующих запросов:
  - «зпр_норма_запаса_запчастей»;
  - «зпр_норма_заказа_запчастей».
  Данные запросы используют информацию, последовательно формируемую запросами:
  - «зпр_плановая_норма_до_то».
  - «зпр_наработка_до_то»;
  - «зпр_запчасти_на_складе».
  Расчет оптимальной величины запаса определяется по формуле (8):
  ,
  (8)
  где: N – норма запаса на ТО (таблица «тбл_запчасти», поле «норма_на_то»);
  tФ – срок фактической эксплуатации, нарастающим итогом с момента постановки экземпляра спецтехники на учет (запрос «зпр_длительность_аренды_по_ос», поле «длительность_аренды_в_часах»);
  tN – нормативной количество часов работы в межсервисный интервал (9).
   
  ,
  (9)
  где: ТN – нормативное количество часов работы в межсервисный интервал (таблица «тбл_ос1», поле «норматив_то»);
  КР – количество ремонтов за фактический срок эксплуатации (запрос «зпр_количество_ремонтов», поле «исправлено» - count).
   
  Оптимальный размер текущего заказа запчастей определяется вычитанием из величины нормативного запаса количества запасных частей на складе (запрос «зпр_запчасти_на_складе», поле «количество»).
  Формула запроса «зпр_норма_запаса_запчастей»:
  SELECT тбл_запчасти.код_запчасти, тбл_запчасти.система, тбл_запчасти.наименование_запчасти, тбл_запчасти!норма_на_то*зпр_наработка_до_то!удельная_наработка_до_то AS норма_запасаFROM тбл_запчасти, зпр_наработка_до_то; Формула запроса «зпр_норма_заказа_запчастей»:
  SELECT зпр_потребность_в_запчастях.код_запчасти, зпр_потребность_в_запчастях.система, зпр_потребность_в_запчастях.наименование_запчасти, зпр_потребность_в_запчастях.норма_заказаFROM зпр_потребность_в_запчастяхGROUP BY зпр_потребность_в_запчастях.код_запчасти, зпр_потребность_в_запчастях.система, зпр_потребность_в_запчастях.наименование_запчасти, зпр_потребность_в_запчастях.норма_заказаHAVING (((зпр_потребность_в_запчастях.норма_заказа)>0));  22. Поскольку в процессе работы с информационной системой специалисты ООО «Золотой век» неизбежно столкнуться с проблемой накопления большого массива информации, восприятие которой в цифровом виде станет проблематичным, в разработанной информационной системе предусмотрена возможность визуализации результатов аналитической обработки информации (рисунок 11 ).
  Рисунок 11 – Пример визуализации данных аналитических запросов
   
  По окончанию работы с отчетами пользователь из каждой вкладки может перейти на форму главного окна базы данных, откуда завершить работу с программой.
  Таким образом, описанная информационная система позволяет удовлетворить потребности управления в ООО «Золотой век» по следующим типам и видам информации, а также, операциям с ними:
  - ввод, изменение и хранение информации о поставщиках, арендаторах и спецтехнике, используемой для передачи в аренду;
  - учет и контроль за своевременностью исполнения ремонтов спецтехники;
  - учет и контроль за своевременностью материального снабжения процесса ремонта;
  - анализ эффективности арендной деятельности, в разрезе по: арендаторам, контрактам, экземплярам спецтехники, ее моделям и типам;
  - анализ прибыли и удельной величины затрат на эксплуатации спецтехники, в разрезе по: арендаторам, контрактам, экземплярам спецтехники, ее моделям и типам;
  - нормирование и определение оптимальных величин складского запаса запчастей и текущего заказа запчастей поставщикам.
  Получая данную информацию руководство ООО «Золотой век» будет способно оперативно и экономически обосновано принимать решения о выборе того или иного направления в аренде: увеличении или уменьшении контрактов с арендаторами, эффективность сотрудничества с которыми высока или, наоборот. слишком низка. Так же, у руководства ООО «Золотой век» появляется возможно объективно оценить, какие типы или модели техники приносят больший доход, требуют больших затрат, чаще нуждаются в сервисном обслуживании, теряют максимальное время в простоях на ремонте и т.п. Это позволит оптимизировать наличный фонд спецтехники таким образом, чтобы обеспечить организацию наиболее эффективными видами и типами техники.
  В сочетании с преимущественным заключением договоров с наиболее «выгодными» контрагентами, использование наиболее рентабельной спецтехники позволит ООО «Золотой век» снизить собственные издержки, увеличить выручку и прибыль от продажи арендных услуг.
   
  4.3 Разработка пользовательского интерфейса  
  При изучении предметной области и выявлении требований к ней отдельных пользователей (сотрудников производственного, сервисного отделов и склада ООО «Золотой век»), также при дальнейшем построении инфологической модели данных, сформировалась предварительная структура пользовательского интерфейса. Предстояло тщательно продумать и осознать сценарий взаимодействия АРМа с пользователем, приведя его к оптимальной системе выполнения требуемых задач, и реализовать ПИ в соответствии с этой системой средствами СУБД Access.
  В результате было разработано приложение, которое имеет дружественный интерфейс, эргономичный дизайн и обеспечивает минимизацию усилий пользователя при работе с системой.
  Процесс создание ПИ был нацелен на показатели эффективности:
  - точность работы: все кнопки, отчеты, формы продуманы так, чтобы пользователь совершал как можно меньше ошибок при работе, то есть, неточность нажатия, варианты ложных путей или ответвлений, число неправильных обращений к данным, запросам и пр. сведены к минимуму.
  - функциональная полнота: назначение все форм, кнопок на них, отчетов продуманы и несут четко определенные функции или содержат конкретную информацию.
  - завершенность работы: при использовании системы каждый пользователь, работающий с ней, за фиксированный срок или период завершит производственную задачу, получит результат или необходимую информацию.
  Формы для ввода данных выполнены в едином стиле, имеют кнопки перехода по записям, на некоторых ленточных формах для удобства перемещения оставлена вертикальная полоса прокрутки и кнопки перехода по записям. С основных форм можно выйти, нажав кнопку «На главную», из форм ввода данных можно выйти, нажав на кнопку закрытия окна, аналогично можно закрыть формы отчетов в режиме просмотра отчетов. На некоторых формах, где это необходимо, вставлены списки, по которым можно осуществлять переход к соответствующей записи, что ускоряет поиск необходимой информации.
  Формы, содержащие определенную информацию и управляющие элементы, продуманы и спланированы с учетом ограниченных размеров пространства экрана. Большинство кнопок на формах сгруппированы по функциональному и логическому принципам, чтобы облегчить восприятие информации пользователем.
  Созданные меню, как более привычный способ организации действий пользователя, имеют логическую и смысловую группировку пунктов с привычными названиями, отражающими смыл конкретного пункта меню. Для всех форм и внесенной информации в БД использован одинаковый стиль шрифта – Times New Roman, который поддерживает кодировку русских букв. Названия элементов управления выполнены шрифтом Tahoma. Цветовая гамма форм, которая в основном соответствует стандартным настройкам OS WINDOWS, размер и стиль шрифтов, расположение кнопок с надписями и характерными изображениями, логическая структура построения связей и переходов между формами делает работу пользователя с приложением удобной и комфортной. Интерфейс организован с предельной простотой, что позволяет освоить работу с АРМ за короткие сроки и без дополнительных консультаций. Вводного инструктажа для пользователей (продавца, администрации) достаточно, чтобы дальнейшее освоение системы и разрешение служебных ситуаций при работе с системой происходили самостоятельно.
  Дизайн пользовательского интерфейса обеспечивает минимизацию усилий пользователя при выполнении работ в системе и приводит:
  - к сокращению длительности операций чтения, редактирования и поиска информации,
  - к уменьшению времени навигации и выбора команды,
  - к повышению общей продуктивности пользователя, заключающейся в объеме обработанных данных за определенный период времени,
  - к увеличению длительности устойчивой работы пользователя и др.
   
  4.4 Руководство пользователя  
  Для обеспечения эффективной работы пользователя разработанная информационная система снабжена пользовательским интерфейсом. Реализована защита от несанкционированного удаления или изменения элементов системы пользователем путем блокировки доступа к возможностям СУБД по редактированию базы данных, элементов управления приложения, экранных форм и формул запросов.
  При запуске приложения на экран демонстрируется форма приглашения (рисунок 11).
  Рисунок 11 – Форма «фрм_главная»
   
  С данной формы пользователю предоставляется возможность производить действия двух типов: ввод данных и просмотр отчетов.
  При нажатии кнопки «Ввод данных» пользователю демонстрируется меню «Ввод данных» (рисунок 12), из которого он имеет возможность выбора того, какие данные требуется ввести: о поставках техники или запчастей, о передаче техники в аренду, возврате из аренды, передачи техники в ремонт или возврате из ремонта, поставке запчастей, расширении их номенклатуры, заказах запчастей или их передачи со сколада в сервисный отдел.
  Рисунок 12 – Форма «фрм_ввод_данных»
   
  Предоставляется также возможность просмотра или редактирования справочных данных. По окончанию ввода данных пользователь должен нажать кнопку «На главную» для возврата к меню выбора основных действий (на главное меню). При вводе данных и регистрации фактов поставки запчастей или передачи их со склада в сервисный отдел, пользователь дожжен подтвердить внесенные изменения нажатием соответствующей кнопки, после чего поставить галочку в соответствующем поле открывшейся формы (рисунок 13).
  Рисунок 13 – Форма «фрм_поставки»
  По нажатию кнопки «Просмотр отчетов» (см. рисунок 11) пользователю демонстрируется меню просмотра отчетов (рисунок 14).
  Рисунок 14 – Форма «фрм_просмотр_отчетов»
  Данное меню имеет три вкладки, соответствующие функциональным блокам деятельности ООО «Золотой век». Во вкладках кнопки меню распределены по логическим блокам.
  При необходимости просмотра данных о просроченной аренде пользователь должен ввести дату, которая соответствует сроку окончания соответствующего договора или текущую дату (рисунок 15).
  Рисунок 15 – Приглашение ввода даты окончания договора аренды или текущей даты
   
  Аналогичные действия пользователю предлагается совершить при необходимости просмотра данных о просроченных ремонтах на вкладке «Ремонты».
  Просмотр отчетов осуществляется в табличной форме на выделенных экранных формах.
  Например:
  - отчет о количестве и составе техники в аренде (рисунок 16):
  Рисунок 16 – Результат активации элемента управления «кнп_отк_тбл_аренда»
   
  - отчет о длительности нахождения техники в аренде (рисунок 17):
  Рисунок 17 – результат активации элемента управления «кнп_отк_зпр_длительность_аренды»
   
  - отчет о накопленной сумме амортизации по экземплярам техники (рисунок 18):
  Рисунок 18 – Результат активации элемента управления «кнп_отк_запр_амортизация_за_год»
  - отчет о накопленной прибыли по арендаторам (рисунок 19):
  Рисунок 19 – Результат активации элемента управления «кнп_отк_зпр_прибыль_по_арендаторам»
   
  - отчет о величине затрат по арендным услугам в разрезе экземпляров техники (рисунок 20):
  Рисунок 20 – Результат активации элемента управления «кнп_отк_зпр_затраты_по_ос»
   
  - отчет об удельной продолжительности нахождения техники в ремонтах по экземплярам техники (рисунок 21):
  Рисунок 21 – Результат активации элемента управления «кнп_отк_зпр_удельные_ремонты»
   
  - отчет об оптимальном размере заказа запчастей на текущую дату (рисунок 22):
  Рисунок 22 – Результат активации элемента управления «кнп_отк_зпр_норма_заказа_запчастей»
   
  Остальные экранные формы пользовательского интерфейса представлены в приложении.
   
  4.5 Руководство программиста  
  Для доступа к возможностям редактирования базы данных, ее таблиц, формул запросов, макросов, форм и отчетов необходимо при запуске приложения удерживать кнопку Shift.
  Программное средство было разработано в среде СУБД Access. При необходимости можно внести изменения в структуру базы данных, а именно: добавить новые таблицы, изменить состав полей, внешний вид форм и т.д. Для этого следует при запуске программы выбрать меню Сервис ? Параметры запуска и в появившемся окне установить флажок в поле «Окно базы данных». После чего программу следует закрыть и запустить снова. Теперь окно базы данных будет доступно.
  Для создания новой таблицы, необходимо активизировать окно базы данных, перейти на закладку «Таблицы» и нажать кнопку создать. На экране появиться окно диалога «Новая таблица». В этом окне выбираем кнопку «Конструктор» и нажимаем кнопку «ОК». Программа выведет окно пустой таблицы в режиме конструктора. В верхней части окна таблицы расположены столбцы, в кото­рые вводятся имя, тип данных и краткое описание каждого поля.
  После введения названия поля необходимо указать тип этого поля.
  Каждая таблица в реляционной БД должна иметь первичный ключ. Для выбора ключевого поля таблицы в окне конструктора щелкнем в области выделения, расположенной слева от имени поля. Нажмем кнопку Ключе­вое поле на панели инструментов. В подтверждении того, что ключевое поле задано появиться символ ключа слева.
  Завершив работу по созданию таблицы, сохраним ее, выбрав команды Файл, Сохранить. Выведется окно сохранения. Введем имя таблицы.
  После создания таблиц нужно сообщить Microsoft Access, как они связаны друг с другом. В дальнейшем Microsoft Access сможет связать эти таблицы при их использовании в запросах, формах, отчетах – в специальном модулу СУБД «Схема данных».
  В этом модуле нужно выделить таблицы, между которыми будут созданы связи, и нажать кнопку «Добавить». Затем кнопку закрыть. Чтобы построить связь, нужно установить курсор на ключевом поле одной таблице и перетащить его на одноименное (или аналогичное) неключевое поле другой таблицы. При этом если типы полей совпадают, будет создана связь типа «один ко многим», в противном случае – связь неопределенного типа, которую нельзя использовать. Когда появится графическое изображение связи в виде соединительной линии, двойной щелчок по ней откроет окно редактирования связи. Устано­вление флажка Обеспечение целостности данных приведет к тому, что в подчиненную таблицу нельзя будет ввести записи, которым нет аналога в главной таблице. Установление флажка также сделает доступным два значения: Каскадное обновление связанных полей и каскадное удаление связанных полей.
  После задания структуры таблиц приложения, можно создать его макет с помощью форм и связать их между собой, используя макросы или процедуры обработки событий. При этом можно создавать «на экране» достаточно реальные необходимые в приложении формы и отчеты, перио­дически переключаясь для контроля своих действий из режима формы в ре­жим предварительного просмотра.
  Чтобы начать создание формы необходимо перейти на вкладку «Форма», а затем нажмем кнопку «Создать» на экране появится «Новая форма». В этом окне выбрать «Конструктор» и нажать ОК. Появиться окно пустой формы в режиме конст­руктора.
  Для добавления на форму элементов управления достаточно выбрать необходимый элемент и перенести его на форму. После того как элемент будет перенесен, запустится мастер, который поможет, установит источник информации и основные настройки. Для создания подчиненной формы в «Главном меню» необходимо выбрать на панели инструментов кнопку «Подчиненная форма/отчет», после этого дожжен запуститься мастер, в котором нужно указать название формы, которая будет подчиненной. Переключив форму из режима конструктора в режим просмотра, можно просмотреть что получилось.
  Для того чтобы связать имеющиеся формы нужно использовать элемент управления «Кнопка». Необходимо перетащить кнопку на главную форму, после чего откроется диалоговое окно «создание кнопок». В окне категория нужно выбрать пункт работа с формой, в окне действия выбрать «открытие формы» и выбрать форму, которая будет открываться после нажатия на кнопку. Аналогично создаются кнопки для просмотра отчетов. После создания кнопки можно будет изменить надпись на кнопке или добавить рисунок.
  Для удобного просмотра хранящейся в БД информации можно использовать отчеты.
  В окне БД нужно перейти на вкладку «Отчеты» и нажать на кнопку «Создать», чтобы открыть окно диалога «Новый отчет». В этом окне нажать на «Мастер отчетов» и выбрать таблицу или запрос в качестве источника данных. На­жав кнопку ОК, перейдем в окно, в котором выбираются необходимые поля таблицы и нажмем кнопку «Далее». В открывшемся окне задается внешний вид отчета в «Макете», затем Стиль. Нажав кнопку «Далее» в открывшемся окне вводится название отчета. Кнопка Готово.
  Базу данных Microsoft Access можно разделить на два файла, в одном из которых содержатся таблицы, а в другом запросы, формы, отчеты, макросы, модули и ярлыки страниц доступа к данным. Это позволит пользователям иметь доступ к общему источнику данных и при этом создавать свои собственные формы, отчеты и другие объекты.
  В меню Сервис выберите команду Служебные программы и подкоманду Разделение баз данных.
  Далее необходимо присоединить таблицы к базе, в которой остались только формы и прочие интерфейсные объекты и задать параметры обновления. Это выполняется при помощи Диспетчера связанных таблиц (Меню Сервис/Служебные Программы).
  Для задания связи с файлом, расположенным в локальной сети, используется стандартный формат записи пути (UNC), в формате «//Сервер/Общая папка/Путь/Имя файла».
  После успешного разделения базы данных необходимо определить механизм блокировки данных для обработки ситуаций одновременного обращения к одним и тем же данным.
  Можно блокировать все записи в базовой таблице или только изменяемую запись. В обоих случаях запись, изменяемая одним пользователем в результатах запроса, недоступна в это время другим пользователям для изменения в базовой таблице.
  Откройте запрос в режиме конструктора. В многопользовательской среде подтвердите, что все пользователи закрыли данный запрос, его базовую таблицу или запрос, а также другие объекты, основанные на данном запросе.
  Также необходимо определить время ожидания запросом ответа от источника данных ODBC, по прошествии которого будет выдано сообщение об ошибке подключения к ODBC. Выполнение запроса, использующего базу данных ODBC в качестве базового источника данных, может быть задержано из-за высокой загруженности сети или занятости сервера ODBC.
  Откройте запрос в режиме конструктора. Выделите запрос, щелкнув в режиме конструктора запроса любое место вне бланка запроса и списков полей.
  Нажмите кнопку Свойства на панели инструментов, чтобы открыть окно свойств запроса.
  Задайте в значении свойства Время ожидания ODBC (ODBCTimeout) число секунд, после которого возвращается сообщения об ошибке превышения времени ожидания. По умолчанию задается значение 60 секунд. Если задать для этого свойства нулевое значение, ошибка превышения времени ожидания не возникает.
  Заключение  
  Главным результатом проведенной работы является создание функционирующей СУБД, которая выполняет требуемый круг задач, с которыми сталкиваются руководители подразделений ООО «Золотой век».
  Реализация данного проекта была проведена без привлечения мощных средств работы с базами данных, которые очень громоздки,  поскольку носят универсальный характер и к тому же требуют необходимую базу знаний по теории баз данных.
  Использование мощных средств MS Access по созданию баз данных, работающих в операционной системе Windows и в частности приложений баз данных, позволило создать программный продукт максимально ориентированный на конечного пользователя, который не искушен в вопросах теории баз данных.
  Вся необходимая работа по осуществлению методов доступа к информации хранимой в базе данных, её модификации, поддержании базы данных в целостном  виде скрыта внутри и пользователю нет необходимости знать о ней,  чтобы успешно решать весь круг возникающих задач связанных с использованием информации хранимой базе данных. Более того, программный интерфейс максимально облегчает работу по обращению с базой данных.
  Все функции выполняемые СУБД были тщательным образом проверены и протестированы в процессе разработки и их работа гарантируется.
  Данный продукт без сомнения может конкурировать с существующей на данный момент базой данных и средствами её управления.
  Список используемых источников  
  1. Базы данных: модели, разработка, реализация / Т.С. Карпова. - СПб.: Питер, 2002. - 304 с.: ил.
  2. Вишневская В. Продвигаясь на мировой рынок. Развитие информационных технологий, как часть стратегии предприятия // Компьютер и бухгалтер. - 2002. - № 1. - С. 10-11.
  3. Голицына О.Л., Максимов, Н.В., Попов И.И. Базы данных: Учебное пособие. - М.: Форум: ИНФРА-М, 2004. - 352 с.: ил. - (профессиональное образование).
  4. Колосов А. «1С: Предприятие» как платформа разработки приложений // Компьютер пресс. - 2000. - № 5. - С. 151-155.
  5. КонсультантПлюс: Высшая школа. Выпуск 5 к весеннему семестру 2009 года. Специальная подборка правовых документов и учебных материалов. 6. Кузнецов, С. Информационная система: Как ее сделать // Автоматизация бухгалтерского учета и финансово-хозяйственной деятельности предпрятий. - 2008. - № 3. - С. 18-21.
  6. Маклаков С.В. BPWin и ERWIN. CASE-средства разработки информационных систем. - М.: ДИАЛОГ-МИФИ, 2007. - 256 с.
  7. Малыхина М.П. Базы данных: основы, проектирование, использование. - СПб.: БХВ-Петербург, 2007. - 512 с.: ил.
  8. Мурахвери В. «1С»: Оптимизм // Компьютер пресс. - 2008. - № 8. - С. 191-192.
  9. Нетесова О. Новые технологии в цифрах. Методы оценки эффективности автоматизированных информационных систем // Компьютер и бухгалтер. - 2008. - № 1 - С. 12-14.
  10. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие для вузов / А. М. Вендров. - М.: Финансы и статистика, 2007. – 192 с.
  11. Послед Б.С. ACCESS 2002. Приложения баз данных. Лекции и упражнения. – СПб.: ДиаСофтЮП, 2002. – 656 с.
  12. Проектирование программного обеспечения экономических информационных систем: Учеб, для вузов / А. М. Вендров. - М.: Финансы и статистика, 2003, - 352 с.
  13. Стороженко К.П. Как выбрать программу // Компьютер и бухгалтер. - 1998. - № 1. - С. 14-16.
  14. Харитонова И.А., Михеева В.Д. Microsoft Access 2000. – СПб.: БХВ-Петербург, 2006. -  1088 с.
  15. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. - 4-е изд., доп. и перераб. - СПб.: КОРОНА принт, 2006. - 736 с.
  16. Чемеркина Н. Если вы менеджер Аналитика для 1С // Компьютер и бухгалтер. - 2007. - № 1. - С. 7-9.
  17. Якобсон И.Г. Автоматизация // Компьютер и бухгалтер. - 2008. - № 1. - С. 41-43.
  Приложение А. Схема базы данных  
  Рисунок А1 – Схема связей таблиц базы данных арендного сегмента (формат MS Access)
  Рисунок А2 – Схема связей таблиц базы данных сервисного сегмента (формат MS Access)
  Приложение Б. Описание таблиц  
  Таблица Б.1 – Таблица «тбл_аренда»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_аренды
  Текстовый ключевое
  Маска ввода «00-00-0000-0»
  Индекс договора аренды
  арендатор
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «арендаторы», поле «наименование_аренда-тора»
  объект_аренды
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «модель»
  количество
  Числовой
   
  Значение по умолчанию «1»
  стоимость_аренды
  Денежный
   
  Цена договора аренды
  дата_передачи_в_аренду
  Дата/ время
   
  Дата фактической передачи техники в аренду
  дата_окончания_аренды
  Дата/ время
   
  Дата окончания договора аренды
  в_аренде
  Логичес-кий
   
  «Да» - экземпляр передан арендатору; «Нет» - экземпляр не в аренде
  возвращено
  Логичес-кий
   
  «Да» - экземпляр возвращен от арендатора; «Нет» - экземпляр не возвращен от арендатора
   
  Таблица Б.2 – Таблица «тбл_арендаторы»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  инн_арендатора
  Текстовый (ключевое)
  Маска ввода «0000000000»
  ИНН арендатора, назначается ФСН
  офп_арендатора
  Текстовый
  Маска ввода «LLL»
  Аббревиатура организационно-правовой формы собственности арендатора из трех символов
  наименование_арендатора
  Текстовый
   
  Юридическое наименование арендатора
  адрес_арендатора
  Текстовый
   
  Юридический адрес арендатора
  телефон_арендатора
  Текстовый
  Маска ввода «+7(000)0000000»
  Телефон арендатора в международном формате
  контактное_лицо_арендатора
  Текстовый
   
  Ф.И.О. представителя арендатора
   
  Таблица Б.3 – Таблица «тбл_заказы_запчастей»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_заказа
  Текстовый ключевое
  Маска ввода «00-0000-0»
  Шифр накладной-требования
  система
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  код_ос
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «код_ос»
  дата_заказа
  Дата/ время
   
  Дата передачи заказа на склад
  заказано
  Логичес-кий
   
  «Да» - заказ передан; «Нет» - заказ не оформлен»
  поставлено
  Логичес-кий
   
  «Да» - запчасти по заказу поступили на склад; «Нет» - запчасти по заказу не поступили на склад
  передано
  Логичес-кий
   
  «Да» - запчасти по заказу переданы со склада в сервисный отдел; «Нет» - запчасти по заказу не переданы в сервисный отдел
   
  Таблица Б.3 – Таблица «тбл_запчасти»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_запчасти
  Текстовый ключевое
   
  Артикул запчасти по каталогу производителя
  система
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  наименование_запчасти
  Текстовый
   
  Наименование запчасти по каталогу производителя
  норма_на_то
  Числовой
   
  Количество запчастей, необходимых на одно ТО, по рекомендациям производителя техники
   
   
   
   
   
  Таблиц Б.5 – Таблица «тбл_модели»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_модели
  Текстовый ключевое
   
  Соответствует наименованию модели по каталогу производителя
  тип_техники
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  наименование_модели
  Текстовый
   
  Наименование модели, в соответствии с каталогом производителя
   
  Таблица Б.6 – Таблица «тбл_ос1»
  Продолжение таблицы 1
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_ос
  Текстовый ключевое
  Маска ввода «000-0000-0000000000»
  Соответствует VIN-коду в международном формате
  модель
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «модели», поле «наименование_модели»
  поставщик
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «поставщики», поле «наименование_поставщика»
  дата_поставки
  Дата/ время
   
  Дата постановки экземпляра техники на учет
  срок_полезного_использования
  Числовой
   
  Срок полезного использования по нормам бухучета
  срок_фактической_эксплуатации
  Числовой
   
  Срок фактической эксплуатации
  коэффициент_амортизации
  Числовой
   
  Норма амортизации в коэффициентном выражении
  норматив_то
  Числовой
   
  Норма машиночасов, установленная производителем техники в межсервисной эксплуатации (между ТО)
   
   
   
  Таблица Б.7 – Таблица «тбл_передача_запчастей»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_передачи
  Текстовый ключевое
  Маска ввода «0000-00-00»
  Соответствует шифру акта передачи запчастей в сервисный отдел
  заказ_запчастей
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «заказ_запчастей», поле «код_заказа»
  поставка_запчастей
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «поставки», поле «код_поставки»
  дата_передачи
  Дата/ время
   
  Дата фактической передачи запчастей со склада в сервисный отдел
   
  Таблица Б.8 – Таблица «тбл_поставки»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_поставки
  Текстовый ключевое
  Маска ввода «00-00-0000-00»
  Индекс договора поставки запчастей от поставщика на склад
  заказ_запчастей
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «заказ_запчастей», поле «код_заказа»
  объект_ос
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «код_ос»
  модель
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «модели», поле «наименование_модели»
  система
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «системы», поле «наименование_системы»
  запчасть
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «запчасти», поле «наименование_запчасти»
  поставщик
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «поставщики», поле «наименование_поставщи-ка»
  количество
  Числовой
   
  Количество поставленных запчастей по одному договору
  Продолжение таблицы Б.8
  Наименование поля
  Тип данных
  Ограничения
  Описание
  стоимость_поставки
  Денежный
   
  Цена договора поставки
  дата_поставки
  Дата/ время
   
  Дата фактической поставки запчастей от поставщика на склад
   
  Таблица Б.9 – Таблица «тбл_поставщики»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  инн_поставщика
  Текстовый ключевое
  Маска ввода «0000000000»
  ИНН поставщика, назначается ФНС
  офп_поставщика
  Текстовый
  Маска ввода «LLL»
  Аббревиатура организационно-правовой формы собственности поставщика из трех символов
  наименование_поставщика
  Текстовый
   
  Юридическое наименование поставщика
  адрес_поставщика
  Текстовый
   
  Юридический адрес поставщика
  телефон_поставщика
  Текстовый
  Маска ввода «+7(000)0000000»
  Телефон поставщика в международном формате
  контактное_лицо_поставщика
  Текстовый
   
  Ф.И.О. представителя поставщика
   
  Таблица Б.10 – Таблица «тбл_ремонты»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_ремонта
  Текстовый ключевое
  Маска ввода «00-00-0000-0»
  Шифр ремонтной карты
  ос
  Текстовый
  Ограниченный список
  Индексированное поле, подстановка из таблицы «ос1», поле «код_ос»
  дата_постановки_в_ремонт
  Дата/ время
   
  Дата передачи экземпляра техники в ремонт
  дата_окончания_ремонта
  Дата/время
   
  Дата фактической передачи экземпляра техники из сервисного отдела в производственный отдел
  в_ремонте
  Логичес-кий
   
  «Да» - экземпляр техники передан в ремонт; «Нет» - экземпляр техники не передавался в ремонт
   
   
  Продолжение таблицы Б.10
  Наименование поля
  Тип данных
  Ограничения
  Описание
  исправлено
  Логичес-кий
   
  «Да» - экземпляр техники передан из сервисного отдела в производственный отдел; «Нет» - экземпляр техники не передан в сервисный отдел или не находится в ремонте
   
  Таблица Б.11 – Таблица «тбл_системы»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_системы
  Текстовый ключевое
  Маска ввода «LLLL»
  Аббревиатура технической системы транспортного средства из четырех символов
  наименование_системы
  Текстовый
   
  Полное наименование системы. в соответствии с классификацией производителя
   
  Таблица Б.12 – Таблица «тбл_типы»
  Наименование поля
  Тип данных
  Ограничения
  Описание
  код_типа
  Текстовый ключевое
  Маска ввода «0000-00-000»
  Код системы, соответствующий обозначению по каталогу ТН ВЭД РФ
  наименование_типа
  Текстовое
   
  Полное наименование типа техники, в соответствии с классификацией ТН ВЭД РФ
   
  Приложение В. Тексты SQL-запросов  
  Запрос «зпр_техника_в_наличии»:
  SELECT тбл_ос1.модель, тбл_ос1.количествоFROM тбл_ос1 INNER JOIN тбл_аренда ON тбл_ос1.код_ос1 = тбл_аренда.объект_арендыGROUP BY тбл_ос1.модель, тбл_ос1.количество, тбл_аренда.возвращеноHAVING (((тбл_аренда.возвращено)=Yes)); (((тбл_ремонты.исправлено)=Yes));  
  Запрос «зпр_техника_в_аренде»:
  SELECT тбл_аренда.код_аренды, тбл_аренда.арендатор, тбл_аренда.объект_аренды, тбл_аренда.дата_передачи_в_аренду, тбл_аренда.дата_возврата_из_арендыFROM тбл_арендаWHERE (((тбл_аренда.в_аренде)=Yes) AND ((тбл_аренда.возвращено)=No));  
  Запрос «зпр_техника_в_ремонте»:
  SELECT тбл_ремонты.код_ремонта, тбл_ремонты.ос, тбл_ремонты.дата_постановки_в_ремонтFROM тбл_ремонтыWHERE (((тбл_ремонты.в_ремонте)=Yes) AND ((тбл_ремонты.исправлено)=No));  
  Запрос «зпр_длительность_аренды_по_контрактам»:
  SELECT тбл_аренда.объект_аренды, Sum(тбл_аренда!дата_возврата_из_аренды-тбл_аренда!дата_передачи_в_аренду) AS длительность_аренды_в_днях, Sum((тбл_аренда!дата_возврата_из_аренды-тбл_аренда!дата_передачи_в_аренду)*16) AS длительность_аренды_в_часахFROM тбл_арендаGROUP BY тбл_аренда.объект_аренды;  
  Запрос «зпр_просроченная_аренда»:
  SELECT тбл_аренда.арендатор, тбл_аренда.объект_аренды, тбл_аренда.дата_передачи_в_аренду, тбл_аренда.дата_возврата_из_арендыFROM тбл_арендаGROUP BY тбл_аренда.арендатор, тбл_аренда.объект_аренды, тбл_аренда.дата_передачи_в_аренду, тбл_аренда.дата_возврата_из_аренды, тбл_аренда.в_аренде, тбл_аренда.возвращеноHAVING (((тбл_аренда.дата_возврата_из_аренды)<[Введите_текущую_дату]) AND ((тбл_аренда.в_аренде)=Yes) AND ((тбл_аренда.возвращено)=No));  
  Запрос «зпр_амортизация_за_год»:
  SELECT тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ос1.стоимость, тбл_ос1!количество*тбл_ос1!стоимость*тбл_ос1!срок_фактической_эксплуатации*тбл_ос1!коэффициент_амортизации AS амортизацияFROM тбл_ос1GROUP BY тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ос1.стоимость, тбл_ос1!количество*тбл_ос1!стоимость*тбл_ос1!срок_фактической_эксплуатации*тбл_ос1!коэффициент_амортизации, тбл_ос1.количество, тбл_ос1.срок_фактической_эксплуатации, тбл_ос1.коэффициент_амортизации;  
  Запрос «зпр_остаточная_стоимость»:
  SELECT тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ос1!стоимость-зпр_амортизация_за_год!амортизация AS остаточная_стоимость, зпр_амортизация_за_год.амортизация, тбл_ос1.стоимостьFROM тбл_ос1 INNER JOIN зпр_амортизация_за_год ON тбл_ос1.код_ос1 = зпр_амортизация_за_год.код_ос1GROUP BY тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ос1!стоимость-зпр_амортизация_за_год!амортизация, зпр_амортизация_за_год.амортизация, тбл_ос1.стоимость, тбл_ос1.срок_фактической_эксплуатации;  
  Запрос «зпр_прибыль_от_аренды_по_арендаторам»:
  SELECT тбл_аренда.арендатор, Sum(тбл_аренда.стоимость_аренды) AS [Sum-стоимость_аренды], Sum(тбл_аренда!стоимость_аренды-тбл_ос1!стоимость*тбл_ос1!коэффициент_амортизации*зпр_длительность_аренды_по_контрактам!длительность_аренды_в_днях/365) AS прибыль_от_арендыFROM тбл_ос1 INNER JOIN (тбл_аренда INNER JOIN зпр_длительность_аренды_по_контрактам ON тбл_аренда.код_аренды = зпр_длительность_аренды_по_контрактам.код_аренды) ON тбл_ос1.код_ос1 = тбл_аренда.объект_арендыGROUP BY тбл_аренда.арендатор;  
  Запрос «зпр_длительность_ремонта_по_ос»:
  SELECT зпр_длительность_ремонтов_подробно.код_ос1, зпр_длительность_ремонтов_подробно.модель, Sum(зпр_длительность_ремонтов_подробно.длительность_ремонта) AS [Sum-длительность_ремонта]FROM зпр_длительность_ремонтов_подробноGROUP BY зпр_длительность_ремонтов_подробно.код_ос1, зпр_длительность_ремонтов_подробно.модель;  
   
  Запрос «зпр_затраты_на_ремонт_по_ос»:
  SELECT тбл_ос1.модель, Sum(тбл_поставки.стоимость_поставки) AS [Sum-стоимость]FROM тбл_ос1 INNER JOIN тбл_поставки ON тбл_ос1.код_ос1 = тбл_поставки.объект_осGROUP BY тбл_ос1.модель;  
  Запрос «зпр_количество_ремонтов»:
  SELECT тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ремонты.исправлено, Count(тбл_ремонты.исправлено) AS [Count-исправлено]FROM тбл_ос1 INNER JOIN тбл_ремонты ON тбл_ос1.код_ос1 = тбл_ремонты.осGROUP BY тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ремонты.исправленоHAVING (((тбл_ремонты.исправлено)=Yes));  
  Запрос «зпр_просроченные_ремонты»:
  SELECT тбл_ремонты.код_ремонта, тбл_ремонты.ос, тбл_ремонты.дата_постановки_в_ремонт, тбл_ремонты.дата_окончания_ремонтаFROM тбл_ремонтыWHERE (((тбл_ремонты.дата_постановки_в_ремонт)<[Введите_текущую_дату]) AND ((тбл_ремонты.в_ремонте)=Yes) AND ((тбл_ремонты.исправлено)=No));  
  Запрос «зпр_удельные_ремонты»:
  SELECT тбл_ос1.код_ос1, тбл_ос1.модель, Sum(зпр_длительность_ремонта_по_ос![Sum-длительность_ремонта]/(365*тбл_ос1!срок_фактической_эксплуатации)) AS удельные_ремонты, тбл_ос1.срок_фактической_эксплуатации, зпр_длительность_ремонта_по_ос.[Sum-длительность_ремонта]FROM зпр_длительность_ремонта_по_ос INNER JOIN тбл_ос1 ON зпр_длительность_ремонта_по_ос.код_ос1 = тбл_ос1.код_ос1GROUP BY тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ос1.срок_фактической_эксплуатации, зпр_длительность_ремонта_по_ос.[Sum-длительность_ремонта];  
  Запрос «зпр_наработка_до_то»:
  SELECT зпр_плановая_норма_до_то.код_ос1, зпр_плановая_норма_до_то.модель, зпр_плановая_норма_до_то!плановая_норма_до_то-зпр_длительность_аренды_по_ос!длительность_аренды_в_часах AS осталось_до_то, зпр_длительность_аренды_по_ос.длительность_аренды_в_часах, зпр_плановая_норма_до_то.плановая_норма_до_то, зпр_длительность_аренды_по_ос!длительность_аренды_в_часах/зпр_плановая_норма_до_то!плановая_норма_до_то AS удельная_наработка_до_тоFROM зпр_плановая_норма_до_то INNER JOIN зпр_длительность_аренды_по_ос ON зпр_плановая_норма_до_то.код_ос1 = зпр_длительность_аренды_по_ос.объект_арендыGROUP BY зпр_плановая_норма_до_то.код_ос1, зпр_плановая_норма_до_то.модель, зпр_плановая_норма_до_то!плановая_норма_до_то-зпр_длительность_аренды_по_ос!длительность_аренды_в_часах, зпр_длительность_аренды_по_ос.длительность_аренды_в_часах, зпр_плановая_норма_до_то.плановая_норма_до_то, зпр_длительность_аренды_по_ос!длительность_аренды_в_часах/зпр_плановая_норма_до_то!плановая_норма_до_то;  
  Запрос «зпр_количество_ремонтов»:
  SELECT тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ос1!норматив_то*зпр_количество_ремонтов![Count-исправлено] AS плановая_норма_до_тоFROM тбл_ос1 INNER JOIN зпр_количество_ремонтов ON тбл_ос1.код_ос1 = зпр_количество_ремонтов.код_ос1GROUP BY тбл_ос1.код_ос1, тбл_ос1.модель, тбл_ос1!норматив_то*зпр_количество_ремонтов![Count-исправлено];  
  Запрос «зпр_заказано_но_не_поставлено»:
  SELECT тбл_заказы_запчастей.код_заказа, тбл_заказы_запчастей.система, тбл_заказы_запчастей.запчасть, тбл_заказы_запчастей.код_ос, тбл_заказы_запчастей.дата_заказаFROM тбл_заказы_запчастейWHERE (((тбл_заказы_запчастей.заказано)=Yes) AND ((тбл_заказы_запчастей.поставлено)=No));  
  Запрос «зпр_запчасти_на_складе»:
  SELECT тбл_запчасти.код_запчасти, тбл_запчасти.система, тбл_запчасти.наименование_запчасти, тбл_поставки.количествоFROM (тбл_запчасти INNER JOIN тбл_заказы_запчастей ON тбл_запчасти.код_запчасти = тбл_заказы_запчастей.запчасть) INNER JOIN тбл_поставки ON тбл_запчасти.код_запчасти = тбл_поставки.запчастьGROUP BY тбл_запчасти.код_запчасти, тбл_запчасти.система, тбл_запчасти.наименование_запчасти, тбл_поставки.количество, тбл_заказы_запчастей.поставлено, тбл_заказы_запчастей.переданоHAVING (((тбл_заказы_запчастей.поставлено)=Yes) AND ((тбл_заказы_запчастей.передано)=No));  
  Запрос «зпр_поставлено_но_не_передано»:
  SELECT тбл_заказы_запчастей.код_заказа, тбл_заказы_запчастей.система, тбл_заказы_запчастей.запчасть, тбл_заказы_запчастей.дата_заказа, тбл_поставки.количествоFROM тбл_заказы_запчастей INNER JOIN тбл_поставки ON тбл_заказы_запчастей.код_заказа = тбл_поставки.заказ_запчастейWHERE (((тбл_заказы_запчастей.заказано)=Yes) AND ((тбл_заказы_запчастей.поставлено)=Yes) AND ((тбл_заказы_запчастей.передано)=No));  
  Запрос «зпр_рентабельность_контрактов»:
  SELECT тбл_аренда.код_аренды, тбл_аренда.арендатор, тбл_аренда!стоимость_аренды-тбл_ос1!стоимость*тбл_ос1!коэффициент_амортизации*зпр_длительность_аренды_по_контрактам!длительность_аренды_в_днях/365 AS прибыль_от_аренды, [прибыль_от_аренды]/(тбл_ос1!стоимость*тбл_ос1!коэффициент_амортизации*зпр_длительность_аренды_по_контрактам!длительность_аренды_в_днях/365) AS рентабельность_контрактовFROM тбл_ос1 INNER JOIN (тбл_аренда INNER JOIN зпр_длительность_аренды_по_контрактам ON тбл_аренда.код_аренды = зпр_длительность_аренды_по_контрактам.код_аренды) ON тбл_ос1.код_ос1 = тбл_аренда.объект_аренды;  
  Запрос «зпр_рентабельность_моделей_техники»:
  SELECT тбл_ос1.код_ос1, тбл_ос1.модель, Sum(тбл_аренда!стоимость_аренды-тбл_ос1!стоимость*тбл_ос1!коэффициент_амортизации*зпр_длительность_аренды_по_контрактам!длительность_аренды_в_днях/365) AS прибыль_от_аренды, [прибыль_от_аренды]/([стоимость]*[срок_фактической_эксплуатации]*[коэффициент_амортизации]) AS рентабельность_моделейFROM тбл_ос1 INNER JOIN (тбл_аренда INNER JOIN зпр_длительность_аренды_по_контрактам ON тбл_аренда.код_аренды = зпр_длительность_аренды_по_контрактам.код_аренды) ON тбл_ос1.код_ос1 = тбл_аренда.объект_арендыGROUP BY тбл_ос1.код_ос1, тбл_ос1.модель, [прибыль_от_аренды]/([стоимость]*[срок_фактической_эксплуатации]*[коэффициент_амортизации]), тбл_ос1.стоимость, тбл_ос1.срок_фактической_эксплуатации, тбл_ос1.коэффициент_амортизации;  
  Запрос «зпр_затратоемкость-контрактов»:
  SELECT тбл_аренда.код_аренды, тбл_аренда.арендатор, тбл_аренда!стоимость_аренды-тбл_ос1!стоимость*тбл_ос1!коэффициент_амортизации*зпр_длительность_аренды_по_контрактам!длительность_аренды_в_днях/365 AS прибыль_от_аренды, (тбл_ос1!стоимость*тбл_ос1!коэффициент_амортизации*зпр_длительность_аренды_по_контрактам!длительность_аренды_в_днях/365)/[прибыль_от_аренды] AS затратоемкость_контрактовFROM тбл_ос1 INNER JOIN (тбл_аренда INNER JOIN зпр_длительность_аренды_по_контрактам ON тбл_аренда.код_аренды = зпр_длительность_аренды_по_контрактам.код_аренды) ON тбл_ос1.код_ос1 = тбл_аренда.объект_аренды;  
  Запрос «зпр_затратоемкость_моделей»:
  SELECT тбл_ос1.код_ос1, тбл_ос1.модель, Sum(тбл_аренда!стоимость_аренды-тбл_ос1!стоимость*тбл_ос1!коэффициент_амортизации*зпр_длительность_аренды_по_контрактам!длительность_аренды_в_днях/365) AS прибыль_от_аренды, ([стоимость]*[срок_фактической_эксплуатации]*[коэффициент_амортизации])/[прибыль_от_аренды] AS затратоемкость_моделейFROM тбл_ос1 INNER JOIN (тбл_аренда INNER JOIN зпр_длительность_аренды_по_контрактам ON тбл_аренда.код_аренды = зпр_длительность_аренды_по_контрактам.код_аренды) ON тбл_ос1.код_ос1 = тбл_аренда.объект_арендыGROUP BY тбл_ос1.код_ос1, тбл_ос1.модель, ([стоимость]*[срок_фактической_эксплуатации]*[коэффициент_амортизации])/[прибыль_от_аренды], тбл_ос1.стоимость, тбл_ос1.срок_фактической_эксплуатации, тбл_ос1.коэффициент_амортизации;  
  Запроса «зпр_норма_запаса_запчастей»:
  SELECT тбл_запчасти.код_запчасти, тбл_запчасти.система, тбл_запчасти.наименование_запчасти, тбл_запчасти!норма_на_то*зпр_наработка_до_то!удельная_наработка_до_то AS норма_запасаFROM тбл_запчасти, зпр_наработка_до_то; Формула запроса «зпр_норма_заказа_запчастей»:
  SELECT зпр_потребность_в_запчастях.код_запчасти, зпр_потребность_в_запчастях.система, зпр_потребность_в_запчастях.наименование_запчасти, зпр_потребность_в_запчастях.норма_заказаFROM зпр_потребность_в_запчастяхGROUP BY зпр_потребность_в_запчастях.код_запчасти, зпр_потребность_в_запчастях.система, зпр_потребность_в_запчастях.наименование_запчасти, зпр_потребность_в_запчастях.норма_заказаHAVING (((зпр_потребность_в_запчастях.норма_заказа)>0));  
  Приложение Г. Тексты макросов  
  Макрос «mkr_open_frm_about_and_close_frm_main»:
  Function mkr_open_frm_about_and_close_frm_main()On Error GoTo mkr_open_frm_about_and_close_frm_main_Err   DoCmd.OpenForm "фрм_о_программе", acNormal, "", "", , acNormal   DoCmd.Close acForm, "фрм_главная"mkr_open_frm_about_and_close_frm_main_Exit:   Exit Functionmkr_open_frm_about_and_close_frm_main_Err:   MsgBox Error$   Resume mkr_open_frm_about_and_close_frm_main_ExitEnd Function  
  Макрос «mkr_open_frm_main_and_close_frm_about»:
  Function mkr_open_frm_main_and_close_frm_about()On Error GoTo mkr_open_frm_main_and_close_frm_about_Err   DoCmd.OpenForm "фрм_главная", acNormal, "", "", , acNormal   DoCmd.Close acForm, "фрм_о_программе" mkr_open_frm_main_and_close_frm_about_Exit:   Exit Functionmkr_open_frm_main_and_close_frm_about_Err:   MsgBox Error$   Resume mkr_open_frm_main_and_close_frm_about_ExitEnd Function  
  Макрос «exit»:
  Function mkr_exit()On Error GoTo mkr_exit_Err   DoCmd.Quit acSavemkr_exit_Exit:   Exit Functionmkr_exit_Err:   MsgBox Error$   Resume mkr_exit_ExitEnd Function  
  Макрос «mkr_open_frm_input_data»:
  Function mkr_open_frm_input_data()On Error GoTo mkr_open_frm_input_data_Err   DoCmd.OpenForm "фрм_ввод_данных", acNormal, "", "", , acNormal   DoCmd.Close acForm, "фрм_главная"mkr_open_frm_input_data_Exit:   Exit Functionmkr_open_frm_input_data_Err:   MsgBox Error$   Resume mkr_open_frm_input_data_ExitEnd Function  
  Макрос «mkr_open_frm_oc1»:
  Function mkr_open_frm_oc1()On Error GoTo mkr_open_frm_oc1_Err   DoCmd.OpenForm "фрм_ос1", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_oc1_Exit:   Exit Functionmkr_open_frm_oc1_Err:   MsgBox Error$   Resume mkr_open_frm_oc1_ExitEnd Function  
  Макрос «mkr_open_frm_arenda»:
  Function mkr_open_frm_arenda()On Error GoTo mkr_open_frm_arenda_Err   DoCmd.OpenForm "фрм_аренда", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_arenda_Exit:   Exit Functionmkr_open_frm_arenda_Err:   MsgBox Error$   Resume mkr_open_frm_arenda_ExitEnd Function  
  Макрос «mkr_open_frm_remont»:
  Function mkr_open_frm_remont()On Error GoTo mkr_open_frm_remont_Err   DoCmd.OpenForm "фрм_ремонты", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_remont_Exit:   Exit Functionmkr_open_frm_remont_Err:   MsgBox Error$   Resume mkr_open_frm_remont_ExitEnd Function  
  Макрос «mkr_open_frm_zakaz_zapch»:
  Function mkr_open_frm_zakaz_zapch()On Error GoTo mkr_open_frm_zakaz_zapch_Err   DoCmd.OpenForm "фрм_заказы_запчастей", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_zakaz_zapch_Exit:   Exit Functionmkr_open_frm_zakaz_zapch_Err:   MsgBox Error$   Resume mkr_open_frm_zakaz_zapch_ExitEnd Function  
  Макрос «mkr_open_frm_postavki»:
  Function mkr_open_frm_postavki()On Error GoTo mkr_open_frm_postavki_Err   DoCmd.OpenForm "фрм_поставки", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_postavki_Exit:   Exit Functionmkr_open_frm_postavki_Err:   MsgBox Error$   Resume mkr_open_frm_postavki_ExitEnd Function  
  Макрос «mkr_open_frm_peredacha_zapchast»:
  Function mkr_open_frm_peredacha_zapchast()On Error GoTo mkr_open_frm_peredacha_zapchast_Err   DoCmd.OpenForm "фрм_передача_запчастей", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_peredacha_zapchast_Exit:   Exit Functionmkr_open_frm_peredacha_zapchast_Err:   MsgBox Error$   Resume mkr_open_frm_peredacha_zapchast_ExitEnd Function  
  Макрос «mkr_open_frm_types»:
  Function mkr_open_frm_types()On Error GoTo mkr_open_frm_types_Err   DoCmd.OpenForm "фрм_типы", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_types_Exit:   Exit Functionmkr_open_frm_types_Err:   MsgBox Error$   Resume mkr_open_frm_types_ExitEnd Function  
  Макрос «mkr_open_frm_models»:
  Function mkr_open_frm_models()On Error GoTo mkr_open_frm_models_Err   DoCmd.OpenForm "фрм_модели", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_models_Exit:   Exit Functionmkr_open_frm_models_Err:   MsgBox Error$   Resume mkr_open_frm_models_ExitEnd Function  
  Макрос «mkr_open_frm_arendators»:
  Function mkr_open_frm_arendators()On Error GoTo mkr_open_frm_arendators_Err   DoCmd.OpenForm "фрм_арендаторы", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_arendators_Exit:   Exit Functionmkr_open_frm_arendators_Err:   MsgBox Error$  Resume mkr_open_frm_arendators_ExitEnd Function  
  Макрос «mkr_open_frm_systems»:
  Function mkr_open_frm_systems()On Error GoTo mkr_open_frm_systems_Err   DoCmd.OpenForm "фрм_системы", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_systems_Exit:   Exit Functionmkr_open_frm_systems_Err:   MsgBox Error$   Resume mkr_open_frm_systems_ExitEnd Function  
  Макрос «mkr_open_frm_zapchast»:
  Function mkr_open_frm_zakaz_zapchast()On Error GoTo mkr_open_frm_zakaz_zapchast_Err  DoCmd.OpenForm "фрм_заказы_запчастей", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_zakaz_zapchast_Exit:   Exit Functionmkr_open_frm_zakaz_zapchast_Err:   MsgBox Error$   Resume mkr_open_frm_zakaz_zapchast_ExitEnd Function  
  Макрос «mkr_open_frm_postavshiki»:
  Function mkr_open_frm_postavshiki()On Error GoTo mkr_open_frm_postavshiki_Err   DoCmd.OpenForm "фрм_поставщики", acNormal, "", "", , acNormal   DoCmd.GoToRecord , "", acNewRecmkr_open_frm_postavshiki_Exit:   Exit Functionmkr_open_frm_postavshiki_Err:   MsgBox Error$   Resume mkr_open_frm_postavshiki_ExitEnd Function  
  Макрос «mkr_open_frm_prosmotr_otchetov»:
  Function mkr_open_frm_prosmotr_otchetov()On Error GoTo mkr_open_frm_prosmotr_otchetov_Err  DoCmd.OpenForm "фрм_просмотр_отчетов", acNormal, "", "", , acNormal   DoCmd.Close acForm, "фрм_главная"mkr_open_frm_prosmotr_otchetov_Exit:   Exit Functionmkr_open_frm_prosmotr_otchetov_Err:   MsgBox Error$   Resume mkr_open_frm_prosmotr_otchetov_ExitEnd Function Макрос «mkr_open_zpr_tech_v_nal»:
  Function mkr_open_zpr_tech_v_nal()On Error GoTo mkr_open_zpr_tech_v_nal_Err   DoCmd.OpenQuery "зпр_техника_в_наличии", acViewPreview, acReadOnlymkr_open_zpr_tech_v_nal_Exit:   Exit Functionmkr_open_zpr_tech_v_nal_Err:   MsgBox Error$   Resume mkr_open_zpr_tech_v_nal_ExitEnd Function  
  Макрос «mkr_open_zpr_v_arend»:
  Function mkr_open_zpr_v_arend()On Error GoTo mkr_open_zpr_v_arend_Err   DoCmd.OpenQuery "зпр_техника_в_аренде", acViewPreview, acReadOnlymkr_open_zpr_v_arend_Exit:   Exit Functionmkr_open_zpr_v_arend_Err:   MsgBox Error$   Resume mkr_open_zpr_v_arend_ExitEnd Function  
  Макрос «mkr_open_zpr_technika_v_remonte»:
  Function mkr_open_zpr_technika_v_remonte()On Error GoTo mkr_open_zpr_technika_v_remonte_Err   DoCmd.OpenQuery "зпр_техника_в_ремонте", acViewPreview, acReadOnlymkr_open_zpr_technika_v_remonte_Exit:   Exit Functionmkr_open_zpr_technika_v_remonte_Err:   MsgBox Error$   Resume mkr_open_zpr_technika_v_remonte_ExitEnd Function  
  Макрос «mkr_open_zpr_dlit_arend»:
  Function mkr_open_zpr_dlit_arend()On Error GoTo mkr_open_zpr_dlit_arend_Err   DoCmd.OpenQuery "зпр_длительность_аренды_по_ос", acViewPreview, acReadOnlymkr_open_zpr_dlit_arend_Exit:   Exit Functionmkr_open_zpr_dlit_arend_Err:   MsgBox Error$   Resume mkr_open_zpr_dlit_arend_ExitEnd Function  
  Макрос «mkr_open_zpr_prosr_arenda»:
  Function mkr_open_zpr_prosr_arenda()On Error GoTo mkr_open_zpr_prosr_arenda_Err   DoCmd.OpenQuery "зпр_простроченная_аренда", acViewPreview, acReadOnlymkr_open_zpr_prosr_arenda_Exit:   Exit Functionmkr_open_zpr_prosr_arenda_Err:   MsgBox Error$   Resume mkr_open_zpr_prosr_arenda_ExitEnd Function  
  Макрос: «mkr_open_zpr_amortiz»:
  Function mkr_open_zpr_amortiz()On Error GoTo mkr_open_zpr_amortiz_Err   DoCmd.OpenQuery "зпр_амортизация_за_год", acViewPreview, acReadOnlymkr_open_zpr_amortiz_Exit:   Exit Functionmkr_open_zpr_amortiz_Err:   MsgBox Error$   Resume mkr_open_zpr_amortiz_ExitEnd Function  
  Макрос «mkr_open_zpr_ostat_stoim»:
  Function mkr_open_zpr_ostat_stoim()On Error GoTo mkr_open_zpr_ostat_stoim_Err   DoCmd.OpenQuery "зпр_остаточная_стоимость", acViewPreview, acReadOnlymkr_open_zpr_ostat_stoim_Exit:   Exit Functionmkr_open_zpr_ostat_stoim_Err:   MsgBox Error$   Resume mkr_open_zpr_ostat_stoim_ExitEnd Function  
  Макрос «mkr_open_zpr_prib_arendator»:
  Function mkr_open_zpr_prib_arendator()On Error GoTo mkr_open_zpr_prib_arendator_Err   DoCmd.OpenQuery "зпр_прибыль_от_аренды_по_арендаторам", acViewPreview, acReadOnlymkr_open_zpr_prib_arendator_Exit:   Exit Functionmkr_open_zpr_prib_arendator_Err:   MsgBox Error$   Resume mkr_open_zpr_prib_arendator_ExitEnd Function  
  Макрос «mkr_open_zpr_prib_arendator»:
  Function mkr_open_zpr_prib_arendator()On Error GoTo mkr_open_zpr_prib_arendator_Err   DoCmd.OpenQuery "зпр_прибыль_от_аренды_по_арендаторам", acViewPreview, acReadOnlymkr_open_zpr_prib_arendator_Exit:   Exit Functionmkr_open_zpr_prib_arendator_Err:   MsgBox Error$   Resume mkr_open_zpr_prib_arendator_ExitEnd Function  
  Макрос «mkr_open_zpr_dlit_rem_po_oc»:
  Function mkr_open_zpr_dlit_rem_po_oc()On Error GoTo mkr_open_zpr_dlit_rem_po_oc_Err   DoCmd.OpenQuery "зпр_длительность_ремонта_по_ос", acViewPreview, acReadOnlymkr_open_zpr_dlit_rem_po_oc_Exit:   Exit Functionmkr_open_zpr_dlit_rem_po_oc_Err:   MsgBox Error$   Resume mkr_open_zpr_dlit_rem_po_oc_ExitEnd Function  
  Макрос «mkr_open_zpr_dlit_rem_podrobno»:
  Function mkr_open_zpr_dlit_rem_podrobno()On Error GoTo mkr_open_zpr_dlit_rem_podrobno_Err   DoCmd.OpenQuery "зпр_длительность_ремонтов_подробно", acViewPreview, acReadOnlymkr_open_zpr_dlit_rem_podrobno_Exit:   Exit Functionmkr_open_zpr_dlit_rem_podrobno_Err:   MsgBox Error$   Resume mkr_open_zpr_dlit_rem_podrobno_ExitEnd Function  
  Макрос «mkr_open_zpr_zatrat_na_rem_po_oc»:
  Function mkr_open_zpr_zatrat_na_rem_po_oc()On Error GoTo mkr_open_zpr_zatrat_na_rem_po_oc_Err   DoCmd.OpenQuery "зпр_затраты_на_ремонт_по_ос", acViewPreview, acReadOnlymkr_open_zpr_zatrat_na_rem_po_oc_Exit:   Exit Functionmkr_open_zpr_zatrat_na_rem_po_oc_Err:   MsgBox Error$   Resume mkr_open_zpr_zatrat_na_rem_po_oc_ExitEnd Function  
  Макрос «mkr_open_zpr_zatrat_po_types»:
  Function mkr_open_zpr_zatrat_po_types()On Error GoTo mkr_open_zpr_zatrat_po_types_Err   DoCmd.OpenQuery "зпр_затраты_на_ремонт_по_типам", acViewPreview, acReadOnlymkr_open_zpr_zatrat_po_types_Exit:   Exit Functionmkr_open_zpr_zatrat_po_types_Err:   MsgBox Error$   Resume mkr_open_zpr_zatrat_po_types_ExitEnd Function  
  Макрос «mkr_open_zpr_kolichestvo_remontov»:
  Function mkr_open_zpr_kolichestvo_remontov()On Error GoTo mkr_open_zpr_kolichestvo_remontov_Err   DoCmd.OpenQuery "зпр_количество_ремонтов", acViewPreview, acReadOnlymkr_open_zpr_kolichestvo_remontov_Exit:   Exit Functionmkr_open_zpr_kolichestvo_remontov_Err:   MsgBox Error$   Resume mkr_open_zpr_kolichestvo_remontov_ExitEnd Function  
  Макрос «mkr_open_zpr_ydeln_remont»:
  Function mkr_open_zpr_ydeln_remont()On Error GoTo mkr_open_zpr_ydeln_remont_Err   DoCmd.OpenQuery "зпр_удельные_ремонты", acViewPreview, acReadOnlymkr_open_zpr_ydeln_remont_Exit:   Exit Functionmkr_open_zpr_ydeln_remont_Err:   MsgBox Error$   Resume mkr_open_zpr_ydeln_remont_ExitEnd Function  
  Макрос «mkr_open_zpr_narabotka_do_to»:
  Function mkr_open_zpr_narabotka_do_to()On Error GoTo mkr_open_zpr_narabotka_do_to_Err   DoCmd.OpenQuery "зпр_наработка_до_то", acViewPreview, acReadOnlymkr_open_zpr_narabotka_do_to_Exit:   Exit Functionmkr_open_zpr_narabotka_do_to_Err:   MsgBox Error$   Resume mkr_open_zpr_narabotka_do_to_ExitEnd Function  
  Макрос «mkr_open_zpr_zaka_ne_postavlen»:
  Function mkr_open_zpr_zaka_ne_postavlen()On Error GoTo mkr_open_zpr_zaka_ne_postavlen_Err   DoCmd.OpenQuery "зпр_заказано_но_не_поставлено", acViewPreview, acReadOnlymkr_open_zpr_zaka_ne_postavlen_Exit:   Exit Functionmkr_open_zpr_zaka_ne_postavlen_Err:   MsgBox Error$   Resume mkr_open_zpr_zaka_ne_postavlen_ExitEnd Function  
  Макрос «mkr_open_zpr_zapchesti_na_sklade»:
  Function mkr_open_zpr_zapchesti_na_sklade()On Error GoTo mkr_open_zpr_zapchesti_na_sklade_Err   DoCmd.OpenQuery "зпр_запчасти_на_складе", acViewPreview, acReadOnlymkr_open_zpr_zapchesti_na_sklade_Exit:   Exit Functionmkr_open_zpr_zapchesti_na_sklade_Err:   MsgBox Error$   Resume mkr_open_zpr_zapchesti_na_sklade_ExitEnd Function Макрос «mkr_open_zpr_zapchesti_na_sklade»:
  Function mkr_open_zpr_zaka_ne_peredan()On Error GoTo mkr_open_zpr_zaka_ne_peredan_Err   DoCmd.OpenQuery "зпр_заказано_поставлено_но_не_передано", acViewPreview, acReadOnlymkr_open_zpr_zaka_ne_peredan_Exit:   Exit Functionmkr_open_zpr_zaka_ne_peredan_Err:   MsgBox Error$   Resume mkr_open_zpr_zaka_ne_peredan_ExitEnd Function  
  Макрос «mkr_open_zpr_rent_po_contracts»:
  Function mkr_open_zpr_rent_po_contracts()On Error GoTo mkr_open_zpr_rent_po_contracts_Err   DoCmd.OpenQuery "зпр_рентабельность_контрактов", acViewPreview, acReadOnlymkr_open_zpr_rent_po_contracts_Exit:   Exit Functionmkr_open_zpr_rent_po_contracts_Err:   MsgBox Error$   Resume mkr_open_zpr_rent_po_contracts_ExitEnd Function  
  Макрос «mkr_open_zpr_rentab_model_techniki»:
  Function mkr_open_zpr_rentab_model_techniki()On Error GoTo mkr_open_zpr_rentab_model_techniki_Err   DoCmd.OpenQuery "зпр_рентабельность_моделей_техники", acViewPreview, acReadOnlymkr_open_zpr_rentab_model_techniki_Exit:   Exit Functionmkr_open_zpr_rentab_model_techniki_Err:   MsgBox Error$   Resume mkr_open_zpr_rentab_model_techniki_ExitEnd Function  Макрос «mkr_open_zpr_zatratoemkost_kontrakt»:
  Function mkr_open_zpr_zatratoemkost_kontrakt()On Error GoTo mkr_open_zpr_zatratoemkost_kontrakt_Err   DoCmd.OpenQuery "зпр_затратоемкость_контрактов", acViewPreview, acReadOnlymkr_open_zpr_zatratoemkost_kontrakt_Exit:  Exit Functionmkr_open_zpr_zatratoemkost_kontrakt_Err:   MsgBox Error$   Resume mkr_open_zpr_zatratoemkost_kontrakt_ExitEnd Function  
  Макрос «mkr_open_zpr_zatratoemkost_po_techn»:
  Function mkr_open_zpr_zatratoemkost_po_techn()On Error GoTo mkr_open_zpr_zatratoemkost_po_techn_Err   DoCmd.OpenQuery "зпр_затратоемкость_моделей", acViewPreview, acReadOnlymkr_open_zpr_zatratoemkost_po_techn_Exit:   Exit Functionmkr_open_zpr_zatratoemkost_po_techn_Err:   MsgBox Error$   Resume mkr_open_zpr_zatratoemkost_po_techn_ExitEnd Function  
  Макрос «mkr_open_zpr_norma_zapasa_zapchast»:
  Function mkr_open_zpr_norma_zapasa_zapchast()On Error GoTo mkr_open_zpr_norma_zapasa_zapchast_Err   DoCmd.OpenQuery "зпр_норма_запаса_запчастей", acViewPreview, acReadOnlymkr_open_zpr_norma_zapasa_zapchast_Exit:   Exit Functionmkr_open_zpr_norma_zapasa_zapchast_Err:   MsgBox Error$   Resume mkr_open_zpr_norma_zapasa_zapchast_ExitEnd Function  
  Макрос «mkr_open_zpr_norma_zakaza_zapchast»:
  Function mkr_open_zpr_norma_zakaza_zapchast()On Error GoTo mkr_open_zpr_norma_zakaza_zapchast_Err   DoCmd.OpenQuery "зпр_норма_заказа_запчастей", acViewPreview, acReadOnlymkr_open_zpr_norma_zakaza_zapchast_Exit:   Exit Functionmkr_open_zpr_norma_zakaza_zapchast_Err:   MsgBox Error$   Resume mkr_open_zpr_norma_zakaza_zapchast_ExitEnd Function  
  Приложение Д. Экранные формы  
  Рисунок Д.1 – Форма «фрм_главная»
   
  Рисунок Д.2 – Форма «фрм_о_программе»
   
  Рисунок Д.3 – Форма «фрм_ввод_данных»
   
  Рисунок Д.4 – Форма «фрм_ос1», обеспечивающая доступ к данным таблицы «тбл_ос1»
   
  Рисунок Д.5 – Форма «фрм_просмотр_отчетов»
  Приложение Е. Макеты представления исходящей информации  
  Рисунок Е.1 – Результат активации элемента управления «кнп_отк_тбл_аренда»
   
  Рисунок Е.2 – результат активации элемента управления «кнп_отк_зпр_длительность_аренды»
   
  Рисунок Е.3 – Результат активации элемента управления «кнп_отк_запр_амортизация_за_год»
   
  Рисунок Е.4 – Результат активации элемента управления «кнп_отк_зпр_прибыль_по_арендаторам»
   
  Рисунок Е.5 – Результат активации элемента управления «кнп_отк_зпр_длительность_ремонтов_подробно»
   
  Рисунок Е.6 – Результат активации элемента управления «кнп_отк_зпр_затраты_по_ос»
   
  Рисунок Е.7 – Результат активации элемента управления «кнп_отк_зпр_затраты_по_типам»
   
  Рисунок Е.8 – Результат активации элемента управления «кнп_отк_зпр_количество_ремонтов»
   
  Рисунок Е.9 – Результат активации элемента управления «кнп_отк_зпр_удельные_ремонты»
   
  Рисунок Е.10 – Результат активации элемента управления «кнп_отк_зпр_затратоемкость_по_контрактам»
   
  Рисунок Е.11 – Результат активации элемента управления «кнп_отк_зпр_затратоемкость_по_технике»
   
  Рисунок Е.12 – Результат активации элемента управления «кнп_отк_зпр_норма_заказа_запчастей»
   
  Рисунок Е.13 – Пример визуализации
Скачать дипломную работу