Главная
База знаний "Allbest"
Программирование, компьютеры и кибернетика
Автоматизация учета основных средств на предприятии
Автоматизация учета основных средств на предприятии
Организационно-экономическая характеристика предметной области. Описание компании ООО "Алеф", анализ административной и хозяйственной деятельности предприятия. Автоматизация процесса учета основных средств с помощью комплекса комплекс УСН 1С Бухгалтерия.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 01.06.2010 |
| Размер файла | 3,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Учитывая выше описанную схему работы с документами, основанную на готовых шаблонах, в которые вносится ряд изменений при формировании, можно преобразовать эту часть работы в отдельный блок не нарушая общей системы работы, что ускорило бы и оптимизировало процесс.
1.2.2 Обоснование выбора задач, входящих в комплекс. Преимущества основной учетной системы 1С УСН, а также недостающие звенья автоматизированного учета
Как мы уже упоминали ранее, основой учета является АСУ - является 1С Бухгалтерия 7.7, УСН типовая конфигурация. Несомненно, эта система имеет огромное количество преимуществ, из них самые главные:
это открытость системы. Многие привыкли к тому, что компьютерная программа - это черный ящик. Что в нем происходит - никому, кроме разработчика, не понятно, а программа может делать только то, что в нее изначально заложено, и большего от нее не добиться. С системой 1С все с точностью до наоборот. По сути дела компания 1С продает не только готовые программы экономического назначения для ведения тех или иных видов учета, она еще и комплектует их инструментами, с помощью которых (обладая определенной квалификацией программиста, конечно же) можно перенастроить (перепрограммировать), доработать существующие решения индивидуально под нужды конкретного предприятия. Более того, с помощью имеющихся средств пользователю дается возможность создавать свои собственные учетные конфигурации. Такой подход придает системе 1С колоссальную гибкость, что выделяет ее из ряда подобных программ очень и очень сильно.
Вторым важным преимуществом систем 1С является наличие широкой партнерской сети - большого количества компании, способных обслуживать данные программные продукты. И действительно, ведь сама по себе открытость системы обычному пользователю мало что дает. На рынке и помимо 1С присутствуют системы с открытой платформой. Однако часто адаптировать программы под собственный учет можно, а специалистов способных это квалифицированно сделать нет.
Еще одно важнейшее преимущество 1С заключается в высокой оперативности поддержки системы со стороны разработчика. Наиболее значимым это преимущество является для тех, кто пользуется конфигурацией "Бухгалтерский учет". Фирма 1С же, являясь, по сути, очень крупной и мощной компаний, всегда обеспечивает своих пользователей своевременным обновлением. Более того, все обновления распространяются для зарегистрированных пользователей бесплатно.
Тем не менее, несмотря на эти три главных плюса системы, а также несмотря на довольно гибкую настраиваемую систему, встроенный язык (макроязык) программирования, есть весьма трудные комплексные моменты, которые возникают при работе с 1С Предприятием, в частности с 1С Бухгалтерией.
Один из таких минусов - это индивидуальные конфигурации предприятия.
Самой сложной с точки зрения организации учета является ситуация, когда вам необходимо автоматизировать и бухгалтерский учет, и управленческий. Имеется в виду, что два вида учета должны быть связаны между собой определенным образом. Самое простое решение этой задачи - использовать для ведения учета входящую в состав комплексной поставки 1С: Предприятие 7.7 комплексную конфигурацию.
Управленческий учет, в отличие от бухгалтерского, целиком и полностью определяется нами - это обычно наше поле для творчества. Здесь мы решаем, что и как должно быть устроено, чтобы отражать реальную картину на нашем предприятии. А это означает, что рано или поздно, заложенных в типовую конфигурацию механизмов нам не хватит, и мы вынуждены будем воспользоваться созданием в ней "индивидуальных настроек", которые будут описывать наши специфические потребности в учете.
Более скромной проблемой является та задача, которую призван решить данный дипломный проект - быстрая и удобная система заполнения унифицированных форм. Функциональная насыщенность комплекса 1С Бухгалтерия достаточно высока для обеспечения основных необходимостей бухгалтерского учета и документооборота и позволяет охватить максимум необходимых задач. По функциональности, однако, мы дополняем имеющуюся схему отдельным блоком автоматизации документооборота - т.е. автоматическое формирование на основании имеющихся динамических данных 1С заполненных документов - стандартных форм документооборота. Таким образом, так как наш блок АСУ является дополнительным и внешним к основной учетной системе, а не конкурирующим, то его функциональность должна быть очень высока при правильной реализации.
1.2.3 Способы решения задачи. Общая модель подбора решения
В современных условиях динамично развивается рынок комплексных интегрированных систем автоматизации предприятий и учреждений самого различного профиля (финансовых, промышленных, офисных) и самых различных размеров с разнообразными схемами иерархии, начиная от малых предприятий численностью в несколько десятков человек и завершая крупными корпорациями численностью в десятки тысяч сотрудников. Такие системы предназначены для решения задач как предприятия в целом (управление финансовыми ресурсами, управление запасами, планирование и производство, сбыт и снабжение, техническое обслуживание и ремонт оборудования, управление персоналом и т.п.), так и уровня его производственных подразделений, цехов и участков.
Фактически проблема комплексной автоматизации стала актуальной для каждого предприятия. Уже не стоит вопрос “надо или не надо автоматизировать”, предприятия столкнулись с проблемой: каким образом это осуществить. Подобная переориентация предприятий объясняется следующими основными причинами:
повышением степени организационной и финансовой самостоятельности;
выходом на зарубежный рынок;
стремлением ряда западных компаний производить свои товары в России;
возрастающей ориентацией предприятий на бизнес-процессы, т.е. деятельности, имеющие ценность для клиента;
появлением на рынке как зарубежных, так и отечественных систем автоматизации, опыта их внедрения и использования и др.
Главная особенность индустрии систем автоматизации различных предприятий и учреждений, характеризующихся широкой номенклатурой входных данных с различными (и нетривиальными) маршрутами их обработки, состоит в концентрации сложности на начальных этапах анализа требований и проектирования спецификаций системы при относительно невысокой сложности и трудоемкости последующих этапов. Фактически здесь и приходит понимание того, что будет делать будущая система и каким образом она будет работать, чтобы удовлетворить предъявленным к ней требованиям. А именно нечеткость и неполнота системных требований, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всей работы в целом.
С другой стороны, не существует двух одинаковых организаций. Даже в таком учреждении как Сбербанк России на уровне его отделений и филиалов выявляются различия в применяемых технологиях. А следовательно, простое тиражирование даже очень хорошей системы управления предприятием никогда не устроит заказчика полностью, поскольку не может учесть его специфики. Более того, в данном случае возникает проблема выбора именно той системы, которая наиболее подходит для конкретного предприятия. А эта проблема осложняется еще и тем, что ключевые слова, характеризующие различные системы, практически одни и те же:
единая информационная среда предприятия;
режим реального времени;
независимость от законодательства;
интеграция с другими приложениями (в том числе с уже работающими на предприятии системами);
поэтапное внедрение и т.п.
Следует отметить, что для большинства предприятий необходим и предваряющий автоматизацию этап - наведение порядка в их деятельности, создание рациональных технологий и бизнес-процессов. Речь даже не идет о жестком их реинжиниринге, в современных российских условиях происходит массовый бизнес-инжиниринг.
Ниже сформулированы два крайних подхода к автоматизации предприятий, полностью игнорирующие приведенные тезисы.
1. Короткое и “легкое" обследование предприятия и дальнейшее лоббирование одной из интегрированных систем управления предприятием под красивыми лозунгами настройки и адаптации под конкретного заказчика (кстати, стоимость такой настройки может на порядок превышать стоимость модулей системы и требовать серьезных временных затрат, совместимых с затратами на разработку новой системы). При этом, как правило, фирма-исполнитель еще до проведения обследования (да и вообще, до появления заказчика на ее горизонте) знает, какую именно систему она будет внедрять, и осуществляет соответствующую “адаптацию” результатов обследования.
2. Детальное обследование предприятия и разработка на его основе собственной системы управления, дублирующей существующие на предприятии технологии, что только усугубляет ситуацию (автоматизируя хаос и неразбериху, можно получить только “автоматизированный хаос”).
Очевидно, что перечисленные подходы к автоматизации уже не могут устроить заказчика, желающего “увидеть” и скорректировать будущую систему до того, как она будет реализована физически, и в конечном итоге за свои немалые деньги получить реальную выгоду от ее эксплуатации.
С другой стороны, самостоятельно с задачей выбора и тем более разработки собственной системы предприятие справиться не в состоянии. И прежде всего потому, что на предприятии, как правило, отсутствует единая концепция автоматизации. Возникает необходимость в услугах независимых от производителей систем автоматизации консалтинговых фирм.
На основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?".
Этот этап разделяется на два подэтапа:
проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;
детальное проектирование, включающее разработку спецификаций каждой компоненты, разработку требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей.
При этом происходит расширение системного проекта:
за счет его уточнения;
за счет построения моделей автоматизированных рабочих мест, включающих подсхемы информационной модели и функциональные модели, ориентированные на эти подсхемы вплоть до идентификации конкретных сущностей информационной модели;
за счет построения моделей межмодульных и внутримодульных взаимодействий с использованием техники структурных карт.
Что касается конкретно нашей задачи, то для ее решения удобно использовать какое-то хранилище данных (для формирования документов), а также интерфейсную часть, для того чтобы организовать программное и интерфейсное взаимодействие с самими данными. Для того, чтобы провести разработку такого дополнительного модуля, нам надо было провести работу по выбору инструментария для разработки интерфейсной части, а также СУБД для хранения данных.
1.3 Обоснование проектных решений по автоматизированному решению экономико-информационных задач. Основные моменты автоматизации учета деятельности предприятия. Решение наших задач с точки зрения автоматизации учета на предприятии
Эта работа предваряет собственно систему автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.
На этом этапе определяются:
архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;
состав людей и работ, имеющих отношение к системе;
ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
Системный проект строится на основе модели “как должно быть” и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3), информационную модель, например, в соответствии со стандартом IDEF1X, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89).
По завершении данного этапа (после согласования системного проекта с заказчиком) изменяется роль консультанта. Отныне он как бы становится на сторону заказчика, и одной из его основных функций на всех последующих этапах работ будет являться контроль на соответствие требованиям, зафиксированным в системном проекте.
Необходимо отметить следующее достоинство системного проекта. Для традиционной разработки характерно осуществление начальных этапов кустарными неформализованными способами. В результате заказчики и пользователи впервые могут увидеть систему после того, как она уже в большей степени реализована. Естественно, эта система отличается от того, что они ожидали увидеть. Поэтому далее следует еще несколько итераций ее разработки или модификации, что требует дополнительных (и значительных) затрат денег и времени. Ключ к решению этой проблемы и дает системный проект, позволяющий:
описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;
уменьшить затраты на разработку и внедрение системы;
оценить разработку по времени и результатам;
достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);
улучшить качество разрабатываемой системы, а именно: создать оптимальную структуру интегрированной базы данных, выполнить функциональную декомпозицию типовых модулей.
Системный проект полностью независим и отделяем от конкретных разработчиков, не требует сопровождения его создателями и может быть безболезненно передан другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации на основе проекта, он может быть положен "на полку" до тех пор, пока в нем не возникнет необходимость. Кроме того, его можно использовать для самостоятельной разработки или корректировки уже реализованных на его основе программных средств силами программистов отдела автоматизации предприятия.
На основании системного проекта осуществляется:
составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;
анализ применимости существующих систем управления предприятиями для решения требуемых задач и формирование рекомендаций по выбору такой системы;
совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;
разработка требований к техническим средствам;
разработка требований к программным средствам;
разработка предложений по этапам и срокам автоматизации.
Что касается конкретно нашей задачи, то исключительно практическая необходимость и целесообразность позволяет правильно сформировать постановку задачи и разработать схему интерфейса, а также саму структуру данных.
1.3.1 Обоснование проектных решений по информационному обеспечению комплекса задач. Подбор информационного обеспечения для блока работы с унифицированными формами
Что касается информационного обеспечения комплекса для решения поставленной задачи, то как мы выше уже указывали для этих целей нам необходимо подобрать максимально простую, но эффективную СУБД для работы с данными, а также собственно язык программирования, который сможет обеспечить взаимодействие с данными и пользовательский интерфейс. Начнем с СУБД.
Общая классификация. База данных (БД) - это данные, организованные в виде набора записей определенной структуры и хранящиеся в файлах, где, помимо самих данных, содержится описание их структуры. Система управления базами данных (СУБД) - это система, обеспечивающая ввод данных в БД, их хранение и восстановление в случае сбоев, манипулирование данными, поиск и вывод данных по запросу пользователя. По моделям представления данных базы данных делят на:
иерархические
сетевые
реляционные
объектно-реляционные
Иерархические базы данных - это самая первая модель представления данных, в которой все записи базы данных представлены в виде дерева, с отношениями предок-потомок. Физически данные отношения реализуются в виде указателей на предков и потомков, содержащихся в самой записи. Такая модель представления данных связана с тем, что на ранних этапах базы данных часто использовались для планирования производственного процесса: каждое выпускаемое изделие состоит из узлов, каждый узел из деталей и т.п.
Однако иерархическая модель не является оптимальной. Допустим, что один и тот же тип болтов используется в автомобиле 300 раз в различных узлах. При использовании иерархической модели, данный тип болтов будет фигурировать в базе данных не 1 раз, а 300 раз (в каждом узле - отдельно). Налицо дублирование информации. Чтобы устранить этот недостаток была введена сетевая модель представления данных.
Сетевая база данных - это база данных, в которой одна запись может участвовать в нескольких отношениях предок-потомок. Т.е. фактически, база данных представляет собой не дерево, а граф.
Физически данная модель также реализуется за счет хранящихся внутри самой записи указателей на другие записи, только, в отличие от иерархической модели, число этих указателей может быть произвольным. И иерархическая и сетевая модель достаточно просты, однако они имеют общий недостаток: для того, чтобы получить ответ даже на простой вопрос, программист был должен написать программу, которая просматривала базу данных, двигаясь по указателям от одной записи к другой. Написание программы занимало некоторое время, и часто к тому моменту, когда такая программа была написана, необходимость в получении данных уже отпадала. Поэтому в середине 80-х годов 20 века произошел практически повсеместный переход к реляционным базам данных.
В реляционной базе данных вся информация представляется в виде таблиц и любые операции над данными - это операции над таблицами. Таблицы состоят из строк и столбцов. Строки - это записи, а столбцы представляют структуру записи (каждый столбец имеет определенный тип данных и длину данных). Строки в таблице не упорядочены - не существует первой или десятой строки. Однако поскольку на строки надо как-то ссылаться, то вводится понятие "первичный ключ". Первичный ключ - это столбец, значения которого во всех строках разные. Используя первичный ключ можно однозначно сослаться на какую-либо строку таблицы. Первичный ключ может состоять и из нескольких столбцов (составной первичный ключ).
Некоторые СУБД требуют в явном виде указать первичный ключ таблицы, а некоторые позволяют пользователю не задавать для таблицы первичный ключ - в таком случае СУБД сама добавляет в таблицу столбец - первичный ключ, не отображаемый на экране (так, например, в СУБД Oracle у любой таблицы существует псевдо-столбец ROWID, формируемый Oracle, который содержит уникальный адрес каждой строки).
Отношения предок-потомок в реляционных БД реализуются при помощи внешних ключей. Внешний ключ это столбец таблицы, значения которого совпадают со значениями первичного ключа некоторой другой таблицы.
Объектно-реляционные базы данных появились в последнее время у значительного числа производителей СУБД (Oracle, Informix, PostgreSQL) и сочетают в себе реляционную модель данных с концепциями объектно-ориентированного программирования (полиморфизм, инкапсуляция, наследование).
СУБД Oracle. СУБД ORACLE является на сегодняшний день самой мощной, многофункциональной и легко масштабируемой СУБД, построенной по архитектуре "клиент/сервер", поддерживающей практически все существующие платформы. Это прекрасный выбор для крупной организации: первоначальные затраты на установку (лицензия, приобретение высокопроизводительных серверов) в будущем обернутся значительной экономией средств при необходимости расширения базы данных. Для небольшой организации мощь Oracle может оказаться чрезмерной, в таком случае можно рекомендовать использование Microsoft SQL Server (Windows NT/2000) или PostgreSQL (Linux/Unix). Для фирм малого бизнеса стандартом остается СУБД MS Access. Тем не менее, Oracle продолжает занимать значительную долю рынка, являясь пожалуй самой передовой СУБД.
База данных Oracle содержит различные типы объектов. Эти объекты можно подразделить на две категории: объекты схемы и объекты, не принадлежащие схемам. Схема (schema) - это набор объектов различной логической структуры данных. Каждая схема принадлежит пользователю базы данных и имеет одинаковое с ним имя. Каждый пользователь владеет одной схемой. Схема может содержать следующие объекты:
таблицы;
индексы;
кластеры;
представления (виды);
снимки - snapshots, журналы репликаций;
линки/связи базы данных (содержат информацию о подключении к удаленной базе данных);
последовательности;
синонимы;
пакеты, хранимые процедуры, функции, триггеры;
библиотеки внешних процедур;
СУБД MS SQL Server, сравнение с MS Access. MS SQL Server - это реляционная СУБД, построенная по архитектуре клиент-сервер. MS SQL Server ориентирован на использование в операционных системах Windows NT/2000 и использует в своей работе системные функции этих ОС, что значительно упрощает архитектуру MS SQL Server, в отличие от других СУБД, вынужденных дублировать некоторые функции ядра операционной системы, для обеспечения межплатформенной переносимости. За счет такой тесной интеграции с Windows NT/2000, СУБД MS SQL Server работает на всех платформах, для которых реализована Windows NT/2000.
SQL Server - это не просто улучшенный Access. В SQL Server реализована система разграничения доступа к объектам базы данных (разные пользователи имеют разные права по работе с различными таблицами, запросами и т.д.). Ограничения доступа можно выставлять не только на таблицу в целом, но даже и на отдельные ее столбцы. Также в SQL Server поддерживается механизм ролей. Роль - это набор прав доступа к объектам базы данных. Роли для каждой базы данных можно определять самостоятельно или пользоваться заранее определенными ролями. Например, роль администраторы безопасности (security admin) - это пользователи которые могут допускать других пользователей к работе с базой данных, роль создатели базы данных (db creators, database creators) - пользователи которые могут создавать и изменять структуру базы данных и т.д. Используя роли можно быстро и удобно разграничить доступ между пользователями, предоставив им только те права, которые действительно необходимы. Причем нарушения прав доступа, также как и сама работа SQL Server будут протоколироваться в специальных log-файлах. SQL Server также позволяет пользователям, правильно указавшим свой пароль при входе в сеть (домен Windows NT/2000), повторно не вводить пароль при доступе к базе данных (Windows authentication mode).
К другим существенным отличиям относится то, что если в Access хранимые процедуры и функции пишутся на VBA (Visual Basic for Applications), то в SQL Server основным языком написания хранимых процедур является Transact SQL (хотя могут использоваться и внешние хранимые процедуры, написанные на других языках). Transact SQL - это диалект SQL, в котором, помимо стандартных инструкций SQL, предусмотрены возможности организации циклов, условного выполнения операторов и т.д.
MS SQL Server может содержать несколько баз данных. На одном компьютере может быть установлено несколько экземпляров MS SQL Server. Каждая база данных содержит следующие объекты:
таблицы
индексы
представления (виды, запросы)
диаграммы (схема данных)
курсоры (окно накладываемое на набор данных, аналог окна в текстовом редакторе, в котором в каждый момент времени отображается только часть документа)
триггеры, хранимые и внешние процедуры, функции пользователя, пользовательские типы данных
правила (ограничения на значения столбцов) и умолчания (значения столбцов по умолчанию) - необходимо для совместимости со старыми версиями, в новых версиях все эти ограничения указываются в инструкции Create языка SQL.
перечень пользователей, допущенных к базе данных и их разрешения, роли пользователей
каталоги полнотекстного поиска (позволяет осуществлять поиск текста по столбцам таблицы, включая столбцы, в которых в качестве значений содержатся файлы. doc,. xls,. txt,. htm)
СУБД Informix Universal Server. Работы над системой управления базами данных Informix были начаты в 1980 г. Согласно начальному замыслу Informix рассматривалась как СУБД, специально ориентированная для работы в среде ОС UNIX и использующая реляционную модель данных. Однако чисто реляционная модель данных не лишена определенных недостатков. За счет использования концепций объектно-ориентированного программирования (инкапсуляция, полиморфизм и наследование) Informix Universal Server позволяет вводить новые базовые типы данных, одновременно с введением для них специальных алгоритмов хранения, доступа и индексирования. При этом можно использовать как встроенные в Informix Universal Server методы доступа и хранения, так и определять новые
СУБД DB2. Одна из первых реляционных СУБД. Разработка фирмы IBM. Построена по архитектуре клиент-сервер и имеет огромный набор возможностей. Первоначально предназначалась для работы на мэйнфреймах, под управлением операционной системы OS/390. Существуют также версии под ОС Windows NT/2000, Linux и др. операционные системы.
СУБД Visual FoxPro, Corel Paradox, MS Access. Общей отличительной особенностью этих реляционных СУБД является то, что они построены по архитектуре файл-сервер и предназначены для баз данных с небольшим числом пользователей и небольшими объемами обрабатываемой информации (офисные СУБД). На территории СНГ наиболее распространенной является СУБД MS Access, о которой и пойдет речь в последующих главах.
Что касается, конкретно нашей задачи, то нам нет необходимости использовать серьезные сетевые ресурсы, обеспечивать высокое быстродействие, высокую степень защиту данных и критически минимальные сроки неработоспособности. У нас не столь серьезные требования к качеству СУБД, чтобы выбирать самое мощное из имеющихся в сегодняшнем арсенале разработчика. Нам нужно обеспечить одно локальное рабочее место, модуль, не имеющий ограничений на доступ, без шифрования данных, без каких-то либо автоматических сервисов. Кроме того. одно из условий выбора - доступность среды, а также нетребовательность к ресурсам системы, отсутствие какого-либо сложного инсталляционного пакета.
1.3.2 Обоснование проектных решений по технологии сбора, передачи, обработки и выдачи информации. Реализация недостающего в УСН блока работы с унифицированными формами
Общая цепочка обработки информации довольно простая. На данном этапе реализована схема, дублирующая аналогичные данные в 1С Бухгалтерии. Так как модуль получился внешним, и соответственно, достаточно гибким в эксплуатации и модификации, то часть связи с 1С может быть обеспечена в любом удобным момент путем добавления еще одного блока в уже существующий.
На текущем этапе разработана схема, позволяющая занести все необходимые для заполнения унифицированных форм данные с помощью отдельного программного интерфейса. Данный интерфейс представлен в виде логически упорядоченных форм. расположенных по разделах. Формы разработаны по подобию аналогичных в 1С Бухгалтерии. Далее, на основании шаблонов 1С Бухгалтерии подключены необходимые шаблоны документов, которые привязаны программным образом к данным из соответствующих форм.
Для того, чтобы вывести в унифицированную форму какой-либо документ, необходимо заполнить информацию по данному документу, т.е. добавить его в базу, выбрать его в перечне соответствующих интерфейсных форм, после чего с помощью соответствующих управляющих элементов запустить печать для необходимой выбранной формы. Вот собственно и весь перечень действий, которые нужно произвести пользователю для того, чтобы получить готовую стандартную документацию.
Для реализации задуманной схемы используется выбранная СУБД MS Access при использовании встроенного языка программирования VBA.
1.3.3 Обоснование проектных решений по программному обеспечению комплекса задач
Таким образом, существует достаточно большое количество популярных СУБД. Что же позволило нам остановиться на MS Access?
Основные достоинства этой СУБД - доступность, простота удобство в конструировании, доработке, администрировании. Вместе с тем Access позволяет надежно хранить данные и эффективно их обрабатывать. Поэтому, начиная с Access 97, этот продукт стабильно держится в рейтинге настольных СУБД на первых местах. Сегодня наиболее популярен Access 2003, который входит в состав пакета MS Office 2003. К отдельным перечням достоинств стоит отнести и полную интеграцию с другими офисными приложениями - Word, Outlook, Excel.
1.3.4 Обоснование необходимости использования вычислительной техники и создания АРМ для решения данного комплекса задач
Программное обеспечение позволяет усовершенствовать организацию работы вычислительной системы с целью максимального использования ее техники.
Необходимость в разработке ПО обусловливается следующим:
обеспечить работоспособность технических средств, так как без программного обеспечения они не могут осуществить никаких вычислительных и логических операций;
обеспечить взаимодействие пользователя с техникой;
сократить цикл от постановки задачи до получения результата ее решения;
повысить эффективность использования ресурсов технических средств.
В настоящее время распространены такие формы ИС в управлении предприятиями:
индивидуальное использование компьютеров;
автоматизированные рабочие места (АРМ);
локальные вычислительные сети (ЛВС).
Эти формы децентрализации ресурсов существенно различаются по концентрации вычислительных средств.
Опыт автоматизации управления в производственно-экономических структурах показал, что степень влияния ИС с развитыми информационно-справочными функциями на эффективность управленческой деятельности очень существенна. К наиболее важным результатам ее работы можно отнести:
расширение информационных возможностей и повышение оперативности принятия решений для ранее действовавших и вновь создаваемых структурных подразделений;
усиление на этой основе координирующих функций звеньев центрального аппарата управления;
значительное повышение информированности и рабочей квалификации работников всех уровней управления.
Применение АРМ не должно нарушать привычный пользователю ритм его работы, должно обеспечивать концентрацию внимания пользователя на логической структуре решаемых задач. Однако если заданное действие не производится или результат искажается, пользователь должен знать причину и информация об этом должна выдаваться на экран.
В составе программного обеспечения АРМ можно выделить два основных вида обеспечения, различающихся по функциям: общее (системное) и специальное (прикладное). К общему программному обеспечению относится комплекс программ, обеспечивающий автоматизацию разработки программ и организацию экономичного вычислительного процесса на ПК безотносительно к решаемым задачам. Специальное (прикладное) программное обеспечение представляет собой совокупность программ решения конкретных задач пользователя.
Режим работы различных технологий, технические особенности вычислительных устройств, разнообразие и массовый характер их применения предъявляют особые требования к программному обеспечению. Такими требованиями являются: надежность, эффективность использования ресурсов ПК, структурность, модульность, эффективность по затратам, дружественность по отношению к пользователю. При разработке и выборе программного обеспечения необходимо ориентироваться в архитектуре и характеристиках ПК, имея в виду минимизацию времени обработки данных, системное обслуживание программ большого количества пользователей, повышение эффективности использования любых конфигураций технологических схем обработки данных.
Классификация программного обеспечения АРМ приведена на рис.1.7.
Рис.1.7 Структура подхода
Главное назначение общего ПО - запуск прикладных программ и управление процессом их выполнения.
Специальное программное обеспечение АРМ обычно состоит из уникальных программ и функциональных пакетов прикладных программ. Именно от функционального ПО зависит конкретная специализация АРМ. Учитывая, что специальное ПО определяет область применения АРМ, состав решаемых пользователем задач, оно должно создаваться на основе инструментальных программных средств диалоговых систем, ориентированных на решение задач со схожими особенностями обработки информации.
Программное обеспечение АРМ должно обладать свойствами адаптивности и настраиваемости на конкретное применение в соответствии с требованиями пользователя.
В качестве операционных систем АРМ, созданных на базе 16-разрядных компьютеров, обычно используется MS DOC, на базе 32-разрядных - OS/2 и UNIX.
Основными приложениями пакетов прикладных программ, входящих в состав специального ПО АРМ, являются обработка текстов, табличная обработка данных, управление базами данных, машинная и деловая графика, организация человеко-машинного диалога, поддержка коммуникаций и работа в сетях.
Эффективными в АРМ являются многофункциональные интегрированные пакеты, реализующие несколько функций переработки информации, например табличную, графическую, управление базами данных, текстовую обработку в рамках одной программной среды.
Интегрированные пакеты удобны для пользователей. Они имеют единый интерфейс, не требуют стыковки входящих в них программных средств, обладают достаточно высокой скоростью решения задач.
Эффективное функционирование ИС управления и АРМ специалиста базируется на комплексном использовании современных программных средств обработки информации в совокупности с современными организационными формами размещения техники.
Выбор организационных форм использования программных средств целесообразно осуществлять с учетом их рассредоточения по уровням иерархии управления в соответствии с организационной структурой автоматизируемого объекта. При этом основным принципом выбора является коллективное обслуживание пользователей, отвечающее структуре экономического объекта.
С учетом современной функциональной структуры территориальных органов управления совокупность программно-технических средств должна образовывать по меньшей мере трехуровневую глобальную систему обработки данных с развитым набором периферийных средств каждого уровня (рис.1.8).
Первый уровень - центральная вычислительная система территориального или корпоративного органа, включающая одну или несколько мощных ЭВМ, или мэйнфреймов. Ее главная функция - общий, экономический и финансовый контроль, информационное обслуживание работников управления.
Второй уровень - вычислительные системы предприятий (объединений), организаций и фирм, которые включают мэйнфреймы, мощные ПК, обеспечивают обработку данных и управление в рамках структурной единицы.
Рис.1.8 Структура подхода
Третий уровень - локально распределенные вычислительные сети на базе ПК, обслуживающие производственные участки нижнего уровня. Каждый участок оснащен собственным ПК, который обеспечивает комплекс работ по первичному учету, учету потребности и распределения ресурсов. В принципе это может быть автоматизированное рабочее место (АРМ), выполняющее функциональные вычислительные процедуры в рамках определенной предметной области.
Пакеты прикладных программ являются наиболее динамично развивающейся частью программного обеспечения: круг решаемых с их помощью задач постоянно расширяется. Внедрение компьютеров во все сферы деятельности стало возможным благодаря появлению новых и совершенствованию существующих ППП.
Структура и принципы построения ППП зависят от класса ЭВМ и операционной системы, с которой этот пакет будет функционировать. Наибольшее количество ППП создано для IBM PC-совместимых компьютеров с операционной системой MS DOS и операционной оболочкой WINDOWS. Классификация этих пакетов программ по функционально-организационному признаку представлена на рис.1.9.
Рис.1.9 Структура подхода.
Проблемно-ориентированные ППП - наиболее функционально развитые и многочисленные ППП. Они включают следующие программные продукты: текстовые процессоры, издательские системы, графические редакторы, демонстрационную графику, системы мультимедиа, ПО САПР, организаторы работ, электронные таблицы (табличные процессоры), системы управления базами данных, программы распознавания символов, финансовые и аналитико-статистические программы.
Обеспечение эффективности информационных технологий и систем в решающей степени определяется программно-техническим оснащением, которое должно отвечать ряду требований. Программно-технические средства организуются на системной основе, что делает их использование более экономичным и надежным.
Широкие возможности компьютеров разных классов и моделей позволяют реализовать любые конфигурации сложных сетевых информационных систем. Аппаратные характеристики ЭВМ влияют на выбор системного и прикладного программного обеспечения. Высокий уровень техники дает возможность использовать и более качественную программную продукцию с большим количеством функций. Развитие программного обеспечения автоматизированного рабочего места (АРМ) экономиста постоянно совершенствует функции пользователя, повышает производительность его труда, одновременно расширяя масштабы деятельности. Совокупный эффект от качества программно-технического оснащения множества АРМ сказывается на процессах управления организацией в целом, на ее доходности и стабильности функционирования.
Что же касается конкретно нашей задачи, то с ней ситуация такова: основная часть АРМ бухгалтера уже готова и продумана в АСУ 1С Бухгалтерия. Наша задача организовать удобный интерфейс для нашего дополнительного блока, который позволит максимально эффективно проводить требуемые операции.
2. Проектная часть
2.1 Информационное обеспечение комплекса задач
2.1.1 Инфологическая (информационная) модель (схема данных) и ее описание
Для построения модели данных удобно воспользоваться языком диаграмм "сущность-связь".
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
СУЩНОСТЬ представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована.
ОТНОШЕНИЕ в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).
Другими словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели:
обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
использование этой информации различными приложениями.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.
ЗНАЧЕНИЕ связи характеризует ее тип и, как правило, выбирается из следующего множества:
{"O или 1", "0 или более", "1", "1 или более", "p: q" (диапазон) }.
Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовать следующие типы отношений:
1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.
1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.
n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).
Разработка ERD включает следующие основные этапы:
Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей.
Идентификация отношений между сущностями и указание типов отношений.
Разрешение неспецифических отношений (отношений n*m).
Этап 1 является определяющим при построении модели, его исходной информацией служит содержимое хранилищ данных, определяемое входящими и выходящими в/из него потоками данных. Его единственное хранилище ДАННЫЕ О ПЕРСОНАЛЕ должно содержать информацию о всех сотрудниках: их имена, адреса, должности, оклады и т.п.
Первоначально осуществляется анализ хранилища, включающий сравнение содержимого входных и выходных потоков и создание на основе этого сравнения варианта схемы хранилища.
Следующий шаг - упрощение схемы при помощи нормализации (удаления повторяющихся групп). Единственным способом нормализации является расщепление данной схемы на две, являющиеся более простыми.
Определение отношений включает выявление связей, для этого отношение должно быть проверено в обоих направлениях следующим образом: выбирается экземпляр одной из сущностей и определяется, сколько различных экземпляров второй сущности может быть с ним связано, и наоборот.
Этап 2 предназначен для разрешения неспецифических (многие ко многим) отношений. Для этого каждое неспецифическое отношение преобразуется в два специфических отношения с введением новых (а именно, ассоциативных) сущностей.
По существу информационно-логическая модель представляет собой иллюстрированную, развернутую, подробную функциональную спецификацию будущей системы.
Инфологическая модель должна выражать информацию о предметной области в виде, независимом от используемой СУБД. Эта модель отражает в естественной и удобной для разработчиков и других пользователей форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей. Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, см. рис 2.1.
Далее на рис.2.2 представлено схематичное изображение потоков данных в системе.
2
Рисунок 2.1
2
Рисунок 2.2.
Что касается нашего случая построения схемы данных, то для ее разработки использовалась уже готовая модель, которая имелась в основной АСУ, а также сами шаблоны унифицированных форм, которые позволяли отобрать необходимые для работы данные.
В структуре данной модели присутствуют: две внешних сущности - “Директор”, “Финансовый отдел"; два процесса - “Ведение исходной информации для заполнения форм”, “Заполнение форм ОС”.
Разработанная схема данных представлена на рис.2.3.
2.1.2 Используемые классификаторы и системы кодирования
Что касается системы кодирования данных, а также схемы классификации, то она полностью идентична таковой, которая имеет место в главной АСУ.
Для принятия к бухгалтерскому учету активов в качестве основных средств необходимо единовременное выполнение следующих условий:
а) при выполнении работ или оказании услуг либо для нужд управления организацией;
б) использование в течение длительного времени, т. с. срока полезного использования продолжительностью свыше 12 месяцев или обычного операционного цикла, если он превышает 12 месяцев;
в) организацией не предполагается последующая перепродажа данных активов;
г) способность приносить организации экономические выгоды (доход) в будущем.
Сроком полезного использования является период, в течение которого использование объекта основных средств приносит доход организации.
Для отдельных групп основных средств срок полезного использования определяется исходя из количества продукции (объема работ в натуральном выражении), ожидаемого к получению в результате использования этого объекта.
Рис.2.3 Рабочая схема данных
Не относятся к основным средствам для целей бухгалтерского учета:
машины, оборудование и иные аналогичные предметы, числящиеся как готовые изделия на складах организаций-изготовителей, как товары - на складах организаций, осуществляющих торговую деятельность;
предметы, сданные в монтаж или подлежащие монтажу, находящиеся в пути;
капитальные и финансовые вложения.
Основные средства организации разнообразны по составу и назначению. В составе основных средств обычно выделяют следующие виды:
здания;
сооружения;
рабочие и силовые машины и оборудование;
измерительные и регулирующие приборы и устройства;
вычислительная техника;
транспортные средства;
инструмент.
производственный и хозяйственный инвентарь и принадлежности;
рабочий, продуктивный и племенной скот;
многолетние насаждения;
капитальные вложения на коренное улучшение земель (осушительные, оросительные и другие мелиоративные работы);
капитальные вложения в арендованные объекты основных средств;
земельные участки, объекты природопользования (вода, недра и другие природные ресурсы);
прочие основные средства.
Единицей бухгалтерского учета основных средств является инвентарный объект. Под инвентарным объектом основных средств признается объект со всеми приспособлениями и принадлежностями или отдельный конструктивно обособленный предмет, предназначенный для выполнения определенных самостоятельных функций, или же обособленный комплекс конструктивно сочлененных предметов, представляющих собой единое целое и предназначенных для выполнения определенной работы. В случае наличия у одного объекта нескольких частей, имеющих разный срок полезного использования, каждая такая часть учитывается как самостоятельный инвентарный объект.
Необходимым условием правильного учета основных средств является единый принцип их оценки. Различают несколько видов оценки основных средств: первоначальная, текущая, восстановительная и остаточная.
Что касается конкретной классификации объектов учета (т.е. товаров или изделий), то она полностью зависит от природы объекта и произвольна. В нашем модуле мы разделили на два уровня классификации наших объектов учета - это категории и подкатегории. При этом структура ступенчатая - категории могут иметь несколько привязанных подкатегорий. А каждый объект учета (т.е. собственно товар - уже может относиться к какой-то категории и подкатегории). Что касается системы кодирования объектов. То каждый и них имеет свой код поставщика, который включен в наименование объекта и является определенной комбинацией букв и цифр. Кроме того, в обязательном порядке каждый объект имеет свой инвентарный уникальный номер, благодаря которому всегда можно получить информацию о местонахождении объекта или его движении.
Используемые классификаторы и системы кодирования отражены в табл.2.1
Таблица 2.1
|
№ п\п |
Наименование кодируемого подмножества |
Система кодирования |
Вид классификатора |
|
|
1 |
Код статьи формы №1 бухгалтерской отчётности |
Последовательная |
Общероссийский |
|
|
2 |
Код статьи формы №2 бухгалтерской отчётности |
Последовательная |
Общероссийский |
|
|
3 |
Код показателя |
Последовательная |
Общесистемный |
|
|
4 |
Формы ОС-1, ОС-2, ОС-3, ОС-4, ОС-6, ОС-6б, инвентаризационная ведомость |
Последовательная |
Общесистемный |
Все перечисленные коды являются индексированными полями.
2.1.3 Характеристика входной информации
Входная информация состоит из первичных данных. которые по своей структуре полностью идентичны таковой в главной АСУ а также шаблонов унифицированных форм.
Для документального оформления операций поступления и выбытия основных средств используются следующие унифицированные формы.
№ОС-1 "Акт о приеме-передаче объектов основных средств (кроме зданий, сооружении)"
Применяется для зачисления в состав основных средств отдельных объектов (кроме зданий, сооружений), поступивших путем:
приобретения за плату у других организаций;
получения от других организаций и лиц в безвозмездное пользование;
внесения учредителями (участниками) в счет их вкладов в уставный (складочный) капитал;
получения в хозяйственное ведение или оперативное управление;
взятия в аренду с последующим выкупом;
получения по акту дарения;
передачи в совместную деятельность и доверительное управление;
передачи в обмен на другое имущество и другими способами, не противоречащими действующему законодательству. При оформлении приемки основных средств акт составляется в одном экземпляре на каждый отдельный объект основных средств членами приемочной комиссии, назначаемой распоряжением (приказом) руководителя организации.
Акт с приложенной технической документацией, относящейся к данному объекту, передается в бухгалтерию организации, подписывается главным бухгалтером и утверждается руководителем организации или лицом, на это уполномоченным.
№ОС-1а "Акт о приеме-передаче здания (сооружения)"
Применяется для зачисления в состав основных средств отдельных зданий и сооружений.
№ОС-1б "Акт о приеме-передаче групп объектов основных средств"
Применяется для зачисления в состав основных средств однородных объектов, имеющих одинаковую стоимость и принятых к учету в одном календарном месяце.
№ОС-2 "Накладная на внутреннее перемещение объектов основных средств", см. образец формы на рис.2.4
Подобные документы
Характеристика и функциональные возможности программы "1С:Предприятие" по автоматизации участка учёта движения и наличия основных средств. Структура информации и технология выполнения работ (работа со справочниками, документами, отчётными формами).
курсовая работа [1,9 M], добавлен 04.11.2013Описание складского учета ООО "Курочка рядом". Проведение инвентаризации на предприятии и возможности его автоматизации. Разработка программного обеспечения подсистемы складского учета. Описание задач разработанной подсистемы и средств ее взаимодействия.
дипломная работа [3,8 M], добавлен 12.04.2012Автоматизация учета закупки и реализации продукции. Сущность задач учета операций товародвижения. Характеристика входной, постоянной, промежуточной и результатной информации. Структура программных средств. Руководство программиста и пользователя.
курсовая работа [2,4 M], добавлен 23.12.2013Разработка проекта автоматизации учета основных средств на сельскохозяйственных предприятиях. Состав технических и программных средств, необходимых для реализации проекта автоматизации учета. Предполагаемые результаты внедрения данного проекта.
курсовая работа [23,4 K], добавлен 14.08.2010Склад ОАО "Ориенбанк", его специфика и структура. Описание структуры базы данных складского учета для предприятия. Разработка пользовательского интерфейса программы. Инструкция к применению базы данных. Автоматизация операций и учета средств банка.
курсовая работа [4,7 M], добавлен 26.02.2010Экономическая эффективность внедрения программного продукта "1С: Бухгалтерия 8.0". Назначение технологической платформы "1С: Предприятие" и конфигурации "Бухгалтерия предприятия". Создание подсистем, справочников, документов, отчетов и интерфейса.
реферат [967,0 K], добавлен 15.06.2015Краткая характеристика организационной структуры управления ООО "Строительная компания "Инжтех". Использование программных средств "ГАРАНТ" и "1С:Бухгалтерия" на предприятии. Расчет экономической эффективности системы автоматизации на предприятии.
курсовая работа [1,2 M], добавлен 11.11.2015Формирование и предоставление бухгалтерской информации в электронном виде внешним контролирующим органам. Сущность комплекса задач по автоматизации учета банковских операций, ее реализация программе "1С: Бухгалтерия". Особенности технология автоматизации.
курсовая работа [1,2 M], добавлен 23.09.2016Программная реализация средства "Автоматизация учета транспортных средств ГАИ" для упрощения работы инспектора ГАИ: отслеживания информации об автомобилях, регистрации, информации о марке, технических характеристиках, владельцах и страховках автомобилей.
курсовая работа [1,3 M], добавлен 12.02.2016Разработка кодификатора, классификатора кадровых ресурсов, входных документов "Прием на работу", "Кадровое перемещение", "Увольнение" и выходных документов учета кадров организации для автоматизации учета кадров на предприятии с помощью 1С:Предприятие.
курсовая работа [72,1 K], добавлен 02.07.2012
