Программные продукты и системы

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

В настоящее время осуществляется планомерная информатизация Государственной налоговой службы России в соответствии с [1-3]; в документах регламентируются принципы формирования и порядок предоставления данных о доходах физических лиц. Используемое в настоящий момент программное обеспечение разрабатывается ГНИВЦ РФ на СУБД FoxPro 2.6.

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

Налоговые инспекции осуществляют прием информации о доходах физических лиц на магнитных носителях от предприятий и организаций, а существующие системы обработки информации развиваются и находятся в стадии разработки. Авторами статьи предлагаются некоторые подходы к обработке информации с использованием средств RAD (Rapid Application Development), а именно Borland DelphiÒ версия 4.0 с установленным Update Pack 2, работающая под Microsoft Windows-98Ò.

Формат файла передачи данных детально описан в [3]. Основную сложность при обработке информации составляет контроль правильности входной информации, а также различия в использованной кодировке информации DOS и кодовой страницы 1251 Microsoft Windows-98Ò. Что касается контроля входной информации, то одной из проблем также является применение различных алгоритмов разбора входящей информации.

Структуру входного файла можно представить в виде схемы (рис. 1).

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

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

Рассмотрим принцип контроля адреса плательщика, обычно используемый в существующем ПО (в частности, рассматривался ИК 2.0, написанный с применением СУБД FoxPro 2.6.):

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

-     осуществляется “смысловой” контроль реквизита, для чего его содержимое сопоставляется с классификатором адресов;

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

В данной ситуации существует несколько так называемых узких мест:

·  при формировании данных вручную возможно возникновение как семантических, так и синтаксических ошибок;

·  при использовании сертифицированного ПО основным узким местом является отсутствие абсолютного большинства адресов РФ в классификаторе или использование более старой версии классификатора подателями сведений;

·  наименование реквизитов может изменяться в дальнейшем, однако в большинстве ПО данная ситуация также не учитывается;

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

В этом случае предлагается использовать подход с учетом возможностей средств Delphi, а также технологии клиент-сервер (в нашем примере рассматривается вариант с использованием Interbase).

1.   Применительно к анализу файла с информацией о доходах физических лиц, учитывая возможность изменения в будущем его структуры (формы представления информации), а также формы и представления реквизитов, предлагается хранить вместе как формат, так и дескрипторы функций обработки, причем применительно к функциям можно использовать и процедуры Delphi (здесь узкое место – необходимость перекомпиляции DLL) и хранимые Interbase процедуры (здесь основная проблема – жесткая привязка к единственной СУБД, непереносимость программ).

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

Размещение списка реквизитов на СУБД

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

Эта процедура осуществляет поиск очередного анализируемого реквизита в СУБД и в случае присутствия возвращает единицу, что соответствует логическому значению True (Истина) или (в обратном случае) ноль – False (Ложь).

Достоинством ее является возможность обращения к ней из любой версии программы. Даже в случае изменения содержимого программный интерфейс останется неизменным (причем обращаться к данной процедуре можно из любой программной среды с возможностью взаимодействия с ODBC либо BDE драйвером Interbase). К недостаткам следует отнести большие затраты по времени, чем при работе, например, с Paradox или dBase файлом, используя не SQL, а методы класса TTable Borland Delphi.

Совместное хранение реквизитов и дескрипторов их обработчиков

На образце реквизита АдрФизЛица, содержащего адрес физического лица, рассмотрим примеры хранимой процедуры, ее вызова и организации интерфейса программиста.

Реквизит имеет следующую структуру: «код страны», «код региона», «город», «район», «населенный пункт», «улица», «дом», «корпус», «квартира». Отсутствующие реквизиты пропускаются, каждый реквизит анализируется по содержимому классификатора адресов.

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

Вариант совместного хранения данных и дескрипторов процедур в СУБД представлен в таблице.

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

Select from TstFizAdr(:P_RekvAdr, :P_RekvDesc, :P_Result)

Мы задаем P_RekvAdr как входной параметр, в котором передаем обрабатываемый реквизит, P_RekvDesc – дескриптор процедуры обработчика, а P_Result возвращает True (Истину), либо False (Ложь) в зависимости от существования данного реквизита.

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

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

Пример вызова хранимых процедур из Delphi

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

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

Применение подобного подхода позволяет гибко анализировать поступающую информацию, а в случае изменения формата файла обеспечивается коррекция функций обработки реквизитов с минимальными затратами времени. Важно упомянуть простоту конфигурирования системы с использованием данного подхода. Более того, данный подход и некоторые процедуры могут быть скомпонованы в отдельную библиотеку (DLL – Dynamic Link Library) и использованы в разных приложения (АРМах), взаимодействующих с файлами подобной структуры.

Список литературы

1.   Федеральный закон от 20.02.95 № 24-ФЗ: Об информации, информатизации и защите информации // Российская газета.- 1995. - № 39.

2.   Приказ Госналогслужбы РФ от 03.02.95 № ВП-3-12/4: Об упорядочении разработки и внедрения программно-технических средств автоматизированной информационной системы в налоговых органах // Электронная справочная правовая система «Консультант Плюс».

3.   Инструкция Госналогслужбы РФ от 29.06.95 N 35 (ред. от 15.06.98): По применению закона Российской Федерации: О подоходном налоге с физических лиц. // Российские вести. – 1995.- № 179.

4.   Миллер, Тодд, Пауэл, Дэвид и др. Использование Delphi 3: Спец. изд. /Пер. с англ. – К.: Диалектика, 1997. – 768 с.