Компьютер в бухгалтерском учете и аудите 1997'3

Home

Поиск

Издания

Контакты

k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

"Алеф.Бухгалтерия" как средство построения учетной информационной системы предприятия

Постановка проблемы

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

"Система бухгалтерского учета - это основная информационная система предприятия. Она предназначена для формирования внутренних отчетов:

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

"Составление внешних отчетов относится к сфере финансового учета...., а составление внутренних отчетов - к системе управленческого..." [1]

В книге "Управленческий учет" Рэя Вандер Вила и Виталия Федоровича Палия дается перечень целей систем бухгалтерского учета:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура аналитического пространства системы "Алеф.Бухгалтерия"

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

Рис. 1. Структура аналитического пространства "Алеф.Бухгалтерии". 1 - дерево плана счетов, 2 - разделы, 3 - проводки

Рис. 2. Структура проводки. Коды и сквозные шифры

Однако для получения аналитической информации не всегда достаточно аналитического пространства, организованного в виде иерархии. Например: из понятий зимний/летний, женский/мужской, взрослый/детский,- невозможно построить иерархию, хотя все эти понятия могут относиться к одному и тому же объекту аналитического учета,- следовательно, эти понятия невозможно расположить в традиционном "плоском" и иерархическом плане счетов. Для расширения аналитических возможностей в "Алеф.Бухгалтерии" используются механизмы сквозного шифрования и кодирования. Для сегментации пространства идентифицируемых состояний используются "разделы"[3]. Каждый "счет" плана счетов может быть открыт в том или ином разделе независимо. На рис. 1 схематически изображена структура аналитического пространства "Алеф.Бухгалтерии". Дерево плана счетов (1) представляет собой иерархию "счет-субсчет-аналитический счет". В качестве аналитического счета может быть использован любой аналитический справочник. Каждый раздел (2) охватывает свою область на дереве плана счетов. Эти области могут быть полностью независимы, пересекаться или совпадать. Это определяется на уровне администрирования и может быть изменено в процессе эксплуатации. Проводки (3) могут иметь несколько окончаний(рис. 2). Каждое окончание может быть окрашено в аналитическую палитру с помощью кодирования, вся проводка в целом - с помощью сквозных шифров. Сквозные шифры пронизывают весь массив проводок независимо от разделов. В качестве источника информации для кодирования и сквозного шифрования выступают аналитические справочники системы.

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

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

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

Документы системы "Алеф.Бухгалтерия"

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

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

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

Рис. 3. Документ "Алеф.Бухгалтерии".

Документы обладают мощным арсеналом свойств, позволяющих гибко конфигурировать систему при настройке для конкретного предприятия:

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

Один и тот же тип документа может выглядеть различным образом и правила проведения его в учете не столь просты и однозначны. Для каждого типа документов "Алеф.Бухгалтерии" предусмотрена возможность определить несколько вариантов форм документа и несколько вариантов алгоритмов и схем проводок.

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

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

Анализируя необходимость создания собственного редактора форм и отчетов, мы приняли решение использовать в этом качестве инструментарий, поставляемый фирмой Sybase (Powersoft) Power Builder Desktop. Данный инструментарий предлагаемый по цене 200$, обладает следующими преимуществами по сравнению с "самодельными" генераторами и компиляторами:

реализует все основные элементы Windows интерфейса для создания форм;
позволяет создавать алгоритмы на языке PowerScript, который, с одной стороны, позволяет настройщику, не являющемуся профессиональным программистом, создать необходимый алгоритм с использованием элементарных операторов. С другой стороны, для профессионального программиста открываются широчайшие возможности программирования и использования встроенного SQL как для прямых запросов к базе данных, так и для интеграции с другими источниками данных;
является тиражным продуктом, широко представленным на рынке программного обеспечения, поддерживается и развивается известным независимым поставщиком;
имеет подробную документацию;
предназначен не только для решения указанной задачи, а позволяет решать много сопутствующих задач, вплоть до создания приложений в рамках технологии "клиент-сервер".

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

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

Формы документов

Новые типы документов могут быть созданы путем рисования внешнего вида - формы нового документа с помощью DataWindow Painter - художника Окон Данных, входящего в состав Power Builder. Технолгия предусматривает следующие шаги:

Вызвать PowerBuilder Desktop, перейти в DataWindow Painter и установить вид будущей формы - свободная (поля располагаются на форме без ограничений), табличная, график и др.
Заполнить таблицу, перечисляющую названия и типы полей создаваемой формы. Названия и типы полей, общих для различных форм одного типа документов, должны совпадать. После окончания ввода нажатием кнопки "OK" подтвердить правильность списка: поля документа автоматически появятся на форме.
Разместить поля на форме желаемым образом и придать нужный размер и стиль: обрамление, надписи, линии, цвет и шрифт элементов и др.
Определить порядок обхода курсора по полям формы и указать недоступные при обходе поля и сохранить созданную форму в файле библиотеки Power Builder (формат *.PBL). При необходимости можно добиться сходства формы с тем объектом, с которым привык работать пользователь.
Дальнейшая работа с формами происходит с помощью "Алеф.Бухгалтерии".

Каждый документ "Алеф.Бухгалтерии" относится к определенному типу (платежное поручение, счет-фактура, акт взаимозачета и пр.) и может иметь несколько форм и схем проводок. Тип документа - это совокупность всех полей, форм и алгоритмов и схем проводок документа. Каждая форма может использовать не все множество полей, а лишь некоторое их подмножество.

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

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

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

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

Для использования подготовленных в Power Builder Desktop форм в системе "Алеф.Бухгалтерия" необходимо произвести следующие действия:

Находясь в режиме "Настройка типов документов", нажать кнопку "Новый тип/форма", указать нужный файл *.PBL и загрузить нарисованную форму с указанием для какого типа документа она предназначена. Если указаный тип документа уже зарегистрирован в системе, то форма прибавляется к множеству его форм. При этом происходит проверка полей, которые использует новая форма. Если новая форма использует поля, которых не было в предшествующих формах - эти поля добавляются к множеству полей документа. Если при загрузке формы было указано название типа документа, которое раньше не встречалось, создается новый тип документа.
Присвоить полям, если это необходимо, названия на русском языке и указать значение "по умолчанию", другие атрибуты и связать их с аналитическими справочниками.
После распределения прав на использование формы пользователь может ею воспользоваться.

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

копирования уже ранее созданных документов;
предварительного заполнения некоторых полей "по умолчанию" при создании нового документа (по указанному значению, по различным предопределенным алгоритмам - автоинкремент ежедневный, ежегодный и др., по значению соответствующего поля из последнего зарегистрированного пользователем документа данного типа и др.);
предварительного заполнения полей значениями, полученными в результате сложных алгоритмов по событию "создание документа" (см. ниже);
возможности ограничения значений вводимых полей посредством предложения выбора из списка перечисленных вариантов с использованием стандартных элементов Windows интерфейса (list box, radio button, check box, compo box и др.);
справочного сервиса, позволяющего избежать повторного ввода информации: при заполнении поля документа может быть вызван аналитический справочник, который определенным образом, указанным в настройках, заполнит поля документа.

Алгоритмы документов

При работе с документом существует возможность использовать специальные алгоритмы, которые предназначены как для предварительного вычисления значений полей, контроля правильности заполнения и установки аналитических признаков, так и для обмена информацией с другими источниками данных. Особым подмножеством алгоритмов документа являются схемы проводок. Они заполняют специальные структуры для генерации проводок. Алгоритмы документов - это программы на языке Power Script, изолированные от всей остальной системы. Алгоритмы взаимодействуют с объектами системы, с таблицами базы данных, с окнами клиентского приложения и с глобальными переменными исключительно посредством специального программного интерфейса, имеющего предметно-ориентированный характер. Настройщик системы может и не быть знаком с элементами построения системы - структурой данных, архитектурой клиентского приложения, использованными алгоритмами, соглашениями и ограничениями. При создании алгоритмов он использует названия полей документа, которые сам создал и предметно-ориентированные понятия, такие как остаток по счету, оборот по счету, курс валюты и др. Кроме того, для создания логических цепочек используется несколько базовых понятий программирования: объявление переменных, операции присвоения, арифметические операции, средства организации циклов и условий если - то - иначе и т.д.

Эти алгоритмы на русском языке могут выглядеть так:

ДЛЯ ДОКУМЕНТА "ПЛАТЕЖНОЕ ПОРУЧЕНИЕ"
Проводку можно сделать, если заполнено поле: "Дата проведения банком"
Дата проводки равна "Дате проведения банком".
Сумма проводки равна "сумме платежного поручения".
Счет кредита проводки равен 51.
Счет дебета проводки определяется исходя из типа платежа.
Если оплачивается счет поставщика, то счет 60.
Если происходит оплата договора купли ценных бумаг, то счет 76.

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

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

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

Алгоритмы могут быть выполнены как автоматически (автозапуск), так и по команде. Для инициирования автозапуска в системе предусмотрены следующие "события", с которыми можно связать выполнение алгоритма:

"перед созданием документа";
"перед сохранением документа";
"после сохранения документа";
"по созданию проводок";
"по удалению проводки" и др.

При наступлении события алгоритм, связанный с ним, выполняется безусловно. Кроме того, существует возможность ручного запуска алгоритмов. Алгоритм, созданный в PowerBuilder Desktop, должен быть помещен в специальную библиотеку (PROVPATT.PBD) и объявлен в системе. Для этого необходимо, находясь в режиме "Настройка типов документов", нажать кнопку "Схемы проводок" и указать название схемы. Затем рекомендуется ввести ее название на русском языке, отражающее смысл действий, производимых ею, и разрешить использование из меню "Администрирование\Документы и группы".

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

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

Предположим, что на счете 62-1 (Расчеты с покупателями и заказчиками) ведется аналитический учет в разрезе контрагентов (покупателей). Для этого к счету 62-1 в качестве справочника аналитических счетов подключен справочник юридических лиц. Допустим, этот справочник имеет номер 4. Кроме того, для того, чтобы знать кто является должником предприятия, по какому счету-фактуре и как давно, по счету 62-1 ведется учет в разрезе счетов-фактур, которые выставляются покупателям. Для этого к счету 62-1 в качестве 1-го дополнительного аналитического кода (код 1) подключен справочник счетов-фактур.

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

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

Стратегии внедрения и организации взаимодействия

Рассматривая пути построения учетных систем предприятия, можно выделить две альтернативы: "белого листа" и "эволюции".

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

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

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

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

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

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

При проектировании взаимодействия с внешними приложениями следует различать несколько существенных моментов:

направление информационного потока;
инициативу по обмену информацией. Всегда крайне важно на стороне какого из приложений находится инициатива; кто является потребителем, а кто поставщиком при осуществлении взаимодействия.
вид взаимодействия. Взаимодействие может быть в реальном времени (on line) и сеансовым (off line).

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

Если нет возможности управлять логикой унаследованного приложения по причине недоступности кодов или др., инициативным звеном по организации взаимодействия может выступать "Алеф.Бухгалтерия". В этом случае удобно использовать алгоритмы документов на языке Power Script. Если подобных алгоритмов накоплено много, рекомендуется создать тип документа "Взаимодействие с ПО" и в одной из его форм, на которой отображается служебная информация о ходе процесса взаимодействия, собрать все соответствующие алгоритмы, из которых будут создаваться проводки, документы и т.д. Для доступа к информации унаследованных приложений используются возможности Power Builder для подсоединения к различным источникам данных - средства доступа ODBC и встроенный язык SQL. Для этого необходимо разобраться в структуре данных унаследованного приложения.

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

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

Для иллюстрации возможностей по организации взаимодействия с внешними приложениями рассмотрим следующий пример.

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

Допустим, что в приложении "Зарплата" есть необходимая информация. Для того чтобы импортировать эту информацию, необходимо:

спроектировать структуру проводок, которые будут генерироваться в "Алеф.Бухгалтерии", структуру документа и набор полей, необходимых для этого;
создать новый тип документа "данные о зарплате" для ввода информации о начислениях зарплаты за определенный период;
подобрать ODBC драйвер для доступа к данным "Зарплаты";
создать и протестировать SQL - выражения для импорта данных. Это можно сделать как с помощью Power Builder Desktop, так и с помощью Microsoft Query, входящего в стандартный набор Microsoft Office;
встроить SQL-выражения в алгоритм документа для импорта информации;
дополнить алгоритм операциями, производящими необходимые вычисления, и функциями, заполняющими поля и структуру для проведения документа в учете.

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

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

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

Примером организации такого взаимодействия может быть проект, реализуемый компанией "Весть" для компании-участника фондового рынка. В рамках этого проекта система управления документами "Work Route 2", управляет вызовом той или иной формы "Алеф.Бухгалтерии" на основании информации о выполнении определенной бизнес-процедуры по карте процесса. При сохранении отредактированной формы или регистрации проводок по документу алгоритмы формы устанавливают флажки карты процесса, сигнализирующие прохождение определенной фазы.

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

Заключение

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

Нашими клиентами являются такие организации, как Авторское Телевидение, ГТК Россия, Финансово-расчетный центр СП "Рашшин Траст энд Трэйд", Институт космического приборостроения, Издательский дом "Империум" и др.

Компанию "Алеф.Консалтинг" связывают партнерские отношения как с производителями программного обеспечения ("Весть АО", "АиТ"..), так и с независимыми компаниями, оказывающими услуги по внедрению программного обеспечения ("Май", "Каисса", "Риккон").

Литература

Хорнгрен и Фостер. Бухгалтерский учет: управленческий аспект., Москва. Финансы и статистика.,1995 г
Рэй Вандер Вил, Виталий Палий. Управленческий учет., Москва. Инфра-М., 1997г.
Компьютер в бухгалтерском учете N2 1997 г.
Нидлз, Андерсон, Колдуэлл. Принципы бухгалтерского учета., Москва. Финансы и статистика., 1994 г.

Справка:

Алеф.Бухгалтерия 2.0 Client/Server для Windows 95 / Windows NT / MS SQL Server
Разработчик - компания "Алеф Консалтинг".
Тел. 240-39-34, факс 240-00-66
E-mail: alef@alef.msk.su, WWW-сервер: www.alef.ru
На выставке SofTool наш стенд Н6