Программное обеспечение пункта обмена валюты банка.
Введение
В начале восьмидесятых годов нашего столетия фирма IBM разработала и выпустила в продажу свой первый персональный компьютер IBM PC, который быстро завоевал рынок вычислительной техники благодаря своей невысокой стоимости, универсальности сфер применения, простоте эксплуатации и самое главное, принципу открытой архитектуры, заложенному в конструкцию. Получив название “персональный” он и в действительности оказался таковым.
РС хорошо зарекомендовал себя в области делового применения. Дешевый и надежный компьютер стал быстро “обрастать” программным обеспечением, многие фирмы стали выпускать клоны IBM-совместимых персональных компьютеров. За РС последовали XT, AT на базе i286, i386, i486 и, наконец, Pentium.
Вычислительная техника шагает в будущее гигантскими шагами, не оставляя в стороне никого. Невозможно представить область интенсивной деятельности человека, которая могла бы обойтись без вычислительной техники без ущерба для себя. В нашей стране за последние 5-6 лет парк персональных компьютеров увеличился в сотни раз. Особое значение в такой ситуации имеет наличие программного обеспечения для персональных ЭВМ как общего назначения, так и чисто прикладных программ, решающих специализированные задачи того, или иного предприятия.
Особенно остро встала проблема специализированного ПО для финансовых организаций и, в частности банков, количество которых за последние пять - шесть лет превысило несколько тысяч только в столице. Отсутствие автоматизированных банковских систем не могло не стимулировать многие фирмы - производители программного обеспечения заполнить образовавшийся вакуум. В течение 90-93 г.г. такие фирмы как “Асофт”, “Диасофт”, “Р-Стайл” и другие выпустили на рынок несколько АБС, ориентированных на российскую банковскую систему. Первый опыт оказался удачным и большинство коммерческих банков обладает на текущий момент довольно приличными системами, реализованными на основе сетевых менеджеров запросов к базам данных, или языках программирования Oracle, Gupta и им подобных. Беда всех АБС в нестабильности законодательства государства, которое вызывает многочисленные корректировки технологии бухгалтерского учета и, следовательно корректировки ПО. Кроме того, первые версии АБС не покрывали всех потребностей банков в автоматизации. Максимально на что мог рассчитывать пользователь, это операционный день банка в рублях и система отчетов. Расширение видов банковской деятельности, работа с валютами иностранных государств, вклады граждан и организаций, развитие рынка ценных бумаг потребовали разработки новых подсистем для существующих АБС.
Наряду с тем, что не все фирмы производители прислушиваются к требованиям пользователей, стоимость новых разработок достаточно велика. В качестве примера можно сказать, что только увеличение документооборота банковской системы с 500 до 2000 документов в день обходится пользователю, имеющему АБС фирмы “Р-Стайл” примерно в 11500 Долларов США. Такие цены, естественно могут заставить любого пользователя пополнять состав программного обеспечения собственными силами.
Назначение проекта
Обменный пункт - подразделение банка и является местом совершения банком валютно-обменных операций. Правила и нормы совершения валютных операций в обменном пункте регламентируются инструкцией Центрального банка Российской федерации №27 от 27 февраля 1995 года.
Комплекс разрабатываемых программных средств предназначен в первую очередь для автоматизации работы кассиров пунктов обмена валют, находящихся как в самом банке, так и вне его территории. Использование программы должно значительно упростить и ускорить работу кассира за счет автоматизации учетно-расчетных операций при обмене валюты. Автоматическое формирование всей сводной отчетности и контроль финансового состояния обменного пункта в любой момент времени также должны повысить эффективность работы кассира.
Технологический процесс работы пункта обмена валюты банка
В процессе работы кассира обменного пункта с использованием автоматизированной системы желательно реализовать как стандартные процедуры, обеспечивающие поддержку операций обменного пункта в течение дня, так и специфические возможности, повышающие производительность труда кассира и облегчающие учетно-расчетные операции и связь обменного пункта с банковской системой автоматизации. Обменный пункт банка при работе с клиентурой совершает следуюшие основные операции:
Продажа валюты иностранного государства клиенту за национальную валюту;
Покупка у клиента валюты иностранного государства за национальную валюту;
Коверсия (обмен) валюты одного иностранного государства на валюту другого иностранного государства.
Каждую из перечисленных операций кассир обменного пункта обязан зафиксировать документально и оформить справку о совершении клиентом валютно-обменной операции на бланке строгой отчетности ф.0406007, с выдачей копии справки клиенту. Для работы ОП, банк обеспечивает его до начала рабочего дня авансом в наличной иностранной валюте и рублях. Данный аванс необходимо учитывать в документах ОП для последующего отражения в отчетных документах при завершении операционного дня. По завершении рабочего дня (или смены при круглосуточном режиме работы ОП) кассир обязан заполнить приходно-расходную ведомость(реестр сделок) по каждой из валют, подсчитать итоги по всем реестрам и сверить сумму полученного аванса с суммой итогов по реестрам и фактическим остатком ценностей по каждому виду. В соответствии с результатами сверки составляется справка о ежедневных остатках ценностей.
Основные сервисные и информационно-расчетные возможности проектируемой системы
Перед началом проектирования какой-либо системы необходимо в первую очередь определить состав тех операций, которые будут заложены в проектируемый комплекс программных средств и проанализировать необходимость и возможность реализации функций средствами конкретной системы проектирования. Система автоматизации работы пункта обмена валюты предназначена, как уже было сказано выше, в первую очередь для повышения эффективности и скорости работы кассира. Поэтому функциональные возможности программного комплекса должны быть направлены на решение конкретных задач ОП возникающих в процессе работы.
Функциональные возможности системы
В проектируемой системе необходимо заложить возможности, обеспечивающие ниже перечисленные сервисные и информационно-расчетные функции:
автоматический расчет сумм по операциям обмена иностранной валюты;
возможность установки автоматического начисления комиссионных вознаграждений (по выбору - комиссия с прихода, расхода и разницы курсов) при обменных операциях;
автоматический контроль наличия в обменном пункте денежных знаков национальной и иностранной валюты различного достоинства;
выдача рекомендаций кассиру по оптимальному набору наличных денежных знаков различного достоинства из числа имеющихся в кассе при каждой обменной операции;
учет операций обмена валют, основанный на ведении двойной записи и обеспечивающий высокий уровень контроля обменных операций;
контроль и восстановление логической целостности базы данных даже в случаях некорректной работы оборудования за счет выполнения процедур ревизий состояния счетов на текущую дату или за заданный период в любой момент работы обменного пункта;
архивирование всех данных, обработанных системой с начала ее функционирования на дату операционного дня или интервал дат;
на основании данных о клиенте, вводимых при осуществлении обменной операции, должна производиться автоматическая печать справки об обмене валюты и фиксация в системе информации о клиенте с привязкой к конкретной операции.
Взаимодействие с банковской системой автоматизации
Взаимодействие подсистемы с системой автоматизации банка должно удовлетворять следующим требованиям:
Независимость от примененной системы автоматизации банковской деятельности;
Обмен информацией с банковской системой при помощи общепринятых носителей (магнитные диски, электронная почта и т.п.);
Формат передаваемых данных должен обеспечивать достоверный прием информации и ее обработку в системе автоматизации банка.
Проблема совместимости с различными банковскими системами разрешается путем применения стандартного формата передаваемых данных в виде текстового файла с разделителями информационных полей. Последовательность полей фиксирована, длина данных - переменная. Использование данных фиксированной длины, конечно упрощает их обработку, однако при больших объемах встает проблема величины передаваемого файла. Такой способ обмена может быть реализован практически во всех известных на данное время системах автоматизации банковской деятельности.
Надежность и резервирование
Все данные, проходящие через подсистему, подлежат обязательной фиксации в базах данных или иных информационных структурах. Система должна хранить данные в специальных архивных файлах начиная с момента запуска в эксплуатацию. При закрытии операционного дня все текущие данные должны переносится в архив, а файлы подготавливаться для новой смены (очистка, обнуление и т.п.). При работе ОП в локальном режиме желательно обеспечить возможность создания резервных копий баз данных на магнитных носителях по желанию пользователя. Для варианта ОП работающего в составе ЛВС банка, данная возможность может быть факультативной при размещении информационных файлов на сетевых дисках и ежедневном выполнении процедур резервирования сетевым оборудованием.
Генерация отчетов
Наиболее ответственной и трудоемкой из функций кассира ОП является ежедневное составление и заполнение отчетных документов по итогам работы пункта за смену. Проектируемая система должна предоставить пользователю возможность в любой момент времени получить документы дня (реестры сделок, справки об остатках наличности и пр.) в разрезе любой валюты. Это позволит оперативно иметь картину финансового состояния ОП в целом и осуществить оперативный контроль деятельности кассира. В состав обязательных отчетов необходимо включить:
Реестры по покупке и продаже иностранной валюты за наличные рубли;
Справку об остатках наличной иностранной и национальной валюты;
Акт передачи (для ОП работающих в режиме сменной работы);
Препроводительные ведомости к инкассаторским сумкам.
Формы отчетов должны соответствовать предложенным в инструкции ЦБ РФ №27 “О порядке организации работы обменных пунктов...”
Анализ потоков и взаимодействия данных
Цель реализации данного проекта состоит в первую очередь в регистрации и хранении всех данных по операциям с наличной иностранной валютой и иными платежными документами, данных о клиентах и генерации форм отчетности. Рассмотрение информационных составляющих начнем с операции оформления сделки купли-продажи наличной иностранной валюты клиенту.
Покупка и продажа наличной иностранной валюты за наличные рубли.
При совершении операции кассир ОП должен выполнить ряд расчетных операций и процедур оформления сделки, к которым относятся:
Вычисление клиентской суммы по текущему курсу покупки (продажи) данной валюты.
СУММА_В_РУБЛЯХ_ПОКУПКИ =СУММА_ВАЛЮТЫ*КУРС_ПОКУПКИ
или при продаже валюты
СУММА_В_ВАЛЮТЕ=СУММА_РУБЛЕЙ_КЛИЕНТА/КУРС_ПРОДАЖИ
Так как при покупке валюты клиент, как правило имеет целью купить определенную сумму валюты, вычисление суммы покупаемой валюты можно заменить расчетом рублевого эквивалента указанной клиентом суммы валюты аналогично операции покупки валюты у клиента
Заполнение справки ф. 0406007 и выдача клиенту копии.
Вся информация о сделке и клиенте содержится в данных, предоставляемых клиентом кассиру ОП для заполнения справки. Проанализировав ее содержание можно сделать первоначальный вывод о формате и структуре данных, необходимых для регистрации сделки.
Данные справки можно разделить на следующие информационные единицы:
Фамилия
Имя
Отчество
Вид документа (паспорт, удостоверение личности и т.п.)
Серия документа
Номер документа
Признак резидент/нерезидент
Код ценности полученной клиентом
Код валюты полученной клиентом
Сумма валюты полученной клиентом
Код ценности принятой от клиента
Код валюты принятой от клиента
Сумма валюты принятой от клиента
Серия справки
Номер справки
Дата совершения обменной операции
Конверсия наличной иностранной валюты
Операция конверсии (обмена) наличной иностранной валюты одного государства в наличную иностранную валюту другого государства практически аналогична описанным выше операциям купли/продажи валюты. Отличие состоит в том, что кассиру требуется вычислить сумму валюты, выдаваемую клиенту на основании суммы валюты клиента и кросс-курса. Кросс-курс, или курс пересчета валюты является числовой величиной, определяющей коэффициент пересчета одной валюты в другую.
СУММА_ВАЛЮТЫ_1=СУММА_ВАЛЮТЫ_2*КРОСС_КУРС
Пример:
Клиент обменивает 100 долларов США на немецкие марки по кросс-курсу USD-DEM 1,51
Клиент получит 100*1,51=151DEM
Так как кросс-курс обычно объявляется для односторонней операции, т.е. к примеру для конверсии USD-DEM, то для обратной операции необходимо применять иную формулу расчета:
СУММА_ВАЛЮТЫ_2=СУММА_ВАЛЮТЫ_1*(1/КРОСС_КУРС)
Пример:
Клиент обменивает 100 немецких марок на доллары США по кросс-курсу USD-DEM 1,51
Клиент получит 100*(1/1,51)=66,2USD
Документальное оформление операции конверсии в плане клиентских документов аналогично описанному выше.
Формы отчетной документации ОП
Все операции, совершенные в течение операционного дня обменным пунктом, по окончании смены обрабатываются для выдачи итоговых документов работы ОП. К таковым относятся:
Реестр наличной иностранной валюты, купленной за наличные рубли;
Реестр наличной иностранной валюты, проданной за наличные рубли;
Реестр по обмену (конверсии) наличной иностранной валюты;
В случае изменения банком в течение операционного дня курса покупки наличной иностранной валюты за наличные рубли кассир обменного пункта закрывает реестр, ведущийся по предыдущему курсу, подводит итоги и открывает новый реестр, ведущийся по новому курсу.
Реестры продажи и конверсии заполняются аналогично.
Технические требования к аппаратуре.
Работа проектируемого программного комплекса должна обеспечиваться наиболее распространенной в настоящее время персональной ЭВМ. Это соображение подразумевает выбор компьютера построенного на платформе INTEL. К таким ПЭВМ относятся различные модификации PC/AT с процессорами от 386 до Pentium различных фирм изготовителей. Поскольку в настоящее время машины класса PC/ХТ практически не применяются, выдвигать какие-либо особые требования к аппаратуре не имеет смысла, так-как стандартный компьютер на текущий момент имеет достаточную вычислительную мощность и объем оперативной памяти для работы практически любого программного обеспечения. Занимаемое программой дисковое пространство должно быть относительно невелико. Конечно, в процессе работы программы объем данных будет возрастать, но с этой проблемой можно справиться, применяя различные средства сжатия и архивации данных на магнитных носителях к примеру ленточного типа (стриммеры и т.п.) или иных со сменными носителями.
Среда выполнения программы.
При выборе среды выполнения программы необходимо учитывать несколько факторов, а именно:
сложность и трудоемкость процесса проектирования программного обеспечения для конкретной среды;
наличие инструментальных средств разработки программного обеспечения;
возможность внесения корректив в программу в процессе эксплуатации;
наличие средств проектирования пользовательского интерфейса;
скорость выполнения программы;
надежность работы программы и защищенность от программных сбоев.
Выбор среды ограничим двумя вариантами - среда DOS и Windows.
При рассмотрении преимуществ и недостатков той и другой платформ мы видим, что и в той и в другой средах имеется большое количество систем разработки программного обеспечения, таких, как Delphi, Dbase 5, VisualBasic 4 (Windows) и Clipper, Fox Pro, Clarion (DOS). С точки зрения трудоемкости процесса проектирования предпочтение можно отдать среде Windows, поскольку наличие систем визуального проектирования значительно облегчает работу программиста, в то же время надежность работы и защита от программных сбоев с среде DOS значительно выше, как в однозадачной среде.
Скорость обработки данных и собственно скорость выполнения программ также выше у DOS-приложений. Модификация программ, написанных для среды Windows, достаточно сложная задача, т.к. внесение изменений в сложную систему взаимодействия объектов и событий влечет за собой большое количество исправлений связанных между собой. Переустановка программного обеспечения в среде Windows также не всегда сводится к простому копированию измененных файлов. Кроме всего выше изложенного нужно учитывать возможность того, что DOS-приложения могут быть запущены и в среде Windows без каких-либо затруднений.
Выбор языка программирования для реализации проекта.
Таким образом, исходя из вышеизложенного, оптимальным вариантом для проектируемой системы будет выбор системы разработки работающей в среде DOS. Из имеющихся инструментальных систем наиболее распространенными являются системы проектирования Fox Pro и Clipper.
При сравнении этих двух систем видно, что по формату поддерживаемых баз данных набору операторов и функций для обработки данных они практически ничем друг отдруга не отличаются: и та и другая система поддерживают формат баз данных Dbase IV с комбинированными индексными файлами формата CDX. Наличие большого количества библиотек функций и возможность их создания, пополнения и быстрого подключения к программе делает систему Clipper более приемлемой для реализации данного проекта. Из имеющихся на данное время компиляторов наиболее функциональным является CA-Clipper 5.02 фирмы Computer Associates International, Inc.
Разработка структуры информационных файлов и их связей.
Предварительные соображения
Из проведенного выше анализа входных и выходных данных можно сделать предварительные соображения о структуре базы данных для хранения информации в нашей системе. В табл.1 приведена первоначальный вариант структуры базы с наименованиями полей и их типами, а также описанием назначения каждого из полей БД.
Таблица 1
Предварительная структура базы “Операции”
Имя поля |
Тип поля |
Длина |
Дробь |
Назначение |
FAM |
Char |
15 |
|
Фамилия |
NAME |
Char |
15 |
|
Имя |
SNAME |
Char |
15 |
|
Отчество |
CDOC |
Char |
10 |
|
Вид документа |
DSER |
Char |
7 |
|
Серия документа |
DNOM |
Num |
6 |
0 |
Номер документа |
REZIDENT |
Logical |
1 |
|
Признак резидент/нерезидент |
BCODC |
Num |
3 |
0 |
Код ценности полученной клиентом |
BNAMEC |
Char |
20 |
0 |
Наименование ценности полученной клиентом |
BCODCUR |
Num |
3 |
0 |
Код валюты полученной клиентом |
BNAMECUR |
Char |
20 |
0 |
Наименование валюты полученной клиентом |
BSUM |
Num |
15 |
2 |
Сумма валюты полученной клиентом |
SCODC |
Num |
3 |
0 |
Код ценности принятой от клиента |
SNAMEC |
Char |
20 |
0 |
Наименование ценности принятой от клиента |
SCODCUR |
Num |
3 |
0 |
Код валюты принятой от клиента |
SNAMECUR |
Char |
20 |
0 |
Наименование валюты принятой от клиента |
SSUM |
Num |
15 |
2 |
Сумма валюты принятой от клиента |
SSER |
Num |
2 |
0 |
Серия справки |
SNOM |
Num |
6 |
0 |
Номер справки |
DATA |
Date |
8 |
|
Дата совершения обменной операции |
Анализируя приведенную структуру можно внести некоторые коррективы, как в саму структуру, так и в состав информационных файлов программы в целом.
Нет необходимости хранить Фамилию Имя и Отчество клиента в отдельных полях БД, целесообразно объединить их в одно поле, приняв для него приемлемую длину.
Для кодов ценностей и валют необходимо предусмотреть специальные базы данных (справочники), в которых должны храниться коды и их расшифровка, поскольку список кодов валют и ценностей, приведенный на обороте справки не включает в себя все возможные коды, а хранение кодов и наименований в основной базе является неоправданным с точки зрения размера записи в БД.Кроме того заполнение граф документа с помощью справочников значительно облегчит и ускорит работу кассира. В системе необходимо предусмотреть специальную процедуру внесения в справочники изменений и дополнений.
Хранение в основной БД наименования документа клиента в символьном виде также нецелесообразно.Желательно хранить в базе код предъявленного документа из специального справочника, аналогично описанному выше.
Таким образом определился первоначальный состав информационных файлов. В него войдут:
Основная БД “Операции”;
Справочник кодов ценностей “Ценности”;
Справочник кодов валют “Валюты”;
Справочник видов документов “Документы”.
Для выполнения всех расчетных операций необходимо также иметь еще одну БД, в которой будут храниться числовые величины обменных курсов валют за каждый день. Описать курс валюты можно следующими информационными единицами:
Код валюты;
Наименование валюты;
Краткое наименование валюты;
Дата установки курса;
Время установки курса;
Курс покупки валюты банком за наличные рубли;
Курс продажи валюты банком за наличные рубли;
Масштаб;
Понятие масштаб используется в том случае, когда курс описываемой валюты относительно базовой меньше единицы. Обычно задают сумму в базовой валюте, которая содержится в единице описываемой валюты, например, 5500 рублей на 1 доллар США. Число МАСШТАБ можно использовать, как количество единиц описываемой валюты, относительно которых пользователь задаст валютный курс в виде суммы в базовой валюте. Например, для украинского карбованца курс будет равен 1 рубль на 20 карбованцев, если МАСШТАБ принять за 20.
Для удобства работы и повышения скорости обработки данных есть смысл в базе данных “Валюты” хранить кроме кода и наименования валюты, также и некоторве текушие данные, необходимые при расчетных операциях - краткое наименование, текущий курс покупки и продажи, курс ЦБ России.
Окончательный состав и структуры информационных файлов.
Таким образом мы можем определиться по составу БД проектируемой программы: основная база данных предназначена для хранения данных о совершенных в течение операционного дня (смены) обменных операциях и данных о клиентах, дополнительные БД справочников, в которых содержится информация о кодах и наименованиях ценностей, валют и видах документов и база данных курсов валют на каждую дату. Структуры БД системы приведены в табл. 2-6.
Таблица 2.
Структура базы данных “Операции”
Имя поля |
Тип поля |
Длина |
Дробь |
Назначение |
FIO |
Char |
35 |
|
Фамилия, Имя, Отчество |
CDOC |
Num |
3 |
|
Код вида документа |
DSER |
Char |
7 |
|
Серия документа |
DNOM |
Num |
6 |
0 |
Номер документа |
REZIDENT |
Logical |
1 |
|
Признак резидент/нерезидент |
BCODC |
Num |
3 |
0 |
Код ценности полученной клиентом |
BCODCUR |
Num |
3 |
0 |
Код валюты полученной клиентом |
BSUM |
Num |
15 |
2 |
Сумма валюты полученной клиентом |
SCODC |
Num |
3 |
0 |
Код ценности принятой от клиента |
SCODCUR |
Num |
3 |
0 |
Код валюты принятой от клиента |
SSUM |
Num |
15 |
2 |
Сумма валюты принятой от клиента |
SSER |
Num |
2 |
0 |
Серия справки |
SNOM |
Num |
6 |
0 |
Номер справки |
DATA |
Date |
8 |
|
Дата |
Таблица 3
Структура базы данных “Ценности”
Имя поля |
Тип поля |
Длина |
Дробь |
Назначение |
COD |
Num |
3 |
0 |
Код ценности |
NAME |
Char |
25 |
|
Наименование ценности |
Таблица 4
Структура базы данных “Валюты”
Имя поля |
Тип поля |
Длина |
Дробь |
Назначение |
COD |
Num |
3 |
0 |
Код валюты |
NAME |
Char |
25 |
|
Наименование валюты |
BKURS |
Num |
10 |
2 |
Курс покупки |
SKURS |
Num |
10 |
2 |
Курс продажи |
CKURS |
Num |
10 |
2 |
Курс ЦБ РФ |
SHORT_NAME |
Char |
3 |
|
Краткое наименование валюты |
SCALE |
Num |
4 |
0 |
Масштаб |
Таблица 5
Структура базы данных “Документы”
Имя поля |
Тип поля |
Длина |
Дробь |
Назначение |
COD |
Num |
3 |
0 |
Код документа |
NAME |
Char |
25 |
|
Наименование документа |
Таблица 6
Структура базы данных “Курсы валют по датам”
Имя поля |
Тип поля |
Длина |
Дробь |
Назначение |
COD |
Num |
3 |
0 |
Код валюты |
NAME |
Char |
25 |
|
Наименование валюты |
BKURS |
Num |
10 |
2 |
Курс покупки |
SKURS |
Num |
10 |
2 |
Курс продажи |
CKURS |
Num |
10 |
2 |
Курс ЦБ РФ |
SHORT_NAME |
Char |
3 |
|
Краткое наименование валюты |
SCALE |
Num |
4 |
0 |
Масштаб |
DATA |
Date |
8 |
|
Дата установки курса |
TIME |
Char |
5 |
|
Время установки курса |
Взаимодействие данных, связи и методы доступа.
Надежность и скорость обработки информации программой во многом определяются качеством проектирования методов доступа к данным системы и связей между отдельными информационными единицами. В нашем случае просматривается один тип связей КОД-НАИМЕНОВАНИЕ для справочников кодов и валют. Такой тип связи реализуется штатными средствами Clipper’а, такими, как установка реляционной связи между двумя базами данных (двумя рабочими областями) по значению ключа
или номеру записи при помощи команды SET RELATION.
SET RELATION является командой обработки баз данных, которая связывает родительскую рабочую область с одной или более дочерними областями путем использования ключевого выражения, номера записи или числового выражения. Каждая родительская рабочая область может быть связана не более, чем с восемью дочерними рабочими областями. Отношение связи заставляет указатель записи перемещаться в дочерней рабочей области в соответствии с перемещением указателя записи в родительской рабочей области. Если в дочерней рабочей области не обнаруживается соответствия, то дочерний указатель записи помещается в позицию “за конец файла”, и результат поиска принимает значение "ложь" (.F.).
Способ связывания родительской и дочерней рабочих областей зависит от типа выражения ключа и присутствия активного ведущего индекса в дочерней рабочей области. Если дочерняя рабочая область имеет активный индекс, поиск осуществляется с помощью стандартной команды SEEK. Если же дочерняя рабочая область не имеет активного индекса, а тип выражения ключа числовой, то вместо этого в дочерней рабочей области выполняется команда GOTO.
Такой способ доступа к данным позволяет очень быстро и надежно находить значение ключевого выражения в связанной БД и обеспечивает автоматическое сканирование дочерней базы данных при перемещении указателя записи в основной базе.
Для обеспечения надежной связи данных необходимо предусмотреть в процедуре пополнения справочников автоматическое создание ключевого выражения. Оно должно удовлетворять следующим требованиям:
Уникальность ключа;
Небольшой размер ключевого выражения для уменьшения размеров индексного файла и ускорения поиска при большом количестве записей.
При создании ключа не желательно в его качестве использовать номер записи. При таком способе уникальность ключа может быть сохранена только если запрещено физическое удаление записей из файла справочника, хотя этот способ наиболее просто реализуем. В нашем случае есть смысл остановиться именно на нем, поскольку физическое удаление записей из справочников приведет к потере логической связи архивных документов. Таким образом при необходимости удаления, запись будет просто помечена, как удаленная и вдальнейшем не будет выводиться в списках.
Одним из важных моментов в проектировании информационно-справочных систем является организация ввода данных пользователем и их дальнейшая обработка. При вводе данных, как правило, используются две формы ввода: табличная и бланк. В проектируемой системе ввод данных по обменной операции желательно организовать в форме бланка при оформлении операции и в таблице при корректировке и пополнении справочников. При вводе курсов валют можно применить комбинированную форму ввода: поиск валюты по списку табличной формы, а ввод курса в форме бланка. Основным режимом работы пользователя будет являться ввод данных по операциям обмена, поэтому бланк ввода необходимо спроектировать таким образом, чтобы форма соответствовала стандартной справке. Ввод данных из справочников можно оформить так, чтобы вызов справочника обеспечивался нажатием функциональной клавиши, соответствие справочника текущему полю ввода также должно обеспечиваться автоматически по имени поля ввода. Запись данных в базу должна производиться после подтверждения пользователем правильности всех введенных числовых и символьных данных и расчетных величин.
После ввода данных необходимо дать пользователю возможность распечатки бланка справки и копии клиента. данная операция должна быть выполнена в обязательном порядке. Печать может быть осуществлена на два типа принтеров: ударного действия (матричные) и струйные. Печать справки на лазерных принтерах невозможна из-за повышенных требований к качеству бумаги. При печати справки на матричном принтере можно осуществить печать двух экземпляров (справка+копия) за один проход с применением копировальной бумаги. На струйном принтере необходимо печатать каждый экземпляр отдельно. Таки м образом нужно предусмотреть изменяемый пользователем счетчик числа копий или специальную функцию настройки на тип принтера.
Разработка функциональной схемы программы.
Функциональный состав программы должен максимально обеспечивать необходимый набор возможностей для выполнения кассиром ОП его должностных обязанностей, связанных с вводом данных, регистрацией сделок и оформлением отчетных документов. Для этого составим примерный перечень функций, которые должны быть реализованы в нашей системе.
Примерный перечень функций системы.
Регистрация обменной операции
Ввод данных по покупке валюты
Ввод данных по продаже валюты
Ввод данных по конверсии валюты
Печать справки клиента
Просмотр документов
Просмотр списка документов дня
Просмотр списка архивных документов
Ведение справочников
Ввод данных по кодам ценностей
Ввод данных по видам документов
Ввод данных по кодам валют
Ввод курсов валют по датам
Генерация отчетных документов
Печать реестра наличной иностранной валюты, купленной за наличные рубли;
Печать реестра наличной иностранной валюты, проданной за наличные рубли;
Печать реестра по обмену (конверсии) наличной иностранной валюты;
Прочие функции
Ввод данных в поле ввода из справочника
Перевод числа из цифровой формы в строчную (сумма прописью)
Изменение вида курсора
Сохранение данных в архивных файлах
Приведенный перечень охватывает все процедуры, описанные в разделе технологического процесса ОП и дополнен некоторыми функциями, которые будут необходимы в процессе ввода данных и их корректировки.
Разработка структурной схемы программы.
Структурная схема программного комплекса определяет в основных чертах и внешний вид проектируемой системы и принципы взаимодействия с пользователем. Схема проектируемой системы будет представлять собой иерархическую древовидную структуру, описывающую процедуры ввода, обработки и вывода данных. Построение программ информационно-справочного класса по такому принципу позволяет довольно легко производить модификацию системы в целом и облегчает восприятие и понимание принципа работы программы. Для построения структурной схемы необходимо определить иерархию и связь перечисленных выше процедур обработки данных. Естественно установить иерархию процедур в том виде, в каком они были описаны в предыдущей главе, поскольку таковая схема соответствует схеме “важности” и “употребимости” процедур. Разработка экранного интерфейса программы
Существующие подходы к проектированию экранного интерфейса
Экранный интерфейс программы во многом определяет удобство работы пользователя и является одним из важных факторов, влияющих на эффективность его труда. Программа, выполняющая все возложенные на нее функции, обладающая высоким быстродействием может быть полностью непригодной для работы из-за неприемлемого интерфейса с пользователем. Еще буквально несколько лет назад существовал текстовый редактор, прекрасно иллюстрирующий такой подход к проектированию программного обеспечения. Вряд ли кому-то придется по душе редактор текста, в котором для вставки символа в строку нужно набрать однобуквенный код команды вставки, номер обрабатываемой строки (к счастью не двоичный), номер символа, после которого будет вставлен новый символ и собственно этот символ. Конечно такой подход абсолютно неприемлем.
Наиболее практичными и удобными с точки зрения пользователя можно считать системы, имеющие экранный интерфейс, построенный на основе системы всплывающих меню. Наиболее распространенными в настоящее время являются две идеологии (имеются в виду DOS-приложения), включающие в себя и определенную форму экранных окон и цветовую гамму и вид всплывающих списков. Это инструментальные Среды фирмы Borland, и операционная оболочка Norton, фирмы Symantec. Обе идеологии предусматривают определенное разбиение экранного пространства на области или зоны, предназначенные для конкретных информационных объектов и действий. Зоны могут быть в некоторой степени переконфигурированы по желанию пользователя: изменены размеры и положение на экране. Команды обработки данных вызываются из системы меню, присутствующего на экране постоянно (Borland), или вызываемого по функциональной клавише (Symantec).