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

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

Размещено на http://www.allbest.ru/

Рисунок 4. Способы хранения товара

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

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

Партионно-сортовый метод. Каждая партия поступивших на склад товаров хранится отдельно. При этом внутри партии товары разбирают по наименованиям и сортам и также размещают отдельно.

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

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

Реализация

В розничной торговой сети продажу товаров покупателям подтверждают выдачей чека ККМ (контрольно-кассовой машины) и отражением выручки за день в книге кассира-операциониста. Но накладные при этом часто не оформляют, так как они не нужны клиентам. Тем не менее, учесть надо не только выручку, но и проданные товары. Очень часто можно увидеть продавца, записывающего эту информацию в тетрадку или на листочек. Между тем проданные товары в рознице нужно списывать на основании товарного отчета или накладной, ведь без этого невозможно определить себестоимость реализованного товара.

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

Документы материально-ответственного лица

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

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

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

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

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

Товарный отчет подписывают материально-ответственное лицо и бухгалтер, который принимает этот отчет. Утверждает отчет руководитель торговой организации или лицо, на которое возложены эти обязанности приказом руководителя [21,c.795].

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

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

Поступление товарно-материальных ценностей, от поставщиков на ответственное хранение (Рисунок 5).

Размещено на http://www.allbest.ru/

Где:

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

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

3. "Товарно-материальные ценности" - собственно партия товаров переданных на ответственное хранение.

4. "Склад" - Складские помещения организации, принявшей товар.

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

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

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

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

Теперь у кладовщика есть акт о замене и старая деталь, которая снова будет зачислена на склад как товарно-материальные ценности, взятые на ответственное хранение, о котором он делает запись в своем журнале и сохраняет этот акт в общей кипе документов. Обычно кладовщик в этот же день составляет еще один акт "О списании старой (-ых) детали (-ей)", запись о котором также поступает в журнал

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

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

У складского учета есть две главные цели:

1. контроль за сохранностью товаров;

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

Главную же цель, которую преследует будущая ИС, заключается в том, что бы избавить кладовщика от рутинной бумажной работы, которую он должен проводить каждый отчетный период по составлению отчета "Об учете материальных ценностей". Путем автоматизации ведения "Журнала складских операций" средствами ЭВМ. Затем при формировании отчетной формы этот шаблон загружается в некую объектную переменную и в процессе выполнения самой процедуры по формированию заполняется всеми необходимыми данными. Такой принцип позволит сделать независимую структуру всей ИС от диктуемых поставщиками правил ведения отчетности.

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

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

Чтобы реализовать этот не хитрый набор действий система как минимум должна состоять из трех основных модулей:

1. Сервер баз данных - модуль, в котором хранится, информационные ресурсы системы и производится поиск нужных данных по запросу сервера приложений (обработанному запросу пользователя);

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

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

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

Предположительно вся ИС будет состоять из четырех частей, а именно:

1. Реляционная база данных;

2. Сервер управления базой данных;

3. Клиентское приложение, которое одновременно будет выполнять несколько функций:

1. Предоставлять средства взаимодействия с сервером БД, для занесения всей необходимой информации;

2. Производить все необходимые операции по обработке вносимых данных;

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

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

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

В качестве инструмента для создания реляционной база данных, будет взята система управления реляционными базами данных (СУБД) MSSQL2000.

Эта система является кросс платформенным продуктом, поддерживающим большое количество различных операционных систем, таких как MSWindowsNT, 2000, 98/ME, XP, Linux и несколько Unix-платформ. MSSQLServer2005 отличается чрезвычайно низкими системными требованиями, высокой производительностью и легкостью администрирования. Для своей работы он может использовать несколько сетевых протоколов: TCP/IP, NetBEUI/namedippers, IPX/SPX.

Несмотря на свою простоту, этот сервер сочетает в себе огромный спектр возможностей. Одной из основных особенностей MSSQL2000 можно считать версионную архитектуру, которая обеспечивает уникальные возможности при многопользовательской работе - пишущие пользователи никогда не блокируют читающих. Помимо этого, версионная архитектура позволяет отказаться от использования протокола транзакций, который в других СУБД служит для восстановления базы данных после сбоев, поэтому MSSQL2000 обладает очень высокой надежностью и устойчивостью. Также в нем реализован механизм оптимистической блокировки на уровне записи. Это значит, сто сервер блокирует только те записи, которые реально были изменены пользователем, и не блокирует всю страницу данных целиком. Эта особенность еще больше снижает вероятность конфликтов при многопользовательском режиме работы. Собственно эта система и станет второй частью ИС Сервером управления базой данных. Клиентская же часть ИС написана на высокоуровневом языке программирования С++, в среде C++Builder 6.0 Из основных достоинствами этой среды, нужно выделить в первую очередь средства интерактивного создания форм и компонентов, мощные средства отладки, простота написания кодов и легко читаемость структуры процедур и функций будущей программы [13].

3. Проектирование организации информационно-справочной системы

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

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

Этап 1:

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

Вносятся ориентировочно след реквизиты:

1. внутренний идентификатор (автоматически);

2. название организации-поставщика;

3. его адрес;

4. прочее описание

Этап 2:

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

Вносятся ориентировочно след реквизиты:

1. внутренний идентификатор (автоматически);

2. наименование данной категории;

Этап 3:

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

Вносятся ориентировочно след реквизиты:

1. внутренний идентификатор (автоматически)

2. внешний идентификатор (код данного наименования в нутрии общей идентификации у поставщика);

3. наименование (согласно внутренней идентификации у поставщика);

4. признак принадлежности данного товара определенному поставщику;

5. признак тематической категории;

6. если необходимо единица размерности (по умолчанию "шт. ”);

7. цена 1-ой ед.;

8. прочее описание;

Этап 4: - операция "прихода" товара на склад:

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

2. текущая дата;

3. признак поставщика, из справочника поставщиков;

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

5. признак уникального кода для данного наименования;

6. цену;

7. количество поступившего товара;

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

1. дата операции;

2. характер операции (в данном случае приход);

3. признак поставщика;

4. код данного наименования;

5. само наименование;

6. цену;

7. количество поступившего товара;

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

1. выберет заготовленную ранее отчетную форму;

2. отсортирует из "журнала" данные, которые входят в выбранный отчетный период;

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

4. по первой записи (самая ранняя запись в отчетном периоде) внесет в подготавливаемый отчет остатки по данному наименованию на начало отчетного периода;

5. внесет по датам все проведенные операции с данным наименованием за выбранный период;

6. и отразит текущие остатки на складе по последней записи (самая поздняя запись в отчетном периоде) в журнале;

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

8. Вот собственно все первостепенные этапы, которые будущая ИС должна позволить произвести.

Логическая структура организации документооборота внутри системы, выглядит следующим образом:

Логическая структура документооборота в системе

Размещено на http://www.allbest.ru/

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

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

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

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

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

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

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

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

Главными элементами концептуальной модели данных являются объекты и отношения.

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

Объектное множество - множество вещей одного типа.

Отношение - связь между элементами двух объектных множеств.

Составное объектное множество отношение, рассматриваемое как объектное множество.

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

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

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

3.3 Разработка реляционной модели базы данных подсистемы

Рисунок 9. Диаграмма прецедентов актера "Администратор"

Рисунок 10. Диаграмма прецедентов актера "Пользователь"

Спецификация прецедентов

Прецедент: "Инициализация БД".

Актер: администратор.

Предусловие: БД для хранения информации не создана.

Постусловие: создана БД и таблицы для хранения учетной информации.

Основной поток: Администратор используя средства выбранной СУБД создает базу данных и таблицы для хранения учетной информации в соответствии с указаниями, приведенными в руководстве администратора.

Альтернативный поток: нет.

Прецедент: "Настройка конфигурационных файлов".

Актер: администратор.

Предусловие: Создана БД, серверное и/или клиентское приложение не запущено.

Постусловие: Старт серверного и/или клиентского приложения.

Основной поток: Администратор изменяет значения в конфигурационных файлах, указывая:

имя класса-драйвера для подключения к БД;

указание адреса СУБД и имени базы данных;

имя пользователя и пароль для подключения к базе данных.

Управление переходит прецеденту "Запуск приложения".

Альтернативный поток: нет.

Прецедент: "Настройка приложения".

Актер: администратор.

Предусловие: Создана БД, приложение не запущено.

Постусловие: Старт приложения системы.

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

Альтернативный поток: нет.

Прецедент: "Запуск приложения".

Актер: администратор.

Предусловие: Серверное и/или клиентское приложение не запущено, конфигурационные файлы настроены.

Постусловие: Успешный старт серверного и/или клиентского приложения.

Основной поток: Администратор запускает серверное и/или клиентское приложение. Приложение запускается, в окне отображается информация, полученная из базы данных.

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

Прецедент: "Просмотр справочной информации".

Актер: администратор, пользователь.

Предусловие: Серверное или клиентское приложение успешно запущено.

Постусловие: Окно справочной системы доступно пользователю.

Основной поток: Пользователь выбирает команду "Помощь". Инициализируется справочная система и ее данные становятся доступными пользователю.

Альтернативный поток: нет.

Прецедент: "Загрузка информационных данных".

Актер: пользователь.

Предусловие: Клиентское приложение успешно запущено.

Постусловие: Непрочитанные пользователем данные загружены в клиентское приложение.

Основной поток: Пользователь в окне клиентского приложения выбирает предоставленные ему действия. Система выводит предупреждающее сообщение. Пользователь нажимает ОК. Система загружает из базы данных непрочитанные пользователем данные и отображает их.

Альтернативный поток: В предупреждающем сообщении пользователь нажимает "ОK". И пользователь продолжает работу. Ошибки при вводе информационных данных обрабатываются, и не допускаются для записи в БД.

Прецедент: "Просмотр полученных данных".

Актер: пользователь.

Предусловие: Клиентское приложение успешно запущено, непрочитанные данные загружены.

Постусловие: нет.

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

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

Прецедент: "Создание записей в журнале"

Актер: пользователь.

Предусловие: Клиентское приложение успешно запущено.

Постусловие: Информация о созданной записи в журнале сохранена в БД.

Основной поток: Пользователь выбирает отдел, куда надо добавить товар на баланс выбирает команду "Добавить". В появившемся диалоговом окне нажимает ОК. Система заносит информацию о новой записи в журнал.

Альтернативный поток: Если пользователь в окне клиентского приложения выбирает команду ">>". Появиться окно для заполнения справочника по товарам или кафедрам. После его заполнения пользователь может вернуться назад для редактирования журнала.

Прецедент: "Удаление записей из журнала".

Актер: пользователь.

Предусловие: Серверное приложение успешно запущено.

Постусловие: Информация о записях успешно удалена из БД

Основной поток: Пользователь выбирает отдел откуда надо удалить товар с баланса, и выбирает команду "Удалить". В появившемся диалоговом окне нажимает ОК. Система удаляет информацию о записи из журнала.

Пользователь выбирает закладку, информацию о которой необходимо удалить и выбирает команду "Удалить закладку". В появившемся окне-предупреждении пользователь нажимает кнопку ОК. Система удаляет информацию о записи из журнала и обновляет окно клиентского приложения.

Альтернативный поток: Если пользователь в диалоговом окне удаления выбирает команду "Отмена", диалоговое окно закрывается, данные о операциях с записями остаются в журнале. Активным становится основное окно клиентского приложения.

Прецедент: "Просмотр данных через генератор отчетов".

Актер: пользователь.

Предусловие: приложение успешно отконфигурировано и запущено.

Постусловие: данные отображены пользователю.

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

Альтернативный поток: нет.

4. Экономическая часть

4.1 Технико-экономическое обоснование