курсовые,контрольные,дипломы,рефераты
I. Специальная часть. XE "СПЕЦИАЛЬНАЯ ЧАСТЬ."
Глава 1. Основная часть
1.1. Содержание и требования, предъявляемые к информации 3
1.2. Значение внутрифирменной системы информации 4
1.3. Основные принципы, цели, задачи и функции внутрифирменной системы информации 6
1.4. Технические средства, используемые во внутрифирменной системе информации 7
1.5. Система ведения записей 8
1.6. Формы как носители информации 8
Глава 2. Информационные базы данных
2.1. Реляционные базы данных 10
2.1.2. Независимость 12
2.2. Проектирование баз данных 18
2.3. Нормализация. 22
3.1. Задачи, выполняемые приложением «Бухгалтерия». 26
3.2. Технические требования, предъявляемые к базе данных. 27
3.3. Выбор системы проектирования и реализации. 27
3.4. Проектирование структуры данных. 29
3.4.1. Описание структуры данных проекта. 31
3.5. Техническая реализация проекта. 39
3.5.1. Общее описание работы с приложением. 39
3.5.2. Формы отчетности (счетов, актов, счетов-фактур, накладных). 41
3.5.3. Сервисные функции. 42
3.5.4. Описание структуры программы. 42
Заключение. Оценка качества программного обеспечения. 95
Метрики Боэма, Брауна и Лайпоу. 96
Метрики программного обеспечения Джилба. 97
Оценка сложности Маккейба. 98
Понимеемость. 99
Выводы. 99
Список литературы к специальной части. 101
II. Организационно-экономическая часть. 122
III. Охрана труда и экология. 128
V. Эргономика 144
Введение.
Целью данного дипломного проекта является разработка системы автоматизации документооборота для малого коммерческого предприятия работающего в сфере информационных услуг. Исходя из современных требований, предъявляемых к качеству работы финансового звена малого предприятия, нельзя не отметить, что эффективная работа его всецело зависит от уровня оснащения офиса компании электронным оборудованием, таким, как компьютеры, программным обеспечением, средствами связи, копировальными устройствами.
В этом ряду особое место занимают базы данных и другое программное обеспечение, связанное с их использованием в качестве инструмента для делопроизводства и рационализации финансового труда. Их использование позволяет сократить время, требуемое на подготовку конкретных маркетинговых и производственных проектов, уменьшить непроизводительные затраты при их реализации, исключить возможность появления ошибок в подготовке бухгалтерской, технологической и других видов документации, что дает для малого предприятия прямой экономический эффект.
Разумеется, для раскрытия всех потенциальных возможностей, которые несет в себе использование баз данных, необходимо применять в работе комплекс программных и аппаратных средств максимально соответствующий поставленным задачам. Поэтому в настоящее время велика потребность малых предприятий в компьютерных программах, поддерживающих и согласующих работу управленческого и финансового звеньев компании, а также в информации о способах оптимального использования имеющегося у компании компьютерного оборудования.
1. Основная часть.
1.1 Содержание и требования, предъявляемые к информации.
В современных условиях важной областью стало информационное обеспечение, которое состоит в сборе и переработке информации, необходимой для принятия обоснованных управленческих решений. Передача информации о положении и деятельности предприятия на высший уровень управления и взаимный обмен информацией между всеми взаимными подразделениями фирмы осуществляются на базе современной электронно-вычислительной техники и других технических средствах связи.
В деятельности коммерческих структур, представляющих собой комплексы большого числа повседневно связанных и взаимодействующих подразделений, передача информации является первостепенным и непременным фактором нормального функционирования данной структуры. При этом особое значение приобретает обеспечение оперативности и достоверности информации. Для многих фирм внутрифирменная система информации решает задачи организации технологического процесса и носит производственный характер. Это касается, прежде всего, процессов обеспечения предприятий кооперированной продукцией, поступающей со специализированных подразделений по внутрифирменным каналам. Здесь информация играет важную роль в предоставлении сведений для принятия управленческих решений и является одним из факторов, обеспечивающих снижение издержек производства и повышение его эффективности.
Соответственную роль в принятии решений играет научно-техническая информация, содержащая новые научные знания, сведения об изобретениях, технических новинках своей фирмы, а также, фирм-конкурентов. Это непрерывно пополняемый общий фонд и потенциал знаний и технических решений, практическое и своевременное использование которого обеспечивает фирме высокий уровень конкурентоспособности.
Информация служит основой для подготовки соответствующих докладов, отчетов, предложений для выработки и принятия соответствующих решений.
Содержание каждой конкретной информации определяется потребностями управленческих звеньев и вырабатываемых управленческих решений. К информации предъявляются определенные требования:
— по объекту и качеству — краткость и четкость формулировок, своевременность поступления;
— по целенаправленности — удовлетворение конкретных потребностей;
— по точности и достоверности — правильный отбор первичных сведений, оптимальность систематизации и непрерывность сбора и обработки сведений.
1.2. Значение внутрифирменной системы информации.
Для современных условий характерно применение высокоэффективной внутрифирменной системы информации, основанной на использовании новейших технических средств автоматизированной обработки цифровой и текстовой информации на базе компьютеров с процессорами Intel Pentium, объединенных в локальную единую внутрифирменную вычислительную сеть
Управленческая и финансовая внутрифирменная информационная система представляет собой совокупность информационных процессов, для удовлетворения потребности в информации разных уровней принятия решений.
Информационная система состоит из компонентов обработки информации, внутренних и внешних каналов передачи.
Управленческие информационные системы последовательно реализуют принципы единства информационного процесса, информации и организации путем применения технических средств сбора, накопления, обработки и передачи информации.
В производственно-хозяйственном подразделении предприятия обеспечивается обобщение информации “снизу вверх”, а также, конкретизация информации “сверху вниз”.
Информационный процесс, направленный на получение научно-технической, плановой, контрольной, учетной и аналитической информации, в информационных системах унифицирован и базируется на электронно-вычислительной технике.
Повышение эффективности использования информационных систем достигается путем сквозного построения и совместимости информационных систем, что позволяет устранить дублирование и обеспечить многократное использование информации, установить определенные интеграционные связи, ограничить количество показателей, уменьшить объем информационных потоков, повысить степень использования информации. Информационное обеспечение предполагает: распространение информации, т.е. предоставление пользователям информации, необходимой для решения научно-производственных задач; создание наиболее благоприятных условий для распространения информации, т.е. проведение административно-организационных, научно-исследовательских и производственных мероприятий, обеспечивающих ее эффективное распространение.
Информация, и, особенно, ее автоматизированная обработка, является важным фактором повышения эффективности производства.
Важную роль в исполнении информации играют способы ее регистрации, обработки, накопления и передачи; систематизированное хранение информации и выдача ее в требуемой форме; производство новой числовой, графической и иной информации.
В современных условиях в крупных организациях созданы и эффективно действуют информационные системы, обслуживающие процесс подготовки и принятия управленческих решений и решающие следующие задачи: обработка данных, обработка информации, реализация интеллектуальной деятельности.
Для определения эффективности внутрифирменной системы управления на многих предприятиях в учете и отчетности стал использоваться показатель — отношение получаемой прибыли к затратам на технические средства и обеспечение функционирования внутрифирменной системы информации.
1.3. Основные принципы, цели, задачи и функции внутрифирменной системы информации.
Основными принципами и целями внутрифирменных систем информации являются:
1.Определение требований к содержанию информации и ее характеру в зависимости от целенаправленности;
2.Выработка системы хранения, использования и предоставления информации в централизованном и децентрализованном управлении;
3.Определение потребностей в технических средствах (в том числе, в компьютерной технике) на предприятии в целом;
4.Разработка программного обеспечения, создание и использование банков данных;
5.Автоматизированная обработка и выдача текстовой информации;
6.Автоматизация административно-управленческого труда на основе использования компьютерной техники.
Важными задачами внутрифирменной системы управления являются:
— координация деятельности по сбору и обработке данных финансовых отчетов на высшем уровне управления и в производственных отделениях в целях повышения качества и своевременности поступления финансовой информации по предприятию в целом;
— определение основных направлений системы сбора, обработки и хранения первичных данных;
— определение основных направлений развития технологии обработки информации.
Определение потребностей каждого руководителя в необходимой ему конкретной информации — чрезвычайно сложная задача, и ее решение зависит от опыта и функций руководителя, а также, от его полномочий в принятии управленческих решений.
Оснащение электронной техникой позволяет экономить управленческие и накладные расходы, значительно повышает эффективность проектно-конструкторских работ, обеспечивает эффективное внутрифирменное планирование.
Для современных условий наиболее характерно использование электронной техники в двух основных направлениях:
— в конторском деле — для замены секретарей-машинисток и делопроизводителей;
— в бухгалтерском деле — для составления письменных финансовых документов, осуществления без кассовых связей с банками и финансовыми учреждениями.
1.4. Технические средства, используемые во внутрифирменной системе информации
Во внутрифирменной системе информации используются, прежде всего, такие виды вычислительной техники, как компьютеры ,оснащенные необходимым набором периферии, электронные пишущие машинки, терминальные устройства со встроенной микро-ЭВМ, средства телекоммуникаций, средства автоматизированной обработки текстовой информации и, прежде всего ЭВМ — как крупногабаритные, так и персональные.
ЭВМ используются, прежде всего, для обработки данных и решения расчетных задач. В современных условиях ЭВМ стали все чаще применять для обработки нечисловой информации (текстовой, графической) и термин “вычислительная техника” перестал соответствовать характеру задач, решаемых с помощью компьютера.
Современные ЭВМ способны одновременно обрабатывать цифровую, текстовую и графическую информацию.
В процессе автоматизации управления мини-ЭВМ используются, преимущественно, для:
— разработки оперативных планов производства и контроля за их выполнением;
— контроля движения запасов материалов, необходимых для процесса производства;
— расчета заработной платы;
— контроля над поступлением заказов;
— анализа данных о сбыте продукции;
— регистрации поступления платежей;
— ведения учета и отчетности.
Развитие систем телекоммуникаций и, в частности, технологий локальных вычислительных сетей, позволило объединить все технические средства обработки цифровой и текстовой информации в единую внутрифирменную информационную систему. Наиболее эффективной системой информации считается система, основанная на одновременном использовании вычислительной техники и средств автоматизированной обработки текстовой информации, объединенных в одну систему.
1.5. Система ведения записей.
На основе специальных программ, направленных на облегчение доступа и использования требуемой информации разрабатываются системы введения записей. К важнейшим видам записей относятся:
— данные учета и финансовой отчетности, финансовая документация;
— расчеты заработной платы рабочих и служащих;
— тексты контрактов и сопроводительная документация;
— тексты годовых отчетов и протоколы собраний акционеров;
— данные для разработки планов и показатели самих планов.
Обычно записи первичных данных делят на две группы:
1.Статистические (финансовые) отчетные показатели, а также, текстовая информация — доклады, сообщения, отчеты о текущей хозяйственной деятельности фирмы и перспективах развития;
2.Составленные на основе информации первой группы предложения и рекомендации по вопросам совершенствования управления предприятием в целом и по отдельным подразделениям.
1.6. Формы как носители информации.
Обычно необходимая информация заносится на определенные формы-носители информации. Формы могут содержать информацию по предприятию в целом и по каждому подразделению в отдельности. Каждая форма имеет свой перечень статистических данных и фактологический информации, позволяющих произвести оптимально детальный экономический анализ состояния и развития хозяйственной деятельности предприятия, разработать и принять необходимые управленческие решения. Так, например, существуют формы, в которые заносятся данные, о выпуске и продаже продукции за установленный период времени; о материально-производственных ресурсах (запасах); о численности персонала и наличии свободных рабочих мест.
Различают следующие виды бланков форм: формы для хранения информации, формы регистрации данных, формы статистической (финансовой) отчетности, формы обследований.
Заполненные формы хранятся в памяти ЭВМ и при необходимости могут быть выведены на экран дисплея или получены путем распечатки на принтере. В случае необходимости размножения заполненной и хранящейся в ЭВМ формы это делается с помощью копирующего устройства той же ЭВМ.
Поскольку потребности в получаемой информации и ее содержание у управленческого персонала фирмы постоянно меняются в зависимости от изменяющихся внутренних условий, возникает необходимость в постоянном уточнении и переработке форм, содержащих первичные данные.
2. Информационные базы данных.
Информационные базы данных включают весь комплекс статистических показателей, характеризующих хозяйственную деятельность предприятия в целом, а также, фактологический материал относительно всех факторов, оказывающих влияние на состояние и тенденции развития предприятия. Обычно, при формировании базы данных, решается вопрос и о системе хранения и обновления данных, а также, обоснованная увязка данных, их взаимная согласованность, возможность проведения сравнений и сопоставления оценок, хранимых в банке данных. Данный вопрос имеет существенное значение при объединении первичных данных в укрупненные группы (файлы) со своими реквизитами. Базы данных непрерывно обновляются на определенной систематической основе с учетом требований менеджеров, бухгалтеров — основных пользователей базой данных.
Во многих организациях и предприятиях созданы базы данных, в которых хранится информация о состоянии финансового положения предприятия, о состоянии товарооборота на складе, о кадровом составе работников, постоянно обновляемая и максимально подробная, систематизированная по самым разнообразным признакам. Выбор информации делается с выводом на печатающее устройство отчетов, что позволяет следить за балансом предприятия, перемещением финансовых средств, делать прогнозы о будущем развитии.
Пользование банками данных, введенных в ЭВМ, резко ускоряет процесс получения информации из круга источников первичной информации и обеспечивает возможность выбора правильного и точного метода исследований для решения современных научных и технических проблем.
Комплексная автоматизированная обработка информации предполагает объединение в единый комплекс всех технических средств обработки информации с использованием новейшей технологии, методологии и различных процедур по обработке информации.
Создание комплексной автоматизированной системы предполагает использование всего комплекса технических средств обработки информации, переход к единой системе обработки всех видов информации.
В последние годы устройства автоматизированной обработки текстовой информации стали широко использоваться руководителями всех уровней, которые на выведенном на экран документе делают свои замечания, ставят резолюции, что упрощает процесс согласования их действий, ускоряет процесс подготовки управленческих решений.
Всей внутрифирменной системой информации управляет, как правило, специализированный аппарат управления. В общем случае он включает в себя:
1. Вычислительный центр для обслуживания фирмы в целом;
2. Центральную службу информации;
3. Информационную систему в производственных подразделениях, включающую отделы: обработки и анализа информации, обработки входящей и выходящей документации, хранения и выдачи информационных материалов, вычислительной техники.
В случае малого предприятия данный аппарат управления, как правило, состоит из двух отделов:
1. Отдел автоматизации (отдел программирования);
2. Технический отдел (отдел сетевых разработок).
Могут создаваться, также, и центры хранения записей, где информация хранится на оптических носителях и может быть в кратчайший срок выдана по запросу через локальную вычислительную сеть.
Внедрение ЭВМ в информационно - управленческую деятельность фирм повлекло за собой возникновение и развитие новых видов профессиональной деятельности, связанных с обслуживанием ЭВМ, а именно программистов, операторов, обработчиков информации.
2.1. Реляционные базы данных
Все системы управления базами данных предназначены для хранения и обработки информации. Реляционный подход к управлению базами данных основан на математической модели, использующей методы реляционной алгебры и реляционного исчисления. Тем не менее большинство действительно необходимых определений из области управления базами данных скорее относятся к практической, чем к теоретической стороне этого вопроса.
С. Дейт дает следующее неформальное определение системе управления реляционными базами данных (СУБД).
· Вся информация в базе данных представлена в виде таблиц.
· Она поддерживает три реляционных оператора—выбора, проектирования и объединения, с помощью которых вы получаете необходимые вам данные (и можете выполнять эти операции, не требуя от системы физической записи получаемых с их помощью данных в каком-то определенном виде).
Др. И.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «правилами Кодда», требует введения сложной терминологии и теоретических выкладок, что выходит за рамки данного дипломного проекта. Тем не менее, опишем состоящий из 12 правил тест Кодда для реляционных систем, и будем использовать его совместно с общим определением Дейта.
Чтобы считаться реляционной, система управления базами данных должна:
· представлять всю информацию в виде таблиц,
· поддерживать логическую структуру данных, независимо от их физического представления,
· использовать язык высокого уровня для структурирования, выполнения запросов и изменения информации в базах данных (теоретически это может быть любой язык баз данных, практически для этого используется язык SQL),
· поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение,
· поддерживать виртуальные таблицы, обеспечивая пользователям альтернативный способ просмотра данных в таблицах,
· различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных,
· обеспечивать механизмы для поддержки целостности, авторизации, транзакций и восстановления данных.
Далее проведем аналитический обзор этих пунктов, ко многим из них будем обращаться в дальнейшем.
Первое правило Кодда гласит, что вся информация в реляционных базах данных представляется значениями в таблицах (tables). В реляционных системах таблицы состоят из горизонтальных строк (row) и вертикальных столбцов (column). Все данные представляются в табличном формате — другого способа просмотреть информацию в базе данных не существует. Несколько замечаний по терминологии. Поскольку такие понятия как таблица, строка и столбец являются общепринятыми в коммерческих системах управления реляционными базами данных, будем стараться использовать их в этом дипломном проекте. Однако иногда можно встретиться и с такими понятиями, как отношение (relations), кортеж (tuple) и атрибут (attributes). Это соответственно синонимы понятий таблица, строка и столбец, так же, как и файл (file), запись (record) и поле (field). Первые три считаются академическими терминами, последние—взяты из общего лексикона, используемого в области обработки данных. Набор связанных таблиц образует базу данных (database). Таблицы в реляционной базе разделены, но полностью равноправны. Между ними не существует никакой иерархии и, вообще говоря, они не обязательно даже физически связаны друг с другом.
Каждая таблица состоит из строк и столбцов. Каждая строка описывает отдельный объект или сущность (entity) человека, компанию, торговую сделку или что-нибудь другое. Каждый столбец описывает одну характеристику объекта—имя человека или его адрес, телефонный номер компании или ее президента, лоты распродажи или дату. Каждый элемент данных, или значение (value), определяется пересечением строки и столбца таблицы. Чтобы найти требуемый элемент данных, необходимо знать имя содержащей его таблицы, столбец и значение его первичного ключа (primary key), или уникального идентификатора (каждая строка должна единственным образом идентифицироваться по одному из своих значений.)
В реляционных базах данных существует два типа таблиц — пользовательские таблицы (user tables) и системные таблицы (system tables). Пользовательские таблицы содержат информацию, для поддержки которой собственно и создавались системы реляционных баз данных—данные по сделкам, заказам, персоналу и т.д. Системные таблицы, известные также под названием системные каталоги (system catalog), содержат описание базы данных. Системные таблицы обычно поддерживаются самой СУБД, однако доступ к ним можно получить так же, как и к любым другим таблицам. Возможность получения доступа к системным таблицам, по аналогии с любыми другими таблицами, составляет основу другого правила Кодда для реляционных систем.
Независимость данных — критический аспект при управлении любой системой баз данных. Она позволяет изменять приложения, не изменяя для этого структуру базы данных, и изменять конструкцию базы данных, не оказывая при этом влияния на работу приложений. Система управления базами данных не должна вынуждать выносить окончательные решения о том, какие данные должны сохраняться, как получать к ним доступ и что будет нужно пользователям. Система не должна становиться бесполезной при изменении потребностей.
Реляционная модель обеспечивает независимость данных на двух уровнях — физическом и логическом. Физическая независимость данных (physical data independents) означает с точки зрения пользователя, что представление данных абсолютно не зависит от способа их физического хранения. Как следствие этого, физическое перемещение данных никоим образом не может повлиять на логическую структуру базы данных и ваше восприятие данных. Такие изменения обычно становятся просто необходимыми, особенно в больших многопользовательских системах. Например, при недостатке места для хранения информации может потребоваться установка дополнительных физических носителей. Когда устройство выходит из строя,—увы, его приходится быстро заменять. Иногда может потребоваться увеличить производительность системы или упростить ее использование, изменив для этого методы доступа к физическим данным. (Эти методы связаны с созданием стратегии доступа (access strategies) и применением индексов (index).)
Другой тип независимости, обеспечиваемый реляционными системами—логическая независимость (logical independents) означает, что изменение взаимосвязей между таблицами, столбцами и строками не влияет на правильное функционирование программных приложений и текущих запросов. Можно разбивать таблицы по строкам или столбцам, а приложения и запросы все равно будут выполняться, как и раньше. Несмотря на изменение логической структуры базы данных, всегда можно воспользоваться старыми запросами. Требование логической и физической независимости данных составляет основу двух других правил Кодда.
Определение реляционной системы, так же, как и правила Кодда, требует, чтобы весь диалог с базой данных велся на едином языке — иногда его называют общим подъязыком данных (comprehensive data sublanguage). В мире коммерческих систем управления базами данных такой язык получил название SQL. SQL используется для манипуляций с данными (data manipulation) выборки и модификации, определения данных (data definition) и администрирования данных (data administration). Любая операция по выборке, модификации, определению или администрированию выполняется с помощью оператора (statement) или команды (command) SQL.
Имеется две разновидности операций по манипуляции с данными — выборка данных (data retrieval) и модификация данных (data modification). Выборка — это поиск необходимых вам данных, а модификация означает добавление, удаление или изменение данных. Операции по выборке (чаше называемые запросами (query)) осуществляют поиск в базе данных, наиболее эффективно извлекают затребованную вами информацию и отображают ее. Другие команды SQL предназначены для создания и удаления таблиц, индексов и других объектов.
Последняя категория операторов SQL—операторы администрирования, или команды управления данными (data control). Они позволяют вам координировать совместное использование базы данных и поддерживать ее в наиболее эффективном состоянии.
Одним из наиболее важных аспектов администрирования многопользовательских систем управления базами данных является управление доступом к данным.
В определении системы управления реляционными базами данных упоминаются три операции по выборке данных — проектирование, выбор (иногда называемый ограничением (restrictions)) и объединение, которые позволяют строго указать системе, какие данные вы хотите увидеть. Операция проектирования выбирает столбцы, операция выбора — строки, а операция объединения собирает вместе данные из связанных таблиц.
Логическая и физическая независимость, о которой мы упоминали выше, означает, что вам не нужно беспокоиться о физическом расположении данных и о том, как их искать — это проблемы исключительно систем управления базами данных.
Проектирование. Операция проектирования позволяет указать системе, какие
столбцы таблицы должны просматриваться. С концептуальной точки зрения: операция проектирования определяет подмножество столбцов в таблице. Обратите внимание, что результаты выполнения проектирования (как и любой другой реляционной операции) также отображаются в форме таблицы. Результирующие таблицы иногда называют производными таблицами (derived tables), чтобы отличать их от базовых таблиц (base tables), содержащих исходные строки данных.
Выбор. Операция выбора позволяет вам получать из таблицы подмножества ее строк. Чтобы указать, какие строки нужны, соответствующие условия нужно разместить в предложении WHERE. В предложении WHERE оператора SELECT определяется критерий, которому должны соответствовать выбираемые строки. Можно комбинировать в запросе операции проектирования и выбора, чтобы получить требуемую информацию.
Объединение. Операция объединения может работать одновременно с одной или несколькими таблицами, соединяя данные таким образом, что можно легко сопоставить или выделить определенную информацию в базе данных. Операция объединения обеспечивает SQL и реляционную модель необходимой мощностью и гибкостью. Можно выявить любую взаимосвязь, существующую между элементами данных, а не только связи, введенные при конструировании базы. Когда «объединяются» две таблицы, на период действия запроса они как бы становятся единой таблицей. Операция объединения соединяет данные, сравнивая значения в заданных столбцах и отражая результаты.
Курсор (view) - это альтернативный способ просмотра данных из нескольких таблиц. Курсоры иногда называются виртуальными таблицами (virtual tables), или производными таблицами. Таблицы, на основе которых работают курсоры, называются базовыми таблицами. Курсор можно рассматривать как перемещаемую по таблицам рамку, через которую можно увидеть только необходимую часть информации. Курсор можно получить из одной или нескольких таблиц базы данных (включая и другие курсоры), используя любые операции выбора, проектирования и объединения. Курсоры позволяют создавать таблицы для специальных целей. С их помощью можно использовать результаты выполнения операторов выбора, проектирования и объединения как основу для последующих запросов. Виртуальные таблицы, в отличие от «настоящих», или базовых таблиц, физически не хранятся в базе данных. Важно осознать, что курсор—это не копия некоторых данных, помещаемая в другую таблицу. Когда изменяются данные в виртуальной таблице, то тем самым изменяются данные в базовых таблицах. Подобно результатам операции выбора, курсоры напоминают обычные таблицы баз данных.
Если применить операцию выбора к виртуальной таблице, то можно увидеть результаты выполнения запроса, на основе которого она была создана. В идеальной реляционной системе с курсорами можно оперировать, как и с любыми другими таблицами. В реальном мире различные версии реляционных баз данных накладывают на курсоры определенные ограничения, в частности на обновление. Одно из правил Кодда гласит, что в истинно реляционной системе над курсорами можно выполнять все «теоретически» возможные операции. Большинство современных систем управления реляционными базами данных не удовлетворяют этому правилу полностью.
В реальном мире управления информацией данные часто являются неизвестными или неполными: клиент не предоставил данных о физическом адресе организации, счет может быть оформлен, но дата его оплаты еще может быть неизвестна. Такие пропуски информации создают «дыры» в таблицах.
Проблема, конечно, состоит не в простой неприглядности подобных дыр. Опасность состоит в том, что из-за них база может стать противоречивой. Чтобы сохранить целостность данных в реляционной модели, так же, как и в правилах Кодда, для обработки пропущенной информации используется понятие нуля. «Нуль» не означает пустое поле или обычный математический нуль. Он отображает тот факт, что значение неизвестно, недоступно или неприменимо. Существенно, что использование нулей инициирует переход с двухзначной логики (да/нет или что-то/ничего) на трехзначную (да/нет/может быть или что-то ничего не уверен).
С точки зрения другого эксперта по реляционным системам, Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее, они являются составной частью большинства официальных стандартов SQL и de facto промышленных стандартов.
Понятие безопасности связано с необходимостью управления доступом к информации. Определенные команды позволяют некоторым привилегированным пользователям устанавливать права других пользователей на просмотр и модификацию информации в базе данных. В большинстве реализаций реляционных баз данных правами на доступ и модификацию данных (permission) можно управлять на уровне таблиц и столбцов. Эти права устанавливают владельцы (owner) баз данных или объектов баз данных. Некоторые системы разрешают передавать права владения от создателя базы другому пользователю.
В многопользовательских системах обычно имеется пользователь с правами даже более высокими, чем у владельца базы данных—системный администратор (system administrator), или администратор базы данных (database administrator). Этот пользователь обычно обладает широкими правами на наделение полномочий, а также выполняет целый ряд других задач, связанных с поддержкой и администрированием базы данных.
В качестве дополнительного механизма обеспечения безопасности могут выступать и виртуальные таблицы. Пользователи могут разрешать доступ только к определенному подмножеству своих данных, включенному в виртуальную таблицу.
Целостность (integrity) - очень сложный и серьезный вопрос при управлении реляционными базами данных. Несогласованность между данными может возникать по целому ряду причин. Несогласованность или противоречивость данных может возникать вследствие сбоя системы—проблемы с аппаратным обеспечением, ошибки в программном обеспечении или логические ошибки в приложениях. Реляционные системы управления базами данных защищают данные от такого типа несогласованности, гарантируя, что команда либо будет исполнена до конца, либо будет полностью отменена. Этот процесс обычно называют управлением транзакциями (transaction management).
Другой тип целостности, называемый объектной целостностью (entity integrity), связан с корректным проектированием базы данных. Объектная целостность требует, чтобы ни один первичный ключ не имел нулевого значения. Третий тип целостности, называемый ссылочной целостностью (referential integrity), означает непротиворечивость между частями информации, повторяющимися в разных таблицах. Например, если вы изменяете неправильно введенный номер расчетного счета покупателя в одной таблице, другие таблицы, содержащие эту же информацию, продолжают ссылаться на старый номер, поэтому вы должны обновить и эти таблицы. Чрезвычайно важно, чтобы при изменении информации в одном месте, она соответственно изменялась и во всех других местах. Правила Кодда гласят, что системы управления реляционными базами данных должны обеспечивать не только объектную и ссылочную целостность, но и позволять «вводить дополнительные ограничения на целостность, отражающие специальные требования». Кроме того, по определению Кодда, ограничения на целостность должны:
· определяться на языке высокого уровня, используемом системой для всех других целей;
· храниться в словаре данных, а не в программных приложениях.
Первоначально только несколько реализаций реляционных баз данных удовлетворяли критериям Кодда на целостность, но ситуация постепенно изменялась. Стандарт 1992 года (часто называемый «SQL92») поддерживает ограничения, обеспечивающие ссылочную целостность и позволяющие задавать бизнес правила. Эти возможности в том или ином виде реализованы в большинстве систем.
2.2. Проектирование баз данных
Процесс, в ходе которого решается, какой вид будет у вновь создаваемой базы данных, называется проектированием базы данных (database design). Работа по проектированию базы данных включает выбор:
· таблиц, которые будут входить в базу данных,
· столбцов, принадлежащих каждой таблице,
· взаимосвязей между таблицами и столбцами.
Конструирование базы данных связано с построением ее логической структуры. В реляционной модели логическая структура базы абсолютно не зависит от ее физической структуры и способа хранения. Логическая структура также не определяется тем, что видит у себя на экране конечный пользователь (это могут быть виртуальные таблицы, созданные разработчиком или прикладными программами).
Конструирование баз данных на основе реляционной модели имеет ряд важных преимуществ перед другими моделями.
· Независимость логической структуры от физического и пользовательского представления.
· Гибкость структуры базы данных—конструктивные решения не ограничивают возможности выполнять в будущем самые разнообразные запросы.
Так как реляционная модель не требует описания всех возможных связей между данными, можно впоследствии задавать запросы о любых логических взаимосвязях, содержащихся в базе, а не только о тех, которые планировались первоначально.
С другой стороны, реляционные системы не имеют никаких встроенных защитных механизмов против некорректных структурных решений и не умеют различать хорошую структуру базы данных от посредственной. К тому же не существует автоматизированных средств, которые могли бы заменить вас в процессе принятия структурных решений.
Часто при обсуждении вопросов проектирования реляционных баз данных почти все внимание уделяется применению правил нормализации. В ходе нормализации обеспечивается защита целостности данных путем устранения дублирования данных. В результате таблица, которая первоначально казалась «имеющей смысл», разбивается на две или более связанных таблиц, которые могут быть «собраны вместе» с помощью операции объединения. Этот процесс называется декомпозицией без потерь (non-loss decomposition) и просто означает разделение таблицы на несколько меньших таблиц без потери информации. Нормализация наиболее полезна для проверки созданной вами структуры. Можно проанализировать свои решения о том, какие столбцы должны быть включены в ту или иную таблицу с точки зрения правил нормализации, убедившись при этом, что не сделали каких-то фатальных ошибок. Понимание основ процесса нормализации также может помочь в процессе проектирования базы данных, но оно не является универсальным рецептом при построении базы с нуля. Итак, как определить, какие столбцы должны располагаться в начале таблицы. Общего правила на этот счет не существует. Однако здесь вам может оказать существенную помощь моделирование зависимостей — анализ сущности данных (в терминах объектов или вещей) и зависимостей между ними (один-к-одному, один-ко-многим, многие-ко-многим).
На практике проектирование базы данных требует хорошего понимания моделируемой предметной области, а также знаний в области моделирования зависимостей и нормализации. Проектирование базы данных обычно является итеративным процессом, в ходе которого шаг за шагом достигается требуемый результат, а иногда и пересматривается несколько шагов, переделывая предыдущую работу с учетом появившихся новых потребностей. Вот примерная последовательность шагов выполняемая в процессе проектирования базы данных.
1. Исследования информационной среды для моделирования.
· Откуда поступает информация и в каком виде?
· Как она будет вводиться в систему и кто этим будет заниматься?
· Как часто она изменяется?
· Какие параметры системы будут наиболее критическими с точки зрения времени реакции на запрос и надежности?
· Изучение всех бумажных материалов, а также информационных файлов и форм, которые используются в организации для хранения и обработки данных.
· Уточнение, в каком виде информация должна извлекаться из базы данных — в форме отчетов, заказов, статистической информации.
· Кому она будет предназначаться.
2. Создание списка объектов (вещей, которые будут предметом базы данных) вместе с их свойствами и атрибутами. Объекты, скорее всего, должны быть собраны в таблицы (каждая строка таблицы будет описывать один объект, например организацию, счет или платежное поручение), свойства объектов будут представлены столбцами таблицы (например, адрес компании, стоимость дистрибутива).
3. В ходе работы обязательно должен создаваться макет таблиц и связей между ними, называемый структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).
4. Предварительно разобравшись с объектами и их атрибутами, надо убедится, что каждый объект имеет атрибут (или группу атрибутов), по которому однозначно можно идентифицировать любую строку в будущей таблице. Этот идентификатор обычно называется первичным ключом. Если такового нет, то для получения искусственного ключа следует создать дополнительный столбец.
5. Затем должны быть рассмотрены зависимости между объектами.
· Имеются ли зависимости типа один-ко-многим (один заказчик может иметь множество выписанных счетов, но каждый счет может быть выписан только на одного заказчика) или многие-ко-многим?
· Есть ли возможности для объединения связанных таблиц? Для этого служат внешние ключи (foreign key), столбцы в связанных таблицах с совпадающими значениями первичных ключей.
6. Анализ структуры базы данных с точки зрения правил нормализации для поиска логических ошибок. Исправление всех отклонений от нормальных форм или обоснование решения отказаться от выполнения ряда правил нормализации в интересах простоты освоения или производительности. Документирование причины таких решений.
7. Непосредственному создание структуры базы данных и помещению в нее некоторых прототипов данных. Обязательное экспериментирование с запросами, изучение полученных результатов. Выполнение рядов тестов на производительность, чтобы проверить разные технические решения.
8. Оцените базы данных с точки зрения того, удовлетворяют ли заказчика полученные результаты.
Хорошая структура — это, в первую очередь, «прозрачная» структура. Проще говоря, хорошая структура:
· максимально упрощает взаимодействие с базой данных;
· гарантирует непротиворечивость данных;
· «выжимает» максимум производительности из системы.
Некоторые факторы, упрощающие понимание базы данных, не имеют строгих технических определений и не являются частью процесса проектирования. Тем не менее, широкие таблицы трудно читать и в них сложно разбираться. В то же время разделение данных на целый ряд небольших таблиц усложняет отслеживание взаимосвязей между ними. Выбор подходящего числа столбцов обычно является компромиссом между простотой понимания базы и правилами нормализации. Хорошо разработанная база данных предотвращает ввод противоречивой информации и случайное удаление данных. Это достигается за счет минимизации ненужного дублирования данных в таблицах и поддержки целостности.
Наконец, хорошо разработанная база должна обладать достаточной производительностью. Опять-таки здесь играет большую роль число столбцов в таблицах: выборка данных будет проводиться медленнее, если информация размешена
не в одной, а в нескольких таблицах. Однако большие таблицы могут требовать
от системы обработки большего количества данных, чем это на самом деле необходимо для выполнения конкретного запроса. Другими словами, количество и размер таблиц существенно влияют на производительность. (Также с точки зрения производительности критическим является выбор столбца, по которому выполняется индексирование и тип индексирования.) Индексирование в большей мере является вопросом физического проектирования, нежели логического.
· приводит к непониманию результатов выполнения запросов;
· повышает риск введения в базу данных противоречивой информации;
· порождает избыточные данные;
· усложняет выполнение изменений структуры созданных ранее и уже заполненных данными таблиц.
Не существует идеального решения, полностью удовлетворяющего все требования, предъявляемые при проектировании баз данных. Часто приходится чем-то жертвовать, основываясь на требованиях и особенностях приложений, которые будут использовать базу данных.
2.3. Нормализация.
Вообще говоря, нормализация — это набор стандартов проектирования данных, называемых нормальным и формами (normal forms). Общепринятыми считаются пять нормальных форм, хотя их было предложено значительно больше. Создание таблиц в соответствии с этими стандартами называется нормализацией. Нормальные формы изменяются в порядке от первой до пятой. Каждая последующая форма удовлетворяет требования предыдущей. Если следовать первому правилу нормализации, то данные будут представлены в первой нормальной форме. Если данные удовлетворяют третьему правилу нормализации, они будут находиться в третьей нормальной форме (а также в первой и второй формах).
Выполнение правил нормализации обычно приводит к разделению таблиц на две или больше таблиц с меньшим числом столбцов, выделению отношений первичный ключ—внешний ключ в меньшие таблицы, которые снова могут быть соединены с помощью операции объединения.
Одним из основных результатов разделения таблиц в соответствии с правилами нормализации является уменьшение избыточности данных в таблицах. При этом в базе возможно возникновение одинаковых столбцов первичных и внешних ключей. Такое преднамеренное дублирование — это не то же самое, что избыточность. На самом деле поддержка непротиворечивости между первичными и внешними ключами связана с понятием целостности данных.
Правила нормализации, подобно принципам объектного моделирования, развивались в рамках теории баз данных. Большинство разработчиков баз данных признают, что представление данных в третьей и четвертой нормальных формах полностью удовлетворяет все их потребности.
Первая нормальная форма требует, чтобы на любом пересечении строки и столбца находилось единственное значение, которое должно быть атомарным. Кроме того, в таблице, удовлетворяющей первой нормальной форме, не должно быть повторяющихся групп.
В ряде случаев объектное моделирование приводит к тем же результатам, так как в этом случае мы имеем отношение один-ко-многим (одна накладная - много позиций).
Второе правило нормализации требует, чтобы любой не ключевой столбец зависел от всего первичного ключа. Следовательно, таблица не должна содержать не ключевых столбцов, зависящих только от части составного первичного ключа. Представление таблицы во второй нормальной форме требует, чтобы все столбцы, не являющиеся первичными ключами (столбцы, описывающие объект, но однозначно не идентифицирующие его), зависели от всего первичного ключа, а не от его отдельных компонентов.
Суммируя вышесказанное, вторая нормальная форма требует, чтобы ни один не ключевой столбец не зависел только от части первичного ключа. Это правило относится к случаю, когда первичный ключ образован из нескольких столбцов, и неприменимо, когда первичный ключ образован только из одного столбца.
Третья нормальная форма повышает требования второй нормальной формы: она не ограничивается составными первичными ключами. Третья нормальная форма требует, чтобы ни один не ключевой столбец не зависел от другого не ключевого столбца. Любой не ключевой столбец должен зависеть только от столбца первичного ключа.
Рассматривая структуру этих таблиц, вы увидите, что они удовлетворяют как второй, так и третьей нормальной форме. Они удовлетворяют второй нормальной форме, так как все не ключевые столбцы зависят от всего первичного ключа, и третьей нормальной форме, так как все не ключевые столбцы не зависят друг от друга. Другими словами, любой не ключевой столбец зависит от ключа, всего ключа и ничего, кроме ключа.
Четвертая нормальная форма запрещает независимые отношения типа один-ко-многим между ключевыми и не ключевыми столбцами. В качестве
примера рассмотрим несколько надуманный пример: с каждым заказчиком может работать несколько кураторов и несколько курьеров, но между кураторами и курьерами нет абсолютно никакой связи, хотя они естественным образом связаны с заказчиком. Помещение этой разнородной информации в одну таблицу может привести к появлению в ней пустых мест, так как курьеров может быть больше, чем кураторов. Удаление данных о курьерах или кураторах также может привести к появлению пустых мест. Проблема здесь состоит в кажущемся существовании зависимости между курьерами и кураторами, так как эти данные могут размещаются рядом в одной строке. Лучше было бы поместить их в разные таблицы и связать с заказчиком посредством внешнего ключа. Пятая нормальная форма доводит весь процесс нормализации до логического конца, разбивая таблицы на минимально возможные части для устранения в них всей избыточности данных. Нормализованные таким образом таблицы обычно содержат минимальное количество информации, помимо первичного ключа.
Преимуществом преобразования базы данных в пятую нормальную форму является возможность управления целостностью. Поскольку при этом любой фрагмент не ключевых данных (данных, не являющихся первичным или внешним ключом) встречается в базе данных только один раз, не возникает никаких проблем при их обновлении. Если, например, изменяется физический адрес заказчика, соответствующие поправки нужно внести только в таблицу «Заказчики», и не надо просматривать остальные таблицы на предмет поиска и изменения в них значения соответствующего поля физический адрес.
Однако, поскольку каждая таблица в пятой нормальной форме имеет минимальное число столбцов, то в них должны дублироваться одни и те же ключи, обеспечивая возможности для объединения таблиц и получения полезной информации.
Изменение значения единственного ключа уже является очень серьезной проблемой. Нужно найти все вхождения этого значения в базе данных и внести соответствующие изменения. На самом деле, столбцы первичных ключей обычно изменяются значительно реже, чем не ключевые. Следовательно, нужно добиваться равновесия между избыточность данных и избыточностью ключей.
Применение систем управления реляционными базами данных очень эффективно при автоматизации финансового звена малого коммерческого предприятия. Вышеизложенная теория и принципы управления реляционными базами данных могут быть с успехом применены в процессе автоматизации работы любого финансового подразделения предприятия. Основные принципы реляционного подхода к структуре коммерческой базы данных обеспечивают наилучшее ее функционирование. Соблюдение принципов целостности, безопасности и независимости данных, что дает нам реляционная модель, позволяет организовать отказоустойчивую структуру данных, что так необходимо для правильного и непрерывного функционирования финансовых подразделений. Применение принципа нормализации к структуре данных дает высокую гибкость при проектировании пользовательского интерфейса и обеспечивает не избыточность данных, что особенно важно учитывая большой объем информации обрабатываемый в повседневной работе финансовых подразделений.
3. Общее описание базы данных
3.1. Задачи, выполняемые приложением «Бухгалтерия»
База данных «Бухгалтерия» предназначена для автоматизации работы бухгалтерии (выписка документации, финансовые расчеты). В техническое задание на реализацию базы данных входили следующие задачи:
1. Оформление, учет и выписка первичной бухгалтерской документации (счетов) по основному профилю работы организации (системы КонсультантПлюс)
2. Оформление, учет и выписка вторичной отчетной документации (акты приемки-сдачи, накладные, счета-фактуры, акты на информационно-программного сопровождение, счета-фактуры на информационно-программного сопровождение), фиксирование информации о приходе денежных средств по счетам, формирование первичного авансового отчета по основному профилю работы организации (системы КонсультантПлюс)
3. Оформление, учет и выписка первичной бухгалтерской документации (счетов) по дополнительным заказам (программное и аппаратное обеспечение, информационные услуги)
4. Оформление, учет и выписка вторичной отчетной документации (акты на установку, накладные, счета-фактуры, акты на информационные услуги), фиксирование информации о приходе денежных средств по счетам, формирование первичного финансового отчета по дополнительным заказам организации (программное и аппаратное обеспечение, информационные услуги)
5. Оформление счетов-фактур на сопровождение по авансовым остаткам с 1996 года
6. Ввод прейскурантов на сопровождение и на системы.
7. Ввод и изменение адресных и банковских реквизитов организаций.
3.2. Технические требования, предъявляемые к базе данных.
При проектировании системы автоматизации принимались во внимание следующие требования:
- система должна нормально функционировать на стандартных персональных компьютерах клона IBM с процессором Intel Pentium - 100 (минимальные требования), подсоединенных к локальной офисной вычислительной сети в режиме невыделенных серверов;
- система не должна иметь привязки к аппаратной части для возможности переноса ее на новую платформу из-за неизбежного морального старения компьютерной техники;
- архитектура системы должна быть выбрана таким образом, чтобы минимизировать вероятность нарушения штатного режима работы системы (выход системы из строя, разрушение информационной базы данных, потери или искажение информации) при случайных или сознательных некорректных действиях пользователей;
- система должна обеспечивать защиту информационной базы данных от несанкционированного доступа;
- основная программная оболочка системы должна устанавливаться на рабочие места директора и бухгалтера с любого компьютера, подсоединенного к локальной офисной вычислительной сети;
- основная программная оболочка должна иметь интуитивно ясный дружественный интерфейс и не должна требовать от пользователей специальной подготовки, не связанной с их профессиональными обязанностями;
- система должна иметь возможность наращивания в программной части.
- система должна функционировать под управлением операционных систем Windows 95 и Windows NT.
3.3. Выбор системы проектирования и реализации.
Для технической реализации вышеуказанных задач с учетом поставленных требований была выбрана система управления базами данных «Microsoft Access».
Данная СУБД была выбрана по следующим причинам:
· простота средств реализации,
· легкость освоения инструментарием разработчика (VBA),
· наглядность визуализации информации.
Базы данных созданные с помощью системы управления базами данных «Microsoft Access» полностью реализую реляционную модель построения данных. База данных «Microsoft Access» представляет собой набор групп объектов, таких как таблицы, запросы, формы, отчеты.
Связи между таблицами можно разбить на четыре базовых реляционных типа с отношениями:
· один-к-одному;
· один–ко-многим;
· многие-к-одному;
· многие-ко-многим.
Структура организации таблиц позволяет создание первичных и внешних ключей. Имеется возможность изменения типа внутренних объединений для связанных таблиц.
Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:
· загрузка модулей по требованию;
· оптимизация дерева вызовов;
· использование файлов MDE;
· автоматическая поддержка компилированного состояния;
· использование библиотек Windows API;
· индивидуальная настройка системы;
· эффективное использование индексов;
· встроенный оптимизатор запросов.
Применение пакета «Microsoft ADT» (расширенные средства разработчика) вводит новый уровень визуализации данных, засчет таких элементов, как «Tree View», «Tab Control» и других.
На начальном этапе реализации база данных проектировалась на СУБД «Microsoft Access 2.0».В дальнейшем с появлением новой версии «Microsoft Access 7.0» база данных была переведена на новую версию СУБД, так как в новой версии появились новые инструменты разработчика, улучшенный интерфейс и реальная 32-разрядность. При переходе были отлажены с некоторые проблемы связанные с несовместимостью программного кода различных версий, и так как отладка происходила по мере выявления ошибок, то в дальнейшем возможно возникновение проблем с совместимостью кода.
3.4. Проектирование структуры данных.
До технической реализации структуры базы данных была проанализирована структура взаимодействия отделов предприятия и составлены несколько вариантов бизнес–планов, характеризующие деятельность отделов по различным типам выполняемых работ. При анализе бизнес-планов учитывались критические моменты и проверки, важные с точки зрения обеспечения целостности данных. Также был произведен анализ типов отчетности по каждому из этапов бизнес-планов.
Данные для технической реализации проекта данные имеют следующую структуру, проиллюстрированную Схемой 2 (основные связи).
Основной является таблица с данными по организациям («Заказчики»), к ней отношениями один ко многим связанны таблицы с информацией по основным («ОсновныеСчета») и дополнительным («ДругиеСчета») счетам (у одной организации может быть много счетов как по основному направлению деятельности предприятия, так и по дополнительным направлениям), к таблицам по счетам отношением один ко многим связанны таблицы с информацией по заказам, входящим в данный счет (в один счет может входить несколько заказов). С другой стороны, к таблицам с данными по организациям отношением один-ко-многим связана таблица с данными по авансовому отчету.
Особенностью проектируемой системы является возможность учета денежных средств поступивших по авансовым платежам, что составляет основную долю прихода денежных средств. Структура данных по авансовым платежам построена с учетом того, что выборка по этим данным должна быть представлена в наиболее полном виде, и как можно в более короткое время. Более того, данная структура одинаково хорошо работает с обыкновенной схемой учета денежных средств, то есть списание денежных средств на реализацию без учета аванса.
Данная схема реализована с помощью двух таблиц, связанных отношением один-ко-многим. В главной таблице находятся данные с информацией по счету, такие как код номера счета, тип системы по позиции счета, количество месяцев сопровождения системы по позиции счета, информация о типе платежа (наличный или безналичный расчет).
В подчиненной таблице расписаны суммы авансовых платежей по месяцам. Таким образом, данная структура реализует быстрые выборки по авансовым задолжностям по конкретной организации, что имеет существенное значение при оценке эффективности деятельности предприятия и прогнозирования дальнейшей работы.
Политика расположения данных имеет критическое значение для приложения применительно к скорости работы. Данные, которые меняются нечасто или не меняются вовсе, названия систем семейства Консультант +, названия месяцев года и так далее, были вынесены локально в клиентские модули, так как скорость выборки данных с локального диска компьютера в несколько раз больше скорости выборки данных по запросу из базы данных расположенной на сетевом диске.
Примечание: Для связывания таблиц в дальнейшем рекомендуется, где возможно, применять поле с уникальным значением, но не поле счетчика (так как возможна ситуация с добавлением данных в таблицу, при этом изменяется значение счетчика и теряются связанные данные в подчиненных таблицах)
После реализации основной части проекта база данных была разделена на три отдельных модуля:
· модуль для бухгалтерии (MdlByx.mdb),
· модуль для отдела сопровождения (MdlClnt.mdb),
· модуль данных (Data.mdb).
Организованная структура данных позволяет:
· организовать клиент - серверную модель данных,
· разработку и изменение модулей параллельно с работой ранее сконструированных,
· уменьшает размер резервного файла,
В процессе технической реализации данных задач появились дополнительные задачи:
1. Изменение данных по авансовому отчету (корректировка распределения сумм по месяцам для организаций).
2. Общая результирующая информация по организациям, адресные и банковские реквизиты, счета, выписанные на организации, информация по системам для данной организации.
3. Обмен сообщениями между пользователями (использование для заказа счетов актов и так далее).
3.4.1. Описание структуры данных проекта.
В процессе разработки базы данных была выработана следующая иерархическая структура данных.
Часть 1. (листинг 2.1)
1. Связь таблицы «Заказчики» с таблицей «СтатусЗаказчика». Поле: «Код» в обеих таблицах
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «СтатусЗаказчика»)
Связывание: мастер подстановок в таблице «Заказчики»
Примечания: данная связь заменяет повторяющееся текстовые значения типа организации соответствующим кодом из таблицы «СтатусЗаказчика».
2.Связь таблицы «Заказчики» с таблицей «Курьеры».
Поле: «КодКурьера» в обеих таблицах.
Тип связи: один ко многим с обеспечением целостности данных.
(один со стороны таблицы «Курьеры»)
Связывание: мастер подстановок в таблице «Заказчики»
Примечания: предусматривает добавление в структуру данных модуля «Курьеры».
3.Связь таблицы «Заказчики» с таблицей «Примечания».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим без обеспечением целостности данных.
(один со стороны таблицы «Заказчики»)
(возможно связывание один к одному)
Связывание: мастер подстановок в таблице «Примечания»
Часть 2. (листинг 2.2)
(таблицы «Заказчики», «КредитАванс», «ОсновныеСчета», «Дистрибутивы», «Системы»,
«ФормаОплаты», «ТипСистемы», «Платежки», «СчетаФактуры», «СчетаФактурыОсновные»)
1.Связь таблицы «Заказчики» с таблицей «ОсновныеСчета».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «Заказчики»)
Связывание: мастер подстановок в таблице «ОсновныеСчета»
Примечания: у каждого заказчика может быть много счетов.
2.Связь таблицы «Заказчики» с таблицей «КредитАванс».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Заказчики»)
(возможно связывание один к одному?)
Связывание: мастер подстановок в таблице «КредитАванс»
3.Связь таблицы «Заказчики» с таблицей «СчетаФактуры».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Заказчики»)
Связывание: мастер подстановок в таблице «СчетаФактуры»
Примечания: у каждого заказчика может быть много счетов-фактур.
4. Связь таблицы «ОсновныеСчета» с таблицей «Дистрибутивы».
Поле: «КодСчета» в обеих таблицах.
Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «ОсновныеСчета»)
Связывание: мастер подстановок в таблице «Дистрибутивы»
Примечания: в каждый счет может входить много записей по заказам.
5. Связь таблицы «ОсновныеСчета» с таблицей «Платежки».
Поле: «КодСчета» в обеих таблицах.
Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «ОсновныеСчета»)
Связывание: мастер подстановок в таблице «Дистрибутивы»
Примечания: в каждому счету может относится несколько платежных поручений.
(*Если платежное поручение оплачивает несколько счетов, то при внесении данных к счетам пишется одно и тоже платежное поручение, но суммы вносятся в соответствии с суммой счета)
6. Связь таблицы «ОсновныеСчета» с таблицей «СчетаФактурыОсновные».
Поле: «КодСчета» в обеих таблицах.
Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «ОсновныеСчета»)
Связывание: мастер подстановок в таблице «Дистрибутивы»
Примечания: в каждому счету может относится несколько счетов-фактур на системы.
7. Связь таблицы «Дистрибутивы» с таблицей «Системы».
Поле: «КодСистемы».
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Системы»)
Связывание: мастер подстановок в таблице «Дистрибутивы»
Примечания: данная связь заменяет повторяющееся текстовые значения названия систем соответствующим кодом из таблицы «Системы».
8. Связь таблицы «Дистрибутивы» с таблицей «ТипСистемы».
Поле: «Код» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «ТипСистемы»)
Связывание: мастер подстановок в таблице «Дистрибутивы»
Примечания: данная связь заменяет повторяющееся текстовые значения типа систем соответствующим кодом из таблицы «ТипСистемы».
9. Связь таблицы «ОсновныеСчета» с таблицей «ФормаОплаты».
Поле: «Код» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «ФормаОплаты»)
Связывание: мастер подстановок в таблице «ОсновныеСчета»
Примечания: данная связь заменяет повторяющееся текстовые значения формы оплаты счета соответствующим кодом из таблицы «ФормаОплаты».
10. Связь таблицы «Системы» с таблицей «КредитАванс».
Временная связь, возможно в дальнейшем будет удалена.
Часть 3. (листинг 2.3)
(таблицы «Заказчики», «ОсновныеСчета», "АвансПоОстаткамС1996Года», «ДанныеДляАвансОтчета», «Системы», «АвансовыйОтчет».)
1. Связь таблицы «Заказчики» с таблицей «АвансПоОстаткамС1996Года».
Поле: «КодЗаказчика» в таблице «Заказчики» с полем «Заказчик» в таблице «АвансПоОстаткамС1996Года».
Тип связи: один ко многим с обеспечением целостности данных.
(один со стороны таблицы «Заказчики»)
Связывание: в окне схемы данных.
Примечания: к каждому заказчику может относится несколько записей по месяцам по авансовому отчету.
2. Связь таблицы «Заказчики» с таблицей «ДанныеДляАвансОтчета».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Заказчики»)
Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»
Примечания: для данной организации данных к каждому заказчику может относится несколько записей по авансовому отчету.
3. Связь таблицы «Системы» с таблицей «ДанныеДляАвансОтчета».
Поле: «КодСистемы» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Заказчики»)
Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»
Примечания: данная связь заменяет повторяющееся текстовые значения названия системы соответствующим кодом из таблицы «Системы».
4. Связь таблицы «ОсновныеСчета» с таблицей «ДанныеДляАвансОтчета».
Поле: «КодСчета» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «ОсновныеСчета»)
Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»
Примечания: к каждому счета может относится несколько записей по авансовому отчету.
5. Связь таблицы «ДанныеДляАвансОтчета» с таблицей «АвансовыйОтчет».
Поле: «Код» в таблице «ДанныеДляАвансОтчета» с полем «ИдентКод» в таблице «АвансовыйОтчет».
Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «ДанныеДляАвансОтчета»)
Связывание: в окне схемы данных.
Часть 4. (листинг 2.4)
(таблицы «Заказчики», «ДругиеСчета», «ДругиеПлатежки», «ДругиеЗаказы», «ДанныеДляАвансОтчетаДр», «АвансовыйОтчетДр».)
1. Связь таблицы «Заказчики» с таблицей «ДругиеСчета».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «Заказчики»)
Связывание: в окне схемы данных.
Примечания: к каждому заказчику может относится несколько счетов по дополнительным заказам.
2. Связь таблицы «Заказчики» с таблицей «ДанныеДляАвансОтчетаДр».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Заказчики»)
Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчетаДр»
Примечания: при данной организации данных к каждому заказчику может относится несколько записей по авансовому отчету по дополнительным заказам.
3. Связь таблицы «ДругиеСчета» с таблицей «ДругиеЗаказы».
Поле: «КодСчета» в обеих таблицах.
Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «ДругиеСчета»)
Связывание: мастер подстановок в таблице «ДругиеЗаказы»
Примечания: к каждому счету может относится несколько записей по дополнительным заказам.
4. Связь таблицы «ДругиеСчета» с таблицей «ДругиеПлатежки».
Поле: «КодСчета» в обеих таблицах.
Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «ДругиеСчета»)
Связывание: в окне схемы данных.
Примечания: каждый счет может быть оплачен несколькими платежными поручениями.
5. Связь таблицы «ДругиеСчета» с таблицей «ДанныеДляАвансОтчетаДр».
Поле: «КодСчета» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «ДругиеСчета»)
Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчетаДр»
Примечания: при данной организации данных к каждому счету может относится несколько записей в авансовом отчете.
6. Связь таблицы «ДанныеДляАвансОтчетаДр» с таблицей «АвансовыйОтчетДр».
Поле: «Код» в таблице «ДанныеДляАвансОтчетаДр» с полем «ИдентКод» в таблице «АвансовыйОтчетДр».
Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.
(один со стороны таблицы «ДанныеДляАвансОтчета»)
Связывание: в окне схемы данных.
Часть 5. (листинг 2.5)
(таблицы «ОсновныеСчета», «Источник», «Подразделение», «Сотрудники»)
1. Связь таблицы «ОсновныеСчета» с таблицей «Источник».
Поле: «КодИсточника» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Источник»)
Связывание: мастер подстановок в таблице «ОсновныеСчета»
Примечания: данная связь заменяет повторяющееся текстовые значения названия источника информации об организации соответствующим кодом из таблицы «Источник».
2. Связь таблицы «ОсновныеСчета» с таблицей «Подразделение».
Поле: «КодПодразделения» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Подразделение»)
Связывание: мастер подстановок в таблице «ОсновныеСчета»
Примечания: данная связь заменяет повторяющееся текстовые значения названия подразделения, от которого поступила информация об организации, соответствующим кодом из таблицы «Подразделение».
3. Связь таблицы «ОсновныеСчета» с таблицей «Сотрудники».
Поле: «КодСотрудника» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «Сотрудники»)
Связывание: мастер подстановок в таблице «ОсновныеСчета»
Примечания: данная связь заменяет повторяющееся текстовые значения фамилий сотрудников, от которого поступила информация об организации, соответствующим кодом из таблицы «Сотрудники».
Часть 6. (листинг 2.6)
(таблицы «Изменение АвансОтчета», «Системы», «СчетаФактуры», «МесяцыСГодом», «ПоследнииДниМесяцаСГодом»)
1. Связь таблицы «Изменение АвансОтчета» с таблицей «Системы».
Поле: «КодСистемы» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(*Может стоит заменить тип связи на «с обеспечением целостности данных»?)
(один со стороны таблицы «Системы»)
Связывание: мастер подстановок в таблице «Изменение АвансОтчета»
Примечания: данная связь проверяет соответствие на правильность занесения кодов систем.
2. Связь таблицы «СчетаФактуры» с таблицей «МесяцыСГодом».
Поле: «Код» в обеих таблицах.
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «МесяцыСГодом»)
Связывание: мастер подстановок в таблице «Изменение АвансОтчета»
Примечания: данная связь заменяет повторяющееся текстовые значения месяца и года даты счета-фактуры соответствующим кодом из таблицы «МесяцыСГодом».
3. Связь таблицы «СчетаФактуры» с таблицей «ПоследнииДниМесяцаСГодом».
Поле: «КодСчетаФактуры» в таблице «СчетаФактуры» с полем «Код» в таблице «ПоследнииДниМесяцаСГодом».
. Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «МесяцыСГодом»)
Связывание: мастер подстановок в таблице «Изменение АвансОтчета»
Примечания: данная связь заменяет повторяющееся текстовые значения месяца и года даты счета-фактуры соответствующим кодом из таблицы «ПоследнииДниМесяцаСГодом».
3.5. Техническая реализация проекта.
3.5.1. Общее описание работы с приложением.
После загрузки главного файла базы данных MdlByh97.MDB на экране автоматически появляется экран, информирующий пользователя о процессе загрузки базы данных. При загрузке происходит проверка целостности данных и инициализация основных параметров базы данных, таких как путь к файлу данных, определение глобальных переменных и т.д. Также происходит проверка разрешения экрана. Дело в том, что экранные формы приложеня имеют достаточно больной размер После процесса проверки формируется основное меню и база данных готова к работе.
Далее, пользуясь командами меню, пользователь может выбрать разные варианты работы:
выписка счетов;
- ввод и распределение денежных средств по платежным поручениям;
- ввод дополнительных данных финансового и справочного характера;
- получение справочной информации различного характера по конкретной организации;
- получение финансовой информации в общем.
Соответственно, для выписки счетов по основному профилю работы предприятия (Системы семейства «Консультант Плюс») пользователю необходимо выбрать в меню «Оформление счетов» пункт «Счета по системам Консультант Плюс» и из раскрывающегося списка выбрать пункт «Оформление». Далее в форме необходимо найти требуемого заказчика, выбором из списка либо по процедуре поиска, или ввести нового и оформить на организацию новый счет. Номер нового счета вносится автоматически, в порядке последовательных номеров. Далее, выбором из раскрывающихся списков требуется выбрать необходимые позиции счета и добавить их, в буфер данных для распечатки.
Основным приемом при выписке документации, на этапе конструирования форм, было заполнение временных таблиц, используя текущие данные в форме, по процедуре обработки событий для кнопки и ее отображение в списке при обновлении данных в форме.
Аналогичным образом оформляются счета на дополнительные заказы. При этом выбор позиций счета строго не фиксирован, так как выписке счета по дополнительным заказам предмет счета изменяется широких пределах.
По приходу денежных средств на расчетный счет предприятия по системе «Банк-Клиент», денежные средства должны быть занесены в систему. Для этого пользователю необходимо выбрать в меню «Оформление счетов» пункт «Счета по системам Консультант Плюс» и из раскрывающегося списка выбрать пункт «Просмотр». Далее необходимо найти счет, по которому пришли денежные средства, занести в систему информацию по платежному поручению и занести денежные средства на авансовый отчет. В процедуре занесения контролируется соответствие денежных средств по платежным поручениям и по счету.
3.5.2. Формы отчетности (счетов, актов, счетов-фактур, накладных).
Данные отчеты реализованы с помощью конструктора отчетов. Источниками данных для отчетов служат соответствующие временные таблицы, заполняемые данными при выписке счетов, актов, накладных и т.д. Общим для всех отчетов является ссылки на соответствующие поля в формах для выписки документов.
Для всех типов счетов, по событию форматирование области заголовка отчета, по процедуре обработки события, изменяется свойство «Visible» для подчиненного отчета и в соответствии со значениями глобальной переменной ВалДляСчета, на печать выводятся реквизиты организации для перевода денежных средств на счета в разных банках («Федеральный Банк Инноваций и Развития», «Валютное управление СБ РФ»).
Во всех типах отчетов в области заголовка находится фирменный логотип организации. Данный логотип представляет комбинацию битового изображения и набора текстовых полей.
3.5.3. Сервисные функции.
Для обеспечения функциональной универсальности базы данных реализован ряд функций общего назначения. Данные функции применяются в ряде форм и отчетов, и выполняю как сервисные функции, так и функции обработки данных. Например, функция «Number» применяется практически во всех формах отчетности для перевода суммы из числового выражения в буквенное. Функции сохранены в модулях базы данных и вызываются динамически по запросу из процедур обработки событий. В листинге 4.1 приведены исходные тексты всех модулей используемых в базе данных.
3.5.4. Описание структуры программы.
Учитывая сформированную иерархическую структуру данных и очередность реализации проекта процесс технической реализации состоял из следующих этапов.
1. Оформление, учет и выписка первичной бухгалтерской документации (счетов) по основному профилю работы организации (системы КонсультантПлюс)
Для реализации данного этапа была разработана структура взаимодействия трех форм:
1. «ОсновнаяОформлениеСчетов» - основная
(источник записей таблица «Заказчики»).
2. «ОсновныеСчета:Подчиненая» - подчиненная1 (к основной)
(источник записей таблица «СчетаОсновные»).
3. «Дистрибутивы1» - подчиненная1.1 (к подчиненной1)
(источник записей таблица «Дистрибутивы»).
Форма «ОсновнаяОформлениеСчетов».
а) Поля.
1) «Образец»
Назначение: для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка165»(Найти).
Вводимое значение: текстовое или цифровое.
2) «Долг»
Назначение: свободное поле для отображения неучтенной задолженности для текущей организации.
Заполнение: в процедуре обработки события по событию «Текущая запись» для данной формы.
Примечание: при очистке данного поля снимается задолженность с данной организации и очищаются соответствующее связанные поля в таблице «КредитАванс». Это осуществляется по событию «После обновления» в процедуре обработки события (листинг 3.1).
3) «Код» (поле со списком)
Назначение: для отображения и выбора типа статуса текущей организации.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
4) «Организация»
Назначение: для отображения названия текущей организации.
Источник записей: аналогичное поле в исходной таблице.
5) «Прейскурант»
Назначение: свободное поле для отображения типа прейскуранта по которому производится расчет для текущей организации.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
Примечания:
- при выборе значения из списка , по событию «После обновления» в процедуре обработки события (листинг 3.2), меняется значения источника строк для поля «ВидСопровождения» в соответствии с наличием видов сопровождения для выбранного прейскуранта.
- на событию «Потеря фокуса» в процедуре обработки события (листинг 3.3), происходит проверка на наличие ввода пустого значения.
6) «ВидСопровождения»
Назначение: для отображения типа сопровождения по которому производится расчет для текущей организации.
Заполнение: выбор из списка (значения списка изменяются в соответствии с типом прейскуранта).
Источник записей: аналогичное поле в исходной таблице.
7) «Список116»(Список)
Назначение: свободное поле для поиска организации и перехода на требуемую запись.
Источник записей: SQL - запрос по таблице «Заказчики».
Примечания: сформирован с помощью мастера.
8) Остальные поля «Индекс», «Страна» и т.д. предназначены для отображения ввода и изменения адресных и банковских реквизитов текущей организации.
Назначение: для отображения типа сопровождения по которому производится расчет для текущей организации.
Источники записей: аналогичные поля в исходной таблице.
б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка165»(Найти).
Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.4).
Примечания: задание флагу flagFind значения True (используется для отлавливания ошибки в «Отсутствие текущей записи», процедуре обработки события по событию «Текущая запись» для формы «Основная»).
2) «Кнопка177»(Настройки счета).
Назначение: для вывода на экран диалогового окна «Настройки счета» (смотри пункт __ ).
Примечания: реализация с помощью мастера.
3) «Кнопка170»(Настройки счета).
Назначение: для предварительного просмотра образца счета. Процедура обработки событий.
Примечания: реализация с помощью мастера.
4) «КнопкаЗакрытьФорму» (Настройки счета).
Назначение: для закрытия текущей формы.
Примечания: реализация с помощью мастера.
5) «Кнопка_Новая_Запись» (Новая организация).
Назначение: для перехода в текущей форме на новую запись (ввод новой организации).
Примечания: реализация с помощью мастера, задание флагу flagNew значения True (используется для отлавливания ошибки в «Отсутствие текущей записи», процедуре обработки события по событию «Текущая запись» для формы «Основная»).
6) «Примечания»
Назначение: для вывода диалогового окна записи примечаний к текущей организации
Примечания: реализация с помощью мастера.
в) Переключатели. (для переключателей процедуры обработки событий вызываются по событию «После обновления»)
1) «Группа 168» (Организация-Счет).
Назначение: для перехода между информацией о счете и адресными реквизитами для текущей организации. Процедура обработки событий (листинг 3.5)
Примечания: задание свойству «Visible» значения True или False в зависимости от положения переключателя. событию «Текущая запись» для формы «Основная»).
Форма «ОсновныеСчета:Подчиненая».
а) Поля.
1) «НомерСчета».
Назначение: для ввода и отображения номера счета для текущей организации.
Заполнение: ввод с клавиатуры или по процедуре обработки событий кнопки «КнопкаНоваяЗапись» в данной форме (смотри пункт __).
Источник записей: аналогичное поле в исходной таблице.
Примечание: значение данного поля изменяется в процедуре обработки событий по событию «После обновления» поля со списком «КодОтдела» (смотри пункт 4)).
2) «ДатаСчета».
Назначение: для ввода и отображения даты счета для текущей счета.
Заполнение: ввод с клавиатуры или по умолчанию, в свойстве «Значение по умолчанию», значением текущей даты (функция Now()).
Источник записей: аналогичное поле в исходной таблице.
3) «Код» (Форма оплаты).
Назначение: для отображения и выбора формы оплаты данного счета.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
Примечание: *надо убрать ПОС по событию «После обновления».
4) «КодОтдела».
Назначение: для отображения и выбора отдела который выписал данный счет..
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
Примечание: по процедуре обработки событий по событию «После обновления» изменяется значение поля «НомерСчета» в соответствии с существующей номенклатурой (листинг 3.6).
5) «СрокДействияСчета» (Срок действия счета).
Назначение: для отображения и ввода даты по которую будет действителен текущий счет.
Заполнение: ввод с клавиатуры или по умолчанию, в свойстве «Значение по умолчанию», значением последнего числа текущего месяца (функция EndMonth() - смотри список функций базы данных).
Источник записей: аналогичное поле в исходной таблице.
Примечание: * необходимо переделать функцию EndMonth(), чтобы значение срока действия счета = текущая дата + 20 (15) дней.
6) «ЦенаДистрибутива» - скрытое поле.
Назначение: свободное поле для хранения цены дистрибутива системы, текущей в форме Подчиненная1.
Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).
Примечание: *необходимо сбрасывать значение данного поля в Null при переходе по записям в форме Подчиненная1.1, для избежания ситуации с занесением цены предыдущего или последующего дистрибутива.
7) «ЦенаСпецВыпуска» - скрытое поле.
Назначение: свободное поле для хранения цены спецвыпуска дистрибутива системы, текущей в форме Подчиненная1.
Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).
Примечание: *необходимо сбрасывать значение данного поля в Null при переходе по записям в форме Подчиненная1.1, для избежания ситуации с занесением цены спецвыпуска предыдущего или последующего дистрибутива.
8) «Сопровождение» - скрытое поле.
Назначение: свободное поле для хранения цены на сопровождение системы, текущей в форме Подчиненная1, в соответствии с параметрами полей «Прейскурант» и «ВидСопровождения» формы Основная.
Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).
Примечание: * необходимо сбрасывать значение данного поля в Null при переходе по записям в форме Подчиненная1.1, для избежания ситуации с занесением цены спецвыпуска предыдущего или последующего дистрибутива.
9) «Месяц» - скрытое поле.
Назначение: свободное поле для хранения значения месяца прейскуранта по которому выписывается заказы по текущему счету.
Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).
Примечание: * необходимо заполнять значение данного поля при повторной выписке счета, возможно по процедуре обработки события для кнопки «Кнопка63» в форме Подчиненная1.1.
10) «КодЗаказчика» - скрытое поле.
Назначение: главное связующее поле по для форм Подчиненная1 и Основная.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
б) Флажки.
1) «ВыпискаНакладной» и «ВыпискаАктов» ?.
Назначение: отметка о выписке актов и накладных при покупке системы.
Заполнение: по процедуре обработки события для кнопки «Кнопка170» в форме Основная.
Источник записей: аналогичное поле в исходной таблице.
Примечание: * возможно запрещение выписки актов и накладных на данном этапе, следовательно необходимость наличия этих полей отпадает.
в) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «КнопкаНоваяЗапись».
Назначение: для перехода на новую запись для данной форма (новый счет для текущей организации) и заполнения поля «НомерСчета» следующим номером согласно существующей номенклатуре, очистка временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной». Процедура обработки событий (листинг 3.7).
Примечания: * отладить на возникновение ошибок при нестандартном номере предыдущего счета.
2) «Кнопка333», «Кнопка334», «Кнопка335», «Кнопка336».
Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.
Форма «Дистрибутивы1».
а) Поля.
1) «КодМесяца» (Месяц) - поле со списком.
Назначение: для выбора и отображения месяца прейскуранта для расчета стоимости заказов для текущего счета.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
Примечание: так как значение данного поля является критичным для последующих вычислений, то для данного поля, в процедуре обработки событий по событию «После обновления», происходит проверка на наличие пустого значения в данном поле (листинг 3.8).
2) «КодСистемы» (Система).
Назначение: для выбора и отображения системы, на которую будет оформлена запись в счете.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит заполнение поля «ЦенаДистрибутива», «ЦенаСпецВыпуска», «Сопровождение» формы Подчиненая1, соответствии с выбранным значением данного поля и со значениями полей «Прейскурант» и «ВидСопровождения», формы Основная (листинг 3.9).
3) «Код» (Тип системы) - поле со списком.
Назначение: для выбора и отображения типа системы, на которую будет оформлена запись в счете.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цены системы и сопровождения (поля «Цена»и «Сопровождение») в соответствии с выбранным значением данного поля и со значениями полей «СпецвыпускИлиНет», «Количество», «Скидки», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.10).
4) «СпецвыпускИлиНет» - флажок. (Спецвыпуск).
Назначение: для указания и отображения, является ли данный дистрибутив спецвыпуском или нет.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цены системы и сопровождения (поля «Цена»и «Сопровождение») в соответствии со значением данного поля и со значениями полей «СпецвыпускИлиНет», «Количество», «Скидки», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.11).
5) «Флажок58» - флажок. (только ИПС).
Назначение: для указания и отображения, оформляется ли данный заказ на продажу или только на сопровождение.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цены сопровождения в соответствии со значением данного поля и со значениями полей «СпецвыпускИлиНет», «Количество», «Скидки», «КоличествоМ», «СкидкиС» текущей формы, и присваивается Null значению поле «Цена» (листинг 3.12).
6) «Примечание».
Назначение: для ввода и отображения комментариев к текущему заказу.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
7) «НомерДистрибутива» - необходимость в данной форме ???.
8) «Количество» (Количество систем). - необходимость в данной форме ???.
Назначение: для ввода и отображения количества систем на которые оформляется данный заказ счета.
Заполнение: постоянное значение, равное 1.
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением в данном поле и со значениями полей «СпецвыпускИлиНет», «Скидки», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.13).
9) «Скидки» (Скидки на систему).
Назначение: для ввода и отображения величены скидки на систему при продаже.
Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением скидки в данном поле и со значениями полей «СпецвыпускИлиНет», «Количество», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.14).
10) «КоличествоМ» (Количество месяцев)
Назначение: для ввода и отображения количества месяцев сопровождения на текущую систему.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением в данном поле и со значениями полей «СпецвыпускИлиНет», «Скидки», «Количество», «СкидкиС» текущей формы (листинг 3.15).
11) «СкидкиС» (Скидки на сопров.).
Назначение: для ввода и отображения величены скидки на сопровождение.
Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).
Источник записей: аналогичное поле в исходной таблице.
Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением скидки в данном поле и со значениями полей «СпецвыпускИлиНет», «Количество», «КоличествоМ», текущей формы (листинг 3.16).
12) «Цена» (Поставка).
Назначение: для ввода и отображения цены на систему при покупке.
Заполнение: ввод с клавиатуры или по процедуре обработки событий вышеописанных полей.
Источник записей: аналогичное поле в исходной таблице.
13) «Сопровождение».
Назначение: для ввода и отображения цены на сопровождение.
Заполнение: ввод с клавиатуры или по процедуре обработки событий вышеописанных полей.
Источник записей: аналогичное поле в исходной таблице.
14) «КодСчета» - скрытое поле.
Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.1.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
15) «СистемыНаВыписку» - список.
Назначение: свободное поле для отображения перечня заказов входящих в счет.
Заполнение: по SQL - запросу.
Источник строк: SQL - запрос по таблице «НаВыпискуСчета».
(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)
Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).
б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка63» (Добавить новую >- при выписке в счете нового заказа).
Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуСчета» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку») и переход на новую запись в текущей форме (для ввода нового заказа счета). Процедура обработки событий (листинг 3.17).
Примечания: - .
2) «Кнопка69» (Добавить > - при повторной выписке счета).
Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуСчета» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку») и переход на следующую запись в текущей форме (для ввода или изменения следующего заказа счета). Процедура обработки событий (листинг 3.18).
Примечания: - .
3) «Кнопка71», «Кнопка72», «Кнопка73», «Кнопка75».
Назначение: для перехода по записям для текущей формы (заказы для данной счета). Реализация с помощью мастера.
4) «Кнопка70».
Назначение: для удаления выделенной записи в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.19).
Примечания: - .
5) «Кнопка74».
Назначение: для удаления всех записей в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета», обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.20).
Примечания: - .
Комментарии.
Описанная структура имеет следующие особенности работы
1. Для формы Основная по событию «Текущая запись» в процедуре обработки событий происходит расчет по значений задолженности текущей организации (заполняется поле «Долг») и проверяется наличие важных примечаний для данной организации (выделение цветом текста кнопки «Примечания»)
(листинг 3.21).
2. Также для формы Основная при загрузки инициализируются две переменные flagNew и flagFind использующиеся для устранения ошибок в процедуре обработки событий по событию «Текущая запись» для формы Основная (для новой организации не может быть кредиторской или авансовой задолженности). Значения переменных - флагов устанавливаются в процедурах обработки событий для кнопок «Кнопка165» (flagFind) и «Кнопка_Новая_Запись» (flagNew). (листинг 3.22).
3. Для формы Подчиненная1 по событию «Открытие» в процедуре обработки событий происходит очистка временной таблицы «НаВыпискуСчета» и «НаВыпискуНакладной» по функции ClearListBox()
2. Оформление, учет и выписка вторичной отчетной документации (акты приемки-сдачи, накладные, счета-фактуры, акты на информационно-программного сопровождение, счета-фактуры на информационно-программного сопровождение), фиксирование информации о приходе денежных средств по счетам, формирование первичного авансового отчета по основному профилю работы организации (системы КонсультантПлюс)
Для реализации данного этапа была разработана структура взаимодействия трех форм:
1. «Просмотр» - основная
(источник записей таблица «Заказчики»).
2. «ПросмотрSub» - подчиненная1 (к основной)
(источник записей таблица «СчетаОсновные»).
3. «ПросмотрSubSub» - подчиненная1.1 (к подчиненной1)
(источник записей таблица «Дистрибутивы»).
4. «Платежки» - подчиненная1.2 (к подчиненной1)
(источник записей таблица «Платежки»).
5. «СчетаФактурыОсновные» - подчиненная1.3 (к подчиненной1)
(источник записей таблица «СчетаФактурыОсновные»).
Форма «Просмотр».
а) Поля.
1) «Образец»
Назначение: для ввода текстовой и цифровой информации использующейся для поиска
по названию организации в процедуре обработки события кнопки «Кнопка165»(Найти).
Вводимое значение: текстовое или цифровое.
2) «Код» (поле со списком)
Назначение: для отображения и выбора типа статуса текущей организации.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
3) «Организация»
Назначение: для отображения названия текущей организации.
Источник записей: аналогичное поле в исходной таблице.
4) «Список116»(Список)
Назначение: свободное поле для поиска организации и перехода на требуемую запись.
Источник записей: SQL - запрос по таблице «Заказчики».
Примечания: сформирован с помощью мастера.
5) Остальные поля «Индекс», «Страна» и т.д. предназначены для отображения ввода и изменения адресных и банковских реквизитов текущей организации.
Назначение: для отображения типа сопровождения по которому производится расчет для текущей организации.
Источники записей: аналогичные поля в исходной таблице.
6) «ПервыйМесяц»
Назначение: свободное поле для ввода первого месяца сопровождения начиная с которого необходимо выписывать акты и счета-фактуры на сопровождение для текущей организации.
Примечания: вводимое значение в кратком формате даты (например 04.03.97) используется только для формирования начальной даты при выписке акты и счета-фактуры на сопровождение для текущей организации.
б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка165»(Найти).
Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.23).
Примечания: задание флагу flagFind значения True (используется для отлавливания ошибки в «Отсутствие текущей записи», процедуре обработки события по событию «Текущая запись» для формы «Основная»).
2) «Кнопка139»(Настройки печати).
Назначение: для вывода на экран диалогового окна «Настройки счета» (смотри пункт __).
Примечания: реализация с помощью мастера.
3) «Кнопка174».
Назначение: для предварительного просмотра образца актов, накладных и счетов-фактур по счету при продаже. Процедура обработки событий (листинг 3.24).
Примечания: реализация с помощью мастера, проверка значений формы критических для выписки счета.
4) «КнопкаЗакрытьФорму» (Настройки счета).
Назначение: для закрытия текущей формы.
Примечания: реализация с помощью мастера.
5) «Кнопка181».
Назначение: для предварительного просмотра образца актов и счетов-фактур на сопровождение по счету для текущей организации (листинг 3.25)
Примечания: реализация с помощью мастера, проверка значений формы критических для выписки счета.
Форма «ПросмотрSub».
а) Поля.
1) «НомерСчета».
Назначение: для отображения номера счета для текущей организации.
Источник записей: аналогичное поле в исходной таблице.
2) «Код» (Форма оплаты).
Назначение: для отображения и выбора формы оплаты данного счета.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
3) «КодОтдела»(Отделы).
Назначение: для отображения и выбора отдела который выписал данный счет..
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
4) «НомерНакладной» ((№ Накладной).
Назначение: для ввода и отображения номера накладной, при выписке документации по счету на продажу.
Заполнение: в ввод с клавиатуры или в процедуре обработки событий по событию «После обновления» группы «Группв337» (смотри пункт __ ).
Источник записей: аналогичное поле в исходной таблице.
Примечание: при просмотре счета на сопровождение значение данного поля остается пустым. *вынести номера платежных поручений в отдельную таблицу, так как не каждый счет выписывается на продажу и возможно наличие большого количества пустых полей.
5) «ВсеПлатежки» - скрытое поле.
Назначение: свободное поле для хранения текстовой информации по платежным поручениям оплачивающим текущий счет (Пример: № 24 от 03.02.97).
Заполнение: в процедуре обработки событий кнопки «Кнопка174» в форме Основная. (смотри пункт __ ).
Примечание: * усовершенствовать заполнение по правилам (Пример: 3 февраля 1997 года).
6) «ПоСчету» (е по счету).
Назначение: свободное поле для отображения общей суммы счета включая НДС для визуальной оценки совпадения суммы по счету и суммы по платежным поручениям.
Заполнение: в процедуре обработки событий кнопки «Кнопка347» (Занести).
7) «ПоПлатежке» (е по платежке).
Назначение: свободное поле для отображения общей суммы прихода денежных средств по платежным поручениям, для визуальной оценки совпадения суммы по счету и суммы по платежным поручениям.
Заполнение: в процедуре обработки событий кнопки «Кнопка347» (Занести)(смотри пункт __ ).
8) «Разница».
Назначение: свободное поле для отображения разницы общей суммы счета включая НДС и общей суммы прихода денежных средств по платежным поручениям.
Заполнение: в процедуре обработки событий кнопки «Кнопка347» (Занести)(смотри пункт __ ).
9) «КодИсточника».
Назначение: для выбора и отображения названия источника информации о пользователе по данному счету.
Заполнение: выбор из списка .
Источник записей: аналогичное поле в исходной таблице.
10) «КодПодразделения».
Назначение: для выбора и отображения названия подразделения от которого поступила информации о пользователе по данному счету.
Заполнение: выбор из списка .
Источник записей: аналогичное поле в исходной таблице.
11) «КодСотрудника».
Назначение: для выбора и отображения фамилии сотрудника от которого поступила информации о пользователе по данному счету.
Заполнение: выбор из списка .
Источник записей: аналогичное поле в исходной таблице.
12) «КодАгента».
Назначение: для выбора и отображения фамилии агента от которого поступила информации о пользователе по данному счету.
Заполнение: выбор из списка .
Источник записей: аналогичное поле в исходной таблице.
Примечание: в процедуре обработки событий по событию «После обновления» для данного поля заполняется поле «СуммаСНакоплением» для отображения общей суммы заказов проданных вышеуказанным агентом в долларах (листинг 3.26).
13) «Агент_процент_1»(% от реализации).
Назначение: для ввода и отображения величины процента агентского вознаграждения от суммы реализации по данному счету.
Заполнение: ввод с клавиатуры, тип вводимого значения дробное число с разделителем точка (Пример: 0.1 - 10%).
Источник записей: аналогичное поле в исходной таблице.
Примечание: в процедуре обработки событий по событию «После обновления» для данного поля рассчитывается значение в поле «ВознагрАгента» и «НаРукиАгент» текущей формы (листинг 3.27).
14) «Агент_процент_2»(% от сопровож.).
Назначение: для ввода и отображения величины процента агентского вознаграждения от суммы сопровождения по данному счету.
Заполнение: ввод с клавиатуры, тип вводимого значения дробное число с разделителем точка (Пример: 0.1 - 10%).
Источник записей: аналогичное поле в исходной таблице.
Примечание: в процедуре обработки событий по событию «После обновления» для данного поля рассчитывается значение в поле «ВознагрАгента» «НаРукиАгент» текущей формы (листинг 3.28).
15) «ВознагрАгент» (Сумма).
Назначение: для отображения общей суммы агентского вознаграждения от суммы данного счета.
Заполнение: в процедуре обработки событий по событию «После обновления» для поля «Агент_процент_1» и поля «Агент_процент_2».
Источник записей: аналогичное поле в исходной таблице.
16) «НаРукиАгент» (На руки).
Назначение: для отображения суммы агентского вознаграждения выдаваемого агенту от суммы данного счета.
Заполнение: в процедуре обработки событий по событию «После обновления» для поля «Агент_процент_1» и поля «Агент_процент_2».
Источник записей: аналогичное поле в исходной таблице.
17) «КурсДоллара» (Курс $).
Назначение: для отображения сегодняшнего курса доллара.
Заполнение: ввод с клавиатуры (пока).
Источник записей: аналогичное поле в исходной таблице.
Поле392
18) «Поле392» (Сумма в $).
Назначение: свободное поле для отображения суммы агентского вознаграждения выдаваемого агенту от суммы данного счета в долларах.
Заполнение: =[ВознагрАгент]/[КурсДоллара].
19) «СуммаСНакоплением».
Назначение: свободное поле для отображения общей суммы заказов проданных вышеуказанным агентом в долларах.
Заполнение: в процедуре обработки событий по событию «После обновления» для поля «КодАгента».
20) «КодЗаказчика» - скрытое поле.
Назначение: главное связующее поле по для форм Подчиненная1 и Основная.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
б) Флажки.
1) «ВыпискаНакладной» и «ВыпискаАктов».
Назначение: отметка о выписке актов и накладных при покупке системы.
Заполнение: по процедуре обработки события для кнопки «Кнопка174» в форме Основная.
Источник записей: аналогичное поле в исходной таблице.
2) «ОплатаСчета».
Назначение: отметка об оплате текущего счета.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
Примечание: в процедуре обработки событий по событию «После обновления» для данного поля свойству Visible формы Подчиненая1.2 присваивается значение True или False в зависимости от факта оплаты счета (листинг 3.29).
3) «ВнесениеВАО»(Внесение в авансовый отчет). - скрытое поле
Назначение: отметка о внесение суммы по текущему счету в авансовый отчет.
Заполнение: по процедуре обработки события для кнопки «Кнопка347» в текущей форме.
Источник записей: аналогичное поле в исходной таблице.
в) Группы.
1) «Группа337».
Назначение: переключение между информацией о счете и информацией о заказах, входящих в счет.
Примечания: * автоматическое вычисление следующего номера накладной (поле «НомерНакладной»в текущей форме) и счета-фактуры (поле «НомерСчетаФактуры» в форме Подчиненая1.3) в процедуре обработки событий по событию «После обновления» для данной группы (листинг 3.30).
г) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка322», «Кнопка323», «Кнопка324», «Кнопка325».
Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.
Примечания: * по процедурам обработки событий для данных кнопок происходит очистка содержимого временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной» (листинг 3.31).
2) «Кнопка347».
Назначение: для занесения данных по текущему счету в авансовый отчет (листинг 3.32).
Примечания: * отладить возникновение ошибок и тестировать, тестировать, тестировать.
3) «Кнопка368».
Назначение: для удаления данных по текущему счету из авансового отчета (листинг 3.33).
Примечания: * пользоваться аккуратно.
Форма «ПросмотрSubSub».
а) Поля.
1) «КодСистемы» (Система).
Назначение: для выбора и отображения системы, на которую будет оформлена запись в счете.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
Примечание: *нужно ли позволять выбор и ввод в этом и следующих полях, кроме поля «НомерДистрибутива»
2) «Код» (Тип системы) - поле со списком.
Назначение: для выбора и отображения типа системы, на которую будет оформлена запись в счете.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
3) «СпецвыпускИлиНет» - флажок. (Спецвыпуск).
Назначение: для указания и отображения, является ли данный дистрибутив спецвыпуском или нет.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
4) «НомерДистрибутива».
Назначение: для ввода и отображения, номера дистрибутива выписываемой системы.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
5) «Скидки» (Скидки на систему). - необходимость в данной форме ???.
Назначение: для ввода и отображения величены скидки на систему при продаже.
Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).
Источник записей: аналогичное поле в исходной таблице.
6) «КоличествоМ» (Количество месяцев) - необходимость в данной форме ???.
Назначение: для ввода и отображения количества месяцев сопровождения на текущую систему.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
7) «СкидкиС» (Скидки на сопров.) - необходимость в данной форме ???.
Назначение: для ввода и отображения величены скидки на сопровождение.
Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).
Источник записей: аналогичное поле в исходной таблице.
8) «Цена» (Поставка).
Назначение: для ввода и отображения цены на систему при покупке.
Источник записей: аналогичное поле в исходной таблице.
9) «Сопровождение». - необходимость в данной форме ???.
Назначение: для ввода и отображения цены на сопровождение.
Источник записей: аналогичное поле в исходной таблице.
10) «СистемыНаВыписку» - список.
Назначение: свободное поле для отображения перечня заказов входящих в счет.
Заполнение: по SQL - запросу.
Источник строк: SQL - запрос по таблице «НаВыпискуСчета».
(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)
Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).
11) «КодСчета» - скрытое поле.
Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.1.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
12) «КодМесяца» - скрытое поле.
Назначение: для фиксации значения месяца прейскуранта по которому был выписан счет.
Источник записей: аналогичное поле в исходной таблице.
Примечание: используется при выписке актов.
б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «КнопкаНЗ» (Добавить в накладную >).
Назначение: занесение информации для данного заказа счета во временную таблицы «НаВыпискуСчета» и «НаВыпискуНакладной»с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку») и переход на следующую запись в текущей форме (для ввода информации по следующему заказу счета) (листинг 3.34).
Примечания: - .
2) «Кнопка49», «Кнопка50», «Кнопка51», «Кнопка52».
Назначение: для перехода по записям для текущей формы (заказы для данной счета). Реализация с помощью мастера.
Форма «Платежки» -ленточная форма.
а) Поля.
1) «НомерПлатежки».
Назначение: для ввода и отображения номера платежного поручения, оплачивающего текущий счет.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
2) «ДатаПлатежки».
Назначение: для ввода и отображения даты платежного поручения, оплачивающего текущий счет.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
3) «СуммаПлатежки».
Назначение: для ввода и отображения суммы по платежному поручению, оплачивающего текущий счет.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
4) «ДатаВыписки».
Назначение: для ввода и отображения даты выписки платежного поручения, оплачивающего текущий счет.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
5) «КодСчета» - скрытое поле.
Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.2.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
Форма «СчетаФактурыОсновные».
а) Поля.
1) «НомерСчетаФактуры».
Назначение: для ввода и отображения номера счета-фактуры для текущего счета.
Заполнение: ввод с клавиатуры или в процедуре обработки событий по событию «После обновления» для группы «Группа337».
Источник записей: аналогичное поле в исходной таблице.
2) «КодСчета» - скрытое поле.
Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.3.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
Комментарии.
Описанная структура имеет следующие особенности работы
1. Для формы Основная и ПросмотрSub по событию «Текущая запись» в процедуре обработки событий происходит проверка значения поля «ОплатаСчета» и в соответствии с этим свойству формы Подчиненная1.2 задается значение True или False.(листинг 3.35).
3. Оформление, учет и выписка первичной бухгалтерской документации (счетов) по дополнительным заказам (программное и аппаратное обеспечение, информационные услуги)
Для реализации данного этапа была разработана структура взаимодействия трех форм:
1. «ДругиеЗаказыОформление» - основная
(источник записей таблица «Заказчики»).
2. «ДругиеСчетаПод» - подчиненная1 (к основной)
(источник записей таблица «ДругиеСчета»).
3. «ДругиеСчетаПодПод» - подчиненная1.1 (к подчиненной1)
(источник записей таблица «Дистрибутивы»).
Данные три формы получены модификацией комплекса форм по выписке основных счетов. При модификации у форм «ОсновнаяОформлениеСчетов» и «ОсновныеСчета:Подчиненая» были изменены только источник данных (таблицы) и измены соответствующие имена полей и форм функциях. Поэтому в данном разделе будут рассмотрены только дополнения и изменения к исходным формам.
Форма «ДругиеЗаказыОформление».
а) Поля - аналогичны.
б) Группы - аналогичны.
в) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка170».
Назначение: для предварительного просмотра образца счета, выписанного на текущую организацию. Процедура обработки событий (листинг 3.36).
Примечания: реализация с помощью мастера, проверка значений формы критических для выписки счета.
Форма «ДругиеСчетаПод».
а) Поля - аналогичны, кроме:
1) «Цена», «Сопровождение», «ЦенаСпецВыпуска».
Назначение: для ввода и отображения номера счета-фактуры для текущего счета.
Заполнение: ввод с клавиатуры или в процедуре обработки событий по событию «После обновления» для группы «Группа337».
Источник записей: аналогичное поле в исходной таблице.
б) Кнопки - аналогичны, кроме. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «КнопкаНоваяЗапись».
Назначение: для перехода на новую запись для данной форма (новый счет для текущей организации) и заполнения поля «НомерСчета» следующим номером согласно существующей номенклатуре, очистка временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной». Процедура обработки событий (листинг 3.37).
Примечания: * отладить на возникновение ошибок при нестандартном номере предыдущего счета.
2) «Кнопка333», «Кнопка334», «Кнопка335», «Кнопка336».
Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.
Форма «ДругиеСчетаПодПод».
а) Поля.
1) «КодСистемы» (Наименование).
Назначение: для ввода и отображения наименования товара в заказе для текущего счета.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
2) «Примечания».
Назначение: для ввода и отображения примечания к товару в заказе для текущего счета.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
3) «НомерДистрибутива» (Рег. номер).
Назначение: для ввода и отображения уникального идентификационного номера товара в заказе для текущего счета (если он есть).
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
4) «Количество».
Назначение: для ввода и отображения количества единиц товара в заказе для текущего счета (если он есть).
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
5) «Цена».
Назначение: для ввода и отображения стоимости указанного количества товара (без НДС) в заказе для текущего счета (то есть вводимое значение = цена 1-й ед. товара * кол-во товара).
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
5) «СистемыНаВыписку» -
список.
Назначение: свободное поле для отображения перечня заказов входящих в счет.
Заполнение: по SQL - запросу.
Источник строк: SQL - запрос по таблице «НаВыпискуСчета».
(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)
Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).
5) «КодСчета» - скрытое поле.
Назначение: главное связующее поле для форм Подчиненная1 и Подчиненная1.1.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка63» (Добавить новую >- при выписке в счете нового заказа).
Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуСчета» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку») и переход на новую запись в текущей форме (для ввода нового заказа счета). Процедура обработки событий (листинг 3.38).
Примечания: - .
2) «Кнопка69» (Добавить > - при повторной выписке счета).
Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуСчета» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку») и переход на следующую запись в текущей форме (для ввода или изменения следующего заказа счета). Процедура обработки событий (листинг 3.39).
Примечания: - .
3) «Кнопка71», «Кнопка72», «Кнопка73», «Кнопка75».
Назначение: для перехода по записям для текущей формы (заказы для данной счета). Реализация с помощью мастера.
4) «Кнопка70».
Назначение: для удаления выделенной записи в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.40).
Примечания: - .
5) «Кнопка74».
Назначение: для удаления всех записей в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета», обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.41).
Примечания: - .
4. Оформление, учет и выписка вторичной отчетной документации (акты на установку, накладные, счета-фактуры, акты на информационные услуги), фиксирование информации о приходе денежных средств по счетам, формирование первичного финансового отчета по дополнительным заказам организации (программное и аппаратное обеспечение, информационные услуги)
Для реализации данного этапа была разработана структура взаимодействия четырех форм:
1. «ПросмотрДрСчетов» - основная
(источник записей таблица «Заказчики»).
2. «ПросмотрДрСчетовSub» - подчиненная1 (к основной)
(источник записей таблица «ДругиеСчета»).
3. «ПросмотрДрСчетовSubSub» - подчиненная1.1 (к подчиненной1)
(источник записей таблица «ДругиеЗаказы»).
3. «ДругиеПлатежки» - подчиненная1.2 (к подчиненной1)
(источник записей таблица «ДругиеПлатежки»).
Данные формы получены модификацией комплекса форм по просмотру основных счетов. При модификации у форм были модифицированы основные функции в соответствии с данными и измены соответствующие имена полей и форм в функциях. Поэтому в данном разделе будут рассмотрены только дополнения и изменения к исходным формам.
Форма «ПросмотрДрСчетов».
а) Поля - аналогичны.
б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки») - аналогичны
в) Группы. (для групп процедуры обработки событий вызываются по событию «После обновления»).
1) «Группа 168» (Организация-Счет).
Назначение: для перехода между информацией о счете и адресными реквизитами для текущей организации. Процедура обработки событий (листинг 3.42)
Примечания: задание свойству «Visible» значения True или False в зависимости от положения переключателя.
Форма «ПросмотрДрСчетовSub».
а) Поля - аналогичны, кроме.
1) «НомерСчетаФактуры».
Назначение: для ввода или отображения номера счета-фактуры для данного счета.
Заполнение: ввод с клавиатуры(пока).
Источник записей: аналогичное поле в исходной таблице.
Примечание: сделать автоматическое заполнение, продумать автоматическое заполнение в зависимости от формы оплаты (номера счетов-фактур по оплате за наличный и безналичный расчет разные).
2) «НомерНакладной».
Назначение: для ввода или отображения номера накладной для данного счета.
Заполнение: ввод с клавиатуры(пока).
Источник записей: аналогичное поле в исходной таблице.
Примечание: сделать автоматическое заполнение.
в) Группы.
1) «Группа337».
Назначение: переключение между информацией о счете и информацией о заказах, входящих в счет.
Примечания:
г) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка322», «Кнопка323», «Кнопка324», «Кнопка325».
Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.
Примечания: * по процедурам обработки событий для данных кнопок происходит очистка содержимого временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной» (листинг 3.43).
2) «Кнопка347».
Назначение: для занесения данных по текущему счету в авансовый отчет (листинг 3.44).
Примечания: * отладить возникновение ошибок и тестировать, тестировать, тестировать.
3) «Кнопка368».
Назначение: для удаления данных по текущему счету из авансового отчета (листинг 3.45).
Примечания: * пользоваться аккуратно.
Форма «ПросмотрДрСчетовSubSub».
а) Поля
1) «Наименование».
Назначение: для ввода и отображения наименования товара в заказе для текущего счета.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
2) «Примечания».
Назначение: для ввода и отображения примечания к товару в заказе для текущего счета.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
3) «НомерДистрибутива» (Рег. номер). ?
Назначение: для ввода и отображения уникального идентификационного номера товара в заказе для текущего счета (если он есть).
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
4) «Количество».
Назначение: для ввода и отображения количества единиц товара в заказе для текущего счета (если он есть).
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
5) «Цена».
Назначение: для ввода и отображения стоимости указанного количества товара (без НДС) в заказе для текущего счета (то есть вводимое значение = цена 1-й ед. товара * кол-во товара).
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
6) «СистемыНаВыписку» -
список.
Назначение: свободное поле для отображения перечня заказов входящих в
счет-фактуру.
Заполнение: по SQL - запросу.
Источник строк: SQL - запрос по таблице «НаВыпискуСчета».
(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)
Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).
7) «Список63» - список.
Назначение: свободное поле для отображения заказов входящих в накладную.
Заполнение: по SQL - запросу.
Источник строк: SQL - запрос по таблице «НаВыпискуНакладной».
(SELECT DISTINCTROW НаВыпискуНакладной.Код, НаВыпискуНакладной.Система, НаВыпискуНакладной.[К-во] FROM НаВыпискуНакладной;)
Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).
8) «Список69» - список.
Назначение: свободное поле для отображения заказов входящих в акты (на
установку, информационные услуги).
Заполнение: по SQL - запросу.
Источник строк: SQL - запрос по таблице «НаВыпискуАктовИПС1».
(SELECT DISTINCTROW НаВыпискуАктовИПС1.Код, НаВыпискуАктовИПС1.Наименование FROM НаВыпискуАктовИПС1;)
Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).
9) «КодСчета» - скрытое поле.
Назначение: главное связующее поле для форм Подчиненная1 и Подчиненная1.1.
Заполнение: автоматически .
Источник записей: аналогичное поле в исходной таблице.
Примечание: не удалять.
г) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка59», «Кнопка60», «Кнопка61», «Кнопка62».
Назначение: для перехода по записям для текущей формы (заказы для данного счета). Реализация с помощью мастера.
Примечания: *
2) «КнопкаНЗ» (Добавить >).
Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуСчета» и «НаВыпискуНакладной» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку» и «Список63») и переход на следующую запись в текущей форме (для ввода в накладную и в счет-фактуру следующего заказа счета). Процедура обработки событий (листинг 3.46).
Примечания: - .
3) «Кнопка68» (Добавить в акт >).
Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуАктов» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «Список69») и переход на следующую запись в текущей форме (для ввода в акт следующего заказа счета). Процедура обработки событий (листинг 3.47).
Примечания: - .
4) «Кнопка70».
Назначение: для удаления выделенной записи в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.48).
Примечания: - .
5) «Кнопка74».
Назначение: для удаления всех записей в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета», обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.49).
Примечания: - .
6) «Кнопка66».
Назначение: для удаления выделенной записи в списке «Список63» из временной таблицы «НаВыпискуНакладной» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «Список63»). Процедура обработки событий (листинг 3.50).
Примечания: - .
7) «Кнопка65».
Назначение: для удаления всех записей в списке «Список63» из временной таблицы «НаВыпискуНакладной» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «Список63»). Процедура обработки событий (листинг 3.51).
Примечания: - .
6) «Кнопка71».
Назначение: для удаления выделенной записи в списке «Список69» из временной таблицы «НаВыпискуАктовИПС1» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «Список69»). Процедура обработки событий (листинг 3.52).
Примечания: - .
6) «Кнопка73».
Назначение: для удаления всех записей в списке «Список69» из временной таблицы «НаВыпискуАктовИПС1» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «Список69»). Процедура обработки событий (листинг 3.53).
Примечания: - .
Форма «ДругиеПлатежки» - ленточная форма.
а) Поля - аналогичны форме «Платежи»
5. Оформление счетов-фактур на сопровождение по авансовым остаткам с 1996 года
Для реализации данного этапа была разработана структура взаимодействия двух форм:
1. «ОформлениеСчетовФактур» - основная
(источник записей таблица «Заказчики»).
2. «ОформСчетовФактурSubSub» - подчиненная1 (к основной)
(источник записей таблица «СчетаФактуры»).
Форма «ОформлениеСчетовФактур».
Данная форма является модификацией формы «ОсновнаяОформлениеСчетов», поэтому в данном разделе описываются расхождения с вышеназванной формой.
а) Поля - аналогичны
б) Группы.
1) «Группа 168» (Организация - Счет-фактура).
Назначение: для перехода между информацией о счете-фактуре и адресными реквизитами для текущей организации. Процедура обработки событий (листинг 3.54)
Примечания: задание свойству «Visible» значения True или False в зависимости от положения переключателя.
в) Кнопки - аналогичны
Форма «ОформлениеСчетовФактур».
а) Поля
1) «КодСистемы».
Назначение: свободное поле для выбора и отображения типа услуг оказываемых организации.
Заполнение: выбор из списка.
Источник записей: список значений.
2) «Код» (Месяц).
Назначение: для выбора и отображения месяца за (по) который оказаны вышеназванные услуги.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
3) «КодДатаСчетаФактуры» (Дата счета-фактуры).
Назначение: для выбора и отображения последнего дня месяца выписываемого счета-фактуры.
Заполнение: выбор из списка.
Источник записей: аналогичное поле в исходной таблице.
4) «НомерСчетаФактуры» (№ счета-фактуры).
Назначение: для ввода и отображения номера выписываемого счета-фактуры (согласно существующей номенклатуре).
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
5) «Количество».
Назначение: для ввода и отображения количества месяцев, на которые оформляется счет-фактура.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
6) «Цена».
Назначение: для ввода и отображения стоимости услуг за вышеуказанное количество месяцев, на которые оформляется счет-фактура.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
7) «НомерПлатежки».
Назначение: для ввода и отображения номера платежного поручения, по которому оплачены вышеуказанные услуги.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
8) «ДатаПлатежки».
Назначение: для ввода и отображения даты платежного поручения, по которому оплачены вышеуказанные услуги.
Заполнение: ввод с клавиатуры.
Источник записей: аналогичное поле в исходной таблице.
9) «СистемыНаВыписку» -
список.
Назначение: свободное список для отображения перечня заказов входящих в
счет-фактуру.
Заполнение: по SQL - запросу.
Источник строк: SQL - запрос по таблице «НаВыпискуСчета».
(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)
Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).
б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)
1) «Кнопка63» (Добавить новую >- при выписке в счете нового заказа).
Назначение: занесение информации для данного заказа счета-фактуры во временную таблицу «НаВыпискуСчета» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку») и переход на новую запись в текущей форме (для ввода нового счета-фактуры). Процедура обработки событий (листинг 3.55).
Примечания: - .
2) «Кнопка69» (Добавить >).
Назначение: занесение информации для данного заказа счета-фактуры во временную таблицу «НаВыпискуСчета» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку») и переход на следующую запись в текущей форме (для ввода или изменения следующего заказа счета-фактуры). Процедура обработки событий (листинг 3.56).
Примечания: - .
3) «Кнопка71», «Кнопка72», «Кнопка73», «Кнопка75».
Назначение: для перехода по записям для текущей формы (счета -фактуры для данной организации). Реализация с помощью мастера.
4) «Кнопка70».
Назначение: для удаления выделенной записи в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.57).
Примечания: - .
5) «Кнопка74».
Назначение: для удаления всех записей в списке «СистемыНаВыписку» из временной таблицы «НаВыпискуСчета», обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку»). Процедура обработки событий (листинг 3.58).
Примечания: - .
6. Ввод прейскурантов на сопровождение и на системы.
В соответствии со структурой распределения цен на системы по регионам была разработана структура взаимодействия пяти форм:
1. «Прейскурант» - основная. (свободная форма)
2. «ПрейскурантОС» - подчиненная1 (к основной)
(источник записей таблица «ПрейскурантОС»).
3. «ПрейскурантОП» - подчиненная2 (к основной)
(источник записей таблица «ПрейскурантОП»).
4. «Прейскурант_Север» - подчиненная3 (к основной)
(источник записей таблица «Прейскурант_Север»).
5. «Прейскурант_Россия» - подчиненная4 (к основной)
(источник записей таблица «Прейскурант_Россия»).
Форма «Прейскурант».
а) Кнопки
1) «Кнопка119»(Отдел продаж).
Назначение: для вывода на экран формы Подчиненная1 и скрытия форм Подчиненная2,3,4, замена подписи надписи «Регион» и надписи «Регион1» на ’ Отдел продаж ’. Процедура обработки событий (листинг 3.59).
Примечания: - .
2) «Кнопка117»(Отдел сопровождения).
Назначение: для вывода на экран формы Подчиненная2 и скрытия форм Подчиненная1,3,4, замена подписи надписи «Регион» и надписи «Регион1» на ’ Отдел сопровождения’. Процедура обработки событий (листинг 3.60).
Примечания: - .
3) «Кнопка118»(По России).
Назначение: для вывода на экран формы Подчиненная3 и скрытия форм Подчиненная1,2,4, замена подписи надписи «Регион» и надписи «Регион1» на ’ Исключая Москву и Московскую область’. Процедура обработки событий (листинг 3.61).
Примечания: - .
4) «Кнопка120»( и др.).
Назначение: для вывода на экран формы Подчиненная4 и скрытия форм Подчиненная1,2,3, замена подписи надписи «Регион» и надписи «Регион1» на ’ Для отдаленных и северных районов’. Процедура обработки событий (листинг 3.62).
Примечания: - .
5) «КнопкаВыход».
Назначение: закрытие текущей формы.
Примечания: реализация с помощью мастера.
Формы «ПрейскурантОС», «ПрейскурантОП», «Прейскурант_Север», «Прейскурант_Россия» являются однотипными простыми формами для ввода информации о ценах систем для разных регионов. Все поля в формах имеют источниками данных аналогичные поля в исходных таблицах для форм. Во всех формах присутствуют кнопки для навигации по записям (переход на новую, следующую и предыдущую записи)
В соответствии со структурой распределения цен на сопровождение по регионам и по типам пополнения была разработана структура взаимодействия четырех форм:
1. «ЦенаСистем» - основная. (свободная форма)
2. «ЦенаСистемМосква» - подчиненная1 (к основной)
(источник записей таблица «ЦенаСистемМосква»).
3. «ЦенаСистемРоссия» - подчиненная2 (к основной)
(источник записей таблица «ЦенаСистемРоссия»).
4. «ЦенаСистемСевер» - подчиненная3 (к основной)
(источник записей таблица «ЦенаСистемСевер»).
Форма «Прейскурант».
а) Кнопки
1) «Москва».
Назначение: для вывода на экран формы Подчиненная1 и скрытия форм Подчиненная2,3, замена подписи надписи «Регион» и надписи «Регион1» на ’ Москва и московская область’. Процедура обработки событий (листинг 3.63).
Примечания: - .
2) «Россия».
Назначение: для вывода на экран формы Подчиненная2 и скрытия форм Подчиненная1,3, замена подписи надписи «Регион» и надписи «Регион1» на ’ Исключая Москву и Московскую область’. Процедура обработки событий (листинг 3.64).
Примечания: - .
3) «ИТД»( и др.).
Назначение: для вывода на экран формы Подчиненная3 и скрытия форм Подчиненная1,2, замена подписи надписи «Регион» и надписи «Регион1» на ’ Для отдаленных и северных районов’. Процедура обработки событий (листинг 3.65).
Примечания: - .
4) «КнопкаВыход».
Назначение: закрытие текущей формы.
Примечания: реализация с помощью мастера.
Формы «ЦенаСистемМосква», «ЦенаСистемРоссия», «ЦенаСистемСевер»
являются однотипными простыми формами для ввода информации о сопровождении систем для разных регионов. Все поля в формах имеют источниками данных аналогичные поля в исходных таблицах для форм. Во всех формах присутствуют кнопки для навигации по записям (переход на новую, первую, следующую, предыдущую и последнюю записи)
7. Ввод и изменение адресных и банковских реквизитов организаций.
Форма «НовыеЗаказчики»
а) Поля
Поля данной формы являются простыми полями для ввода информации об адресных и банковских реквизитах организаций.
Поля для данной формы имеют источниками данных аналогичные поля в исходной таблице.
1) «Образец»
Назначение: свободное поле для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка56»(Найти).
Вводимое значение: текстовое или цифровое.
2) «Список57»(Список) - скрытое поле
Назначение: свободное поле для поиска организации и перехода на требуемую запись.
Источник записей: SQL - запрос по таблице «Заказчики».
Примечания: сформирован с помощью мастера.
б) Кнопки
1) «Кнопка50».
Назначение: для вывода на экран диалогового окна «СтатусЗаказчика», для ввода нового типа статуса организации (см пункт __ ).
Примечания: реализация с помощью мастера.
2) «Кнопка43».
Назначение: переход на новую запись для данной формы (ввод новой организации).
Примечания: реализация с помощью мастера.
3) «Кнопка44», «Кнопка45», «Кнопка46», «Кнопка47»
Назначение: переход по записям данной формы (первая, предыдущая, следующая и последняя записи).
Примечания: реализация с помощью мастера.
4) «Кнопка_Закрыть»
Назначение: закрытие данной формы.
Примечания: реализация с помощью мастера.
5) «Кнопка56»(Найти).
Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.66).
Примечания: - .
8. Изменение данных по авансовому отчету (корректировка распределения сумм по месяцам для организаций).
Для реализации данного этапа была разработана структура взаимодействия трех форм:
1. «ИзменитьАвансОтчет» - основная
(источник записей таблица «Заказчики»).
2. «SubИзменениеАавнсОтчета» - подчиненная1 (к основной)
(источник записей временная таблица «Изменение АвансОтчета»).
3. «ИзменАавнсОтчТАБЛ» - вспомогательная
(источник записей таблица «АвансовыйОтчет»).
Форма «ИзменитьАвансОтчет»
а) Поля
1) «Образец»
Назначение: свободное поле для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка24»(Найти).
Вводимое значение: текстовое или цифровое.
2) «Организация»
Назначение: для отображения названия текущей организации.
Источник записей: аналогичное поле в исходной таблице.
3) «Список13» - список.
Назначение: свободное поле для поиска организации и перехода на требуемую запись.
Источник записей: SQL - запрос по таблице «Заказчики».
Примечания: сформирован с помощью мастера.
б) Кнопки
1) «Кнопка24»(Найти).
Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.67).
Примечания:.
2) «КнопкаЗакрытьФорму» (Настройки счета).
Назначение: для закрытия текущей формы.
Примечания: реализация с помощью мастера.
Форма «SubИзменениеАавнсОтчета» - ленточная форма
а) Поля
1) «ПоСчету»
Назначение: для отображения номера счета по которому было выписано сопровождение для текущей организации.
Источник записей: аналогичное поле в исходной таблице.
2) «КодСистемы»
Назначение: для отображения названия системы, на которую было выписано сопровождение для текущей организации.
Источник записей: аналогичное поле в исходной таблице.
3) «ДатаНМС» - скрытое поле
Назначение: для хранения даты начального месяца сопровождения по данному счету.
Источник записей: аналогичное поле в исходной таблице.
4) «Поле2» - скрытое поле
Назначение: для хранения даты последнего месяца сопровождения по данному счету.
Источник записей: аналогичное поле в исходной таблице.
5) «ИдентКод» - скрытое поле
Назначение: для хранения уникального кода записи в авансовом отчете. Значение используется, как значение фильтра при вызове диалогового окна «ИзменАавнсОтчТАБЛ».
Источник записей: аналогичное поле в исходной таблице.
6) «Поле4»
Назначение: для отображения даты первого месяца сопровождения по данному счету.
Источник записей: =Format([ДатаHMC];"mmmm yyyy").
7) «ДатаПМС»
Назначение: для отображения даты последнего месяца сопровождения по данному счету.
Источник записей: =Format([Поле2];"mmmm yyyy")
б) Кнопки
1) «Кнопка14» (...).
Назначение: для вызова диалогового окна «ИзменАавнсОтчТАБЛ», с применением фильтра по соответствующему значению в поле «ИдентКод» (листинг 3.68).
Примечания: реализация с помощью мастера.
Форма «ИзменАавнсОтчТАБЛ» - ленточная форма
а) Поля
1) «Месяц»
Назначение: для отображения месяца авансового отчета.
Источник записей: аналогичное поле в исходной таблице.
2) «Сумма»
Назначение: для отображения суммы по соответствующему месяцу авансового отчета.
Источник записей: аналогичное поле в исходной таблице.
3) «ИдентКод» - скрытое поле
Назначение: для хранения уникального кода записи по авансовому отчету. Значение по которому используется фильтр при вызове диалогового окна «ИзменАавнсОтчТАБЛ».
Источник записей: аналогичное поле в исходной таблице.
б) Кнопки
1) «Кнопка8» (Выход).
Назначение: для закрытия текущей формы.
Примечания: реализация с помощью мастера.
Комментарии.
Описанная структура имеет следующие особенности работы
1. Для формы Основная по событию «Текущая запись» в процедуре обработки событий происходит заполнение временной таблицы «Изменение АвансОтчета» и обновление формы, с целью отображения последних изменений с подчиненной форме .
(листинг 3.69).
9. Общая результирующая информация по организациям, адресные и банковские реквизиты, счета, выписанные на организации, информация по системам для данной организации.
Для реализации данного этапа была разработана структура взаимодействия трех форм:
1. «ИнфПоОрганизациям» - основная
(источник записей таблица «Заказчики»).
2. «ИнфоПоОрганСистемы» - подчиненная1 (к основной)
(источник записей временная таблица «ИнфоПоСистемамЗаказчика»).
3. «ИнфоПоОрганSub» - подчиненная2 (к основной)
(источник записей временная таблица «ИнфоПоСистемамЗаказчика»).
Форма «ИнфПоОрганизациям»
а) Поля
1) «Образец»
Назначение: свободное поле для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка24»(Найти).
Вводимое значение: текстовое или цифровое.
2) «Список13» - список.
Назначение: свободное поле для поиска организации и перехода на требуемую запись.
Источник записей: SQL - запрос по таблице «Заказчики».
Примечания: сформирован с помощью мастера.
3) Другие поля данной формы являются полями для отображения адресных и банковских реквизитов текущей организации и имеют источниками данных соответствующие поля в исходной таблице.
б) Кнопки
1) «Кнопка24»(Найти).
Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.70).
Примечания:.
2) «Кнопка57» (Обновить) - необходимость?.
Назначение: для обновления данных для текущей формы. Процедура обработки событий (листинг 3.71).
Примечания: считывание обновленных данных из исходной таблицы на сетевом диске.
3) «Кнопка26» (Адрес, реквизиты).
Назначение: для вывода на экран адресных и банковских реквизитов организации (листинг 3.72).
Примечания: задание свойству Visible форм Подчиненная1 и Подчиненная2 значения False.
4) «Кнопка28» (Счета).
Назначение: для вывода на экран информации по счетам выписанным для текущей организации. (листинг 3.73).
Примечания: заполнение временной таблицы «ИнфоПоСистемамЗаказчика», задание свойству Visible формы Подчиненная1 значения True и Подчиненная2 значения False.
5) «Кнопка27» (Системы).
Назначение: для вывода на экран информации по системам для текущей организации. (листинг 3.74).
Примечания: заполнение временной таблицы «ИнфоПоСистемамЗаказчика», задание свойству Visible формы Подчиненная1 значения False и Подчиненная2 значения True.
6) «Кнопка25» (Выход).
Назначение: для закрытия текущей формы.
Примечания: реализация с помощью мастера.
Форма «ИнфоПоОрганСистемы» - ленточная форма
а) Поля данной формы являются полями для отображения информации временной таблицы источника данных формы и имеют источниками данных соответствующие поля в исходной таблице.
Форма «ИнфоПоОрганSub» - ленточная форма
а) Поля
1) «Поле4»
Назначение: для отображения даты начала сопровождения текущей системы по последнему выписанному и оплаченному счету.
Источник записей: =Format([Поле20];"mmmm yyyy").
2) «ДатаПМС»
Назначение: для отображения даты конца сопровождения текущей системы по последнему выписанному и оплаченному счету.
Источник записей: =Format([Поле2];"mmmm yyyy").
3) Другие поля данной формы являются полями для отображения адресных и банковских реквизитов текущей организации и имеют источниками данных соответствующие поля в исходной таблице.
10. Обмен сообщениями между пользователями (в дальнейшем возможно использование для заказа счетов актов и так далее? ).
Форма «Сообщения»
а) Поля
1) «username» (Кому) - поле со списком
Назначение: для выбора имени пользователя, которому должно быть отправлено сообщение.
Источник строк: SQL - запрос.
Заполнение: по SQL - запросу.
(SELECT DISTINCTROW [usersTable].[Код], [usersTable].[user] FROM [usersTable];)
Примечания:
2) «messageText» (Текст сообщения)
Назначение: для ввода текста сообщения.
Заполнение: ввод с клавиатуры.
б) Кнопки
1) «Кнопка8» (Послать сообщение).
Назначение: для отсылки сообщения. Процедура обработки событий (листинг 3.75).
Примечания: заполнение временной таблицы «flagsTable».
2) «Кнопка28» (Выход).
Назначение: для закрытия текущей формы.
Примечания: реализация с помощью мастера.
Форма «HiddenFormForCheck»
Данная форма открывается при загрузке базы данных и свойству Visible для данной формы задается значение False.
Комментарии.
Описанная структура имеет следующие особенности работы
1. Для формы HiddenFormForCheck по событию «Таймер» в процедуре обработки событий происходит проверка содержимого таблицы «flagsTable» на наличие соответствующего имени пользователя для проверки наличия сообщения для него.
(листинг 3.76).
11. Инициализация глобальных переменных НдсДляСчета и ВалДляСчета.
Данные переменные инициализируются при открытии базы данных в модуле «Сервис» в «Общей области», и используются при выписке счетов, актов , счетов-фактур, накладных.
Форма «ТипСчета» и «ТипСчета1»
а) Группы
1). «Группа0»
Назначение: для задание, по событию «После обновления» в процедуре обработке событий, глобальной переменной НдсДляСчета значения True или False в зависимости от положения переключателей. (листинг 3.77).
2). «Группа11»
Назначение: для задание, по событию «После обновления» в процедуре обработке событий, глобальной переменной ВалДляСчета значения True или False в зависимости от положения переключателей. (листинг 3.78).
Заключение. Оценка качества программного обеспечения.
Оценка качества программного обеспечения совсем новая дисциплина. Когда это направление получит достаточное развитие, то будут разработаны хорошие методы оценки, но в настоящее время имеются самые противоречивые мнения о том, какие характеристики программного обеспечения следует измерять. Методология разработки программного обеспечения развивается так быстро, что установление отдельных оценок и "отливка этих оценок в бронзе" могут привести к укоренению практики программирования, которая впоследствии окажется неправильной.
Боэм, Браун и Лайпоу занимались проблемой вычисления единой обобщающей меры качества и пришли к выводу, что это невозможно, так как входит в противоречие с частными характеристиками качества. Руководство должно принять решение об относительной важности следующих характеристик:
1) своевременное выполнение;
2) эффективность использования таких ресурсов, как:
а) процессоры;
б) память;
в) периферийные устройства;
3) аспекты обслуживания программы, такие как:
а) понимаемость;
б) модифицируемость;
в) удобство переноса с ЭВМ на ЭВМ.
Важность входящих в данный перечень характеристик изменяется в зависимости от того, в какой организации используется данное программное обеспечение. Разработчики программных библиотек могут предпочесть эффективности удобство переноса, в то время как создатели систем учета кадров могут сосредоточить свое внимание на модифицируемости.
Метрики Боэма, Брауна и Лайпоу.
Чтобы оценить качество, необходимо определить измеряемые характеристики. Боэм, Браун и Лайпоу описали иерархическое дерево характеристик программного обеспечения, в котором направление стрелок задает логическое следование. Так, например, хорошо поддерживаемая программа должна быть хорошо тестируемой, понимаемой и модифицируемой. Самый высокий уровень структуры отражает используемую оценку качества программного обеспечения. Боэм, Браун и Лайпоу подчеркивают достоинства пакетов программ и считают, что наибольшее значение для них имеют ответы на такие вопросы:
1. Как хорошо (просто, надежно, эффективно) могу я использовать данный пакет в том виде, как он есть?
2. Насколько просто его обслуживать (разобраться в нем, модифицировать, перепроверить)?
3. Могу ли я пользоваться этим пакетом, если сменю оборудование (удобство переноса)?
Характеристики самого нижнего уровня представляют собой "примитивы", комбинации которых образуют характеристики среднего уровня. Эти примитивы предлагаются в качестве количественных метрик как самих примитивных характеристик, так и характеристик более высоких уровней.
Боэм, Браун и Лайпоу разработали 51 возможную метрику оценки примитивных характеристик, а затем провели сравнение этих метрик по степени их корреляции с качеством программы. Это подробная и сложная схема, опирающаяся на практический опыт, однако, Боэм, Браун и Лайпоу не предложили четкой демонстрации ее эффективности, надежности или применимости в различных контекстах. Длинный список понятий используется скорее как контрольный лист для рецензирования программы, чем как руководство по ее составлению.
Метрики программного обеспечения Джилба.
Джилб приводит не претендующий на полноту набор метрик программного обеспечения. Он обращает внимание на то, что каждое приложение требует введения собственных понятий и инструментов; его книга предназначена для введения основных понятий, от которых может оттолкнуться пользователь.
Среди прочих характеристик Джилб упоминает надежность программы, которую он определяет как вероятность того, что данная программа проработает определенный период времени без логических сбоев. Прагматической оценкой программной надежности является единица минус отношение числа логических сбоев к общему числу запусков.
Отношение количества правильных данных ко всем данным приводится Джилбом в качестве меры точности (свободы от ошибок). Так же, как Боэм, Браун и Лайпоу, Джилб считает, что точность необходима для надежности программы. Прецизионность определяется как мера того, насколько часты ошибки, обусловленные одинаковыми причинами. Джилб оценивает ее дробью, в числителе которой стоит число фактических ошибок на входе, а в знаменателе - общее число наблюденных ошибок, причинами которых явились эти ошибки на входе. Так, например, если одна ошибка вызывает в течение определенного периода времени 100 сообщений об ошибках, то прецизионность равна 0.01.
Второй большой категорией, введенной Джилбом, является гибкость, в которую входят:
1) логическая сложность;
2) внутренняя гибкость;
3) открытость (адаптируемость);
4) толерантность (к изменениям входа системы);
5) универсальность;
6) удобство переноса;
7) совместимость.
В качестве меры логической сложности Джилб предложил число логических "двоичных принятий решений". Такая оценка может быть получена вручную или автоматически. Абсолютная логическая сложность задается числом нестандартных выходов из операторов, в которых происходит принятие решений. Джилб предполагает, что логическая сложность окажется значимым фактором для предсказания стоимости программы.
Кроме этих, Джилб приводит еще большое количество иных метрик, но это длинное перечисление скорее будит воображение, чем приносит пользу. Работа Джилба демонстрирует новые возможности, однако реальное применение этих идей на практике дает обескураживающие результаты. Большинство характеристик очень трудно получить; сбивает с толку и то, что оценки сильно связаны, что затрудняет программисту предсказание влияния изменения программы на некоторую группу характеристик.
Оценка сложности Маккейба.
Маккейб описывает оценку сложности с помощью теории графов и демонстрирует ее применение для управления, тестирования и контроля за сложностью программы. Следует оговорить, что в данном исследовании Маккейб под сложностью программы понимал ее логическую сложность. В его теории предполагается, что сложность не зависит от размера, а только от структуры выборов решений в программе.
Маккейб предлагает математический метод, дающий количественные основания для модуляризации и позволяющий выявлять модули, которые будет трудно тестировать или обслуживать.
Согласно его подходу вычисляется и контролируется число путей в программе. В математические предпосылки входит определение цикломатического числа V(G) для графа с n вершинами, e ребрами и p компонентами связности:
V(G) = e - n + p
Маккейб использует следующую теорему: в сильно связанном графе G цикломатическое число равно максимальному числу линейно-независимых циклов.
Применяя эту теорему, Маккейб связывает с программой ориентированный граф с одним выходом. Каждой вершине графа соответствует блок кода с последовательным управлением, а каждой дуге соответствует ветвление программы. Каждой вершины можно достигнуть из входной вершины и из каждой вершины может быть достигнута выходная вершина. Этот граф сильно связан, так как для любой пары вершин существует связывающий их путь.
Общий подход состоит в оценке сложности программы с помощью вычисления числа линейно-независимых путей, цикломатической сложности V(G), а также управления размером программ с помощью ограничения V(G) и использования V(G) как основы для методологии тестирования. Маккейб обнаружил, что разумной верхней границей для цикломатической сложности является 10. Если программисты переступают эту границу, им следует или переписать программу, или разбить ее на модули.
Оценка цикломатической сложности Маккейба полезна при подготовке тестовых данных и может дать нужную информацию о логической сложности программы. Однако при такой оценке не принимается во внимание выбор структур данных, алгоритмов, мнемонических имен переменных или комментариев, отсутствует обсуждение таких важных понятий, как удобство переноса, гибкость, эффективность. Необходимы дополнительные исследования, чтобы прояснить, когда полезно использовать цикломатическую сложность. В рассмотренном программном модуле по созданию базы данных абонентов автоматизированной системы оповещения циклическая граница сложности модуля равняется 6, что не превышает верхнюю границу сложности. Ориентированный граф модуля представлен на рис.14.1. Это позволяет сделать вывод о правильном подходе к написанию отдельных модулей программного обеспечения системы оповещения, который применялся при разработке данного дипломного проекта.
Понимаемость.
Понимаемость программы можно назвать ее психологическую сложность, так как психологическая сложность связана с теми же характеристиками программы, которые затрудняют понимание программы человеком.
Авторы работы "Predicting Software Comprehensibility" экспериментировали с 36 профессиональными программистами, предложив им по 25 минут изучать 3 программы, а затем восстановить их за 20 минут. Были использованы 3 класса задач (инженерные, статические и не численные) и 3 типа структурирования (полное, частичное и неструктурированные программы). Было также введено 3 уровня мнемоничности имен переменных.
Результаты эксперимента показали, что хуже всего восстанавливаются неструктурированные программы, лучше всего - частично структурированные. Уровень мнемоничности имен переменных не оказал влияния на проведение эксперимента.
Важным заключением этого эксперимента явилось то, что на способность правильно воспроизводить программы оказали влияние индивидуальные особенности участников, характеристики программы и уровень их структурированности.
Выводы.
Качество управляемо и может быть повышено. Администратор может выбрать принципы руководства, определив, что является основной целью - своевременная выдача результата, эффективное использование ресурсов или надежное обслуживание. В любом из этих случаев не следует забывать о психологической сложности программ. Как показывает опыт, в случае создания и отладки большого программного комплекса очень важно, чтобы программа каждого из авторов была понятна остальным, что обеспечивает четкую и безболезненную стыковку. К сожалению, приемлемый набор оценок пока еще не разработан. Глубокое теоретическое понимание поведения человека в программировании может привести к разработке более совершенных оценок, но проверить их пригодность следует экспериментально.
Список литературы к специальной части.
1. Р.Ахаян и др. «Эффективная работа с СУБД», Санкт-Петербург, «Питер», 1997г.
2. «Проектирование и разработка систем автоматизации предприятий».
3. «Database Unleashed», Indianapolis USA, «SAMS Publishing», 1996г.
4. Боуман Джудит, Эмерсон Сандра, Дарновски Марси. «Практическое руководство по SQL. 3-е издание». Пер с англ. – Киев, Диалектика. 1997.
5. Дейт, К. «Введение в системы баз данных».-М.:Наука, Диалектика. 1980.
6. Мартин, Дж. «Организация баз данных в вычислительных системах».-М.:Наука, Диалектика. 1980.
7. ANSI SQL Standart. The 1992 ISO-ANSI SQL standart is available through ANSI as document X3.135-1992 and through ISO as document ISO/EC 9075:1992.
8. Кодд, Е.Ф. «Реляционная модель данных». Пер с англ. – Киев, Диалектика. 1996.
9. Ипстейн, Роберт. «Реляционная производительность: Понимание производительности реляционных баз данных». Пер с англ. – Киев, Диалектика. 1996.
10. Ross, Ronald G. «Entity Modeling: Techniques and Application». Boston: Database Research Group, Inc. 1995.
11. Гайн, Крисс. «Введение в SQL» .-М.:Наука, Диалектика. 1980.
12. Праг, Керри Н. и др. «Секреты Access 97» Пер с англ. – Киев, Диалектика. 1997.
13. Кент, Вилиам. «Введение в пять нормальных форм в теории реляционных баз данных». Пер с англ. – Киев, Диалектика. 1996.
14. Ларcон, Брюс. «Руководство по экспертным базам данных». Пер с англ. – Киев, Диалектика. 1996.
15. Date C.J. «An Introduction to Database Systems» Volume 1, Reading, Mass.: Addison-Wesley Publishing Company, 1989.
16. Date C.J. «An Introduction to Database Systems» Volume 2, 2-th edition. Reading, Mass.: Addison-Wesley Publishing Company, 1989.
17. Перкинсон, Р.С. «Анализ данных: Ключ к проектированию баз данных». Пер с англ. – Киев, Диалектика. 1996.
18. Microsoft Corporation. «Описание Transact-SQL» .-М.:Наука, Диалектика. 1980.
Приложение А
Листинг программ
1) Преобразование числового денежного номера в строчное выражение
Public Function NewNumber(nnn As Double) As String
Dim numb(21) As String
Dim numb1(11) As String
Dim numb2(11) As String
Dim mil, tus, ed As Long
Dim sot, des, ed1 As Integer
Dim strval, strkop As String
Dim kop As Integer
Dim str1, str2 As String
Dim numstr As Integer
If (nnn > 999999999) Then
MsgBox ("Слишком большое число!")
Exit Function
End If
'
nnn = CDbl(Format(nnn, "Currency"))
If GetStrAfterSign(CStr(nnn) & "0") = "" Then
NewNumber = "00 копеек"
Exit Function
End If
kop = CInt(Left(GetStrAfterSign(CStr(nnn) & "0"), 2))
nnn = kop
numb(0) = " один"
numb(1) = " двe"
numb(2) = " три"
numb(3) = " четыре"
numb(4) = " пять"
numb(5) = " шесть"
numb(6) = " семь"
numb(7) = " восемь"
numb(8) = " девять"
numb(9) = " десять"
numb(10) = " одиннадцать"
numb(11) = " двенадцать"
numb(12) = " тринадцать"
numb(13) = " четырнадцать"
numb(14) = " пятнадцать"
numb(15) = " шестнадцать"
numb(16) = " семнадцать"
numb(17) = " восемнадцать"
numb(18) = " девятнадцать"
numb1(0) = " двадцать"
numb1(1) = " тридцать"
numb1(2) = " сорок"
numb1(3) = " пятьдесят"
numb1(4) = " шестьдесят"
numb1(5) = " семьдесят"
numb1(6) = " восемьдесят"
numb1(7) = " девяносто"
numb2(0) = " сто"
numb2(1) = " двести"
numb2(2) = " триста"
numb2(3) = " четыреста"
numb2(4) = " пятьсот"
numb2(5) = " шестьсот"
numb2(6) = " семьсот"
numb2(7) = " восемьсот"
numb2(8) = " девятьсот"
numb(19) = " одна"
numb(20) = " две"
mil = nnn 1000000
tus = (nnn - mil * 1000000) 1000
ed = nnn - mil * 1000000 - tus * 1000
If (mil <> 0) Then
sot = mil 100
des = (mil - sot * 100) 10
ed1 = mil - sot * 100 - des * 10
If (sot > 0) Then
strval = strval & numb2(sot - 1)
End If
If (des > 0) Then
If (des = 1) Then
strval = strval & numb(des * 10 + ed1 - 1) & " миллионов"
GoTo nex
Else
strval = strval & numb1(des - 2)
End If
End If
If (ed1 = 0) Then
strval = strval & " миллионов"
ElseIf (ed1 = 1) Then
strval = strval & " один миллион"
ElseIf (ed1 > 1 And ed1 < 5) Then
strval = strval & numb(ed1 - 1) & " миллиона"
Else
strval = strval & numb(ed1 - 1) & " миллионов"
End If
End If
nex:
If (tus <> 0) Then
sot = tus 100
des = (tus - sot * 100) 10
ed1 = tus - sot * 100 - des * 10
If (sot > 0) Then
strval = strval & numb2(sot - 1)
End If
If (des > 0) Then
If (des = 1) Then
strval = strval & numb(des * 10 + ed1 - 1) & " тысяч"
GoTo nex1
Else
strval = strval & numb1(des - 2)
End If
End If
If (ed1 = 0) Then
strval = strval & " тысяч"
ElseIf (ed1 = 1) Then
strval = strval & " одна тысяча"
ElseIf (ed1 = 2) Then
strval = strval & " две тысячи"
ElseIf (ed1 > 2 And ed1 < 5) Then
strval = strval & numb(ed1 - 1) & " тысячи"
Else
strval = strval & numb(ed1 - 1) & " тысяч"
End If
End If
nex1:
If (ed <> 0) Then
sot = ed 100
des = (ed - sot * 100) 10
ed1 = ed - sot * 100 - des * 10
If (sot > 0) Then
strval = strval & numb2(sot - 1)
End If
If (des > 0) Then
If (des = 1) Then
strval = strval & numb(des * 10 + ed1 - 1) & " копеек"
GoTo nex2
Else
strval = strval & numb1(des - 2)
End If
End If
If (ed1 = 0) Then
strval = strval & " копеек"
ElseIf (ed1 = 1) Then
strval = strval & " одна копейка"
ElseIf (ed1 > 1 And ed1 < 5) Then
strval = strval & numb(ed1 - 1) & " копейки"
Else
strval = strval & numb(ed1 - 1) & " копеек"
End If
Else
strval = strval & " копеек"
End If
nex2:
strval = LTrim(strval)
NewNumber = strval
End Function
2) Занесение денежных средств по счету на авансовый остаток.
Sub Кнопка347_Click()
On Error GoTo Err_Кнопка347_Click
Dim dbs As Database
Dim rst, rstПоCчету, rstПоАО As Recordset
Dim rstПоДате As Recordset
Dim strSQL As String
Dim i, j As Integer
Dim Цена, ЦенаП, Сопровождение, Сумма As Double
Dim Дата As Date
Dim ДатаTMP As Date
Dim ДатаПМС As Date
Dim ДатаTMP2 As Date
Dim ДАТАПМП As Date
Dim flagДата As Boolean
Dim flagБольше As Boolean
Dim flagГолоеСопр As Boolean
Dim Разница As Currency
Dim sing As String
'Dim ЦенаП_Р, Сумма_Р As Currency
flagБольше = False
Set dbs = CurrentDb
Me.Refresh
sing = Chr(34)
Set dbs = CurrentDb
strSQL = "SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Дистрибутивы.Цена AS Цена, Дистрибутивы.Сопровождение AS Сопровождение FROM [ОсновныеСчета] INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета WHERE (((ОсновныеСчета.НомерСчета)=" & sing & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & sing & "));"
Set rst = dbs.OpenRecordset(strSQL)
If Forms![Просмотр]![ОсновныеСчета].Form![ВнесениеВАО] = True And Разница = 0 Then
Msg = "Суммы по счету уже внесены в авансовый отчет." ' Сообщение.
Style = vbOKCancel + vbQuestion ' Кнопки.
Title = "Сообщение" ' Заголовок.
Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.
If Response = vbOK Then ' Если нажата кнопка "Да" (Yes).
GoTo labelBegin
Else
Exit Sub
End If
End If
labelBegin:
Цена = 0
Сопровождение = 0
rst.MoveLast
j = rst.RecordCount
rst.MoveFirst
For i = 1 To j
Цена = rst![Цена] * 1.2 + Цена
Сопровождение = rst![Сопровождение] * 1.2 + Сопровождение
rst.MoveNext
Next i
Сумма = Цена + Сопровождение
Forms![Просмотр]![ОсновныеСчета].Form![ПоСчету] = Сумма
rst.Close
strSQL = "SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Платежки.СуммаПрихода As Цена, Платежки.ДатаВыписки As Дата FROM [ОсновныеСчета] INNER JOIN Платежки ON ОсновныеСчета.КодСчета = Платежки.КодСчета WHERE (((ОсновныеСчета.НомерСчета)=" & sing & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & sing & "));"
Set rst = dbs.OpenRecordset(strSQL)
rst.MoveLast
Дата = rst![Дата]
j = rst.RecordCount
rst.MoveFirst
For i = 1 To j
ЦенаП = rst![Цена] + ЦенаП
rst.MoveNext
Next i
Forms![Просмотр]![ОсновныеСчета].Form![ПоПлатежке] = ЦенаП
rst.Close
If ЦенаП < Сумма Then
Msg = "Cумма по счету" & Chr(13) & " - " & Сумма & "р." & Chr(13) & "Cуммы по платежкам " & Chr(13) & " - " & ЦенаП & "р." & Chr(13) & "Cуммы по платежкам меньше суммы по счета." ' Сообщение.
'Msg = "Cуммы по платежкам меньше суммы по счетам." & Chr(13) & "Занести в авансовый отчет?" ' Сообщение.
Style = vbCancel + vbCritical ' Кнопки.
Title = "Предупреждение" ' Заголовок.
Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.
Exit Sub
End If
If ЦенаП > Сумма Then
Msg = "Cумма по счету" & Chr(13) & " - " & Сумма & "р." & Chr(13) & "Cуммы по платежкам " & Chr(13) & " - " & ЦенаП & "р." & Chr(13) & "Cуммы по платежкам больше суммы по счета." ' Сообщение.
'Msg = "Cуммы по платежкам больше суммы по счета." & Chr(13) & "Занести в авансовый отчет?" ' Сообщение.
Style = vbOKCancel + vbCritical ' Кнопки.
Title = "Предупреждение" ' Заголовок.
Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.
If Response = vbOK Then ' Если нажата кнопка "Да" (Yes).
flagБольше = True
Разница = ЦенаП - Сумма
GoTo labelOK
Else
Exit Sub
End If
End If
'ЦенаП_Р = ЦенаП
'Сумма_Р = Сумма
Msg = "Cумма по счету" & Chr(13) & " - " & Сумма & "р." & Chr(13) & "Cуммы по платежкам " & Chr(13) & " - " & ЦенаП & "р." & Chr(13) & "Суммы совпадают." & Chr(13) & "Занести в авансовый отчет?" ' Сообщение.
Style = vbOKCancel + vbInformation ' Кнопки.
Title = "Сообщение" ' Заголовок.
Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.
If Response = vbOK Then ' Если нажата кнопка "Да" (Yes).
Forms![Просмотр]![ОсновныеСчета].Form![Разница] = 0
GoTo labelOK
Else
Exit Sub
End If
labelOK:
Set rst = dbs.OpenRecordset("ДанныеДляАвансОтчета")
strSQL = "SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Дистрибутивы.КодСистемы, Дистрибутивы.Цена, Дистрибутивы.ТолькоИПС, Дистрибутивы.Сопровождение, Дистрибутивы.КоличествоМ, Дистрибутивы.Количество FROM [ОсновныеСчета] INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета WHERE (((ОсновныеСчета.НомерСчета)=" & sing & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & sing & "));"
'"SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Дистрибутивы.КодСистемы, Дистрибутивы.Цена, Дистрибутивы.Сопровождение, Дистрибутивы.КоличествоМ, Дистрибутивы.Количество FROM [ОсновныеСчета] INNER JOIN Дистрибутивы ON ОсновныеСчета.НомерСчета = Дистрибутивы.НомерСчета WHERE (((ОсновныеСчета.НомерСчета)=" & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & "));"
Set rstПоCчету = dbs.OpenRecordset(strSQL)
Set rstПоАО = dbs.OpenRecordset("АвансовыйОтчет")
rstПоCчету.MoveLast
j = rstПоCчету.RecordCount
ДатаStore = Дата
Select Case Forms![Просмотр]![ОсновныеСчета].Form![Код]
Case 1, 3
Нал = False
Case 2
Нал = True
End Select
rstПоCчету.MoveFirst
'ОСНОВНОЙ ЦИКЛ
flagДата = False
For i = 1 To j
'Проверка для вторичного ИПС
If rstПоCчету![Цена] = 0 Then
If flagДата = False Then
GoTo ДатаОпределение
End If
Дата = ДатаStore
Set dbs = CurrentDb
strSQLTMP = "SELECT DISTINCTROW ДанныеДляАвансОтчета.Код, ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС, Max(ДанныеДляАвансОтчета.ДатаПМС) AS ДатаПМС FROM [ДанныеДляАвансОтчета] GROUP BY ДанныеДляАвансОтчета.Код, ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС HAVING (((ДанныеДляАвансОтчета.КодЗаказчика)=" & Forms![Просмотр]![КодЗаказчика] & ") AND ((ДанныеДляАвансОтчета.КодСистемы)=" & rstПоCчету![КодСистемы] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0));"
Set rstTMP2 = dbs.OpenRecordset(strSQLTMP)
If rstTMP2.RecordCount >= 1 Then
GoTo labelЕстьЗаписи
'Else
'MsgBox ("Записей Нет")
Exit Sub
End If
labelЕстьЗаписи:
rstTMP2.MoveLast
rstTMP2.Close
Дата:
ДатаTMP2 = Format(ДатаStore, "m yy")
If flagГолоеСопр = True Then 'Расписать если сопров голое
rst.AddNew
rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]
rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]
rst![КодСистемы] = rstПоCчету![КодСистемы]
rst![ДатаПМС] = Format(ДатаTMP2, "m yy")
rst![КоличествоМС] = rstПоCчету![КоличествоМ]
rst![Нал] = Нал
Msg = "Заносим сопровождение " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & rstПоCчету![КоличествоМ] & " месяцев"
Style = vbOKCancel + vbInformation ' Кнопки.
Title = "Сообщение" ' Заголовок.
MsgBox Msg, Style, Title
rst.Update
rst.MoveLast
m = rstПоCчету![КоличествоМ]
For k = 1 To m
rstПоАО.AddNew
rstПоАО![ИдентКод] = rst![Код]
ЦенаСоп = rstПоCчету![Сопровождение] / m
rstПоАО![Сумма] = ЦенаСоп * 1.2
rstПоАО![Нал] = Нал
ДатаTMP = Format(ДатаПМС, "m yy")
rstПоАО![Месяц] = ДатаTMP
ДатаTMP = ДатаTMP + 32
ДатаПМС = ДатаTMP
rstПоАО.Update
Next k
GoTo labelnext
End If
'Сравнение с месяцем выписки
ДатаTMP2 = CDate(Format(ДатаStore, "m yy"))
If CDate(ДатаTMP2) <= CDate(ДатаПМС) Or (CDate(Format(ДатаStore, "m yy")) - CDate(Format(ДатаПМС, "m yy"))) / 100 = 1 Then
rst.AddNew
rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]
rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]
rst![КодСистемы] = rstПоCчету![КодСистемы]
ДАТАПМП = Format(ДатаПМС, "m yy")
ДАТАПМП = ДАТАПМП + 32
rst![ДатаПМС] = Format(ДатаTMP2, "m yy")
rst![КоличествоМС] = rstПоCчету![КоличествоМ]
rst![Нал] = Нал
Msg = "Заносим сопровождение " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & rstПоCчету![КоличествоМ] & " месяцев с " & CurrentMonthWParamWSuf(ДатаTMP2)
Style = vbOKOnly + vbInformation ' Кнопки.
Title = "Сообщение" ' Заголовок.
MsgBox Msg, Style, Title
rst.Update
rst.MoveLast
m = rstПоCчету![КоличествоМ]
For k = 1 To m
rstПоАО.AddNew
rstПоАО![ИдентКод] = rst![Код]
ЦенаСоп = rstПоCчету![Сопровождение] / m
rstПоАО![Сумма] = ЦенаСоп * 1.2
rstПоАО![Нал] = Нал
ДатаTMP = Format(ДАТАПМП, "m yy")
rstПоАО![Месяц] = ДатаTMP
ДатаTMP = ДатаTMP + 32
ДАТАПМП = ДатаTMP
rstПоАО.Update
Next k
Else
РазницаДат = (CDate(Format(ДатаStore, "m yy")) - CDate(Format(ДатаПМС, "m yy"))) / 100
rst.AddNew
rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]
rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]
rst![КодСистемы] = rstПоCчету![КодСистемы]
rst![ДатаПМС] = ДатаTMP2
rst![КоличествоМС] = rstПоCчету![КоличествоМ]
rst![Нал] = Нал
rst.Update
rst.MoveLast
rstПоАО.AddNew
rstПоАО![ИдентКод] = rst![Код]
ЦенаСоп = rstПоCчету![Сопровождение] / rstПоCчету![КоличествоМ]
rstПоАО![Сумма] = ЦенаСоп * 1.2 * CInt(РазницаДат)
rstПоАО![Нал] = Нал
ДатаTMP = Format(Дата, "m yy")
rstПоАО![Месяц] = ДатаTMP
ДатаTMP = ДатаTMP + 32
Дата = ДатаTMP
rstПоАО.Update
m = rstПоCчету![КоличествоМ]
For k = 1 To m - CInt(РазницаДат)
rstПоАО.AddNew
rstПоАО![ИдентКод] = rst![Код]
ЦенаСоп = rstПоCчету![Сопровождение] / m
rstПоАО![Сумма] = ЦенаСоп * 1.2
rstПоАО![Нал] = Нал
ДатаTMP = Format(Дата, "m yy")
rstПоАО![Месяц] = ДатаTMP
ДатаTMP = ДатаTMP + 32
Дата = ДатаTMP
rstПоАО.Update
Next k
End If
Else
'ДЛЯ ПЕРВИЧНОЙ ПОКУПКИ
Дата = ДатаStore
If rstПоCчету![Цена] <> 0 Then
rst.AddNew
rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]
rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]
rst![КодСистемы] = rstПоCчету![КодСистемы]
rst![ДатаПМС] = Дата
rst![КоличествоМС] = 0
rst![Нал] = Нал
rst.Update
rst.MoveLast
rstПоАО.AddNew
rstПоАО![ИдентКод] = rst![Код]
rstПоАО![Сумма] = rstПоCчету![Цена] * 1.2
rstПоАО![Месяц] = Дата
rstПоАО![Нал] = Нал
Msg = "Заносим сумму реализации системы " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & CurrentMWParam(Дата)
Style = vbOKOnly + vbInformation ' Кнопки.
Title = "Сообщение" ' Заголовок.
MsgBox Msg, Style, Title
rstПоАО.Update
End If
If rstПоCчету![Сопровождение] <> 0 Then
rst.AddNew
rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]
rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]
rst![КодСистемы] = rstПоCчету![КодСистемы]
rst![ДатаПМС] = Дата
rst![КоличествоМС] = rstПоCчету![КоличествоМ]
rst![Нал] = Нал
Msg = "Заносим сопровождение " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & rstПоCчету![КоличествоМ] & " месяцев с " & CurrentMonthWParamWSuf(Дата)
Style = vbOKOnly + vbInformation ' Кнопки.
Title = "Сообщение" ' Заголовок.
MsgBox Msg, Style, Title
rst.Update
rst.MoveLast
m = rstПоCчету![КоличествоМ]
For k = 1 To m
rstПоАО.AddNew
rstПоАО![ИдентКод] = rst![Код]
ЦенаСоп = rstПоCчету![Сопровождение] / m
rstПоАО![Сумма] = ЦенаСоп * 1.2
rstПоАО![Нал] = Нал
If Format(Дата, "dd") < 20 Then
ДатаTMP = Format(Дата, "m yy")
rstПоАО![Месяц] = ДатаTMP
ДатаTMP = ДатаTMP + 32
Дата = ДатаTMP
rstПоАО.Update
Else
ДатаTMP = Format(Дата + 12, "m yy")
rstПоАО![Месяц] = ДатаTMP
ДатаTMP = ДатаTMP + 32
Дата = ДатаTMP
rstПоАО.Update
End If
Next k
End If
End If
labelnext:
rstПоCчету.MoveNext
Next i
Код = rst![КодСистемы]
rst.Close
rstПоCчету.Close
rstПоАО.Close
labelEnd:
Forms![Просмотр]![ОсновныеСчета].Form![ВнесениеВАО] = True
If flagБольше = True Then
Set rst = dbs.OpenRecordset("КредитАванс")
rst.AddNew
rst.[КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]
rst![+или-] = Разница
rst![КодСистемы] = Код
rst![Месяц] = Дата
rst.Update
rst.Close
End If
Exit_Кнопка347_Click:
DoCmd.OpenTable "АвансовыйОтчет"
dbs.Close
Exit Sub
Err_Кнопка347_Click:
If Err.Number = 94 Then
MsgBox ("Задайте дату платежки")
Exit Sub
End If
If Err.Number = 3021 Then
DoCmd.OpenForm "Месяц2", , , , , acDialog
ДатаTMP3 = "01." & Forms![Месяц2]![Месяц] & "." & Forms![Месяц2]![Год]
ДатаПМС = Format(ДатаTMP3, "m yy")
flagГолоеСопр = True
'ДатаTMP3 = Forms![Месяц2]![Месяц]
'ДатаПМС = Format(ДатаTMP3, "m yy")
Resume Дата
End If
If Err.Number = 424 Then
Resume labelEnd
End If
If Err.Number = 2113 Then
Resume labelBegin
End If
' Вначале, вычитаем константу, добавленную объектом, чтобы получить
' собственный код ошибки объекта.
MyError = Err.Number - vbObjectError
' Если после вычитания константы vbObjectError число по-прежнему
' попадает в диапазон 0 - 65535, то ошибка определена в объекте.
If MyError > 0 And MyError < 65535 Then
Msg = "Адресуемый объект присвоил ошибке следующий код : " _
& MyError & ". Источником ошибки является: " _
& Err.Source & ". Нажмите клавишу F1 для вывода справки."
' В противном случае ошибке соответствует код ошибки Visual Basic.
Else
Msg = "Эта ошибка (# " & Err.Number & ") имеет код ошибки Visual" & _
" Basic. Для вывода раздела справки Visual Basic нажмите" & _
" кнопку 'Справка' или клавишу F1."
End If
MsgBox Msg, , "Ошибка объекта", Err.HelpFile, Err.HelpContext
Err.Number = 0
Resume Exit_Кнопка347_Click
ДатаОпределение:
strSQLДата = "SELECT DISTINCTROW ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС, Max(АвансовыйОтчет.Месяц) AS Max_Месяц FROM [ДанныеДляАвансОтчета] INNER JOIN [АвансовыйОтчет] ON ДанныеДляАвансОтчета.Код = АвансовыйОтчет.ИдентКод GROUP BY ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС HAVING (((ДанныеДляАвансОтчета.КодЗаказчика)=" & Forms![Просмотр]![КодЗаказчика] & ") AND ((ДанныеДляАвансОтчета.КодСистемы)=" & rstПоCчету![КодСистемы] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0));"
Set rstПоДате = dbs.OpenRecordset(strSQLДата)
rstПоДате.MoveLast
ДатаПМС = rstПоДате![Max_Месяц]
flagДата = True
rstПоДате.Close
GoTo Дата
End Sub
3) Просмотр информации по счетам и системам выбранного заказчика.
Private Sub Счет_Click()
Dim rst, rstTMP As Recordset
Dim dbs As Database
Dim i, j As Integer
Dim strSQL As String
Dim Дата As Date
Set dbs = CurrentDb
strSQL = "SELECT DISTINCTROW Заказчики.КодЗаказчика, ОсновныеСчета.НомерСчета, ОсновныеСчета.ОплатаСчета, ОсновныеСчета.ДатаСчета, ОсновныеСчета.СрокДействияСчета, Дистрибутивы.КодСистемы, Дистрибутивы.Код, Дистрибутивы.КоличествоМ, Дистрибутивы.Цена, Дистрибутивы.Сопровождение, Дистрибутивы.Скидки, Дистрибутивы.СкидкиС, Дистрибутивы.СпецвупыскИлиНет FROM ([Заказчики] INNER JOIN [ОсновныеСчета] ON Заказчики.КодЗаказчика = ОсновныеСчета.КодЗаказчика) INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета WHERE (((Заказчики.КодЗаказчика)=" & Me![КодЗаказчика] & "));"
Set rst = dbs.OpenRecordset(strSQL)
Set rstTMP = dbs.OpenRecordset("ИнфоПоСистемамЗаказчика")
Do Until rstTMP.EOF
rstTMP.Delete
rstTMP.MoveNext
Loop
If rst.RecordCount = 0 Then
MsgBox ("Нет счетов на данную организацию")
rstTMP.Close
rst.Close
dbs.Close
Me.Refresh
Exit Sub
End If
rst.MoveLast
j = rst.RecordCount
rst.MoveFirst
For i = 1 To j
rstTMP.AddNew
rstTMP![КодСистемы] = НазваниеСистемы(rst![КодСистемы])
rstTMP![ПоСчету] = rst![НомерСчета]
If rst![Код] = 1 Then
rstTMP![Тип] = "Локальная"
Else
rstTMP![Тип] = "Сетевая"
End If
rstTMP![ДатаС] = CurrentDateWParam(rst![ДатаСчета])
rstTMP![Цена] = rst![Цена]
rstTMP![Сопр] = rst![Сопровождение]
rstTMP![Скид] = rst![Скидки]
rstTMP![СкидС] = rst![СкидкиС]
rstTMP![ДейстПо] = rst![СрокДействияСчета]
rstTMP![Спец] = rst![СпецвупыскИлиНет]
rstTMP![Кво] = rst![КоличествоМ]
rstTMP![Оплата] = rst![ОплатаСчета]
rst.MoveNext
rstTMP.Update
Next i
Me![ИнфоПоОрганСистемы].Form.Visible = -1
Me![ИнфоПоОрганизSub].Form.Visible = 0
rstTMP.Close
rst.Close
dbs.Close
Me.Refresh
End Sub
Private Sub Сист_Click()
On Error GoTo Err_Кнопка6_Click
Dim rst, rstTMP, rstTMP2 As Recordset
Dim rstTMP3 As Recordset
Dim rstTMP4 As Recordset
Dim rstTMP5 As Recordset
Dim dbs As Database
Dim i, j As Integer
Dim strSQL, strSQLTMP, strSQLTMP3 As String
Dim strSQLTMP2 As String
Dim Дата As Date
DoCmd.Hourglass True
Set dbs = CurrentDb
strSQL = "SELECT DISTINCTROW ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСистемы FROM [ДанныеДляАвансОтчета] WHERE (((ДанныеДляАвансОтчета.КодЗаказчика)=" & Me![КодЗаказчика] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0));"
Set rst = dbs.OpenRecordset(strSQL)
Set rstTMP4 = dbs.OpenRecordset("ИнфоПоСистемамЗаказчика")
Do Until rstTMP4.EOF
rstTMP4.Delete
rstTMP4.MoveNext
Loop
If rst.RecordCount = 0 Then
' MsgBox ("Не сопровождается")
rst.Close
Me![ИнфоПоОрганизSub].Form.Visible = -1
Me![ИнфоПоОрганСистемы].Form.Visible = 0
'инфо по 1996 году
strSQLTMP2 = "SELECT DISTINCTROW АвансПоОстаткамС1996Года.Заказчик, АвансПоОстаткамС1996Года.Месяц, АвансПоОстаткамС1996Года.Сумма FROM АвансПоОстаткамС1996Года WHERE (((АвансПоОстаткамС1996Года.Заказчик)=" & Me![КодЗаказчика] & "));"
Set rstTMP5 = dbs.OpenRecordset(strSQLTMP2)
rstTMP4.AddNew
rstTMP5.MoveFirst
rstTMP4![Дата1С1996] = CurrentMWParam(rstTMP5![Месяц])
rstTMP5.MoveLast
rstTMP4![Дата2С1996] = rstTMP5![Месяц]
rstTMP5.Close
rstTMP4.Update
Me.Refresh
rstTMP4.Close
dbs.Close
DoCmd.Hourglass False
Exit Sub
End If
rst.MoveLast
j = rst.RecordCount
rst.MoveFirst
For i = 1 To j
rstTMP4.AddNew
rstTMP4![КодСистемы] = НазваниеСистемы(rst![КодСистемы])
strSQLTMP = "SELECT DISTINCTROW Заказчики.Организация, ДанныеДляАвансОтчета.КодСистемы, АвансовыйОтчет.Месяц, ДанныеДляАвансОтчета.КоличествоМС, Заказчики.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ОсновныеСчета.НомерСчета AS НС, АвансовыйОтчет.ИдентКод, Дистрибутивы.СкидкиС, ОсновныеСчета.ДатаСчета"
strSQLTMP = strSQLTMP & " FROM (([ОсновныеСчета] INNER JOIN ([Заказчики] INNER JOIN [ДанныеДляАвансОтчета] ON (Заказчики.КодЗаказчика = ДанныеДляАвансОтчета.КодЗаказчика) AND (Заказчики.КодЗаказчика = ДанныеДляАвансОтчета.КодЗаказчика)) ON (Заказчики.КодЗаказчика = ОсновныеСчета.КодЗаказчика) AND (ОсновныеСчета.КодСчета = ДанныеДляАвансОтчета.КодСчета)) INNER JOIN [АвансовыйОтчет] ON ДанныеДляАвансОтчета.Код = АвансовыйОтчет.ИдентКод) INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета"
strSQLTMP = strSQLTMP & " GROUP BY Заказчики.Организация, ДанныеДляАвансОтчета.КодСистемы, АвансовыйОтчет.Месяц, ДанныеДляАвансОтчета.КоличествоМС, Заказчики.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ОсновныеСчета.НомерСчета, АвансовыйОтчет.ИдентКод, Дистрибутивы.СкидкиС, ОсновныеСчета.ДатаСчета"
strSQLTMP = strSQLTMP & " HAVING (((ДанныеДляАвансОтчета.КодСистемы)=" & rst![КодСистемы] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0) AND ((Заказчики.КодЗаказчика)=" & Me![КодЗаказчика] & "));"
Set rstTMP2 = dbs.OpenRecordset(strSQLTMP)
Дата = Format(rstTMP2![Месяц], "m yy")
rstTMP4![ДатаС] = Дата
rstTMP2.MoveLast
Дата = Format(rstTMP2![Месяц], "m yy")
rstTMP4![ДейстПо] = Дата
rstTMP4![ПоСчету] = rstTMP2![НС]
rstTMP4![ДатаСчСопр] = CurrentDateWParam(rstTMP2![ДатаСчета])
rstTMP4![СкидС] = rstTMP2![СкидкиС]
'Запрос по системам
strSQLTMP = "SELECT DISTINCTROW Заказчики.КодЗаказчика, Заказчики.Организация, ОсновныеСчета.НомерСчета, ОсновныеСчета.ДатаСчета, ОсновныеСчета.ДатаУстановки, Дистрибутивы.КодСистемы, Дистрибутивы.Код, Дистрибутивы.СпецвупыскИлиНет, Дистрибутивы.Скидки, Дистрибутивы.Цена, Дистрибутивы.НомерДистрибутива"
strSQLTMP = strSQLTMP & " FROM ([Заказчики] INNER JOIN [ОсновныеСчета] ON Заказчики.КодЗаказчика = ОсновныеСчета.КодЗаказчика) INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета"
strSQLTMP = strSQLTMP & " WHERE (((Заказчики.КодЗаказчика)=" & Me![КодЗаказчика] & ") AND ((Дистрибутивы.КодСистемы)=" & rst![КодСистемы] & ") AND ((Дистрибутивы.Цена)<>0));"
Set rstTMP3 = dbs.OpenRecordset(strSQLTMP)
rstTMP4![ПоСчетуПок] = rstTMP3![НомерСчета]
rstTMP4![ДатСчПок] = CurrentDateWParam(rstTMP3![ДатаСчета])
rstTMP4![Рег] = rstTMP3![НомерДистрибутива]
rstTMP4![Скид] = rstTMP3![Скидки]
rstTMP4![Спец] = rstTMP3![СпецвупыскИлиНет]
If rstTMP3![Код] = 1 Then
rstTMP4![Тип] = "Локальная"
Else
rstTMP4![Тип] = "Сетевая"
End If
labelnext:
strSQLTMP2 = "SELECT DISTINCTROW АвансПоОстаткамС1996Года.Заказчик, АвансПоОстаткамС1996Года.Месяц, АвансПоОстаткамС1996Года.Сумма FROM АвансПоОстаткамС1996Года WHERE (((АвансПоОстаткамС1996Года.Заказчик)=" & Me![КодЗаказчика] & "));"
Set rstTMP5 = dbs.OpenRecordset(strSQLTMP2)
If rstTMP5.RecordCount > 0 Then
rstTMP5.MoveFirst
rstTMP4![Дата1С1996] = CurrentMWParam(rstTMP5![Месяц])
rstTMP5.MoveLast
rstTMP4![Дата2С1996] = CurrentMWParam(rstTMP5![Месяц])
rstTMP5.Close
rstTMP4.Update
rst.MoveNext
rstTMP2.Close
rstTMP3.Close
Else
rstTMP5.Close
rstTMP2.Close
rstTMP3.Close
End If
Next i
rstTMP4.Close
rst.Close
dbs.Close
Me.Refresh
Exit_Кнопка6_Click:
Me.Refresh
Me![ИнфоПоОрганизSub].Form.Visible = -1
Me![ИнфоПоОрганСистемы].Form.Visible = 0
DoCmd.Hourglass False
Exit Sub
Err_Кнопка6_Click:
If Err.Number = 3021 Then
'MsgBox ("Нет данных по этой организации")
Resume labelnext:
'Resume Exit_Кнопка6_Click
'MsgBox Err.Description
End If
MsgBox ("Нет данных по этой организации")
Me![ИнфоПоОрганизSub].Form.Visible = 0
Me![ИнфоПоОрганСистемы].Form.Visible = 0
MsgBox Err.Number
Resume Exit_Кнопка6_Click
DoCmd.Hourglass False
End Sub
Задание по организационно – экономической части к дипломному проекту.
Тема: «Технико-экономическое обоснование проекта. Расчет сметы затрат и цены на ПП. Оценка конкурентоспособности разработки»
1. Календарный график.
В силу того, что данная разработка относится к НИР, которая не является комплексом работ высокой сложности и в ее выполнении не участвуют большое количество исполнителей, в данном случае для реализации работ выбран календарный график.
|
N п/п |
Наименование работ |
Исполнители |
Длительность работы |
||||
|
Сент. |
окт. |
ноябрь |
Декабрь |
Январь |
|||
|
1 |
Разработка технического задания |
Начальник отдела, менеджер |
20 |
||||
|
2 |
Подбор литературы |
Системный программист, программист |
15 |
||||
|
3 |
Рабочее проектирование |
Системный программист, программист |
25 |
||||
|
4 |
Отладка и тестирование |
Системный программист, программист |
55 |
||||
|
5 |
Обобщение и оценка результатов |
Системный программист, программист, менеджер |
30 |
||||
|
6 |
Сдача темы |
Начальник отдела, менеджер |
5 |
||||
2. Расчет сметы.
При составлении сметы затрат на НИР учитываются:
- стоимость материалов, покупных полуфабрикатов и изделий,
- основная заработная плата,
- дополнительная заработная плата,
- отчисления на социальные нужды,
- накладные расходы,
- затраты на машинное время.
2.1. Определения затрат на материалы, покупные изделия и полуфабрикаты.
|
Наименование |
Единица измерения |
Количество |
Цена за единицу, руб. |
Стоимость |
|
1. Литература |
Шт. |
6 |
60.000 |
360.000 |
|
2. НЖМД (дискеты) |
Пачка. |
4 |
40.000 |
160.000 |
|
3. Канцтовары |
Шт. |
50.000 |
||
|
4. Бумага(А4) |
Пачка |
3 |
5.000 |
15.000 |
|
Итого: |
585.000 |
Транспортные расходы учитываются здесь же и состовляют 5% итоговой суммы, т.е. 29.250 р.
Затраты на материалы и покупные изделия равны:
Зм = 585.000 + 29.250 = 614.250 руб.
2.2. Основная заработная плата.
К этой статье относится заработная плата научных сотрудников, программистов, лаборантов, рабочих , непосредственно связанных с выполнением НИР, а также зарплата сотрудников внештатного состава, привлекаемых к разработке и выполнению НИР
|
Должность |
Заработная плата в месяц, руб. |
Стоимость одного рабочего дня, руб. |
|
Начальник отдела |
2.300.000 |
115.000 |
|
Системный программист |
1.200.000 |
60.000 |
|
Программист |
1.000.000 |
50.000 |
|
Менеджер |
1.900.000 |
95.000 |
Таблица расчета основной заработной платы.
|
N п/п |
Наименование этапа НИР |
Исполнитель |
Трудоем-кость |
Зарплата за 1 день, руб. |
Сумма, руб. |
|
|
1 |
Разработка технического задания |
Начальник отдела, менеджер |
20 |
115.000 95.000 |
2,300,000 1,900,000 |
|
|
2 |
Подбор литературы |
Системный программист, программист |
15 |
60.000 50.000 |
900,000 750,000 |
|
|
3 |
Рабочее проектирование |
Системный программист, программист |
25 |
60.000 50.000 |
1,500,000 1,250,000 |
|
|
4 |
Отладка и тестирование |
Системный программист, программист |
55 |
60.000 50.000 |
3,300,000 2,750,000 |
|
|
5 |
Обобщенеи и оценка результатов |
Системный программист, программист, менеджер |
30 |
60.000 50.000 |
1,800,000 1,500,000 |
|
|
6 |
Сдача темы |
Начальник отдела, менеджер |
5 |
115.000 95.000 |
575,000 475,000 |
|
|
7 |
Итого |
19,000,000 |
||||
2.3. Дополнительная заработная плата.
На эту статью относятся выплаты, предусмотренные законодательством за неотработанное рабочее время. Размер дополнительной заработной платы сотрудников, непосредственно
выполняющий НИР, определяется в процентах от основной. В научных учереждениях она составляет 10-12% от основной заработной платы.
Здоп = Зосн * 0,12 = 2,280,000 руб.
2.4. Отчисления на социальные нужды.
На эту статью относятся отчисления на оплату перерывов в работе по временной нетрудоспособности. Отчисления на социальные нужды составляют 40% от величины основной заработной платы.
В отчисления на социальные нужды входят:
- отчисления на медицинское страхование:
- в городской бюджет – 0,2%
- в федеральный бюджет – 3,4%
- отчисления в фонд занятости – 1,5%;
- отчисления в пенсионный фонд - 29%;
- отчисления на социальное страхование – 5,4%;
- транспортный налог - 1%;
- отчисления на в фонд образования – 1%;
Зсн = Зосн * 0.415 = 7,600,000 руб.
2.5. Накладные расходы.
Накладные расходы в учреждении, где выполняется данная НИР составляют 120% от суммы основной и дополнительной заработной платы.
Зн = (Зосн + Здоп) * 1.2 = 25,536,000 руб.
2.6. Стоимость машинного времени.
Для отладки программы, численных расчетов и построения графиков необходимо 50 дней. В среднем программист работает 6 часов в день, себестоимость одного часа машинного времени около 3000 руб.
Змаш = 3000 * 6 * 50 = 900,000 руб.
Итоговая таблица сметы затрат.
|
N п/п |
Наименование статьи расходов |
Сумма, руб. |
|
1 |
Стоимость материалов, покупных полуфабрикатов и изделий. |
614,250 |
|
2 |
Основная заработная плата. |
19,000,000 |
|
3 |
Дополнительная заработная плата. |
2,280,000 |
|
4 |
Отчисления на социальные нужды. |
7,600,000 |
|
5 |
Накладные расходы. |
25,536,000 |
|
6 |
Стоимость машинного времени. |
900,000 |
|
Итого |
55,930,250 |
2.7. Цена программного продукта.
Цена, определяется себестоимостью и прибылью, которая в свою очередь составляет 30% от ФОТ.
Ц = 55.930.250 + 0,3 * 21,280,000 = 62,314,250 руб.
3. Оценка экономической эффективности.
Данная НИР относится к базам данных в области бухгалтерского учета. Поэтому количественную оценку эффективности целесообразно производить путем оценки конкурентоспособности данного программного продукта. Для этого возьмем подобную программу и определим параметры обоих товаров путем сравнения. Рассчитаем и оценим коэффициент конкурентоспособности.
|
Частота регистраций |
|||||
|
Обьем памяти |
Быстродействие |
Аппаратная независимость |
Дизайн |
Сервис |
|
|
Нащ программный продукт |
0,81 |
0,93 |
0,85 |
0,87 |
0,89 |
|
Конкутентный программный продукт |
0,62 |
0,84 |
0,86 |
0,78 |
0,81 |
Представляемый программный продукт превосходит по конкурентоспособности предоставленный образец и, следовательно, можно сделать вывод, что он будут представлять достаточно большой интерес в своей области, связанной с проектированием баз данных.
Задание по охране труда и техника безопасности.
Тема: «Разработать мероприятия по охране труда на рабочем месте пользователя.»
1. Введение.
Охрана труда - система законодательных актов, постановлений, организационных, санитарных, технических мер, обеспечивающих безопасные для здоровья условия труда на рабочем месте. Научно-технический прогресс внес изменения в условия производственной деятельности работников умственного труда. Их труд стал более интенсивным, напряженным, требующим затрат умственной, эмоциональной и физической энергии.
Это имеет прямое отношение и к специалистам, связанным с проектированием, разработкой, эксплуатацией, сопровождением и модернизацией автоматизированных систем управления различного назначения.
На рабочем месте пользователя должны быть созданы условия для высокопроизводительного труда. В настоящее время все большее применение находят автоматизированные рабочие места ИТР, которые оснащаются персональной ЭВМ и графическим дисплеем, клавиатурой и принте
ром.
2. Анализ условий труда пользователя.
Помещение, в котором находится рабочее место пользователя, имеет следующие характеристики:
- длина помещения: 9 м;
- ширина помещения: 7 м;
- высота помещения: 3.5 м;
- число окон: 3;
- число рабочих мест: 6;
- освещение: искусственное;
- число вычислительной техники: 5.
На рабочем месте пользователь подвергается воздействию следующих факторов, которые могут привести к неблагоприятным последствиям:
- недостаточное освещение;
- шум от работающих машин;
- облучение от экрана дисплея;
- выделение избытков теплоты.
Кроме того, в помещение могут попадать частички пыли.
3. Постановка задачи.
На основе анализа условий труда пользователя разрабатываются различные средства защиты от факторов, влияющих на пользователя в процессе работы, такие как: ограничение длительности работ, вентиляция, искусственное освещение, звукоизоляция. Имеются нормативы, определяющие комфортные условия и предельно допустимые нормы запыленности, температуры воздуха, шума, освещенности. В данной дипломной работе, согласно заданию, рассчитаем освещение и выберем систему вентиляции.
4. Расчет вентиляции.
4.1. Анализ микроклимата.
Необходимым условием жизнедеятельности человека является поддержка постоянства температуры тела, благодаря свойству терморегуляции, т.е. свойству организма регулировать отдачу тепла в окружающую среду. Поэтому большое значение имеет микроклимат в помещении, где работает инженер-программист. Метеорологические условия на производстве определяются следующими параметрами:
1) температурой воздуха t( C);
2) относительной влажностью (%);
3) скоростью движения воздуха на рабочем месте,V(м/с).
Основной принцип нормирования микроклимата - создание оптимальных условий для теплообмена тела человека с окружающей средой. Выделяемая организмом человека теплота должна отводиться в окружающую среду. Соответствие между количеством этой теплоты и охлаждающей способностью среды характеризует ее как комфортную. В условиях комфорта у человека не возникает беспокоящих его температурных ощущений холода или перегрева. В "Общих санитарно-гигиенических требованиях к воздуху рабочей зоны" (ГОСТ 12.1.005-88) установлены оптимальные и допустимые параметры микроклимата в зависимости от времени года, категории работ и рабочих мест (постоянных и непостоянных). Параметры микроклимата приведены табл. 1.
Таблица 1. Параметры микроклимата.
|
Период года |
Категория работ |
Зона |
Тмпера-тура, °C |
Относит. влажность, % |
Скорость движения, м/с |
|
холдн. |
Легкая |
оптим. |
22-24 |
40-60 |
0.1 |
|
доп. |
25-18 |
75 |
<0.1 |
||
|
теплый |
Легкая |
оптим. |
23-25 |
40-60 |
0.1 |
|
доп. |
28-22 |
55 |
0.1-0.2 |
В настоящее время для обеспечения комфортных условий используются как организационные методы, так и технические средства, среди которых вентиляция воздуха.
4.2. Определение потребного воздухообмена.
Влага выделяется в результате испарения со свободной поверхности воды и влажных поверхностей материалов и кожи, в результате дыхания людей и т.д. Количество влаги, выделяемое людьми, г/ч, определяется по формуле:
W=n*w (1.)
где n - число людей, n = 6 человек;
w - количество влаги, выделяемое одним человеком, г/ч,
w = 84 г/ч при t = 22С [1].
По формуле (1.) получаем:
W = 6 * 84 = 504 (г/ч)
Теперь можно определить потребный воздухообмен, который определяется по формуле:
(2.)
где W - количество водяного пара, выделяющегося в помещении, г/ч, W = 504 г/ч;
D, d - влагосодержание вытяжного и приточного воздуха, г/кг, определяется по температуре и относительной влажности воздуха;
p - плотность приточного воздуха, р = 1.2 кг/ м;
d = 10 г/кг при температуре рабочей зоны 22 С;
D = 16 г/кг -принимается равным предельно допустимому, т.е. при tр.з.=26 С , =75 %. Таким образом расход воздуха (по формуле (2.)) равен :
Теперь проведем расчет выделений тепла.
Тепловыделения от людей зависят от тяжести работы, температуры и скорости движения окружающего воздуха. Считается, что женщина выделяет 85% тепловыделений взрослого мужчины. В расчетах используется явное тепло, т. е. тепло воздействующее на изменение температуры воздуха в помещении. Тепловыделения от людей :
Qл = n * q , (3.)
где n - количество людей в помещении, 5 мужчин и 1 женщина;
q - удельная теплота , выделяемая человеком (явное тепло при t = 22 С ), Вт ; q = 68 Вт [1];
По формуле (3.) получаем:
Qл = 5 * 68 + 1 * 0.85 * 68 = 397.80 Вт.
Расчет тепла, поступающего в помещение от солнечной радиации Qост производится по формуле:
Qост = Fост * qост * Aост , (4.)
где Fост - площадь поверхности остекления,м ,
Fост= 9 м ;
qост - тепловыделения от солнечной радиации, Вт/м, через 1 м поверхности остекления (с учетом ориентации по сторонам света), qост = 150 Вт/м [4], т.е окна с двойным остеклением с металлическими переплетами;
Aост - коэффициент учета характера остекления, Aост=1.15 (двойное остекление в одной раме).
Подставив все полученные значения в формулу (4.), получим:
Qост = 9 * 150 * 1.15 = 1552,5 Вт.
Расчет тепловыделений от источников искусственного освещения Qосв, Вт, производится по формуле:
Qосв = N * * 1000 , (5.)
где N - суммарная мощность источников освещения, кВт,
N= 2 * 6 * 0.08 = 0.960 кВт где 0.08 кВт - мощность одной лампы, а всего в помещении 6 светильников по 2 лампы в каждом;
- коэффициент тепловых потерь, = 0.55 для люминес-
центных ламп.
По формуле (5.) имеем:
Qосв = 0.96 * 0.55 * 1000 = 528 Вт.
Для расчета тепловыделений от устройств вычислительной техники используется формула (5.) с коэффициентом тепловых потерь равном = 0.5. В помещении стоят 5 компьютеров типа IBM PC AT с мощностью 63.5 Вт источника питания.Тогда :
Qвт = 5 * 0.0635 * 0.5 * 1000 = 158.75 Вт.
Таким образом, в помещении выделяется всего избыточного тепла:
Qизб = Qл + Qост + Qосв + Qвт = 2637.05 Вт.
При открытии дверей и окон естественный расход тепла:
Qрасх = 0.1 * Qизб = 263.705 (Вт). (6.)
По формуле (7.) посчитаем объем вентилируемого воздуха для теплого времени года:
(7.)
где Qизб - теплоизбытки, Qизб = 2637.05 Вт;
Ср - массовая удельная теплоемкость воздуха,
Ср = 1000 Дж/(кг* С);
р - плотность приточного воздуха, р = 1.2 кг/м ;
tуд, tпр - температуры удаляемого и приточного воздуха, С;
Температура удаляемого воздуха определяется по формуле:
tуд = tрз + а * (Н - 2),
где tрз = 22 С;
а - нарастание температуры воздуха на каждый 1 м высоты, С/м, а =0.5 С/м;
Н - высота помещения, Н = 3.5 м.
Следовательно, tуд = 22 + 0.5 * (3.5 - 2) = 23 С.
Температура приточного воздуха tпр при наличии избытков тепла должна быть на 5 С ниже температуры воздуха в рабочей зоне, поэтому tпр = 17 С. Подставив полученные значения в формулу (7.) найдем:
При одновременном выделении тепла и влаги сравниваются соответствующие воздухообмены, потребные для их удаления, и выбирается наибольший. Поскольку Gт= 1318 м /ч,а G = 70 м /ч,то систему вентиляции будем проектировать для воздухообмена Gвент = 1318.5 м /ч.
5. Проектирование системы вентиляции.
Исходными данными для расчета размера воздуховода являются расход воздуха (Gвент = 1318.5 м /ч) и допустимые скорости его движения в помещении (v = 9 м/с). Потребная площадь воздуховода f, м определяется по формуле:
(8.)
Для дальнейших расчетов (при определении сопротивления сети, подборе вентилятора и электродвигателя) площадь воздуховода принимается равной ближайшей большей стандартной величине, т. е. f = 0.0614 м [1]. В промышленных зданиях рекомендуется использовать круглые металлические воздуховоды. Тогда расчет сечения воздуховода заключается в определении диаметра трубы. По справочнику находим, что для площади f = 0.0614 м условный диаметр воздуховода d = 280 мм [1].
Определим потери давления в вентиляционной сети. При расчете сети необходимо учесть потери давления в вентиляционном оборудовании. Естественным давлением в системах механической вентиляции пренебрегают. Для обеспечения запаса вентилятор должен создавать в воздуховодах избыточное давление, превышающее не менее чем на 10% расчетное давление. Для расчета сопротивления участка сети используется формула:
где R - удельные потери давления на трение на участке сети, R =3.2 Па/м;
l - длина участка воздуховода, м, l = 3 м;
- сумма коэффициентов местных потерь на участке воздуховода, 1.1 - для колена, 1.4 - для прямого участка; v - скорость воздуха на участке воздуховода, 9 м/с;
р - плотность воздуха( принимаем р = 1.2 кг/м ).
Значения R,v, определяются по справочнику (R - по значению диаметра воздуховода на участке d = 280 мм, в зависимости от типа местного сопротивления)[1]. Результаты расчета воздуховода и сопротивления сети приведены в табл. 2.
Таблица 2. Расчет воздуховода и сопротивления сети.
|
G, (м/ч) |
l, (м) |
v, (м/с) |
d, (мм) |
v*p/2 Па |
R, Па/м |
R*I, Па |
Па |
P, Па |
|
|
1318 |
3 |
9 |
280 |
48.60 |
3.2 |
9.6 |
2.5 |
121.5 |
131.1 |
Требуемое давление, создаваемое вентилятором, с учетом запаса на непредвиденное сопротивление в сети в размере 10 % составит:
Ртр = 1.1 * Рmax = 1.1 * 131.1 = 144.21 (Па) (10.)
В вентиляционных установках применяют вентиляторы низкого давления (до 1 кПа) и среднего давления (от 1 до 3 кПа). В сетях с малым сопротивлением до 200 Па применяют осевые вентиляторы. Вентиляторы подбирают по аэродинамическим характеристикам, т.е. зависимостям между полным давлением (Ртр, Па), создаваемым вентилятором, и произволительностью (Gтр, м /ч).
С учетом возможных дополнительных потерь или подсоса воздуха в воздуховодах потребная производительность вентилятора увеличивается на 10 %, поэтому:
Gтр = 1.1 * Gвент = 1.1 * 1318.3 = 1450.35 (м /ч)(11)
По справочным данным [2] определяем необходимый вентилятор и электродвигатель: вентилятор О6-300 (N4), КПД вентилятора h = 0.65.
Мощность электродвигателя (N, кВт) рассчитывается по формуле:
(12.)
где h - КПД вентилятора и ременной передачи.
Выберем по рассчитанному значению мощности электродвигатель 4АА63В4У2 с мощностью 0.37 кВт.
Задание по гражданской обороне.
Тема: «Оценка устойчивости дисплейного зала к воздействию ионизирующего излучения.»
1. Введение.
Гражданская оборона (ГО) представляет собой общегосударственную систему мероприятий, осуществляющую защиту населения и народного хозяйства государства в чрезвычайных ситуациях мирного и военного времени, обеспечивающих повышение устойчивости работы отраслей экономики, проведение АСИДНР при ликвидации последствий стихийных бедствий, аварий и катастроф.
Руководство осуществляется МЧС. Рабочим органом управления комитета является штаб войск ГО и 9 региональных центров, которые находятся в Москве, Санкт-Петербурге, Ростове на Дону, Самаре, Екатеринбурге, Новороссийске, Красноярске, Чите и Хабаровске.
В целом ГО строится по территориально-производственному принципу, т.е. органы управления ГО создаются исполнительными властями по территориям (края, области) и по линии безопасности управления (министерства, ведомства).
ГО России предназначено для решения трех групп задач:
- защита населения в чрезвычайных ситуациях мирного и военного времени;
- повышение устойчивости работы отраслей экономики в чрезвычайных ситуациях;
- организация и проведение АСИДНР при ликвидации последствий чрезвычайных ситуаций.
ГО Москвы имеет, кроме того, следующие задачи:
- организация первоочередного жизнеобеспечения пострадавшего населения;
- проведение профилактических мероприятий для уменьшения риска возникновения промышленных аварий и катастроф;
- всеобщее обязательное обучение населения основам ГО;
- создания и подготовка органов управления (систем связи, оповещения, пунктов управления и т.п.).
На ГО возлагается:
- осуществление мероприятий по защите рабочих и служащих в чрезвычайных ситуациях;
- проведение мероприятий, повышающих устойчивость работы объектов в чрезвычайных ситуациях;
- обеспечение непрерывного управлениями службами и формированиями ГО;
- создание, оснащение, подготовка сил ГО объектов и поддержание их в постоянной готовности;
- всеобщее обязательное обучение рабочих и служащих мерам защиты при чрезвычайных ситуациях;
- обеспечение защиты продовольствия и источников водоснабжения от радиоактивного, химического и бактериологического заражения;
- проведение аварийно - спасательных и других неотложных работ в очагах поражения.
К учреждениям ГО относятся:
- медицинские учреждения (больницы, поликлиники, здравпункты, диспансеры, санатории и т.п.);
- ветеринарные лаборатории и учреждения;
- химические лаборатории;
- комплексные пункты опорной сети наблюдения и лабораторного контроля, включая сеть экологического мониторинга;
Для организации и проведения мероприятий по защите объектов и ликвидации последствий применения противником оружия массового поражения необходимы знания поражающего действия ядерного оружия.
Поражающее действие ядерного взрыва определяется механическим воздействием ударной волны, тепловым воздействием светового излучения, радиационным воздействием поникающей радиации и радиоактивного заражения, а также электромагнитным излучением (электромагнитным импульсом). Первичные действия поражающих факторов могут привести к возникновению пожаров, взрывов. При этом образуются вторичные очаги поражения.
Распределение энергии между поражающими факторами ядерного взрыва зависит от вида взрыва и условий, в которых он происходит. При взрыве в атмосфере примерно 50% энергии взрыва расходуется на образование ударной волны, 30 - 40% - на световое излучение, до 5% - на проникающую радиацию и электромагнитный импульс и до 15% - на радиоактивное заражение.
Действие поражающих факторов ядерного взрыва на людей и объекты происходит не одновременно и различается по длительности воздействия, характеру и масштабам поражения.
2. Постановка задачи.
Задача данного этапа дипломного проектирования - оценка устойчивости дисплейного зала к воздействию ионизирующего излучения. Зададимся исходными данными для задачи.
Описание дисплейного класса:
- дисплейный класс находится на втором этаже здания института;
- дисплейный класс рассчитан на 20 ЭВМ типа Intel Pentium-100 с мониторами типа Samsung 15GA;
- дисплейный класс дополнительно имеет внутреннее покрытие из дерева рассчитанное на погашение внешних наводок и наводок от электросети.
Для проверки устойчивости дисплейного зала к воздействию ионизирующего излучения зададимся параметрами ядерного взрыва:
- мощность взрыва равна 1000 Кт;
- диапазон оцениваемых расстояний от 500 до 3500 м.
2.1. Оценка поражающих факторов проникающей радиации.
При оценке воздействия поражающих факторов ядерного взрыва на дисплейный класс достаточно оценить степень воздействия на один характерный элемент дисплейного класса (ЭВМ), и затем применить полученные выводы на дисплейный класс в общем.
Проникающая радиация ядерного взрыва при воздействии на ЭВМ способна значительно ухудшить ее работоспособность или вывести ЭВМ из строя.
Радиация ядерного взрыва представляет собой гамма-излучение и поток нейтронов, испускаемых в окружающую среду из зоны ядерного взрыва.
Время действия проникающей радиации не превышает 10-15 секунд с момента взрыва. Основными параметрами, характеризующими проникающую радиацию, является доза и мощность излучения, потоки плотность потока частиц. Ионизирующая способность гамма-излучения характеризуется экспозиционной дозой излучения.
Распространяясь в среде, гамма-излучение и поток нейтронов ионизируют ее атомы и изменяют физическую структуру вещества. Проникающая радиация может вызвать обратимые и необратимые изменения в материалах, элементах электротехнической, оптической, и другой аппаратуры, входящей в состав ЭВМ.
Необратимые изменения вызываются нарушениями структуры кристаллической решетки вещества вследствие возникновения дефектов. В результате радиационного захвата нейтронов возможно образование примесей радиоактивных веществ. В процессе распада, образовавшихся радиоактивных ядер происходит радиационное излучение, которое может оказывать воздействие на электрические параметры элементов и схем ЭВМ, а также затруднять ремонт и эксплуатацию аппаратуры. Наиболее опасными по вторичному излучению являются изделия, изготовленные из материалов, содержащих марганец, кадмий, индий. Таким образом, необратимые изменения в компонентах ЭВМ приведут к ее отказу, и для восстановления ее работоспособности потребуется ремонт.
Обратимые изменения являются следствием ионизации материала и окружающей среды. Они проявляются в увеличении числа носителей тока, что приводит к возрастанию токов утечки, снижению сопротивления изоляции, полупроводников, поводящих материалов, а на макро уровне - к сбоям в работе ЭВМ.
Обратимые изменения в материалах, элементах и аппаратуре в целом могут возникать при мощности экспозиционных доз от 1000 Р/с.
Гамма-излучение делится на захватное, осколочное и мгновенное. Мгновенное гамма-излучение образуется в момент деления ядер урана или плутония в течении десятых долей микросекунды. Мгновенное гамма-излучение является главным источником высокой мощности экспозиционной дозы гамма-излучения, однако, его роль в накоплении общей экспозиционной дозы очень мала.
При ядерном взрыве воздействие нейтронного импульса на объект происходит несколько позднее импульсного гамма-излучения, причем задержка во времени, как и длительность самого импульса, зависит от расстояния до центра взрыва. Этот факт имеет существенное значение при проектировании аппаратуры, поскольку задачи исследования стойкости подразделяются на отдельные задачи исследования гамма-излучения и воздействия нейтронного излучения.
3.2. Расчет факторов проникающей радиации.
Мощность взрыва принимаем равную 1000 Кт.
1. Мощность поглощенной дозы, [P/c].
, где - мощность взрыва, Кт.
2. Поглощенная доза излучения, [р.].
3. Поток нейтронов, [1/м].
.
При расчетах также необходимо учитывать, что все ЭВМ в дисплейном классе, как правило, находится в здании института и, следовательно, степень воздействия всех факторов проникающей радиации снижается примерно на порядок.
Результаты расчетов для всех вышеперечисленных факторов проникающей радиации сведены в табл. 1.1.
Таблица 1.1.
|
Факторы |
Радиус, м |
||||||
|
500 |
1000 |
1500 |
2000 |
2500 |
3000 |
3500 |
|
|
P, P/с |
3.18 |
6.76 |
2.55 |
1.14 |
600 |
34 |
2 |
|
D, P |
2.06 |
9.84 |
8.53 |
930 |
120 |
17 |
3 |
|
н/м |
2.018 |
3.916 |
1.215 |
5.013 |
2.312 |
1.211 |
6.09 |
Учитывая, что наименее стойким элементом ЭВМ являются микросхемы, количество которых определяется типом ЭВМ и составляет 30 - 50 единиц, для которых предельные значения равны соответственно:
=10 н/м; D=1000 P; P=1000 P/с, получаем, что на расстоянии более 2500 метров от взрыва проникающая радиация ЯВ не повлияет на работоспособность ЭВМ. Необратимые изменения в микросхемах под воздействием проникающей радиации будут возникать, если ЭВМ будет находиться на расстоянии менее 1500 метров от центра взрыва.
4. Выводы.
В целом защита ЭВМ от воздействия проникающей радиации может быть в первую очередь достигнута за счет размещения в помещении, обеспечивающем снижение дозы проникающей радиации в 500 - 1000 раз, и использования экранов из тяжелых металлов и перекрытий из бетонных плит толщиной 1 - 1,5 м и более.
4.1. Предложения по обеспечению устойчивости дисплейного зала к воздействию ионизирующего излучения
Следовательно, надежность работы ЭВМ в условиях воздействия проникающей радиации ядерного взрыва будет повышена, если будут приняты следующие меры:
- наиболее важные узлы ЭВМ будут укрыты защитным слоем материала и перегородок, не пропускающего радиацию и тепло. Наиболее хорошо поглощают радиацию тяжелые материалы, например металлы (бетон, железные плиты и др.);
- конструкционные элементы ЭВМ будут изготовлены из такого типа материалов, которые наименее всего подверчены воздействию излучения и тепла. Т.к. изменить элементарную базу довольно сложно, то можно предложить создание схем, малокритичных к изменениям электрических параметров элементов, компенсирующих и отводящих дополнительные токи, выключающие отдельные блоки и элементы на период воздействия ионизирующего излучения;
- в электрических схемах увеличить расстояния между элементами, находящимися под электрической нагрузкой, снизить рабочее напряжение на них;
- элементы, являющиеся наиболее важными при функционировании, должны быть защищены с помощью различных заливок, не проводящих ток при облучении.
5. Список используемой литературы.
1. В.Г.Атаманюк, Л.Г.Ширшев, Н.И.Акимов “Гражданская оборона”, Москва, Высшая школа, 1986 г.
2. Л.Г.Ширшев “Ионизирующее излучение и электроника”, Москва, 1969 г.
3. Радиационная стойкость материалов радиотехнических конструкций, Справочник, Москва, 1976 г.
4. Методические указания к практическим работам по курсу “Гражданская оборона” под редакцией Л.Г.Ширшева, Москва, 1981г.
Задание по эргономике.
Тема: «Применение эргономики при проектировании, разработке и внедрения систем автоматизации деятельности предприятия».
1. Введение.
С развитием экономики возрастает объем взаимосвязанных данных, необходимых для решения коммерческих и административных задач. Взаимосвязанные данные называют информационной системой. Такая система в первую очередь призвана облегчить труд человека, но для этого она должна как можно лучше соответствовать очень сложной модели реального мира. Для воссоздания моделей бизнес-процессов предприятия служат информационные системы, называемые системами автоматизации предприятия.
Для разработки систем автоматизации на предприятии создается структурное подразделение – обычно это отдел автоматизации. До последнего времени в составе отдела автоматизации главенствующую роль играли технические специалисты – программисты, проектировщики, технические консультанты. Однако развитие компьютерного рынка, кункуренция и все большее усложнение самих систем автоматизации – породили необходимость в специалистах самых различных областей:
· художников-дизайнеров – для оформления интерфейса пользователей
· финансистов-консультантов – для более глубокого исследования бизнес-процессов предприятия
· менеджеров – для организации работы групп разработчиков систем автоматизации
· специалистов по эргономике – для исследования потребительских свойств разрабатываемой системы, а также для проектирования наиболее удобного интерфейса пользователя
· психологов – для анализа процесса внедрения системы автоматизации, а также для непосредственной помощи пользователям адаптироваться к новым условиях работы.
В данной работе мы рассмотрим требования, предъявляемые специалистами по эргономики при разработке систем автоматизации предприятий.
2. Влияние эргономики при проектировании реляционной базы данных.
Система автоматизации представляет собой прежде всего реляционную базу данных – хранилище данных предприятия. Первым этапом разработки проекта является проектирование реляционной базы данных. На данном этапе составляются бизнес-схемы процессов предприятия, анализируется аппаратное и программное обеспечение необходимое для разработки системы, проводится планирование разработки интерфейса пользователей. Разработчики систем автоматизации предприятия при работе на данном этапе должны учитывать следующие эргономические особенности:
Соответствие аппаратных и программных средств, применяемых для работы, нуждам сотрудников предприятия. От данного соответствия во многом будет зависеть эффективность системы управления.
Скорость отклика системы. Время ожидания пользователем при работе с системой должно быть минимальным. В ряде случаев при проектировании реляционных баз данных приходится отказаться от идеализированных моделей в пользу гибкости и скорости работы. Чаще всего ускорение работы системы связано с увеличением размера программы.
Достаточность данных. Реляционная база данных должна содержать все необходимые пользователю данные. В случае недостатка данных пользователь будет вынужден использовать вспомогательные средства для фиксации информации (например бумажные носители для записей или калькулятор для дополнительных вычислений). В ряде случаев недостаточность данных может привести к неправильному использованию системы или даже заставить пользователя отказаться от использования системы.
Масштабируемость системы. При проектировании реляционной базы данных необходимо предусмотреть модификацию и наращиваемость базы данных в процессе внедрения и эксплуатации системы. В большинстве случаев уже в период создания системы автоматизации бизнес процессы предприятия претерпевают изменения. Таким образом, разработчики должны быть готовы к пересмотру схемы базы данных во время написания системы автоматизации. Отсутствие механизмов масштабируемости приводит к быстрому устареванию системы.
Открытость системы. Большинство современных систем управления представляют собой открытые системы. Это означает способность расширения системы за счет подключения модулей сторонних разработчиков и дополнительного аппаратного и программного обеспечения. Например, возможно понадобиться использование контрольно-кассовых машин, счетчиков банкнот или детекторов скан-кода. В любом случае данные возможности помогут пользователю взаимодействовать с системой и значительно увеличат производительность его работы.
Необходимо отметить, что хотя на этапе проектирования вопросам эргономики уделяется меньшее значение, чем во время других этапов, разработчикам необходимо обратить внимание на перечисленные выше эргономические особенности. Следование данным советам поможет создать систему автоматизации, максимально приспособленную для работы в реальных условиях бизнес процессов предприятия.
3. Влияние эргономики при создании интерфейса пользователя.
Эргономика интерфейса пользователя является одним из наиболее важных аспектов системы автоматизации предприятия. Прежде, чем начинать разрабатывать интерфейс пользователя необходимо ознакомиться с действиями пользователя, проанализировать механизмы работы и при необходимости усовершенствовать их. От качества интерфейса и его эргономических характеристик будет зависеть в дальнейшем судьба системы автоматизации. Во многих случаях приходилось занова переписывать интерфейс пользователя из-за небрежного отношения разработчиков к нуждам конечного потребителя. Перечислим основные эргономические особенности интерфейса пользователя, используемые в современных программах:
Использование стандартных средств разработки и средств RAD (средства быстрой разработки программ). Большинство конечных пользователей не желают “изобретать велосипед”, поэтому при разработке пользовательского интерфейса необходимо ориентироваться на известные программные продукты, присутствующие на рынке. В этом случае пользователю будет легче разобраться в интерфейсе, и возможно он даже сможет самостоятельно усовершенствовать программу в соответствии со своими нуждами.
Использование графического интерфейса. При создании системы автоматизации необходимо ориентироваться на операционные системы с графическим интерфейсом пользователя (Windows, OS/2, OSMac и т.п.). Системы с текстовым вводом (например MS-DOS) являются устаревшими и не предназначены для разработки интерфейса пользователя.
Использование средств обучения и самообучения пользователя. Хорошая система автоматизации должна обладать не менее хорошей системой помощи. Использование контекстно-зависимой помощи, гипертекстовые ссылки, руководство пользователя, ярлыки-подсказки – все это является «правилами хорошего тона» при реализации интерфейса пользователя.
Использование средств «психологической разгрузки пользователя». На сегодняшний день компьютер является не только хорошим помощником, но и сильным стрессовым раздражителем. Поэтому при проектировании современного интерфейса необходимо использовать некоторые приемы «психологической разгрузки пользователя»:
Длительное ожидание выполнения каких-либо действий всегда должно сопровождается надписью (например «Идет выполнение операции. Подождите…»). Также необходимо использовать строки загрузки, которые позволяют наглядно представить какой объем информации уже обработан и какой объем еще предстоит обработать. Данные средства позволяют сгладить эффект «длительного ожидания» у пользователя.
При работе необходимо использовать строки повседневного общения. Это позволит снять напряжение от работы, а также развлечет пользователя. Например, при выходе из программы можно использовать сообщение вида «Действительно уходите? До свидания. Надеемся вы к нам еще загляните…».
Использование анимации и видео желательно, однако не следует слишком перегружать программу данными элементами. Данные элементы не только могут являться причиной более медленной работы программы, но и отвлекать (раздражать) пользователя.
Использование современных элементов управления. Такие элементы управления как «закладки», «деревья», «ползунки» и т.п. – помогут пользователю легко управлять даже самыми сложными данными.
Использование «индивидуального» интерфейса. Одно из основных преимуществ правильно созданной системы управления предприятием – наличие индивидуального интерфейса пользователя. Именно этим отличается она от широко распространненых программ автоматизации бухучета для малых предприятий. При создании интерфейса пользователя разработчикам необходимо учитывать особенности человека, работающего за конкретным рабочим местом и методы его работы. Иногда для двух разных людей, выполняющих одну и ту же работу приходится создавать два разных интерфейса пользователя. Такие высокие «накладные расходы» при разработке интерфейса с лихвой окупятся предприятию при использовании системы автоматизации.
4. Внедрение и его влияние на эргономические свойства проекта.
После окончания этапов проектирования и разработки наступает этап внедрения системы автоматизации предприятия. На данном этапе проводятся доработки пользовательского интерфейса и отладка системы. Как правило основные изменения, вносимые на данном этапе в программу касаются прежде всего эргономических свойств проекта. Этап внедрения подобен покупке новой обуви – должно пройти некоторое время для того, что бы «расходить» программу. Часто оказывается, что на этапе разработки интерфейса пользователь и разработчики неправильно поняли друг друга в результате чего на этапе внедрения приходится находить компромис. Важно понимать, что данный компромис должен устраивать пользователя и помогать ему в работе.
5. Заключение.
В любой организации, как большой, так и маленькой, возникает проблема такой организации управления данными, которая обеспечила бы наиболее эффективную работу. Небольшие организации используют для этого шкафы с папками, однако крупные корпоративные предприятия используют компьютеризированные системы автоматизации, позволяющие эффективно хранить, извлекать информацию и управлять большими объемами данных.
Темпы внедрения новых технологий в компьютерной отрасли вызывают изумление. Компании, конкурирующие за рынки и прибыли, стремятся моментально реализовать технические новшества в аппаратных средствах, программном обеспечении и парадигмах вычислений, стимулирующих развитие всей технологии управления информацией. Однако для успешной реализации крупных систем управления требуся применить нестандартный подход, творческое решение. Использование основ эргономики при проектировании, реализации и внедрении системы управления позволит решить многие «психологические» и «технологические» проблемы предприятий.
Список литературы.
1. Р.Ахаян и др. «Эффективная работа с СУБД», Санкт-Петербург, «Питер», 1997г.
2. «Проектирование и разработка систем автоматизации предприятий».
3. «Database Unleashed», Indianapolis USA, «SAMS Publishing», 1996г.
Содержание I. Специальная часть. XE "СПЕЦИАЛЬНАЯ ЧАСТЬ." Введение 3 Глава 1. Основная часть 1.1. Содержание и требования, предъявляемые к информации 3 1.2. Значение внутрифирменной систем
Разработка ПО "Правила Дорожного Движения"
Состав и функционирование ИС построенной по принципу "клиент-сервер" для численного обоснования решений
Сопряжение факсимильного аппарата с IBM PC
Автоматизированное рабочее место регистрации и документирования комплекса средств автоматизации
Человеко-машинный интерфейс, разработка эргономичного интерфейса
АРМ для бухгалтерии ВУЗа
Разработка системы управления работой коммерческой компании
Формирование структуры электронного учебника и решение задач на ней
Прогнозирование на основе аппарата нейронных сетей
Разработка и анализ перспектив развития предприятия
Copyright (c) 2024 Stud-Baza.ru Рефераты, контрольные, курсовые, дипломные работы.