Статья опубликована в рамках: XXXI Международной научно-практической конференции «Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ» (Россия, г. Новосибирск, 28 апреля 2015 г.)
Наука: Информационные технологии
Скачать книгу(-и): Сборник статей конференции
- Условия публикаций
- Все статьи конференции
дипломов
РАЗРАБОТКА ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ПРИЛОЖЕНИЯ В КОНФИГУРАТОРЕ 1С
Кормановская Анна Сергеевна
студент 3 курса Прикладной информатики, Ярославский филиал МЭСИ, РФ, г. Ярославль
E -mail: anna.nomos@mail.ru
Заботина Наталья Николаевна
научный руководитель, канд. техн. наук, доцент, Ярославский филиал МЭСИ, РФ, г. Ярославль
Популярность платформы 1С объясняется возможностью адаптироваться под конкретные нужды большинства организаций и предприятий всех форм собственности. Разработка индивидуальной конфигурации позволяет создать программный продукт, способный решать конкретные задачи без дополнительных ненужных модулей, которыми снабжены типовые конфигурации. Гибкость технологической платформы 1С обеспечивает модификацию самых разнообразных приложений.
Целью данной разработки является создание командного интерфейса при проектировании информационной системы (ИС) «Организация управления доставкой нефтепродуктов в системе АЗС» на основе платформы 1С: Предприятие 8.
Командный интерфейс — это основное средство навигации пользователя по функциональности конфигурации. В системе 1С:Предприятие он строится на основе подсистем. Разработчик должен создать в конфигурации иерархию подсистем, отражающую для пользователя структуру функциональности прикладного решения [2].
Работа приложения ИС «Управление доставкой нефтепродуктами» начинается с открытия базы данных. Создаем новую информационную базу и называем её «Перевозка нефтепродуктов». Открываем конфигуратор и дерево конфигурации. Задаем самой конфигурации имя. После этого приступаем к созданию самой базы.
После открытия базы данных автоматически загружается рабочий стол, на котором размещены все действующие заявки и подсистемы «Доставка топлива» и «Реализация топлива» (рис. 1). С этого начинается вся работа. После поступления заказа с АЗС, диспетчер должен составить заявку, на основе заявки создать документ «Маршрутный лист». Рабочий стол необходим для быстрого доступа пользователей ко всем объектам проектируемой ИС, он всегда появляется как закладка командного интерфейса в процессе открытия системы в пользовательском режиме.
Для того чтобы учитывать перевозку нефтепродуктов, нужно знать куда, сколько и какое топливо нужно перевезти, а также нужно указать ответственного водителя. Все документы создаются на базе справочников. Для их создания нажимаем в дереве конфигурации форму «Справочники», добавить новый справочник. Задаем справочнику свое имя.
Рисунок 1. Подсистемы командного интерфейса
Объект конфигурации Справочник является прикладным объектом и предназначен для описания списков данных [1]. Справочник используется для того, чтобы на его основе платформа создала в базе данных информационную структуру, в которой будет храниться, например, перечень АЗС (автозаправочных станций), ТС (транспортных средств) и т. д. Характерной особенностью объекта конфигурации Справочник является то, что пользователь в процессе работы может самостоятельно добавлять новые элементы в справочник. Например, пользователь может добавить в справочник новое транспортное средство или водителя.
Каждая подсистема имеет в своем составе свои необходимые объекты. Подсистема «Доставка топлива» включает объекты «Водители», «Маршрутный лист», «ТС». Подсистема «Реализация топлива» содержит перечень АЗС и виды топлива.
В соответствии с данной предметной областью были созданы следующие справочники: 1) АЗС; 2) ТС; 3) Водители; 4) Топливо. Справочник «АЗС» содержит сведения о АЗС, которые состоят в системе компании «Татнефть». Справочник «ТС» содержит информацию о транспортных средствах компании. Справочник «Водители» хранит в себе сведения о водителях, которые нанимаются компанией. Справочник «Топливо» содержит наименования видов топлива, которые поставляет компания.
Теперь нужно зафиксировать выполняемы нами действия. Первое действие — это принять заявку с АЗС. Второе действие — формирование маршрутного листа. Третье действие — фиксирование времени после убытия водителя с АЗС. Значит, у нас будет 3 документа. Аналогичным образом выбираем ветку «Документы», добавить новый документ. Называем документ «Заявка». Для того, чтобы заполнить этот документ нам нужно указать АЗС, статус и оставшееся количество его определенного вида топлива. Значит, мы создадим у этого документа 4 реквизита. Добавляем первый реквизит и называем его «АЗС». Теперь выбираем тип реквизита — СправочникСсылка.АЗС. Этот реквизит будет указывать, какая именно АЗС нуждается в топливе. Аналогично поступаем с остальными реквизитами. Тип реквизита «Топливо» будет таким же — СправочникСсылка.Топливо, выбор происходит из справочника «Топливо». Тип реквизита «Количество» — Число, длина 10. Тип реквизита «Статус» — строка, длина 200. Теперь нужно создать другой документ «Маршрутный лист». Задаем ему реквизиты: АЗС, Топливо, Количество, ТС, Водитель, Время прибытия план, Статус. Этот документ будет создаваться на основании документа «Заявки». Чтобы не заполнять поля АЗС, Топливо, Количество и Статус заново, для документа «Маршрутный лист» откроем модуль объекта, и создадим обработчик события «ОбработкаЗаполнения». В данном параметре будет передана ссылка на документ «Заявки». Теперь при открытии документа «Маршрутный лист» данные реквизиты будут заполняться автоматически. Остается ввести ТС, водителя, а также время по прибытию.
В данный документ также должны быть включены данные по времени, для того, чтобы посчитать время в пути водителя. Для начала нужно создать собственную форму документа (рис. 2). Чтобы вычисления могли выполняться, нужно поместить необходимые данные в таблицу: время прибытия по факту, время убытия водителя из АТП, и соответственно время в пути.
Рисунок 2. Форма документа «Маршрутный лист»
Время прибытия по факту и время убытия вводится вручную. Но вот время в пути по каждой из строк табличной части вполне поддается автоматизированному расчету на основе этих данных. Для того, чтобы автоматически заполнить поле «Время в пути» по каждой из строк табличной части, редактируемой пользователем, очевидно, что рассчитывать его имеет смысл после заполнения поля «Время прибытия по факту». Назначим обработчик событий «ПриИзменении» для поля «ТабличнаяЧасть1ВремяПрибытияФакт». Теперь нам нужно реализовать то, что при изменении времени по прибытию в поле «ВремяВПути» автоматически рассчитывалось время в пути.
Итак, наша задача может быть решена следующим образом:
&НаКлиенте
Процедура ТабличнаяЧасть1ВремяПрибытияФактПриИзменении(Элемент)
РассчитатьВремя();
КонецПроцедуры
&НаКлиенте
Процедура РассчитатьВремя()
ТекущаяСтрока=Элементы.ТабличнаяЧасть1.ТекущиеДанные;
ТекущаяСтрока.ВремяВПути=ТекущаяСтрока.ВремяПрибытияФакт -ТекущаяСтрока.ВремяУбытия;
КонецПроцедуры
Из обработчика событий «ПриИзменении» вызывается клиентская процедура РассчитатьСумму(). Здесь мы получаем данные текущей строки через свойство «ТекущиеДанные» и вычисляем поле «ВремяВпути», вычитая данные из поля «ВремяПрибытияФакт» данные поля «ВремяУбытия».
На основании данных документов происходит перенос накопленных данных в регистр накоплений. Регистры специальным образом хранят учётные данные, поставляемые документом. При проведении документ записывает по некоторому алгоритму свои данные в регистр. В свою очередь отчеты оперируют уже не данными документов, а теми данными, которые хранятся в регистре. Регистры специальным образом обрабатывают данные, так чтобы отчеты могли быстро получить нужные им итоговые значения. Таким образом, дело отчета выбрать из регистра данные в нужном нам разрезе, а дело документа — поместить свои данные в регистр в соответствии с прикладной логикой. Поэтому добавим новый регистр и назовем его «Учет перевозок». Раскроем регистр и добавим Измерения регистра. Измерения регистра — это разрезы, где учитываются хранимые данные. Нас могут интересовать 3 разреза: Водители, АЗС, Топливо. Какие водители, на какую АЗС, какой вид топлива доставили. Ресурсы регистра — это сами учитываемые показатели. В нашем случае учитываемым показателем будет — количество. В регистре Учет перевозок во вкладке Регистраторы указываем документы, из которых будут браться данные: Заявки, Маршрутный лист. Теперь остается записать алгоритм, в соответствии с которым они будут помещать свои данные в этот регистр.
Теперь все эти данные требуется разместить в подсистемах. Для этого: два раза щелкаем по подсистеме и заходим в «Состав». Здесь помечаем то, что мы хотели бы видеть в данной подсистеме.
Таким образом, на основе структуры объектов подсистем платформа сама автоматически строит командный интерфейс приложения, удобный для пользователя.
Список литературы:
1.Заика А.А. Основы разработки для платформы 1С:Предприятие 8.2 в режиме "Управляемое приложение"/ [Электронный ресурс]. — Режим доступа: — URL: http://www.intuit.ru/studies/courses/2318/618/info (дата обращения 12.04.2015).
2.Толковый словарь 1С:Предприятия 8/ [Электронный ресурс]. — Режим доступа: — URL: http://v8.1c.ru/overview/Term_000000282.htm (дата обращения 18.04.2015).
дипломов
Оставить комментарий