На тему: "Инвентаризация склада"

Содержание

1.1 Описание объекта автоматизации

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

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

Рис. 1 Организационная структура склада.

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

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

Количество инвентаризаций в отчетном году и даты их проведения определяются руководителем организации. Однако вне зависимости от принятой учетной политики, согласно пункту 2 статьи 12 Закона "О бухгалтерском учете", проведение инвентаризации является обязательным.

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

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

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

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

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

Этапы инвентаризации:

1. Руководителем предприятия издается приказ о создании инвентаризационной комиссии.

2. Комиссия готовит план проведения инвентаризации, в котором указывает:

- зоны инвентаризации;

- сотрудников, которые будут проводить пересчеты в указанных зонах;

- временные рамки проведения пересчетов в каждой указанной зоне.

3. Руководителем предприятия утверждается план проведения инвентаризации.

4. Руководителем предприятия издается приказ о прекращении на время проведения инвентаризации:

- перемещений товара внутри складских подразделений;

- перемещений товара на другие предприятия;

- отгрузки товара клиентам.

5. Руководителем предприятия издается приказ о составе рабочих (счетных) комиссий, согласно плану проведения инвентаризации.

6. Инвентаризационной комиссией готовятся инвентаризационные описи товарно-материальных ценностей.

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

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

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

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

11. Согласно инвентаризационным описям товарно-материальных ценностей рабочей (счетной) комиссией проводится повторный пересчет товара.

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

13. По итогам проведения второго пересчета инвентаризационной комиссией готовятся сличительные ведомости результатов инвентаризации товарно-материальных ценностей.

14. Все документы по инвентаризации передаются инвентаризационной комиссией в бухгалтерию предприятия для дальнейшей обработки.

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

16. Руководителем предприятия издается приказ о создании комиссии по проведению контрольной проверки результатов инвентаризации.

17. Комиссия составляет акт о контрольной проверке правильности проведения инвентаризации ценностей и проводит контрольные пересчеты товара. Результаты согласуются со всеми членами инвентаризационной комиссии и заносятся в журнал учета.

1.2 Формализация существующих бизнес-процессов

Функциональная модель "как есть" строится с целью выявления наиболее слабых и уязвимых мест деятельности компании, анализе преимуществ бизнес - процессов и степени изменения существующей структуры организации.

С помощью диаграммы использования (use case diagram), на которой показана совокупность прецедентов и актеров, а также отношения (зависимости, обобщения, ассоциации) между ними, можно выделить внешние системы, контактирующие с системой, основные процессы и их взаимосвязь. Диаграммы использования дают возможность выделить функциональную структуру системы, не вдаваясь в детали ее реализации. Кроме того, производится предварительное выделение объектов системы и их классификация. На основании построенной модели составляется план разработки системы.

В ходе разработки модели "как есть" были выявлены следующие недостатки:

- неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время);

- невозможность автоматически формировать отчеты и общий план производства.

Рис. 2. Диаграмма вариантов использования "как есть"

Разработка и реализация АИС "Инвентаризация склада предприятия" позволит обеспечить возможность выполнения следующих функций:

- формирование номенклатуры материальных ценностей (МЦ);

- регистрация результатов инвентаризации;

- формирование инвентаризационной описи;

- регистрация документов;

- формирование и печать бирок на материальные ценности;

- поиск документов по критериям;

- печать документов.

Внедрение АИС "Инвентаризация склада" позволит:

- сократить сроки выполнения инвентаризации;

- сократить количество ошибки осуществляемых при заполнение документов;

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

- сократить количество рабочих мест;

- снизить общие затраты на выполнение операций по инвентаризации.

2. Определение функциональных требований к ИС

Перед выбором конкретного CASE-средства предстоит сделать выбор методологии.

На сегодняшний день применяются две основные методологии - структурная и объектно-ориентированная [5].

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

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

Объектно-ориентированная декомпозиция рассматривает структуру объектов и связей между ними, а также поведение системы в терминах обмена сообщений между объектами.

Актуальность разработки объектно-ориентированной модели информационной подсистемы обуславливается применением языка UML (Unified Modeling Language).

В настоящее время существует несколько методологий объектно-ориентированной разработки прикладных программных систем [4]:

- OMT (Object Modeling Technique),

- SA/SD (Structured Analysis/Structured Design),

- JSD (Jackson Structured Development),

- OSA (Object-Oriented System Analysis).

Методология OMT опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора набора диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. В настоящее время OMTTool входит в состав системы Paradigm+.

В технологии OMT проектируемая программная система представляется в виде трех взаимосвязанных моделей:

1) объектной модели, которая представляет статические, структурные аспекты системы, в основном связанных с данными;

2) динамической модели, которая описывает работу отдельных частей системы;

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

Методология SA/SD содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов. Диаграммы потоков данных, составляющие основу методологии SA/SD, моделирует преобразования данных при их прохождении через систему.

В методологии SA/SD ведущей является функциональная модель, на втором месте по важности стоит динамическая модель и на последнем месте - объектная модель. Таким образом, в методологии SA/SD проектируемая система описывается с помощью процедур (процессов), что несколько противоречит объектно-ориентированному подходу. Методология OMT гораздо ближе к нему: в ней моделирование концентрируется вокруг объектной модели, т.е. вокруг объектов, из которых строится проектируемая система. Процедурная ориентированность методологии SA/SD является ее недостатком: системы, спроектированные по этой методологии, имеют четкую структуру.

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

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

Методология OSA, как и другие методологии, поддерживают три взаимно-ортогональных представления (модели) проектируемой системы:

- модель зависимостей между объектами;

- модель поведения объектов;

- модель взаимодействий объектов.

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

Для разработки информационной системы была разработана следующая технология проектирования:

- разработать диаграмму вариантов использования, на которой отобразить отношения, существующие между актерами и прецедентами;

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

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

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

Под выбранную технологию проектирования наиболее эффективным является выбор CASE-средства Rational Rose.

Rational Rose - CASE-средство, предназначенное для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. [12]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования.

В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов [12].

2.2 Формализация требований к новой системе