5. Требования безопасности в аварийных ситуациях.

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

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

5.2. Если во время работы произошёл несчастный случай, необходимо немедленно оказать первую медицинскую помощь пострадавшему,

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

5.3. При поражении электрическим током необходимо как можно скорее освободить пострадавшего от действия тока Отключение оборудования произвести с помощью выключателей, разъёма штепсельного соединения, перерубить питающий провод инструментом с изолированными ручками. Если отключить оборудование достаточно быстро нельзя, необходимо принять другие меры к освобождению пострадавшего от действия тока. Для отделения пострадавшего от токоведущих частей или провода следует воспользоваться палкой, доской или каким-либо сухим предметом, не проводящим электроток, при этом оказывающий помощь должен встать на сухое, непроводящее ток место, или надеть диэлектрические перчатки.

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

5.5. При обнаружении постороннего напряжения на рабочем месте необходимо немедленно прекратить работу и доложить старшему смены.

6. Требования безопасности по окончании работы.

6.1. Необходимо привести в порядок рабочее место.

6.2. Сообщить сменщику (ст. смены) обо всех неисправностях, замеченных во время работы, и мерах, принятых к их устранению.

6.3. Спецодежду (халат и тапочки) нужно убрать в специально отведённое место.

1.3 Описание рабочего места

Технические характеристики рабочего места

Материнская плата: MB Albatron PX865 PE PRO <Socket 478

Процессор: CPU Celeron 2400 MHz BOX <400FSB, 128 Kb

Оперативная память: DDR 256 Mb (pc - 3000)

Винчестер: IDE : HDD 120.0 Gb Maxtor 6V 120 PO

Накопитель: FDD 1.44 Mb 3.5 “Samsung

Видеокарта: 128 Mb <AGP> ATI 9200 128 bit DDR TV-Out

Combo DVD-ROM + CD-RW : Combo DVD/CD-Rev Sony

Корпус: Midi Tower Proxima Vector Grey 350W (p-4) ATX(2

Монитор: 17 “LG Flatron T710PH

Клавиатура: Keyboard Win95 BTC 5197 PS/2

Мышь: Mouse (2 -but) Mitsumi Optical Wheel Mouse Ps/2

Сетевой фильтр: <Surge Protector> 1.8 m

Колонки: Codegen S3-004-B2

Тип операционной системы: Windows XP Professional

Пакеты прикладных программ: Microsoft Office, 1С: Предприятие, Total Commander Power Pack 7.00 , Windows Internet Explorer 7, Adobe Reader 8.1.1,

Microsoft Visual FoxPro 6.0

1.4 Проектирование баз данных. Общие принципы

Широко известные методы проектирования баз данных (БД) появились в процессе разработки все более сложных Информационных Систем (ИС), которые должны были рассматривать потребности не одного пользователя, но больших групп и коллективов. Одна такая интегрированная БД создавалась для решения многих задач, каждая из которых использовала только "свою" часть данных, обычно, пересекающуюся с частями, используемыми в других задачах. Поэтому главнейшими методами проектирования стали методы исключения избыточности в данных. Эти методы связывались с другими средствами обеспечения логической целостности данных.

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

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

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

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

• полная процедура нормализации высоких степеней и минимизации набора отношений не проводится или проводится редко, если же экспертиза проверки на соответствие даже 3НФ или БКНФ предусмотрена в CASE-средствах, эта возможность редко используется на практике ввиду ее громоздкости и высоких требований к квалификации проектировщика, использующего CASE;

• оптимизация размещения БД на устройствах внешней памяти проводится "на глазок", распространенные сегодня тесты временных параметров не приспособлены для помощи в решении этой задачи проектирования;

• так же "на глазок" производится оптимизация размещения БД по узлам распределенной БД.

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

Этому есть, на наш взгляд, несколько причин:

• высокие требования к квалификации проектировщиков в области теоретических основ классического проектирования БД;

• громоздкость методов, используемых в рамках "каскадной" схемы, в условиях практической невозможности обеспечить устойчивость больших интегрированных решений в мире с постоянно меняющимися требованиями к ИС;

• относительная легкость выполнения реорганизации логической и физической структуры БД в реляционных СУБД (однако, и это конкретизируется в конце доклада, в современных условиях такой подход становится одной из ловушек для проектировщика).

1.5 Системный анализ предметной области

Нет необходимости говорить, насколько широкое распространение получила в последнее время идеология обьектов в самых разных областях информатики. Обьектный подход присутствует, кажется, во всех мыслимых разработках, начиная от операционных систем, таких как Gairo и Taligent, и кончая текстовыми процессорами и электронными таблицами. Системы управления базами данных не представляют в данном случае исключения. Один из самых насущных вопросов, стоящих перед разработчиками СУБД, состоит в том, как обеспечить возможность хранения и работы с данными бурно развивающихся сейчас нетрадиционных приложений. Практика показала, что наиболее распространенная сегодня реляционная технология мало пригодна для работы со сложными обьектами, встречающимися в приложениях мультимедиа, GAD/GAM, CASE, географических информационных системах, полнотекстовых базах данных, системах управления большими компьютерными сетями. Объектно-ориентированный подход - это попытка преодолеть ограничения, связанные с использованием традиционной (реляционной) технологии СУБД.

Примеры использования объектно-ориентированных СУБД

Объектно-ориентированная СУБД - это система, позволяющая создавать, хранить и использовать информацию в форме объектов (см. Объектно-ориентированный подход). Полностью объектно-ориентированная СУБД обеспечивает также объектно-ориентированный интерфейс взаимодействия с пользователем.

Наиболее широкое применение объектно-ориентированные базы данных нашли в таких областях, как системы автоматизированного конструирования/производства (CAD/CAM), системы автоматизированной разработки программного обеспечения (CASE), системы управления составными документами - словом, в областях не вполне традиционных для баз данных.

Создание базы данных, как правило, включает несколько этапов.Среди них можно выделить:

1. Создание концептуальной модели данных (см. Объектно-ориентированный системный анализ). Как правило, на этом этапе происходит уточнение требований пользователей; модель не связывается с каким-либо конкретным способом реализации, какой-либо конкретной СУБД. Такие свойства технологии моделирования, как выразительность и гибкость, играют здесь первостепенное значение. Довольно часто на практике этап создания концептуальной модели пропускается, что чревато просчетами, которые трудно и дорого исправлять на последующих этапах.

2. Логическое конструирование. На этом этапе создается модель, пригодная для реализации средствами какой-либо определенной СУБД. Здесь уже приходится считаться с ограничениями по типам данных, набору операций, налагаемыми конкретной СУБД.

3. Физическое конструирование. На этом этапе прорабатываются вопросы, связанные с реализацией модели данных во внешней памяти, - кластеризации, разбиения (partitioning), индексирования.

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

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

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

2. Подклассы и суперклассы - экземпляры некоторого класса могут образовывать подмножество другого класса. Так, классы "студент" или "преподаватель" могут рассматриваться как подкласс класса "человек". Для "студента" и "преподавателя" "человек" является суперклассом.

3. Подклассы наследуют атрибуты и поведение своих суперклассов (например, "студент" и "преподаватель" наследуют у "человека" такие атрибуты, как "имя", "пол", "возраст" и т.д.).

4. Наследование атрибутов и поведения позволяет построить иерархию классов: суперкласс, обладающий общими для ряда классов атрибутами, порождает ряд подклассов, которые, наследуя атрибуты своего класса-родителя, добавляют к ним ряд атрибутов, определяющих их собственные свойства. Так, класс "студент", наследуя у "человека" "имя", "возраст", "пол", может добавить к ним "курс", "кафедру" и пр. Этот механизм практически реализует концепции обобщения/конкретизации.

5. Агрегирование - по зволяет создать сложные объекты из объектов-компонентов, определять отношения типа "часть-целое".

В совокупности эти концепции дают возможность не просто моделировать состояние некоторой предметной области на данный момент, но и рассматривать ее в развитии. Все они так или иначе реализуются в различных объектно-ориентированных языках программирования, таких как С++ и Smalltalk Объектно-ориентированные СУБД добавляют к перечисленным выше механизмам свойства, традиционно присущие СУБД: постоянство существования данных (которое в данном случае перерастает в постоянство существования объектов), управление хранением данных во внешней памяти, параллельный доступ к данным, защита целостности (управление транзакциями и восстановление после сбоев), управление доступом к данным, управление запросами пользователей, модификация схемы базы данных.

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

В объектно-ориентированных СУБД технологоия объектов охватывает и концептуальную, и логическую стадии создания продукта. При этом механизмы моделирования данных, о которых сказано выше, находятся в распоряжении разработчиков вплоть до этапа конкретной реализации модели данных во внешней памяти. Таким образом, средства анализа предметной области становятся и средствами реализации этого анализа в конкретном продукте.

1.6 Инфологическое и даталогическое проектирование.

ER-модель

Выделяют несколько подходов к проектированию данных. Например, в РФ используются три этапа проектирования данных: инфологический, даталогический и физический; на Западе - два этапа: инфологическое (логическое или концептуальное) и физическое проектирование данных.

Существует множество способов представления реального мира в виде моделей. Инфологическое моделирование, как способ отражения объектов и процессов реального мира отличают:

а) селективность. Не все объекты и процессы реального мира можно отразить с помощью инфологических моделей (ИЛМ), более того разные методологии ИЛМ могут быть предназначены для различных сфер реального мира. Изначально на объекты и процессы предметной области накладываются некоторые ограничения (чаще всего они довольно нестрогие и "размыты") для того, чтобы построить модель. Это связано с тем, что в ИЛМ отражается не весь реальный мир, и не все объекты и процессы, которые можно отразить аппаратом данной ИЛМ, а только те, которые входят в предметную область и самое главное важны для предметной области. Предметная область - это часть реального мира, информация о которой является объектом рассматриваемой информационной системы;

б) язык. Синтаксические и семантические правила построения ИЛМ. По используемому языку ИЛМ можно разделить на два вида (рисунок 12) - аналитические и графовые.

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

В графовых ИЛМ алфавитом являются различные графические символы. Наиболее известной методикой проектирования баз данных, использующей аналитическую ИЛМ, является методика проектирования Дейта.

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

Аналитические модели практически невозможно использовать для целей проектирования баз данных ЭИС вследствие их сложности, громоздкости, неадаптивности и большой трудоемкости разработки при отображении большого количества разнотипных процессов, объектов, свойств и ограничении. Такие модели идеально подходят для систем с небольшим количеством разнотипных объектов и процессов (не более пяти), имеющих малое количество свойств. Кроме того, моделируемая предметная область должна быть относительно статична, что нехарактерно для экономических систем.

Распространение сетевых инфологических моделей сдерживается из-за объективных сложностей в создании и реализации алгоритма перехода от них к физическим моделям, описанным на широко применяемых языках описания данных.

Отдельным классом графовых ИЛМ являются ER-модели. В настоящее время они наиболее широко распространены, вследствие своей эффективности, возможности использования для отображения многих областей реального мира, относительной простоты построения и наглядности.

Широкое применение ER-моделей привело к появлению сначала алгоритмов перехода от них к иерархическим, сетевым и реляционным физическим моделям, а затем средств автоматизации, как процесса построения ER-модели, так и процесса получения по ней физической модели.

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

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

ER-модель - это отражение реального мира в виде сущностей (Entity) и связей между ними (Relationship). Сегодня ER-моделирование является самым распространенным методом построения инфологических моделей ЭИС. Многие из методик ER-моделирования легли в основу современных автоматизированных систем проектирования баз данных либо используются при неавтоматизированной разработке.

Различные методики построения ER-моделей анализируются по следующим основным аспектам:

- терминологический аппарат, лежащий в основе методики;

- семантические возможности модели для отображения различных ситуаций реального мира;

- наличие алгоритма перехода от ER-модели к различным физическим и конкретно к реляционной физической модели;

- эффективность алгоритма перехода;

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

Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект может быть представлен только одной сущностью, которая должна быть уникально унифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

Каждая сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. При этом любой атрибут может быть определен как ключевой. Ключ - один или несколько атрибутов, однозначно определяющих каждый экземпляр объекта. Например, атрибут КОД КЛИЕНТА является идентификатором объекта КЛИЕНТ. Графически объект может быть представлен в виде прямоугольника, содержащего имя объекта и список атрибутов, в котором ключевые атрибуты выделены, например, подчеркиванием.

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

1) Связь 1:1 (один-к-одному) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.

2) При связи 1:n (один-ко-многим) одному экземпляру информационного объекта А соответствует любое количество экземпляров объекта В, но каждый экземпляр объекта В связан не более, чем с одним экземпляром объекта А. Отношения данного типа являются наиболее часто используемыми.

3) Связь m:n (многие-ко-многим) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует любое количество экземпляров объекта В и наоборот. Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных ассоциативных сущностей и с введением новых отношений).

На основе полученной логической модели осуществляется физическое проектирование данных. Физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. Результатом этого процесса является физическая модель, содержащая полную информацию, необходимую для генерации всех необходимых объектов в базе данных. Для СУБД, поддерживающих системный каталог, физическая модель обычно соответствует его содержимому.

В процессе физического проектирования следует определить наименования таблиц и типы данных для всех полей. Если необходимо, на этом же этапе описываются представления (если таковые будут создаваться) и может быть создан код хранимых процедур. Далее обычно полагается определить, какие именно объекты и как будут создаваться: например, с помощью каких SQL-предложений создаются индексы, с помощью каких объектов – триггеров или серверных ограничений – реализуется ссылочная целостность, создаются ли индексы для альтернативных ключей и т.д.

ER-Модель П.Чена

Идеи П.Чена [25, 26] являются своеобразным стандартом в построении ER-моделей. Другие модели могут отличаться набором графических символов, некоторыми особенностями моделирования, но основные правила остались теми же.

Под сущностью понимается "нечто", что можно идентифицировать. Сущности могут попадать в различные типы сущностей, которые на ER-диаграммах изображаются в виде прямоугольников. Реальный мир содержит множество объектов, которые можно четко идентифицировать. Некоторые из них интересны при моделировании, другие - нет. В задачи проектировщика входит отобрать именно те типы сущностей, которые нужны и будущей информационной системе.

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

Символы "m" и "1" около типа связи "РУКОВОДИТЕЛЬ" показывают, что каждый проект имеет только одного руководителя, а каждый сотрудник может руководить несколькими проектами. Символы "m" и "n" около типа связи "УЧАСТНИК" указывают на отношение "многие-ко-многим". Это означает, что в каждом проекте могут участвовать несколько сотрудников, и каждый сотрудник может входить в несколько проектов. Возникновение других видов связей между сущностями, по мнению П. Чена. маловероятно, но возможно. Например, тип связи "БРАК" - это отношение "один-к-одному" между людьми.

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

Сущности и связи имеют свойства, которые могут быть выражены парой "атрибут - значение атрибута". Например, в выражении "Возраст сотрудника Х равен 24". "ВОЗРАСТ" - это свойство сотрудника X, а "24" - значение свойства "ВОЗРАСТ".

На ER-диаграммах атрибуты изображаются в кружках, соединенных с типами сущностей.

В некотрых случаях атрибут может иметь более одного значения для одной и той же сущности. В этих случаях дуга от сущности к атрибуту помечается как "1:n" и это означает множественность атрибута. Большинство атрибутов имеют единственное значение, поэтому, чтобы не усложнять диаграмму, их дуги не помечаются как "1:1".

Не только сущности имеют атрибуты. Иногда бывают интересны свойства связей. Например, мы хотим узнать, когда сотрудник Х начал работать в данном проекте. "ДАТА НАЧАЛА РАБОТЫ" не является атрибутом сущностей "СОТРУДНИК" или "ПРОЕКТ". Это свойство сразу двух сущностей. В действительности, "ДАТА НАЧАЛА РАБОТЫ" является атрибутом связи "УЧАСТВУЕТ".

П.Ченом был предложен также алгоритм перехода от инфологической к сетевой физической модели. С некоторыми модификациями этот алгоритм может быть использован для проектирования структур реляционных баз данных.

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

Объект описывается путем задания значений его свойств. При описании предметной области связи между объектом и его свойствами обычно представляются как односторонние (от объекта к свойству). Кроме типа связи, желательно указывать признак стабильности, а для условных связей - значение условия, при котором данная связь отсутствует.

2 Производственный этап

2.1 Создание конфигурации «Библиотека»

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

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

Выходными данными будут являться данные отчетов о должниках и работе по фондам на определенную дату или период.

Для начала работы с программой необходимо дважды нажать на ярлык, расположенный на рабочем столе и в появившейся диалоговой форме выбрать информационную базу и режим работы 1С:Предприятие, поставив галочку Монопольно (рисунок 2).

Рисунок 2 Запуск 1С:Предприятия

После этого запустится авторизация доступа системы (рисунок 3), в которой следует выбрать нужного пользователя (ЗавБиблиотекой или библиотекарь), а также ввести соответствующие пароли, установленные при конфигурировании системы.

Рисунок 3 – авторизация доступа

При выборе нужного пользователя и ввода пароля открывается главное окно программы (рисунок 4)

Рисунок 4 - Главное окно программы

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

При нажатии пункта «Справочники» появится дополнительное меню с тремя справочниками «Читатели» (все имеющиеся читатели), «Выданные книги» (все выданные книги) и «Каталог книг» (все имеющиеся книги) (рисунок 5).

Рисунок 5 – выбор справочника

При нажатии пункта «Документы» появится дополнительное меню с документами «Запись в библиотеку», «Выдача книг», «возврат книг», «Покупка», «Списание книг» (рисунок 6).

Рисунок 6 – Выбор документа

После выбора нужного документа появляется форма соответствующего документа для ввода информации. Внешний вид форм документов можно посмотреть на рисунке 7.

Рисунок 7- Форма документа «Запись в библиотеку»

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

После проведения документа все данные заносятся в справочник Читатели. Внешний вид форм справочника можно посмотреть на рисунке 8.

Рисунок 8 – Справочник Читатели

Так же можно просмотреть печатную форму документа. Рисунок 9.

Рисунок 9 – печатная форма документа «Запись в библиотеку»

Для выдачи книг читателям заполняется документ «Выдача Книг». Рисунок 10.

Рисунок 10 – Форма документа «Выдача Книг»

При проведении документа информация заносится в справочник «Выданные книги». Рисунок 11.

Рисунок 11 – Справочник Выданные книги

При необходимости можно получить печатную форму документа «Выданные книги». Рисунок 12.

Рисунок 12 – печатная форма документа «Выдача книг»

При возврате читателем книг в библиотеку заполняется документ «возврат книг». Рисунок 13,14.

Рисунок 13 – Форма документа «Возврат Книг»

Рисунок 14 – печатная форма документа «Возврат книг книг»

При проведении документа информация заносится в справочник «Каталог Книг» и в нем ставится отметка о сдаче. Рисунок 15.

Рисунок 15 – Справочник КаталогКниги

При покупке книг оформляется документ оформляется документ «Покупка». Рисунок 16, 17.

Рисунок 16 – Форма документа «Покупка»

Рисунок 17 – печатная форма документа «Покупка»

При проведении документа информация заносится в справочник «Каталог Книг». Рисунок 18.

Рисунок 18 – Справочник Каталог Книг

При списании книг оформляется документ «Списание книг». Рисунок 19, 20

Рисунок 19 – Форма документа «Списание книг»

Рисунок 20 – печатная форма документа «Списание книг»

При проведении документа информация заносится в справочник «Каталог Книг», ставится дата списания. Рисунок 21.

Рисунок 21 – Справочник Каталог Книг

При необходимости, можно просмотреть имеющиеся в наличии книги, списанные и закупленные, сформировав отчет «По фондам». Рисунок 22,23.

Рисунок 22 – Отчет «По фондам»

Рисунок 23 – Отчет «По фондам»

Так же можно просмотреть списки должников, сформировав отчет «ПоДолжникам». Рисунок 24.

Рисунок 24 – Отчет «ПоДолжникам»

Для простоты использования Каталога книг предусмотрен поиск по названию книги и фамилии автора. Рисунок 25.

Рисунок 25 – Справочник «КаталогКниг»

2.2 Заполнение бухгалтерских документов

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

Рисунок 26 – Справка о доходах физических лиц

Путевой лист показывает какую работу должен выполнить водитель автомобиля, движение горючего, маршрут, так же используется при начислении заработной платы. Пример путевого листа показан на рисунке 27.

Рисунок 27 – Путевой лист

Счет-фактура показывает, какой материал был продан, какой организации и на какую сумму. Рисунок 28.

Рисунок 28 – Счет-фактура

Расходный кассовый ордер показывает информацию о том, какая сумма была взята из кассы предприятия и на каком основании. Пример документа показан на рисунке 29

Рисунок 29 – Расходный кассовый ордер

Приходный кассовый ордер показывает информацию о том, какие деньги пришли в кассу предприятия и на каком основании. Пример Приходного кассового ордера показан на рисунке 30.

Рисунок 30 – Приходный кассовый ордер

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

Рисунок 31 – Авансовый отчет

Накладная – это сопровождающий документ, который содержит информацию о проданном материале. Пример Накладной показан на рисунке 32.

Рисунок 32 – Накладная

Заключение

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

ЛИТЕРАТУРА

1. Байдаков В., Нуралиев С., Шевченко А. Введение в конфигурирование 1С:Бухгалтерии 7.7 М, Фирма «1С», 2000

2. 1С:Предприятие 7.7 Описание встроенного языка М, Фирма «1С», 1999

3. 1С:Предприятие 7.7 Конфигурирование и администрирование. Часть 1 М, Фирма «1С», 1999

4. 1С:Предприятие 7.7 Конфигурирование и администрирование. Часть 2 - М, Фирма «1С», 1999

5. Тимофеев Г.С., Шумейко Д.А. Конфигурирование и администрирование 1С:Предприятия. Серия «Учебный курс» Ростов Н/Д: Феникс, 2003

6. Козырев Д.В. Курс «Базовые объекты+объекты компоненты Бухгалтерский учет, 7.7» Методические материалы. – М: ООО «1С – Учебный центр № 3», 2003

7. Рязанцева Н.А., Рязанцев Д.Н. 1С: Предприятие. Секреты программирования СПб.: БХВ-Петербург, 2004