Проектирование и Разработка Информационной Системы в MS Access для Оценки Неполной Оплаты Отгруженной Продукции: Методология, Реализация и Анализ

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

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

Целью данной курсовой работы является разработка методологии и практических шагов для проектирования и реализации информационной системы (ИС) в среде СУБД MS Access, предназначенной для оценки неполной оплаты отгруженной продукции всеми заказчиками за заданный период. В рамках работы будут решены следующие задачи:

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

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

Теоретические основы проектирования информационных систем и баз данных

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

Основные определения и понятия

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

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

Система управления базами данных (СУБД) — это программный комплекс, который позволяет создавать, изменять, получать информацию из баз данных и контролировать версии. Если БД — это библиотека, то СУБД — это библиотекарь, который организует всю работу: принимает новые книги, следит за их порядком, помогает найти нужную информацию и обеспечивает её сохранность. В нашем случае, роль такого «библиотекаря» будет выполнять Microsoft Access.

Дебиторская задолженность — это финансовые обязательства, которые другие лица или компании имеют перед нашей компанией. Она возникает, когда товары или услуги были предоставлены, но оплата за них ещё не поступила. Это как «займ», который компания предоставила своим клиентам, ожидая возврата в будущем.

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

Нормализация базы данных — это процесс оптимизации структуры базы данных путём организации данных в соответствии с определёнными правилами, известными как нормальные формы. Главная цель нормализации — устранить избыточность данных, уменьшить размер базы данных, сохранить целостность данных при их изменении и предотвратить аномалии. Представьте, что вы организуете картотеку: нормализация помогает избежать ситуации, когда одна и та же информация (например, адрес клиента) записана в десятках разных мест, что приводит к ошибкам при её изменении.

Принципы проектирования реляционных баз данных

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

Модель «сущность-связь» (ER-модель) — это мощный инструмент для формализованного представления предметной области и логической структуры базы данных. Она позволяет визуализировать основные информационные объекты (сущности), их характеристики (атрибуты) и взаимосвязи между ними. Представьте, что вы создаёте карту мира: ER-модель поможет определить континенты (сущности), их особенности (атрибуты, такие как площадь, население) и границы (связи).

Компоненты ER-модели:

• Сущности — это объекты или события, о которых необходимо хранить информацию. В нашем случае сущностями могут быть «Заказчики», «Продукция», «Отгрузки», «Платежи» и «Договоры». Каждая сущность является своего рода таблицей в будущей базе данных.
• Атрибуты — это характеристики или свойства сущности. Например, для сущности «Заказчики» атрибутами будут «НазваниеЗаказчика», «Адрес», «ИНН». Атрибуты становятся полями в таблице.
• Связи (отношения) — это ассоциации между сущностями. Например, «Заказчики» заключают «Договоры», «Договоры» порождают «Отгрузки», а «Отгрузки» связаны с «Продукцией». Связи определяют, как данные в одной таблице соотносятся с данными в другой и являются ключевым элементом для обеспечения целостности данных.

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

Нормализация данных и ее значение

Нормализация — это не просто академическое упражнение, а критически важный этап в проектировании базы данных, который имеет прямое отношение к её производительности, надёжности и удобству эксплуатации. Представьте, что вы строите дом: нормализация — это процесс прокладки всех коммуникаций таким образом, чтобы они работали без сбоев, а их ремонт не требовал сноса стен.

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

Аномалии при работе с данными

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

1. Аномалии модификации (или редактирования): Они возникают, когда для изменения одного факта требуется обновить данные в нескольких записях. Например, если адрес поставщика хранится в каждой записи о поставке, и поставщик меняет адрес, то нужно обновить все записи о его поставках. Если какая-то запись будет пропущена, возникнет противоречие в данных.
2. Аномалии удаления: Этот тип аномалий проявляется, когда при удалении записи теряется другая, косвенно связанная, но важная информация. Например, если данные о поставщике хранятся только в записях о его поставках, то удаление всех поставок этого поставщика приведет к потере всей информации о нём самом (его названии, контактах), даже если он потенциально может быть будущим контрагентом.
3. Аномалии добавления: Возникают, когда невозможно добавить новую информацию в таблицу, пока она неполна, или вставка новой записи требует наличия уже существующих данных. Например, если для добавления информации о новом поставщике обязательно требуется указать номер поставки, то нельзя будет внести данные о поставщике, с которым только что заключен договор, но ещё не было ни одной отгрузки.

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

Нормальные формы (1НФ, 2НФ, 3НФ, НФБК)

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

1. Первая нормальная форма (1НФ). Это базовый уровень нормализации. Чтобы таблица соответствовала 1НФ, должны быть выполнены следующие условия:
   • Каждая ячейка таблицы должна содержать только атомарное значение (одно значение, которое нельзя разделить на более мелкие смысловые части). Например, нельзя хранить «Имя Фамилия» в одном поле, нужно разделить на «Имя» и «Фамилия».
   • Все данные в одном столбце должны быть одного типа.
   • Каждая запись (строка) должна быть уникально идентифицируемой с помощью первичного ключа (отсутствие повторяющихся строк).
   • Отсутствие повторяющихся групп атрибутов.

   Пример: Если в таблице «Заказчики» есть поле «Телефоны», где через запятую перечислены несколько номеров, это нарушает 1НФ. Для соблюдения 1НФ необходимо либо создать отдельную таблицу «ТелефоныЗаказчиков», либо добавить отдельные поля «Телефон1», «Телефон2» и т.д., что менее гибко.

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

   Пример: Представим таблицу «ОтгрузкиПродукции» с составным первичным ключом (НомерТТН, КодПродукции) и полями «НаименованиеПродукции», «Количество», «СуммаОтгрузки». «НаименованиеПродукции» зависит только от «КодПродукции», а не от всего составного ключа. Это нарушение 2НФ. Для устранения необходимо вынести «НаименованиеПродукции» в отдельную таблицу «Продукция», где «КодПродукции» будет первичным ключом.

3. Третья нормальная форма (3НФ). Отношение находится в 3НФ, если оно находится во 2НФ, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых. Это означает, что каждый неключевой атрибут должен зависеть от ключа, от всего ключа целиком, и ни от чего другого, кроме ключа. 3НФ устраняет аномалии, когда один неключевой атрибут зависит от другого неключевого атрибута.

   Пример: Рассмотрим таблицу «Заказчики» с полями «КодЗаказчика» (первичный ключ), «НазваниеЗаказчика», «АдресЗаказчика», «КодГорода», «НазваниеГорода». Здесь «НазваниеГорода» зависит от «КодГорода», а «КодГорода» зависит от «КодЗаказчика» (через зависимость «Заказчик» → «Город»). То есть «НазваниеГорода» транзитивно зависит от «КодЗаказчика». Для соблюдения 3НФ необходимо вынести «КодГорода» и «НазваниеГорода» в отдельную таблицу «Города».

4. Нормальная форма Бойса-Кодда (НФБК). Эта форма является более строгой, чем 3НФ, и требует, чтобы детерминанты всех нетривиальных функциональных зависимостей в отношении были потенциальными ключами. НФБК устраняет аномалии, которые могут оставаться в 3НФ в случаях, когда в таблице есть несколько составных потенциальных ключей, имеющих общие атрибуты. НФБК гарантирует, что каждый атрибут является частью ключа, зависит от всего ключа и только от него.

   Пример: НФБК актуальна в более сложных сценариях, когда, например, в таблице «СтудентыКурсыПреподаватели» есть зависимости: (Студент, Курс) → Преподаватель (один студент изучает курс у одного преподавателя), и Преподаватель → Курс (один преподаватель ведет один курс). Здесь (Студент, Курс) и (Студент, Преподаватель) могут быть потенциальными ключами. Если Преподаватель не является потенциальным ключом, но детерминирует Курс, это нарушает НФБК. Для соответствия НФБК потребуется дальнейшее деление таблицы.

Переход по нормальным формам позволяет создать базу данных, которая является не только компактной, но и устойчивой к ошибкам, легкой в поддержке и эффективной в работе с данными. Для большинства бизнес-приложений достижение 3НФ или НФБК считается достаточным и оптимальным, поскольку обеспечивает максимальный баланс между эффективностью хранения и сложностью реализации. Что касается дальнейшего развития системы, то понимание этих принципов критически важно для её масштабирования и поддержания.

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

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

Описание бизнес-процессов

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

Основные этапы движения продукции и денежных средств на предприятии:

1. Оформление заказа. Этот этап начинается с получения запроса от клиента или заключения нового договора. На этом этапе фиксируются основные условия сделки: наименование продукции, количество, цена, сроки отгрузки и условия оплаты. Важно учесть, что один заказчик может заключать множество договоров, и каждый договор может охватывать несколько позиций продукции.
2. Отгрузка продукции. После оформления заказа и подготовки продукции происходит её физическая отгрузка со склада. Документальным подтверждением этого события является Товарно-транспортная накладная (ТТН) или иной отгрузочный документ. В нём фиксируются дата отгрузки, перечень отгруженной продукции, её количество и стоимость. С этого момента у покупателя возникает обязательство по оплате. Одна отгрузка может включать несколько видов продукции по одному договору.
3. Выставление счетов. Параллельно с отгрузкой или сразу после неё предприятие выставляет клиенту счёт на оплату. Этот документ детализирует сумму к оплате, срок и реквизиты для перечисления денежных средств. Хотя счёт не является первичным документом, подтверждающим факт хозяйственной операции, он является ключевым элементом для инициирования платежа.
4. Поступление оплаты. Клиент осуществляет перевод денежных средств в соответствии с условиями договора и выставленным счётом. Документом, подтверждающим этот факт, является Платежное поручение (ПП), выписка банка или кассовый ордер. В этом документе фиксируется дата платежа, сумма и ссылка на договор или счёт, по которому производится оплата. Важно отметить, что платеж может быть полным или частичным, а также может поступать с задержкой. Именно здесь возникает возможность для неполной оплаты.
5. Учёт задолженности. На основе данных об отгрузках и поступлениях платежей формируется информация о дебиторской задолженности. Этот процесс включает в себя сопоставление отгруженных сумм с полученными платежами по каждому договору и заказчику. Цель этого этапа — выявить расхождения и определить сумму недоплаты.

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

Разработка ER-модели для системы учета неполной оплаты

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

Основные сущности и их взаимосвязи для системы учёта неполной оплаты:

1. Заказчики (Customers):
   • Сущность, представляющая контрагентов, которым отгружается продукция.
   • Атрибуты: КодЗаказчика (первичный ключ), НазваниеЗаказчика, Адрес, Телефон, ИНН, КПП.
2. Продукция (Products):
   • Сущность, описывающая товары, которые предприятие отгружает.
   • Атрибуты: КодПродукции (первичный ключ), Наименование, ЕдиницаИзмерения, Цена.
3. Договоры (Contracts):
   • Сущность, фиксирующая юридические соглашения с заказчиками.
   • Атрибуты: НомерДоговора (первичный ключ), ДатаДоговора, КодЗаказчика (внешний ключ), СуммаДоговора (планируемая или общая сумма по договору, может быть необязательным).
4. Отгрузки (Shipments):
   • Сущность, представляющая факт отгрузки продукции по конкретному договору.
   • Атрибуты: НомерТТН (первичный ключ), ДатаОтгрузки, НомерДоговора (внешний ключ), КодПродукции (внешний ключ), Количество, ЦенаОтгрузки (цена на момент отгрузки), СуммаОтгрузки. Примечание: ЦенаОтгрузки важна, так как Цена продукции может меняться со временем, а отгрузка фиксирует цену на конкретный момент.
5. Платежи (Payments):
   • Сущность, фиксирующая факт поступления денежных средств от заказчика по договору.
   • Атрибуты: НомерПП (первичный ключ), ДатаПлатежа, НомерДоговора (внешний ключ), СуммаПлатежа, Примечание.

Связи между сущностями (предполагаемый тип отношения):

• Заказчики ↔ Договоры: Один-ко-многим (1:M). Один заказчик может заключать множество договоров, но каждый договор относится только к одному заказчику.
  • Механизм: КодЗаказчика из таблицы «Заказчики» является внешним ключом в таблице «Договоры».
• Договоры ↔ Отгрузки: Один-ко-многим (1:M). По одному договору может быть осуществлено множество отгрузок, но каждая отгрузка связана только с одним договором.
  • Механизм: НомерДоговора из таблицы «Договоры» является внешним ключом в таблице «Отгрузки».
• Договоры ↔ Платежи: Один-ко-многим (1:M). По одному договору может быть получено множество платежей, но каждый платеж относится только к одному договору.
  • Механизм: НомерДоговора из таблицы «Договоры» является внешним ключом в таблице «Платежи».
• Продукция ↔ Отгрузки: Один-ко-многим (1:M). Один вид продукции может быть отгружен много раз, но каждая позиция в отгрузке относится к одному виду продукции.
  • Механизм: КодПродукции из таблицы «Продукция» является внешним ключом в таблице «Отгрузки».

Графическое представление ER-модели (схематическое):

+----------------+       +-----------------+       +-----------------+
|   Заказчики    |───────|    Договоры     |───────|     Отгрузки    |
+----------------+ 1:M   +-----------------+ 1:M   +-----------------+
| КодЗаказчика(PK)|       | НомерДоговора(PK)|       | НомерТТН(PK)    |
| НазваниеЗаказчика|       | ДатаДоговора    |       | ДатаОтгрузки    |
| Адрес          |       | КодЗаказчика(FK)|       | НомерДоговора(FK)|
| Телефон        |       | СуммаДоговора   |       | КодПродукции(FK) |
| ИНН            |       +-----------------+       | Количество      |
| КПП            |               |               | ЦенаОтгрузки    |
+----------------+               | 1:M           | СуммаОтгрузки   |
                                 |               +-----------------+
                                 |
                                 |               +-----------------+
                                 |───────|     Платежи       |
                                         +-----------------+
                                         | НомерПП(PK)     |
                                         | ДатаПлатежа     |
                                         | НомерДоговора(FK)|
                                         | СуммаПлатежа    |
                                         | Примечание      |
                                         +-----------------+

+----------------+
|   Продукция    |───────
+----------------+ 1:M
| КодПродукции(PK)|
| Наименование   |
| ЕдиницаИзмерения|
| Цена           |
+----------------+

Примечание: Стрелки показывают направление связи «один-ко-многим». FK — внешний ключ, PK — первичный ключ.

Эта ER-модель является основой для дальнейшего этапа — проектирования физической структуры таблиц.

Обоснование логической структуры таблиц

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

Представим структуру наших таблиц:

Таблица «Заказчики»

Эта таблица будет содержать основную информацию о контрагентах.
Структура:

• КодЗаказчика (Автосчётчик/Целое число, Первичный ключ) – уникальный идентификатор заказчика.
• НазваниеЗаказчика (Текстовый, 255 символов) – полное наименование организации.
• Адрес (Текстовый, 255 символов) – юридический или фактический адрес заказчика.
• Телефон (Текстовый, 20 символов) – контактный номер телефона.
• ИНН (Текстовый, 12 символов) – идентификационный номер налогоплательщика.
• КПП (Текстовый, 9 символов) – код причины постановки на учет.

Обоснование нормализации:
Таблица «Заказчики» находится в 3НФ. Каждый атрибут (НазваниеЗаказчика, Адрес, Телефон, ИНН, КПП) полностью зависит от первичного ключа КодЗаказчика (2НФ), и нет транзитивных зависимостей (3НФ). Все поля содержат атомарные значения (1НФ).

Таблица «Продукция»

Содержит данные о номенклатуре товаров.
Структура:

• КодПродукции (Автосчётчик/Целое число, Первичный ключ) – уникальный идентификатор продукции.
• Наименование (Текстовый, 255 символов) – название товара.
• ЕдиницаИзмерения (Текстовый, 50 символов) – например, «шт.», «кг», «м».
• Цена (Денежный) – текущая розничная или отпускная цена за единицу продукции.

Обоснование нормализации:
Таблица «Продукция» также соответствует 3НФ, поскольку все атрибуты зависят исключительно от КодПродукции, и нет транзитивных зависимостей.

Таблица «Договоры»

Фиксирует детали каждого договора с заказчиком.
Структура:

• НомерДоговора (Текстовый/Автосчётчик, Первичный ключ) – уникальный номер договора.
• ДатаДоговора (Дата/Время) – дата заключения договора.
• КодЗаказчика (Целое число, Внешний ключ) – ссылка на таблицу «Заказчики».
• СуммаДоговора (Денежный, необязательный) – общая сумма договора, если она известна заранее.

Обоснование нормализации:
Эта таблица находится в 3НФ. КодЗаказчика является внешним ключом, связывающим договор с конкретным заказчиком, что устраняет избыточность данных о заказчике в таблице «Договоры». СуммаДоговора и ДатаДоговора зависят только от НомерДоговора.

Таблица «Отгрузки» (Товарно-транспортные накладные)

Содержит информацию о каждой конкретной отгрузке.
Структура:

• НомерТТН (Автосчётчик/Текстовый, Первичный ключ) – уникальный номер товарно-транспортной накладной.
• ДатаОтгрузки (Дата/Время) – дата фактической отгрузки.
• НомерДоговора (Текстовый/Целое число, Внешний ключ) – ссылка на таблицу «Договоры».
• КодПродукции (Целое число, Внешний ключ) – ссылка на таблицу «Продукция».
• Количество (Числовой, Целое/Дробное) – количество отгруженной продукции.
• ЦенаОтгрузки (Денежный) – цена единицы продукции на момент отгрузки (важно для фиксации цены, которая могла измениться).
• СуммаОтгрузки (Вычисляемое поле, Денежный) – Количество * ЦенаОтгрузки.

Обоснование нормализации:
Таблица «Отгрузки» находится в 3НФ. НомерДоговора и КодПродукции являются внешними ключами, предотвращая дублирование информации о договорах и продукции. Все остальные поля (ДатаОтгрузки, Количество, ЦенаОтгрузки, СуммаОтгрузки) зависят от первичного ключа НомерТТН и не имеют транзитивных зависимостей. СуммаОтгрузки является вычисляемым полем, что исключает аномалии модификации, так как ее значение всегда корректно пересчитывается.

Таблица «Платежи» (Платежные поручения)

Фиксирует все входящие платежи от заказчиков.
Структура:

• НомерПП (Автосчётчик/Текстовый, Первичный ключ) – уникальный номер платежного поручения.
• ДатаПлатежа (Дата/Время) – дата поступления платежа.
• НомерДоговора (Текстовый/Целое число, Внешний ключ) – ссылка на таблицу «Договоры».
• СуммаПлатежа (Денежный) – сумма поступившего платежа.
• Примечание (Текстовый, 255 символов, необязательный) – комментарии к платежу.

Обоснование нормализации:
Таблица «Платежи» также соответствует 3НФ. НомерДоговора является внешним ключом, а ДатаПлатежа, СуммаПлатежа и Примечание зависят от первичного ключа НомерПП без транзитивных зависимостей.

Обеспечение ссылочной целостности:
При проектировании связей между таблицами, как описано в ER-модели, мы обеспечиваем ссылочную целостность. Это означает, что невозможно будет ввести КодЗаказчика в таблице «Договоры», если такого заказчика нет в таблице «Заказчики». Аналогично, нельзя удалить заказчика, если с ним связаны активные договоры, или договор, если по нему были отгрузки или платежи. Это предотвращает аномалии удаления и модификации, обеспечивая консистентность данных во всей системе. Достижение 3НФ для всех таблиц позволяет минимизировать избыточность и эффективно управлять данными, что является ключевым для точного учёта неполной оплаты.

Практическая реализация информационной системы в MS Access

Теоретические выкладки и логическое проектирование обретают форму в практической реализации. MS Access, будучи одной из самых доступных и широко используемых СУБД для малых и средних предприятий, предоставляет обширный инструментарий для создания полноценных информационных систем. Этот раздел станет пошаговым руководством по воплощению нашей спроектированной модели в живую и работающую базу данных.

Этапы разработки базы данных в MS Access

Разработка информационной системы в MS Access — это структурированный процесс, который охватывает все стадии жизненного цикла ПО, от создания базовых хранилищ данных до построения пользовательского интерфейса и аналитических отчётов. Представим основные этапы, которые предстоит пройти:

1. Разработка и описание структур таблиц данных. На этом этапе мы создаём физические таблицы в Access, определяя для каждой из них поля, типы данных, размеры, первичные ключи и другие свойства в строгом соответствии с логической структурой, разработанной на предыдущем этапе.
2. Разработка схемы данных и задание системы взаимосвязей между таблицами. После создания таблиц необходимо установить между ними связи, отражающие отношения «один-ко-многим» или «один-к-одному», определённые в ER-модели. Критически важно настроить параметры обеспечения ссылочной целостности, чтобы предотвратить ввод некорректных данных.
3. Разработка системы запросов к таблицам базы данных. Запросы — это сердце аналитической части системы. Они позволяют извлекать, фильтровать, сортировать, группировать и вычислять данные, необходимые для анализа неполной оплаты. На этом этапе создаются запросы на выборку, обновление, добавление и удаление данных.
4. Разработка экранных форм ввода/вывода данных. Формы — это пользовательский интерфейс, который делает работу с базой данных удобной и интуитивно понятной. Они служат для ввода новой информации (например, об отгрузках или платежах) и для просмотра существующих данных.
5. Разработка системы отчетов по данным. Отчёты предназначены для представления обработанных данных в печатном или электронном виде. Они позволяют визуализировать результаты анализа, например, списки заказчиков с недоплатой, оборачиваемость дебиторской задолженности и т.д.
6. Разработка программных расширений (VBA/Макросы). Для автоматизации сложных операций, реализации специфических бизнес-логик или повышения интерактивности системы используются макросы Access или код на Visual Basic for Applications (VBA). Это позволяет выйти за рамки стандартных возможностей Access. Например, VBA может быть использован для автоматического расчёта СуммыОтгрузки при вводе Количества и ЦеныОтгрузки в форме, или для валидации данных, которая сложнее, чем простая проверка типа.
7. Разработка системы защиты данных, прав и ограничений по доступу. На финальных этапах внедряются меры безопасности для защиты конфиденциальной информации и разграничения прав доступа пользователей к различным частям системы.

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

Создание и описание структур таблиц данных

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

Последовательность действий:

1. В главном окне Access выберите вкладку «Создание».
2. Нажмите «Таблица» (или «Конструктор таблиц» для более полного контроля).
3. Для каждой таблицы:
   • Введите имена полей в соответствии с разработанной структурой.
   • Выберите подходящий тип данных для каждого поля (например, «Текстовый», «Числовой», «Денежный», «Дата/Время», «Автосчётчик»).
   • Установите первичные ключи. Для полей КодЗаказчика, КодПродукции, НомерДоговора, НомерТТН, НомерПП выберите тип «Автосчётчик» (если номера не формируются вручную или из другой системы) и назначьте их первичными ключами.
   • Настройте свойства полей, такие как размер поля, обязательность заполнения, значение по умолчанию и т.д. Например, для НазваниеЗаказчика установите размер 255 символов.
   • Создайте вычисляемое поле СуммаОтгрузки в таблице «Отгрузки». Для этого в Конструкторе таблиц выберите тип данных «Вычисляемый» и введите выражение: [Количество]*[ЦенаОтгрузки].

Пример создания таблицы «Заказчики» (в режиме конструктора):

Имя поля	Тип данных	Описание
КодЗаказчика	Автосчётчик	Уникальный идентификатор заказчика (ПК)
НазваниеЗаказчика	Короткий текст	Полное наименование организации
Адрес	Короткий текст	Юридический/фактический адрес
Телефон	Короткий текст	Контактный телефон
ИНН	Короткий текст	Идентификационный номер налогоплательщика
КПП	Короткий текст	Код причины постановки на учет

После создания всех таблиц сохраните их с соответствующими именами («Заказчики», «Продукция», «Договоры», «Отгрузки», «Платежи»).

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

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

Последовательность действий:

1. В главном окне Access перейдите на вкладку «Работа с базами данных».
2. Нажмите кнопку «Схема данных». Откроется окно «Схема данных», где можно добавить все созданные таблицы.
3. Добавьте все таблицы («Заказчики», «Продукция», «Договоры», «Отгрузки», «Платежи») в окно схемы данных.
4. Установите связи:
   • Заказчики ↔ Договоры: Перетащите поле КодЗаказчика (первичный ключ) из таблицы «Заказчики» на поле КодЗаказчика (внешний ключ) в таблице «Договоры».
   • Договоры ↔ Отгрузки: Перетащите поле НомерДоговора из таблицы «Договоры» на поле НомерДоговора в таблице «Отгрузки».
   • Договоры ↔ Платежи: Перетащите поле НомерДоговора из таблицы «Договоры» на поле НомерДоговора в таблице «Платежи».
   • Продукция ↔ Отгрузки: Перетащите поле КодПродукции из таблицы «Продукция» на поле КодПродукции в таблице «Отгрузки».
5. Настройка параметров связей (Обеспечение целостности данных):
   • При создании каждой связи появится диалоговое окно «Изменение связи».
   • ОБЯЗАТЕЛЬНО установите флажок «Обеспечение целостности данных». Это гарантирует, что нельзя будет ввести в подчиненную таблицу данные, для которых нет соответствующей записи в главной таблице (например, отгрузку по несуществующему договору).
   • Рассмотрите опции «Каскадное обновление связанных полей» (позволяет автоматически обновлять внешние ключи при изменении первичного ключа в главной таблице) и «Каскадное удаление связанных записей» (позволяет автоматически удалять связанные записи в подчиненной таблице при удалении записи в главной). Для большинства случаев в бухгалтерском учёте каскадное удаление следует использовать с осторожностью или вообще избегать, чтобы не потерять важные и��торические данные. Каскадное обновление может быть полезным.

Правильно настроенная схема данных с обеспечением ссылочной целостности является основой для надёжной работы информационной системы.

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

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

Виды запросов, которые нам потребуются:

• Запросы на выборку: Для получения данных по определённым критериям.
• Запросы с параметрами: Позволяют пользователю вводить значения (например, код заказчика или месяц) для фильтрации данных.
• Итоговые запросы (с группировкой): Для выполнения агрегирующих функций (СУММ, СЧЁТЧИК, СРЕДНЕЕ) по группам данных.

Примеры запросов:

• Запрос для просмотра всех отгрузок по конкретному договору.
• Запрос для просмотра всех платежей по конкретному заказчику.
• Специализированный запрос для расчета неполной оплаты.

Алгоритм расчета недоплаты

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

1. Идентификация отгрузок: Получить все отгрузки (ТТН) для указанного заказчика за интересующий месяц. Для каждой отгрузки определить её общую стоимость.
2. Идентификация платежей: Получить все платежи (ПП), поступившие от того же заказчика за тот же месяц, с привязкой к соответствующим договорам. Для каждого платежа определить его сумму.
3. Сопоставление и агрегация по договорам: Для каждого договора, связанного с выбранным заказчиком, суммировать общие отгрузки и общие платежи за выбранный месяц.
4. Расчет недоплаты: Вычислить разницу между суммой отгруженного товара и суммой оплаченного товара по каждому договору. Если сумма отгрузок превышает сумму платежей, это и будет сумма недоплаты.
5. Итоговая недоплата: Сгруппировать результаты по заказчику и представить общую сумму недоплаты.

Этот алгоритм ляжет в основу нашего SQL-запроса.

Пример SQL-запроса для выявления неполной оплаты

Представленный ниже SQL-запрос является одним из ключевых элементов нашей системы. Он реализует описанный алгоритм и позволяет получить детализированную информацию о недоплате.
Примечание: SQL-код адаптирован для MS Access, где функция FORMAT используется для работы с датами, а параметры запроса обозначаются квадратными скобками [].

SELECT
    Z.НазваниеЗаказчика,
    D.НомерДоговора,
    SUM(O.СуммаОтгрузки) AS СуммаОтгрузок,
    Nz(SUM(P.СуммаПлатежа), 0) AS СуммаПлатежей,
    (SUM(O.СуммаОтгрузки) - Nz(SUM(P.СуммаПлатежа), 0)) AS Недоплата
FROM
    Заказчики AS Z
INNER JOIN
    Договоры AS D ON Z.КодЗаказчика = D.КодЗаказчика
LEFT JOIN
    Отгрузки AS O ON D.НомерДоговора = O.НомерДоговора
LEFT JOIN
    Платежи AS P ON D.НомерДоговора = P.НомерДоговора
WHERE
    Z.КодЗаказчика = [ВведитеКодЗаказчика] AND
    FORMAT(O.ДатаОтгрузки, "yyyy-mm") = [ВведитеМесяцГодОтгрузки]
GROUP BY
    Z.НазваниеЗаказчика, D.НомерДоговора
HAVING
    (SUM(O.СуммаОтгрузки) - Nz(SUM(P.СуммаПлатежа), 0)) > 0;

Подробное объяснение структуры и функционала запроса:

• SELECT: Определяет, какие поля будут выведены в результате запроса.
  • Z.НазваниеЗаказчика, D.НомерДоговора: Выводятся наименование заказчика и номер договора.
  • SUM(O.СуммаОтгрузки) AS СуммаОтгрузок: Вычисляется общая сумма отгрузок по каждому договору. AS СуммаОтгрузок присваивает псевдоним полю.
  • Nz(SUM(P.СуммаПлатежа), 0) AS СуммаПлатежей: Вычисляется общая сумма платежей по каждому договору. Функция Nz() (Null Zero) в Access заменяет NULL значения на 0, что критически важно, если по договору не было платежей (тогда SUM(P.СуммаПлатежа) вернет NULL, и вычитание NULL приведет к NULL в Недоплата).
  • (SUM(O.СуммаОтгрузки) - Nz(SUM(P.СуммаПлатежа), 0)) AS Недоплата: Вычисляется сумма недоплаты как разница между отгрузками и платежами.
• FROM: Указывает таблицы, из которых извлекаются данные.
  • Заказчики AS Z: Таблица «Заказчики» с псевдонимом Z.
• INNER JOIN Договоры AS D ON Z.КодЗаказчика = D.КодЗаказчика: Соединяет «Заказчики» с «Договорами». Используется INNER JOIN, так как нас интересуют только заказчики, у которых есть договоры.
• LEFT JOIN Отгрузки AS O ON D.НомерДоговора = O.НомерДоговора: Соединяет «Договоры» с «Отгрузками». LEFT JOIN используется, чтобы включить все договоры, даже если по ним не было отгрузок (хотя в контексте неполной оплаты это менее вероятно).
• LEFT JOIN Платежи AS P ON D.НомерДоговора = P.НомерДоговора: Соединяет «Договоры» с «Платежами». LEFT JOIN позволяет включить договоры, по которым не было платежей, что очень важно для выявления неполной оплаты.
• WHERE: Фильтрует записи до группировки.
  • Z.КодЗаказчика = [ВведитеКодЗаказчика]: Позволяет пользователю ввести код конкретного заказчика.
  • FORMAT(O.ДатаОтгрузки, "yyyy-mm") = [ВведитеМесяцГодОтгрузки]: Фильтрует отгрузки по заданному месяцу и году. FORMAT преобразует дату в строку «ГГГГ-ММ». Важно: для корректного расчета недоплаты может потребоваться фильтрация платежей также по соответствующему периоду, или же по всем платежам, которые относятся к отгрузкам до определенной даты, независимо от даты платежа. Для простоты в данном примере фильтруем по дате отгрузки.
• GROUP BY: Группирует результаты по НазваниюЗаказчика и НомеруДоговора, чтобы агрегирующие функции (СУММ) работали для каждой уникальной пары «Заказчик-Договор».
• HAVING: Фильтрует группы после выполнения агрегирующих функций.
  • (SUM(O.СуммаОтгрузки) - Nz(SUM(P.СуммаПлатежа), 0)) > 0: Показывает только те группы (договоры), по которым сумма отгрузок превышает сумму платежей, т.е. есть недоплата.

Этот запрос является мощным инструментом для оперативного контроля дебиторской задолженности и своевременного выявления проблемных контрагентов. Что из этого следует? Регулярное использование такого запроса позволяет руководству принимать решения по взысканию задолженности до того, как она станет критической проблемой для ликвидности предприятия.

Разработка экранных форм ввода/вывода данных

Экранные формы в MS Access — это пользовательский интерфейс, который значительно упрощает взаимодействие с базой данных, делая её доступной для пользователей без глубоких знаний SQL или структуры таблиц. Они служат для ввода, редактирования и просмотра данных в удобном графическом представлении.

Цели создания форм:

• Удобство ввода данных: Предоставить интуитивно понятные поля для заполнения информации об отгрузках, платежах, заказчиках и продукции.
• Валидация данных: Встроенные механизмы Access и VBA позволяют проверять корректность вводимых данных (например, числовые значения в поле «Количество», формат даты).
• Навигация: Упростить перемещение между записями и связанными данными.
• Защита данных: Ограничить прямой доступ к таблицам, предотвращая случайные или преднамеренные изменения структуры.

Примеры форм, которые необходимо создать:

1. Форма «Заказчики»: Для ввода и просмотра информации о клиентах. Может содержать подформу со списком договоров данного заказчика.
2. Форма «Продукция»: Для управления каталогом товаров.
3. Форма «Договоры»: Для ввода и просмотра деталей договоров. В эту форму могут быть встроены подформы для отображения всех отгрузок и платежей по конкретному договору.
4. Форма «Отгрузки»: Для записи данных о каждой товарно-транспортной накладной. Может автоматически рассчитывать СуммуОтгрузки.
5. Форма «Платежи»: Для регистрации входящих платежей.

Процесс создания форм в Access:

1. Мастер форм: Самый простой способ. Выбираете таблицу или запрос, на основе которого хотите создать форму, и Мастер форм последовательно задаст вопросы о полях, макете и стилях.
2. Конструктор форм: Предоставляет максимальную гибкость. Позволяет вручную размещать элементы управления (текстовые поля, кнопки, списки), добавлять графические элементы и настраивать их свойства.
3. Кнопки и элементы управления: Добавьте кнопки для навигации (следующая/предыдущая запись), сохранения, удаления, печати, а также для вызова отчетов или других форм.

Пример: Форма «Отгрузки» может иметь следующие поля: НомерТТН, ДатаОтгрузки, выпадающий список для выбора НомерДоговора (связанный с таблицей «Договоры»), выпадающий список для выбора КодПродукции (связанный с таблицей «Продукция»), Количество. Поле СуммаОтгрузки может быть отображено как вычисляемое и заблокировано для ручного ввода.

Разработка программных расширений (VBA/Макросы)

Хотя MS Access предоставляет обширные возможности без программирования, для реализации более сложной логики, автоматизации рутинных задач и создания по-настоящему интерактивной системы часто требуется использование программных расширений. Это могут быть макросы или, что гораздо мощнее, код на Visual Basic for Applications (VBA).

Макросы Access:
Макросы — это последовательности команд, которые можно запускать по определённым событиям (например, по нажатию кнопки, при открытии формы, при изменении значения поля). Они идеально подходят для простых автоматизированных действий:

• Открытие/закрытие форм и отчётов.
• Выполнение запросов.
• Отображение сообщений пользователю.
• Простые проверки условий.

Пример: Создание макроса для кнопки «Показать Отчет о Недоплате», который запускает соответствующий отчет с запросом параметров.

Visual Basic for Applications (VBA):
VBA — это полноценный язык программирования, встроенный в MS Access (и другие приложения Microsoft Office). Он предоставляет значительно больше возможностей, чем макросы:

• Сложные вычисления: Реализация пользовательских функций для расчёта сложных финансовых показателей, которые не могут быть выполнены с помощью стандартных запросов.
• Автоматизация заполнения полей: Например, автоматическое заполнение ЦенаОтгрузки в форме «Отгрузки» при выборе КодПродукции, подтягивая текущую цену из таблицы «Продукция».
• Динамическое создание объектов: Программное создание или изменение таблиц, запросов, форм и отчётов во время выполнения приложения.
• Взаимодействие с другими приложениями: Обмен данными с Excel, Word, Outlook для генерации писем должникам или экспорта отчётов.
• Расширенная валидация данных: Более сложные проверки вводимых данных, чем те, что предоставляются свойствами полей. Например, проверка, что общая сумма платежей по договору не превышает общую сумму отгрузок.
• Обработка событий: Более гибкое реагирование на действия пользователя, чем в макросах.

Пример VBA-кода для автоматического заполнения поля ЦенаОтгрузки в форме «Отгрузки» при изменении КодПродукции (событие AfterUpdate для поля КодПродукции):

Private Sub КодПродукции_AfterUpdate()
    If Not IsNull(Me.КодПродукции) Then
        ' Находим цену продукта из таблицы "Продукция"
        Me.ЦенаОтгрузки = DLookup("Цена", "Продукция", "КодПродукции = " & Me.КодПродукции)
        ' Пересчитываем СуммуОтгрузки
        If Not IsNull(Me.Количество) Then
            Me.СуммаОтгрузки = Me.Количество * Me.ЦенаОтгрузки
        End If
    Else
        Me.ЦенаОтгрузки = Null
        Me.СуммаОтгрузки = Null
    End If
End Sub

Private Sub Количество_AfterUpdate()
    If Not IsNull(Me.Количество) And Not IsNull(Me.ЦенаОтгрузки) Then
        Me.СуммаОтгрузки = Me.Количество * Me.ЦенаОтгрузки
    Else
        Me.СуммаОтгрузки = Null
    End If
End Sub

Этот простой пример демонстрирует, как VBA позволяет сделать систему более «умной» и удобной для пользователя, уменьшая количество ручных операций и потенциальных ошибок.

Анализ результатов и формирование отчетности

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

Формы отчетности и визуализации данных

Отчёты в MS Access — это конечный продукт, который представляет обработанные данные в удобном для чтения и анализа виде. Они могут содержать таблицы, графики, итоговые суммы и другую агрегированную информацию, сгруппированную по различным критериям. Для нашей задачи они станут основным средством для визуализации проблем неполной оплаты и дебиторской задолженности.

Цели создания отчётов:

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

Инструменты Access для создания отчётов:

1. Мастер отчётов: Позволяет быстро создать отчёт, пошагово отвечая на вопросы о выборе источника данных (таблицы или запроса), полей, группировки, сортировки и макета. Идеально подходит для стандартных отчётов.
2. Конструктор отчётов: Предоставляет полную свободу в дизайне. Здесь можно вручную размещать элементы управления, добавлять вычисляемые поля, настраивать форматирование, вставлять графики и изображения.

Отчет по неполной оплате отгруженной продукции

Это центральный отчёт нашей системы. Он должен наглядно демонстрировать, кто, сколько и по каким договорам не доплатил.

Структура и содержание отчёта:

• Заголовок отчёта: «Отчёт о неполной оплате отгруженной продукции за [Месяц Год]».
• Параметры отчёта: Указание периода (месяц) и, возможно, выбранного заказчика.
• Группировка по заказчикам: Основная группировка, позволяющая видеть общую картину по каждому клиенту.
  • НазваниеЗаказчика
• Группировка по договорам: Внутри каждого заказчика детализация по отдельным договорам.
  • НомерДоговора
  • ДатаДоговора
• Детализация по строкам (может быть скрыта по умолчанию):
  • НомерТТН (если нужна детальная информация по каждой накладной)
  • ДатаОтгрузки
  • СуммаОтгрузки
  • НомерПП (если нужна детальная информация по каждому платежу)
  • ДатаПлатежа
  • СуммаПлатежа
• Сводные данные для каждого договора:
  • Итого Сумма Отгрузок по договору: Суммируются все отгрузки по данному договору за период.
  • Итого Сумма Платежей по договору: Суммируются все платежи по данному договору за период.
  • Недоплата по договору: Разница между суммой отгрузок и суммой платежей по договору.
• Сводные данные для каждого заказчика:
  • Общая недоплата по заказчику: Сумма недоплат по всем договорам данного заказчика.
• Общие итоги:
  • Итоговая недоплата по всем заказчикам за период.

Пример вывода отчёта (схематично):

Отчет о неполной оплате отгруженной продукции за Октябрь 2025
Заказчик: ООО «Альфа»
Договор: 123/А от 01.01.2025
Сумма отгрузок:	150 000 руб.
Сумма платежей:	100 000 руб.
Недоплата по договору:	50 000 руб.
Договор: 456/Б от 15.03.2025
Сумма отгрузок:	200 000 руб.
Сумма платежей:	200 000 руб.
Недоплата по договору:	0 руб.
ИТОГО по заказчику ООО «Альфа»:	50 000 руб.
Заказчик: ЗАО «Бета»
Договор: 789/В от 10.02.2025
Сумма отгрузок:	120 000 руб.
Сумма платежей:	50 000 руб.
Недоплата по договору:	70 000 руб.
ИТОГО по заказчику ЗАО «Бета»:	70 000 руб.
ОБЩАЯ НЕДОПЛАТА ЗА ОКТЯБРЬ 2025:	120 000 руб.

Этот отчёт будет строиться на основе запроса, аналогичного представленному в разделе «Алгоритмы и SQL-запросы», но, возможно, с дополнительными полями и группировками.

Анализ оборачиваемости дебиторской задолженности

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

Коэффициент оборачиваемости дебиторской задолженности (формула и расчет)

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

Формула расчета:

Коэффициент оборачиваемости = Выручка / Средняя дебиторская задолженность

Где:

• Выручка — это общая сумма выручки от продаж за анализируемый период (например, год).
• Средняя дебиторская задолженность — рассчитывается как среднее арифметическое дебиторской задолженности на начало и конец периода.
  Средняя дебиторская задолженность = (Дебиторская задолженность на начало периода + Дебиторская задолженность на конец периода) / 2

Пример расчета:

Предположим, у предприятия:

• Выручка за год = 15 000 000 руб.
• Дебиторская задолженность на начало года = 1 500 000 руб.
• Дебиторская задолженность на конец года = 2 500 000 руб.

1. Расчет средней дебиторской задолженности:
   Средняя дебиторская задолженность = (1 500 000 + 2 500 000) / 2 = 4 000 000 / 2 = 2 000 000 руб.
2. Расчет коэффициента оборачиваемости:
   Коэффициент оборачиваемости = 15 000 000 / 2 000 000 = 7.5 оборота.

Это означает, что за год дебиторская задолженность предприятия обернулась 7.5 раз.

Продолжительность оборота дебиторской задолженности (формула и расчет)

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

Продолжительность оборота дебиторской задолженности (в днях) показывает, за какой промежуток времени в среднем долги дебиторов становятся «живыми» деньгами. Чем меньше это число, тем быстрее деньги возвращаются в оборот предприятия.

Формула расчета:

Продолжительность оборота в днях = Количество дней в периоде / Коэффициент оборачиваемости дебиторской задолженности

Где:

• Количество дней в периоде — обычно 365 для года (или 360, в зависимости от принятой в учётной политике методики).
• Коэффициент оборачиваемости дебиторской задолженности — значение, рассчитанное ранее.

Пример расчета (продолжение предыдущего):

Используя ранее рассчитанный коэффициент оборачиваемости (7.5 оборота) и количество дней в году (365 дней):

Продолжительность оборота в днях = 365 / 7.5 ≈ 48.67 дней.

Таким образом, в среднем предприятие получает оплату от своих клиентов в течение 48-49 дней после отгрузки. Этот показатель можно сравнивать с установленными нормативными сроками оплаты по договорам, а также с аналогичными показателями конкурентов или прошлых периодов для оценки динамики. Это помогает не только выявить проблемы, но и своевременно корректировать политику работы с дебиторской задолженностью. Какой важный нюанс здесь упускается? Важно понимать, что «средняя» продолжительность может скрывать значительные отклонения по отдельным клиентам или типам продукции, требуя более глубокого анализа по сегментам. Для реализации этих расчетов в MS Access можно создать специальные запросы, которые будут агрегировать данные о выручке (сумме отгрузок за период) и дебиторской задолженности на начало и конец периода. Затем эти запросы могут быть использованы в отчётах для вывода рассчитанных коэффициентов.

Обеспечение целостности и безопасности данных

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

Обеспечение ссылочной целостности

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

Как Access обеспечивает ссылочную целостность:

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

1. Ключевые поля: Связанное поле главной таблицы (первичный ключ) должно быть либо первичным ключом, либо иметь уникальный индекс.
2. Типы данных: Связанные поля в обеих таблицах должны иметь один и тот же тип данных.
3. Локализация: Обе таблицы должны принадлежать одной базе данных Access.

Правила целостности данных, которые блокирует Access:

Когда ссылочная целостность включена, Access предотвращает следующие действия:

• Ввод «потерянных» данных: Невозможно ввести значение во внешнее ключевое поле подчиненной таблицы, если это значение отсутствует в первичном ключе главной таблицы. Например, нельзя создать запись об отгрузке по НомеруДоговора, которого нет в таблице «Договоры».
• Удаление связанных записей: Невозможно удалить запись из главной таблицы, если существуют связанные с ней записи в подчиненной таблице. Например, нельзя удалить запись о заказчике, если по нему существуют активные договоры.
• Изменение первичного ключа: Невозможно изменить значение первичного ключа в главной таблице, если существуют связанные с этим значением записи в подчиненной таблице. Например, нельзя изменить КодПродукции в таблице «Продукция», если этот продукт фигурирует в каких-либо отгрузках.

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

Методы обеспечения безопасности данных в MS Access

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

1. Установка пароля на базу данных:
   • Суть: Это простейший и самый базовый способ защиты. При установке пароля база данных шифруется, и для её открытия требуется ввод этого пароля.
   • Ограничения: После успешного ввода пароля вся база данных становится полностью доступной для пользователя. Это не обеспечивает гранулярного контроля доступа к отдельным объектам (таблицам, запросам, формам, отчётам). Подходит для однопользовательских систем или систем с низкими требованиями к безопасности.
2. Защита на уровне пользователей (УРВ — Управление Разрешениями Пользователей):
   • Суть: Это более гибкий и мощный механизм, позволяющий администратору базы данных назначать различные права доступа (чтение, запись, изменение, удаление, проектирование) для конкретных пользователей или групп пользователей к отдельным объектам базы данных.
   • Механизм: Информация о пользователях, группах и их разрешениях хранится в специальном файле рабочей группы (.mdw или .mda). Пользователи идентифицируются по имени и паролю при входе в систему.
   • Преимущества: Позволяет настроить детальное разграничение доступа. Например, одному отделу разрешено только просматривать отчёты, другому — вводить данные об отгрузках, а финансовому отделу — редактировать платежи.
   • Ограничения: В современных версиях Access (начиная с Access 2007) этот функционал значительно сокращён или вовсе отсутствует для новых форматов баз данных (.accdb), ориентируясь на безопасность на уровне файловой системы или сервера при использовании Access как фронтенда для серверных БД (SQL Server). Однако для старых форматов (.mdb) и некоторых решений он всё ещё актуален.
3. Сохранение базы данных как файл MDE/ACCDE:
   • Суть: Базу данных можно сохранить в формате MDE (для .mdb файлов) или ACCDE (для .accdb файлов). При этом удаляется изменяемая программа Visual Basic for Applications (VBA), а также возможность просмотра и изменения структуры форм, отчётов и модулей.
   • Преимущества: Защищает интеллектуальную собственность (код VBA) и предотвращает непреднамеренные или злонамеренные изменения дизайна пользовательского интерфейса и логики.
   • Ограничения: Пользователи не смогут вносить изменения в дизайн объектов, что может быть нежелательно для разработчиков или продвинутых пользователей.
4. Шифрование базы данных:
   • Суть: В Access 2010 и более поздних версиях реализована усовершенствованная технология шифрования, использующая более сильные алгоритмы. Шифрование делает данные нечитаемыми для тех, кто пытается получить к ним доступ вне Access (например, открывая файл в текстовом редакторе).
   • Преимущества: Добавляет ещё один уровень защиты данных в состоянии покоя (когда база данных хранится на диске).
5. Аутентификация и авторизация:
   • Аутентификация: Процесс проверки подлинности пользователя (кто вы?). В Access это может быть пароль пользователя или, в случае интеграции с доменными службами, проверка учётных данных Windows.
   • Авторизация: Процесс определения прав пользователя (что вы можете делать?). Это реализуется через защиту на уровне пользователей или другие механизмы разграничения доступа.
6. Мониторинг и аудит:
   • Суть: Хотя Access не имеет встроенных мощных средств аудита, как серверные СУБД, можно программно (с помощью VBA) реализовать логирование критически важных операций (кто, когда и что изменил в данных).
   • Преимущества: Помогает выявлять подозрительную активность, отслеживать изменения данных и обеспечивать подотчётность.
7. Физический доступ:
   • Суть: Самый базовый, но часто недооцениваемый аспект. Физическая защита сервера или компьютера, на котором хранится файл базы данных, от несанкционированного доступа.
   • Преимущества: Предотвращает прямой доступ к файлу БД, который может обойти многие программные меры безопасности.

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

Интеграция разработанной системы с существующими бизнес-процессами предприятия

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

Роль интеграции информационных систем

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

Для нашей системы учёта неполной оплаты, разработанной в MS Access, интеграция с другими системами (например, бухгалтерскими программами, ERP-системами или CRM) имеет ряд критических преимуществ:

• Повышение точности и скорости обработки данных: Ручной перенос данных из одной системы в другую чреват ошибками и занимает много времени. Интеграция позволяет синхронизировать данные в реальном или почти реальном времени, обеспечивая их актуальность и точность. Например, информация об отгрузках может автоматически передаваться из учётной системы в нашу БД Access.
• Снижение количества ошибок: Автоматизация обмена данными минимизирует человеческий фактор, исключая опечатки и пропуски, которые неизбежны при ручном вводе.
• Экономия времени и ресурсов: Сотрудникам не нужно тратить время на дублирующий ввод информации, что позволяет им сосредоточиться на более важных, аналитических задачах.
• Консолидация данных и создание единого представления о бизнесе: Интегрированные системы предоставляют целостную картину деятельности предприятия, позволяя принимать более обоснованные управленческие решения на основе всесторонней и актуальной информации. Например, руководство сможет видеть не только данные о недоплате, но и связанные с ними данные из CRM о взаимодействии с клиентом.

Методы интеграции данных

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

1. Общая база данных:
   • Суть: Все подсистемы (ERP, CRM, наша система учёта) работают с одной, централизованной базой данных. Изменения, внесённые одной системой, мгновенно становятся доступными для всех остальных.
   • Применимость: Характерно для крупных корпоративных платформ (например, SAP, 1С:Предприятие), где MS Access может выступать как клиентское приложение (фронтенд) для серверной БД (например, SQL Server), где и хранятся общие данные. Наша система в Access может подключаться к этой общей БД и использовать её таблицы напрямую.
   • Преимущества: Максимальная согласованность данных, отсутствие дублирования, высокая скорость доступа.
   • Недостатки: Высокие требования к архитектуре, безопасности и управлению транзакциями.
2. Файловый обмен (Импорт/Экспорт):
   • Суть: Данные передаются между системами через промежуточные файлы различных форматов (CSV, XML, Excel, TXT). Одна система экспортирует данные в файл, другая импортирует их.
   • Применимость: Наиболее простой и распространённый метод для MS Access. Например, данные об отгрузках из бухгалтерской программы могут выгружаться в Excel-файл, который затем импортируется в нашу базу Access для дальнейшего анализа. Или, наоборот, отчёт о недоплате из Access может быть экспортирован в Excel для дальнейшей обработки или визуализации.
   • Преимущества: Простота реализации, низкая стоимость, подходит для массовой загрузки данных, не требует глубоких знаний сетевых технологий.
   • Недостатки: Риск ошибок при форматировании файлов, данные неактуальны в реальном времени (нужен регулярный импорт/экспорт), высокая вероятность дублирования и несогласованности данных при отсутствии строгих правил обмена.
3. Дистанционный вызов процедур (RPC, SOAP/REST):
   • Суть: Системы взаимодействуют напрямую друг с другом через стандартизированные программные интерфейсы (API — Application Programming Interface). Одна система отправляет запрос другой системе, которая выполняет определённую функцию и возвращает результат.
   • Технологии:
     • RPC (Remote Procedure Call): Позволяет одной программе вызвать процедуру или функцию в другой программе, расположенной на другом компьютере в сети.
     • SOAP (Simple Object Access Protocol): Протокол обмена структурированной информацией в распределённых вычислительных средах, часто используется для веб-сервисов.
     • REST (Representational State Transfer): Архитектурный стиль для построения распределённых систем, широко используемый в современных веб-сервисах (REST API).
   • Применимость: Для MS Access прямая реализация таких методов без дополнительных надстроек или программирования на других языках может быть сложной. Однако Access может использовать данные из внешних источников, подключенных через ODBC (Open Database Connectivity) или OLE DB, которые, в свою очередь, могут быть связаны с API. VBA-модули в Access могут быть использованы для отправки HTTP-запросов к REST API или для работы с XML-документами (SOAP).
   • Преимущества: Обмен данными в реальном времени, высокая гибкость, строгая стандартизация, высокая степень автоматизации.
   • Недостатки: Высокая сложность реализации, требует экспертизы в программировании и знание протоколов.

Интеграция разработанной в MS Access системы с существующими бизнес-процессами предприятия, скорее всего, будет начинаться с файлового обмена (импорта отгрузок и экспорта отчётов), а при развитии системы и инфраструктуры может эволюционировать в сторону более сложных методов, таких как подключение к общей базе данных или использование API через VBA. Цель — не просто автоматизировать одну функцию, а сделать её частью единого, эффективного организма предприятия.

Заключение

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

Мы начали с определения фундаментальных терминов, таких как база данных, СУБД, дебиторская задолженность и неполная оплата, заложив терминологический базис. Далее, особое внимание было уделено принципам проектирования реляционных баз данных, включая подробный разбор ER-модели и процесса нормализации. Детальное объяснение аномалий (модификации, удаления, добавления) и рассмотрение нормальных форм (1НФ, 2НФ, 3НФ, НФБК) позволили обосновать выбор структуры таблиц, обеспечивающей минимизацию избыточности и высокую целостность данных.

Анализ предметной области позволил идентифицировать ключевые бизнес-процессы, связанные с движением продукции и денежных средств, что стало основой для разработки логической структуры базы данных. Мы спроектировали пять сущностей — «Заказчики», «Продукция», «Договоры», «Отгрузки» и «Платежи» — и установили между ними корректные взаимосвязи, обеспечив соблюдение 3НФ и ссылочной целостности.

Практическая реализация системы в MS Access была представлена как последовательный алгоритм, включающий создание таблиц, схемы данных, запросов, форм ввода/вывода, а также рассмотрение возможностей программных расширений на VBA для автоматизации и повышения интерактивности. Ключевым достижением стал разработанный алгоритм и пример SQL-запроса, позволяющего точно выявлять и рассчитывать неполную оплату по каждому заказчику и договору за заданный период.

Раздел по анализу результатов продемонстрировал, как преобразовывать сырые данные в осмысленную отчётность. Мы описали структуру отчёта по неполной оплате, а также методы расчёта и интерпретации важнейших финансовых показателей — коэффициента оборачиваемости дебиторской задолженности и продолжительности оборота в днях. Эти инструменты дают руководству предприятия ценную информацию для принятия своевременных управленческих решений.

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

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

Дальнейшие направления развития и улучшения информационной системы могут включать:

• Расширение аналитических возможностей: Добавление графических отчётов (диаграмм) для визуализации динамики задолженности, сравнение показателей с плановыми значениями или отраслевыми бенчмарками.
• Реализация системы напоминаний: Автоматическая генерация уведомлений или писем для заказчиков с просроченной или неполной оплатой с использованием VBA и интеграции с Outlook.
• Разработка модуля прогнозирования: Использование исторических данных для прогнозирования будущей дебиторской задолженности и оценки рисков.
• Улучшение пользовательского интерфейса: Создание более сложного навигационного меню и дашбордов для быстрого доступа к ключевым показателям.
• Миграция на серверную СУБД: По мере роста предприятия и увеличения объёма данных, а также требований к многопользовательскому доступу и производительности, целесообразным может стать переход на более мощные СУБД, такие как SQL Server, PostgreSQL или MySQL, с сохранением MS Access в качестве клиентского приложения.

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

Список использованной литературы

1. Балдин К.В. Информационные технологии в менеджменте: учебник. М.: Издательский центр «Академия», 2012. 288 с.
2. Дейт К. Введение в системы баз данных: проектирование. Реализация и управление. СПб.: БХВ-Петербург, 2004. 324 с.
3. Карпова Т.С. Базы данных: модели, разработка, реализация: учебник для вузов. СПб.: Питер, 2002. 303 с.
4. Коннолли Т., Бегг К. Базы данных: Проектирование, реализация и сопровождение: Теория и практика. 2-е изд., испр. и доп. М.: Вильямс, 2003. 1111 с.
5. Кошелев В.Е. Access 2007. Эффективное использование. М.: Бином-Пресс, 2009. 590 с.
6. Кузнецов С.Д. Основы баз данных. 2-е изд. М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. 484 с.
7. Малыхина М.П. Базы данных: основы, проектирование, использование. 2-е изд. перераб. и доп. СПб.: БХВ-Петербург, 2007. 528 с.
8. Мак-Дональд М. Access 2007 Недостающее руководство. СПб.: БХВ-Петербург, 2007. 784 с.
9. Проектирование баз данных. СУБД Microsoft Access: Учебное пособие для вузов / Н.Н. Гринченко, Е.В. Гусев, Н.П. Макаров, А.Н. Пылькин, Н.И. Цуканова. М.: Горячая линия-Телеком, 2004. 240 с.
10. Сергеев А.В. Access 2007. Новые возможности. СПб.: Питер, 2008. 176 с.
11. Сеннов А. Access 2010. СПб.: Питер, 2010. 288 с.
12. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. 6-е изд. СПб.: КОРОНА принт, 2009. 736 с.
13. Что такое СУБД? Наиболее популярные СУБД. URL: https://www.nic.ru/help/what-is-dbms/ (дата обращения: 01.11.2025).
14. Что такое база данных. URL: https://azure.microsoft.com/ru-ru/resources/cloud-computing-dictionary/what-is-a-database (дата обращения: 01.11.2025).
15. Что такое дебиторская задолженность в бухгалтерском учете? Виды и примеры. URL: https://www.freshbooks.com/ru-ru/accounting/what-is-accounts-receivable (дата обращения: 01.11.2025).
16. Система управления базами данных (СУБД): что это такое и зачем нужна — Cloud.ru. URL: https://cloud.ru/ru/docs/cloud-native/dbms/what-is-dbms (дата обращения: 01.11.2025).
17. База данных, банк данных. URL: https://uchebnikirus.com/informatika/osnovi_inf_tex_ucheb/153_baza_dannyh_bank_dannyh.htm (дата обращения: 01.11.2025).
18. СУБД: что это, виды, структура, функции — где и как используются системы управления базами данных, примеры — Яндекс Практикум. URL: https://practicum.yandex.ru/blog/chto-takoe-subd/ (дата обращения: 01.11.2025).
19. СУБД — что это: Системы Управления Базами Данных — Skillfactory media. URL: https://skillfactory.ru/media/subd-chto-eto-sistemy-upravleniya-bazami-dannyh (дата обращения: 01.11.2025).
20. Что такое базы данных, и зачем им СУБД и SQL — Skillfactory media. URL: https://skillfactory.ru/media/chto-takoe-bazy-dannyh (дата обращения: 01.11.2025).
21. СУБД (Системы управления базами данных) — что это, какие бывают — itglobal. URL: https://itglobal.com/ru/company/blog/chto-takoe-subd-i-kakie-byvayut/ (дата обращения: 01.11.2025).
22. Дебиторская задолженность в бухгалтерском учете: виды, причины возникновения. URL: https://journal.tinkoff.ru/debitor-credit/ (дата обращения: 01.11.2025).
23. Что такое база данных? Определение, типы, преимущества — Astera Software. URL: https://www.astera.com/ru/resources/data-integration-database-definition/ (дата обращения: 01.11.2025).
24. Дебиторская задолженность—что это, отражение в бухучете и балансе — Бухэксперт. URL: https://buh.ru/articles/89914/ (дата обращения: 01.11.2025).
25. Нормализация базы данных, основные принципы и цель нормализации. URL: https://studfile.net/preview/4172782/page:14/ (дата обращения: 01.11.2025).
26. Введение в системы баз данных — Википедия. URL: https://ru.wikipedia.org/wiki/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 01.11.2025).
27. Крис Дейт. Введение в базы данных. Шестое издание. Киев, Диалектика, 1998. URL: http://www.open-oracle.ru/articles/date.html (дата обращения: 01.11.2025).
28. Дебиторская задолженность в бухгалтерском учете — Контур.Бухгалтерия. URL: https://kontur.ru/articles/3284 (дата обращения: 01.11.2025).
29. Дебиторская задолженность — Главная книга. URL: https://glavkniga.ru/situations/s508682 (дата обращения: 01.11.2025).
30. Базы данных: модели, разработка, реализация. URL: https://book.ru/book/915725 (дата обращения: 01.11.2025).
31. Базы данных. Кузнецов С.Д. URL: https://alleng.org/d/comp/comp779.htm (дата обращения: 01.11.2025).
32. Базы данных. Учебное пособие — И. Карпова. URL: https://www.labirint.ru/books/299066/ (дата обращения: 01.11.2025).
33. Базы данных. Кузнецов С.Д. URL: https://alleng.org/d/comp/comp6.htm (дата обращения: 01.11.2025).
34. Базы данных. Кузнецов С.Д. URL: https://books.google.ru/books/about/%D0%91%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85.html?id=lWf1AgAAQBAJ (дата обращения: 01.11.2025).
35. Основные этапы разработки базы данных в среде MS Access. URL: https://taurion.ru/lectures/ms-access/osnovnye-etapy-razrabotki-bazy-dannykh-v-srede-ms-access (дата обращения: 01.11.2025).
36. Примеры и принципы нормализации реляционных баз данных (БД) | DecoSystems. URL: https://decosys.ru/blog/normalizaciya-baz-dannyx/ (дата обращения: 01.11.2025).
37. Основы баз данных. URL: https://www.intuit.ru/studies/courses/652/508/lecture/11797 (дата обращения: 01.11.2025).
38. Дейт Введение в Системы Баз Данных. URL: https://www.ozon.ru/product/deyt-vvedenie-v-sistemy-baz-dannyh-172166567/ (дата обращения: 01.11.2025).
39. Базы данных — Издательский центр «Академия». URL: http://www.academia-moscow.ru/ftp_share/files/fragment_33758.pdf (дата обращения: 01.11.2025).
40. Нормализация базы данных: для чего нужна нормализованная бд | GitVerse Blog. URL: https://gitverse.ru/blog/normalizaciya-bazy-dannyh (дата обращения: 01.11.2025).
41. Введение в системы баз данных. Дейт, К. URL: https://alleng.org/d/comp/comp136.htm (дата обращения: 01.11.2025).
42. Введение в системы баз данных. Том 2. Классическое издание К. Дейт. URL: https://www.labirint.ru/books/995206/ (дата обращения: 01.11.2025).
43. Базы данных — DBS. URL: http://dbs.miem.edu.ru/files/2016/09/%D0%91%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5.pdf (дата обращения: 01.11.2025).
44. Создание информационной системы в среде MS Access. URL: https://www.uchportal.ru/load/275-1-0-28045 (дата обращения: 01.11.2025).
45. Основные этапы разработки базы данных в среде MS Access. URL: https://studfile.net/preview/6166548/page:4/ (дата обращения: 01.11.2025).
46. Базы данных: модели, разработка, реализация — ЭБС Лань. URL: https://e.lanbook.com/book/100575 (дата обращения: 01.11.2025).
47. Базы данных : модели, разработка, реализация: учебное пособие Карпова Т. С. URL: https://urait.ru/book/bazy-dannyh-modeli-razrabotka-realizaciya-412239 (дата обращения: 01.11.2025).
48. Анализ дебиторской и кредиторской задолженности: зачем нужен, как провести | Нескучные финансы. URL: https://nfin.ru/baza-znaniy/analiz-debitorskoy-i-kreditorskoy-zadolzhennosti-zachem-nuzhen-kak-provesti (дата обращения: 01.11.2025).
49. Дебиторская задолженность: понятие, методы анализа, управление. URL: https://cyberleninka.ru/article/n/debitorskaya-zadolzhennost-ponyatie-metody-analiza-upravlenie (дата обращения: 01.11.2025).
50. Модель «сущность — связь», Компоненты ER-диаграммы — Основы проектирования баз данных. URL: https://uchebnikirus.com/informatika/osnovi_proekt_baz_dannyh/model_suschnost_svyaz_komponenty_er_diagrammy.htm (дата обращения: 01.11.2025).
51. Создание базы данных MS Access — урок. Информатика, 11 класс. — ЯКласс. URL: https://www.yaklass.ru/p/informatika/11-klass/bazy-dannykh-i-subd-329486/sozdanie-bazy-dannykh-ms-access-288219/re-d36c5b96-b6d9-48e0-a42e-dd132f814b74 (дата обращения: 01.11.2025).
52. Методы анализа дебиторской задолженностью. URL: https://cyberleninka.ru/article/n/metody-analiza-debitorskoy-zadolzhennostyu (дата обращения: 01.11.2025).
53. Методика анализа дебиторской и кредиторской задолженностей — Аллея науки. URL: https://alley-science.ru/domains_data/files/12December2021/metodika%20analiza%20debitorskoj%20i%20kreditorskoj%20zadolzhennostej.pdf (дата обращения: 01.11.2025).
54. Анализ дебиторской и кредиторской задолженности — Управляем предприятием. URL: https://upravlyaem.com/articles/analiz-debitorskoy-i-kreditorskoy-zadolzhennosti.html (дата обращения: 01.11.2025).
55. Этапы проектирования базы данных — Stfw.Ru. URL: http://stfw.ru/pages/etapy-proektirovanija-bazy-dannyh.html (дата обращения: 01.11.2025).
56. Модель «сущность-связь». — БАЗЫ ДАННЫХ и СУБД. URL: http://www.vneshtorg.spb.ru/lectures/296.html (дата обращения: 01.11.2025).
57. Сущность-связь» (Entity-Relationship model, ER-модель). URL: https://www.rea.ru/ru/org/managements/izdanija/Documents/%D0%91%D0%B0%D0%B7%D1%8B%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85.pdf (дата обращения: 01.11.2025).
58. Нотации модели сущность-связь (ER диаграммы) — Блог программиста. URL: https://habr.com/ru/articles/577660/ (дата обращения: 01.11.2025).
59. Что такое ER-диаграмма и как ее создать? — Lucidchart. URL: https://www.lucidchart.com/pages/ru/chto-takoe-er-diagramma-i-kak-ee-sozdat (дата обращения: 01.11.2025).
60. Обеспечение целостности данных. URL: https://studfile.net/preview/6166548/page:8/ (дата обращения: 01.11.2025).
61. Базы данных. Хомоненко А.Д. и др. URL: https://alleng.org/d/comp/comp235.htm (дата обращения: 01.11.2025).
62. Целостность данных в Microsoft Access — Accesshelp.ru. URL: http://accesshelp.ru/celostnost_dannyx_v_microsoft_access/ (дата обращения: 01.11.2025).
63. Базы данных. Хомоненко А.Д. URL: https://alleng.org/d/comp/comp130.htm (дата обращения: 01.11.2025).
64. Безопасность баз данных. Средства защиты бд access. URL: https://studfile.net/preview/6166548/page:21/ (дата обращения: 01.11.2025).
65. Коннолли Томас, Бегг Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — StudMed.ru. URL: https://studmed.ru/konnolli-tomas-begg-karolin-bazy-dannyh-proektirovanie-realizaciya-i-soprovozhdenie-teoriya-i-praktika_1f5686fc6.html (дата обращения: 01.11.2025).
66. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — Коннолли, Бегг. URL: https://www.labirint.ru/books/579845/ (дата обращения: 01.11.2025).
67. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. — Базы данных. Учебник для высших учебных заведений (6-е изд.) — 2009. URL: https://studizba.com/files/show/1084484-homonenko-a-d-tsygankov-v-m-maltsev-m-g-bazy-dannyh-uchebnik-dlya-vysshih-uchebnyh-zavedeniy-6-e-izd-2009.html (дата обращения: 01.11.2025).
68. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. — Базы данных. Учебник для высших учебных заведений (6-е изд.) — 2009. URL: https://vuzlit.com/102073/homonenko_tsyganov_malcev_bazy_dannyh (дата обращения: 01.11.2025).
69. Карпова Т.С. Базы данных: модели, разработка, реализация — StudMed.ru. URL: https://studmed.ru/karpova-t-s-bazy-dannyh-modeli-razrabotka-realizaciya_1f728362d.html (дата обращения: 01.11.2025).
70. Microsoft Support. URL: https://support.microsoft.com/ru-ru/office/%D0%91%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%B2-access-2010-4ed2029c-a128-444a-a436-9b55239e083a (дата обращения: 01.11.2025).
71. Защита базы данных в Microsoft Access — Студенческий научный форум. URL: https://www.scienceforum.ru/2017/2502/27670 (дата обращения: 01.11.2025).
72. Дейт К.Дж. Введение в системы баз данных — StudMed.ru. URL: https://studmed.ru/deyt-k-dzh-vvedenie-v-sistemy-baz-dannyh_6489a24.html (дата обращения: 01.11.2025).
73. Базы данных: Проектирование, реализация и сопровождение. Теория и практика: Пер. с англ. URL: https://e.nlrs.ru/open/811 (дата обращения: 01.11.2025).
74. Вильямс книга Базы данных: проектирование, реализация и сопровождение. URL: https://www.williamspublishing.com/books/8459-00527-3/ (дата обращения: 01.11.2025).
75. Технологии интеграции: Общая БД, Файловый обмен, SOAP/REST — Systems.Education. URL: https://systems.education/integrations/ (дата обращения: 01.11.2025).
76. БД Access Оценка неполной оплаты отгруженной продукции заказчику за месяц. URL: https://www.dbforyou.ru/access/bd-access-ocenka-nepolnoj-oplaty-otgruzhennoj-produkcii-zakazchiku-za-mesyac/ (дата обращения: 01.11.2025).
77. Организация защиты данных в СУБД MS Access. URL: https://studfile.net/preview/6166548/page:11/ (дата обращения: 01.11.2025).
78. Интеграция с системами учета для автоматизации бизнеса — dabl24.ru. URL: https://dabl24.ru/blog/integratsiya-s-sistemami-ucheta/ (дата обращения: 01.11.2025).
79. Интеграция информационных систем предприятия — Интуит. URL: https://www.intuit.ru/studies/courses/770/626/lecture/14353 (дата обращения: 01.11.2025).
80. Кузнецов С.Д. — Базы данных — 6. Модели данных — YouTube. URL: https://www.youtube.com/watch?v=Jb6tJ3H5k0M (дата обращения: 01.11.2025).
81. Что такое интеграция баз данных? Обзор и преимущества — Astera Software. URL: https://www.astera.com/ru/resources/what-is-database-integration/ (дата обращения: 01.11.2025).
82. Защита баз данных на примере MS ACCESS — Bstudy. URL: https://bstudy.ru/other/zashchita-baz-dannykh-na-primere-ms-access.html (дата обращения: 01.11.2025).
83. Кузнецов С.Д. Основы современных баз данных — Лекция — Refdb.ru. URL: https://refdb.ru/look/1683353-pall.html (дата обращения: 01.11.2025).
84. STEP-BY-STEP formatting of the INVOICE report in Access — YouTube. URL: https://www.youtube.com/watch?v=NkF2JGAN440 (дата обращения: 01.11.2025).
85. Что такое интеграция данных? — SAP. URL: https://www.sap.com/mena/insights/what-is-data-integration.html (дата обращения: 01.11.2025).
86. Создание простого отчета — Служба поддержки Майкрософт — Microsoft Support. URL: https://support.microsoft.com/ru-ru/office/%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B3%D0%BE-%D0%BE%D1%82%D1%87%D0%B5%D1%82%D0%B0-ac253139-4467-4256-b08e-59c4708764b4 (дата обращения: 01.11.2025).
87. Объект Reports (Access) — Microsoft Learn. URL: https://learn.microsoft.com/ru-ru/office/vba/api/access.reports (дата обращения: 01.11.2025).
88. Отчет Microsoft Office Access | Руководство, Проектов, Исследование Информационные системы в экономике | Docsity. URL: https://www.docsity.com/ru/otchet-microsoft-office-access-rukovodstvo-proektov-issledovanie-informatsionnye-sistemy-v-ekonomike/7667232/ (дата обращения: 01.11.2025).