Разработка приложения учёта продаж бытовой техники в среде 1С: Предприятие 8.2

 

 

 

Для того чтобы представить работу организации в развёрнутом виде нужно определить основные функции (рисунок 2.2). Для достижения результата необходимо:

• вести учёт товара на складе;
• учитывать продажи в магазине;
• осуществлять передачу товара со склада в магазин.

 

Рисунок 2.2 – Декомпозиция блока «Учёт продаж бытовой техники»

 

 

 

 

 

 

 

 

 

 

 

 

Для отображения подробной  функциональности склада блок «Учёт товара на складе» необходимо декомпозировать. Данный блок декомпозируется на следующие блоки (рисунок 2.3):

• приём товара;
• проверка поставленного товара;
• складирование;
• отгрузка в магазин;
• возврат брака поставщику.

 

Рисунок 2.3 – Декомпозиция блока «Учёт товара на складе»

 

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

 

 

 

 

 

 

 

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

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

 

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

 

Рисунок 2.4 – Декомпозиция блока «Учёт товара в магазине»

 

 

2.3 Построение модели DFD

 

Диаграммы потоков данных (Data Flow Diagramming) используются для описания потоков информации между работами. Модели DFD можно использовать как дополнение к модели IDEF0 для более подробного отображения текущих операций.

Для разъяснения работы склада блок «Проверка поставленного товара» декомпозируется на следующие элементы (рисунок 2.5):

• работы:
1. сравнение заказанного и поставленного товара;
2. проверка качества товара;
3. зарегистрировать приход товара;
4. работа с поставщиком;
5. обновить справочник «Номенклатура»;
6. обновить справочник «Контрагенты».
• внешние сущности:
1. поставщик.
• хранилища данных:
1. справочник «Номенклатура»;
2. справочник «Контрагенты».

 

Рисунок 2.5 – Декомпозиция блока «Проверка поставленного товара»

 

 

2.4 Построение модели IDEF3

 

IDEF3 (workflow diagramming) используется для описания логики взаимодействия информационных потоков.

Для уточнения логики приёма товара на складе блок «Приём товара»  декомпозируется на следующие элементы (рисунок 2.6):

• единицы работы:
1. заказ товара у поставщика;
2. подготовка к приёму товара;
3. разгрузка товара;
4. отправка товара на розничный склад;
5. отправка товара на оптовый склад;
6. оформление приходной накладной.

 

 

Рисунок 2.6 – Декомпозиция блока «Приём товара»

 

 

 

2.5 Разработка структуры базы данных

 

Проектирование  структуры базы данных является неотъемлимой частью процесса разработки ИС. Для моделирования данных используется инструментальное средство «ERWin».

«ERWin» – это средство для разработки структуры данных. Оно сочетает в себе графический интерфейс, инструменты для создания ER – диаграмм, а так же редакторы для создания логического и физического описания модели данных.

Построение  структуры БД включает в себя следующие  шаги:

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

 

«ERWin» имеет логический и физический уровни представления информационной модели БД.

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

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

2.5.1 Логическая модель

 

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

При помощи «ERWin» была создана модель БД, в которую входят следующие сущности (рисунок 2.7):

• номенклатура;
• контрагенты;
• менеджеры;
• приходная накладная;
• товарный чек.

 

 

Модель БД включает следующие связи:

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

 

Сущности  в модели БД имеют следующие атрибуты:

• Kontragenti:
1. IDK – идентификационный номер контрагента. Данный атрибут является первичным ключом сущности;
2. GryppaKon – группа контрагента;
3. NaimKon – наименование контрагента;
• Nomenklatyra:
1. IDN – идентификационный номер номенклатуры. Данный атрибут является первичным ключом сущности;
2. GryppaNom – группа номенклатуры;
3. NaimNom – наименование номенклатуры;
• Menegeri:
1. IDM – идентификационный номер менеджера. Данный атрибут является первичным ключом сущности;
2. NaimMen – ФИО менеджера;
3. Doljnost – должность, занимаемая менеджером;
• Spisok nomenklatyri:
1. IDSN – идентификационный номер списка номенклатуры. Данный атрибут является первичным ключом сущности;
2. Kolichestvo – количество одной позиции номенклатуры;
3. Cena – цена за одну позицию номенклатуры;
4. Symma – сумма за все позиции номенклатуры;
5. GryppaSvoistv – Группа свойств позиции номенклатуры;
• Prixodnaya nakladnaya:
1. Nomer – идентификационный номер приходной накладной. Данный атрибут является первичным ключом сущности;
2. Data – дата проведения документа;
3. Organizaciya – организация заказчик;
4. VidPostyplenia – вид поступления товара;
5. Sklad – склад, на который поступил товар;

 

 

• Tovarnii chek:
1. Nomer – идентификационный номер товарного чека. Данный атрибут является первичным ключом сущности;
2. Data – дата проведения товарного чека;

 

Рисунок 2.7 –  Логическая модель

 

 

Для перехода к физической модели базы данных необходимо указать целевую СУБД. ERwin непозволяет использовать в качестве СУБД «1С: Предприятие 8.2», по-этому не представляется возможным создать физическую модель базы данных.

 

Выводы

 

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

 

3 Разработка алгоритмов и программного обеспечения

 

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

3.1 Разработка структуры программы

 

 

Рисунок 3.1 – Структура программы

 

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

 

3.2 Процесс создания объектов конфигурации

 

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

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

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

 

Рисунок 3.2 –  Дерево конфигурации

 

 

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

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

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

• «Справочник». Справочники служат для описания таких сущностей как товары, контрагенты, склады и прочие. У сущностей имеются общие свойства, например внутренняя идентификация, поддержка иерархии, поддержка внутренних машин;
• «Документ», «Журнал документов», «нумератор», «последовательность». Служат для описания таких сущностей как счета, накладные, заказы и прочее. Эти сущности отображаются в учётных механизмах;
• «Регистр накопления». Отвечают за учёт движения ресурсов (Финансов, товаров, материалов);
• «Регистр сведений». Регистры сведений предназначены для хранения многомерных сведений о значениях различных величин, например курсы валют или значения цен;
• «План счетов», «регистр бухгалтерии». Предназначены для построения модели, реализующей систему двойной записи бухгалтерского учёта;
• «План видов расчёта», «регистр расчёта». Позволяют описывать различные виды расчёта, например оклад или штраф;
• «Задача», «бизнес – процесс». Позволяют создавать формализованные описания типичных последовательностей работ, выполняемых в организации;
• «Обработка», «отчёт». Служат для обработки информации в системе и получения сводных данных в удобном для просмотра виде.