Учет бартерных операций

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

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

1.1 Анализ предметной области

Постановка задачи. Бартерные или товарообменные операции между предприятиями предполагают учет взаимных поставок по стоимости отгружаемых товаров в документе «Журнал бартерных операций».

Необходимо учесть следующие обстоятельства:

в каждой записи журнала заполняется только одна из двух граф «Отгружено...» и «Получено…»;

не все контрагенты из справочника могут быть упомянуты в журнале;

не все товары могут принимать участие в проведенных на данный момент операциях.

Пример журнала бартерных операций.

Таблица 1 Журнал бартерных операций

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

ведение списка товаров;

ведение списка контрагентов;

ведение списков ТТН;

ведение архива журналов бартерных операций.

Необходимо предусмотреть:

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

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

определение рисков, условных сроков и штрафов;

определение неэффективности сделки;

подсчёт суммы денежных средств, полученных от контрагентов за отгруженный товар;

ведение бюджета в организации, ведение календаря;

1.2 Построение модели в AllFusion Process Modeler

Рисунок 1 Модель IDEF0

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

справочник товаров;

справочник контрагентов;

журнал операций.

Используются следующие механизмы для ведения учета операций:

отдел снабжения используется для получения и отгрузки товаров;

информационные системы используются для автоматизации процесса ведения учета бартерных операций;

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

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

Из рисунка 2 видно, что диаграмму IDEF0 можно декомпозировать следующим образом, т.е. выделить функциональные блоки:

определить операцию, производимую между организацией и контрагентом;

выписать/получить ТТН;

получить/отгрузить товар;

оплатить платежное поручение/выписать платежное поручение;

записать операцию в журнал операций.

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

Рисунок 3 Диаграмма DFD

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

Товар;

Контрагенты;

Журнал операций.

1.3 Выделение сущностей, выявление связей между сущностями

Итак, мы выделили 3 сущности: Товар, Контрагенты, Журнал операций. Выделим основные атрибуты для каждой сущности, исходя из таблицы 1:

Товар (НаимТовара, ЕдИзм, Цена);

Контрагенты (НаимКонтрагента);

Журнал операций (ДатаОперации, НаимТовара, ЕдИзм, Отгружено/Получено, Количество, Стоимость, НаимКонтрагента).

Рисунок 4 Диаграмма Чена

Из рисунка 4 видно, что мы отразили 3 основные сущности, определили показатели кардинальности связи. Показатели кардинальности связи мы определили на основании рисунка 5 и рисунка 6.

бартерный учет товарообменный

Рисунок 5 Показатели кардинальности и класс принадлежности связи для сущностей Товар и Журнал операций

Рисунок 6 Показатели кардинальности и класс принадлежности связи для сущностей Контрагент и Журнал операций

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

Для сущности Товар мы не можем выбрать первичный ключ НаимТовара, поэтому в качестве первичного ключа введем атрибут - КодТовара. Для сущности Контрагенты введем первичный ключ - КодКонтрагента, а для Журнала операций - НомерЖурнала.

Теперь мы получим следующие более правильные сущности:

Товар (КодТовара, НаимТовара, ЕдИзм, Цена);

Контрагенты (КодКонтрагента, НаимКонтрагента);

Журнал операций (НомерЖурнала, ДатаОперации, НаимТовара, ЕдИзм, Отгружено/Получено, Количество, Стоимость, НаимКонтрагента).

Таким образом, мы получим нормализованную модель Чена, которая представлена на рисунке 7.

Рисунок 7 Нормализованная диаграмма Чена

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

Логическое проектирование применяется для перенесения концептуального проекта на внутреннюю модель выбранной СУБД. При этом все объекты концептуальной модели отображаются на модель с определенной структурой, которая используется выбранным программным обеспечением. Для реляционной СУБД логическое проектирование заключается в проектировании таблиц, индексов, представлений, транзакций, авторизации доступа и т.д.

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

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

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

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

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

Данная модель соответствует второму условию нормализации.

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

Данная модель соответствует третьей нормальной форме.

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

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

КодТовара - {НаимТовара, ЕдИзм, Цена}.

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

Сущности Контрагенты, Журнал операций соответствуют всем трем нормальным формам.

Таким образом, на основе приведения модели к третьей нормальной форме, можно приступить к построению данной модели в ERWin.

Рисунок 8 Сущности, их атрибуты и связи между сущностями модели данных

Рисунок 9 Нормализованная модель данных со связями

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

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

Рисунок 8 Физическая модель данных

Размещено на Allbest.ru