Проектирование реализации операций бизнес-процесса «Взаиморасчеты с поставщиками
Содержание:
Введение
Целью данной работы является разработка и реализация системы, обеспечивающей автоматизацию процесса взаиморасчетов с поставщиками. Внедрение системы упростит работу специалистов отдела закупок и бухгалтерии, а также избавит их от излишнего объёма документации и сделает менее трудоёмкой.
Разработанная база данных объединяет в себе все сведения необходимые для систематизации и упорядочения процесса работы.
Представлена и описана концептуальная модель базы данных, включающая в себя описание информационных объектов и связей между ними, а также описаны ограничения целостности.
Построена реляционная модель базы данных, представлен набор схем отношений с указанием первичных ключей, а также связей между отношениями.
Выполнено физическое проектирование базы данных «Взаиморасчеты с поставщиками» в среде MS Access.
Аналитическая часть.
Выбор комплекса задач автоматизации.
При проведении взаиморасчетов с поставщиками существуют следующие входные информационные потоки:
- сведения о поставщиках продукции;
- сведения о товарах, поставляемых поставщиками;
- приходные накладные;
- счета на оплату от поставщиков;
- выписки с расчетного счета банка об оплате или неоплате по счетам.
Выходные информационные потоки:
- справочник поставщиков;
- справочник товаров;
- сальдо взаиморасчетов с поставщиками;
- запросы и отчеты о взаиморасчетах с поставщиками.
Начальные границы рассматриваемой задачи – поступление товаров, получение счетов на оплату. Конечные границы – оплата счетов, сальдо взаиморасчетов с поставщиками.
Взаиморасчеты с поставщиками непосредственно взаимосвязаны с решением следующих задач:
- учет денежных средств;
- учет затрат на производство;
- сводный бухгалтерский учет и отчетность;
- бухгалтерский учет по прочим счетам.
Учет взаиморасчетов с поставщиками является важным элементом в системе бухгалтерского учета. Основными задачами этого учета являются:
- формирование полной и достоверной информации о состоянии расчетов с поставщиками за товарно-материальные ценности, выполненные работы и услуги, необходимой внутренним пользователям, руководителям и другим пользователям бухгалтерской отчетности;
- обеспечение информацией для контроля за соблюдением законодательства при осуществлении хозяйственных операций;
- предотвращение отрицательных результатов хозяйственной деятельности;
- исключение просроченной дебиторской и кредиторской задолженности.
В процессе осуществлении взаиморасчетов с поставщиками участвуют бухгалтера, специалисты по закупкам, менеджеры складов.
Перечень результатных показателей, рассчитываемых на базе использования совокупности исходных показателей в процессе выполнения этих функций:
- данные накладной при получении товаров, сумма накладной, дата, детализированная информация по каждому товару указанному в накладной;
- данные платежного поручения на оплату счетов поставщиков;
- данные журнала операций;
- данные карточки взаиморасчетов;
- данные сальдо взаиморасчетов с поставщиками;
- справки и отчеты по запросам пользователей.
Перечень используемых входных документов (файлов), в которых содержатся первичные показатели:
- справочник поставщиков;
- справочник товаров;
- счета поставщиков на оплату;
- накладная приема товаров на складе;
- выписка с расчетного счета банка об оплате поставщикам.
Перечень результатных документов (файлов), в которых отражаются результатные показатели:
- журнал операций;
- карточки взаиморасчетов;
- сальдо взаиморасчетов с поставщиками;
- справки и отчеты по запросам пользователей.
Регламент исполнения бизнес-процесса выглядит следующим образом:
- менеджер отдела закупок ежедневно получает от поставщика медикаментов счет на оплату, регистрирует его в реестре счетов поставщиков и передает счет поставщика бухгалтеру;
- бухгалтер на основании счета поставщика ежедневно формирует платежное поручение на оплату и передает платежное поручение в банк;
- бухгалтер на основании выписки с расчетного счета банка выполняет соответствующую бухгалтерскую проводку;
- менеджер склада обеспечивает приемку товара на склад;
- менеджер отдела закупок при поступлении товара и (или) при оплате делает запись о поступлениях и оплат;
- бухгалтер в конце каждого месяца выводит сальдо взаиморасчетов с клиентами;
- менеджер отдела закупок по запросу руководства и служб составляет справки и отчеты по взаиморасчетам с поставщиками.
Характеристика существующих бизнес – процессов.
Для описания бизнес - процесса взаиморасчетов с поставщиками выбрана функциональная модель IDEF0, которая представляет методологию и графическую нотацию, предназначенную для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временна́я последовательность (WorkFlow). Также отображаются все сигналы управления. Данная модель является одной из самых прогрессивных моделей и используется при организации бизнес проектов и проектов, основанных на моделировании всех процессов, как административных, так и организационных. Первоначально построена контекстная диаграмма. Основной блок в данной работе можно назвать «Взаиморасчеты с поставщиками». На вход модели будут идти данные о поставщиках, товарах, накладные на товары, счета на оплату. Организация учета будет осуществляться с помощью сотрудников бухгалтерии и отдела закупок. Все действия регламентируются в соответствии с правилами бухгалтерского учета и методиками расчета. Выходом системы являются выписки из банка об оплате счетов, отчеты и справки.
Контекстная диаграмма представлена на рисунке 1.
Рисунок 1. Контекстная диаграмма
После разработки контекстной диаграммы ее нужно декомпозировать. Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы, имеющие общую родительскую работу.
Декомпозируя контекстную диаграмму, можно выделить 4 этапа рассматриваемого процесса:
- составление справочников поставщиков и товаров;
- формирование платежных поручений;
- оплата счетов;
- составление отчетов и справок.
Диаграмма декомпозиции моделируемой системы приведена на рисунке 2.
Рисунок 2. Диаграмма декомпозиции моделируемой системы
На этапе «Создание справочников и поставщиков» отделом закупок совместно с бухгалтерией на основании собранной информации о поставщиках и товарах создаются и в дальнейшем постоянно ведутся справочники поставщиков и товаров.
На этапе «Формирование платежных поручений» отделом закупок ежедневно регистрируются счета поставщиков на оплату и накладные о поступлении товаров. Бухгалтерия на основании этой информации и справочников формирует платежные поручения и передает их в банк.
На этапе «Оплата счетов» бухгалтерия передает платежное поручение в банк и на основании выписки из банка фиксирует оплату.
На этапе «Составление отчетов и справок» отделом закупок и бухгалтерией составляются различные отчеты и справки.
Характеристика документооборота, возникающего при решении задачи.
Схема документооборота справочника поставщиков приведена в таблице 1.
Таблица 1
Схема документооборота справочника поставщиков
|
Действие |
Исполнитель |
|
Использование справочника при составлении платежных поручений |
Отдел закупок, бухгалтерия |
|
Использование справочника при оплате счетов |
Отдел закупок, бухгалтерия |
|
Использование справочника при составлении справок и отчетов |
Отдел закупок, бухгалтерия |
Схема документооборота справочника товаров приведена в таблице 2.
Таблица 2
Схема документооборота справочника товаров
|
Действие |
Исполнитель |
|
Использование справочника при составлении платежных поручений |
Отдел закупок, бухгалтерия |
|
Использование справочника при оплате счетов |
Отдел закупок, бухгалтерия |
|
Использование справочника при составлении справок и отчетов |
Отдел закупок, бухгалтерия |
Схема документооборота счетов на оплату приведена в таблице 3.
Таблица 3
Схема документооборота счетов на оплату
|
Действие |
Исполнитель |
|
Поступление в отдел закупок |
Отдел закупок |
|
Контроль счета и передача в бухгалтерию |
Отдел закупок |
|
Использование при формировании платежного поручения |
Бухгалтерия |
|
Использование при составлении справок и отчетов |
Отдел закупок, бухгалтерия |
Схема документооборота счетов на оплату приведена в таблице 4.
Таблица 4
Схема документооборота накладных приема товара
|
Действие |
Исполнитель |
|
Поступление в отдел закупок |
Отдел закупок |
|
Контроль накладной и передача в бухгалтерию |
Отдел закупок |
|
Использование при формировании платежного поручения |
Бухгалтерия |
|
Использование при составлении справок и отчетов |
Отдел закупок, бухгалтерия |
Схема документооборота выписки с расчетного счета приведена в таблице 5.
Таблица 5
Схема документооборота выписки с расчетного счета
|
Действие |
Исполнитель |
|
Поступление в бухгалтерию |
Бухгалтерия |
|
Выполнение бухгалтерских проводок |
Бухгалтерия |
Обоснование проектных решений по информационному обеспечению.
В соответствии с описанием бизнес – процесса «Взаиморасчеты с поставщиками» система должна обеспечивать следующие функции:
- ввод, вывод, редактирование, хранение информации о поставщиках:
- наименование организации
- адрес организации
- ИНН
- расчетный счет
- ввод, вывод, редактирование, хранение, информации о товаре:
- наименование
- единица измерения
Входной информацией является:
- информация о поступлении товаров на склад
- информация о выставленных счетах на оплате
- информация об оплате поступившего товара
- информация об оплате по поступившим счетам
- информация об авансовых платежах
Выходной информацией системы является:
- карточки взаиморасчетов с поставщиками
- сальдо взаиморасчетов с поставщиками
Перечень и содержание экранных форм, необходимых для решения задачи:
- главная форма, содержащая меню режимов функционирования;
- форма «Поставщики» для ввода и редактирования информации о поставщиках;
- форма «Товары» для ввода и редактирования информации о товарах;
- составная форма «Приход и оплата товаров», включающая в себя подчиненные формы «Поступление товара» и «Оплата товара»;
- составная форма «Поступление и оплата счетов», включающая в себя подчиненные формы «Товары по счету» и «Оплата по счету»;
- форма «Авансовые платежи» для ввода и редактирования информации об авансовых платежах;
- форма «Карточка взаиморасчетов» для формирования и вывода информации о поступлении товаров и платежах по выбранному поставщику и заданному периоду;
- форма «Сальдо взаиморасчетов» для формирования и вывода информации о поступлении товаров и платежах по всем поставщикам по заданному периоду.
Состав файлов, необходимых для решения задачи:
- файл, содержащий информацию о поставщиках;
- файл, содержащий информацию о товарах;
- файл, содержащий основные сведения о накладной на товары, и связанный с ним файл, содержащий информацию о товарах, поступивших согласно этой накладной;
- файл, содержащий информацию об оплате поступивших товаров;
- файл, содержащий основные сведения о выставленном счете, и связанный с ним файл, содержащий информацию о товарах, перечисленных в счете;
- файл, содержащий информацию об оплате по выставленному счету поставщика;
- файл, содержащий выходную информацию по карточке взаиморасчетов;
- файл, содержащий выходную информацию по сальдовой ведомости.
Наиболее целесообразным для решения данной задачи является использование реляционной системы управления базами данных.
Обоснование проектных решений по программному обеспечению.
Наиболее целесообразным является физическая реализация всей задачи в среде MS Access. При разработке электронного журнала в школе была выбрана настольная СУБД (система управления базами данных) реляционного типа MS Access. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать приложения, используя встроенные средства.
В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам, как и положено реляционной СУБД. К этим данным относится не только информация в таблицах, но и другие объекты базы данных, которые будут описаны ниже.
Для выполнения почти всех основных операций Access предлагает большое количество Мастеров (Wizards), которые делают основную работу за пользователя при работе с данными и разработке приложений, помогают избежать рутинных действий и облегчают работу неискушенному в программировании пользователю.
Проектная часть.
Информационная модель и ее описание.
Для решения данной задачи применяется информационная модель баз данных под названием "сущность-связь" (entity-relationship), которая также известна как ER-диаграмма.
Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Результатом второго этапа является готовая база данных либо DDL-скрипт для ее создания.
Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность.
Одной из основных частей информационного обеспечения является информационная база, которая представляет собой совокупность данных, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).
Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО). Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущности Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address. Каждая сущность должна быть полностью определена с помощью текстового описания. Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя). В IDEFIX могут быть выражены следующие мощности связей:
- каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;
- каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
- каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
- каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «Клиент размещает заказ» («A customer places an order» — этой фразой вполне можно описать связь, изображенную на рис. 1), где существительными являются названия связанных между собой сущностей. Подавляющее большинство средств проектирования данных позволяют создавать ER-диаграммы визуально, изображая сущности и соединяя их связями с помощью мыши. Интерфейс таких средств нередко настолько прост, что позволяет освоить логическое проектирование данных не только разработчику, но и пользователю-непрограммисту, если таковой участвует в проектировании данных как эксперт в предметной области.
На основании анализа предметной области выделены сущности и определены атрибуты. Перечень сущностей и входящих в них атрибутов приведен в таблице 6.
Таблица 6
Сущности и атрибуты
|
Сущности |
Атрибуты |
|
Поставщики |
Код поставщика Наименование Адрес ИНН Расчетный счет |
|
Товары |
Код товара Наименование Единица измерения |
|
Накладные |
Номер документа Дата Поставщик |
|
Поступление товара |
Накладная Товар Цена за единицу Количество |
|
Оплата по накладной |
Регистрационный номер Накладная Дата оплаты Сумма |
|
Счета на оплату |
Номер документа Дата Поставщик |
|
Товары по счету |
Счет Товар Цена за единицу Количество |
|
Оплата по счетам |
Регистрационный номер Счет Дата оплаты Сумма |
|
Авансы |
Регистрационный номер Поставщик Дата Сумма |
В каждой сущности можно выделить первичные ключи:
- для сущности Поставщики атрибут Код поставщика,
- для сущности Товары атрибут Код товара,
- для сущности Накладные атрибут Номер документа,
- для сущности Поступление товара составной ключ: атрибуты Накладная, Товар,
- для сущности Оплата по накладной атрибут Регистрационный номер,
- для сущности Счета на оплату атрибут Номер документа,
- для сущности Товары по счету составной ключ: атрибуты Счет, Товар,
- для сущности Оплата по счетам атрибут Регистрационный номер,
- для сущности Авансы атрибут Регистрационный номер.
Для повышения эффективности функционирования базы данных целесообразно применить для всех сущностей суррогатные ключи коды, в нашем случае это Код поставщика, Код товара.
Как правило, суррогатный ключ – это числовое поле (порядковый номер). Его использование дает следующие преимущества:
- неизменность,
- гарантированная уникальность,
- гибкость,
- эффективность.
Перечень связей между сущностями приведен в таблице 7.
Таблица 7
Связи и атрибуты
|
Связь |
Атрибут связи |
|
Поставщики и Накладные |
Передают товар по накладным |
|
Поставщики и Счета на оплату |
Выставляют счета на оплату |
|
Накладные и Поступление товара |
Включают в себя перечень товаров |
|
Накладные и Оплата по накладным |
Оплачиваются |
|
Товары и Поступление товара |
Поступают по накладным |
|
Счета на оплату и Товары по счету |
Включают в себя перечень товаров |
|
Счета и Оплата по счетам |
Оплачиваются |
|
Товары и Товары по счетам |
Включены в счет |
|
Поставщики и Авансы |
Получают авансы |
На основании анализа исходных данных и информационных потоков можно сделать следующие выводы:
1. Каждая накладная в соответствии с принятой структурой может относиться только к одному поставщику, в то же время один поставщик может поставлять товары по нескольким накладным, кроме того, отдельные поставщики могут вообще не поставлять товар. Следовательно, для связи Поставщики – Накладные степень связи 1:n (один ко многим), класс принадлежности сущности Поставщики – необязательный, сущности Накладные – обязательный.
2. Каждый счет на оплату в соответствии с принятой структурой может относиться только к одному поставщику, в то же время один поставщик может выставлять несколько счетов, кроме того, отдельные поставщики могут вообще не выставлять счетов. Следовательно, для связи Поставщики – Счета на оплату степень связи 1:n (один ко многим), класс принадлежности сущности Поставщики – необязательный, сущности Счета на оплату – обязательный.
3. Каждое поступление товара в соответствии с принятой структурой может проводиться только по одной накладной, в то же время по одной накладной могут поступать несколько товаров. Следовательно, для связи Накладные – Поступление товара степень связи 1:n, класс принадлежности сущности Накладные – необязательный, сущности Поступление товара – обязательный.
4. Каждое оплата по накладной в соответствии с принятой структурой может проводиться только по одной накладной, в то же время по одной накладной могут производиться несколько оплат. Следовательно, для связи Накладные – Оплата по накладным степень связи 1:n, класс принадлежности сущности Накладные – необязательный, сущности Оплата по накладным – обязательный.
5. Каждое поступление товара в соответствии с принятой структурой может проводиться только для одного товара, в то же время один товар может поступать неоднократно в разное время. Следовательно, для связи Товары – Поступление товара степень связи 1:n, класс принадлежности сущности Товары – необязательный, сущности Поступление товара – обязательный.
6. Каждый товар по счету в соответствии с принятой структурой может указываться только в одном счете, в то же время по одному счету могут указываться несколько товаров. Следовательно, для связи Счета на оплату – Товары по счету степень связи 1:n, класс принадлежности сущности Счета на оплату – необязательный, сущности Товары по счету – обязательный.
7. Каждое оплата по счету в соответствии с принятой структурой может проводиться только по одному счету, в то же время по одному счету могут производиться несколько оплат. Следовательно, для связи Счета на оплату – Оплата по счету степень связи 1:n, класс принадлежности сущности Счета на оплату – необязательный, сущности Оплата по счету – обязательный.
8. Каждый товар по счету в соответствии с принятой структурой может указываться только для одного товара, в то же время один товар может указываться в разных счетах. Следовательно, для связи Товары – Товары по счету степень связи 1:n, класс принадлежности сущности Товары – необязательный, сущности Товары по счету – обязательный.
9. Каждая выплата аванса в соответствии с принятой структурой может производиться только для одного поставщика, в то же время один поставщик может получать в разные авансы. Следовательно, для связи Поставщики – Авансы степень связи 1:n, класс принадлежности сущности Поставщики – необязательный, сущности Авансы – обязательный.
На рисунке 7 представлена логическая модель данных.
Рисунок 3. Логическая модель данных.
Для всех связей установлена степень связи 1:n и класс принадлежности n-связной сущности обязательный. Следовательно, для построения предварительных отношений используются следующие правила:
- необходимы два отношения;
- ключами отношений являются ключи сущности;
- ключ односвязной сущности должен быть добавлен как атрибут в отношение для n-связной сущности.
Перечень отношений с учетом суррогатных ключей представлен в таблице 8.
Таблица 8
Перечень отношений и атрибутов
|
Отношения |
Атрибуты |
|
Поставщики |
Код поставщика Наименование Адрес ИНН Расчетный счет |
|
Накладные |
Номер документа Дата Поставщик |
|
Авансы |
Регистрационный номер Дата Поставщик Сумма |
|
Поступление товара |
Накладная Товар Цена за единицу Количество |
|
Оплата по накладным |
Регистрационный номер Накладная Дата оплаты Сумма |
|
Счета на оплату |
Номер документа Дата Поставщик |
|
Товары по счету |
Счет Товар Цена за единицу Количество |
|
Оплата по счетам |
Регистрационный номер Счет Дата оплаты Сумма |
|
Товары |
Код товара Наименование Единица измерения |
Ключевые поля почеркнуты. Курсивом выделены атрибуты n-связной сущности, соответствующие значению первичного ключа односвязной сущности.
На основании логической модели данных создана физическая модель с учетом конкретной системы управления базами данных (СУБД) Access. Физическая модель представлена на рисунке 4.
Рисунок 4. Физическая модель данных.
Характеристика базы данных.
-
-
- Таблицы базы данных.
-
В базе данных заполнение таблиц должно выполняться только через разработанные формы. Нарушение этого правила может привести к потере информации. Перечень таблиц с указанием полей и их свойств приведен на рисунках 5-15.
Рисунок 5. Структура таблицы «Авансы»
Рисунок 6. Структура таблицы «Карточка взаиморасчетов»
Рисунок 7. Структура таблицы «Накладные»
Рисунок 8. Структура таблицы «Обороты»
Рисунок 9. Структура таблицы «Оплата по накладным»
Рисунок 10. Структура таблицы «Оплата по счетам»
Рисунок 11. Структура таблицы «Поставщики»
Рисунок 12. Структура таблицы «Поступление товара»
Рисунок 13. Структура таблицы «Счета на оплату»
Рисунок 14. Структура таблицы «Товары»
Рисунок 15. Структура таблицы «Товары по счету»
-
-
- Запросы.
-
Запросы в Access являются основным инструментом выборки, обновления и обработки данных в таблицах базы данных. Access в соответствии с концепцией реляционных баз данных для выполнения запросов использует язык структурированных запросов SQL (Structured Query Language). С помощью инструкций языка SQL реализуется любой запрос в Access.
Ниже приводятся тексты SQL-выражений запросов.
- Запрос «Авансовые платежи».
SELECT Поставщики.[Код поставщика], Поставщики.Наименование, Авансы.Дата, 'Авансовый платеж' AS Выражение2, Авансы.Сумма
FROM Поставщики INNER JOIN Авансы ON Поставщики.[Код поставщика] = Авансы.Поставщик
ORDER BY Поставщики.[Код поставщика], Поставщики.Наименование, Авансы.Дата, 'Авансовый платеж';
- Запрос «Итоги по накладным».
SELECT Поставщики.[Код поставщика], Поставщики.Наименование, Накладные.Дата, 'Накладная № ' & [Номер документа] AS Выражение2, Sum([Поступление товара]![Цена за единицу]*[Поступление товара]![Количество]) AS Выражение1
FROM Поставщики INNER JOIN (Накладные INNER JOIN [Поступление товара] ON Накладные.[Номер документа] = [Поступление товара].Накладная) ON Поставщики.[Код поставщика] = Накладные.Поставщик
GROUP BY Поставщики.[Код поставщика], Поставщики.Наименование, Накладные.Дата, 'Накладная № ' & [Номер документа]
ORDER BY Поставщики.[Код поставщика], Поставщики.Наименование, Накладные.Дата, 'Накладная № ' & [Номер документа];
- Запрос «Итоги по оплате по накладным».
SELECT Поставщики.[Код поставщика], Поставщики.Наименование, Накладные.Дата, 'Оплата по накладной № ' & [Номер документа] AS Выражение2, Sum([Оплата по накладным]![Сумма]) AS Выражение1
FROM (Поставщики INNER JOIN Накладные ON Поставщики.[Код поставщика] = Накладные.Поставщик) INNER JOIN [Оплата по накладным] ON Накладные.[Номер документа] = [Оплата по накладным].Накладная
GROUP BY Поставщики.[Код поставщика], Поставщики.Наименование, Накладные.Дата, 'Оплата по накладной № ' & [Номер документа]
ORDER BY Поставщики.[Код поставщика], Поставщики.Наименование, Накладные.Дата, 'Оплата по накладной № ' & [Номер документа];
- Запрос «Итоги по оплате по счетам».
SELECT Поставщики.[Код поставщика], Поставщики.Наименование, [Счета на оплату].Дата, 'Оплата по счету № ' & [Номер документа] AS Выражение2, Sum(([Оплата по счетам]![Сумма])) AS Выражение1
FROM (Поставщики INNER JOIN [Счета на оплату] ON Поставщики.[Код поставщика] = [Счета на оплату].Поставщик) INNER JOIN [Оплата по счетам] ON [Счета на оплату].[Номер документа] = [Оплата по счетам].Счет
GROUP BY Поставщики.[Код поставщика], Поставщики.Наименование, [Счета на оплату].Дата, 'Оплата по счету № ' & [Номер документа]
ORDER BY Поставщики.[Код поставщика], Поставщики.Наименование, [Счета на оплату].Дата, 'Оплата по счету № ' & [Номер документа];
- Запрос «Итоги по счетам».
SELECT Поставщики.[Код поставщика], Поставщики.Наименование, [Счета на оплату].Дата, [Счета на оплату].[Номер документа], Sum(([Товары по счету]![Цена за единицу]*[Товары по счету]![Количество])) AS Выражение1
FROM (Поставщики INNER JOIN [Счета на оплату] ON Поставщики.[Код поставщика] = [Счета на оплату].Поставщик) INNER JOIN [Товары по счету] ON [Счета на оплату].[Номер документа] = [Товары по счету].Счет
GROUP BY Поставщики.[Код поставщика], Поставщики.Наименование, [Счета на оплату].Дата, [Счета на оплату].[Номер документа]
ORDER BY Поставщики.[Код поставщика], Поставщики.Наименование, [Счета на оплату].Дата, [Счета на оплату].[Номер документа];
- Запрос «Сальдо».
SELECT *
FROM [Итоги по накладным]
UNION SELECT *
FROM [Итоги по оплате по накладным]
UNION SELECT *
FROM [Итоги по оплате по счетам]
UNION SELECT *
FROM [Авансовые платежи];
-
-
- Формы.
-
Форма — это объект БД, предназначенный для ввода и отображения информации. Формы позволяют выполнить проверку корректности данных при вводе, проводить вычисления, обеспечивают доступ к данным в связанных таблицах с помощью подчиненных форм.
Ниже приводятся формы базы данных.
Рисунок 16. Главная форма «Взаиморасчеты с поставщиками»
Рисунок 17. Форма «Поставщики»
Форма создана с помощью Мастера. Источником информации для формы является таблица «Поставщики».
Рисунок 18. Форма «Товары»
Форма создана с помощью Мастера. Источником информации для формы является таблица «Товары».
Рисунок 19. Составная форма «Накладные»
Форма создана с помощью Мастера. Источником информации для основной формы является таблица «Накладные», для подчиненных форм – таблицы «Поступление товара» и «Оплата по накладным».
Рисунок 20. Составная форма «Счета на оплату»
Форма создана с помощью Мастера. Источником информации для основной формы является таблица «Счета на оплату», для подчиненных форм – таблицы «Товары по счету» и «Оплата по счетам».
Рисунок 21. Форма «Авансы»
Форма создана с помощью Мастера. Источником информации для формы является таблица «Авансы».
Рисунок 22. Форма «Карточка взаиморасчетов»
Форма создана в режиме конструктора. После заполнения периода, выбора поставщика и нажатия кнопки «Отчет» последовательно выполняются запросы «Итоги по накладным», «Итоги по оплате по накладным», «Итоги по счетам», «Итоги по оплате по счетам», функция VZR и составляется отчет «Карточка взаиморасчетов».
Рисунок 23. Форма «Сальдо взаиморасчетов»
Форма создана в режиме конструктора. После заполнения периода, выбора поставщика и нажатия кнопки «Отчет» последовательно выполняются запросы «Итоги по накладным», «Итоги по оплате по накладным», «Итоги по счетам», «Итоги по оплате по счетам», функция OB и составляется отчет «Сальдо взаиморасчетов».
-
-
- Отчеты.
-
Отчет – это форматированное представление данных, которое выводится на экран, в печать или файл.
Ниже приводятся фрагменты отчетов.
Рисунок 24. Отчет «Карточка взаиморасчетов»
Рисунок 25. Фрагмент отчета «Сальдо взаиморасчетов»
Контрольный пример реализации проекта и его описание.
Задача реализована на примере работы предприятия, выпускающего мясные полуфабрикаты. Контрольная информация дана за август2017 года.
Для проверки правильности функционирования базы данных создан контрольный пример и выполнены все расчеты согласно меню Главной формы. Расчеты произведены верно. Контрольный пример и результаты расчетов приведены в Приложении.
ЗАКЛЮЧЕНИЕ
Результатом выполненной работы является разработанная информационная система «Взаиморасчеты с поставщиками» на базе MS Access.
Работа выполнена в соответствии с поставленными задачами.
Разработка может быть использована на небольших предприятиях независимо от форм собственности.
СПИСОК ЛИТЕРАТУРЫ
- Владимир Грекул, Нина Коровкина, Юрий Куприянов. Проектное управление в сфере информационных технологий. – М.:БИНОМ, ИНФРА-М, 2013.
- Абушенкова, М. Про расчеты с поставщиками и учет материалов / Марина Абушенкова // Главбух. - 2014. - № 2.
ПРИЛОЖЕНИЕ
Исходные данные и результаты функционирования базы данных.
В качестве контрольного примера заполнены с помощью форм таблицы базы данных.
|
Поставщики |
||||
|---|---|---|---|---|
|
Код поставщика |
Наименование |
Адрес |
ИНН |
Расчетный счет |
|
1 |
С/х предприятие "Россия" |
г.Зареченс, ул.Заводская, 9 |
123456789 |
23456789012345 |
|
2 |
ООО "Эврика" |
Энская обл, пгт Приветное, ул.Морская, 1 |
678901234 |
5678901234567 |
|
3 |
Объединение "АВС" |
г.Зареченск, ул. Строителей, 7 |
890123456 |
7890123456789 |
|
4 |
С/х ферма "Восток" |
Энская обл., пгт Раздольное, ул.Дражников, 5 |
012345667 |
890123456789 |
|
Товары |
||
|---|---|---|
|
Код товара |
Наименование |
Единица измерения |
|
1 |
Говядина |
кг |
|
2 |
Свинина |
кг |
|
3 |
Телятина |
кг |
|
4 |
Баранина |
кг |
|
5 |
Пищевые добавки |
кг |
|
Накладные |
||
|---|---|---|
|
Номер документа |
Дата |
Поставщик |
|
1 |
08.08.2017 |
С/х предприятие "Россия" |
|
10 |
25.08.2017 |
С/х ферма "Восток" |
|
2 |
09.08.2017 |
С/х предприятие "Россия" |
|
3 |
10.08.2017 |
ООО "Эврика" |
|
4 |
13.08.2017 |
Объединение "АВС" |
|
5 |
14.08.2017 |
Объединение "АВС" |
|
6 |
15.08.2017 |
Объединение "АВС" |
|
7 |
18.08.2017 |
С/х предприятие "Россия" |
|
8 |
18.08.2017 |
ООО "Эврика" |
|
9 |
23.08.2017 |
С/х ферма "Восток" |
|
Поступление товара |
|||
|---|---|---|---|
|
Накладная |
Товар |
Цена за единицу |
Количество |
|
1 |
Говядина |
200,00р. |
45 |
|
1 |
Свинина |
300,00р. |
2000 |
|
1 |
Телятина |
250,00р. |
4000 |
|
1 |
Баранина |
100,00р. |
6000 |
|
1 |
Пищевые добавки |
50,00р. |
101 |
|
10 |
Говядина |
345,00р. |
876 |
|
10 |
Свинина |
120,00р. |
120 |
|
10 |
Телятина |
412,00р. |
90 |
|
10 |
Баранина |
100,00р. |
100 |
|
10 |
Пищевые добавки |
41,00р. |
91 |
|
2 |
Говядина |
125,00р. |
900 |
|
2 |
Свинина |
130,00р. |
2100 |
|
2 |
Телятина |
340,00р. |
900 |
|
2 |
Баранина |
70,00р. |
350 |
|
2 |
Пищевые добавки |
67,00р. |
9 |
|
3 |
Говядина |
190,00р. |
3000 |
|
3 |
Свинина |
200,00р. |
2000 |
|
3 |
Телятина |
210,00р. |
200 |
|
3 |
Баранина |
100,00р. |
1600 |
|
3 |
Пищевые добавки |
40,00р. |
2300 |
|
4 |
Говядина |
320,00р. |
670 |
|
4 |
Свинина |
110,00р. |
700 |
|
4 |
Телятина |
150,00р. |
200 |
|
4 |
Баранина |
123,00р. |
80 |
|
4 |
Пищевые добавки |
70,00р. |
200 |
|
5 |
Говядина |
110,00р. |
2900 |
|
5 |
Свинина |
170,00р. |
1000 |
|
5 |
Телятина |
200,00р. |
1000 |
|
5 |
Баранина |
120,00р. |
300 |
|
5 |
Пищевые добавки |
60,00р. |
40 |
|
6 |
Говядина |
111,00р. |
1111 |
|
6 |
Свинина |
120,00р. |
2222 |
|
6 |
Телятина |
150,00р. |
200 |
|
6 |
Баранина |
89,00р. |
98 |
|
6 |
Пищевые добавки |
29,00р. |
3000 |
|
7 |
Говядина |
390,00р. |
2000 |
|
7 |
Свинина |
120,00р. |
2000 |
|
7 |
Телятина |
180,00р. |
200 |
|
7 |
Баранина |
165,00р. |
22 |
|
7 |
Пищевые добавки |
30,00р. |
1000 |
|
8 |
Говядина |
300,00р. |
100 |
|
8 |
Свинина |
123,00р. |
90 |
|
8 |
Телятина |
432,00р. |
70 |
|
8 |
Баранина |
100,00р. |
100 |
|
8 |
Пищевые добавки |
54,00р. |
8 |
|
9 |
Говядина |
550,00р. |
87 |
|
9 |
Свинина |
300,00р. |
1200 |
|
9 |
Телятина |
430,00р. |
78 |
|
9 |
Баранина |
56,00р. |
900 |
|
9 |
Пищевые добавки |
1,00р. |
90 |
|
Оплата по накладным |
|||
|---|---|---|---|
|
РегНомер |
Накладная |
Дата оплаты |
Сумма |
|
1 |
1 |
09.08.2017 |
1 500 000,00р. |
|
2 |
1 |
10.08.2017 |
1 000 000,00р. |
|
3 |
10 |
26.08.2017 |
367 431,00р. |
|
4 |
2 |
10.08.2017 |
716 603,00р. |
|
5 |
3 |
11.08.2017 |
1 000 000,00р. |
|
6 |
4 |
14.08.2017 |
100 000,00р. |
|
7 |
4 |
15.08.2017 |
210 000,00р. |
|
8 |
6 |
16.08.2017 |
515 683,00р. |
|
9 |
7 |
19.08.2017 |
1 000 000,00р. |
|
10 |
7 |
20.08.2017 |
89 630,00р. |
|
11 |
8 |
21.08.2017 |
81 472,00р. |
|
12 |
9 |
30.08.2017 |
491 880,00р. |
|
Счета на оплату |
||
|---|---|---|
|
Номер документа |
Дата |
Поставщик |
|
101 |
02.08.2017 |
С/х ферма "Восток" |
|
102 |
05.08.2017 |
Объединение "АВС" |
|
109 |
15.08.2017 |
С/х ферма "Восток" |
|
120 |
19.08.2017 |
ООО "Эврика" |
|
Товары по счету |
|||
|---|---|---|---|
|
Счет |
Товар |
Цена за единицу |
Количество |
|
101 |
Свинина |
300,00р. |
200 |
|
101 |
Баранина |
78,00р. |
100 |
|
101 |
Пищевые добавки |
13,00р. |
101 |
|
102 |
Телятина |
400,00р. |
400 |
|
102 |
Баранина |
100,00р. |
100 |
|
109 |
Говядина |
230,00р. |
1090 |
|
120 |
Свинина |
200,00р. |
34 |
|
Оплата по счетам |
|||
|---|---|---|---|
|
РегНомер |
Счет |
Дата оплаты |
Сумма |
|
1 |
101 |
10.08.2017 |
70 000,00р. |
|
2 |
109 |
18.08.2017 |
100 000,00р. |
|
3 |
109 |
19.08.2017 |
150 000,00р. |
|
Авансы |
|||
|---|---|---|---|
|
Регистрационный номер |
Поставщик |
Дата |
Сумма |
|
1 |
С/х предприятие "Россия" |
02.08.2017 |
590 000,00р. |
|
2 |
Объединение "АВС" |
03.08.2017 |
140 000,00р. |
|
3 |
С/х ферма "Восток" |
03.08.2017 |
200 000,00р. |
На основании информации таблиц составлены отчеты «Карточка взаиморасчетов» и «Сальдо взаиморасчетов». Результаты составления отчетов проверены. Выборки и вычисления произведены без ошибок.
- Теории происхождения государства (Теоретические аспекты происхождения государства)
- Графические планшеты (TABLET PC: РЕВОЛЮЦИЯ ИЛИ ЭВОЛЮЦИЯ?)
- Налоговая система РФ как фактор экономической стабилизации (Экономическое содержание налогов)
- Страхование и его роль в развитии экономики (Прогноз развития страхового рынка РФ)
- Финансовая политика и ее реализация в РФ ( Содержание финансовой политики РФ )
- Культуpa pecтopaннoгo oбcлуживaния
- Мотивация и управленческая деятельность (
- Страховые пенсии по старости (ОБЩИЕ ПОЛОЖЕНИЯ ПРАВОВОГО РЕГУЛИРОВАНИЯ СТРАХОВОЙ ПЕНСИИ ПО СТАРОСТИ В РОССИЙСКОЙ ФЕДЕРАЦИИ)
- Правовой статус депутата государственной думы (ТЕОРЕТИКО-ПРАВОВЫЕ ОСНОВЫ ПРАВОВОГО СТАТУСА ДЕПУТАТА ГОСУДАРСТВЕННОЙ ДУМЫ)
- Анализ деятельности спортивной организации на примере спортивного клуба ПФК ЦСКА
- Система управления миграционными процессами Российской Федерации
- Облачные сервисы