Компьютер в бухгалтерском учете и аудите 1998'3
	Home Поиск Издания Контакты k-press.ru

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

Компания “Алеф Консалтинг & Софт”

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

Введение

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

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

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

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

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

Технологические требования к финансовым приложениям

Анализы тенденций рынка финансовых приложений, проводимые различными агентствами, как в России, так и за рубежом, говорят об ужесточении требований к гибкости и надежности систем. В отчетах агентства IDC, обзорах рынка финансового программного обеспечения [1, стр. 34], говорится, что средства построения учетных систем предприятия, не имеющие возможности настроек в широком диапазоне, реализованных без использования ориентированных на выполнение транзакций платформ и языка запросов SQL, не имеющие развитого программного интерфейса взаимодействия и системы контроля прав доступа,— практически не имеют будущего.

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

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

Системные требования к финансовым приложениям.

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

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

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

Известны также примеры “трехслойной” модели, когда данные перегружаются затем в системы, предназначенные для анализа данных и поддержки принятия стратегических решений.

Практически все производители СУБД позиционируют свои продукты либо в классе систем для оперативной обработки (OLTP — On Line Transaction Processing), либо в классе систем, предназначенных для анализа данных (OLAP — On Line Analytical Processing).

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

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

К аналитическому ядру учетной системы предъявляются следующие системные требования:

• поддержка глобальных справочников. Аналитическое ядро, обеспечивая преемственность семантических связей от периферии к центру, от систем оперативного учета к системам поддержки принятия решения, становится удобным, а подчас единственным местом, где может быть поддержана непротиворечивость “локальных” справочников приложений;
• наличие возможности интерпретировать документы различных внешних приложений. Часто обмен информацией обеспечивается обменом документами в каком-либо стандарте (например, EDI). Таким образом, аналитическое ядро должно обладать возможностью интерпретировать документы периферийных систем, которые могут быть разработаны на предприятии или принадлежать третьим фирмам;
• наличие единого информационного поля. Кроме согласованности справочников, единство информационного поля обеспечивается также контролем непротиворечивости состояний различных внешних приложений и системы в целом, как с точки зрения данных, так и с точки зрения логики ведения бизнеса.

Архитектурные требования к финансовым приложениям

С точки зрения сбора и анализа информации хозяйственная деятельность предприятия может быть рассмотрена как совокупность хозяйственных операций. Под хозяйственными операциями понимаются “факты хозяйственной жизни, которые оказывают влияние на финансовое положение фирмы” [3, стр. 19].

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

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

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

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

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

К достоинствам этого подхода можно отнести следующие:

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

Однако документоориентированный подход имеет ряд серьезных недостатков:

• консервативность. Данное свойство характеризуется следующими факторами:
• каждое отслеживаемое состояние хозяйственной операции отмечается определенным значением статуса документа. При этом необходимость контроля промежуточных состояний приводит к переработке алгоритмов и структуры приложения. Добавление новых статусов достаточно часто происходит на уровне ядра данных. Это может отразиться также на внешних приложениях, взаимодействующих с данной подсистемой;
• алгоритмы взаимодействия различных документов должны, как правило, “распознавать” наиболее важные статусы документа (“удален”, “подписан” и т.д.). Таким образом, изменение жизненного цикла документа может привести к необходимости внесения изменений в алгоритмы приложения, обслуживающие логику всех взаимодействующих с ним документов;
• необходимость распознавания состояния на более детальном уровне также приводит к изменению в алгоритмах обработки и структуре данных не только на уровне данного документа, но и на уровне многих документов, связанных с ним;
• “статичность” документоориентированного подхода. Это свойство первого подхода выражается в том, что при нем не сохраняется история операций над документами. В большинстве реализаций документоориентированного подхода достаточно сложно получить запрос о состоянии учетных регистров на какой-либо момент времени. Кроме того, такой подход ведет к утрате информации при отменах статусов. Например, в случае, если документ получил статус “подписан”, а затем был доработан (утратил его) и вновь требует заверения, в большинстве систем нельзя получить информацию о том, что он уже был подписан. Для того чтобы хранить историю операций, документоориентированные системы снабжаются регистраторами действий над документами или иными средствами.
• сложность обработки нестандартных ситуаций. В случае необходимости оперативного изменения состояния какого-либо учетного регистра, если ранее не приходилось его изменять, необходимо создать специальный интерфейс или произвести изменения на уровне данных. Это происходит вследствие того, что документоориентированный подход не предполагает абстрактного подхода к управлению учетными регистрами, независимо от документа, статуса и т.д.

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

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

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

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

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

Примером такой реализации может быть бухгалтерский план счетов и двойная запись. В терминах бухгалтерского учета хозяйственная операция, фиксируемая данным документом, должна быть распознана и представлена в виде двойной записи на счетах плана счетов. “В системе двойной записи факт хозяйственной жизни должен быть зарегистрирован как минимум дважды: по дебету одного и кредиту другого счета таким образом, чтобы общая сумма по дебету уравновешивала общую сумму по кредиту” [3, стр. 37]

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

Среди достоинств второго подхода можно выделить следующие:

• адаптивность. “Развязывание” непосредственных взаимоотношений между документами, появление слоя абстракции между ними, возможность отказа от статусов для отражения хозяйственных операций позволит стабилизировать учетные процессы при нестабильных и быстроизменяющихся хозяйственных операциях и избежать непрерывной коррекции алгоритмов взаимодействия между документами. Данное преимущество выражается также и тем, что в зависимости от реализации мета-структуры даже необходимость более точного отражения той или иной хозяйственной операции не приведет к значительным изменениям в алгоритмах;
• возможность создания единого интерфейса для работы с учетными регистрами. В результате абстрагирования появилась возможность реализации интерфейса для оперативного вмешательства и изменения состояния учетной системы без построения новых документов и внесения изменений в алгоритмы их обработки;
• “динамичность” аналитической картины. При реализации динамической мета-структуры, когда сохраняется не конечное значение учетного регистра, а история его изменений, несложно получать различные временные срезы состояния учетной системы;
• оперативность предоставления аналитической информации. Учетные регистры — это параметры, с помощью которых измеряется состояние хозяйствующего субъекта. Таким образом, для контроля состояния уже подготовлен промежуточный слой. Это позволяет оперативно контролировать изменение состояния предприятия с помощью его модели — мета-структуры учетной системы.

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

Говоря о недостатках данного подхода, следует отметить следующее:

• высокая ресурсоемкость. Очевидно, что для “трансляции” документа в оперативном режиме (OLTP) в мета-структуру возрастает объем вычислительных операций, порождаемый при этом, приведет к возрастанию вычислительной нагрузки. Кроме того, хранение большого объема информации об изменениях учетных регистров выливается в самостоятельную проблему. Отчасти именно этот фактор сдерживал долгое время развитие подобных систем. Лишь с появлением мощных SQL-серверов и удешевлением как SQL-технологий, так и вычислительных мощностей, открылся путь для практической реализации подобных систем.
• проблема интерпретации. Эта проблема связана с неоднозначностью отображения, интерпретации факта хозяйственной деятельности в терминах аналитической мета-структуры. Известно, что различные бухгалтеры при регистрации схожих хозяйственных операций по-разному отображают их на плане счетов.
• проблема оценки. Для отображения хозяйственной операции в мета-структуре необходимо определить, к какому изменению того или иного (или пары) учетных регистров приведет свершение данной хозяйственной операции. Кроме того, в результате хозяйственной деятельности часто происходит изменение ценности того или иного ранее отраженного факта. Это приводит к переоценке — изменению некоторых количественных параметров, связанных с ним.
• проблема сопровождения. Дело в том, что при изменении стратегических и тактических задач, поставленных перед управляющим звеном предприятия, изменятся и необходимые учетные регистры. Более того, может понадобиться пересмотр интерпретации некоторых хозяйственных операций с учетом новых целей. Это, в свою очередь, требует сохранения связи хозяйственной операции и ее “следа” в учетной системе.

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

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

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

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

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

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

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

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

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

“Алеф.Бухгалтерия” как финансовое приложение

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

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

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

Кроме того, система “Алеф.Бухгалтерия” обладает следующими встроенными механизмами:

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

Более полную информацию о системе “Алеф.Бухгалтерия” можно почерпнуть в ранее вышедших статьях [Компьютер в Бухгалтерском учете 1/98, 3/98] и в интернете по адресу http:\\www.alef.ru. Рассмотрим основные этапе организации совместной работы “Алеф.Бухгалтерии” и внешних приложений.

Организация совместной работы учетной системы

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

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

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

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

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

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

Основная задача этого этапа — спроектировать структуру документов-справочников. Выше уже было сказано, что одними из основных требований к системе являются требования синхронизации справочников и поддержания единого информационного поля. Основная роль в этом процессе ложится на документы-справочники. Это обусловлено, с одной стороны, тем, что, документы “Алеф.Бухгалтерии”, обладая широкими возможностями по построению алгоритмов документа, организации действий по событиям документа, являются активным элементом системы. С другой стороны, программный интерфейс системы обладает широкими возможностями по работе с документами из внешних приложений. Используя функции этого интерфейса, можно создать, удалить и изменить документ, провести его в учете или удалить проводки, отыскать необходимый набор документов и получить информацию об их состоянии и значении атрибутов. Кроме того, посредством документов легко организовать обмен данными между двумя системами “Алеф.Бухгалтерия”.

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

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

• Счета и субсчета. Счета и субсчета — это наиболее крупные аналитические образования. Организовывать синтетические счета рекомендуется лишь для консервативных параметров, вероятность трансформации которых достаточно низка. Иерархия счетов — план счетов, как правило, является проекцией укрупненной модели хозяйственной деятельности предприятия или группы предприятий. С помощью счетов организуются агрегатные, учетные регистры, такие как “Касса”, “Товары отгруженные”, “Готовая продукция” и др.
• Учетные регистры, основанные на справочниках. Данные учетные регистры используются для динамических параметров, состав которых быстро изменяется во времени. Кроме того, учитывая, что существует единый механизм (API) для доступа к справочным данным из внешних приложений, данный способ создания учетных регистров очень удобен для согласования семантик различных подсистем. Создав новый справочник, мы имеем возможность использовать его для ведения того или иного учетного регистра несколькими способами.
• Сквозные шифры. Данный способ формирования учетных регистров используется для ведения учетных регистров, имеющих отношение ко многим или всем синтетическим счетам плана счетов. Например, “Вид деятельности”. Трудно сказать, какого синтетического счета он не коснется. Может быть, лишь “Кредиты полученные”.
• Аналитические счета и кодовые признаки. Способ формирования учетных регистров с помощью аналитических счетов хорошо применим в тех случаях, когда параметр имеет локальное действие и “инкапсулирован” внутри какого-либо синтетического счета или субсчета. Для создания аналитического счета выбираются справочники, которые предполагается использовать чаще других для ведения учетных регистров внутри счетов. Кодовые признаки — это способ формирования учетных регистров, при котором каждому признаку для определенного счета или субсчета ставится в соответствие справочник.

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

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

На шестом шаге из элементарных проводок формируются блоки проводок и разрабатываются основные алгоритмы управления блоками при выполнении процедуры интерпретации данных из документов.

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

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

Рассмотрим более подробно возможности организации взаимодействия системы “Алеф.Бухгалтерия” с внешними приложениями.

Механизмы межпрограммного взаимодействия

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

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

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

Рассмотрим механизмы межпрограммного взаимодействия на примере некоторого авиапредприятия. Пусть имеется две подсистемы оперативного учета: обработка полетных заданий (контроль выполненных рейсов) и регистрация поступивших счетов за использованные в аэропортах ресурсы (требования на заправку ГСМ).

Рис. 1. Алеф.Бухгалтерия в качестве пассивного субъекта межпрограммного взаимодействия

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

Рассмотрим первый вариант: при взаимодействии необходимо передать информацию о выполненных рейсах из внешней подсистемы в “Алеф.Бухгалтерию”, причем подсистема обработки полетных заданий должна выполнять активную функцию взаимодействия (см. рис. 1).

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

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

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

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

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

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

Сценарий взаимодействия в этом случае предполагает четыре фазы:

• уточнить, не содержится ли в учетной подсистеме информация о полете, которая должна быть передана. Для этого формируются параметры с условиями поиска (дата, номер рейса, номер борта и др.) и вызывается функция функции FindDocument(), которая возвращает идентификаторы документов, удовлетворяющих указанным условиям. Если необходимо дополнительно уточнить значение какого-либо поля найденных документов, вызывается функция GetDocumentFields() с указанием идентификатора документа и списка полей, значения которых необходимо установить. Если информации о полете не содержится в учетном подсистеме, то можно перейти к следующему шагу;
• создать буферный документ типа “Экспорт данных о полетах” и передать в него всю необходимую информацию. Для этого необходимо сформировав строку параметров для создания документа, вызвать функцию CreateDocument();
• с помощью функции RunAlgorythm() запустить алгоритм созданного документа, который произведет связывание переданной информации с системными справочниками и зарегистрирует в справочнике полетов новый рейс. Подобный алгоритм может не только создать структуру справочников, но и сгенерировать какие-либо проводки, которые изменяют состояние тех или иных учетных регистров.

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

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

Сценарий взаимодействия предусматривает следующие фазы.

• Установление связи по ODBC. С помощью сервиса подсоединения к данным, встроенного в Power Script, создаем SQLCA — SQL Communication Area и посылаем запрос на языке SQL типа “SELECT * FROM TREBOVANIA WHERE ID > ID_LAST”.
• Получение таблицы требований в системе. Посредством протокола ODBC получим таблицу результатов, содержащую список всех требований, которые не были импортированы.
• Импорт отсутствующих требований. С помощью функций API для работы с документами создадим для каждой строки полученной таблицы новый документ-требование.

Рис. 2. Алеф.Бухгалтерия в качестве активного субъекта межпрограммного взаимодействия

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

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

Резюме

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

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

• сложность организации межпрограммного взаимодействия. Эта проблема решается по-разному в каждом конкретном случае. Однако обилие путей ее разрешения достаточно оптимистично позволяет смотреть на построение механизмов межпрограммного взаимодействия. Трудно решаемой является проблема ON-LINE’ового взаимодействия в рамках одной транзакции;
• сложность аналитического пространства. В ходе эксплуатации сложность аналитического пространства возрастает. Наряду с этим, многие из прежде актуальных параметров, теряя значение, все же остаются встроенными в архитектуру аналитического пространства учетной системы. Для того чтобы поддерживать уровень энтропии системы, необходимы регламентные работы по сопровождению учетных регистров и процедуры документирования системы;

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

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

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

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

1. КомпьютерУик-Москва. Финансовое ПО № 44 за 1996
2. Справочник директора предприятия / Под ред. М.Г. Лапусты.— М.: ИНФРА-М, 1996.— 704 с.
3. Принципы бухгалтерского учета / Б. Нидлз, Х. Андерсон, Д.Колдуэлл: Пер с англ. / Под ред. Я.В. Соколова.— 2-е изд.— М.: Финансы и статистика, 1994,— 496 с.: илл. (Серия по бухгалтерскому учету и аудиту)
4. Statement of the Accounting Principles Board № 4 “Basic Concepts and Accounting Principles Underlying Financial Statements of Business Enterprises” (New York: American Institute of Certified Public Accountants, 1970) par.40
5. Управление предприятием. Новый взгляд на старую проблему./ Аксенов Е.Г., Тришанков Л.А., Электронный офис. Сентябрь 1996 года. Подписной индекс 32509
6. Информационное обеспечение деятельности предприятия. Анализ программного обеспечения. / Кварцхелия Н.Г. М., 1997 г. фирма Риккон. Внутренний репринт.
7. Об основных концептуальных положениях “Алеф.Бухгалтерии” можно прочитать во втором номере журнала “Логистика”.
8. Компьютер Уик-Москва № 16 за 1996.
9. Компьютер Уик-Москва № 33 за 1996.

Тел.: (095) 240–93–34

Тел./Факс: (095) 240–00–66

Адрес: 121059, Москва a/y 48

E-mail: public@alef.ru

Интернет: http://www.alef.ru

С вопросами и предложениями обращайтесь digraph@rinet.ru

Copyright © 1994-2016 ООО "К-Пресс"