Ведение бухгалтерского учета продаж продукции

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

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

Для формализации и описания бизнес процессов  была построена контекстная диаграмма IDEF0 «Деятельность компании» (см. Приложение 1). Диаграмма декомпозирована на три блока (см. Приложение 2).

Процесс «Деятельность компании» имеет:

Входной поток данных:

• Сопроводительная документация;
• Товар от поставщика;
• Заказы клиентов;

Выходной поток данных:

• Отгруженный товар;
• Товарно-транспортная накладная;
• Отчетность;
• Деньги поставщику;

Управление:

• Законодательство;
• Состояние рынка;

Механизмы:

• Сотрудники отдела продаж;
• Сотрудники склада;
• Сотрудники отдела закупок;

Декомпозиция диаграммы «Деятельность компании» состоит из трех процессов (см. Приложение 2):

• Закупка;
• Хранение;
• Продажа;

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

Получение запросов на товар

На данном этапе Отдел Продаж получает запросы на товар от заказчиков. Запрос на материал представляет собой внешнее сообщение отделу продаж о потребности в товаре. Запрос составляет основу последующих документов. В позициях запроса указываются следующие реквизиты:

• Идентификационный номер запроса;
• Дата отправки;
• Идентификационный номер;
• Краткое описание;

Регистрация полученных запросов на материал

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

Анализ полученных запросов  

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

Хранение

Хранение товаров на складе является одной из важнейших операций технологического процесса. Хранение товаров начинается после их приёма и перемещения на склад.

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

Продажа

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

Для моделирования архитектуры и поведения системы выбрано Rational Rose – семейство объектно-ориентированных CASE-средств, предназначенных для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта – возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

Рассмотрим процесс моделирования архитектуры и поведения системы при помощи языка UML. Для этого построим диаграмму вариантов использования. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).

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

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

Естественно, что представление будет неоднозначным, но методология UML этого не требует.

 

 

 

 

 

2.2Информационное  обеспечение системы учета продаж

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

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

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

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

На основании анализа входных и выходных данных предметной области, опишем атрибуты сущностей.

Входные данные:

• Информация по готовой продукции (полное наименование, дата изготовления, изготовитель, инвентарный номер, срок годности);
• данные о клиентах (ФИО,);
• заявка на получение готовой продукции (наименование товара, количество, цена, сумма).

Выходные данные:

• отчеты;

Информация, содержащая сведения о готовой продукции представлена в таблице 2.1.

Таблица 2.1.

Готовая продукция

Атрибуты	Тип	Примеры значений
номер	Число	{414 002 852 123 456}
Полное наименование	Дата	{Холодильник }
Дата изготовления	Дата	{10.01.2010 }
Изготовитель	Строка	{SONY}
Срок годности	Дата	{10.01.2010 }

 

 

Информация, содержащая сведения о сотрудниках, представлена в таблице 2.3.

Таблица 2.3.

Сотрудники

Атрибуты	Тип	Примеры значений
ФИО	строка	{Деловой Олег Петрович}
Должность	строка	{Продавец}

 

 

 

Информация, содержащая сведения об услуге на ремонт основных средств, представлена в таблице 2.5.

Таблица 2.5.

Продажа

Атрибуты	Тип	Примеры значений
Код товара	строка	{Продано }

 

Информация, содержащая сведения о заявке на получение готовой продукции представлена в таблице 2.6.

Таблица 2.6.

 

Заявка на получение готовой продукции

Атрибуты	Тип	Примеры значений
номер	Число	{414 002 852 123 456}
Полное наименование	Дата	{Холодильник }
Дата	Дата	{10.01.2010 }
Изготовитель	Строка	{SONY}
Срок годности	Дата	{10.01.2010 }
Количество	Число	{1}
Сумма	Число	{15000 }
Состояние	Строка	{доставлено}

 

 

 

 

2.3. Технология  работы с прототипом разрабатываемой  информационной системы

 

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

• справочники («Клиенты», «Номенклатура», «Сотрудники», «Склад»
• документы («Приходная накладная», «Продажа»
• регистр накопления («РегистрОстаткиТоваров»);
• отчет («Товары», «ОтчетОПродажах»).

 

Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов и в качестве серверов. Для более детальногоотраженияпоследовательностипередачи сообщений между объектамибыло использовано CASE-средство RationalRose (см. прил. 5.).

На данной диаграмме главным акцентом является последовательность приема/передачи сообщений.

В программе используются данные с акта о приеме-передаче объекта нематериальных активов. Форма акта (форма № НМА-1) - содержит сведения о поставщике и перечень поставленной продукции. Акт является основным документом, на основании которого заводятся записи в книге учета. С целью ускорения процесса ввода информации было решено не создавать отдельную форму для регистрации акта приемки-передачи, а внести всю информацию непосредственно в электронную форму (Поступление НМА).

При запуске программы появляется стартовое окно (см. рис. 1).

 

 

Рис.1 Стартовое окно

 

Входная и условно-постоянная информация отображается и хранится в справочниках. Используемые справочники представлены на рис. 2-5.

 

Рис. 2.Экранная форма справочника «Клиенты»

 

Рис. 3. Экранная форма справочника «Номенклатура»

 

Рис. 4. Экранная форма справочника «Сотрудники»

 

Рис. 5. Экранная форма справочника «Склад»

 

Данные по принятию товара и его продаже можно заполнить с помощью документов «Приходная накладная» и «Продажа»(см. рис. 6-7).

 

Рис. 6. Экранная форма «Приходная накладная»

 

Рис. 7. Экранная форма «Продажа»

 

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

 

Рис. 8. Экранная форма отчета «Список проданных товаров»

 

 

Рис.9. Экранная форма отчета «Товары»

 

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

 

ЗАКЛЮЧЕНИЕ

 

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

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

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

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

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