Автоматизация ведения расчетов с поставщиками

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

Стандарты ЕСПД в основном охватывают ту часть  документации, которая создается  в процессе разработки ПИ, и связаны, по большей части, с документированием функциональных характеристик ПИ. Следует отметить, что стандарты ЕСПД носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПИ (ГОСТ 34, Международному стандарту ISO/IEC, и др.).

Дело  в том, что в соответствии с  Законом РФ «О стандартизации» эти стандарты становятся обязательными на контрактной основе — то есть при ссылке на них в договоре на разработку (поставку) ПИ.

Говоря  о состоянии ЕСПД в целом, можно  констатировать, что большая часть  стандартов ЕСПД морально устарела.

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

Под автоматизированной системой расчетов с поставщиками подразумевается решение следующих задач:

• составление договоров с поставщиками
• оплата товара
• заказ новых товаров
• перечисление денежных средств на счет поставщика
• написание отчетности и тд.

Назначение разработки

Автоматизированная система предназначена для решения следующих задач:

1. хранение информации о поставщиках и товарах
2. заключение контрактов
3. учет излишек и недостачи товаров
4. заказ новых товаров
5. оплата товаров
6. составление отчетности

Требования к функциональным характеристикам

Система должна обеспечивать следующие функции:

1. ввод, вывод, редактирование, хранение, печать, экспорт в другие форматы информации о поставщиках:

• ФИО поставщика

• Наименование организации
• Адрес организации
• № лицевого счета
• № договора

2. ввод, вывод, редактирование, хранение, печать, экспорт в другие форматы информации о товаре:

• наименование
• производитель
• адрес производителя
• количество
• срок годности
• цена товара

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

• № договора
• Вид услуг
• Срок действия договора
• Срок оплаты за поставку товара

Входной информацией является:

1. бухгалтерская информация:

• информация о сроке действия договора клиента с поставщиком

• информация об оплате клиентом поставок товара, оговоренных в договоре

2. регистрационная информация:

• информация о необходимом товаре
• информация о сотрудниках магазина
• информация о поставщиках и их предложении

Выходной  информацией системы является:

1. отчеты
2. зачисление денежных средств на счет поставщика

Требования к надежности

Система должна:

• проводить контроль вводимой информации
• блокировать некорректные действия пользователя при работе с системой
• обеспечивать целостность

Требования к составу и параметрам технических средств

1. Настоящая система должна работать на процессорах совместимых с процессором IBM.
2. Оперативная память на каждой ЭВМ, не менее 32 Мб.
3. Сетевые карты.
4. Необходимо наличие видеокарты не менее 32 Мб на ЭВМ клиента.
5. Мышь. Клавиатура на ЭВМ.
6. Свободное место на жестком диске не менее 12Мб. А так же место для хранения баз данных.

Требования к информационной и  программной совместимости

Система должна работать под управлением  ОС семейства Win32. Система должна работать под управлением ОС семейства Win32.

Требования к программной документации

Программная документация должна содержать следующие  документы (см. ГОСТ 19.101-77):

1.Программные  документы:

• Спецификация (ГОСТ 19.202-78);
• Текст программы (ГОСТ 19.401-78);
• Описание программы (ГОСТ 19.402-78);
• Пояснительная записка (ГОСТ 19.404-79);

2.Эксплуатационные  документы:

• Ведомость эксплуатационных документов (ГОСТ 19.507-79);
• Формуляр (ГОСТ 19.501-78);
• Описание применения (ГОСТ 19.502-78);
• Руководство системного программиста (ГОСТ 19.503-79);
• Руководство программиста (ГОСТ 19.504-79);
• Руководство оператора (ГОСТ 19.505-79);

Требования  к перечисленным документам не отличаются от требований, определенных в ЕСПД.

Стадии и этапы разработки

 

Таблица 1. «План разработки»

этапы реализации проекта	февраль		март	апрель	май
разработка ПО
1. техническое задание
2. эскизный проект
3. технический проект
4. рабочий проект

 

3. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ

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

Средство  функционального моделирования  BPwin применяет такие методологии как: IDEF0, IDEF3 и DFD.

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

Методология функционального моделирования  IDEF0 – это технология описания системы в целом как множества взаимозависимых действий, или функций.

Обычно  IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах разработки проекта. Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.

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

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

 

Рис.1. «Контекстная диаграмма».

 

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

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

Влияя на работу блока, оно непосредственно не потребляется и не трансформируется в результате

Управлением в данной подсистеме являются:

- правила  составления документов и накладные.

Механизмы являются ресурсом, который непосредственно исполняет моделируемое действие.

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

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

Следующая диаграмма более детально показывает разрабатываемый бизнес-процесс (рис.2.).

 

Рис.2. «Подсистема  учета расчетов с поставщиками».

 

Функциональный  блок «систематизация учета расчетов с поставщиками» разбивается  на 4 составляющие – блоки, которые  в дальнейшем декомпозируются:

1.подписать  договоры с поставщиками.

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

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

 

Рис.3. «Декомпозиция блока «Подписать договоры с поставщиками».

 

2.обработать  информацию в договорах.

Полученный  договор обрабатывается бухгалтером  в соответствии с накладными.

После выполнения этого блока заказываются новые  товары, а так же выходной информацией  является № лицевого счета поставщика (рис.4).

 

 

Рис.4. «Декомпозиция  блока «Обработать информацию в  договорах».

 

1. оплатить договор.

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

После их обработки бухгалтер выдает платежный  документ и переводит на счет поставщика денежные средства.

Этот  процесс изображен на рисунке 5.

 

Рис.5. «Декомпозиция  блока «Оплатить договор».

 

 

составить отчет.

Отчет составляется бухгалтером на основе платежного документа  и данных из накладных (рис.6.).

 

Рис.6. «Декомпозиция  блока «Составить отчет».

 

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

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

IDEF3 не  имеет жестких синтаксических  или семантических ограничений.

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

При помощи этого метода были описаны следующие  процессы:

2. проверить количество излишек и их недостаток товаров в наличии.

Этот  процесс показан на рисунке 7.

 

Рис.7. «Процесс проверки количества излишек и их недостатка товаров в наличии».

 

3. занести данные в платежные документы.

На рисунке  8 соединение J2 показывает, каким образом будет проводиться расчет с поставщиками.

 

Рис.8. «Занесение данных в платежные документы».