Версия для печати

Файл в формате pdf

УДК 631.162 : 657.1.011.56

ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ УПРАВЛЕНИЯ АГРОПРОМЫШЛЕННЫМ ПРЕДПРИЯТИЕМ, ПОДСИСТЕМА УЧЕТА БАНКОВСКИХ И КАССОВЫХ ОПЕРАЦИЙ

Кондратьев В.Ю. – к. э. н., доцент

Непомнящий А.А. – студент

Кубанский государственный аграрный университет

В статье описана архитектура и основные особенности разрабатываемой системы бухгалтерского учета на предприятии ОАО "Племзавод им. В.И. Чапаева". Описание представлено на примере подсистемы учета банковских и кассовых операций.

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

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

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

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

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

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

1.  Сервер – процесс, который предоставляет клиентам свои ресурсы и выполняет глобальные функции системы. Физически это, как правило, мощный компьютер в сети (локальной или глобальной), на котором находится централизованная база данных (БД) и программное обеспечение, выполняющее запросы клиентов и общесистемные        задачи [3].

2.  Клиенты – процессы, которые используют информационные ресурсы сервера для своих нужд. Клиентами, как правило, являются пользователи информационной системы, компьютеры которых находятся в общей сети с сервером [3].

В последнее время в больших системах все более широкое распространение получает 3-х уровневая клиент-серверная архитектура ИС, где в сервере системы выделяют 2 основные части:

1) сервер базы данных, на котором находится только система управления базой данных (СУБД), и сама база данных (БД);

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

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

Схема функционирования трехуровневой клиент-серверной архитектуры приведена на рисунке 1.

Рисунок 1 – Упрощенная схема функционирования системы

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

1.  Oracle Database 10g – система управления базами данных, использующая клиент-серверную архитектуру;

2.  Oracle Application Server 10g – многофункциональный сервер приложений, играющий роль "среднего звена" в системе;

3.  Oracle Developer Suite 10g – пакет программ для разработки пользовательского интерфейса.

Также были использованы многие прикладные программы, которые входят в комплект поставки вышеперечисленных программных пакетов. Кроме программ фирмы Oracle при разработке системы использовались программные продукты фирм Quest Software, Adobe и Microsoft.

Из пакета Oracle Developer Suite были использованы Forms Developer для разработки форм и Report Developer для создания отчетов. Эти программы позволяют, используя визуальные средства проектирования, создавать интерфейсы форм ввода данных, а также шаблоны отчетов, которые будут заполняться данными в реальном времени использования ИС.

Если говорить о том, как же работают приложения, созданные с помощью Oracle Developer Suite, то здесь схема довольно проста. Все приложения, запущенные клиентами, фактически исполняются на сервере приложений. Это достигается за счет использования Java-сервлетов, которые работают на сервере приложений. Для каждого подключившегося клиента запускается свой процесс виртуальной машины Java, это обеспечивает параллельность их работы. Java-сервлеты принимают запросы пользователей, обрабатывают их и посылают обратно результирующую информацию. Если в запросе клиента содержится обращение к БД, то сервлет связывается с СУБД Oracle через специальный драйвер JDBC.

Так как пользователю для работы предоставляется Web-интерфейс, то все приложение работает внутри окна Internet-браузера. Чтобы это было возможным, в окно браузера встраивается Java-апплет, который загружается с сервера автоматически. Апплет отображает все формы, которые открывает пользователь, и держит связь с Java-сервлетом. Таким образом, внутри окна браузера реализуется полноценный многооконный интерфейс.

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

Если требуется защитить передаваемую информацию, то это можно успешно выполнить средствами Application Server. Он поддерживает многие технологии защиты данных (протокол HTTPS, отдельный сервер авторизации, Oracle Internet Directory и др.).

Конечно, может возникнуть вопрос: а нужно ли кому-то работать с бухгалтерской системой через Internet? В большинстве случаев, наверное, не нужно. Тем не менее сейчас у сотрудников некоторых предприятий есть потребность в удаленной работе. Особенно если это предприятие имеет много территориально удаленных подразделений. Стоит ли в каждом подразделении устанавливать свою отдельную базу данных, с которой они будут локально работать, а потом думать над тем, как все эти данные собрать в центральную БД? Или лучше один раз настроить сервер и подключить все подразделения через Internet для работы в реальном времени?

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

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

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

Рисунок 2 – Документ "Расходный кассовый ордер"

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

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

В поле "Основание" записывается основание выписки документа. Оно указывается почти всегда, так как нужно знать, за что деньги получены, или на какие цели выданы. Значение поля "Основание" часто совпадает с назначением платежа, которое указывается в проводках документа, а точнее, назначение платежа является более общим понятием, чем основание. Например, назначение платежа – "услуги автобуса", а основание – "услуги автобуса (3 часа)". Для того чтобы каждый раз не набирать в основании тот текст, который уже был выбран из справочника в назначении платежа, рядом с полем "Основание" существует кнопка "Скопировать из назначения платежа". Из назначения платежа в поле "Основание" она копирует текст, который можно затем пополнять и редактировать.

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

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

В каждом документе можно вводить несколько проводок (рис. 3). На самом деле стандартные формы кассовых документов содержат всего одну строку для проводки [2], хотя для проводок там заранее предусмотрена таблица, поэтому все существующие бухгалтерские системы позволяют вводить и распечатывать также всего одну проводку. Но в бухгалтерском учете встречаются случаи, когда к документу желательно привязать несколько проводок и вывести все их на печать в документе. В подсистеме "Банк-касса" эта возможность реализована во всех документах.

Рисунок 3 – Проводки документа

Если все документы за день по банку или кассе внесены и проведены, то по ним уже требуется получать отчеты. Но перед этим еще нужно ввести остатки по счетам на начало и конец дня [2].

Для ввода остатков существует специальная форма "Ввод остатков" (рис. 4), где по каждому счету (банковскому или кассовому) вводится дата и остатки на начало и конец дня на эту дату.

Рисунок 4 – Ввод остатков

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

В подсистеме разработаны следующие виды отчетов за день (рис. 5):

-  кассовая книга;

-  отчет кассира;

-  журнал и ведомость № 1, 2;

- расшифровка;

-  расшифровка по клиентам;

-  расшифровка по корсчетам;

-  расшифровка по назначению платежа.

Отчеты за произвольный период (рис. 6):

-  журнал № 1, 2;

-  ведомость № 1, 2;

-  расшифровка журнала по датам;

-  расшифровка журнала по клиентам;

-  расшифровка журнала по назначению платежа;

-  расшифровка журнала по корсчетам;

-  расшифровка ведомости по датам;

-  расшифровка ведомости по клиентам;

-  расшифровка ведомости по назначению платежа;

-  расшифровка ведомости по корсчетам.

Также доступно получение следующих справок за произвольный период:

-  справка по физ. лицу;

-  справка по клиенту;

-  справка по счету;

-  справка по назначению платежа.

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

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

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

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

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

Нам пришлось работать с программой "Клиент-Сбербанк" Сбербанка РФ. Формат файлов данных у нее свой – DDF, структура которого нигде не описана. Однако программистами Сбербанка предусмотрена функция "Экспорт" в программе, которая предназначена для выгрузки данных в другие форматы. С первых минут изучения работы этих функций стало ясно, что они сильно недоработаны, а реализованные в них возможности плохо отлажены. В принципе, программа должна обеспечивать выгрузку данных в 3 формата: DDF, DBF и текстовый файл. Мы остановились на самом простом и понятном для нас варианте – текстовый файл. После продолжительного общения со специалистами банка нам все-таки удалось добиться корректной выгрузки банковских выписок в текстовый файл определенной структуры.

В СУБД Oracle есть возможность подключать текстовый файл к базе данных с описанием его структуры и использовать его как обычную таблицу, доступную только для чтения. Таким образом, открывается путь использования выгрузки из "Клиент-Сбербанк" для загрузки в нашу БД с использованием стандартных средств.

Происходит это следующим образом. Пользователь в программе "Клиент-Сбербанк" заходит в журнал выписок банка, отмечает документы, подлежащие выгрузке, и выбирает операцию "Экспорт данных". Информация о документах сохраняется в текстовом файле в определенном формате. Далее этот файл копируется по локальной сети на сервер, где установлена СУБД Oracle, все это происходит средствами ОС Windows. СУБД, обнаружив новую версию файла, подключает его как внешнюю таблицу. Теперь остается только обработать данные внешней таблицы и загрузить их в таблицы документов системы. Для этих целей была создана форма "Загрузка документов банка" (рис. 7).

Внутри формы входящие и исходящие документы сразу разделяются и попадают на разные закладки.

Теперь пользователю нужно выполнить определенные операции, чтобы подготовить документы из "Клиент-Сбербанк" к загрузке в подсистему "Банк-касса". Так как в системе бухгалтерского учета существует свой справочник клиентов предприятия, то при загрузке документов нужно поставить соответствие между клиентами из документов "Клиент-Сбербанк" и клиентами нашего справочника. Если и в выгрузке данных, и в справочнике клиентов указаны ИНН клиента, то программа загрузки поставит соответствие между клиентами автоматически, и пользователю здесь большего ничего делать не нужно. Если же клиент в справочнике не был найден по своему ИНН, то программа автоматически предложит создать в справочнике нового клиента по данным из программы "Клиент-Сбербанк". Если клиент не найден, то в поле "Клиент из справочника" отображается надпись "<Новый клиент>", это значит, что если пользователь не выберет клиента вручную, то в справочнике будет создан новый клиент с теми реквизитами, которые получены из банковской выгрузки.

Кроме выбора клиентов, пользователю предстоит также указать бухгалтерскую проводку по каждому документу. По умолчанию программа предлагает проводку, с которой пользователь может согласиться или же заменить ее своей. Программа загрузки рассчитана на работу с несколькими расчетными счетами предприятия, каждому из которых соответствует определенный субсчет 51-го счета в плане счетов [1]. Это соответствие указано в справочнике расчетных счетов, поэтому при присвоении документу проводки по умолчанию в зависимости от расчетного счета предприятия сразу указывается правильный субсчет. Как показывает практика, пользователям приходится исправлять только некоторые проводки из тех, что предложены по умолчанию.

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

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

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

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

Учет банковских и кассовых операций – это сравнительно небольшая задача, если рассматривать весь учет предприятия в целом. Но даже в такой задаче есть множество индивидуальных особенностей, которые необходимо учитывать при разработке.

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

Конечно, особенной является и архитектура всей системы. Можно отметить использование мощной СУБД, Web-интерфейс всей системы, современные средства администрирования и защиты информации на самом высоком уровне, а также гибкие возможности масштабирования.

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

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

1. План счетов бухгалтерского учета финансово-хозяйственной деятельности организаций и Инструкция по применению Плана счетов бухгалтерского учета финансово-хозяйственной деятельности организаций, утвержденных приказом Минфина РФ от 31 октября 2000 года № 94н (в редакции изменений и дополнений, внесенных приказом Минфина РФ от 7 мая 2003 года № 38н).
2. Никитин, В.М. Теория бухгалтерского учета. Дело и Сервис / В.М. Никитин, Д.А. Никитина. – М., 2004.
3. Кайт, Том. Oracle для профессионалов. – М. : Торгово-издательский дом DiaSoft, 2003.