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

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

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

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

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

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

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

Предметом исследования выступает автоматизированная информационная система, предназначенная для анализа выполнения плана отгрузки продукции и выявления дефицита/излишков.

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

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

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

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

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

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

Далее рассмотрим понятие автоматизированной системы (АС). Это более широкое определение, охватывающее любую систему, где взаимодействие человека и машины направлено на выполнение определенных функций. АС состоит из персонала и комплекса средств автоматизации, работающих в тандеме. Частным случаем является автоматизированная информационная система (АИС), которая специально предназначена для организации, хранения и обработки данных. АИС могут выполнять различные функции: от загрузки и консолидации данных до их хранения и обработки, например, для проведения закупок или, как в нашем случае, для анализа отгрузки продукции.

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

Наконец, в контексте анализа выполнения плана отгрузки, критически важными являются понятия дефицита и излишков товарных запасов. Дефицит товарных запасов возникает тогда, когда спрос на определенный товар или продукцию превышает его предложение на рынке. Это может привести к ограниченному выбору для покупателей, полному отсутствию товаров на складе, а иногда и к росту цен из-за повышенного спроса. Последствия дефицита многогранны: это недополученная прибыль, прямые убытки, которые исчисляются упущенными продажами, ухудшение имиджа компании в глазах клиентов, потеря лояльности и, как следствие, рост продаж у конкурентов. Излишки товарных запасов, напротив, возникают, когда предложение товаров существенно превышает спрос. Это состояние также несет серьезные экономические риски. Избыточные запасы приводят к увеличению затрат на складское хранение (аренда, коммунальные услуги, зарплата персонала, страхование), связывают оборотные средства компании, тем самым снижая ее финансовую гибкость, и могут повлечь необходимость снижения цен или проведения акций для стимулирования продаж, а также потери от порчи, устаревания и уценки продукции. По оценкам, дефицит может составлять до 8% от общего оборота, а избыточные запасы — до 20% ассортимента в крупных торговых точках, что подчеркивает значимость точного планирования и управления. Из этого следует, что эффективная АИС не только фиксирует эти проблемы, но и позволяет оперативно реагировать на них, предотвращая финансовые потери и укрепляя рыночные позиции предприятия.

Методологии системного анализа и этапы проектирования ИС

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

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

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

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

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

Жизненный цикл разработки систем (SDLC, System Development Life Cycle) — это структурированный подход к созданию, внедрению и сопровождению информационных систем. Он обычно включает следующие этапы:

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

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

• Концептуальное (инфологическое) проектирование: Это самый высокий уровень абстракции. Цель — построить семантическую модель предметной области, которая описывает основные сущности и их взаимосвязи, не привязываясь к конкретной СУБД. На этом этапе происходит интенсивный сбор, анализ и редактирование требований к данным, формируется высокоуровневое представление о структуре информации.
• Логическое (даталогическое) проектирование: На этом этапе концептуальная модель преобразуется в модель данных, соответствующую выбранной модели (например, реляционной), но все еще без учета специфики конкретной СУБД. Определяются таблицы, поля, первичные и внешние ключи, типы связей, но не конкретные типы данных СУБД или физические параметры хранения.
• Физическое проектирование: Это последний и наиболее детализированный этап. Здесь определяются реальные структуры хранения данных на диске, выбирается конкретная СУБД (например, MS Access), разрабатывается подробная схема БД, задаются параметры таблиц, индексов, а также учитываются требования к производительности, безопасности и доступности данных.

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

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

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

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

Ключевые элементы ER-диаграммы:

• Сущность (entity): Это класс реальных или виртуальных однотипных объектов, информацию о которых необходимо хранить в базе данных. Например, «Продукция», «Клиенты», «Заказы». На ER-диаграммах сущности обычно обозначаются прямоугольником.
• Атрибут (attribute): Это свойство сущности, описывающее её характеристики. Например, для сущности «Продукция» атрибутами могут быть «Наименование», «Артикул», «Единица измерения».
• Связь (relationship): Это ассоциация или взаимодействие между двумя или более сущностями. Связи описывают, как сущности взаимодействуют друг с другом. Типы связей могут быть:
  • «один-к-одному» (1:1): каждая запись в одной таблице связана не более чем с одной записью в другой таблице.
  • «один-ко-многим» (1:М): одна запись в главной таблице может быть связана с несколькими записями в подчиненной таблице, но каждая запись в подчиненной таблице связана только с одной записью в главной.
  • «многие-ко-многим» (М:М): одна запись в главной таблице может быть связана с несколькими записями в подчиненной, и одна запись в подчиненной таблице может быть связана с несколькими записями в главной. Такие связи обычно разрешаются с помощью промежуточной таблицы.

Существуют различные популярные нотации для построения ER-диа��рамм, среди которых выделяются нотация Чена, «воронья лапка» (нотация Мартина) и UML (Unified Modeling Language). Нотация «воронья лапка» особенно распространена в индустрии благодаря своей наглядности и легкости чтения, что делает её идеальным выбором для сложных ER-диаграмм. ER-диаграммы могут быть как концептуальными, которые представляют высокоуровневое описание данных без привязки к конкретной СУБД, так и физическими, которые отображают всю структуру таблицы, включая названия столбцов, типы данных, ограничения, первичные и внешние ключи, что соответствует этапу физического проектирования БД.

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

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

Основные нормальные формы (НФ) представляют собой последовательный набор правил, которые помогают достичь оптимальной структуры базы данных:

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

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

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

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

Общая характеристика предметной области предприятия

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

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

Отдел логистики/сбыта играет ключевую роль в процессе отгрузки продукции. Его функции включают:

• Прием заказов от клиентов и формирование планов отгрузки.
• Координацию взаимодействия с производственными цехами для обеспечения своевременного выпуска продукции.
• Взаимодействие со складом готовой продукции для подготовки партий к отгрузке.
• Организацию транспортировки и контроль за доставкой продукции покупателям.
• Документальное оформление всех этапов отгрузки.

Основными видами деятельности предприятия, непосредственно влияющими на процесс отгрузки, являются:

1. Производство готовой продукции: Преобразование сырья и материалов в конечный продукт, соответствующий стандартам качества.
2. Складской учет: Прием готовой продукции из цехов, хранение, комплектация партий для отгрузки.
3. Продажи и отгрузка: Оформление заказов, формирование планов отгрузки, непосредственная отгрузка продукции клиентам.
4. Бухгалтерский учет: Отражение всех финансовых операций, связанных с производством, реализацией и отгрузкой.

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

• Низкая оперативность: Задержки в получении информации о фактических отгрузках и выполнении плана.
• Высокая вероятность ошибок: Человеческий фактор при ручном вводе и обработке данных.
• Сложность анализа: Трудности с быстрым получением сводной аналитики по дефициту/излишкам, выполнению планов по различным номенклатурным позициям или клиентам.
• Отсутствие централизованной базы данных: Информация хранится в разных источниках, что затрудняет ее консолидацию и использование для принятия управленческих решений.

Эти факторы подчеркивают актуальность разработки АИС, способной централизовать данные и автоматизировать процессы учета и анализа отгрузок.

Учетно-аналитические задачи: план отгрузки, дефицит и излишки

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

Учет готовой продукции охватывает весь жизненный цикл товара на складах предприятия:

1. Выпуск: Фиксация факта поступления готовой продукции из производственных цехов на склад. Важно, чтобы продукция соответствовала утвержденным стандартам или техническим условиям и была принята отделом технического контроля.
2. Движение на складах: Отслеживание внутренних перемещений продукции, например, между основными и резервными зонами хранения.
3. Отгрузка: Регистрация факта отправки продукции покупателям в соответствии с заключенными договорами и планами.
4. Реализация: Отражение момента перехода права собственности на продукцию к покупателю и получения оплаты.

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

• Контроль за выполнением договорных обязательств: Отслеживание соответствия фактических отгрузок условиям заключенных с покупателями договоров, включая сроки и объемы поставок.
• Своевременность расчетов с покупателями: Мониторинг дебиторской задолженности и обеспечение своевременного получения оплаты за отгруженную продукцию.
• Соблюдение норм запасов готовой продукции: Одна из критически важных задач. Поддержание оптимального уровня запасов позволяет избежать как дефицита, так и излишков. Недостаток товаров может привести к потере клиентов и упущенной выгоде, в то время как избыток замораживает оборотные средства и увеличивает затраты на хранение.
• Контроль сметы расходов по сбыту: Анализ затрат, связанных с логистикой, хранением и реализацией продукции, для их оптимизации.

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

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

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

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

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

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

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

Процесс движения готовой продукции начинается с ее изготовления в цехах. Выпуск готовой продукции на производственном предприятии фиксируется внутренним документом — «Отчет производства за смену». Этот документ агрегирует данные о количестве и номенклатуре выпущенной продукции за определенный период времени.

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

Кульминация процесса — отгрузка готовой продукции покупателям. Для оформления этой операции используются специальные накладные, которые должны содержать все обязательные реквизиты, предусмотренные Федеральным законом от 06.12.2011 №402-ФЗ «О бухгалтерском учете». Согласно этому закону, первичные учетные документы обязаны включать:

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

Типовой формой для отпуска готовой продукции покупателям исторически являлась форма № М-15 «Накладная на отпуск материалов на сторону», хотя в современном документообороте чаще используются другие формы. Основными документами, подтверждающими реализацию и отгрузку, являются товарная накладная (ТОРГ-12) или универсальный передаточный документ (УПД). УПД является более универсальным, так как он объединяет функции товарной накладной и счета-фактуры.

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

• По отпускным ценам (ценам реализации).
• По плановой себестоимости.
• По фактической себестоимости.

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

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

Постановка задачи на разработку АИС

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

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

Для достижения этой глобальной цели, система должна решать следующие задачи:

1. Централизованное хранение данных: Обеспечение единой точки хранения всей необходимой информации о продукции, клиентах, заказах, планах отгрузки и фактических отгрузках.
2. Автоматизация ввода и актуализации данных: Предоставление удобных пользовательских интерфейсов для быстрого и безошибочного ввода информации о поступлении продукции на склад, планах и фактах отгрузки.
3. Расчет и анализ выполнения плана: Автоматическое сравнение плановых показателей отгрузки с фактическими данными за определенные периоды (день, неделя, месяц, квартал).
4. Выявление и детализация отклонений: Оперативное определение дефицита (недопоставки) и излишков (перепоставки) продукции по каждой номенклатурной позиции, клиенту и заказу.
5. Формирование аналитических отчетов: Генерация наглядных и информативных отчетов, позволяющих руководству и соответствующим отделам (логистики, сбыта, бухгалтерии) быстро оценивать текущее состояние дел, выявлять проблемные зоны и принимать обоснованные решения.
6. Поддержание целостности данных: Обеспечение непротиворечивости и достоверности хранимой информации за счет использования механизмов СУБД (ссылочная целостность, правила проверки).
7. Базовая защита данных: Реализация мер по ограничению доступа к данным и предотвращению их несанкционированного изменения.

Функции, которые должна выполнять система:

• Ввод и хранение данных:
  • Справочник продукции (наименование, артикул, единица измерения).
  • Справочник клиентов (наименование, реквизиты, контактные данные).
  • Учет заказов/договоров с клиентами (номер, дата, плановый объем по продукции).
  • Учет плановых показателей отгрузки (дата, продукция, количество, клиент, заказ).
  • Учет фактических отгрузок (дата, продукция, количество, клиент, заказ, номер накладной).
  • Учет поступления готовой продукции на склад (дата, продукция, количество, номер отчета производства).
• Обработка данных:
  • Автоматический расчет фактического остатка готовой продукции на складе.
  • Сравнение плановых и фактических объемов отгрузки.
  • Расчет абсолютных и относительн��х отклонений (дефицит/излишки) по каждой позиции и заказу.
• Формирование отчетов:
  • Отчет о выполнении плана отгрузки за выбранный период (по номенклатуре, по клиентам).
  • Отчет о дефиците продукции (с указанием объема недопоставки и потенциальных упущенных продаж).
  • Отчет об излишках продукции (с указанием объема перепоставки и потенциальных затрат на хранение).
  • Сводный отчет по отгрузкам (по клиентам, по продукции, за период).
• Поддержка принятия решений:
  • Предоставление актуальной информации для корректировки производственных планов.
  • Выявление «узких мест» в логистической цепочке.
  • Оценка эффективности работы отдела сбыта.

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

Проектирование информационной системы

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

Выбор программных средств и обоснование их использования

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

Для реализации автоматизированной информационной системы учета и анализа выполнения плана отгрузки продукции на малом или среднем предприятии целесообразно использовать систему управления базами данных (СУБД) Microsoft Access.

Обоснование выбора MS Access:

1. Доступность и распространенность: MS Access является частью пакета Microsoft Office, который широко распространен на большинстве предприятий. Это означает, что для его использования, как правило, не требуется приобретение дополнительного дорогостоящего программного обеспечения, что критично для предприятий с ограниченным ИТ-бюджетом.
2. Простота освоения и использования: Access разработан для пользователей, не имеющих глубоких навыков программирования и администрирования баз данных. Интуитивно понятный графический интерфейс позволяет относительно быстро создавать таблицы, запросы, формы и отчеты. Это снижает порог входа для разработки и дальнейшего сопровождения системы.
3. Комплексное решение для малых и средних предприятий: Access предоставляет полный набор инструментов для создания настольных баз данных, включая функционал для:
   • Создания таблиц: Определения структуры данных, типов полей, первичных и внешних ключей.
   • Установки связей: Графическое отображение и поддержка ссылочной целостности между таблицами.
   • Разработки запросов: Инструменты для выборки, фильтрации, сортировки, агрегации и преобразования данных, включая возможность написания SQL-запросов.
   • Создания форм: Разработка удобных пользовательских интерфейсов для ввода, редактирования и просмотра данных без прямого взаимодействия с таблицами.
   • Построения отчетов: Гибкие инструменты для создания профессионально выглядящих аналитических отчетов, позволяющих группировать, суммировать и визуализировать данные.
   • Автоматизации с помощью макросов и VBA: Возможность создания простых автоматизированных действий (макросы) или написания более сложного кода на Visual Basic for Applications (VBA) для расширения функционала.
4. Низкие требования к аппаратным ресурсам: По сравнению с более мощными серверными СУБД (например, SQL Server, Oracle), Access имеет значительно более низкие требования к оборудованию, что делает его идеальным для использования на обычных офисных компьютерах.
5. Возможность многопользовательского доступа: Несмотря на то что Access является файловой СУБД, он поддерживает многопользовательский режим работы, хотя и с определенными ограничениями по одновременному количеству пользователей. Для малого и среднего предприятия, где количество операторов, одновременно работающих с базой данных отгрузки, невелико, этого функционала будет достаточно.

Ключевые особенности функционала MS Access, используемые в проекте:

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

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

Инфологическая (концептуальная) модель базы данных

Инфологическое проектирование — это первый и один из наиболее важных шагов в разработке базы данных. На этом этапе мы создаем высокоуровневое, абстрактное представление о данных предметной области, не привязываясь к конкретной СУБД. Главным инструментом здесь выступает ER-диаграмма, которая позволяет визуализировать ключевые сущности, их атрибуты и взаимосвязи.

Для предметной области «Учет отгрузки продукции» выделим следующие ключевые сущности:

1. Продукция (Product): Информация о товарах, производимых и отгружаемых предприятием.
2. Клиенты (Client): Информация о контрагентах, приобретающих продукцию.
3. Сотрудники (Employee): Сотрудники, ответственные за оформление отгрузок.
4. Единицы Измерения (UnitOfMeasure): Справочник единиц измерения для продукции.
5. Отчеты Производства (ProductionReport): Документы, фиксирующие выпуск готовой продукции.
6. Планы Отгрузки (ShipmentPlan): Запланированные объемы отгрузки по продукции и клиентам.
7. Отгрузки (Shipment): Фактические операции отгрузки продукции.
8. Строки Плана Отгрузки (ShipmentPlanItem): Детализация плана отгрузки по каждой номенклатурной позиции.
9. Строки Отгрузки (ShipmentItem): Детализация фактической отгрузки по каждой номенклатурной позиции.

Атрибуты для каждой сущности:

• Продукция:
  • Код_Продукции (первичный ключ, уникальный идентификатор)
  • Наименование_Продукции
  • Артикул
  • Код_Единицы_Измерения (внешний ключ к Единицы_Измерения)
  • Описание (необязательно)
• Клиенты:
  • Код_Клиента (первичный ключ)
  • Наименование_Клиента
  • ИНН
  • КПП
  • Юридический_Адрес
  • Фактический_Адрес
  • Телефон
  • Email
  • Контактное_Лицо
• Сотрудники:
  • Код_Сотрудника (первичный ключ)
  • Фамилия
  • Имя
  • Отчество
  • Должность
• Единицы_Измерения:
  • Код_Единицы_Измерения (первичный ключ)
  • Наименование_Единицы
  • Сокращение
• Отчеты_Производства:
  • Номер_Отчета_Производства (первичный ключ)
  • Дата_Отчета
  • Код_Продукции (внешний ключ к Продукция)
  • Количество_Выпуска
  • Код_Сотрудника (внешний ключ к Сотрудники, ответственный за отчет)
• Планы_Отгрузки:
  • Номер_Плана (первичный ключ)
  • Дата_Плана
  • Дата_Начала_Периода
  • Дата_Окончания_Периода
  • Код_Клиента (внешний ключ к Клиенты)
  • Код_Сотрудника (внешний ключ к Сотрудники, ответственный за план)
  • Статус_Плана (например, «Черновик», «Утвержден», «Выполнен»)
• Строки_Плана_Отгрузки: (Сущность для разрешения связи «многие-ко-многим» между Планами_Отгрузки и Продукцией)
  • Номер_Плана (часть составного первичного ключа, внешний ключ к Планы_Отгрузки)
  • Код_Продукции (часть составного первичного ключа, внешний ключ к Продукция)
  • Плановое_Количество
• Отгрузки:
  • Номер_Накладной (первичный ключ, например, ТОРГ-12 или УПД)
  • Дата_Отгрузки
  • Код_Клиента (внешний ключ к Клиенты)
  • Код_Сотрудника (внешний ключ к Сотрудники, ответственный за отгрузку)
  • Дата_Перехода_Права_Собственности (если отличается от даты отгрузки)
  • Счет_Бухгалтерского_Учета (например, 43 или 45)
• Строки_Отгрузки: (Сущность для разрешения связи «многие-ко-многим» между Отгрузками и Продукцией)
  • Номер_Накладной (часть составного первичного ключа, внешний ключ к Отгрузки)
  • Код_Продукции (часть составного первичного ключа, внешний ключ к Продукция)
  • Фактическое_Количество
  • Цена_За_Единицу
  • Сумма

Типы связей между сущностями (с использованием нотации «воронья лапка»):

• Продукция —< Единицы_Измерения: «Один-ко-многим»
  • Одна единица измерения может быть использована для многих видов продукции.
  • Каждый вид продукции имеет одну единицу измерения.
• Планы_Отгрузки —< Клиенты: «Один-ко-многим»
  • Один клиент может иметь множество планов отгрузки.
  • Каждый план отгрузки относится к одному клиенту.
• Планы_Отгрузки —< Сотрудники: «Один-ко-многим»
  • Один сотрудник может быть ответственным за множество планов отгрузки.
  • Каждый план отгрузки имеет одного ответственного сотрудника.
• Планы_Отгрузки >— Строки_Плана_Отгрузки —< Продукция: «Многие-ко-многим» разрешается через промежуточную сущность.
  • Один план отгрузки может включать множество видов продукции.
  • Одна продукция может входить во множество планов отгрузки.
• Отгрузки —< Клиенты: «Один-ко-многим»
  • Один клиент может иметь множество отгрузок.
  • Каждая отгрузка относится к одному клиенту.
• Отгрузки —< Сотрудники: «Один-ко-многим»
  • Один сотрудник может быть ответственным за множество отгрузок.
  • Каждая отгрузка имеет одного ответственного сотрудника.
• Отгрузки >— Строки_Отгрузки —< Продукция: «Многие-ко-многим» разрешается через промежуточную сущность.
  • Одна отгрузка может включать множество видов продукции.
  • Одна продукция может входить во множество отгрузок.
• Отчеты_Производства —< Продукция: «Один-ко-многим»
  • Один вид продукции может фигурировать во множестве отчетов производства.
  • Каждый отчет производства относится к одному виду продукции.
• Отчеты_Производства —< Сотрудники: «Один-ко-многим»
  • Один сотрудник может составлять множество отчетов производства.
  • Каждый отчет производства имеет одного составителя.

Концептуальная ER-диаграмма (примерное схематическое представление):

+----------------+       1|-----M+----------------------+       1|----M+----------------+
| Единицы_Измерения |         |       | Продукция         |         |      | Отчеты_Производства |
+----------------+         |       +----------------------+         |      +----------------+
| Код_Единицы_Измерения (PK)|         | - Код_Продукции (PK)  |         |      | Номер_Отчета_Производства (PK)|
| Наименование_Единицы   |         | - Наименование_Продукции  |         |      | Дата_Отчета         |
| Сокращение           |         | - Артикул             |         |      | Код_Продукции (FK)    |
+----------------+         |       | - Код_Единицы_Измерения (FK)|         |      | Количество_Выпуска  |
                           |       +----------------------+         |      | Код_Сотрудника (FK)   |
                           |                                        |      +----------------+
                           |                                        |
+----------------+         M|-----1+----------------------+       1|----M+----------------+
| Сотрудники     |         |       | Планы_Отгрузки      |         |      | Отгрузки        |
+----------------+         |       +----------------------+         |      +----------------+
| Код_Сотрудника (PK)|         |       | Номер_Плана (PK)      |         |      | Номер_Накладной (PK)|
| Фамилия          |         |       | Дата_Плана          |         |      | Дата_Отгрузки     |
| Имя              |         |       | Дата_Начала_Периода |         |      | Код_Клиента (FK)  |
| Отчество         |         |       | Дата_Окончания_Периода|         |      | Код_Сотрудника (FK)|
| Должность        |         |       | Код_Клиента (FK)    |         |      | Дата_Перехода_Права_Собственности|
+----------------+         |       | Код_Сотрудника (FK) |         |      | Счет_Бухгалтерского_Учета|
                           |       | Статус_Плана        |         |      +----------------+
                           |       +----------------------+         |
                           |                                        |
+----------------+         M|-----1+----------------------+       1|----M+----------------+
| Клиенты        |         |       | Строки_Плана_Отгрузки |         |      | Строки_Отгрузки   |
+----------------+         |       +----------------------+         |      +----------------+
| Код_Клиента (PK)  |         |       | Номер_Плана (PK, FK)  |         |      | Номер_Накладной (PK, FK)|
| Наименование_Клиента|         |       | Код_Продукции (PK, FK)|         |      | Код_Продукции (PK, FK)|
| ИНН              |         |       | Плановое_Количество   |         |      | Фактическое_Количество|
| КПП              |         |       +----------------------+         |      | Цена_За_Единицу   |
| Юридический_Адрес|                                                  |      | Сумма             |
| Фактический_Адрес|                                                  |      +----------------+
| Телефон          |                                                  |
| Email            |                                                  |
| Контактное_Лицо  |                                                  |
+----------------+                                                  |
                                                                    |
                                                                    +-------------------------------------------+
                                                                                                                |

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

Даталогическая (логическая) модель базы данных

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

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

1. Таблица «Единицы_Измерения»
   • Поля: Код_Единицы_Измерения (целое, первичный ключ), Наименование_Единицы (текст), Сокращение (текст).
   • Применение НФ: В 1НФ (атомарные значения), 2НФ (все неключевые поля зависят от ПК), 3НФ (нет транзитивных зависимостей).
   • Комментарий: Справочная таблица.
2. Таблица «Продукция»
   • Поля: Код_Продукции (целое, первичный ключ), Наименование_Продукции (текст), Артикул (текст), Код_Единицы_Измерения (целое, внешний ключ к «Единицы_Измерения»), Описание (текст).
   • Применение НФ: В 1НФ, 2НФ, 3НФ.
   • Комментарий: Справочник товаров.
3. Таблица «Клиенты»
   • Поля: Код_Клиента (целое, первичный ключ), Наименование_Клиента (текст), ИНН (текст), КПП (текст), Юридический_Адрес (текст), Фактический_Адрес (текст), Телефон (текст), Email (текст), Контактное_Лицо (текст).
   • Применение НФ: В 1НФ, 2НФ, 3НФ.
   • Комментарий: Справочник контрагентов.
4. Таблица «Сотрудники»
   • Поля: Код_Сотрудника (целое, первичный ключ), Фамилия (текст), Имя (текст), Отчество (текст), Должность (текст).
   • Применение НФ: В 1НФ, 2НФ, 3НФ.
   • Комментарий: Справочник персонала.
5. Таблица «Отчеты_Производства»
   • Поля: Номер_Отчета_Производства (целое, первичный ключ), Дата_Отчета (дата/время), Код_Продукции (целое, внешний ключ к «Продукция»), Количество_Выпуска (число), Код_Сотрудника (целое, внешний ключ к «Сотрудники»).
   • Применение НФ: В 1НФ, 2НФ, 3НФ.
   • Комментарий: Фиксация поступления продукции на склад.
6. Таблица «Планы_Отгрузки»
   • Поля: Номер_Плана (целое, первичный ключ), Дата_Плана (дата/время), Дата_Начала_Периода (дата/время), Дата_Окончания_Периода (дата/время), Код_Клиента (целое, внешний ключ к «Клиенты»), Код_Сотрудника (целое, внешний ключ к «Сотрудники»), Статус_Плана (текст).
   • Применение НФ: В 1НФ, 2НФ, 3НФ.
   • Комментарий: Заголовок документа плана.
7. Таблица «Строки_Плана_Отгрузки»
   • Поля: Номер_Плана (целое, часть составного первичного ключа, внешний ключ к «Планы_Отгрузки»), Код_Продукции (целое, часть составного первичного ключа, внешний ключ к «Продукция»), Плановое_Количество (число).
   • Применение НФ: Эта таблица является результатом декомпозиции связи «многие-ко-многим» между «Планы_Отгрузки» и «Продукция». Она находится в 1НФ, 2НФ, 3НФ.
   • Комментарий: Детализация плана отгрузки.
8. Таблица «Отгрузки»
   • Поля: Номер_Накладной (текст, первичный ключ), Дата_Отгрузки (дата/время), Код_Клиента (целое, внешний ключ к «Клиенты»), Код_Сотрудника (целое, внешний ключ к «Сотрудники»), Дата_Перехода_Права_Собственности (дата/время, может быть NULL), Счет_Бухгалтерского_Учета (текст).
   • Применение НФ: В 1НФ, 2НФ, 3НФ.
   • Комментарий: Заголовок документа отгрузки. Номер_Накладной может быть строковым, так как часто содержит буквенные префиксы.
9. Таблица «Строки_Отгрузки»
   • Поля: Номер_Накладной (текст, часть составного первичного ключа, внешний ключ к «Отгрузки»), Код_Продукции (целое, часть составного первичного ключа, внешний ключ к «Продукция»), Фактическое_Количество (число), Цена_За_Единицу (денежный), Сумма (денежный).
   • Применение НФ: Эта таблица является результатом декомпозиции связи «многие-ко-многим» между «Отгрузки» и «Продукция». Она находится в 1НФ, 2НФ, 3НФ.
   • Комментарий: Детализация фактической отгрузки. Сумма — вычисляемое поле (Фактическое_Количество * Цена_За_Единицу), но часто хранится для ускорения запросов.

Краткая сводка по нормализации:

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

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

Физическая модель базы данных (схема данных)

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

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

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

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

1. Таблица: tblЕдиницы_Измерения

Поле	Тип данных (Access)	Размер поля	Свойство
Код_Единицы_Измерения (PK)	Числовой, Целое	Длинное целое	Индексированное (без совпадений)
Наименование_Единицы	Текстовый	50	Обязательное поле
Сокращение	Текстовый	10	Обязательное поле

2. Таблица: tblПродукция

Поле	Тип данных (Access)	Размер поля	Свойство
Код_Продукции (PK)	Числовой, Целое	Длинное целое	Индексированное (без совпадений)
Наименование_Продукции	Текстовый	100	Обязательное поле
Артикул	Текстовый	20	Индексированное (допускаются совпадения)
Код_Единицы_Измерения (FK)	Числовой, Целое	Длинное целое	Обязательное поле
Описание	Текстовый	255

3. Таблица: tblКлиенты

Поле	Тип данных (Access)	Размер поля	Свойство
Код_Клиента (PK)	Числовой, Целое	Длинное целое	Индексированное (без совпадений)
Наименование_Клиента	Текстовый	150	Обязательное поле
ИНН	Текстовый	12	Индексированное (допускаются совпадения)
КПП	Текстовый	9
Юридический_Адрес	Текстовый	255
Фактический_Адрес	Текстовый	255
Телефон	Текстовый	50
Email	Текстовый	100
Контактное_Лицо	Текстовый	100

4. Таблица: tblСотрудники

Поле	Тип данных (Access)	Размер поля	Свойство
Код_Сотрудника (PK)	Числовой, Целое	Длинное целое	Индексированное (без совпадений)
Фамилия	Текстовый	50	Обязательное поле
Имя	Текстовый	50	Обязательное поле
Отчество	Текстовый	50
Должность	Текстовый	100

5. Таблица: tblОтчеты_Производства

Поле	Тип данных (Access)	Размер поля	Свойство
Номер_Отчета_Производства (PK)	Числовой, Целое	Длинное целое	Индексированное (без совпадений)
Дата_Отчета	Дата/время		Обязательное поле
Код_Продукции (FK)	Числовой, Целое	Длинное целое	Обязательное поле
Количество_Выпуска	Числовой, Целое	Длинное целое	Обязательное поле, ≥ 0
Код_Сотрудника (FK)	Числовой, Целое	Длинное целое	Обязательное поле

6. Таблица: tblПланы_Отгрузки

Поле	Тип данных (Access)	Размер поля	Свойство
Номер_Плана (PK)	Числовой, Целое	Длинное целое	Индексированное (без совпадений)
Дата_Плана	Дата/время		Обязательное поле
Дата_Начала_Периода	Дата/время		Обязательное поле
Дата_Окончания_Периода	Дата/время		Обязательное поле
Код_Клиента (FK)	Числовой, Целое	Длинное целое	Обязательное поле
Код_Сотрудника (FK)	Числовой, Целое	Длинное целое	Обязательное поле
Статус_Плана	Текстовый	50	Значения: «Черновик», «Утвержден», «Выполнен»

7. Таблица: tblСтроки_Плана_Отгрузки

Поле	Тип данных (Access)	Размер поля	Свойство
Номер_Плана (PK, FK)	Числовой, Целое	Длинное целое	Составной ПК, Обязательное поле
Код_Продукции (PK, FK)	Числовой, Целое	Длинное целое	Составной ПК, Обязательное поле
Плановое_Количество	Числовой, Целое	Длинное целое	Обязательное поле, ≥ 0

8. Таблица: tblОтгрузки

Поле	Тип данных (Access)	Размер поля	Свойство
Номер_Накладной (PK)	Текстовый	50	Индексированное (без совпадений)
Дата_Отгрузки	Дата/время		Обязательное поле
Код_Клиента (FK)	Числовой, Целое	Длинное целое	Обязательное поле
Код_Сотрудника (FK)	Числовой, Целое	Длинное целое	Обязательное поле
Дата_Перехода_Права_Собственности	Дата/время
Счет_Бухгалтерского_Учета	Текстовый	5	Значения: «43», «45»

9. Таблица: tblСтроки_Отгрузки

Поле	Тип данных (Access)	Размер поля	Свойство
Номер_Накладной (PK, FK)	Текстовый	50	Составной ПК, Обязательное поле
Код_Продукции (PK, FK)	Числовой, Целое	Длинное целое	Составной ПК, Обязательное поле
Фактическое_Количество	Числовой, Целое	Длинное целое	Обязательное поле, ≥ 0
Цена_За_Единицу	Денежный		Обязательное поле, ≥ 0
Сумма	Денежный		Вычисляемое поле или хранимое

Связи между таблицами (графическое представление в Схеме данных MS Access):

• tblПродукция (Код_Единицы_Измерения) <—> tblЕдиницы_Измерения (Код_Единицы_Измерения)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением связанных полей.
• tblПланы_Отгрузки (Код_Клиента) <—> tblКлиенты (Код_Клиента)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением связанных полей.
• tblПланы_Отгрузки (Код_Сотрудника) <—> tblСотрудники (Код_Сотрудника)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением связанных полей.
• tblОтгрузки (Код_Клиента) <—> tblКлиенты (Код_Клиента)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением связанных полей.
• tblОтгрузки (Код_Сотрудника) <—> tblСотрудники (Код_Сотрудника)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением связанных полей.
• tblОтчеты_Производства (Код_Продукции) <—> tblПродукция (Код_Продукции)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением связанных полей.
• tblОтчеты_Производства (Код_Сотрудника) <—> tblСотрудники (Код_Сотрудника)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением связанных полей.
• tblСтроки_Плана_Отгрузки (Номер_Плана) <—> tblПланы_Отгрузки (Номер_Плана)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением и каскадным удалением.
• tblСтроки_Плана_Отгрузки (Код_Продукции) <—> tblПродукция (Код_Продукции)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением.
• tblСтроки_Отгрузки (Номер_Накладной) <—> tblОтгрузки (Номер_Накладной)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением и каскадным удалением.
• tblСтроки_Отгрузки (Код_Продукции) <—> tblПродукция (Код_Продукции)
  • Тип связи: Один-ко-многим.
  • Обеспечение целостности: Да, с каскадным обновлением.

Примечание: Данное изображение является иллюстративным примером схемы данных в MS Access и должно быть заменено на скриншот реальной схемы, разработанной в рамках курсовой работы.

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

Реализация автоматизированной информационной системы

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

Создание таблиц и установка связей в MS Access

Первым шагом в реализации любой базы данных является создание её структурных элементов — таблиц. В MS Access этот процесс достаточно интуитивен и осуществляется через «Конструктор таблиц».

Пошаговое описание создания таблиц:

1. Запуск MS Access и создание новой базы данных:
   • Открыть MS Access.
   • Выбрать «Новая пустая база данных».
   • Указать имя файла (например, Uchet_Otgruzki.accdb) и место сохранения.
2. Создание первой таблицы (tblЕдиницы_Измерения):
   • В меню «Создание» выбрать «Таблица».
   • Переключиться в «Режим конструктора».
   • Задать имя таблицы: tblЕдиницы_Измерения.
   • Для поля Код_Единицы_Измерения выбрать тип данных «Счетчик» (чтобы Access автоматически генерировал уникальные номера) и установить его как первичный ключ (нажать кнопку «Ключевое поле»).
   • Для поля Наименование_Единицы выбрать тип данных «Короткий текст», установить размер поля 50 и свойство «Обязательное поле» — «Да».
   • Для поля Сокращение выбрать тип данных «Короткий текст», размер поля 10 и «Обязательное поле» — «Да».
   • Сохранить таблицу.
3. Создание остальных таблиц: Повторить шаги 2 для каждой таблицы из даталогической модели, тщательно выбирая типы данных, размеры полей и устанавливая свойства «Обязательное поле» и «Индексированное» в соответствии с разработанной схемой.
   • Для первичных ключей, где это уместно, можно использовать «Счетчик» для автоматической генерации. Если первичный ключ составной (например, в tblСтроки_Плана_Отгрузки), то для каждого поля, входящего в составной ключ, устанавливается индексация «Да (допускаются совпадения)», а затем выбираются все поля составного ключа и устанавливаются как первичный ключ.
   • Для полей, которые являются внешними ключами, тип данных должен строго соответствовать типу данных связанного первичного ключа. Например, если Код_Клиента в tblКлиенты — «Счетчик» (Длинное целое), то Код_Клиента в tblПланы_Отгрузки также должен быть «Числовой, Длинное целое».
   • Дополнительно для числовых полей, таких как Количество_Выпуска или Плановое_Количество, можно задать «Правило проверки» (≥0) и «Сообщение об ошибке» для обеспечения корректности ввода.

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

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

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

Пример связей в Схеме данных:

Примечание: Данное изображение является иллюстративным примером схемы данных в MS Access и должно быть заменено на скриншот реальной схемы, разработанной в рамках курсовой работы.

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

Разработка запросов для анализа плана отгрузки и выявления отклонений

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

Алгоритмы расчета дефицита и излишков продукции:

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

1. Плановое количество отгрузки (PQ_i): Суммарное плановое количество продукции i за определенный период.
2. Фактическое количество отгрузки (FQ_i): Суммарное фактическое количество отгруженной продукции i за тот же период.
3. Фактический остаток на складе (SO_i): Текущее количество продукции i на складе.

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

• Абсолютное отклонение (Δ_i):
  Δi = FQi - PQi

Выявление дефицита/излишков:

• Если Δ_i < 0, то имеется дефицит продукции i. Величина дефицита = |Δ_i|.
• Если Δ_i > 0, то имеется излишек продукции i. Величина излишка = Δ_i.
• Если Δ_i = 0, то план выполнен точно.

Относительное отклонение (δ_i):
δi = (Δi / PQi) * 100% (при PQi > 0)

Для расчета фактического остатка на складе по продукции i на текущую дату (или на конец периода):
SOi = Σ(Количество_Выпускаi) - Σ(Фактическое_Количествоi)

Рассмотрим примеры SQL-запросов в MS Access для реализации этих алгоритмов.

Пример 1: Запрос ��ля суммирования плановых объемов отгрузки за период

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

SELECT
    P.Наименование_Продукции,
    SUM(SP.Плановое_Количество) AS Плановое_Количество
FROM
    tblСтроки_Плана_Отгрузки AS SP
INNER JOIN
    tblПродукция AS P ON SP.Код_Продукции = P.Код_Продукции
INNER JOIN
    tblПланы_Отгрузки AS PL ON SP.Номер_Плана = PL.Номер_Плана
WHERE
    PL.Дата_Начала_Периода <= #2025-10-31# AND PL.Дата_Окончания_Периода >= #2025-10-01#
GROUP BY
    P.Наименование_Продукции;

Примечание: Даты #2025-10-01# и #2025-10-31# должны быть заменены на параметры при использовании в формах или отчетах.

Пример 2: Запрос для суммирования фактических объемов отгрузки за период

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

SELECT
    P.Наименование_Продукции,
    SUM(SI.Фактическое_Количество) AS Фактическое_Количество
FROM
    tblСтроки_Отгрузки AS SI
INNER JOIN
    tblПродукция AS P ON SI.Код_Продукции = P.Код_Продукции
INNER JOIN
    tblОтгрузки AS S ON SI.Номер_Накладной = S.Номер_Накладной
WHERE
    S.Дата_Отгрузки BETWEEN #2025-10-01# AND #2025-10-31#
GROUP BY
    P.Наименование_Продукции;

Пример 3: Запрос для выявления отклонений (дефицита/излишков)

Этот запрос объединяет результаты двух предыдущих запросов и вычисляет отклонение. Для удобства, сначала создадим два запроса (например, qryПлановыеОтгрузки и qryФактическиеОтгрузки), а затем используем их:

SELECT
    P.Наименование_Продукции,
    Nz([Плановое_Количество],0) AS План,
    Nz([Фактическое_Количество],0) AS Факт,
    Nz([Фактическое_Количество],0) - Nz([Плановое_Количество],0) AS Отклонение,
    IIF(Nz([Фактическое_Количество],0) - Nz([Плановое_Количество],0) < 0, "Дефицит", IIF(Nz([Фактическое_Количество],0) - Nz([Плановое_Количество],0) > 0, "Излишек", "В норме")) AS Статус
FROM
    (tblПродукция AS P LEFT JOIN qryПлановыеОтгрузки AS QP ON P.Наименование_Продукции = QP.Наименование_Продукции)
LEFT JOIN
    qryФактическиеОтгрузки AS QF ON P.Наименование_Продукции = QF.Наименование_Продукции;

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

Пример 4: Запрос для расчета текущих остатков на складе (на определенную дату)

SELECT
    P.Наименование_Продукции,
    Nz(SUM(PR.Количество_Выпуска), 0) - Nz(SUM(SI.Фактическое_Количество), 0) AS Текущий_Остаток
FROM
    tblПродукция AS P
LEFT JOIN
    tblОтчеты_Производства AS PR ON P.Код_Продукции = PR.Код_Продукции
LEFT JOIN
    tblСтроки_Отгрузки AS SI ON P.Код_Продукции = SI.Код_Продукции
LEFT JOIN
    tblОтгрузки AS S ON SI.Номер_Накладной = S.Номер_Накладной
WHERE
    (PR.Дата_Отчета <= #2025-10-31# OR PR.Дата_Отчета IS NULL) AND (S.Дата_Отгрузки <= #2025-10-31# OR S.Дата_Отгрузки IS NULL)
GROUP BY
    P.Наименование_Продукции;

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

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

Создание форм для ввода и редактирования данных

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

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

1. Форма «Справочник Продукции» (frmПродукция):
   • Назначение: Ввод и редактирование информации о продукции предприятия.
   • Элементы управления: Поля для ввода Код_Продукции, Наименование_Продукции, Артикул, Описание. Комбинированное поле для выбора Единицы_Измерения из tblЕдиницы_Измерения (отображает Наименование_Единицы, сохраняет Код_Единицы_Измерения).
   • Функционал: Кнопки для добавления новой записи, сохранения, удаления, поиска.
2. Форма «Справочник Клиентов» (frmКлиенты):
   • Назначение: Ввод и редактирование данных о клиентах.
   • Элементы управления: Поля для Код_Клиента, Наименование_Клиента, ИНН, КПП, Юридический_Адрес, Фактический_Адрес, Телефон, Email, Контактное_Лицо.
   • Функционал: Стандартные кнопки навигации, сохранения, удаления.
3. Форма «Справочник Сотрудников» (frmСотрудники):
   • Назначение: Ввод и редактирование информации о сотрудниках.
   • Элементы управления: Поля для Код_Сотрудника, Фамилия, Имя, Отчество, Должность.
   • Функционал: Стандартные кнопки навигации, сохранения, удаления.
4. Форма «Учет Планов Отгрузки» (frmПланыОтгрузки):
   • Назначение: Создание, просмотр и редактирование планов отгрузки.
   • Структура: Это будет главная/подчиненная форма.
     • Главная часть: Поля для Номер_Плана, Дата_Плана, Дата_Начала_Периода, Дата_Окончания_Периода. Комбинированные поля для выбора Клиента (Код_Клиента из tblКлиенты) и Ответственного сотрудника (Код_Сотрудника из tblСотрудники).
     • Подчиненная форма: Внедренная таблица или форма, основанная на tblСтроки_Плана_Отгрузки. Поля: Комбинированное поле для выбора Продукции (Код_Продукции из tblПродукция) и Плановое_Количество.
   • Функционал: Автоматическая привязка строк плана к основному плану, кнопки для добавления/удаления строк.
5. Форма «Учет Отгрузок» (frmОтгрузки):
   • Назначение: Ввод и редактирование фактических отгрузок продукции.
   • Структура: Также главная/подчиненная форма.
     • Главная часть: Поля для Номер_Накладной, Дата_Отгрузки, Дата_Перехода_Права_Собственности, Счет_Бухгалтерского_Учета. Комбинированные поля для выбора Клиента (Код_Клиента из tblКлиенты) и Ответственного сотрудника (Код_Сотрудника из tblСотрудники).
     • Подчиненная форма: Внедренная таблица или форма, основанная на tblСтроки_Отгрузки. Поля: Комбинированное поле для выбора Продукции (Код_Продукции из tblПродукция), Фактическое_Количество, Цена_За_Единицу, Сумма (автоматически рассчитывается на основе количества и цены или вводится).
   • Функционал: Автоматическая привязка строк отгрузки к основной накладной, кнопки для добавления/удаления строк.
6. Форма «Учет Отчетов Производства» (frmОтчетыПроизводства):
   • Назначение: Ввод данных о выпуске продукции на склад.
   • Элементы управления: Поля для Номер_Отчета_Производства, Дата_Отчета, Количество_Выпуска. Комбинированные поля для выбора Продукции (Код_Продукции из tblПродукция) и Ответственного сотрудника (Код_Сотрудника из tblСотрудники).
   • Функционал: Стандартные кнопки навигации, сохранения, удаления.

Общие принципы разработки форм в MS Access:

• Использование «Мастера форм» и «Конструктора форм»: Начать с мастера для быстрого создания базовой структуры, затем перейти в конструктор для тонкой настройки дизайна, расположения элементов, добавления кнопок и логики.
• Применение комбинированных полей (ComboBox): Для полей внешних ключей использовать комбинированные поля, чтобы пользователи выбирали значения из связанных справочников по наименованию, а в базу данных сохранялся соответствующий код (например, выбрать «Стол», а сохранится «101»). Это улучшает удобство и предотвращает ошибки.
• Правила проверки данных: В формах можно настроить дополнительные правила проверки (например, Количество > 0) для полей, чтобы предотвратить ввод некорректных значений.
• Макросы и VBA: Для расширения функционала форм, например, для автоматического расчета суммы в frmОтгрузки при изменении количества или цены (Сумма = Фактическое_Количество * Цена_За_Единицу), или для создания кнопок запуска отчетов.
• Навигация и удобство: Разработать главную навигационную форму (главное меню), которая предоставляет доступ ко всем другим формам и отчетам. Использовать понятные заголовки, группировку элементов и цветовое оформление.

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

Разработка отчетов для анализа выполнения плана отгрузки

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

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

1. Отчет по выполнению плана отгрузки за период:
   • Назначение: Предоставить сводную информацию о плановых и фактических объемах отгрузки по каждой номенклатурной позиции и/или клиенту за выбранный период, с расчетом абсолютных и относительных отклонений.
   • Источник данных: Запрос, объединяющий qryПлановыеОтгрузки и qryФактическиеОтгрузки (см. «Разработка запросов…»), с добавлением полей для расчета Отклонение и Статус.
   • Структура отчета:
     • Заголовок отчета: «Отчет по выполнению плана отгрузки за период с [Начальная дата] по [Конечная дата]».
     • Заголовок страницы: Дата создания отчета, пользователь.
     • Группировка: По Наименование_Продукции (или Наименование_Клиента).
     • Детализация: Наименование_Продукции, Плановое_Количество, Фактическое_Количество, Отклонение (в количестве), % Отклонения (вычисляется: (Отклонение / Плановое_Количество) * 100).
     • Итоговые поля: Суммы по Плановое_Количество, Фактическое_Количество, Отклонение для каждой группы и по всему отчету.
     • Форматирование: Условное форматирование для Отклонение (например, красный цвет для дефицита, зеленый для излишков).
2. Отчет по дефициту/излишкам продукции:
   • Назначение: Выделить только те позиции, по которым выявлены существенные отклонения (дефицит или излишки), с подробной информацией.
   • Источник данных: Запрос из Примера 3 («Запрос для выявления отклонений»), отфильтрованный по Отклонение ≠ 0.
   • Структура отчета:
     • Заголовок отчета: «Отчет по дефициту и излишкам продукции за период с [Начальная дата] по [Конечная дата]».
     • Детализация: Наименование_Продукции, План, Факт, Отклонение, Статус (Дефицит/Излишек). Можно добавить Наименование_Клиента для детализации по клиентам.
     • Дополнительные поля для анализа: Потенциальные упущенные продажи (при дефиците, если умножить дефицит на цену реализации) или потенциальные затраты на хранение (при излишках, если умножить излишки на стоимость хранения единицы).
     • Группировка: По Статус (отдельно «Дефицит» и «Излишек»).
3. Сводный отчет по отгрузкам (по клиентам/продукции/за период):
   • Назначение: Представить общую картину отгрузок, позволяя анализировать объемы и стоимость по различным срезам.
   • Источник данных: Запрос, объединяющий tblОтгрузки, tblСтроки_Отгрузки, tblПродукция, tblКлиенты, tblСотрудники.
   • Структура отчета:
     • Заголовок отчета: «Сводный отчет по отгрузкам за [Период]».
     • Группировка (примеры):
       • По Наименование_Клиента, затем по Наименование_Продукции.
       • По Дата_Отгрузки (еженедельно/ежемесячно), затем по Наименование_Продукции.
     • Детализация: Номер_Накладной, Дата_Отгрузки, Наименование_Продукции, Фактическое_Количество, Цена_За_Единицу, Сумма.
     • Итоговые поля: Суммарное количество и общая сумма отгрузок для каждой группы и по всему отчету.

Процесс создания отчетов в MS Access:

1. Выбор источника данных: Определить, какой запрос будет служить основой для отчета. Если стандартных запросов недостаточно, создать новый, специально для отчета.
2. Использование «Мастера отчетов»: Для быстрого создания основы отчета, выбрав поля, группировки и сортировки.
3. Работа в «Конструкторе отчетов»:
   • Настройка заголовков, колонтитулов, добавление логотипа предприятия.
   • Размещение полей, текстовых надписей.
   • Добавление вычисляемых полей (% Отклонения).
   • Применение условного форматирования для визуального выделения ключевых показателей (например, красные значения для дефицита, зеленые для перевыполнения плана).
   • Вставка графиков (например, гистограмма сравнения плана и факта) для повышения наглядности.
   • Добавление итоговых сумм и средних значений в колонтитулы групп и отчета.
   • Настройка параметров печати и экспорта.

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

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

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

Методы обеспечения целостности данных на уровне СУБД:

Целостность данных — это гарантия того, что данные в базе данных являются точными, согласованными и надежными. MS Access предоставляет ряд механизмов для её поддержания:

1. Ссылочная целостность (Referential Integrity): Это самый важный механизм для реляционных баз данных. При установке связей между таблицами в окне «Схема данных» Access позволяет активировать опцию «Обеспечение целостности данных». Это гарантирует, что:
   • Запрет на создание «висячих» записей: Нельзя ввести значение во внешний ключ подчиненной таблицы, если соответствующее значение отсутствует в первичном ключе главной таблицы. Например, нельзя отгрузить продукцию, которой нет в справочнике tblПродукция.
   • Запрет на удаление связанных записей: Нельзя удалить запись из главной таблицы, если на нее ссылаются записи в подчиненной таблице. Например, нельзя удалить запись о клиенте, если у него есть активные планы отгрузки или оформленные отгрузки.
   • Каскадное обновление связанных полей: Если необходимо изменить значение первичного ключа в главной таблице (например, Код_Продукции), Access автоматически обновит все соответствующие значения внешних ключей в связанных подчиненных таблицах. Это обеспечивает согласованность.
   • Каскадное удаление связанных записей: При удалении записи из главной таблицы, Access автоматически удаляет все связанные записи в подчиненных таблицах. Этот механизм следует использовать крайне осторожно и только в тех случаях, когда удаление «главной» записи однозначно подразумевает удаление всех «подчиненных» (например, удаление Плана Отгрузки влечет удаление всех Строк Плана Отгрузки).
2. Правила проверки (Validation Rules): Для каждого поля таблицы можно задать правила, ограничивающие диапазон или формат вводимых значений.
   • Для числовых полей: Например, Количество_Выпуска в tblОтчеты_Производства должно быть >0. Можно задать правило >0 или ≥0 и соответствующее «Сообщение об ошибке» (например, «Количество выпуска должно быть положительным числом»).
   • Для текстовых полей: Можно использовать маски ввода или правила для проверки формата (например, для ИНН/КПП).
   • Для полей даты/времени: Например, Дата_Окончания_Периода в tblПланы_Отгрузки должна быть > [Дата_Начала_Периода].
3. Обязательные поля (Required Property): Установка свойства «Обязательное поле» в «Да» для критически важных полей гарантирует, что пользователь не сможет сохранить запись без заполнения этих данных.

Обеспечение целостности на уровне приложения (через формы):

Хотя большая часть целостности обеспечивается на уровне СУБД, формы также могут вносить свой вклад:

• Использование списков и комбинированных полей: Вместо свободного ввода значений в полях внешних ключей, предлагать пользователю выбрать значение из выпадающего списка, который связан со справочной таблицей (например, выбор Наименования_Продукции вместо ввода Кода_Продукции). Это исключает ввод несуществующих кодов.
• Автоматические расчеты: В формах можно настроить автоматический расчет полей (например, Сумма в tblСтроки_Отгрузки) для минимизации ошибок ��учного ввода.
• Макросы и VBA: Для реализации более сложных проверок, которые не могут быть выполнены встроенными правилами Access. Например, проверка уникальности номера накладной перед сохранением.

Базовые принципы безопасности данных в Access:

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

1. Защита паролем базы данных: Самый простой способ — установить пароль на .accdb файл. Без этого пароля открыть базу данных будет невозможно. Однако стоит помнить, что эта защита не очень надежна против квалифицированных атак.
   • Как установить: Файл → Сведения → Зашифровать с помощью пароля.
2. Разделение базы данных (Split Database): Рекомендуется разделить базу данных на две части:
   • Серверная часть (Backend): Содержит только таблицы. Хранится на сетевом диске с ограниченными правами доступа.
   • Клиентская часть (Frontend): Содержит формы, отчеты, запросы, макросы и связи с таблицами серверной части. Распространяется среди пользователей.

   Это позволяет:

   • Защитить структуру таблиц и данные от случайных изменений пользователями.
   • Упростить обновление клиентской части без затрагивания данных.
   • Разграничить права доступа на уровне файловой системы: пользователям даются только права на чтение/запись в файл серверной части, а на клиентскую часть — полные права.
3. Управление учетными записями пользователей (недоступно в новых версиях Access): В старых версиях Access существовала система защиты на уровне пользователей и групп, но в современных версиях (начиная с Access 2007) эта функциональность была значительно упрощена и фактически упразднена для обычных файлов .accdb. В корпоративной среде Access может использовать безопасность Windows при интеграции с SharePoint или SQL Server.
4. Скрытие объектов: Можно скрыть объекты базы данных (таблицы, запросы) в области навигации, чтобы пользователи взаимодействовали только с формами и отчетами, что предотвращает случайное изменение или удаление.
5. Резервное копирование: Регулярное создание резервных копий файла базы данных является критически важным для восстановления данных в случае сбоев, повреждения файла или некорректных действий пользователей.

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

Тестирование и перспективы развития системы

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

Тестирование разработанной системы

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

Методика тестирования функционала АИС:

Процесс тестирования будет включать следующие этапы и виды проверок:

1. Функциональное тестирование:
   • Тестирование ввода данных:
     • Проверка корректности работы форм: frmПродукция, frmКлиенты, frmПланыОтгрузки, frmОтгрузки, frmОтчетыПроизводства.
     • Попытки ввода некорректных данных (например, отрицательное количество, текст вместо числа, несуществующие коды клиентов/продукции) для проверки правил проверки полей и ссылочной целостности. Система должна выдавать соответствующие сообщения об ошибках и не позволять сохранять некорректные записи.
     • Проверка работы комбинированных полей: корректность отображения данных из справочников и сохранения соответствующих идентификаторов.
     • Проверка добавления, редактирования и удаления записей в каждой форме, а также вложенных (подчиненных) форм.
   • Тестирование запросов:
     • Запуск всех разработанных SQL-запросов (для плановых/фактических отгрузок, отклонений, остатков).
     • Проверка корректности результатов: сравнение с ручными расчетами на основе тестовых данных. Особое внимание уделить запросам с вычисляемыми полями и агрегирующими функциями (SUM, Nz).
     • Тестирование фильтрации и сортировки в запросах.
     • Проверка обработки граничных условий (например, пустые данные, отсутствие планов/фактов за период).
   • Тестирование формирования отчетов:
     • Запуск всех разработанных отчетов (по выполнению плана, по дефициту/излишкам, сводные).
     • Проверка корректности отображения данных, соответствия отчетов источникам данных (запросам).
     • Проверка правильности группировки, сортировки, итоговых сумм и вычисляемых полей в отчетах.
     • Оценка читаемости и наглядности отчетов, корректности применения условного форматирования.
     • Проверка параметров печати и экспорта отчетов (например, в PDF или Excel).
2. Тестирование ссылочной целостности:
   • Попытки удаления записей из «главных» таблиц, на которые ссылаются записи в «подчиненных» таблицах (например, удаление продукции, которая уже есть в плане отгрузки). Система должна предотвращать такие действия, если не настроено каскадное удаление.
   • Попытки изменения первичных ключей в главных таблицах для проверки каскадного обновления.
3. Тестирование пользовательского интерфейса (UI) и удобства использования (Usability Testing):
   • Оценка общего удобства работы с формами: расположение элементов, понятность надписей, скорость отклика.
   • Проверка навигации между формами и отчетами.
   • Оценка информативности сообщений об ошибках.
4. Тестирование производительности (базовое):
   • Оценка скорости выполнения запросов и открытия форм/отчетов при небольшом объеме тестовых данных. Для Access, как правило, это не является критической проблемой на малых объемах.

Пример сценария тестирования (для формы «Учет Отгрузок»):

Шаг	Ожидаемый результат	Фактический результат	Статус
1. Открыть frmОтгрузки.	Форма открывается, поля пустые/готовы к вводу.
2. Ввести Номер_Накладной (уникальный).	Поле принимает значение.
3. Ввести Дату_Отгрузки.	Поле принимает корректную дату.
4. Выбрать несуществующего Клиента через ComboBox.	Невозможно выбрать, так как клиент отсутствует в справочнике.
5. Выбрать существующего Клиента.	Клиент успешно выбран, его Код_Клиента ассоциирован с записью.
6. Добавить строку отгрузки.	Появляется новая строка для ввода.
7. Выбрать Продукцию и ввести Фактическое_Количество = -5.	Система выдает ошибку «Количество должно быть ≥ 0». Запись не сохраняется.
8. Ввести Фактическое_Количество = 10, Цена_За_Единицу = 100.	Сумма автоматически рассчитывается как 1000.
9. Попытаться сохранить накладную без Даты_Отгрузки.	Система выдает ошибку «Поле ‘Дата отгрузки’ должно быть заполнено».
10. Сохранить корректную накладную.	Запись успешно сохранена в tblОтгрузки и tblСтроки_Отгрузки.

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

Перспективы развития и масштабирования системы

Разработанная АИС в MS Access является эффективным решением для малого или среднего предприятия, однако важно осознавать её потенциал и ограничения. По мере роста компании или изменения бизнес-процессов могут возникнуть новые требования, которые потребуют развития и масштабирования системы.

Потенциальные направления для расширения функционала системы:

1. Интеграция с другими подсистемами предприятия:
   • Бухгалтерский учет: Автоматический экспорт данных об отгрузках и реализации в бухгалтерские программы (например, 1С:Бухгалтерия) для минимизации ручного ввода и ошибок.
   • Управление запасами: Расширение функционала для более сложного управления складскими запасами, включая прогнозирование спроса, автоматическое формирование заказов на производство или закупку.
   • CRM-системы: Интеграция с системой управления взаимоотношениями с клиентами для отслеживания истории заказов, предпочтений клиентов и улучшения обслуживания.
   • Системы планирования производства (MRP/ERP): Включение данных о планах отгрузки в общую систему планирования ресурсов предприятия для более точного расчета производственных мощностей и потребности в сырье.
2. Переход на более мощные СУБД:
   • По мере увеличения объема данных, числа одновременно работающих пользователей или усложнения запросов, производительность MS Access может стать недостаточной. В этом случае целесообразным будет переход на серверные СУБД, такие как Microsoft SQL Server Express (бесплатная версия для малых проектов), MySQL, PostgreSQL или Oracle.
   • Процесс перехода может быть упрощен благодаря архитектуре Access (разделение на клиентскую и серверную части), где серверная часть (таблицы) может быть перенесена на SQL Server, а клиентская часть Access (формы, отчеты, запросы) будет работать с удаленными таблицами.
3. Добавление новых аналитических функций:
   • Прогнозирование отгрузок: Использование исторических данных для построения моделей прогнозирования будущих объемов отгрузок, что поможет более точно планировать производство и закупки.
   • Анализ причин отклонений: Добавление полей для фиксации причин дефицита/излишков (например, «задержка производства», «отказ клиента», «неверное планирование») и создание отчетов по анализу этих причин.
   • ABC/XYZ-анализ продукции и клиентов: Классификация продукции по значимости (ABC) и стабильности спроса (XYZ) для оптимизации запасов и стратегий отгрузки.
   • Dashboards и визуализация данных: Создание интерактивных панелей мониторинга (например, в MS Excel с подключением к Access или Power BI) для визуализации ключевых показателей эффективности (KPI) в реальном времени.
4. Развитие пользовательского интерфейса и доступности:
   • Создание веб-интерфейса для удаленного доступа к системе через браузер, что особенно актуально для сотрудников, работающих вне офиса.
   • Разработка мобильного приложения для оперативного ввода данных или просмотра отчетов с мобильных устройств.
   • Внедрение функций оповещения (например, по электронной почте) при возникновении критического дефицита или значительных излишков.
5. Повышение уровня безопасности:
   • В случае перехода на серверную СУБД, использование встроенных механизмов безопасности СУБД (управление пользователями и ролями, права доступа на уровне объектов, шифрование данных).
   • Внедрение журналов аудита для отслеживания всех изменений данных в системе.

Разработка АИС — это живой процесс. Планирование перспектив развития на ранних этапах позволяет создать более гибкую и адаптивную систему, способную эволюционировать вместе с потребностями предприятия.

Заключение

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

В процессе исследования были детально проанализированы теоретические основы проектирования информационных систем и баз данных, что позволило систематизировать ключевые понятия, методологии системного анализа (включая SDLC) и принципы создания ИС. Особое внимание было уделено ER-моделированию как инструменту концептуального проектирования и нормализации баз данных до 3НФ/БКНФ, что обеспечило теоретическую базу для создания эффективной и логически стройной структуры данных.

Детальный анализ предметной области предприятия выявил ключевые бизнес-процессы, связанные с движением готовой продукции, а также обозначил критические проблемы, вызванные дефицитом и излишками товарных запасов, влияющие на финансовые показатели и имидж компании. Были описаны особенности документооборота (Отчет производства за смену, приемо-сдаточные накладные, ТОРГ-12, УПД) и бухгалтерского учета отгрузки продукции, включая обязательные реквизиты документов и учет на счете 45 «Товары отгруженные». Это позволило сформулировать конкретные цели и задачи для разрабатываемой АИС, ориентированные на автоматизацию ввода, хранения, обработки данных и формирования аналитических отчетов.

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

Практическая реализация АИС в MS Access продемонстрировала процесс создания таблиц, установки связей с обеспечением ссылочной целостности. Были разработаны ключевые SQL-запросы для расчета плановых и фактических показателей отгрузки, выявления абсолютных и относительных отклонений (дефицита/излишков). Созданы пользовательские формы для удобного ввода данных и разнообразные отчеты для анализа выполнения плана отгрузки, предоставляющие руководству предприятия наглядную и оперативную информацию. Отдельное внимание было уделено методам обеспечения целостности и базовой безопасности данных в Access, включая защиту паролем и разделение базы данных.

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

Практическая значимость разработанной АИС заключается в предоставлении предприятию эффективного инструмента для:

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

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

Список использованных источников

1. Что такое база данных и принцип ее работы — Банковско-финансовая телесеть. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFFW784bDMFASU0kUtLI6oTcxBp6EmuCx2VA1HbIV95A8CemAAwz8-mqQn9vEG3StnaKmUhLfaFrl8PiVZMeN_dWIAm6CSnPbN2u2FRHKe_H5EAfgXTlbHhtUnywDvG2l418IZzelYdVo7oimEgC9tQc0B4UsTqwZ0o (дата обращения: 29.10.2025).
2. Автоматизированные информационные системы — определение термина. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGYkyJ9ZqVzi_u7Hly7KM3i_9SiizK_DY5ZFJdeeu-cc7MvsXT_CVbSxu6fDBUdIyuw2UHG2xf_ebK5rMwUOnhm6hCUXMpMRnycu0fB-tRlYH969-F4CZWI5-ea-J4BQmMjrmqjXyE32luiRBYb2uLqoX0MxZCfI7kf1k1QsbBJWth9uRYSbIecjg== (дата обращения: 29.10.2025).
3. Основы методологии проектирования БД — Теория баз данных — Ucoz. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE8fFjiiDx86cciFPPRwH3mzMuTqg13WIVFzHaiHngPLMrrSerxDbsogFe1gPItdEpC5nu1sOHrGul0IlZlIf3yB8SpwbVBOcxGv3bx5fXPjs1NxvH_IkDkZecSL3X (дата обращения: 29.10.2025).
4. ДЕФИЦИТ И ИЗЛИШКИ ТОВАРНЫХ ЗАПАСОВ — Ростовская Школа Логистики. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQF7jgJQ90TXtwNKiY1Jpy1g9U40mdAMOx-aP8PVXBFoinBB8kEzq63_nnJkfoAsjZpnEV8eeH8HnLq1Vry-5hAlp461ZpD6BQIfO4O9GgHu38WKdEcUNxs8CV7DMxcWzm1clGHDfWuP_KfEKsAhcz0fjicPuTHyx2w0XJP7dGW3dXWk6NIbIdzBFwuAl8b72-JB66TyD4Lb01O9nYp0 (дата обращения: 29.10.2025).
5. Описание нормализации базы данных — Microsoft 365 Apps. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHkVTMfFLqzs3EkeNTzUWWpWGNiWQA3tM6tpareIcjjDvflkto2JckymCEaMeWG6Us3JwMluyINhWKMEugAmc5mFqLobpW9ePjc_TK3jOeznSexANhD7ViCzJRyXSU38EFUUTpThOlAoB8H9IBTxtFy9DyX94idgMYOU914ei_YCn4FwBjBhNrqJkmKsSgrvGrxrCt4_cgD35M8 (дата обращения: 29.10.2025).
6. Методы анализа информационных систем. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHUT0chpYmyrOaCISk9G1fjFUCA76rpBf_P-_kgnqBHs3LirOOMUBFFmJoIHf1z6MfpPpzr3oNBlFL-I34WDFso7eAXWbu6bLmO9Wl-XnkxsIiJnXvFVT3e5rM0lIGbstR-ftekGb7_jVB3cbsAvhUbw0Ch4zs_yuWUsMGU9U1YQBgRUhITXkUFhY12ouwqyI= (дата обращения: 29.10.2025).
7. Проектирование баз данных: основные этапы, методы и модели БД — DECO systems. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGQSbCnmRG2CuRD-ySlUXeUhXFb_t49MT_L9cJjsM59JhAcKge3QFzgDO3nmm0p44HtInQfME3EfSgH5sCqmLwXPupe-zfZkftNkagmdR3JlK5rKOzoGS9lyTMOpTSCPQ9rONSnRYfRIE1J_N8yoEBBsg== (дата обращения: 29.10.2025).
8. БД_ВТ: Лекция 9. Проектирование баз данных. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGp1j6v3yLfMeOSXDfsu7d6-cQWYsDPUUfk7E_zrE95cfcQSatiXaA5DLddmX_uk_dwS6_fOHB6JMiyn85Xf5I0uzZ1T5tNae_uIUwGjdp0B6gcRilRTs-ORnc6rV3fDTufa7FPpSydAfAZvVxX (дата обращения: 29.10.2025).
9. Что такое нормализация базы данных? — Первый Бит. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEJoOpPQ9_nNbW6oTA2b2rNbdq3GfJEi1v7X1YH6d9gZApvmXvolygTuYA5qsf-AWrJsaO7-RiAFfKq9IWljEUt0hOrkwsBlILoYcl6lSfec68GJGtwp90TrbBYaiHuiAKGblYia0gP0IfMWh93bVPfCJeS5l1xG8w2K90= (дата обращения: 29.10.2025).
10. Примеры и принципы нормализации реляционных баз данных (БД) | DecoSystems. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHzTypG6ZpFTc-0E9QdnYp61j0fn7PdPzlCbnzvRUkJ2nLrvUYpckEX9ZD5mrMU8sZwY_ylFUQxPFVOOvgSYae8eQBpjX6xzfaPKhWJSuNYczZfMY_Cen3Trtbqg4HFVnbTuFZd-zKF4opr1O0D-ejxVo0= (дата обращения: 29.10.2025).
11. Что такое нормализация базы данных? [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFl-ygST90BT2cw8Uh9AqtktiuNCbvWE-OUtl7WIVbxY8MN-LL2GoSIZqFncsLBrXthMdYnfAA5UalmFx3zDMMjxCaeuOe69E9dan7H2VhwNBlMgalurzsiFVgPlbiupiT3pm1b9Axa3HLRl7MbVOXjV53VkOefip71Y4_tIwJE7i8= (дата обращения: 29.10.2025).
12. [Глава 13.] — 13.3 Бухгалтерский учет отгрузки и продажи готовой продукции. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEu2AEko-UPCU9z6aGzdSkouqYfoguQXRfPrgixieV7xqjN8Om1K6804bZMaUX9nw2dY8PkPUOXjfpq4K6gqb4tPl8Rv5TkSr8gP25CkYVtU2Co6X-awuudEqw91mM6n238ZfmRqYr5rGD8zOGJFmnC (дата обращения: 29.10.2025).
13. Учёт готовой продукции — Википедия. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFxcuEuQW8Vm48BApSKKmmo7aQrldhpa6UW06_w1gAFutBcRNJHv1_7dqGq82dbcUGqakG9aog80ENJKwh5grumi6yD8tI17bBmoLW6uXl45br5Hgi9fgS6zqzAgYfCECAcu2WvXizniK3d4C79r3tLiQUsON2CCnNY57E5FXhE32D9D0iJ3iZStVAnzRDiqLbRuRvWi0VUDb7rhSIhiQXt8EhCmFiI4JXx1Wc0xX-X3zf91135zXaoRlVP2lcGrhQfQURvdjTZAbS83DiA9PB-dZSSYA== (дата обращения: 29.10.2025).
14. Нормализация данных: что это и зачем их нормировать — правила нормирования данных в БД — Яндекс Практикум. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGdarHiSVBMyhAnYw3FYOYYXi1tI8525dzGKL1PerSjS4O4fNsFYRN4H4edAugQDpYM0L-Yh6KFQFPZvuOfCf09vC0C_RT9vG2Kef8s7-vGOzHsL_65FOoueA25ZBdUZx7TOH1wVUGVAV-BkvUFhwBYKpKtH7Pv30guM0Em (дата обращения: 29.10.2025).
15. Что такое база данных? Определение, типы, преимущества — Astera Software. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGquoVWBLi0VC0o_eEet9Ry8vQjDuCK6Iaa5izYbDVGBr2nKvW4TujTMMKMAjlvhozFwgqKutHWgHUPiwreeK7aLzIyZWij7a032pIAePSur1TyPhQuvIz1mpCXqvdjJG58kmoVavJ7yRtbeS6glKeA5hs= (дата обращения: 29.10.2025).
16. что такое БД, их типы, свойства, структура — примеры использования и управления таблицами баз данных — Яндекс Практикум. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHDRn8xpiXDNGNdY6jZcmDtNPDPqxDS8xEeKUBCuS1TfnbIgAJdRZYSr2A90jLen1suglCBBXed9Nydzjr3LJcCkgP1_jr0Vi5g2vtaP80n_uPrZDgmAZaLYBt1acqmUcjKzyfRAuv3lbjxN90833y-mGNB (дата обращения: 29.10.2025).
17. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ И СОЗДАНИЯ БАЗ ДАННЫХ ДЛЯ СОВРЕМЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ — Научные журналы Universum для публикации статей. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE5pvrNnRSForZ5_VwoJwVTky4Y8gv2v5kkGrTc11qQ18lJkfqZhtMCJPnJbywJYPA8Q9l5Vr6q82U4lnlCgpf_ZM13Z5Q46r6n7Q0NPfomLLfgbIYeczNE0g-HUE2p-34Mc3CEykz9rU4F3_g= (дата обращения: 29.10.2025).
18. Что такое база данных? Значение, типы, компоненты — Prehost.com. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFRG1hSabKza1pBLHlmeftrcsXTQzQ63eY1Qmt9lcKkz64a4Gg9GIlsWe4_Uho2EKNA4xmWewziJibaePvRn6WIUUXIkS4um4ec6NWPGtL11XnnmOqPBVKr9wFwb6t-2pZWHSM= (дата обращения: 29.10.2025).
19. Учет готовой продукции (работ, услуг), ее отгрузки и реализации. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGnn4tscuGQhJj_zsjG4_OmP9-JU8YmRJ7IcwSRCQr1XJw_1jo-p-61z021HI1f9PVCwCCJL5ruYPTAUtQC0jkgSmlbo4lUwpA4B0YjdKc6XXvdRx3RUM_dynkBAgzmGNmn69opbr1R (дата обращения: 29.10.2025).
20. Методы и порядок проведения анализа предметной области — DissHelp. [Электронный ресурс]. URL: https://vertexaisearch.google.com/grounding-api-redirect/AUZIYQHct2QRF3-W3se6TUXDVsgMQuy1o3plQfLLcDSqPh_MGnHpxrMyzysx5Bz57SBtzF1dmN9LIV2btzSt7NahGDQHyd0qTlWFGNffSHJ0SEgYFd7ZH089Ccf1edoI_TZApSv7H4kqeRTi3JLbtPZ7yAhLVhXALXcdXv1o2JyUIjgt6QC3FdxP63tLkJlr9lc= (дата обращения: 29.10.2025).
21. Учет готовой продукции в бухгалтерском учете: организация, оценка — Контур.Бухгалтерия. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGTMx1g86bTcm_g3LDupFfS596dxlT42V5Q3QSFAepDNFlprNP4qABSB3OlSndyGKWVu-TGFAjHNXwpuNUYYdQG_L0-Bgunh5-8sy-9KNtooTjy_grtR0xQp4vRQ8zKz1tbFT1UWnHXHGbv4DPkfxHI9NMVV03aZ4YB_ovdDTGcjXa_gg== (дата обращения: 29.10.2025).
22. Определение дефицита товара — Lokad. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHJV7yPazzMn3OSPw6044qR5ZlwQhBibYuH0V-w3783btSrlefKWZxqAS3aRf55LsOwY7BgtojzMUmhMirXNafuVHxpDthljDXxcNygiAUhdP4L9iUeXFG1VBRgrJoL4C_qAN-zhkyUYCX3gZrytFWmur9lBwbDvJLvJspEyb0jEsXsoQ5Z81qAfdvr3G6QuD-nOFc9thpTMhTgB1P5QMxNopuUxg== (дата обращения: 29.10.2025).
23. Проектирование баз данных — Википедия. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH68los77Qd4SZGZd417Kzwy5EBwochU0b7PTg9oUPJqKxbIv5MG5bR1mni1VVhU9NfPVTukB2M5cJPVltj5K-uANRxO8gg0jDm-NDMsJ2sVXN4j5QKcd2CRVpiSHVbBiLRey8EPgLCewZidS2UUxBGOldFNfGsSCOsUXNTnugVUCmLkJwqk2IdoOOYrQ0UZy3wg8QuVD9hQVdq-V5l5pOQ8pne9v5Rf2dT-kt9L42nl6Fl_0nuZs0kBDlamyp4eW7wY45ssuEhin4oXfiQywAfLrm8hEB-fdbYGBstH4JvY6ggiQ10g== (дата обращения: 29.10.2025).
24. ER-диаграмма: задачи, нотации, правила составления — Генератор Продаж. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFdoPnfNNisl9GX-t0RjU7ZXRIYZnQElmtNvUQNZ_7B-CAs64h03dE1ZneN09DBVaFwWd9J7z2flI1iRa6BEx0O_OjWPzncn3dZ8S1qS4Lg6nENHA38Pt9c8uyWSylCFU6C6igt2J1OlQ== (дата обращения: 29.10.2025).
25. Применение методов системного анализа при проектировании и разработке системы, обеспечивающей взаимодействие разнородных автоматизированных систем — КиберЛенинка. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHY5GpaWZgEIRS9C46LFaj8PaPbCKtdeeb4agGwQ555F7yEaO66ThUHXbNueTO22iHcBimVZ-r6jQVZMOcdlC2SC9Zg4rx_R4nv6MXQgZ8enFCOEO5WzEg_23yn6zcDK5vlawjS1HTiSc6dbgE0JgxvKmHIYlwsUwhUi3AGsI65ypDjSCzDprbW1InmRoJpqd3wO87UWnQWDBNbIY43ZzBK8iYT7dHla6I2-EnU6HhAHspKxc2zNhvrpKhd6JMrLdMz9GteifdNmEryLT7iJRZhr9tWwHuoZCpc (дата обращения: 29.10.2025).
26. РАЗЛИЧНЫЕ ПОДХОДЫ К СИСТЕМНОМУ АНАЛИЗУ И ПРОЕКТИРОВАНИЮ. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFFLPhY1bNuvo_1Uhvt0QuY277k6aZshF8Sg8TXFuOaMlz2NaigU2V91dT0BJRHIX__Xcohzdxqo1DUYP3D3OKTUfrqAKxuq-nGiai_YPH-_XZKCis9oO88DvCwuPHYDEWUnngb_ftw5UstZ_c= (дата обращения: 29.10.2025).
27. Существующие методики анализа предметных областей информационных систем. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHgWd2xZ4z2jLwgQb71RJjzf4NF7wVCDDDr9it156zIKnOPmqB2okxnZOxQO4dLI15kzA_tjAgtflo4vNNGaj60dlpoz1E75Lf8PWck2RhImMAtBDJF0VQE0Q4ODhNldJ3gsOvKLSIcWSqCZmuQiAu3p7k-b0JXHHdfCe3pL-fmBxUIHXUPhlteJGL8FY9FzNswo3ts0U_99nKKb8iBpJnbPSDwCZcH3aLZZpo= (дата обращения: 29.10.2025).
28. 45. Методы анализа предметных областей. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQG96eS09hjH20NGedqGKbOB1TVBPPceOSCSYLnc8BK-b280GG6CY8eqnprieWvk2ZO5O2kJKLIiYMiLCJ7TkdV8gogTlwSdN40LxJ6XBTEuXxMGVBYg9ynVg0w-4pvheGQ= (дата обращения: 29.10.2025).
29. Учет готовой продукции на производстве — Школа финансовой грамотности Пророковой Марины. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFTMp2G0H2JtJ_31ZwfpnsfyXD0qcW_54-chkWyAeOFk7i31Mg72HzyPhAUGkNO8gaedluVGM6sbZcH_NRqAh0RF3npHJK1ZvZX_zkqNl-QmmVyxm8bvdN_aZW_a_zwlxtzrCoJXG-lHojo_2QZLTgUfXJpN4KU (дата обращения: 29.10.2025).
30. Методика системного анализа. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH0CDMzbIDbTt8mWB8YR-CwPdreXQrBtRVwJ3vDPZzdc0GgMbXM2njynEqAWgMtW4mOMIClONLmHBYBR7RL1q5Jy9NPcmlLd3dkY6_GD1VA8ZH5HSgrfgW6uga-26vEno2V8hNGUdXAv0uJ (дата обращения: 29.10.2025).
31. Научная электронная библиотека Монографии, изданные в издательстве Российской Академии Естествознания. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHt8esINbJ-8JNiFCL2HIfnntjcK8l4MugSmkcNKdh28d8eBCv1PCGxoHbGvXuSDubsbeUGNBjr6hmW-7LnL82E5xXMBAzZPuSY-MDFkCoxxKxh2HWGY3jT13mLvaNhUB5Mxy6DwvaIq9ovJw== (дата обращения: 29.10.2025).
32. Значение слова информационные системы (ИС). Что такое информационные системы (ИС). — YouTube. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEbhSVCkijn4prHb_DhnGpd6axyXH9prbNumA4XshSQW9f9vhuhemy2ew20YreHHWj76OHRj2maqCrHOVuagmBNKyGNITeSJGysQRhi0h0E1GqU6lii1CT_r-kiS8S3QZOf21moYZQ= (дата обращения: 29.10.2025).
33. Что такое ER-диаграмма и как ее создать? — Lucidchart. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHSNnHp0MQdVun90NewATnTz1pnZ64ETd7NmIcslJiCSBtvZ-7vxfBaYVzcrRc4JTa6ry6M6Y15R6EAOV280MabcedabIjwtusR1BYB1jT4Wu_ODZKnIMg6aaR86peF2W8Nw03jisiWJAfk (дата обращения: 29.10.2025).
34. Дефицит и излишки товаров: как влияет схема поставок — Ольга Правук. Управление запасами: семинары, консультации. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEl9Jy-xYiPWLmuaeWgomq8440ofp_gdvzCzgvVdOfe_eXFEPoWAKRpg2dAtMjRwE7dzW9ztnjqBe4ZzO1yTpUQXy0cfZcxenS8VwOTZvHGRq5CZLqQRfT0RxkXcn5GF0haxUI6aLv243BRcbxcn8yUXQCZpfjja65mxBc3KkZUtNqudyrGO2= (дата обращения: 29.10.2025).
35. ER-модель — Википедия. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFwiKc1cqA2cDDzIzHsKpBerrq_—T7til5fLDQq1bfy4ODvo5FPMQNJH_w8oGeSrSBu4eXPEdGixvHSbF_NpBaLSDTxLY8nS67y1tL_cEtTBj_vyn82YHErab0jC2Vk1EA9KGZN3nvP4UvjcdWjZe-clU6nCwTv-hiBIRiHypFuU== (дата обращения: 29.10.2025).
36. 5.3. Системный анализ предметной области — Электронная библиотека >> Управление данными. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEQUEu6DJeYpY9qbsITbID5o1kUufjl7PZ1Csw4b6eMBd-0VGBJlYdLcN4s0TYCNVtrDvobkUDQS5pMhrYIwcBOjv1EXQ9-D6ccGG6-gZwTp1G9FlzchEGQNTyThD5_3YoCNdF3LwinYr5hn1luSm_upjmSrb8s6TWhDH5khY3OMa9VQUbxcUUdR5mhjB8= (дата обращения: 29.10.2025).
37. Проектирование ER-диаграммы — Национальная сборная Worldskills Россия. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFb_CxSR5kyGi3YWdBZjWXNdLwvx6Dr20IX2rjNjp7adICL1gMkk0H7PwIfPy6XOtpUrde3MB8yu5bQK28YOYu-7P6tbFmqFpW178LisCZkSyi2l5O2j1KPJO-Dap5MHWpUiagZEORI3VIJVf7ujIS-jT_rGhfNiVZpD4Ui1zF18YY (дата обращения: 29.10.2025).
38. что это, применение, нотации — как создать ER-диаграмму сущность-связь, примеры. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEDd_OyZL_JHay-XR8470D19lRcIU32vU7S9_hFIcZ8nz8DqWqUFPC4GRn52szAfpHv8jZp_mFkERNO0l5_CpFHDLQutFwosS_YSN4htPCPsQeCWj2OB0BFV-9qzUblP3WdR3CpD7qRhG3yq7Vg9-cOYThckA== (дата обращения: 29.10.2025).
39. 4.6. Основы проектирования баз данных — Без названия. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFh8fKetVcyr9J6rpbNMjkLzFq676aYFo61KSozPenKQp6M2Ily59ya4abYrjuFs-QawBmf_uOh6_RI2YiZ370QwG5e81bVof_aeaRPWvu2gN4LjDzsVGhqyn2sjMNe7hFSDSj26LQ= (дата обращения: 29.10.2025).
40. Единая автоматизированная информационная система торгов города Москвы (ЕАИСТ). [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFus94RuzGyzmURYOhFUBF2zEvGJi4Jblh7qXu8ywp8eAbNaNSkTGXRbKOFQDEYWuO94J7EQrNrfmOpDzYrvKPd44R7FPisZI2YB0gzdd3GM9r30-BVkwbwrdQ= (дата обращения: 29.10.2025).
41. Автоматизированные системы, используемые в НИУ «БелГУ». [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHl9Q9RDYVc_coG4Kw94tFquTBrcl3EHKyievnps9kZMseeju7tNGBu1_-DenMNqdbVXTm0dfsGCHtbJcL4Z7lSIo3c2—CyQ0ywhEDqQYlEQ47JvoqQ2u08Wukrgg= (дата обращения: 29.10.2025).
42. Россельхознадзор / Федеральная государственная информационная система в области ветеринарии. [Электронный ресурс]. URL: https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEHz94u-SZS5eeIiw9o5T-dzVR14VJ_0ABMuUWGqVicUba40-HEwUEgkgrfi-e1mDWThhbionWGXT9n51BZudndQkJdqXTp2Y8eFFT (дата обращения: 29.10.2025).
43. 1. Что такое база данных: определение, структура, функции | Контур.Школа. [Электронный ресурс]. URL: https://school.kontur.ru/articles/1231-chto-takoe-baza-dannyh (дата обращения: 29.10.2025).
44. 2. Анализ предметной области | Занятие 3. [Электронный ресурс]. URL: https://habr.com/ru/articles/717830/ (дата обращения: 29.10.2025).
45. 3. 2.1.2. Принципы создания информационных систем. [Электронный ресурс]. URL: https://www.intuit.ru/studies/courses/2301/476/lecture/11317?page=1 (дата обращения: 29.10.2025).
46. 4. Жизненный цикл разработки информационных систем. [Электронный ресурс]. URL: https://edu.tatar.ru/upload/documents/29532/SDLC_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9%20%D1%86%D0%B8%D0%BA%D0%BB.pdf (дата обращения: 29.10.2025).
47. 5. ER-диаграмма: что это, как ее создать и использовать. [Электронный ресурс]. URL: https://skillbox.ru/media/code/er-diagramma-chto-eto-kak-ee-sozdat-i-ispolzovat/ (дата обращения: 29.10.2025).
48. 6. Учет готовой продукции на производстве — Школа финансовой грамотности Пророковой Марины. [Электронный ресурс]. URL: https://prosvetfin.ru/uchet-gotovoj-produktsii-na-proizvodstve/ (дата обращения: 29.10.2025).
49. 7. Федеральный закон «О бухгалтерском учете» от 06.12.2011 N 402-ФЗ. [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_122849/ (дата обращения: 29.10.2025).

Приложения

Включают скриншоты интерфейса АИС, ER-диаграммы, схемы данных, тексты SQL-запросов, примеры форм и отчетов.

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

1. Балдин, К. В. Информационные технологии в менеджменте: учеб. для студ. учреждений высш. проф. образования / К. В. Балдин. — М.: Академия, 2012. — 288 с.
2. Дейт, К. Введение в системы баз данных: проектирование. Реализация и управление. Пер. с англ. — СПб.: БХВ-Петербург, 2004. — 324 с.
3. Гарсиа-Молина, Г., Ульман, Дж., Уидом, Дж. Системы баз данных. Полный курс. Пер. с англ. — М.: Вильямс, 2004. — 1088 с.
4. Кошелев, В. Е. Access 2007. Эффективное использование. — М.: Бином-Пресс, 2009. — 590 с.
5. Кузин, А. В. Базы данных: учебное пособие / А. В. Кузин, С. В. Левонисова. — 2-е изд., стереотип. — Москва: Академия, 2008. — 320 с.
6. Кузнецов, С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с.
7. Малыхина, М. П. Базы данных: основы, проектирование, использование. — 2-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2007. — 528 с.
8. Мак-Дональд, М. Access 2007 Недостающее руководство. — СПб.: БХВ-Петербург, 2007. — 784 с.
9. Проектирование баз данных. СУБД Microsoft Access: Учебное пособие для вузов / Н. Н. Гринченко, Е. В. Гусев, Н. П. Макаров, А. Н. Пылькин, Н. И. Цуканова. — М.: Горячая линия-Телеком, 2004. — 240 с.
10. Сергеев, А. В. Access 2007. Новые возможности. — СПб.: Питер, 2008. — 176 с.
11. Харитонова, И., Рудикова, Л. Microsoft Office Access 2007. — СПб.: БХВ-Петербург, 2008. — 1280 с.
12. Хомоненко, А. Д. Базы данных: Учебник для высших учебных заведений / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев; под ред. Проф. А.Д. Хомоненко. — 6-е изд., СПб.: КОРОНА принт, 2009. — 736 с.
13. Автоматизированные информационные системы – определение термина.
14. Описание нормализации базы данных. Microsoft 365 Apps.
15. Примеры и принципы нормализации реляционных баз данных (БД). DecoSystems.
16. Проектирование баз данных: основные этапы, методы и модели БД. DECO systems.
17. Что такое база данных? Определение, типы, преимущества. Astera Software.
18. Что такое нормализация базы данных? Первый Бит.
19. Что такое нормализация базы данных?
20. Нормализация данных: что это и зачем их нормировать — правила нормирования данных в БД. Яндекс Практикум.
21. Что такое база данных? Значение, типы, компоненты. Prehost.com.
22. что такое БД, их типы, свойства, структура — примеры использования и управления таблицами баз данных. Яндекс Практикум.
23. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ И СОЗДАНИЯ БАЗ ДАННЫХ ДЛЯ СОВРЕМЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. Научные журналы Universum для публикации статей.
24. [Глава 13.] — 13.3 Бухгалтерский учет отгрузки и продажи готовой продукции.
25. Учёт готовой продукции — Википедия.
26. Учет готовой продукции (работ, услуг), ее отгрузки и реализации.
27. Учет готовой продукции на производстве — Школа финансовой грамотности Пророковой Марины.
28. Учет готовой продукции в бухгалтерском учете: организация, оценка — Контур.Бухгалтерия.
29. Определение дефицита товара. Lokad.
30. Дефицит и излишки товаров: как влияет схема поставок — Ольга Правук. Управление запасами: семинары, консультации.
31. ДЕФИЦИТ И ИЗЛИШКИ ТОВАРНЫХ ЗАПАСОВ — Ростовская Школа Логистики.
32. Проектирование баз данных — Википедия.
33. БД_ВТ: Лекция 9. Проектирование баз данных.
34. 4.6. Основы проектирования баз данных.
35. Проектирование ER-диаграммы — Национальная сборная Worldskills Россия.
36. ER-модель — Википедия.
37. ER-диаграмма: задачи, нотации, правила составления — Генератор Продаж.
38. что это, применение, нотации — как создать ER-диаграмму сущность-связь, примеры.
39. Что такое ER-диаграмма и как ее создать? — Lucidchart.
40. Методы анализа информационных систем.
41. Методика системного анализа.
42. РАЗЛИЧНЫЕ ПОДХОДЫ К СИСТЕМНОМУ АНАЛИЗУ И ПРОЕКТИРОВАНИЮ.
43. Применение методов системного анализа при проектировании и разработке системы, обеспечивающей взаимодействие разнородных автоматизированных систем — КиберЛенинка.
44. 5.3. Системный анализ предметной области — Электронная библиотека >> Управление данными.
45. Существующие методики анализа предметных областей информационных систем.
46. 45. Методы анализа предметных областей.
47. Методы и порядок проведения анализа предметной области — DissHelp.